Kostenrechnung (3)

Schlagwörter

, , ,

Nachdem im vorherigen Beitrag die Klassifizierung der Kostenarten in primäre und sekundäre Kostenarten aufgezeigt wurde, sollen die entsprechenden Daten nun erstmals dargestellt werden. Für diese Darstellung ist die Einrichtung eines sog. cost accounting ledgers (deutsche Begriff ‚Kostenrechnungssachkonten‘) erforderlich. Siehe hierzu auch den folgenden Screenshot.

Im Rahmen der Einrichtung dieses cost accounting ledgers ist es zunächst notwendig eine Kostenartendimensionshierarchie festzulegen, welche die unterschiedlichen Kostenarten entsprechend strukturiert. Ein Beispiel hierfür ist im folgenden Screenshot dargestellt.

Neben der Kostenartendimensionshierarchie sind darüber hinaus die Kostensteuerungseinheiten festzulegen, die definieren, was im Detail analysiert werden soll (z.B. Kostenstellen, Abteilungen, usw.).

 An dieser Stelle besteht die Möglichkeit eine Vielzahl von Kostensteuerungseinheiten parallel festzulegen.

Nachdem die Kostenelemente (Kostenarten) und Kontrolleinheiten definiert wurden, können die Daten aus dem Hauptbuch in die Kostenrechnung übertragen werden. Um dies zu realisieren ist die Datenquelle bzw. der Datenanbieter zu konfigurieren, wie dies nachfolgend dargestellt ist.

 Das neue Kostenrechnungsmodul erlaubt die Verarbeitung und Analyse von Daten aus unterschiedlichen Buchungsebenen, was in dieser Form im alten Kostenrechnungsmodul nicht möglich war.

Nachdem die Datenquelle bzw. der Datenanbieter konfiguriert ist, können die Hauptbuchdaten in die Kostenrechnung über eine entsprechende Quelldatenverarbeitung übernommen werden.

Das Ergebnis dieser Datenübertragung kann schließlich über eine Abfrage der Kostenrechnungsjournaleinträge eingesehen werden. Siehe hierzu auch den folgenden Screenshot.

Um die derart übertragenen Daten schließlich zu visualisieren ist ein sog. cost controlling workspace (deutscher Begriff: ‚Kostensteuerungs-Arbeitsbereich‘) einzurichten, welcher (1) die Kostensteuerungseinheit, (2) die Kostenelement-Dimensionshierachie und (3) die Kostenobjekt-Dimensionshierarchie miteinander verknüpft.

Sobald der cost controlling workspace derart eingerichtet wurde können die entsprechenden Daten der Kostenobjekte im cost controlling workspace betrachtet werden. Im nachfolgend dargestellten Beispiel für das Kostenobjekt ‚Kostenstelle 500 Sales‘.

 Bitte beachten sie, dass bei dieser Darstellung aktuell nicht zwischen Kosten und Erlösen unterschieden wird, sondern die unterschiedlichen Werte stattdessen einfach aufsummiert werden. Der cost controlling workspace eignet sich daher nicht für eine gleichzeitig Kosten- und Erlösbetrachtung. Darüber hinaus ist zu beachten, dass es im cost controlling workspace nur möglich ist einzelne Kostenobjekte, wie z.B. Kostenstellen zu betrachten. Ein spaltenweiser Vergleich verschiedener Kostenobjekte wie im vorherigen Beitrag dargestellt, ist im D365 web client nicht möglich. Dies liegt darin begründet, dass dieser workspace primär für die Analyse durch einzelne Kostenobjektverantwortliche konzipiert wurde und über ein Berechtigungskonzept gesteuert wird. Aufgrund dessen ist es für einen spaltenweisen Vergleich verschiedener Kostenobjekte erforderlich Power-BI-Instrumente einzusetzen.

 Details der im cost controlling workspace dargestellten Daten können über den Auswahlbutton ‘Details anzeigen‘ betrachtet werden und zwar auch dann, wenn unterschiedliche Sachkonten in einer Kostenart zusammengefasst wurden. Der folgende Screenshot zeigt dies beispielhaft für die Kostenart ‚travel costs‘ auf.

Im nächsten Beitrag betrachten wir, wie eine Aufteilung der Gesamtkosten in fixe und variable Anteile erfolgen kann.

Kostenrechnung (2)

Schlagwörter

, , ,

Innerhalb dieses zweiten Beitrags zur Kostenrechnung soll zunächst die Kostenartenrechnung näher betrachtet werden. Diese Betrachtung wird auf Basis der folgenden Daten durchgeführt, die der Einfachheit halber über ein Hauptbuchjournal unter Verwendung der aufgeführten Sachkonten und Kostenstellen eingebucht wurden.

Um die Kosten entsprechend gegliedert zu bekommen ist es erforderlich in einem ersten Schritt eine sog. Kostenelementedimension einzurichten, welche die verschiedenen Kostenarten aus dem Kontenplan in der Finanzbuchhaltung (FIBU) übernimmt.

Hierfür ist es erforderlich eine Verknüpfung zu einem bestehenden Kontenplan herzustellen. Darüber hinaus sind die Konten zu spezifizieren, die in die Kostenrechnung zu übernehmen sind. Diese Spezifikation kann entweder anhand des Hauptkontotyps oder basierend auf der Angabe von Kontonummer erfolgen, wie dies im folgenden Screenshot dargestellt ist.

Sobald der Datenkonnektor für die Kostenarten eingerichtet ist, können diese über die Auswahl ‘Dimensionsmitglieder importieren‘ in das Kostenrechnungsmodul übernommen werden. Nach erfolgreicher Durchführung des Imports können die verschiedenen Kostenarten schließlich über die Maske ‚Dimensionsmitglieder anzeigen‘ betrachtet werden.

 Im neuen Kostenrechnungsmodul können sowohl Bilanz- als auch GuV-Konten als Kostenarten definiert werden. Dies war im ‚alten‘ Kostenrechnungsmodul nur über eine Anpassung möglich.

 Für den Fall dass zu viele oder falsche Kostenarten importiert wurden erscheint es am einfachsten die Kostenelementdimension zu löschen und neu zu erstellen, da nachfolgende Importe bereits übernommene Kostenarten nicht entfernen.

Nachdem schließlich die Kostenarten aus dem FIBU-Kontenplan in die Kostenrechnung (KORE) als sog. Primäre Kostenarten übernommen wurden, können weitere sekundäre Kostenarten unmittelbar in der gleichen Maske (manuell) hinzugefügt werden.

 Sekundäre Kostenarten werden für Umlagen und Gemeinkostensatzberechnungen benötigt. Details hierzu werden in späteren Beiträgen aufgezeigt.

Eine genaue Betrachtung der Kostenarten im obenstehenden Screenshot zeigt auf, dass zwischen den Kostenarten der KORE und den Sachkonten der FIBU eine 1:1 Beziehung besteht. Für den Fall dass eine solche 1:1 Beziehung nicht erwünscht ist, kann wie folgt vorgegangen werden, um bspw. die reisebezogenen Kostenarten 6401 bis 6405 in einer Kostenart zusammenzufassen.

Schritt 1: Export der Datenentität ‘imported cost element dimension’

Schritt 2: Aufbereitung der benötigten Kostenarten im exportierten Excel-Template

Schritt 3: Import der im Excel-Template aufbereiteten Kostenarten

Schritt 4: Einrichtung einer neuen Kostenelementdimension
Hierbei ist es wichtig, das der Datenkonnektor der Kostenelementdimension auf die importierten Kostenarten verweist, wie dies im folgenden Screenshot dargestellt ist.

Schritt 5: Konfiguration des Dimensionselementanbieters

 Beim Dimensionselementanbieters handelt es sich um den über das Excel-Template importierten sog. SourceIdentifier. Siehe hierzu auch Schritt 2 weiter oben.

Schritt 6: Import dem Kostenelement-Dimensionsmitglieder
Das Ergebnis dieses Imports kann über die Auswahl ‘Dimensionsmitglieder anzeigen‘ betrachtet werden.

Schritt 7: Dimensionszuordnung durchführen
Die zuvor übernommenen Sachkonten bzw. Kostenarten sind nun den importierten Kostenarten zuzuordnen, wie dies beispielhaft im folgenden Screenshot dargestellt ist.

 Die Möglichkeit verschiedene Kostenelementdimensionen einander zuordnen zu können und hierüber firmenübergreifende Auswertungen zu realisieren bestand im alten Kostenrechnungsmodul nicht. Die nächste Grafik veranschaulicht dies nochmals für drei Firmen (US, FR & DE), die alle ihren eigenen Kontenplan (COA) haben und gemeinsam im Kostenrechnungsmodul eingebunden werden können.

Kostenrechnung (1)

Schlagwörter

, ,

Vor kurzem wurde ein neues Kostenrechnungsmodul für Dynamics 365 for Finance & Operations Enterprise Edition (nachfolgend kurz D365) bereitgestellt. Auch frühere Dynamics AX Versionen beinhalten ein Kostenrechnungsmodul, welches allerdings nichts mit dem vollständig neu entwickelten Kostenrechnungsmodul gemein hat.

Bevor wir die einzelnen Modulfunktionen näher beleuchten, lassen sie uns zunächst einen Blick auf die Kostenrechnungstheorie werfen, um die verschiedenen neuen Modulfunktionen dagegen abprüfen zu können.

Sucht man nach dem Begriff ‚Kostenrechnung‘, so erhält man i.d.R. sehr schnell eine Vielzahl ähnlicher Begriffsdefinitionen. Anstatt diese hier wiederzugeben, soll stattdessen auf die wesentlichen Elemente eines klassischen Kostenrechnungssystems eingegangen werden. In diesem Zusammenhang können die folgenden drei Grundpfeiler eines klassischen Kostenrechnungssystems aufgeführt werden.

 

Kostenartenrechnung
Die Kostenartenrechnung befasst sich mit der Fragestellung welche Kosten in welcher Höhe angefallen sind. Dementsprechend gliedert die Kostenartenrechnung die Kosten nach verschiedenen Gesichtspunkten, wie z.B. nach der Art der verbrauchten Produktionsfaktoren (Personal-, Material-, …-Kosten), nach der Herkunft der Kostengüter (Primärkosten, Sekundärkosten), nach der Zurechenbarkeit (Einzelkosten, Gemeinkosten), nach dem Verhalten bei Beschäftigungsschwankungen (fixe vs. variable Kosten), usw.

Kostenstellenrechnung
Die Kostenstellenrechnung bildet den zweiten Grundpfeiler eines klassischen Kostenrechnungssystems und befasst sich mit der Frage, wo Kosten entstanden sind. Die Beantwortung dieser Frage dient zum einen der Steuerung und Kontrolle der verschiedenen Kostenstellen. Zum anderen dient sie der Ermittlung von Kosten-, Zuschlags- und Verrechnungssätzen, die im Rahmen der Kostenträgerrechnung benötigt werden.

Kostenträgerrechnung
Die Kostenträgerrechnung bildet den dritten und letzten Grundpfeiler eines klassischen Kostenrechnungssystems und beantwortet die Frage wofür welche Kosten in welcher Höhe angefallen sind. Sie wird i.d.R. in eine Kostenträgerstück- und Kostenträgerzeit-Rechnung unterteilt und baut auf den anderen beiden Grundpfeilern auf.

 

Die folgende Übersicht stellt beispielhaft und stark vereinfacht die verschiedenen Elemente eines klassischen Kostenrechnungssystems dar und zeigt dessen Verbindung zur Finanzbuchhaltung auf.

 

 Häufig werden die Finanzbuchhaltung und die Kostenrechnung auch als externes und internes Rechnungswesen bzw. externer und interner Rechnungskreis bezeichnet.

 

Betrachtet man sich die obenstehende Übersicht, so kann man leicht erkennen, dass zahlreiche Kostenrechnungselemente bereits in anderen D365 Modulen enthalten sind. Kostenverteilungen und Umlagen können bspw. auch über Zuweisungsbedingungen im Hauptbuch realisiert werden und Stückkosten können über den sog. Nachkalkulationsbogen und Nachkalkulationsversionen ermittelt werden. Die Nutzung von Finanzdimensionen und Sachkontozuweisungsregeln erlaubt darüber hinaus die de facto Abbildung einer Deckungsbeitragsrechnung.

Vor dem Hintergrund dieser bereits verfügbaren Funktionen stellt sich die Frage nach dem Mehrwert des neuen Kostenrechnungsmoduls. Dieser wird in den folgenden Beiträgen anhand eines Vergleichs mit den bereits verfügbaren Standardfunktionen dargestellt.

Dynamics AX Project Accounting & Controlling – Teil 2

Ab sofort ist auch der 2. Teil des Buches zum Projektmodul im CreateSpace Onlineshop und bei Amazon erhältlich.

Aufgrund der Rückmeldungen die ich zur Preispolitik zum ersten Teil erhalten habe, habe ich den Preis der beiden Bücher auf einen einheitlichen niedrigeren Preis festgelegt. Ich hoffe das ist im Sinne der D365/AX Community und hilft dabei das Projektmodul erfolgreich zu implementieren.

 

 

 

 

Kreditorenrechnungserfassung (Teil 9)

Schlagwörter

, , , ,

Der in den vorherigen Beiträgen verwendete Bestellanforderungsworkflow wies die Genehmigungsaufgabe der Bestellanforderung bzw. der Rechnung grundsätzlich dem Kostenstellenleiter zu und zwar unabhängig davon, ob der Kostenstellenleiter eine ausreichend große Unterschriftsberechtigung besaß oder nicht.

Um unterschiedliche Unterschriftsberechtigungen im Bestellanforderungsworkflow zu berücksichtigen habe ich daher zunächst versucht den Zuordnungstyp des Workflow-Genehmigungsschrittes auf eine Hierarchie abzuändern. Leider erlaubte diese Änderung nicht den Workflow ausgehend von der anfordernden Person aus zu starten. Siehe hierzu auch den folgenden Screenshot.

205_p9_0015

Auf das im vorherigen Beitrag verwendete Beispiel angewandt würde die Auswahl ‘submitted by‘ nur dann dem richtigen Kostenstellenleiter zur Genehmigung zugeordnet, wenn die anfordernde Person (Susan) die Bestellanforderung selbst an den Worfklow übermittelt.

205_p9_0020

 

Modifikation A:
Um diese Problemstellung zu umgehen wurde statt des Bestellanforderungsworkflows ein Bestellanforderungs-Zeilenworkflow mit den gleichen Workflowelementen eingerichtet. Der Bestellanforderungs-Zeilenworkflow wurde deshalb verwendet, weil er die Zuordnung des Genehmigungsschrittes vom Anforderer ausgehend erlaubt. Details hierzu können den folgenden beiden Screenshots entnommen werden.

205_p9_0021 205_p9_0025

notesign In früheren Versionen war es möglich den Genehmigungsschritt im Bestellanforderungsworkflow unmittelbar dem Anforderer zuzuweisen. Diese Möglichkeit würde jüngst entfernt, weshalb der ‚Umweg‘ über den Zeilenworkflow gewählt wurde.

Um den Bestellanforderungs-Zeilenworkflow nutzen zu können muss dieser schließlich in einen gewöhnlichen Bestellanforderungsworkflow eingebaut werden. Dies ist beispielhaft im folgenden Screenshot dargestellt.

205_p9_0030

 

Beispiel:
Nachfolgend wird eine Bestellanforderung über ein Dynamics AX Training in Höhe von $10000 von Nicole Holiday im Auftrag von Susan Burk erstellt.

205_p9_0035

Aufgrund der vorgenommenen Workflowänderungen wird die Genehmigungsaufgabe nun Julia, der Marketingleiterin zugeordnet, da sie über ein ausreichend großes Unterschriftslimit verfügt. Siehe hier auch die folgenden beiden Screenshots.

205_p9_0040

205_p9_0045

 

Modifikation B:
Gleichlaufend mit den Änderungen die für den Bestellanforderungsworkflow umgesetzt wurden, wurde auch der Genehmigungsschritt des Rechnungsworkflows an eine Hierarchie gebunden.

205_p9_0060

notesign Da die im Rahmen des Rechnungsworkflows vorgenommenen Änderungen denjenigen entsprechen, die bereits in einem der vorherigen Beiträge aufgezeigt wurden, kann an dieser Stelle auf weitere Details verzichtet werden.

 

Beispiel:
Das weiter oben aufgezeigte Beispiel wird nun in der Art und Weise fortgeführt, dass eine Rechnung in Höhe von $10900 erfasst wird. Da dieser Rechnungsbetrag von der eingerichteten akzeptablen Preistoleranz in Höhe von 5% abweicht, wird eine entsprechende Genehmigungsaufgabe für Charlie, den Präsidenten der Einheit, erstellt, da er über eine ausreichend hohe Unterschriftsberechtigung verfügt.

205_p9_0070 205_p9_0075

 

Zusammenfassung Workflows für ausgabenbezogene Kreditorenrechnungen:
Dieser Beitrag beendet die Reihe zur Erfassung von ausgabenbezogenen Kreditorenrechnungen. Basierend auf dem was im Rahmen dieses und der vorherigen Beiträge aufgezeigt wurde, kann festgehalten werden, dass Dynamics AX/365 for Operations leistungsstarke und flexible Workflowfunktionen besitzt.

Die Einrichtung dieser Workflowfunktionen ist nicht immer selbsterklärend und einfach und bedarf n.M.d.Verf. einer Anpassung im Bereich der Maske der ausstehenden Kreditorenrechnungen.

Vor dem Hintergrund dieser Nachteile und der aufgezeigten Workflowfunktionen kann der Leser selbst beurteilen, ob derartige Erweiterungen selbständig oder über ein Zusatzmodul realisiert werden können.

Kreditorenrechnungserfassung (Teil 8)

Schlagwörter

, , ,

Dieser Beitrag schließt sich an den vorherigen Beitrag an, welcher mit der Genehmigung der Bestellanforderung endete.

205_p8_0003

 

Prozessschritt 4:
Nachdem die Bestellanforderung genehmigt wurde, wird diese in eine Bestellung umgewandelt. Die folgenden beiden Screenshots zeigen diese Umwandelung beispielhaft auf.

205_p8_0005

205_p8_0010

notesign Für die Erstellung von Bestellungen gibt es in Dynamics AX/365 for Operations einen eignen Workflow. Dieser wird an dieser Stelle nicht genutzt, weil der Hauptaugenmerk dieses Beitrags nicht auf der Anlage von Bestellungen liegt.

 

Prozessschritt 5:
Um sicherzustellen, dass die bestellten Dienstleistungen auch empfangen bzw. durchgeführt wurden, wurde eine sog. Category policy Regel eingerichtet, die vor der Rechnungsbuchung eine explizite Zugangsbestätigung in Form einer Lieferscheinbuchung erfordert. Einzelheiten wie diese Regel eingerichtet wurde, können der folgenden Darstellung entnommen werden.

205_p8_0015

 

Prozessschritt 6:
Der letzte Prozessschritt wird durch den folgenden Rechnungsworkflow unterstützt:

205_p8_0020

Dieser Rechnungsworkflow beginnt mit einer Prüfung daraufhin, ob Abgleichdifferenzen bestehen.

205_p8_0025

Ist dies nicht der Fall, so wird die Kreditorenrechnung automatisiert und ohne weiteres zutun gebucht.

Für den Fall dass Abgleichdifferenzen bestehen, ist ein zusätzlicher Prüf- und Genehmigungsschritt durch den zuständigen Kostenstellenleiter vorgesehen.

Bitte beachten sie, dass dieser zusätzliche Prüf- und Genehmigungsschritt den entsprechenden Kostenstellenverantwortlichen zugewiesen wird. Die hierfür notwendigen Einstellungen können den folgenden Screenshots entnommen werden.

205_p8_0030

205_p8_0035

notesignUm Situationen zu vermeiden bei denen Kostenstellenverantwortliche jede auch noch so kleine Abweichung explizit zu genehmigen haben, wurde die folgende Preistoleranzeinstellung in den Kreditorenparametern vorgenommen.

205_p8_0040

Bei der Einrichtung dieser Einstellung ist darauf zu achten, dass gleichlaufend hierzu der Parameter ‘post invoice with discrepancies‘ auf ‚allow with warning‘ eingestellt ist. Andernfalls müsste der Kostenstellenverantwortliche im Falle einer Preis- oder Mengenabweichung zum einen eine Genehmigung über den Workflow und zum anderen eine Genehmigung über die nachfolgend dargestellte Abgleichmaske vornehmen.

205_p8_0041

 

Beispiel:
Die nachfolgend erfasste Rechnung wird mit einer Preisabweichung in Höhe von 8% erfasst.

205_p8_0045

Aufgrund dieser Abweichung wird die Rechnung nicht automatisiert gebucht, sondern dem Kostenstellenverantwortlichen Kevin Cook zur Prüfung und Genehmigung zugewiesen.

205_p8_0050

Für den Fall dass dieser die Abweichung genehmigt, findet eine automatisierte Rechnungsbuchung statt.

205_p8_0055

Die Buchung der Kreditorenrechnung endet den hier dargestellten Prozess. Im nächsten Beitrag betrachten wir, wie Unterschriftenregelungen im aufgezeigten Prozessablauf berücksichtigt werden können.

Kreditorenrechnungserfassung (Teil 7)

Schlagwörter

, , ,

Ein grundlegendes Problem der in den vorherigen Beiträgen dargestellten Rechnungsworkflows bestand darin, dass die Materialien per Email ohne jedweden formalen Genehmigungs- und Freigabeprozess beschafft wurden. Für den Fall dass der zuständige Vorgesetzte eine Beschaffung von Gütern oder Dienstleistern letztendlich nicht genehmigt, ist es häufig zu spät die beschafften Güter oder Dienstleistungen zurückzusenden bzw. die Beschaffung zu stoppen.

Derartige Situationen lassen sich durch einen frühzeitigen Prüf- und Genehmigungsprozess, der über Bestellanforderungen abgebildet wird umgehen. Die Einbindung von Bestellanforderungen in den Rechnungsbuchungs- und Genehmigungsprozess bzw. die hierfür erforderlichen Prozessschritte sind im nächsten Screenshot dargestellt.

205_p7_0005

Der oben dargestellte Prozess beginnt mit der Erstellung einer Bestellanforderung durch Nicole Holiday.

Diese Bestellanforderung wird anschließend an eine Gruppe von Einkäufern zur Prüfung übermittelt um sicherzustellen, dass die Bestellanforderung alle notwendigen Informationen und keine Fehler enthält.

Dieser Prüfung schließt sich die Genehmigung und Freigabe der Bestellanforderung durch den zuständigen Kostenstellenleiter an.

Nach erfolgter Genehmigung und Freigabe können die angeforderten Güter oder Dienstleistungen über eine Bestellung beschafft werden.

Um sicherzustellen, dass auch alle Güter oder Dienstleistungen erfasst wurden, wurde ein separater Zahlungsprozessschritt in der obenstehenden Prozessdarstellung berücksichtigt.

Der Beispielprozess endet schließlich mit der Erfassung und Buchung der Kreditorenrechnung. Aufgrund der im Rahmen der Bestellanforderung durchgeführten Prüfungen und Genehmigungen kann die Kreditorenrechnung anschließend unmittelbar gebucht werden, soweit keine Preis- oder Mengenabweichungen vorliegen. Für den Fall dass es zu Preis- oder Mengenabweichungen zwischen Bestellung und Rechnung kommt ist hingegen eine gesonderte Prüfung und Freigabe durch den Kostenstellenleiter erforderlich.

 

Bitte beachten sie, dass die oben dargestellten Prozessschritte von zwei Workflows unterstützt werden, die der folgenden Darstellung entnommen werden können.

205_p7_0007

Im nächsten Unterkapitel werden die für die Implementierung der verschiedenen Prozess-/Workflowschritte erforderlichen Einrichtungen aufgezeigt, bevor im Anschluss der gesamte Prozess anhand eines Beispiels dargestellt wird.

notesign Aufgrund der großen Anzahl der hier dargestellten Prozessschritte werden im Rahmen dieses Beitrags lediglich die ersten drei Prozessschritte erläutert. Die verbleibenden Prozessschritte werden im nächsten Beitrag im Detail dargestellt.

 

Prozessschritt 1:
Der erste Prozessschritt betrifft die manuelle Anlage einer Bestellanforderung für die weiter keine besonderen Einstellungen in Bezug auf die nachfolgende Rechnungsverarbeitung vorzusehen sind.

 

Prozessschritt 2:
Wie eingangs erwähnt wird die erstellte Bestellanforderung im zweiten Schritt von einer Gruppe von Einkäufern geprüft. Dieser Prozessschritt wird über den nachfolgend dargestellten Bestellanforderungsworkflow abgebildet.

205_p7_0010

Hierfür wurde ein gesonderter Workflowschritt eingerichtet, welcher der Gruppe ‘Purchase requisition reviewer‘ zugeordnet wurde.

205_p7_0015

Im hier dargestellten Beispiel wurden die Mitarbeiter Phyllis und Susan zu Einkäufern befördert und der Purchase requisition reviewer‘ Gruppe zugeordnet.

205_p7_0020

 

Prozessschritt 3:
Im dritten Prozessschritt ist nun der Kostenstellenverantwortliche aufgerufen die Bestellanforderung zu genehmigen.

205_p7_0025

Dieser Workflowschritt wurde der ‘AppREQ’ Gruppe zugeordnet, welche auf die in der Bestellanforderung hinterlegten Kostenstellenleiter verweist.

205_p7_0030 205_p7_0035

 

Beispiel:
Basierend auf den zuvor aufgezeigten Einstellungen und dem folgenden Organigramm, erstellt Nicole Holiday zunächst eine Bestellanforderung für eine Trainingsmaßnahme. Bitte beachten sie, dass Nicole die Bestellanforderung für ihre Kollegin Susan Burk erstellt.

205_p7_0040 205_p7_0045

Da in Susan’s Mitarbeiterstammdaten eine entsprechende Kostenstelle hinterlegt ist, wird diese automatisch in die Bestellanforderung übertragen. Diese Übertragung ist für die spätere Identifikation des für die Genehmigung zuständigen Kostenstellenverantwortlichen wichtig.

205_p7_0050

Nachdem der Bestellanforderungsworkflow gestartet wurde, wird dieser zunächst allen Benutzern der hinterlegten Einkäufergruppe zugewiesen.

205_p7_0055

Für den Fall, dass Phyllis die Erfüllung dieser Aufgabe übernimmt…

205_p7_0060

…ist sie für die Prüfung und Fertigstellung dieses Prüfschritts verantwortlich.

205_p7_0065

Nach erfolgreich durchlaufener Prüfung wird die Genehmigung der Bestellanforderung schließlich Susan’s Kostenstellenleiter Kevin Cook zur Genehmigung übermittelt.

205_p7_0070

Nachdem der verantwortliche Kostenstellenleiter die Bestellanforderung schließlich genehmigt…

205_p7_0075

…ändert sich deren Status auf genehmigt (approved) und erlaubt die Erstellung einer entsprechenden Bestellung.

205_p7_0080

Mit der Genehmigung der Bestellanforderung endet dieser Beitrag. Die verbleibenden Prozess-/Workflowschritte werden im nächsten Beitrag dargestellt.

Kreditorenrechnungserfassung (Teil 6)

Schlagwörter

, , ,

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.

205_p6_0005

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

205_p6_0010

…, welche vom Projektleiter eine explizite Genehmigung erfordert.

205_p6_0015

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.

205_p6_0020

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.

205_p6_0025

205_p6_0030

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.

205_p6_0035

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.

Kreditorenrechnungserfassung (Teil 5)

Schlagwörter

, , ,

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.

205_p5_0005new

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.

205_p5_0010new

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

205_p5_0015new

… 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.

205_p5_0020new

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.

205_p5_0025new 205_p5_0030new

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.

205_p5_0035new

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

205_p5_0040new

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.

Kreditorenrechnungserfassung (Teil 4)

Schlagwörter

, , ,

Im vorherigen Beitrag wurde der zuständige Mitarbeiter für die Genehmigung der Rechnung über die Aufwendungsgruppe ‚Approver‘ identifiziert. Die hierfür erforderliche rollenbasierte Einstellung ist nochmals im folgenden Screenshot dargestellt.

205_p4_0005new

Die obenstehende Hinterlegung einer Aufwandsprüfergruppe ist immer dann hilfreich, wenn ein bestimmter Mitarbeiter, wie z.B. ein Kostenstellenleiter für die Genehmigung von Rechnungen zuständig ist.

Unternehmen, die von dezidierten unterschiedlich abgestuften Unterschriftsregeln Gebrauch machen ist mit einer solchen Zuordnung allerdings nicht weitergeholfen. Wie solche Unternehmen den Rechnungsgenehmigungsworkflow gestalten können, ist Gegenstand der folgenden Ausführungen.

Die folgende Darstellung zeigt die geänderten Workfloweinstellungen für die Berücksichtigung abgestufter Unterzeichnungslimits auf.

205_p4_0010new

Der wesentliche Unterschied zu dem im vorherigen Beitrag verwendeten Workflow besteht im zweiten Workflowschritt, der nun einer Hierarchie zugeordnet wurde.

205_p4_0015new

Problematisch an der Hierarchiezuordnung ist, dass der Workflow entweder ausgehend vom Workflow owner – einer statischen Benutzerreferenz – oder vom workflow originator aus beginnen kann.

205_p4_0020new

Ausgehend vom dem Fall dass Buchhalter, die nicht in der Positionshierarchie des Anforderers bzw. Genehmigers zugehören, Rechnungen erfassen und den Rechnungsworkflow starten, würde die Auswahl ‚workflow originator‘ immer dazu führen, dass der Vorgesetzte des erfassenden Buchhalters die Rechnung zu genehmigen hätte. Um dies zu vermeiden wurde die folgende neue Positionshierarchie (LRE Signing) eingerichtet, die ausgehend von der rechnungserfassenden Buchhalterin (Phyllis Harris) die entsprechenden Genehmigungsstufen aus der Organisationsstruktur abbildet.

205_p4_0025new

Diese Positionshierarchie ist anschließend mit dem Workflow zu verknüpfen, wie dies in der nachfolgenden Darstellung aufgezeigt ist.

205_p4_0030new

Anschließend können die Kriterien für die Auswahl des Genehmigungsberechtigten definiert werden.

205_p4_0035new

Nachdem der Workflow derart eingerichtet wurde, können im zweiten Schritt die eigentlichen Unterschriftsberechtigungen definiert werden. Die im folgenden verwendeten Limits, sind im folgenden Screenshot dargestellt.

205_p4_0040new

Nach Abschluss dieser Einrichtungstätigkeiten wird nun eine Rechnung über $47500 von der Buchhalterin Phyllis erfasst und der Workflow gestartet.

205_p4_0045new

Um den Unterschied zwischen den in den vorherigen Beiträgen verwendeten Workflows aufzuzeigen, wurden alle Rechnungen dieses Mal ohne Kostenstelle erfasst.

205_p4_0050new

Unabhängig von dieser Tatsache konnte der hierarchische Workflowschritt immer den richtigen Genehmiger identifizieren. Der folgende Screenshot zeigt die vom Workflow angesprochenen Genehmiger für die dritte Rechnung über $47500 auf.

205_p4_0055new

Der obenstehenden Darstellung kann man entnehmen, dass Nicole Holiday als Besteller die erste Workflowaufgabe zugewiesen bekam. Danach wurden sukzessive den Kostenstellen-, Abteilungs- und Divisionsleitern Genehmigungsaufgaben zugeordnet. Dies liegt darin begründet, dass im Falle der dritten Rechnung über $47500 weder die Kostenstellen-, noch die Abteilungsleiter über eine entsprechend hohe Unterschriftsberechtigung verfügen.

warningsign1 Da weder Kostenstellen-, noch Abteilungsleiter im Falle der dritten Rechnung über $47500 ein ausreichend hohes Unterschriftslimit aufweisen, können diese Genehmigungsschritte bzw. –aufgaben auch über die folgende Parametrisierung übersprungen werden.

205_p4_0060new

Wird mit diesen modifizierten Workfloweinstellungen erneut eine Rechnung in Höhe von $47500 erfasst, so werden nun weder den Kostenstellen-, noch den Abteilungsleitern entsprechende Workflowaufgaben zugeordnet, da deren Unterschriftslimit hierfür nicht ausreicht. Der folgende Screenshot stellt dies beispielhaft dar, bei dem nach Durchführung der sachlichen Rechnungsprüfung unmittelbar der Divisionsleiter (Charlie Carson) mit der Genehmigung der Rechnung betraut wird.

205_p4_0065new

Lassen sie uns nun das Beispiel dahingehend modifizieren, dass die Materialien nun von Michael Redmond beschafft werden, dessen Linienvorgesetzer (Kevin Cook) die Rechnung zu genehmigen hat.

205_p4_0070new

Aus diesem Grund wurde nun eine weitere Kreditorenrechnung – diesmal über $2000 – erfasst. Im Gegensatz zum weiter oben aufgezeigten Beispiel wurde nun allerdings Michael Redmond im Finanzdimensionsfeld für den Mitarbeiter hinterlegt, da er für die sachliche Prüfung der Rechnung zuständig ist.

205_p4_0075new

Nachdem Michael Redmond seine sachliche Prüfung abgeschlossen hat, wird nun Benjamin Martin und nicht Kevin Cook mit der Genehmigungsaufgabe betraut.

205_p4_0080new

Dies liegt darin begründet, dass Kevin Cook nicht in der dem Workflow zugeordneten Positionshierarchie enthalten ist. Nun könnte man meinen, dass man Kevin Cook einfach in diese Hierarchie aufnehmen müsste um das Problem der richtigen Zuordnung zu beheben. Dies lässt sich aktuell allerdings nicht in Dynamics AX/365 for Operations realisieren, da lediglich eine einzige und eindeutige Beziehung zwischen den verschiedenen Positionen der Hierarchie möglich ist. Mit anderen Worten, die Tatsache dass Kevin Cook und Benjamin Martin beide die gleiche Vorgesetzte Julia Funderburk haben kann nicht in der verwendeten Positionshierarchie abgebildet werden.

Wie diese Problemstellung gelöst werden kann, wird im nächsten Beitrag aufgezeigt.