Dieser Beitrag schließt sich an den vorherigen an und erweitert diesen in der Art und Weise, dass nun eine projektbezogene Ausgabenrechnung erfasst wird, die eine explizite Genehmigung des Projektleiters erfordert. Für diese explizite Genehmigung wurde ein zusätzlicher Workflowschritt (‘PM review‘) in den zuvor verwendeten Workflow eingebaut.

Bitte beachten sie, dass der neue Workflowschritt der Aufwendungsprüfergruppe ‚Approver‘ zugeordnet wurde …

…, welche vom Projektleiter eine explizite Genehmigung erfordert.

Um sicherzustellen, dass der zusätzliche Workflowschritt nur dann ausgeführt wird, wenn eine Projektrechnung erfasst wird, wurde folgende Bedingung an die Ausführung dieses neuen Workflowschritts geknüpft.

Für den Fall dass eine gewöhnliche Rechnung ohne Projektbezug erfasst wird bedeutet dies, dass der zusätzliche Workflowschritt unmittelbar übergangen bzw. abgeschlossen wird.

Bitte beachten sie, dass für das nachfolgend dargestellte Beispiel Susan Burk als Projektleiterin festgelegt wurde.

Wird nun eine Rechnung mit der entsprechenden Projektnummer erfasst, so wird eine zusätzliche Workflowschleife über Susan Burk abgearbeitet bevor der Linienvorgesetzte der Bestellers die Rechnung wie üblich zu genehmigen hat.

Für den Fall dass keine Projektnummer bei der Rechnungserfassung angegeben wurde, entfällt der zusätzliche Genehmigungsschritt natürlich.

Dieser Beitrag schließt den ersten Teil zur manuellen Rechnungserfassung mit ein oder mehreren Genehmigungsschritten für Aufwandsrechnungen ab.

Als Zwischenfazit kann bislang festgehalten werden, dass die im Standard von Dynamics AX/365 for Operations verfügbaren Rechnungsworkflowfunktionen eine Vielzahl unterschiedlicher Rechnungsgenehmigungsszenarien abbilden können. Was aus Sicht des Verfassers allerdings fehlt ist eine übergreifende Übersicht die aufzeigt, welchen Mitarbeitern welche Rechnungen zur Genehmigung zugeordnet wurden und in welchem Genehmigungsstadium sich diese Workflows befinden.

Die nächsten Beiträge beschäftigen sich ebenfalls mit aufwandsbezogenen Rechnungen, die allerdings mit Bestellanforderungen verknüpft bzw. von dort aus gestartet werden.

Dieser Beitrag setzt den vorherigen in der Art und Weise fort, dass nun Michael Redmond, der account manager, die Materialien bestellt und die zugehörige Rechnung von dessen vorgesetzten Kevin Cook genehmigt werden muss. Das folgende Organigramm stellt die entsprechenden Beziehungen der am Workflow beteiligten Personen nochmals überblicksmäßig dar.

Um auch diese zweite Linienstruktur im Rahmen des Genehmigungsworkflows abbilden zu können wurde eine neue Positionshierarchie (LRE Signing 2) eingerichtet, die Kevin Cook als entsprechenden Linienverantwortlichen einschließt.

Die neu eingerichtete Positionshierarchie wird im Anschluss einem neuen Rechnungsworkflow zugeordnet …

… der identisch zum vorherigen Workflow eingerichtet wurde bis auf die Tatsache, dass dieser Workflow nur dann aktiviert wird, wenn der Mitarbeiter 000050 (Michael Redmond) als zuständiger sachlicher Prüfer im Finanzdimensionsmitarbeiterfeld der Rechnung hinterlegt ist.

Anschließend wurden zwei Rechnungen erfasst. Die erste mit Nicole Holiday als sachlicher Prüferin und eine zweite mit Martin Redmond als sachlichem Prüfer. Die nachfolgenden Screenshots zeigen auf dass in beiden Fällen immer der richtige Linienverantwortliche mit der Genehmigung der Rechnung vom Workflow angesprochen wird.

Zusammenfassend kann man aus diesem und dem vorherigen Beitrag festhalten, dass über die Einrichtung mehrerer Positionshierarchien und Workflows auch mehrstufige, komplexe Unterschriftsregeln im Standard von Dynamics AX/365 for Operations abgebildet werden können.

Ein Gesichtspunkt der bislang noch nicht weiter erörtert wurde betrifft den Umstand, dass alle Rechnungen bislang von einem einzigen Mitarbeiter aus der Buchhaltung (Phyllis Harris) erfasst wurden, der gleichzeitig den Rechnungsworkflow als sog. Originator initiierte. In der Praxis werden Rechnungen in der Regel von einer Vielzahl an Mitarbeitern erfasst, die basierend auf den obenstehenden Einstellungen alle als Workflow Originator agieren würden und demzufolge in der Positionshierarchie zu berücksichtigen wären. Im Ergebnis wären demnach eine Vielzahl an Positionshierarchien und Workflows einzurichten. Diese Problemstellung lässt sich derart umgehen, dass lediglich ein einziger repräsentativer Mitarbeiter aus der Buchhaltung in der Positionshierarchie hinterlegt und gleichzeitig als Workflow Owner deklariert wird, wie dies im nächsten Screenshot dargestellt ist.

Wird nun der Workflowgenehmigungsschritt derart ergänzt, dass er vom Workflow owner ausgehend startet, kann das oben beschriebene Problem vermieden werden.

Der nächste Beitrag erweitert den hier dargestellten Workflow auf solche Fälle bei denen projektbezogene Rechnungen erfasst werden, die vom Projektleiter explizit freigegeben werden müssen.