Fünf Fragen & Antworten zum Jahresabschluss in Dynamics AX

16 Mittwoch Dez 2015

Schlagwörter

Abschlussbogen, Primobuchungen, Zwischenbilanz

Da das Jahresende unmittelbar vor der Tür steht habe ich mir überlegt etwas zum Jahresabschluss und im speziellen zu den Primobuchungen in Dynamics AX zu schreiben. Die erwähnte Primobuchungsfunktionalität kann man in Dynamics AX unter den periodischen Hauptbuchfunktionen wie im folgenden Screenshot dargestellt finden.

Im Zusammenhang mit der Primobuchungsfunktion sollen nachfolgend die folgenden Fragen anhand von Beispieldaten beantwortet werden:

Welche Auswirkung hat die Aktivierung bzw. Deaktivierung des Parameters „Jahresabschlussbuchungen bei Umbuchung löschen“?
Welchen Effekt hat die Aktivierung bzw. Deaktivierung des Parameters „Abschussbuchungen bei Umbuchung erstellen“?
Was ist der Unterschied zwischen der Auswahl „Schließen->Öffnen“ und „Zurücksetzen“ in der Primobuchungsmaske?
Welchen Effekt hat die Auswahl einer speziellen Finanzdimension auf die im Rahmen des periodischen Primobuchungsprozesses generierten Buchungen?
Welche Auswirkung hat die Hinterlegung eines Eröffnungskontos im Kontenplan auf den Jahresabschlussprozess?

Beispieldaten
Um die eingangs gestellten Fragen zu beantworten wurden zunächst die Bilanz-Anfangsbestände in einem ersten Schritt in Dynamics AX erfasst. Anschließend wurde im zweiten Schritt – aus Vereinfachungs- und Darstellungsgründen – eine einzige Verkaufstransaktion gebucht, bevor im dritten Schritt die Primobuchungen zum ersten Mal verarbeitet und gebucht wurden. Aufgrund einer von den Wirtschaftsprüfern geforderten und im vierten Schritt gebuchten Anpassungsbuchung wurden im fünften Schritt die Primobuchungen erneut verarbeitet. Die nachfolgende Prozessdarstellung fasst die durchgeführten Schritte nochmals überblicksartig zusammen.

In den beiden folgenden Screenshots werden die durchgeführten Prozessschritte nochmals aus buchhalterischer Sicht zusammengefasst dargestellt. Für die Interpretation dieser Daten gilt es die folgenden Vereinbarungen zu berücksichtigen:

Neben vierstelligen Sachkonten wurden alle Buchungen mit einer dreistelligen Finanzdimension erfasst. Die Kombination 1000-001 repräsentiert bspw. das Sachkonto „Anlagevermögen“ und die Geschäftseinheit „001“.
Aus Darstellungs- und Vereinfachungsgründen wurde die denkbar einfachste Bilanz- und Gewinn- und Verlustrechnungsstruktur (GuV) gewählt, die im Wesentlichen aus einem Anlage- und Umlagevermögenskonto auf der Aktivseite und einem Eigen- und Fremdkapitalkonto auf der Passivseite der Bilanz besteht. Für die GuV wurden lediglich ein Umsatzerlös- und ein Kostenkonto verwendet.

Fragestellung 1: Welche Auswirkung hat die Aktivierung bzw. Deaktivierung des Parameters „Jahresabschlussbuchungen bei Umbuchung löschen“?
Unabhängig davon ob der Parameter „Jahresabschlussbuchungen bei Umbuchungen löschen“ aktiviert ist oder nicht, generiert Dynamics AX den folgenden Buchungsbeleg bei der erstmaligen Verarbeitung der Primobuchungen:

Der im vorstehenden Screenshot dargestellte Buchungsbeleg zeigt die Vortragsbuchuchungen zum 01. Januar des Folgejahres auf. Diesem Beleg ist zu entnehmen, dass der Gewinn des Vorjahres in Höhe von 600 EUR auf das Bilanzkonto 2100 zusammen mit der Finanzdimension 001 übertragen wird.
Nach Durchführung der von den Prüfern geforderten Anpassungsbuchung werden die Primobuchungen erneut verarbeitet um hierdurch die Veränderungen an den Anfangssalden im neuen Jahr korrekt darzustellen. Im Rahmen dieses zweiten Verarbeitungslaufes der Primobuchungen werden in Abhängigkeit von der Aktivierung bzw. Nicht-Aktivierung des Parameters „Jahresabschlussbuchungen bei Umbuchung löschen“ unterschiedliche Belege generiert, die nachfolgend erläutert werden.

Fall 1: Parameter „Jahresabschlussbuchungen bei Umbuchung löschen“ ist aktiviert
Ist der Parameter aktiviert, so löscht Dynamics AX den zuvor erstellten Vortragsbuchungsbeleg und erstellt einen neuen.

Fall 2: Parameter „Jahresabschlussbuchungen bei Umbuchung löschen“ ist nicht aktiviert
Ist der Parameter hingegen nicht aktiviert, so generiert Dynamics AX einen zusätzlichen Vortragsbuchungsbeleg, lässt den zuvor erstellten allerdings unverändert bestehen.

Obwohl die Löschung von gebuchten Belegen regelmäßig gegen geltende Buchhaltungsvorschriften verstößt, findet man in der Praxis häufig Systeme bei denen der angesprochene Parameter aktiviert ist. Aufgrund der angesprochenen Löschungsproblematik besteht die „best practice“ Einstellung nach Meinung des Verf. darin diesen Parameter nicht zu aktivieren.

Fragestellung 2: Welchen Effekt hat die Aktivierung bzw. Deaktivierung des Parameters „Abschlussbuchung bei Umbuchung erstellen“?
Um den Unterschied in der Aktivierung bzw. Nicht-Aktivierung des zweiten im Rahmen dieses Beitrags angesprochenen Parameters darzustellen, wurden die zuvor dargestellten und durchgeführten Buchungen in einem anderem Geschäftsjahr wiederholt, um anschließend den ersten Primobuchungslauf zu verarbeiten.

Fall 1: Parameter „Abschlussbuchungen bei Umbuchung erstellen“ ist nicht aktiviert
Für den Fall das der Parameter nicht aktiviert ist ergeben sich die gleichen Vortragsbuchungen die bereits weiter oben dargestellt wurden.

Fall 2: Parameter „Abschlussbuchungen bei Umbuchung erstellen“ ist aktiviert
Ist der Parameter hingegen aktiviert, so erstellt Dynamics AX zum 31. Dezember des Vorjahres die im folgenden Screenshot gelb hervorgehobenen Zusatzbuchungen.

Diese Zusatzbuchungen stellen sicher dass alle Sachkonten bereits zum Ende des Vorjahres in der Abschlussperiode gegen das Gewinn-/Verlustkonto (2100-001) gebucht werden bevor der Übertrag der Salden in das neue Jahr erfolgt.
Eine unmittelbare Auswirkung haben diese Zusatzbuchungen auf die Kontendarstellung in der Zwischenbilanz, da aufgrund der durchgeführten Umbuchungen kein Abschlusssaldo mehr identifiziert werden kann.

Aus auswertungstechnischen Gründen erscheint es daher sinnvoll den Parameter “Abschlussbuchungen bei Umbuchungen erstellen” nicht zu aktivieren um dadurch sicherzustellen, dass es im Ausweis der Zwischenbilanz nicht zu einer Vermischung von Abschluss- und Vortragsbuchungen kommt.

Fragestellung 3: Was ist der Unterschied zwischen der Auswahl „Schließen->Öffnen“ und „Zurücksetzen“ in der Primobuchungsmaske?
Die dritte hier aufgeworfene Frage lässt sich sehr schnell und einfach dergestalt beantworten dass die Auswahl “zurücksetzen” keine automatisierten Vortragsbuchungen generiert und diese daher vom Anwender manuell zu erfassen sind. Abgesehen von Testszenarien sollte nach Meinung des Verf. daher immer die Auswahl „Schließen->Öffnen“ getroffen werden.

Fragestellung 4: Welchen Effekt hat der Auswahl einer speziellen Finanzdimension auf die im Rahmen des periodischen Primobuchungsprozesses generierten Buchungen?
Wird im Finanzdimensionsreiter der Primobuchungsmaske eine bestimmte Finanzdimension ausgewählt, wie dies im folgenden Screenshot beispielhaft dargestellt ist, …

… so verwendet Dynamics AX die ausgewählte Finanzdimension für die Vortragsbuchung des Gewinns bzw. Verlustes des Vorjahres. Alle anderen Sachkontobuchungen werden von dieser Einstellung nicht beeinflusst wie der nachfolgende Beispielbuchungsbeleg aufzeigt.

Da die Hinterlegung einer Finanzdimension in der Primobuchungsmaske lediglich einen Einfluss auf Finanzdimensionsbuchung auf dem Bilanzkonto für im Vorjahr erwirtschaftete Gewinne / Verluste hat stellt sich die Frage nach möglichen Anwendungsfällen für die Hinterlegung einer spezifischen Finanzdimension an dieser Stelle.
Ein solches denkbares Anwendungsszenario in der Praxis sind Situation in denen Unternehmen unterschiedliche Buchhaltungsvorschriften (HGB, IFRS, US-GAAP, usw.) in Dynamics AX abbilden und die sich hieraus ergebenden unterschiedlichen Gewinne/Verluste entsprechend buchhalterisch trennen möchten.

Fragestellung 5: Welche Auswirkung hat die Hinterlegung eines Eröffnungskontos im Kontenplan auf den Jahresabschlussprozess?
Wenn Sie im Kontenplan für ein bestimmtes Sachkonto ein Eröffnungskonto hinterlegen…

…, dann wird dieses Konto für die Vortragsbuchungen im Folgejahr herangezogen. Im aufgezeigten Beispiel wird der Endsaldo des Sachkontos 1000 auf das Sachkonto 1001 übertragen.

Eine derartige Hinterlegung eines Eröffnungskontos erfolgt i.d.R. immer dann, wenn bestimmte Konten stillgelegt und in Folgejahren nicht mehr bebucht werden sollen.

Zum Schluss möchte ich Ihnen noch ein frohes Weihnachtsfest und einen guten Rutsch ins Neue Jahr wünschen. Ich hoffe, dass Sie die in den letzten Monaten veröffentlichten Beiträge interessant und hilfreich fanden und würde mich freuen Sie auch wieder im kommenden Jahr auf dieser Seite begrüßen zu dürfen.

Parallele Lagerbewertung

09 Mittwoch Dez 2015

Posted by Ludwig Reinhard in Lager

≈ Ein Kommentar

Schlagwörter

Dual warehouse, Lagerbewertung, Lagersteuerungsgruppe

Vielleicht hat der eine oder andere von ihnen bereits einmal der Anforderung begegnet die Lagerbestände nach mehr als einem Verbrauchsfolgeverfahren bewerten zu müssen z.B. weil Steuerprüfer danach verlangen. Die Möglichkeit der parallelen Bewertung von Lagerbeständen besteht bereits seit einiger Zeit in Dynamics AX über die sog. Dual Warehouse Funktion. Siehe hierzu beispielhaft auch den folgenden Screenshot, der eine Lagersteuerungsgruppe aufzeigt, die eine gleichzeitige Bewertung nach FIFO und LIFO erlaubt.

Sucht man im Internet nach der Dynamics AX Dual Warehouse Funktion so findet man nur einige wenige Informationen (siehe z.B. die folgende Webseite, so dass einem regelmäßig nichts anderes übrig bleibt als die Funktion auszutesten.

Um die Dual Warehouse Funktion auszutesten ging ich zunächst davon aus, dass man über die Aktivierung des entsprechenden Konfigurationsschlüssels die Funktion generell bereitstellen kann.

Leider war dies zu kurz gedacht und auch nach der Synchronisation und Kompilierung meiner Test-Datenbank bestand keine Möglichkeit ein zweites Lagermodell in der Lagersteuerungsgruppenmaske einrichten zu können.

Mein nächster Versucht bestand darin im AOT nach dem Begriff „dual warehousing“ zu suchen. Bei dieser Suche stieß ich auf das folgende Projekt.

Über die Suche nach Länderschlüsseln in diesem Projekt habe ich nun versucht die Dual Warehouse Funktion allgemein verfügbar zu machen.

Die Erweiterung der entsprechenden Konfiguration im Programmcode war etwas aufwendig, brachte allerdings auch nicht den erhofften Erfolg; im Gegenteil, nach der Erweiterung des Programmcodes dieses Projekts funktionierten einige Standardfunktionen nicht mehr ordnungsgemäß.

Aufgrund dessen setzte ich die Anpassung aller zugehörigen Tabellen, Klassen, usw. fort bis die Dual Warehouse Funktion schließlich auch in meiner deutschen Test-Firma bereitstand. Nach der Bereitstellung dieser Funktion ging ich daran die Funktion anhand der folgenden Testtransaktionen zu prüfen.

Nach der Erfassung aller Testbuchungen konnte ich in der „Am Lager“ Maske den folgenden laufenden Durchschnittspreis erkennen, der mit meinen Berechnungen soweit übereinstimmte.

Von diesen Daten ausgehend habe ich anschließend das Lager zweimal reguliert; zunächst mit Hilfe der Standard „Abschluss und Regulierungsfunktion“ und anschließend über die „Close and adjustment in currency“ Funktion.

Im Ergebnis konnte man anschließend die folgenden beiden Anpassungsbeträge bei der erfassten Verkaufsbuchung erkennen.

Der gewöhnliche Lagerwertbericht zeigte wie erwartet den FIFO-Wert entsprechend dem ersten eingerichteten Wertmodell.

Da es keinen eigenen Lagerwertbericht für die Duale Warehouse Funktion gibt konnte kein vergleichbarer Bericht für die LIFO-Bewertung erstellt werden, da ein solcher Bericht erst entwickelt werden muss.

Zusammenfassung & Evaluierung
Die Möglichkeit einer parallelen Lagerbewertung ist sehr interessant speziell in Fällen wo bspw. Steuerbehörden nach einer zweiten alternativen Lagerbewertung verlangen.

Selbst wenn eine solche Anforderung nicht besteht kann der Einsatz der Dual Warehouse Funktion hilfreich sein, da hierüber eine Bestandsbewertung in einer zweiten Währung möglich ist, die es bspw. erlaubt die Effektivität von eingesetzten Währungssicherungsinstrumenten im Warenbereich zu beurteilen.

Trotz dieser potentiellen Vorteile gilt es allerdings folgendes zu beachten:

Die Dual Warehouse Funktion erlaubt lediglich den Einsatz einer zusätzlichen Lagerbewertungsmethode,
Ein eigener Dual Warehouse Lagerwertbericht ist nicht vorhanden und muss erst entwickelt werden,
Wenn die Berichts- und Buchhaltungswährung voneinander abweichen ist eine parallele Bestandsbewertung praktisch nicht möglich da Währungseffekte immer zu einer Verzerrung der ausgewiesenen Werte führen,
Die größte Problematik besteht allerdings im sog. „development footprint“ welche die Dual Warehouse Funktion in einem System hinterlässt. Der nächste Screenshot zeigt einige (!) der Tabellen und Klassen auf, die von der Bereitstellung dieser Funktion beeinflusst werden.

Aus diesem Auszug kann man bereits erkennen dass die Dual Warehouse Funktion praktisch das gesamte System und somit auch die Möglichkeit späterer Upgrades erheblich beeinflusst.

Darüber hinaus gilt es zu beachten, dass vor der Bereitstellung der Dual Warehouse Funktion eine detaillierte Codeanalyse und Codeanpassung erforderlich ist. Andernfalls erhält man ein System mit vielen zusätzlichen Funktionen, Einstellfenstern, usw. die man ohne weitere Recherche gar nicht einrichten kann.

Aufgrund der letztgemachten Anmerkungen erscheinen mir die Risiken und potentiellen Probleme der Dual Warehouse Funktion im Vergleich zu den erwünschten Vorteilen zu groß speziell wenn man eigentlich nur an einem zweiten Lagerwertbericht interessiert ist, der die Bestände nach einem anderen Verbrauchsfolgeverfahren bewertet. Im letzten Fall erscheint eine einfache Berichtsentwicklung basierend auf math. statistischen Verfahren deutlich einfacher umsetzbar als der Einsatz der Dual Warehouse Funktion.

Management Reporter – Integration unterschiedlicher Kontenpläne

03 Donnerstag Dez 2015

Posted by Ludwig Reinhard in Management Reporter

≈ Hinterlasse einen Kommentar

Schlagwörter

Dynamics AX, Konsolidierung, Kontenplan, Management Reporter

Im Rahmen von Konsolidierungen sind regelmäßig Finanzdaten aus unterschiedlichen Firmen miteinander zu kombinieren. Häufig basieren die zu kombinierenden Finanzdaten der verschiedenen Firmen auf unterschiedlichen Kontenplänen die einander zuzuordnen und in einem Bericht aufzunehmen sind. Wie eine solche Zuordnung im Management Reporter vorgenommen werden kann, soll anhand des nachfolgend dargestellten stark vereinfachten Beispiels aufgezeigt werden.

Beispiel:
Die Finanzdaten der beiden Firmen DEMF und BRMF sind zu konsolidieren, wobei die erste Firma (DEMF) einen anderen Kontenplan verwendet als die zweite Firma (BRMF). Hinzu kommt, dass die beiden Firmen ihre Bücher in unterschiedlichen Währungen führen (EUR bzw. BRL). Der folgende Screenshot fasst die unterschiedlichen Einstellungen der beiden Firmen nochmals überblicksartig zusammen.

Um die folgenden Ausführungen und Darstellungen so einfach wie möglich zu halten, werden lediglich die Bankkonten der beiden Firmen betrachtet.

Auf dem Bankkonto (Sachkonto „110200“) der Firma DEMF wurde hierbei im Berichtszeitraum lediglich eine Buchung in Höhe von 10000 EUR durchgeführt.

Auf dem Bankkonto der brasilianischen Tochtergesellschaft (Sachkonto „1.1.1.2.02“) wurden hingegen die folgenden beiden Buchungen in BRL durchgeführt.

Der für die Konsolidierung verwendet Wechselkurs wurde vereinfachend auf 300 BRL / 100 EUR festgelegt.

Basierend auf diesen Daten sollte der Bericht einen Bankkonten-Saldo in Höhe von 50000 EUR bzw. 150000 BRL ausweisen.

Um einen solchen Bericht zu generieren sind die folgenden Einrichtungen erforderlich.

Schritt 1: Einrichtung der Zeilendefinition
Im ersten Schritt sind die Konten aus den verschiedenen Kontenplänen einander zuzuordnen. Diese Zuordnung („Mapping“) erfolgt hierbei über die Definition eigener Zeilenverknüpfungen (sog. row links), welche die Kontoinformationen aus den verschiedenen Firmen beinhalten. Der folgende Screenshot zeigt diese Verknüpfung exemplarisch auf.

Schritt 2: Einrichtung der Berichtsbaumstruktur
Im nächsten Schritt ist ein Berichtsbaum einzurichten über den die verschiedenen Firmen mit der im ersten Schritt eingerichteten Zeilenstruktur verknüpft werden. Beispiel:

Schritt 3: Einrichtung der Spaltendefinition
Der dritte Einrichtungsschritt besteht in der Einrichtung der Spaltendefinition. Hierbei ist die Verknüpfung zu den Elementen des zuvor eingerichteten Berichtsbaums in der Zeile „Reporting Unit“ herzustellen, wie dies im nächsten Screenshot aufgezeigt wird.

Schritt 4: Einrichtung des Management Reporter Berichts
Im letzten Schritt sind schließlich die Zeilenstruktur, der Berichtsbaum sowie die Spaltenstruktur in einem Bericht miteinander zu verknüpfen. Vor der Verarbeitung des Berichts ist hierbei darauf zu achten, dass die Checkbox für die Fremdwährungsumrechnung ausgewählt wird, wenn der Bericht später in unterschiedlichen Währungen dargestellt werden soll.

Ergebnis:
Nachdem der Bericht verarbeitet wurde kann dieser über eine entsprechende Auswahl des Währungskennzeichens in unterschiedlichen Währungen dargestellt werden. Die beiden nachfolgenden Screenshots zeigen dies am Beispiel der Währungen „EUR“ und „BRL“ auf.