Schlagwörter
Übrigens … hier noch eine kleine Anmerkung wie man die im vorherigen Beitrag aufgezeigten Prozess weiter verbessern kann.
11 Freitag Okt 2019
Schlagwörter
Übrigens … hier noch eine kleine Anmerkung wie man die im vorherigen Beitrag aufgezeigten Prozess weiter verbessern kann.
09 Mittwoch Okt 2019
Schlagwörter
11 Mittwoch Apr 2018
Posted Anlagen, Kostenrechnung, Projekt
in06 Freitag Jan 2017
Posted Projekt
inSchlagwörter
Projektbezogene Ausgabenrechnungen können auf verschiedene Arten in Dynamics AX erfasst werden, wie z.B. über Kreditorenrechnungsjournale, Projektausgabenjournale oder das sog. Rechnungsworkbench, um nur einige Möglichkeiten zu erwähnen.
Ein wichtiger Gesichtspunkt in diesem Zusammenhang ist der Zeitpunkt zu dem Ausgaben auf Ebene von Projekten identifiziert werden können. Dieser Zeitgesichtspunkt ist vor allem in solchen Unternehmen wichtig, die aufgrund detaillierter Rechnungsprüfungs- und Genehmigungsprozeduren vergleichsweise lange Rechnungsdurchlaufzeiten haben.
Um Unterschiede in der Art der Erfassung von projektbezogenen Kreditorenrechnungen besser nachvollziehen zu können, soll nachfolgend exemplarisch eine Rechnung über $150 zunächst über ein Kreditorenrechnungsjournal erfasst werden, um diesen Erfassungsprozess anschließend mit einer Erfassung über das Rechnungsworkbench vergleichen zu können.
Beginnen wir zunächst mit der Rechnungserfassung über ein gewöhnliches Kreditorenrechnungsjournal, welches im folgenden Screenshot beispielhaft dargestellt ist. Bitte beachten sie bei dieser Darstellung, dass die Rechnung, das Kreditorenkonto und das Projekt, auf welches die Kosten gebucht werden sollen, im linken oberen Bereich des Screenshots dargestellt sind. Der rechte untere Bereich zeigt darüber hinaus weitergehende projektspezifische Angaben, wie die Projektkategorie, den Verkaufspreis, usw. an, die im Projektreiter des Journals erfasst werden.
Nachdem die Rechnung erfasst und gespeichert wurde, können erwartungsgemäß noch keine Kosten auf Ebene des Projekts identifiziert werden. Die nachfolgend dargestellte Projektkostenkontrollmaske weist dementsprechend noch keine Werte aus.
Dies ändert sich allerdings zum Zeitpunkt der Rechnungsbuchung, ab dem die entsprechenden Projektkosten identifiziert und analysiert werden können. Beispiel:
Betrachten wir nun im Vergleich hierzu welchen Unterschied die Erfassung einer vergleichbaren Rechnung über das sog. Rechnungsworkbench, d.h. die Maske der ausstehenden Kreditorenrechnungen, macht. Hierfür wird zunächst eine neue Rechnung wie nachfolgend dargestellt angelegt…
… um anschließend zunächst alle Rechnungsinformationen zu erfassen. Beispiel:
Im Gegensatz zur Rechnungserfassung über das Kreditorenrechnungsjournal können nun allerdings bereits mit der Speicherung der Rechnungsinformationen die voraussichtlich auf dem Projekt auflaufenden Kosten über die Projektkostenkontrollmaske identifiziert werden. Die voraussichtlich auftretenden Kosten werden hierbei als sog. zugesagte Kosten (committed costs) entsprechend ausgewiesen, wie dies im folgenden Screenshot beispielhaft dargestellt ist.
Die Möglichkeit derart erfasste Projektausgaben schon frühzeitig auf Projekten identifizieren und analysieren zu können ist eines der wesentlichen Unterscheidungsmerkmale der Rechnungserfassung über das sog. Rechnungsworkbench im Vergleich zu einer Erfassung über Rechnungsjournale.
Speziell in Unternehmen mit langen Durchlauf- und Prüfprozessen kann sich die hier aufgezeigte frühzeitige Identifikation von Projektkosten als sinnvoll erweisen, um vor ‚bösen‘ Überraschungen gefeit zu sein.
Hinweis: Voraussetzung für die aufgezeigte frühzeitige Identifikation von Projektkosten ist zum einen die Aktivierung der im folgenden Screenshot dargestellten Projektparameter.
Darüber hinaus ist die Einrichtung eines periodischen Verarbeitungslaufes zur Ermittlung der zugesagten Projektkosten erforderlich. Beispiel:
06 Dienstag Dez 2016
Posted Projekt
inSchlagwörter
Vor der Erstellung von Projektrechnungen und/oder vor Durchführung des Monatsabschlusses ist es gängige Praxis eine Prüfung auf fehlende bzw. unvollständige Arbeitszeiten hin durchzuführen. Dynamics AX unterstützt diesen Prüfungsprozess über den sog. ‚fehlenden Arbeitszeitnachweisbericht‘, der im folgenden Screenshot beispielhaft dargestellt ist.
Hinweis: Beim Manager, welcher in der letzten Spalte des obenstehenden Screenshots identifiziert werden kann, handelt es sich um den Mitarbeiter, der im Personalverwaltungsmodul im Feld ‚Bericht an Position‘ hinterlegt ist.
Anstelle oder parallel zum fehlenden Arbeitszeitnachweisbericht kann eine periodische Email-Übermittlungsfunktion zu fehlenden Arbeitszeitnachweisen genutzt werden, welche allen Mitarbeitern, die keine Arbeitszeitnachweise gebucht haben, eine Email sendet. Der genaue Inhalt dieser Email wird hierbei in einem Email-Template festgelegt, welches in den Projektparametern zu hinterlegen ist. Beispiel:
Ein grundlegendes Problem des fehlenden Arbeitszeitnachweisberichts bzw. der erwähnten Emailfunktion besteht darin, dass keine Prüfung daraufhin stattfindet, ob alle Zeiten auch tatsächlich erfasst wurden. Stattdessen wird lediglich eine Prüfung daraufhin durchgeführt ob überhaupt Zeiten erfasst und gebucht wurden.
Das folgende Beispiel, bei dem eine Mitarbeiterin (‚Julia‘) zunächst eine Stunde an Arbeitszeit über einen Arbeitszeitnachweis erfasst, diesen anschließend zur Genehmigung übermittelt um ihn im dritten Schritt schließlich zu buchen verdeutlicht die angesprochene Problemstellung.
Schritt 1: Erstellung und Speicherung des Arbeitszeitnachweises
Schritt 2: Übermittlung des Arbeitszeitnachweises
Schritt 3: Buchung des Arbeitszeitnachweises
Den obenstehenden Arbeitszeitnachweisberichten kann man entnehmen, dass die Mitarbeiterin ‚Julia‘ nicht mehr im fehlenden Arbeitszeitnachweisbericht ausgewiesen wird, sobald der erste Arbeitszeitnachweis für diese Mitarbeiterin gebucht wurde und zwar unabhängig davon, ob lediglich ein Teil der vertraglich vereinbarten Arbeitszeit von 40 Stunden/Woche erfasst und gebucht wurde.
Vor dem Hintergrund dieses Ergebnisses kann man festhalten, dass der Arbeitszeitnachweisbericht und die periodische Email-Notifikationsfunktion für sich alleine genommen nicht in der Lage sind sicherzustellen, dass alle Mitarbeiter ihre Arbeitszeiten vollständig erfasst haben.
Wenn nun die beiden Berichts- bzw. Email-Standardfunktionen nicht ausreichen eine Vollständigkeitsprüfung der erfassten Arbeitszeiten von Mitarbeitern sicherzustellen, so stellt sich die Frage, welche Alternativen für eine solche Prüfung bestehen?
Ein wichtiges Zusatzinstrument stellen in diesem Zusammenhang die sog. Arbeitszeitnachweisrichtlinien dar. Unter der Voraussetzung, dass zum einen die vertraglich vereinbarte Arbeitszeit der Mitarbeiter in einem Kalender festgehalten ist und zum anderen eine Arbeitszeitnachweisrichtlinie die Übermittlung von Arbeitszeitnachweisen verhindert, die weniger als die vertraglich vereinbarte Arbeitszeit enthalten, können die oben aufgeführten Arbeitszeitnachweis- und Email-Funktionen für eine Vollständigkeitsprüfung der erfassten Arbeitszeiten verwendet werden.
Der folgende Screenshot stellt ein Beispiel für eine solche Arbeitszeitrichtlinie dar, welche Mitarbeiter daran hindert Arbeitszeitnachweise mit weniger als 40 Stunden Arbeitszeit pro Woche an Vorgesetzte zu übermitteln.
Für den Fall dass Mitarbeiter versuchen Arbeitszeitnachweise mit weniger als 40 Stunden zu übermitteln, wird eine Fehlermeldung der folgenden Art generiert:
Aufgrund der fehlenden Übermittlung und Buchung solcher Arbeitszeitnachweise können nun auch die Standard-Arbeitszeitnachweisberichte Verwendung finden, da sie gespeicherte aber noch nicht übermittelte Arbeitszeitnachweise identifizieren können. Beispiel:
Zusammenfassend lässt sich somit an dieser Stelle festhalten, dass erst die Kombination aus Arbeitszeitrichtlinien und fehlendem Arbeitszeitnachweisbericht (bzw. der zugehörigen Emailfunktion) eine Vollständigkeitsprüfung auf den von Mitarbeitern erfassten Arbeitszeiten erlauben.
Hinweis: Das im Rahmen dieses Beitrags dargestellte Beispiel basierte auf der Annahme, dass Mitarbeiter ihre Arbeitszeiten einmal pro Woche vollständig – d.h. inkl. Ausfallzeiten – erfassen. Über eine leicht modifizierte Parametrisierung der Arbeitszeitrichtlinien kann das Gleiche auch in solchen Fällen realisiert werden in denen Mitarbeiter ihre Arbeitszeiten täglich zu erfassen haben.
19 Samstag Nov 2016
Posted Projekt
inSchlagwörter
Gemeinkosten, indirekte Kosten, Intercompany, Projektkostenumlagen
Beispiel 3: Auf Ebene von Tochtergesellschaften realisierte Erlöse werden teilweise an die Unternehmenszentrale weiterverteilt
Teil A: Ausgangssituation
Das den nachfolgenden Ausführungen zugrundeliegende Szenario bezieht sich auf die Entwicklung und regelmäßige Wartung eines Softwareprodukts durch ein Entwicklungsteam aus der Unternehmenszentrale (USSI).
Hierbei wird davon ausgegangen, dass die ursprüngliche Softwareentwicklung bereits vor einiger Zeit abgeschlossen wurde und alle mit der Entwicklung zusammenhängenden Kosten auf einem eigenen Entwicklungsprojekt U1 erfasst wurden. Nach Abschluss der Produktentwicklung wurde dieses Projekt für weitere Buchungen geschlossen und stattdessen ein eigenes, neues „Maintenance & Support“-Projekt U2 angelegt, auf dem alle im Nachgang anfallenden Kosten erfasst werden.
Um nun das interne Entwicklungsteam/-projekt nicht lediglich als Cost-Center, sondern als eigenes Profit-Center zu führen, wurde von der Unternehmensleitung beschlossen, dass die Tochtergesellschaften, welche das Softwareprodukt verkaufen einen Obolus in Form einer Lizenzgebühr an die Unternehmenszentrale abzuführen haben. Alle zugehörigen Verträge wurden abgeschlossen, um basierend hierauf die für die Abbildung dieses Szenarios erforderlichen Einrichtungen in Dynamics AX realisieren zu können.
Bevor wir uns die einzelnen Einrichtungs- und Prozessschritte im Detail betrachten, lassen sie uns zunächst den Prozess-/Geldfluss, sowie die an diesem Prozess beteiligten Gesellschaften im folgenden Schaubild betrachten.
Teil B: Systemeinrichtung
Setup B.1: Intercompany Dummy Lieferantenkonten FRSI & GBSI
Ähnlich zu den Einstellungen, die im vorherigen Beitrag aufgezeigt wurden, ist auch an dieser Stelle zunächst die Einrichtung von Dummy Lieferantenkonten vorzunehmen. Diese Einrichtung unterscheidet sich nicht von der im vorherigen Beitrag aufgezeigten, bis auf den Umstand, dass nun zwei statt einem Dummy Lieferantenkonto in den Tochtergesellschaften FRSI und GBSI einzurichten sind.
Setup B.2: Intercompany Kunden- und Lieferantenkonten
Der zweite Einrichtungsschritt bezieht sich auf die Einrichtung der Intercompany Kunden- und Lieferantenkonten. Auch hier kann auf das im vorherigen Beitrag Gesagte verwiesen werden. Der einzige Unterschied hierzu besteht darin, dass nun in den Tochtergesellschaften FRSI und GBSI Intercompany Kundenkonten und in der Konzerngesellschaft USSI Intercompany Lieferantenkonten einzurichten sind.
Setup B.3: Projektkategorien
Ebenfalls wie zuvor gestaltet sich die Einrichtung von Projektkategorien. Zu beachten ist im Rahmen dieser Einrichtung allerdings, dass an dieser Stelle zwei separate Projektkategorien benötigt werden, da es über die Projektbuchungseinstellungen nicht möglich ist eine entsprechende firmenspezifische Unterscheidung vorzunehmen. Siehe hierzu auch weiter unten im Detail.
Hinweis. Die hier verwendete Kategorie wurde der Buchungsart “Ausgaben” zugeordnet.
Setup B.4: Beschaffungskategorien
Nach Einrichtung der Projektkategorien ist auch an dieser Stelle die Einrichtung von Beschaffungskategorien erforderlich, die sich in gleicher Art und Weise gestaltet, wie dies im vorherigen Beitrag aufgezeigt wurde. Beispiel:
Setup B.5: Projekteinrichtung
Der vorletzte elementare Einrichtungsschritt bezieht sich auf die Einrichtung entsprechender Projekte in der Unternehmenszentrale und den Tochtergesellschaften. Die beiden folgenden Screenshots zeigen die hier verwendeten Projekteinstellungen auf, die sich aus dem eingangs aufgezeigten Schaubild ergibt.
Hinweis: Wie bereits in den vorherigen Beiträgen auch, gibt es im Rahmen der Einrichtung der Projekte weiter keine Besonderheiten zu berücksichtigen bis auf die Empfehlung, die Projekte zumindest mit einer Intercompany-Finanzdimension einzurichten, um später die Konsolidierung der Finanzdaten zu erleichtern.
Setup B.6: Sachkontobuchungseinstellungen
Auch in Bezug auf die Sachkontobuchungseinstellungen im Projekt- und Lagermodul kann auf die Ausführungen in den vorherigen Beiträgen verwiesen werden. Der einzig zu beachtende Unterschied besteht an dieser Stelle darin, dass in den Tochtergesellschaften intercompany Erlöskonten und in der Unternehmenszentrale Kostenkonten zu hinterlegen sind.
Teil C: Prozessschritte
Schritt C.1: Projektstundenbuchung & Fakturierung an Kunden FRSI & GBSI
Basierend auf den aufgezeigten Einstellungen werden nun im ersten Schritt aus Vereinfachungs- und Darstellungsgründen lediglich Projektstundenbuchungen gebucht, welche unmittelbar im Anschluss an die Buchung den Kunden in Rechnung gestellt werden. Der nächste Screenshot zeigt die hierbei in der Firma GBSI generierten Sachkontobuchungsbelege auf.
Da die Sachkontobuchungen in der zweiten Tochtergesellschaft FRSI prinzipiell denen der ersten hier dargestellten Tochtergesellschaft GBSI entsprechen, wurden diese aus Platzgründen an dieser Stelle nicht aufgenommen. Diese sind allerdings in der folgenden Buchungsübersicht enthalten.
(IC = Intercompany Finanzdimension, PRO = Projekt-Finanzdimension)
Die obenstehende Buchungsübersicht stellt eine typische Projektstunden-Kosten und –Erlösbuchung dar, welche zum einen ein Projektkostenkonto mit den Stundenkosten belastet und zum anderen die erzielten Umsätze auf einem Projekterlöskonto (gelb hervorgehoben) gutschreibt.
Schritt C.2: Buchung interner Kreditoren-Verrechnungsbelege in FRSI & GBSI
Der zweite Prozessschritt unterscheidet sich von den im vorherigen Beitrag aufgezeigten internen Verrechnungsbuchung dahingehend, dass nun zwei statt einer Buchungszeile erfasst werden. Die erste Buchungszeile dient hierbei der Zwecksetzung entsprechende Lizenzaufwendungen auf den Kundenprojekten in den Tochtergesellschaften zu erfassen.
Die zweite Buchungszeile wird hingegen für die nachfolgend zu erstellende Gutschrift an die Unternehmenszentrale als Abrechnungsgrundlage benötigt. Aufgrund dessen wird zum einen die Buchungszeile mit einem negativen Vorzeichen erfasst und zum anderen auf das Maintenance und Supportprojekt in der Unternehmenszentrale verwiesen. Siehe hierzu auch den folgenden Screenshot.
Hinweis: Die hier dargestellte Erfassung der internen Verrechnungsbuchungen lässt sich in Unternehmen mit einer überschaubaren Anzahl von Projekten durchaus manuell realisieren. In Unternehmen mit einer Vielzahl von Projekten ist dies regelmäßig allerdings nicht mehr möglich. In solchen Fällen empfiehlt es sich dementsprechend die Erfassung über das Standard Dynamics AX Excel-Addin umzusetzen.
Die aus dem internen Verrechnungsbeleg resultierenden Sachkontobuchungsbelege bzw. Sachkontobuchungen sind in den folgenden beiden Screenshots dargestellt.
Zunächst ist in Bezug auf die generierten Sachkontobuchungen anzumerken, dass aufgrund der beiden mit gegenläufigen Vorzeichen eingegebenen Buchungszeilen kein offener Posten auf dem Dummy Kreditorenkonto entsteht.
Darüber hinaus kann man erkennen, dass es aufgrund der gebuchten intercompany Lizenzkosten auf den Sachkonten Nr. 707451 (FRSI) und Nr. 402451 (GBSI) zu einer entsprechenden Gewinnreduzierung auf Kundenprojekten in den Tochtergesellschaften kommt. Diese Gewinnreduzierung ist im folgenden Screenshot für die Firma GBSI beispielhaft dargestellt.
Schritt C.3: Erstellung und Buchung Intercompany Gutschriften FRSI & GBSI
Im Anschluss an die Buchung des internen Verrechnungsbelegs schließt sich die Erstellung und Buchung der Intercompany-Projektrechnungen bzw. in diesem Fall -Gutschriften an. Da es in diesem Zusammenhang keine Unterschiede zu den im vorherigen Beitrag dargestellten Abläufe gibt, kann an dieser Stelle auf diese verwiesen werden. Siehe hierzu beispielhaft auch die beiden folgenden Screenshots.
Die sich aus den intercompany Gutschriften ergebenden Buchungen/Buchungsbelege wurden – wie zuvor – nachfolgend zusammengefasst dargestellt.
Hinweis: Bitte beachten sie dass sich die grau hervorgehobenen Buchungen GuV-technisch betrachtet gegenseitig aufheben und somit keinen Einfluss auf den Gewinn der entsprechenden Tochtergesellschaft ausüben.
Schritt C.4: Buchung ausstehenden Gutschriftsbelege in USSI
Der letzte im Rahmen des hier vorgestellten Prozesses erforderliche Schritt besteht in der Buchung der automatisch in der Unternehmenszentrale erstellten ausstehenden Gutschriften.
Die Buchung dieser Belege führt zu Sachkontobuchungen der folgenden Art …
… welche in der folgenden Buchungsübersicht zusammengefasst wurde.
Die in der obenstehenden Buchungsübersicht dargestellten Pfeile sollen die anteilige Weiterleitung der in den Tochtergesellschaften erzielten Umsätze an die Unternehmenszentrale aufzeigen. Das hierbei verwendete buchhalterische „Weiterleitungs-Vehikel“ stellen die gebuchten intercompany Lizenzgebühren dar. Aufgrund dieser Weiterleitung ist es möglich die entstandenen Entwicklungskosten unmittelbar mit den zugehörigen Lizenzerlösen zu vergleichen, was eine wesentliche Voraussetzung für die Behandlung des internen Entwicklungsteams als Profit Center darstellt.
Zusammenfassung
Innerhalb dieses und der vorherigen Beiträge habe ich aufgezeigt wie man indirekte Kosten und Erlöse auf Projekten innerhalb einer bzw. zwischen verschiedenen Gesellschaften verteilen kann. Zusammenfassend lässt sich an dieser Stelle festhalten, dass Dynamics AX die hierfür notwendigen Prozesse, Buchungen und belege grundsätzlich bereitstellt, an der ein oder anderen Stelle allerdings einer kleinen Erweiterung bedarf um die entsprechenden Prozessvorgänge mehr bzw. vollständig zu automatisieren.
04 Freitag Nov 2016
Posted Projekt
inSchlagwörter
Gemeinkosten, indirekte Kosten, Intercompany, Projektkostenumlagen
Beispiel 2: Gehaltskosten des Direktoriums werden auf Projekte in den Tochtergesellschaften verteilt
Teil A: Ausgangssituation
Im vorherigen Beitrag habe ich Ihnen die Funktionsweise der Standard intercompany Arbeitszeitnachweisfunktion dargestellt. Innerhalb dieses Beitrags möchte ich das dort aufgezeigte Szenario erweitern und aufzeigen, wie die Gehaltskosten des Unternehmensdirektoriums auf Projekte in anderen Gesellschaften verteilt werden können.
Dem hier gewählten Beispiel liegt die Annahme zugrunde dass Mitglieder des Direktoriums ihre Arbeitszeit nicht in Dynamics AX auf Projekten erfassen, sondern lediglich deren Gehaltsaufwendungen in der Unternehmenszentrale (Firma USSI) summarisch gebucht werden.
Die folgende Darstellung illustriert die in diesem Beitrag verwendete Unternehmensstruktur und zeigt auf, dass ein Teil der Gehaltsaufwendungen aus der Zentrale auf die Projekte in den Tochtergesellschaften FRSI und GBI verteilt werden.
Hinweis. Ein wichtiger Gesichtspunkt im Rahmen der Erfassung und Buchung von intercompany Umlagen ist die Berücksichtigung internationaler Transferpreisregelungen, sowie die Erstellung von Rechnungen. Andernfalls besteht die Gefahr, dass Steuer-/Wirtschaftsprüfer die vorgenommenen Umlagen nicht anerkennen. Auf diese Gesichtspunkte wird nachfolgend noch im Detail eingegangen.
Teil B: Systemeinrichtung
Für die nachfolgende Darstellung von intercompany Kostenumlagen mit Projektbezug werden – ähnlich wie in einem früheren Beitrag – zunächst alle Kosten in einem ersten Schritt auf internen Sammel-Projekten (F0 und G0) erfasst, bevor diese in einem zweiten Schritt auf die verschiedenen Projekte verteilt werden. Die nächste Graphik zeigt diese prinzipielle Vorgehensweise auf.
Um diese Art der Kostenverteilung in Dynamics AX zu realisieren ist eine Reihe von Einrichtungsschritten erforderlich, die nachfolgend im Detail erläutert werden.
Setup B.1: Intercompany Dummy Lieferantenkonto in Firma USSI
Im ersten Einrichtungsschritt ist ein zunächst ein Dummy Lieferantenkonto in der Unternehmenszentrale (USSI) zu erstellen von der aus die Kosten verteilt werden sollen. Im Zusammenhang mit der Einrichtung dieses Dummy Lieferantenkontos gibt es drei Dinge zu berücksichtigen:
Erstens, die Hinterlegung eines GuV-Sammelkontos Nr. 602101 in den Kreditorenbuchungsprofilen, welches als Gegenkonto für die nachfolgenden Allokationsbuchungen benötigt wird.
Zweitens, die (optionale) Einrichtung einer eigenen Zahlungsmethode für dieses Dummy Lieferantenkonto, um ein unbegrenztes Anwachsen des Saldos auf diesem Konto zu verhindern und drittens, die (optionale) Verknüpfung des hinterlegten Sammelkontos mit festen Finanzdimensionswerten, welche im Rahmen der Verteilung der Direktorengehälter die entsprechenden Finanzdimensionen entlasten.
Setup B.2: Intercompany Kunden- und Lieferantenkonten
Nach Einrichtung des Dummy Lieferantenkontos, sind anschließend weitere gewöhnliche intercompany Kunden- und Lieferantenkonten in den Unternehmen, die am intercompany Umlagenprozess beteiligt sind einzurichten.
Wichtig bei der Einrichtung dieser intercompany Kunden- und Lieferantenkonten ist die Hinterlegung einer Standard intercompany Finanzdimensionsgröße, da sich andernfalls die nachfolgende Konsolidierung der Finanzdaten schwierig gestaltet.
Setup B.3: Projektkategorien
Im dritten Einrichtungsschritt ist eine Projektkategorie – die für die nachfolgenden Allokations- und Rechnungsbuchungen erforderlich ist – in allen am intercompany Prozess beteiligten Unternehmen einzurichten. Im Rahmen dieser Einrichtung gibt es weiter keine Besonderheiten zu berücksichtigen.
Hinweis. Die hier verwendete Kategorie wurde der Buchungsart “Ausgaben” zugeordnet.
Setup B.4: Beschaffungskategorien Firma USSI
Nach Einrichtung der Projektkategorie sind in der Unternehmenszentrale zwei Beschaffungskategorien für die Erfassung der intercompany Buchungen anzulegen. Grundsätzlich sollte eine Kategorie für diese Zwecksetzung ausreichen. Im Rahmen von Tests hat sich allerdings herausgestellt, dass bei der Nutzung leidglich einer Beschaffungskategorie unerwünschte Buchungszusammenfassungen vorgenommen wurden. Um dies zu vermeiden wurden daher zwei Beschaffungskategorien eingerichtet und verwendet.
Hinweis: Bitte beachten sie, dass beide Beschaffungskategorien mit der zuvor eingerichteten Projektkategorie verknüpft wurden. Neben der Einrichtung der beiden Beschaffungskategorien ist die Einrichtung entsprechender Sachkonten in der Lagerbuchungsmatrix erforderlich. In der obenstehenden Abbildung wurden hierfür die beiden Sachkonten Nr. 602310 und 602320 verwendet. Details zur Verwendung dieser beiden Sachkonten sind weiter unten dargestellt.
Setup B.5: Projekte Firma FRSI & GBSI
Als nächstes sind in den verschiedenen Tochtergesellschaften entsprechende Projekte einzurichten. Bei dieser Einrichtung ist auf keine Besonderheiten zu achten außer derjenigen, dass für die Projekte zumindest ein intercompany Finanzdimensionsstandardwert hinterlegt wird. Der folgende Screenshot zeigt dies beispielhaft auf.
Setup B.6: Sachkontobuchungseinstellungen
Der letzte erforderliche Einrichtungsschritt bezieht sich auf die Einrichtung der Sachkontobuchungseinstellungen im Projektmodul. In diesem Zusammenhang ist darauf zu achten, dass in der Unternehmenszentrale (USSI) ein entsprechendes intercompany Erlöskonto und in den Tochtergesellschaften intercompany Kostenkonten eingerichtet werden, wie dies beispielhaft im folgenden Screenshot dargestellt ist.
(Hinweis: Im gewählten Beispiel wird sowohl in der Unternehmenszentrale als auch in der Tochtergesellschaft GBSI der gleiche einheitliche Kontenplan eingesetzt. Die Tochtergesellschaft FRSI verwendet hingegen einen eigenen hiervon abweichenden lokalen Kontenplan).
Neben der Einrichtung der intercompany Konten ist im Rahmen der Sachkontobuchungseinstellungen für das Projektmodul darauf zu achten, dass die Kostenkonten für die Erfassung der verteilten Gehaltskosten auch im Bereich der Projektkosten eingerichtet sind, da letztere für die Buchung der Kostenumlagen auf die Projekte verwendet werden.
Hinweis: Die obenstehenden Projektbuchungseinstellungen wurden für Aufwandsprojekte vorgenommen. Für den Fall dass sie andere Projektarten verwenden können andere / weitere Buchungseinstellungen erforderlich werden.
Teil C: Prozessschritte
Schritt C.1: Buchung der Direktorengehälter in der Firma USSI
Basierend auf den vorgenommenen Einstellungen beginnt der intercompany Umlagenprozess zunächst mit der Erfassung und Buchung der Direktorengehälter in der Unternehmenszentrale USSI. Der Einfachheit halber wird diese Buchung in einem gewöhnlichen Hauptbuchjournal durchgeführt.
Bitte beachten sie, dass die obenstehende Buchung nicht nur rein auf Sachkontenebene, sondern im Zusammenhang mit einer BusinessUnit-und einer Abteilungs-Finanzdimension erfasst wurde.
Der sich aus der Buchung ergebene Beleg belastet auf der einen Seite ein GuV-Konto für Gehaltsaufwendungen (Konto Nr. 602100), welches auf der anderen Seite gegen ein Verbindlichkeitenkonto (Konto Nr. 201100) in der Bilanz gebucht wird. Siehe hierzu auch den folgenden Screenshot.
Schritt C.2: Buchung interner Kreditoren-Verrechnungsbeleg in Firma USSI
Der nächste Prozessschritt besteht in der Erfassung einer internen Buchungstransaktion, welche für die nachfolgende Erstellung der intercompany Rechnungen an die Tochtergesellschaften erforderlich ist. Im Rahmen dieser internen Buchungstransaktion wird eine „interne Rechnung“ auf dem zuvor angelegten Dummy Lieferantenkonto erfasst. Die Erfassung erfolgt hierbei unter Verwendung der angelegten Beschaffungskategorien und unter Referenz auf die in den Tochtergesellschaften angelegten Sammelprojekte. Im gewählten Beispiel werden hierbei insgesamt 200T USD den verschiedenen Tochtergesellschaften belastet (125T USD der Firma FRSI und 75T USD der Firma GBSI). Siehe hierzu auch die folgenden Screenshots.
Die Buchung dieses internen Rechnungsbelegs generiert den folgenden Sachkontobeleg, …
…, welcher in der nachfolgenden Übersicht nochmals aus buchhalterischer Sicht zusammengefasst ist.
(IC = Intercompany Finanzdimension, PRO = Projekt-Finanzdimension)
Was man der obenstehenden Buchungsdarstellung entnehmen kann ist zum einen, dass die Buchung des internen Rechnungsbelegs keinerlei Ergebnisveränderung in der Firma USSI führt, da aufgrund der vorgenommenen Buchungseinstellungen im Soll und Haben GuV-Konten angesprochen werden. Darüber hinaus kann man erkennen, dass buchhalterisch lediglich eine Aufteilung der Direktorengehaltsbuchung in drei Teile vorgenommen wurde:
Schritt C.3: Erstellung und Buchung Intercompany Rechnungen
Nach der Erfassung und Buchung des internen Rechnungsbelegs können die intercompany Rechnungen an die Tochtergesellschaften erstellt werden. Diese Erstellung findet über die Standard Dynamics AX intercompany Rechnungsfunktion im Projektmodul statt. Siehe hierzu auch den folgenden Screenshot.
Ein wesentlicher Vorteil dieser Art der intercompany Rechnungserstellung besteht darin, dass die zugehörigen steuerlichen Rechnungsbelege automatisiert erstellt werden. Der folgende Screenshot zeigt ein entsprechendes Beispiel aus meiner Demo-Umgebung auf.
Der mit der intercompany-Rechnung erstellte Buchungsbeleg weist im verwendeten Beispiel folgenden Inhalt auf.
Zur besseren Nachvollziehbarkeit der durchgeführten Buchungen wurden diese – wie zuvor – in der folgenden Darstellung nochmals zusammengefasst. Aus dieser Darstellung kann man den Ausgleichs- bzw. Ergebniseffekt der durch die Rechnungsbuchung in der Firma USSI hervorgerufen wird an den gelb hervorgehobenen Zellen erkennen.
Aufgrund der gebuchten intercompany Erlöse, verbleiben somit letztendlich nur 100T USD an Gehaltskosten für die Direktoren. Dieser Betrag kann anhand der Buchungsbeträge auf den Konten 602100, 602310, 602320, 602101 und 603200 nachvollzogen werden.
Schritt C.4: FRSI & GBSI: Buchung ausstehender Kreditorenrechnungen
Mit der Buchung der intercompany Rechnung in der Firma USSI werden gleichzeitig intercompany Kreditorenrechnungen in den Tochtergesellschaften FRSI und GBSI erstellt und können in der Maske der ausstehenden Kreditorenrechnungen identifiziert werden. Siehe hierzu auch den folgenden Screenshot.
Die Buchung dieser intercompany Kreditorenrechnungen führt zu folgenden Sachkontobuchungen.
Bitte beachten sie, dass die Buchungsbelege in den Tochtergesellschaften sowohl in USD, als auch mit der jeweiligen Buchhaltungswährung der Tochtergesellschaften (EUR bzw. GBP) gebucht werden. In diesem Zusammenhang gilt es zu beachten, dass die Entscheidung welche Währung im Rahmen der intercompany Verrechnung verwendet wird nicht lediglich eine buchhalterische Fragestellung ist, sondern auch Fragestellungen rund um Transferpreisregeln und –vereinbarungen berührt, weil über die Entscheidung der zu verwendenden intercompany Währung u.a. auch das Fremdwährungsrisiko zwischen den Gesellschaften verlagert werden kann.
Wie zuvor, fast die nachfolgende Darstellung die in den verschiedenen Gesellschaften gebuchten intercompany Rechnungen nochmals zusammen.
Schritt C.5: FRSI & GBSI: Umlage auf die verschiedenen Projekte
Einer der letzten Prozessschritte, welcher im Rahmen der intercompany Allokation durchzuführen ist, besteht in der Verteilung der auf den Sammelprojekten akkumulierten Gehaltskosten auf die verschiedenen Projekte. Diese Verteilung kann mit Hilfe der Regulierungsfunktion umgesetzt werden, die bereits in einem früheren Beitrag dargestellt wurde. Die nächsten Screenshots zeigen die Anwendung dieser Verteilungsfunktionalität – angewendet auf die Kosten, die in die Tochtergesellschaft GBSI übertragen wurden- auf.
Die nachfolgende buchhalterische Darstellung fasst die in den verschiedenen Tochtergesellschaften durchgeführten Buchungen nochmals zusammen und zeigt auf, dass alle Kosten auf die Projekte und zugehörigen Finanzdimensionen verteilt wurden.
Die verbleibenden beiden intercompany Prozessschritte werden im Rahmen dieses Beitrags nicht explizit aufgeführt, da sich nicht in unmittelbarem Zusammenhang mit der Umlagenfunktion stehen. Es handelt sich hierbei…
Zusammenfassung
Innerhalb dieses Beitrags habe ich aufgezeigt wie indirekte Kosten die in einer Gesellschaft anfallen auf Projekte in anderen Unternehmensteilen verteilt werden können. Ein wichtiger Gesichtspunkt in diesem Zusammenhang ist, dass alle grundlegen hierfür notwendigen Funktionalitäten und Belege im Standard von Dynamics AX enthalten sind.
Im nächsten und letzten Beitrag dieser Reihe soll aufgezeigt werden, wie auf Projektebene erfasste Kosten/Erlöse für interne Auswertungs- und Analysezwecke auf die Ebene der Konzernmuttergesellschaft zurückverteilt werden können.
23 Sonntag Okt 2016
Posted Projekt
inSchlagwörter
Gemeinkosten, indirekte Kosten, Intercompany, Projektkostenumlagen
Im vorherigen Beitrag habe ich verschiedene Möglichkeiten aufgezeigt, wie man über Dynamics AX Standardfunktionen indirekte Kosten auf Projekte verteilen kann. Der primäre Fokus im letzten Beitrag lag hierbei auf sog. intra-company Kostenumlagen und -verteilungen.
Innerhalb dieses und der folgenden Beiträge möchte ich diesen Fokus auf intercompany Kostenumlagen und -verteilungen erweitern und anhand von verschiedenen Beispielen aufzeigen, wie diese im Standard von Dynamics AX realisiert werden können.
Beispiel 1: Mitarbeiter der Firma USSI arbeiten auf Projekten der Firma FRSI
Teil A: Ausgangssituation
Im Rahmen dieses ersten Beispiels möchte ich zunächst auf die Standard intercompany Arbeitszeitnachweisfunktion eingehen, welche es Mitarbeitern erlaubt Zeiten auf Projekten, die in anderen Gesellschaften angelegt wurden, zu erfassen.
Der ein oder andere hat bestimmt schon von dieser Standardfunktion gehört bzw. etwas darüber gelesen. Ungeachtet dessen möchte ich dennoch innerhalb dieses ersten Beispiels auf dieses Szenario eingehen, weil es die Grundlage alle weiteren komplexeren intercompany Szenarien bildet.
Ausgangsbasis für dieses erste Beispiel ist eine Mitarbeiterin, die in der Firma USSI angestellt ist und für ein Kundenprojekt das in der Firma FRSI angelegt ist eine Softwareinstallation durchführt. Damit diese Mitarbeiterin ihre Zeiten auf das entsprechende Kundenprojekt in der Firma FRSI erfassen kann sind die folgenden Einstellungen erforderlich.
Teil B: Systemeinrichtung
Setup B.1: Intercompany Kunden – Lieferanten Beziehung
Zunächst ist es erforderlich in den Firmen USSI und FRSI entsprechende Kunden- und Lieferantenkonten anzulegen, welche über die Standard intercompany Funktion miteinander verknüpft werden, wie dies im folgenden Screenshot aufgezeigt ist.
Hinweis: Da im Rahmen der Projektbuchungseinstellungen keine Möglichkeit besteht auf eine bestimmte Gesellschaft zu referenzieren ist es erforderlich die entsprechenden Kunden-/Lieferantenkonten mit einer entsprechenden intercompany Finanzdimension einzurichten. Zu weiteren Einzelheiten hierzu, siehe auch weiter unten im Detail.
Setup B.2: Projekt Kategorien
Die zweite erforderliche Einrichtung bezieht sich auf die Einrichtung von Projektkategorien, die in beiden am intercompany Prozess beteiligten Firmen eingerichtet sein müssen.
Hinweis: Ist die Kategorie auf die Zeiten erfasst werden sollen nur in einer Firma angelegt, so wird die Verarbeitung der Zeiterfassung auf dem Projekt in der anderen Firma mit folgendem Fehlerhinweis unterbrochen:
Setup B.3: Intercompany Verrechnung
Sobald alle erforderlichen Projektkategorien in beiden Firmen angelegt wurden, kann im nächsten Schritt die Einrichtung der intercompany Verrechnungseinstellungen im Hauptbuch vorgenommen werden. Beispiel:
Die Einrichtung dieser Verrechnungsbeziehungen ist selbst nicht unmittelbar für die Buchung der intercompany Arbeitszeitnachweise erforderlich. Für eine richtige Zuordnung und Auswahl der entsprechenden Gesellschaften und Projekte ist diese Einrichtung allerdings unerlässlich.
Für den Fall dass eine solche Beziehung bspw. zwischen der Firma USSI und FRSI nicht besteht, ist eine Auswahl in der Arbeitszeitnachweismaske nicht möglich. Der folgende Screenshot zeigt dieses Systemverhalten nach Löschung der USSI-FRSI Verrechnungsbeziehung auf.
Setup B.4: Projekteinrichtung Firma FRSI
Bei der Projekteinrichtung in der Firma FRSI – auf welches später die entsprechenden Zeiten gebucht werden sollen – ist darauf zu achten, dass diese Einrichtung mit Hinterlegung einer entsprechenden intercompany Finanzdimension erfolgt. Andernfalls wird eine spätere Identifikation und Trennung von intercompany Kosten und Erlösen z.B. im Rahmen der Konsolidierung erheblich erschwert.
Hinweis: Die anderen an dieser Stelle verwendeten Finanzdimensionen (Abteilung 0023 & Projekt 0000027) sind für die Verarbeitung und Buchung der Zeiten auf intercompany Projekten nicht zwingend erforderlich. Aus Darstellungsgründen wurden diese beiden Größen allerdings an dieser Stelle mit aufgenommen.
Setup B.5: Mitarbeiter USSI
Nach der Einrichtung des Projekts in der Firma FRSI wird im nächsten Schritt der Mitarbeiter in der Firma USSI entsprechend eingerichtet. Im Rahmen dieser Einrichtung gibt es weiter keine Besonderheiten zu beachten außer derjenigen, dass die Mitarbeiter mit ihren zugehörigen Finanzdimensionen, wie den ihnen zugeordneten Abteilungen / Kostenstellen, usw. eingerichtet werden.
Setup B.6: Intercompany Verkaufspreis
Aus systemtechnischer Sicht ist die Einrichtung von intercompany Verkaufspreisen, welche für die Buchung und Abrechnung zwischen den Gesellschaften verwendet werden regelmäßig kein Problem, da lediglich ein bestimmter interner Verrechnungspreis zu hinterlegen ist.
Aus buchhalterischen und steuerlichen Gesichtspunkten ist die Festlegung von intercompany Verrechnungspreisen allerdings erheblich komplexer. Diese Komplexität lässt sich hauptsächlich auf eine Vielzahl von zum Teil widersprüchlichen intercompany Verrechnungspreisregeln zurückführen, auf die im Rahmen dieses Beitrags nicht eingegangen werden kann. Ein guter Ausgangspunkt für die hier angesprochenen Verrechnungspreisregeln stellen die OECD Transfer Pricing Guidelines dar.
Basierend auf dem grundlegenden OECD arm’s length Prinzip wurde für das hier verwendete Beispiel ein Verrechnungspreis in Höhe von 300 USD festgelegt, welcher dem Preis entspricht, den auch externe Kunden berechnet bekommen. Siehe hierzu den folgenden Screenshot.
Hinweis: Im Zusammenhang mit der Festlegung von internen Verrechnungspreisen erlaubt Dynamics AX auch die Nutzung von Auf- und Abschlags-Verkaufspreismodellen um hierdurch bestimmte Intercompany-Preis-Modelle aus den OECD Richtlinien abbilden zu können.
Teil C: Prozessschritte
Schritt C.1: Verarbeitung von intercompany Arbeitszeitnachweisen
Nachdem alle zuvor aufgeführten Einrichtungsschritte abgeschlossen wurden, kann die Mitarbeiterin der Firma USSI über die Arbeitszeitnachweismaske das zugehörige Projekt in der Firma FRSI auswählen und ihre Zeiten hierauf buchen. Zu beachten ist in diesem Zusammenhang dass die Finanzdimensionen, die auf dem Projekt hinterlegt wurden automatisiert in den Arbeitszeitnachweis übertragen werden, wie dies im folgenden Screenshot aufgezeigt ist.
Mit Buchung des Arbeitszeitnachweises generiert Dynamics AX die folgende Sachkontobuchung in der Firma USSI, welche auf der einen Seite das gewöhnliche Projekt-Kostenkonto (Nr. 540100) mit den Kosten für die geleisteten Arbeitsstunden belastet und auf der anderen Seite das Lohn- und Gehaltsverrechnungskonto Nr. 602100 entsprechend entlastet.
Schritt C.2: Buchung der intercompany Projektrechnung
Nach der Erfassung der Stunden erfolgt im nächsten Schritt die Buchung der intercompany Rechnung über die entsprechende Projektmodulfunktion. Beispiel:
Sobald alle zu berechnenden Positionen ausgewählt und gebucht wurden …
… verbleibt der folgende Buchungsbeleg.
Hinweis: Das im Rahmen dieser Buchung verwendete intercompany Forderungskonto Nr. 133100 stammt aus den Debitoren Buchungsprofileinstellungen und das intercompany Erlöskonto aus den Sachkontobuchungseinstellungen im Projektmodul.
Schritt C.3: Buchung der zugehörigen Kreditorenrechnung in der Firma FRSI
Mit der Buchung der intercompany Projektrechnung in der Firma USSI wird gleichzeitig eine entsprechende Kreditorenrechnung in der Firma FRSI erstellt, die im Bereich der ausstehenden Kreditorenrechnungen im Kreditorenmodul identifiziert werden kann.
Die Buchung dieser Rechnung führt zu folgender Sachkontobuchung:
Um die einzelnen Buchungen besser nachvollziehen zu können, habe ich diese in der folgenden Übersicht nochmals zusammengefasst.
Was man der obenstehenden Übersicht entnehmen kann ist …
Hinweis: Wie bereits mehrfach erwähnt ist die Nutzung einer intercompany Finanzdimension für den gesamten Prozess entscheidend. Diesbezüglich gilt es zu beachten, dass es über die Projektbuchungseinstellungen nicht möglich ist Konteneinstellungen in Abhängigkeit bzw. Referenz zu einer bestimmten Firma zu hinterlegen, sondern dass zwingend die Nutzung von Finanzdimensionsgrößen hierfür erforderlich ist.
Was buchhalterisch geschieht, wenn die intercompany Finanzdimensionsinformation auf Ebene des IC-Projekts fehlt, kann aus dem folgenden Screenshot identifiziert werden.
Die rot hervorgehobenen Flächen und Pfeile zeigen auf, dass es bei fehlender intercompany Finanzdimensionshinterlegung auf Ebene des Projekts zu erheblichen Schwierigkeiten im Rahmen der Konsolidierung kommen kann, da die zu konsolidierenden intercompany Buchungen nicht einfach identifiziert werden können. Gleiches gilt für die Prüfung der verwendeten Verrechnungspreisregeln.
Zwischenergebnis
Ich hoffe dass Ihnen dieser Beitrag einige neue Hinweise im Hinblick auf den Einsatz der intercompany Arbeitszeiterfassung liefern konnte auch wenn sie bereits zuvor davon gehört und/oder gelesen haben. Vor dem Hintergrund dieser Standardfunktion möchte ich im folgenden Beitrag auf andere, komplexere intercompany Verrechnungsszenarien eingehen.
02 Sonntag Okt 2016
Posted Projekt
inSchlagwörter
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.
25 Freitag Mrz 2016
Posted Projekt
inSchlagwörter
Fortsetzung von Teil (4)
Die folgenden Screenshots fassen die im Rahmen der zuvor verwendeten Beispielbuchungen und Analysen nochmals der Vollständigkeit halber überblicksartig zusammen.
Die im Folgenden eingefügten Screenshots stellen die bereits weiter oben dargestellten Werte nochmals in anderer Form dar und verdeutlichen nochmals dass erst über die Ermittlung des EV ein sinnvolles Projektcontrolling möglich ist.
Betrachtet man sich die Beispieldaten nochmals genau, so erkennt man, dass das Projekt von Anfang an über Budget und hinter dem Zeitplan war. Der einfache PLAN-IST Vergleich konnte hingegen bis August 2016 keinerlei Hinweise auf mögliche Probleme in der Projektabwicklung liefern.