Die Projektdaten sind in drei Kategorien unterteilt. Je nach Hersteller können die Angaben und auch die Kennzeichnungen der Pflichtfelder variieren (Abb. 1 [Standard], Abb. 2 [KRONE]). Dies wird über die Config gesteuert.
Angaben zur Abwicklung sind im Backend (PIA) einstellbar. Je nach Hersteller können die Angaben und auch die Kennzeichnung der Pflichtfelder variieren. Dieses wird über die Config gesteuert.
Projekt Abwicklung (Tab 1)
Abwicklung / Auftrag
Um ein Projekt zu Speichern, muss der Anwender verschiedene Angaben zur Abwicklung tätigen.
Ein Ausrufe Symbol kennzeichnet noch auszufüllende Pflichtfelder.
Ein Haken Symbol macht vollständige Angaben deutlich.
Der Anwender kann verschiedene Angaben (z.B. Lieferbedingung, gewünschter Liefertermin) dem Projekt hinzufügen, damit kundenspezifische Anforderungen im Projekt gespeichert werden. Je nach Hersteller können die Angaben und auch die Kennzeichnungen der Pflichtfelder variieren (Abb. 1 [Standard], Abb. 2 [KRONE]). Dieses wird über die Config gesteuert. In der Config kann vom jedem Hersteller gesteuert werden, welche Angaben im Bereich der Abwicklung optional (optional) oder benötigt (required) sind. Sind diese Angaben unvollständig, kann das Projekt nicht gespeichert werden.
Angaben zur Abwicklung sind im Backend (PIA) einstellbar. Je nach Hersteller können die Angaben und auch die Kennzeichnung der Pflichtfelder variieren. Dieses wird über die Config gesteuert.
Beispiel Zahlungsbedingungen
Zahlungsbedingungen können - in den Einstellungen - zu einer Liste zusammen gestellt werden. Diese Vorauswahl wird hier angezeigt und kann vom Anwender ausgewählt und dem Projekt hinzugefügt werden (Abb. 3).
Je nach Zahlungsbedingung setzt die Anwendung dann zum Beispiel 180 Tage netto.
Verwaltung der Zahlungsbedingungen via Configfile.
Beispiel Statuseinträge (Hier die andere Seite verlinken)
Der Benutzer kann den Projektstatus
Ein Projekt kann mehrere Statuseinträge durchlaufen. Dieser Projektstatus kann vom Anwender bearbeitet werden. Je nach Hersteller kann der Projektstatus variieren (Abb. 4 [Standard], Abb. 5 [KRONE]).
Ein Statuswechsel ist durch Bedingungen beschränkt. Diese Bedingungen müssen bei einem Projektstatus erfüllt sein, damit ein Statuswechsel durchgeführt werden kann. Kann ein Statuswechsel nicht durchgeführt werden, weil Bedingungen nicht erfüllt sind, sind die jeweiligen Projektstatus grau hinterlegt und können nicht ausgewählt werden. Bei einer Auswahl werden dem Anwender dann die Bedingungen angezeigt, die fehlschlagen (Abb. 6).
Modul Projekte → Workflow Status (Aktion wählen)
Verwaltung der Projektstatus befindet sich im Backend (PIA).
Neben der grau hinterlegten Darstellung des Projektstatus dient ein Info-Icon als zusätzlicher Hinweis.
Beispiel Projektbeziehungen
Wenn das Projekt keine Projektbeziehung anzeigt, dann hat das Projekt keine Beziehungen zu einem anderen Projekt (Abb. 7).
Bei einer Projektkopie kann der Anwender den Bezug zum Ursprungsprojekt erhalten. Das Originale Projekt und die Kopie stehen dann in einer Beziehung (parent / children). Dieser Zusammenhang wird im Bereich der Projektbeziehung visuell dargestellt (Abb. 8).
Eine Baumstruktur zeigt dem Benutzer die übergeordneten (parent) und zugeordneten (children) Projekte an.
Das Ursprungsprojekt wird mit dem Hinweis Original gekennzeichnet. Die daraus abgeleiteten Kopien werden mit dem Zusatz ∟ und dem Erstellungsdatum gekennzeichnet. Das aktuell geöffnete Projekt wird zudem noch fett gedruckt dargestellt.
Über das Symbol kann der Anwender jederzeit in die anderen Projekte wechseln.
Beispiel 1
Im Beispiel 1 wird das Projekt OD-62881 angezeigt (Abb. 8). In den Projektbeziehungen wird das Projekt zudem noch fett gedruckt dargestellt, da sich der Anwender in diesem Projekt befindet. Dies ist das Ursprungsprojekt (Original) aus dem eine Kopie OD-62882 erstellt wurde.
Beispiel 2
Im Beispiel 2 wird das Projekt OD-62882 angezeigt (Abb. 9). In den Projektbeziehungen wird das Projekt zudem noch fett gedruckt dargestellt, da sich der Anwender in diesem Projekt befindet. Dies ist die Kopie des Ursprungsprojektes OD-62881, da dieses Projekt unterhalb des Originals mit dem Zusatz ∟ gekennzeichnet ist.
Projekt Speichern
Bei der Speicherung wird das Projekt zum Backend (PIA) geschickt und gespeichert. Das PIA weist dem Projekt eine OD-Nummer (OrderID) zu und ist anhand dieser OD-Nummer auf den Anwendungen und im PIA eindeutig auffindbar (Abb. 10). Diese OD-Nummer kann beispielsweise in der Suche nach Projekten verwendet werden.
Projekt Verlauf
Der Anwender kann verschiedene Angaben hinterlegen. Je nach Hersteller können die Angaben und auch die Kennzeichnungen der Pflichtfelder variieren. Unter Verlauf können u.a. Wiedervorlagetermine festgehalten werden (Abb. 1 [Standard]). In der SalesApp werden die Termine im iPad Kalender gespeichert und der Anwender wird an das Fälligkeitsdatum erinnert. In der WebApp können die Termine lediglich eingetragen werden. Unter Angebot können u.a. Ergänzungstexte zum Angebot hinterlegt werden (Abb. 2 [KRONE]).
Angaben zum Verlauf sind im Backend (PIA) einstellbar. Je nach Hersteller können die Angaben und auch die Kennzeichnung der Pflichtfelder variieren. Dieses wird über die Config gesteuert.
Beispiel Grund für Auftragsverlust [Standard]
In der Standard Version können unter Verlauf auch unterschiedliche Gründe für z.B. einen Auftragsverlust eingepflegt werden (Abb. 3). Dem Anwender stehen hier vorgegebene Auswahllisten zur Verfügung. Diese Daten können für verschiedene Auswertungen genutzt werden.
Die hier aufgeführten Angaben werden über das Backend (PIA) im Bereich der Projektoptionen eingestellt.
Beispiel Ergänzungstext zu Beginn des Angebots [KRONE]
In der KRONE Version können unter Angebot auch unterschiedliche Ergänzungstexte zum Angebot eingepflegt werden (Abb. 4). Dem Anwender stehen hier freie Eingaben zur Verfügung, die anschließend auf dem Endkundendokument erscheinen. Diese Daten können ebenfalls für verschiedene Auswertungen genutzt werden.
Die hier aufgeführten Angaben werden über das Backend (PIA) im Bereich der Projektoptionen eingestellt.