Kostenumlagen & -verteilungen auf Projekte

02 Sonntag Okt 2016

Schlagwörter

Gemeinkosten, indirekte Kosten, Projektkostenumlagen

Einführung
In einem früheren Beitrag habe ich die Funktion der sog. indirekten Projektkosten dargestellt. Zu Einzelheiten, siehe hier.

Ein wesentliches Ergebnis dieses Beitrags war, dass die Einsatzmöglichkeiten der indirekten Projektkostenfunktion – aufgrund ihrer Limitierung auf Transaktionen, die im unmittelbaren Zusammenhang mit Projektstundenbuchungen stehen – derzeit eingeschränkt ist.

Innerhalb dieses Beitrags möchte ich einen erneuten, allgemeineren Blick auf indirekte Projektkosten („Gemeinkosten“) werfen, um zu analysieren, wie diese auf verschiedene Projekte verteilt werden können, um hierdurch einen Blick auf die Gesamtkosten eines Projekts zu erhalten.

Ein wichtiger Gesichtspunkt in diesem Zusammenhang ist, welche Gemeinkosten überhaupt auf Projekte verteilt werden dürfen. Die meisten Rechnungslegungstandardsetter, wie das IASB oder das FASB, bestimmen in diesem Zusammenhang, dass lediglich solche Gemeinkosten auf Projekte verteilt werden dürfen, die in unmittelbarem Zusammenhang zu Projekten stehen. Siehe hierzu z.B. IAS 11.

In den folgenden Unterkapiteln möchte ich aufzeigen, welche Standardmöglichkeiten in Dynamics AX bestehen, um sowohl direkt als auch nicht direkt auf Projekte zuordenbare Kosten auf diese zu verteilen, um hierdurch eine Analyse der gesamten Projektkosten zu ermöglichen.

Beginnen wir mit dem Beispiel wie Versicherungsgebühren – die eindeutig einer Vielzahl von Projekten zugerechnet werden können – auf diese Projekte verteilt werden können.

Beispiel 1: Umlage von Versicherungsgebühren
Im Rahmen dieses ersten Beispiels werden Versicherungsgebühren über ein gewöhnliches Kreditorenrechnungserfassungsjournal auf dem Sachkonto Nr. 606200 und der Abteilung 023 erfasst, da diese Abteilung primär für die Abwicklung aller Versicherungsverträge im Unternehmen verantwortlich ist.

Um die derart erfassten Kosten auf die verschiedenen Kundenprojekte Nr. 000009 bis 000012 (siehe den folgenden Screenshot) verteilt zu bekommen, wurde zunächst ein internes Kostenprojekt Nr. 000008 eingerichtet, auf dem die Kosten zunächst gesammelt werden.
Hinweis: Das interne Kostenprojekt wurde mit seiner eigenen Projektfinanzdimension Nr. 000008, sowie einer Verrechnungs-Abteilung Finanzdimension Nr. 099 eingerichtet.

Basierend auf diesen Einstellungen wurde im nächsten Schritt ein Projektausgabenjournal unter Nutzung der Kategorie „ALLOC INSURANCE” gebucht.

Hinweis: Die erwähnte Kategorie ist mit dem Sachkonto 606250 verknüpft, welche auf Projekte verrechnete Versicherungskosten erfasst.

Der im Rahmen dieser Buchung eingesetzte Buchungsbetrag entspricht dem Betrag, der uns von der Versicherungsgesellschaft ursprünglich in Rechnung gestellt wurde. Das hierbei verwendete Gegenkonto Nr. 679999 wurde als festes Gegenkonto im Projektausgabenjournal hinterlegt. Alternativ hätte natürlich auch von der Standardgegenkontofunktion im Projektmodul Gebrauch gemacht werden können. Die verwendeten Finanzdimensionen (Abteilung Nr. 099 und Projekt Nr. 000008) ergeben sich schließlich aus den auf Ebene des internen Kostenprojekts hinterlegten Finanzdimensionen.

Ergebnis dieser Buchung ist ein Beleg, welcher ein Versicherungsverrechnungskonto Nr. 606250 belastet und eine entsprechende Entlastungsbuchung auf dem Sachkonto 679999 durchführt.

Nachdem die Versicherungskosten auf diese Art dem internen Kostenprojekt belastet wurden, erfolgt im nächsten Schritt eine Verteilung dieser Kosten über die im Standard verfügbare Anpassungsfunktion. Zu Einzelheiten, siehe auch die folgenden beiden Screenshots.

Hinweis: Aus den vorstehenden Abbildungen kann man leicht entnehmen, dass die im Standard verfügbare Projektregulierungsfunktion als „Umlageinstrument“ verwendet wurde, um hierdurch die zunächst auf dem internen Kostenprojekt gesammelten Kosten auf die verschiedenen Projekte zu verteilen. Ein wesentlicher Nachteil dieser Standardfunktion besteht darin, dass hierbei der Verteilungsschlüssel manuell zu erfassen ist und sich diese Art der Umlage demnach nur für solche Fälle eignet in denen eine Kostenverteilung auf eine überschaubare Anzahl von Projekten erfolgt. Diesbezüglich ist anzumerken, dass über eine überschaubare Systemmodifikation die bereits im Standard verfügbare Verteilungslogik erweitert und voll automatisiert werden kann, um deren Einsatz auch auf solche Fälle hin auszuweiten in denen eine Kostenverteilung auf eine Vielzahl von Projekten zu erfolgen hat.
Alternativ hierzu bietet sich der Einsatz des Excel-add-in’s an, über welches die Umlagebuchungen unmittelbar auf die verschiedenen Projekte in Dynamics AX zugeordnet werden können.

Mit der Buchung der Kostenverteilung auf die unterschiedlichen Projekte erstellt Dynamics AX den folgenden Buchungsbeleg.

Um den gesamten Umlagevorgang besser nachverfolgen zu können, wurden in der nächsten Darstellung alle Buchungen zusammenfassend einander gegenübergestellt.

Der obenstehenden Buchungsdarstellung kann man entnehmen, dass die ursprünglich gebuchten Versicherungsaufwendungen nach wie vor auf dem ursprünglich verwendeten Sachkonto Nr. 606200 identifiziert werden können. Darüber hinaus kann man der Darstellung entnehmen, dass das Verrechnungskonto Nr. 606250, sowie die eingerichtete Verrechnungsabteilung Nr. 099 vollständig entlastet werden, so dass sich folgendes Bild in der Gewinn- und Verlustrechnung (GuV) ergibt:

Aus der obenstehenden nach Abteilungen und Projekten aufgegliederten GuV-Darstellung kann man zum einen entnehmen, dass alle Versicherungskosten auf Projekte verteilt wurden. Dies lässt sich sehr leicht an der in der farblich grün hervorgehobenen Spalte „SUM DEPT“ nachvollziehen, die in Summe betrachtet keinen Saldo mehr aufweist.
Zum anderen können in der obenstehenden Darstellung die insgesamt auf Projekte verteilten Kosten in der letzten – ebenfalls grün hervorgehobenen Spalte – identifiziert werden.

Beispiel 2: Verteilung von Lizenzkosten
An dieser Stelle haben sie sich vielleicht gefragt, warum die im vorherigen Beispiel dargestellte Buchung der Versicherungskosten nicht unmittelbar über das interne Kostenprojekt erfolgte? Innerhalb dieses zweiten Unterkapitels möchte ich diese Frage unter Verwendung eines weiteren Beispiels – der Verteilung von Lizenzkosten auf Projekte – beantworten.
Anders als im ersten Beispiel werden die Versicherungskosten nun unmittelbar auf dem internen Kostenprojekt Nr. 000008 unter der Verwendung einer eigenen Projektkategorie („License Costs“), wie im folgenden Screenshot dargestellt, erfasst.

Bitte beachten Sie dass die hier verwendete Beschaffungskategorie („License Fees“) mit der entsprechenden Projektkategorie („License costs“) verknüpft ist.

Nach Erfassung der Lizenzgebühren erfolgt nun im zweiten Schritt die Verteilung der auf dem internen Kostenprojekt gesammelten Kosten auf die verschiedenen Kundenprojekte Nr. 000010 bis 000012.

Die folgende Buchungsdarstellung fasst die im Rahmen dieses Beispiels generierten Sachkontobuchungen nochmals überblicksartig zusammen.

Ein wesentlicher Unterschied zur ersten Vorgehensweise besteht nun darin, dass sich die Buchungen, die auf der internen Verrechnungs-Abteilung Nr. 099 durchgeführt wurden gegenseitig ausgleichen. Dies hat zur Folge, Lizenzgebühren in Finanzauswertungen auf Ebene von Abteilungen nicht mehr unmittelbar im Detail nachverfolgt werden können. Die folgende Finanzaufstellung zeigt das eben Gesagte nochmals auf.

Beispiel 3: Umlage von Abschreibungsaufwendungen
Im dritten und letzten hier verwendeten Beispiel sollen nun Kosten, die nicht in unmittelbarem Zusammenhang mit Projekten stehen auf diese verteilt werden, um Projektleitern hierdurch einen Überblick über die tatsächlich angefallenen und von den verschiedenen Projekten zu tragenden Gesamtkosten zu ermöglichen.
Die hierfür erforderlich Vorgehensweise entspricht im Wesentlichen derjenigen, die bereits im Rahmen des ersten Beispiels dargestellt wurde. Der wesentliche Unterschied besteht hier nun allerdings darin, dass für die Verteilungsbuchungen statistische Konten verwendet werden, die nicht unmittelbar in Finanzauswertungen einfließen, welche externen Adressaten bereitgestellt werden.
Betrachten wir zunächst den ersten Prozessschritt, die Buchung der Abschreibungen im Anlagenmodul. Diese Buchung wird über das Aufwandskonto 607200 zusammen mit der Abteilung Nr. 024 durchgeführt, welche für das Management der entsprechenden Sachanlagen verantwortlich ist.

Im zweiten Schritt wird nun der Abschreibungsbetrag über ein Projektausgabenjournal auf das interne Kostenprojekt verteilt. Die hierbei verwendeten Projektkategorien und Journaleinstellungen sorgen dafür, dass die folgende Sachkontobuchung auf den statistischen Konten 907250 und 907251 durchgeführt werden.

Der dritte Schritt besteht nun wieder darin die derart auf dem internen Kostenprojekt gesammelten Kosten auf die externen Kundenprojekte – wie weiter oben bereits aufgezeigt– zu verteilen, …

…, so dass sich insgesamt die folgenden Sachkontobuchungen ergeben.

Die folgende Finanzaufstellung fasst die hierbei durchgeführten Buchungen nochmals überblicksmäßig zur besseren Nachvollziehbarkeit zusammen.

Der wesentliche Unterschied im Vergleich zum ersten Beispiel besteht nun darin, dass die in der obenstehenden Darstellung blau hervorgehobenen Zeilen nicht in solche Auswertungen einfließen, die externen Adressaten, wie Wirtschaftsprüfern, Finanzbehörden, Investoren, usw. bereitgestellt werden.

Zusammenfassung
Innerhalb dieses Beitrags habe ich Ihnen aufgezeigt, wie die Standard Projektregulierungsfunktion für die Verteilung (Umlage) von Kosten auf Projekten verwendet werden kann.
Ein wesentlicher Vorteil der hier aufgezeigten Vorgehensweise im Vergleich zu der indirekten Projektkostenfunktion besteht darin, dass sich diese Vorgehensweise für alle Arten von Kosten und nicht ausschließlich stundenbezogene Projektkosten einsetzen lässt.
Abschließen möchte ich mit der Anmerkung, dass die hier dargestellte Umlagefunktion sicherlich keine Optimal-Lösung i.S.e. vollautomatisierten Umlagetools darstellt. Nichtsdestotrotz stellen die Standard Projektmodulfunktionen eine gute Ausgangsbasis für die Implementierung einer vollautomatisierten Umlagefunktion dar, die speziell in solchen Unternehmen benötigt wird, in denen Kosten auf eine Vielzahl von Projekten zu verteilen sind.

Management Reporter – Unit Security

18 Sonntag Sept 2016

Posted by Ludwig Reinhard in Management Reporter

≈ Hinterlasse einen Kommentar

Schlagwörter

Berichtsbaumstruktur, Datenzugriff, Einschränkung, Unit Security

Innerhalb dieses Beitrags möchte ich eine Management Reporter Funktion näher beleuchten, die es erlaubt den Zugriff auf Management Reporter Berichtsdaten für bestimmte Benutzer einzuschränken.

Ein typischer Anwendungsfall für diese Funktion liegt immer dann vor, wenn bestimmte Sparten-/Kostenstellen-/Abteilungs-Verantwortliche nur die Daten für die Bereiche betrachten können sollen, für die sie auch verantwortlich sind.

Gehen wir einmal beispielhaft von folgender Gewinn- und Verlustrechnung aus und nehmen an, dass die Leiterin der Sparte (BU 001) ausschließlich die Daten ihrer Sparte, nicht aber die der anderen Sparten betrachten können soll.

Eine derartige Berichtseinschränkung kann über die Nutzung eines Berichtsbaumes vorgenommen werden, welcher den in der Spalte „Unit Security“ hinterlegen Personen explizit Zugriff auf die Berichtsdaten des entsprechenden Berichtsbaumelements erteilt. Da im Beispielbericht die Sparten nebeneinander dargestellt sind ist darüber hinaus an dieser Stelle eine Verknüpfung der Berichtsbaumelemente mit den Berichtsspalten erforderlich, wie dies im folgenden Screenshot dargestellt ist.

Basierend auf diesen Einstellungen kann die Spartenleiterin beim Öffnen des Berichts nur die Daten ihrer Sparte „BU 001“ betrachten.

Hinweise:
Die eingeschränkte Sicht auf die Daten, welche über die Unit Security Einstellungen realisiert wurden, greifen auch dann, wenn die im Management Reporter dargestellten Daten über einen drill down in Dynamics AX geöffnet werden. Beispiel:

Zu beachten ist, dass das Management Reporter Unit Security Feature nicht sicherstellen kann, dass Benutzer über den Dynamics AX Client unmittelbaren Zugriff auf Daten nehmen, die sie eigentlich nicht betrachten können sollten. Im Beispiel kann die Spartenleiterin der Sparte BU001 beispielsweise über eine einfache Belegabfrage in Dynamics AX auch die Daten der anderen Sparten betrachten.

Eine solche Art der Umgehung der Management Reporter Unit Security kann nur über eine parallele Implementierung des sog. Extensible Data Security Frameworks in Dynamics AX sichergestellt werden. Andernfalls laufen die Berichtseinschränkungen im Management Reporter ins Leere. Weitere Details zum Extensible Data Security Framework kann man bspw. den folgenden beiden Webseiten 1 / 2 entnehmen.

Berichtsmodifikation 1
Lassen sie uns nun einige weitere Berichtsmodifikationen und Fallstricke betrachten, auf die man bei der Nutzung von Berichtsbäumen und der Unit Security Funktion achten sollte.
Erweitern wir hierfür den Bericht nun dergestalt, dass neben den Sparten auch die zu den Sparten zugehörigen Kostenstellenbereiche in den Bericht mit aufgenommen werden. Richtet man die Unit Security für diese Unterelemente der Sparten in gleicher Weise ein wie zuvor (siehe den folgenden Screenshot)…

… so kann die Spartenleiterin die folgenden Daten mit der Öffnung des Berichts betrachten.

Die zugehörigen Kostenstellendaten sind in diesem Fall nicht zugriffsbeschränkt, müssen allerdings explizit über eine Auswahl des entsprechenden Berichtsbaumelements ausgewählt werden. Beispiel:

Berichtsmodifikation 2
Aufgrund der etwas unglücklichen Darstellungs- und Betrachtungsweise der Kostenstellenbereiche im vorherigen Berichtsdesign wird die BU001-Sparten Spalte – sowie die zugehörige Gesamtspalte – nun als Berechnungsspalten definiert. Siehe hierzu die gelb hervorgehobenen Bereiche im Spaltendefinitionsfenster.

Startet die BU001 Spartenleiterin nun den auf diese Art modifizierten Bericht, so öffnet sich dieser mit der folgenden Hinweismeldung:

Erst über eine explizite Auswahl der Unterelemente – im Beispiel einem bestimmten Kostenstellenbereich – können die Berichtsdaten betrachtet werden. An dieser Stelle ist allerdings zu beachten, dass aufgrund des gewählten Berichtsdesigns eine gleichzeitige Betrachtung aller Kostenstellenbereiche nicht möglich ist.

Berichtsmodifikation 3
Um die obenstehende Informations-/Fehler-Meldung beim Berichtsaufruf zu vermeiden, wurde das Berichtsdesign erneut wie folgt überarbeitet:

Der grundlegende Unterschied im Vergleich zu den vorherigen Einstellungen besteht nun darin, dass die Sparten-Unterelemente, d.h. die Kostenstellenbereiche, im Berichtsbaum eingerückt wurden. Mit diesem Berichtsdesign öffnet sich der Bericht nun wie folgt:

Über eine entsprechende Auswahl bestimmter Kostenstellenbereiche findet dementsprechend eine Einschränkung auf die entsprechenden Bereiche statt.

Zusammenfassung
Ich hoffe, dass ihnen die in diesem Beitrag aufgezeigten Beispiele einige Hinweise darauf geben konnten auf was bei der Einrichtung von Management Reporter Berichten im Zusammenhang mit Berichtsbäumen und dem Unit Security Feature zu achten ist.

Der wahrscheinlich wichtigste Gesichtspunkt den es in diesem Zusammenhang zu beachten gilt ist die Klärung der Frage, ob Berichtsnutzer die im Management Reporter eingerichteten Unit Security Funktion über entsprechende Abfragen in Dynamics AX umgehen können. Sollte dies einzelnen Benutzern möglich sein, so ist die parallele Einrichtung des Extensible Data Security Frameworks in Dynamics AX unumgänglich, um einen unberechtigten Zugriff auf Daten vermeiden zu können.

Zusammenfassung von Zahlungsbuchungen

04 Sonntag Sept 2016

Posted by Ludwig Reinhard in Kreditoren

≈ 2 Kommentare

Schlagwörter

Buchungsbeleg, Buchungszusammenfassung, Kreditorenzahlungen

Vor kurzem wurde ich mit einer Anforderung konfrontiert, bei der alle Kreditorenzahlungsbuchungen, welche von einem Bankkonto aus vorgenommen wurden, zusammengefasst und nicht einzeln gebucht werden sollten. Im konkreten Fall erstellte Dynamics AX allerdings eine Vielzahl von Buchungen auf dem Bankkonto, da die unterschiedlichen Journalzeilen verschiedene Finanzdimensionskombinationen aufwiesen. Dieser Umstand erschwerte den Bankabstimmungsprozess, weil einer einzigen summierten Bankabbuchung auf dem Kontoauszug eine Vielzahl von Belegbuchungen in Dynamics AX gegenüberstanden.

Beispiel
Das nachfolgend dargestellte Beispiel soll die eben beschriebene Problemstellung verdeutlichen.

Beispiel – Erstellung Zahlungsvorschlag

Beispiel – Generierter Buchungsbeleg für die erste Journalzeile

Beispiel – Gebuchte Banktransaktionen

A) Änderung Journaleinstellungen
Um nicht eine Vielzahl von Zahlungsbuchungen auf dem Bankkonto, welches für die Buchung des Zahlungslaufes verwendet wird, zu erhalten wurden an den Buchungsjournaleinstellungen die beiden folgenden Parameteränderungen in Bezug auf die Verwendung von Belegnummern und den Detailgrad der Buchungen vorgenommen:

Hinweis: Ursprünglich wies der Parameter ‚neuer Beleg‘ die Einstellung ‚im Zusammenhang mit Ausgleich‘ und der Parameter ‚Detailebene‘ die Einstellung ‚Detaildaten‘ auf.
Nach Umstellung dieser Journaleinstellungen wurde ein weiterer Zahlungslauf erstellt und gebucht. Das Ergebnis dieser Buchung ist im folgenden Screenshot dargestellt und zeigt auf, dass zwar eine einzige Belegnummer für alle Zahlungsbuchungen verwendet wurde, gleichzeitig allerdings keine Zusammenfassung der unterschiedlichen Bankbuchungen erfolgte.

B) Änderung Bankkontoeinstellungen
Die Ursache weshalb im vorstehenden Beispiel keine Buchungszusammenfassung erfolgte lag darin begründet, dass die Kreditorenrechnungen mit unterschiedlichen Finanzdimensionskombinationen gebucht wurden und diese Finanzdimensionskombinationen auf die Bankbuchungen vererbt wurden. Im obenstehenden Screenshot kann man dies an den Buchungen auf dem Bankkonto erkennen, welche mit den Kostenstellen Nr. 022, 023 und 024 durchgeführt wurden.
Um dieses Problem zukünftig zu vermeiden, wurden auf Ebene des verwendeten Bankkontos die folgenden Standardfinanzdimensionseinstellungen hinterlegt:

Vor dem Hintergrund der vorgenommenen Standardfinanzdimensionseinstellungen auf Ebene des Bankkontos wurde nun erwartet, dass Dynamics AX eine entsprechende Buchungszusammenfassung der Bankbuchungen vornimmt.

Dies war allerdings nicht der Fall, wie die nachfolgende Darstellung aufzeigt, was darin begründet lag, dass die Finanzdimensionseinstellungen, welche mit der Rechnungsbuchung vorgenommen wurden, die hinterlegten Standardfinanzdimensionseinstellungen auf Ebene des Bankkontos überschrieb.

C) Änderung Sachkontoeinstellungen
Um die Problematik mit der Finanzdimensionsvererbung gelöst zu bekommen wurden schließlich auf Ebene des Sachkontos, welches mit dem Bankkonto verknüpft ist, feste Finanzdimensionsgrößen hinterlegt.

Der anschließend durchgeführte Zahlungslauf generierte schließlich die folgende ersehnte zusammengefasste Bankbuchung.

D) Modifikation 1 – Unterschiedliche Zahlungstage
Um die Zuverlässigkeit und Stabilität der gewählten Parametrisierung zu testen wurde ein weiterer Zahlungslauf initiiert, diesmal allerdings in der Form, dass die zu zahlenden Rechnungen mit unterschiedlichen Zahlungs-/Buchungsdatumswerten versehen wurden.
Im Ergebnis generierte Dynamics AX nun mehrere Belegbuchungen – jeweils eine pro angegebenem Buchungsdatum – verwendete hierbei allerdings lediglich eine einzige Belegnummer. Das Ergebnis dieser Testbuchung ist im nächsten Screenshot ersichtlich.

Hinweis: Problematisch an den hier dargestellten Buchungen ist, dass Dynamics AX die gleiche Belegnummer für Buchungen mit unterschiedlichem Buchungsdatum verwendet. Diese Art der Belegbuchung ist nach den gängigen Rechnungslegungsvorschriften regelmäßig nicht erlaubt und kann zu Problemen mit den Wirtschafts- und Steuerprüfern führen.

E) Modifikation 2 – Unterschiedliche Zahlungsmethoden
In einem weiteren Test wurde abschließend untersucht, welche Auswirkungen die Verwendung unterschiedlicher Zahlungsmethoden auf die generierten Belegbuchungen hat. Das Ergebnis dieses Tests ist in der nachfolgenden Grafik dargestellt und zeigt auf, dass die Buchungszusammenfassung auch in diesem Fall einwandfrei funktioniert.

Zusammenfassung
Innerhalb dieses Beitrags wurde die Zusammenfassung von Zahlungsbuchungen aufgezeigt. Ohne dies explizit anhand von Beispielen auszuführen gilt das oben Gesagte natürlich auf in solchen Fällen, in denen ein Zahlungstransferkonto zum Einsatz kommt, vorausgesetzt eine entsprechende Finanzdimensionsverknüpfung wurde auf Ebene des Sachkontos vorgenommen.

Neben der festen Finanzdimensionsverknüpfung als zwingende Voraussetzung für die Anwendung der hier dargestellten Buchungsdarstellung gilt es insbesondere den dargestellten Zusammenhang zum verwendeten Buchungsdatum zu beachten, da es andernfalls zu Unstimmigkeiten mit den Prüfern des Unternehmens kommen kann.