Management Reporter – Excel Import

23 Montag Nov 2015

Posted by Ludwig Reinhard in Management Reporter

Schlagwörter

Dynamics AX 2012, Excel Import, Management Reporter

Bei der Erstellung von Management Reporter Berichten trifft man häufig auf die Notwendigkeit Daten aus Dynamics AX mit Daten aus externen Excel-Datenquellen miteinander in einem Bericht verknüpfen zu müssen. Beispiele hierfür sind Konsolidierungsberichte bei denen ausländische Gesellschaften ihre Finanzdaten in Form von Excel Berichten einreichen oder PLAN-IST Berichte bei denen die IST-Daten aus Dynamics AX mit in Excel geführten PLAN-Daten zu kombinieren sind.

Wie derartige kombinierte Berichte im Management Reporter abgebildet werden können ist Gegenstand der nachfolgenden Ausführungen. Im Rahmen der hierfür notwendigen Excel-Importdefinitionen sind zwei unterschiedliche Vorgehensweisen bzw. Importmethoden zu unterscheiden: die sogenannte „Combined Link“ Importmethode und die sog. „Separate Link“ Importmethode.

Option 1: „Combined Link“ Importmethode
Die sog. combined link Importmethode stellt die erste Möglichkeit dar externe Excel-Daten in Management Reporter Berichten zu integrieren. Diese Vorgehensweise zeichnet sich dadurch aus, dass in einer einzigen Spalte der Management Reporter Zeilendefinition eine Verknüpfung sowohl zu den Dynamics AX Daten als auch zu den externen Excel-Daten hergestellt wird. Im folgenden Screenshot ist diese Integrationsmöglichkeit derart dargestellt dass Referenzen zu Dynamics AX Daten gelb und Referenzen zu externen Excel Daten grün hervorgehoben sind.

Leider ist es im Rahmen dieser Importmethode nicht möglich die Referenzen zu den Dynamics AX Daten mit denen der externen Excel-Daten in einer Zeile zu kombinieren weshalb zusätzliche Berechnungszeilen erforderlich sind.

Neben den dargestellten Referenzen im Zeilendefinitionsfenster sind im Spaltendefinitionsfenster entsprechende „WKS“-Spalten zu integrieren, welche die externen Excel-Daten aufnehmen. Siehe hierzu den folgenden Screenshot.

Im letzten Schritt sind schließlich die Zeilen- und Spaltendefinitionen miteinander in einem Bericht zu kombinieren um diesen erstellen zu können. Ergebnis:

Hinweise bei Nutzung der combined link Importmethode

Die Verknüpfung zu den externen Excel-Daten wird im Zeilendefinitionsfenster hergestellt. Die Referenz “@WKS(G=C3)” bedeutet in diesem Zusammenhang beispielsweise dass der Wert aus der Zelle C3 des Exceldokuments in der Management Reporter Berichtsspalte G angezeigt wird. Siehe hierzu auch die folgende Darstellung.
Die Referenzen zu den externen Exceldaten sind statisch. Dies bedeutet, dass Änderungen an der Spaltendefinition regelmäßig Anpassungen aller „@WKS“ Zeilen im Zeilendefinitionsfenster erfordern. Dieser Umstand schränkt die Nutzung der combined link Importmethode auf solche Fälle ein, bei denen eine vergleichsweise kleine Anzahl an externen Excel-Daten in Management Reporter Berichte zu integrieren sind. Für den Import größerer Datenmengen über verschiedene Berichtsperioden hinweg scheint die separate link Importmethode dagegen besser geeignet zu sein. Diese Methode wird im folgenden Unterkapitel dargestellt.

Option 2: „Separate Link“ Importmethode
Die separate link Importmethode stellt die zweite Möglichkeit der Integration externer Excel Daten in Management Reporter Berichte dar. Der wesentliche Unterschied zur combined link Methode besteht darin, dass sowohl die Referenzen zu den Dynamics AX Daten als auch die Referenzen zu den externen Exceldaten in jeweils einer eigenen Spalte im Zeilendefinitionsfenster umgesetzt werden, wie dies beispielhaft im folgenden Screenshot dargestellt ist.

Der zweite wesentliche Unterschied zur combined link Methode besteht darin, dass die Verknüpfung zum externen Exceldokument nicht über die Zeilendefinitionsmaske, sondern über einen eigenen Berichtsbaum erfolgt (siehe den nächsten Screenshot).

Wie zuvor sind für die Berichtserstellung Berichtszeilen, Berichtsspalten und Berichtsbäume miteinander zu verknüpfen bevor der Bericht aufgerufen werden kann.

Hinweise bei Nutzung der separate link Importmethode

Bei dieser zweiten Importmethode werden Referenzen zu externen Exceldaten über die Schlüsselkennzeichen „CPO“ bzw. „RPO“ im Zeilendefinitionsfenster definiert, die angeben in welche Richtung der Management Reporter beim Datenimport suchen soll (C => Spaltenweise, R => Zeilenweise). Siehe hierzu auch die folgende Darstellung.
Im Gegensatz zur combined link Methode wird bei der separate link Methode die Zellen über den Periodencode im Spaltendefinitionsfenster definiert. Im gewählten Beispiel wird der Sales-Budget Wert für den ersten Berichtsmonat aus dem Exceldokument aus der Zelle C3 entnommen (=> Startpunkt B3 aus der Zeilendefinition + 1 zusätzliche Zelle rechts davon gem. Periodendefinition im Spaltendefinitionsfenster). Der Sales-Budget Wert für den zweiten Monat wird aus der Zelle D3 entnommen (=> Startpunkt B3 aus der Zeilendefinition + 2 zusätzliche Zellen rechts davon gem. Periodendefinition im Spaltendefinitionsfenster), usw.
Dieser relative Zellbezug macht diese Importmethode sehr robust bspw. gegenüber Änderungen die an Spaltendefinitionen vorgenommen werden. Aufgrund dessen eignet sich die separate link Importmethode deutlich besser für den Import von großen Datenmengen über mehrere Berichtsperioden hinweg.

Buchungsschnellerfassungen

05 Samstag Sep 2015

Posted by Ludwig Reinhard in Hauptbuch, Kreditoren

≈ Hinterlasse einen Kommentar

Schlagwörter

Buchungsschnellerfassung, Buchungsvorlagen, Dynamics AX 2012, Sachkontoalias

Manuelle Buchungserfassungen können in Dynamics AX sehr schnell zeitaufwendig werden insbesondere dann, wenn viele Finanzdimensionswerte wie Kostenstellen, Kostenträger, usw. zu erfassen sind. Glücklicherweise gibt es verschiedene Standardfunktionen, welche einem die manuelle Erfassung von Buchungsbelegen erleichtern. Nachfolgend sollen einige dieser Buchungsschnellerfassungen dargestellt werden.

Sachkontoalias
Eine erste Möglichkeit der Buchungsschnellerfassung besteht in der Nutzung von sog. Sachkontoalias, die im Hauptbuch angelegt, aber auch in anderen Modulen wie z.B. dem Kreditoren- oder Projektmodul genutzt werden können. Die Einrichtung von Sachkontoalias gestaltet sich recht einfach, da für eine bestimmte Buchungskombination (bestehend aus Sachkonto und Finanzdimensionen) ein eindeutiger Schlüssel angelegt wird.

Anstatt mühsam Sachkonten und Finanzdimensionen manuell erfassen zu müssen, kann im Buchungsjournal einfach der eingerichtete Sachkontoalias-Schlüssel eingegeben werden. Dynamics AX ersetzt diesen Schlüssel bei der Betätigung der Tab-Taste durch die entsprechende Buchungskombination, so dass die Buchung nur noch geprüft und ggf. vervollständigt werden muss. Im folgenden Beispiel wird die Finanzdimension „Department“ ergänzt, weil dieses nicht über den Buchungsschlüssel vordefiniert wurde.

Standardkontoeinstellungen
Eine zweite Möglichkeit der Buchungsschnellerfassung besteht in der Nutzung von Standardkontoeinstellungen im Kreditorenmodul. Diese Einstellungen können zum einen auf Ebene der Kreditorengruppe als auch auf Ebene des einzelnen Kreditors vorgenommen werden. Beispiel:

Wird das entsprechende Kreditorenkonto ausgewählt, so schlägt Dynamics AX automatisch das entsprechende Sachkonto zur Buchung vor. Siehe hierzu beispielhaft den folgenden Screenshot.

Excel add-in
Eine dritte Möglichkeit manuelle Buchungen schnell in AX erfassen und buchen zu können ist deren Aufbereitung in einem Excel-Vorlagendokument sowie ein entsprechender Upload dieser Buchungen nach Dynamics AX. Einzelheiten zu dieser Funktionalität wurden bereits in früheren Beiträgen aufgezeigt. Von daher wird an dieser Stelle auf weitergehende Ausführungen verzichtet. Zu Einzelheiten, siehe dort.

Buchungsvorlagen
Die letzte im Rahmen dieses Beitrags dargestellte Möglichkeit für die Buchungsschnellerfassung besteht in der Nutzung von Buchungsvorlagen. Buchungsvorlagen können bspw. in Hauptbuch- oder Kreditorenrechnungsjournalen angelegt und für die spätere Widerverwendung gespeichert werden. Der folgende Screenshot stellt dies beispielhaft dar.

Nachdem die Buchungsvorlagen angelegt wurden, können diese zu einem späteren Zeitpunkt über eine entsprechende Selektion abgerufen und wiederverwendet werden. Beispiel:

Zusammenfassend kann man somit an dieser Stelle festhalten, dass Dynamics AX verschiedene Möglichkeiten zur Schnellerfassung von Buchungsbelegen bietet. Alle aufgezeigten Möglichkeiten erlauben vor der Durchführung der Buchung eine entsprechende Überarbeitung und ggf. notwendige Änderung der vorgeschlagenen Buchungen und ermöglichen somit einen flexiblen Einsatz.

Trennung von Auftragserlösen und Rücklieferungsauftragserlösminderungen

18 Samstag Jul 2015

Posted by Ludwig Reinhard in Debitoren

≈ Hinterlasse einen Kommentar

Schlagwörter

Dynamics AX 2012, Erlöskonten, Rücklieferungen

Der ein oder andere von Ihnen wird vielleicht schon einmal dem Umstand begegnet sein, dass Dynamics AX für Auftragserlösbuchungen sowie für die Buchung von Kundenrücklieferungen die gleichen Erlöskonten verwendet. Dies liegt darin begründet, dass Dynamics AX in beiden Fällen auf die Konten aus dem Umsatzerlösbereich in den Lagerbuchungseinstellungen zugreift. Siehe hierzu auch den folgenden Screenshot.
Dieses Standardsystemverhalten ist aus Finance & Controlling Sicht sehr unglücklich, da Umsatzerlöse und Erlösminderungen aus Rücklieferungen in das gleiche Sachkonto einfließen und somit das Reporting über die verschiedenen Umsatzarten bzw. Umsatzminderungen erschweren.

Glücklicherweise gibt es zahlreiche Möglichkeiten, wie diesem Sachverhalt begegnet werden kann um eine Trennung von Auftragserlösen und Rücklieferungserlösminderungen zu erlangen. In diesem Beitrag möchte ich Ihnen einige dieser Möglichkeiten sowie damit zusammenhängende Vor- und Nachteile darstellen.

Lösungsansatz 1: Manuelle Anpassung des Sachkontos in der Rücklieferungsmaske
Die erste Möglichkeit Rücklieferungserlösbuchungen von gewöhnlichen Auftragserlösbuchungen zu trennen besteht darin das Sachkonto, welches automatisch aus dem Kundenauftrag in die Rücklieferungsmaske übertragen wird, manuell zu überschreiben, wie dies im folgenden Screenshot beispielhaft dargestellt ist.

Diese manuelle Änderung stellt sicher, dass die Buchung der Gutschrift an den Kunden mit dem manuell eingetragenen Erlöskonto erfolgt. Der folgende Screenshot stellt das Ergebnis meiner durchgeführten Beispielbuchung dar.

Vorteile & Nachteile dieses Lösungsansatzes
Die wesentlichen Vorteile dieses ersten Lösungsansatzes bestehen in seiner Einfachheit und darin, dass keine Systemanpassungen erforderlich sind. Diesen Vorteilen steht allerdings der höhere Zeitaufwand für die manuelle Änderung der Sachkonten in der Rücklieferungsmaske gegenüber, speziell in Fällen in denen sehr viele Kontenänderungen vorzunehmen sind. Im Zusammenhang mit dem erwähnten erhöhten Zeitaufwand steht auch ein erhöhtes Risiko von Fehleingaben und daraus resultierenden fehlerhaften Sachkontobuchungen.

Lösungsansatz 2: Nutzung der Dimensionsverknüpfungsfunktion
Eine zweite Möglichkeit zur Trennung von Rücklieferungserlösbuchungen von gewöhnlichen Auftragserlösbuchungen besteht in der Nutzung der Dimensionsverknüpfungsfunktion im Lagerbereich. Zu beachten ist in diesem Zusammenhang allerdings, dass die Erlöstrennung nicht über eigene Sachkonten, sondern über Finanzdimensionen erfolgt.

Die Nutzung dieses zweiten möglichen Lösungsansatzes setzt voraus, dass Standorte zunächst mit einer Finanzdimensionsgröße verknüpft werden, wie dies in den beiden folgenden Screenshots dargestellt ist.
Basierend auf diesen Einstellungen ist im Rahmen der Erfassung von Rücklieferungen lediglich darauf zu achten, dass die richtigen Lagerdimensionen (insbes. der richtige Standort) gewählt werden, da diese Auswahl entscheidend für die Kennzeichnung von Rücklieferungserlösminderungen und somit der Buchung der Kundengutschrift ist. Die folgenden beiden Screenshots stellen die hier beschriebene Vorgehensweise nochmals exemplarisch dar.

Im Ergebnis sorgt dieser Prozessablauf dafür dass die Buchung der Kundengutschrift zwar über das gleiche Erlöskonto – im Beispiel Konto 401100 – allerdings mit dem Kennzeichen „Rücklieferungsabteilung 193“ durchgeführt wird. Über diese Kennzeichnung kann anschließend eine Analyse der Rücklieferungserlösminderungen durchgeführt werden.

Vorteile & Nachteile dieses Lösungsansatzes
Ein wesentlicher Vorteil dieser Vorgehensweise im Vergleich zum eingangs dargestellten Lösungsansatz besteht darin, dass keine manuellen Kontoänderungen in der Rücklieferungsmaske erforderlich sind, was das Risiko von Falscheingaben erheblich mindert.
Ungeachtet dieses Vorteils hat der Lösungsansatz über die Dimensionsverknüpfung allerdings den Nachteil, dass er unter Umständen mit dem Lagersetup und den Vorgängen im Lagerbereich im Konflikt steht und daher ggf. nicht realisierbar ist. Darüber hinaus ist zu berücksichtigen dass für diesen Lösungsansatz evtl. die Einrichtung einer weiteren Finanzdimension erforderlich sein kann.

Lösungsansatz 3: Systemanpassung
Wenn die beiden zuvor dargestellten Lösungsansätze in ihrem Unternehmen aufgrund verschiedener Umstände nicht realisierbar sind, so kann alternativ für die Erlöstrennung von Aufträgen und Rücklieferungen eine kleine Systemanpassung in Betracht gezogen werden. Im Folgenden wird eine sehr einfache Möglichkeit aufgezeigt, wie eine solche Systemanpassung umgesetzt werden kann um Auftragserlöse von Rücklieferungsauftragserlösminderungen zu trennen.

Ausgangspunkt dieses Lösungsansatzes ist, dass die Erlöskonten die für Rücklieferungen verwendet werden, aus einem anderen Bereich der Lagerbuchungsmaske herangezogen werden. Im nachfolgenden Beispiel habe ich der Einfachheit halber den Buchungstyp (=> invent account type) „Lieferschein-Umsatzerlös“ gewählt, in dem das Erlösminderungskonto 405000 hinterlegt wurde.

Hinweis: Die dahinterstehende Annahme ist, dass im normalen Geschäftsbetrieb nicht mit dem Buchungstyp „Lieferschein-Umsatzerlös“ gearbeitet wird. Falls dies bei Ihnen doch der Fall sein sollte, so können Sie einen beliebigen anderen Buchungstypen verwenden, notfalls einen länderspezifischen, den Sie über eine kleine Erweiterung der Länderkonfiguration bereitstellen können.

Unabhängig vom konkret gewählten Buchungstyp gehe ich, wie zuvor erwähnt, für die nachfolgenden Darstellungen davon aus dass die Rücklieferungserlösminderungskonten im Bereich „Lieferschein-Umsatzerlös“ hinterlegt sind.
Um auf diese Konten zugreifen zu können wird in der Return Table Methode “loadSegments“ die folgende Codeanpassung vorgenommen. Siehe die beiden folgenden Screenshots.

Die hier dargestellte Anpassung überschreibt das zunächst von AX gefundene Sachkonto aus dem ursprünglichen Auftrag durch dasjenige, das im Bereich „Lieferschein-Umsatzerlös“ gefunden wird. Für die Wahl dieses Buchungstyps ist die Referenz zum InventAccountType „SalesPckSlipRevenue“ ausschlaggebend.

Aufgrund dieser minimal invasiven Anpassung wird standardmäßig immer das Sachkonto verwendet, welches im Bereich der physischen Umsatzerlösbuchung in der Lagerbuchungsmaske hinterlegt ist.

Dieses Konto wird entsprechend bei der Buchung der Kundengutschrift verwendet, wie dies in Fortsetzung des gewählten Beispiels im nächsten Screenshot dargestellt ist.

Vorteile & Nachteile dieses Lösungsansatzes
Ein wesentlicher Vorteil dieses dritten Lösungsansatzes besteht darin, dass er mit einer kleinen Systemanpassung umgesetzt werden kann und die manuelle Kontoänderung in der Rücklieferungsmaske überflüssig macht, was das Risiko von Falscheingaben erheblich mindert.
Die Nachteile dieses Ansatzes bestehen darin, dass ein Dynamics AX Entwickler für die Codeimplementierung benötigt wird und dass die hier dargestellte Vorgehensweise keine Trennung von Erlösminderungen anhand der Rückgabegründe wie z.B. Bruch, Falschbestellung, usw. ermöglicht. Wie dem letztgenannten Einwand begegnet werden kann ist im Folgenden letzten Unterkapitel dargestellt.

Lösungsansatz 4: Verknüpfung von Belastungs- und Dispositionscodes
In diesem letzten Kapitel möchte ich kurz darstellen wie bei Rücklieferungsaufträgen eine Trennung der Erlösminderungen entsprechend den Rückgabegründen der Kunden erfolgen kann. Ausgangspunkt hierfür ist die Verknüpfung der Rücklieferungs-Dispositionscodes mit Belastungscodes, wie dies im folgenden Screenshot beispielhaft dargestellt ist.

Bitte beachten Sie dass der Belastungscode mit der Kategorie “Prozent” und einem Wert von 100% eingerichtet wurde.

Alle in diesem Zusammenhang verwendeten Belastungscodes wurden jeweils so eingerichtet, dass die Soll- und Habenbuchung über eigene Sachkonten erfolgt. Über diese Sachkonten kann später eine Analyse der Rücklieferungserlösminderungen durchgeführt werden.

Beispiel:
Die nachfolgenden Darstellungen stellen ein Beispiel des aufgezeigten Setups dar. Ausgangspunkt ist ein Kundenauftrag über 100 Stück eines Produkts, welches am 01. August zu einem Preis von 322 EUR / Stück verkauft wurde. Die Auftragserlöse wurden hierbei über das Sachkonto 401100 abgebildet. Weitere Details können dem folgenden Screenshot entnommen werden.
Acht Tage später hat der Kunde 10 Stück der verkauften Produkte retourniert. Diese Rückgabe wurde in Dynamics AX über die folgende Rücklieferung abgebildet. DE_27_0160
Bitte beachten Sie, dass im Rahmen der Retourenbuchungen keine Änderung am Sachkonto vorgenommen wurde und demnach das gleiche Sachkonto herangezogen wird, welches auch im Rahmen der ursprünglichen Auftragsbuchung verwendet wurde.

Als nächstes wurden die zurückgelieferten Produkte im Lager erfasst. Für diese Erfassung wurde ein Dispositionscode angegeben, der u.a. darüber entscheidet was mit der Ware geschieht (Einlagerung, Verschrottung, usw.).
Mit der Buchung der Rücklieferungsgutschrift hat Dynamics AX schließlich die folgenden Sachkontobuchungen durchgeführt:
Neben der standardmäßigen Buchung der Erlösminderungen auf dem Konto 401100 (gelb hervorgehoben) wurden aufgrund des hinterlegten Belastungscodes zwei zusätzliche Buchungszeilen (grün hervorgehoben) generiert anhand derer in der Buchhaltung abgelesen werden kann warum Kunden Produkte zurückgeschickt haben.

Nach der Buchung von weiteren Rücklieferungen mit anderen Dispositionscodes weißt die Zwischenbilanzmaske schließlich am Monatsende die folgenden Werte aus:

Die gelb und grün hervorgehobenen Zeilen können wie folgt interpretiert werden:

Die Summe der gelb hervorgehobenen Zeilen (22540.00 + 6440.00 + 3220.00 = 32200.00) stellen die gesamten Umsatzerlöse des Monats dar.
Die Summe der grün hervorgehobenen Zeilen (6440.00 + 3220.00 = 9660.00) repräsentieren Erlösminderungen aufgrund von Kundenrücklieferungen.
Aufgrund der verwendeten unterschiedlichen Dispositionscodes kann identifiziert werden, dass von den gesamten Kundenrücklieferungen im Wert von 9660.00, insgesamt 6440.00 durch Beschädigungen auf dem Transportweg („dead on arrival“) und 3220.00 durch Falschbestellungen („ordering error“) verursacht wurden.

Vorteile & Nachteile dieses Lösungsansatzes
Ein wesentlicher Vorteil dieses zuletzt ausgeführten Lösungsansatzes besteht darin, dass alle Einrichtungen und Vorgänge im Standard von Dynamics AX abgebildet werden können. Nachteilig ist allerdings, dass – je nach Ausgestaltung – unter Umständen zahlreiche neue Sachkonten anzulegen sind und die Analyse und Interpretation der Kundenerlöse durch diese zusätzlichen Sachkonten erschwert wird.

Zusammenfassend kann man an dieser Stelle festhalten, dass Dynamics AX zahlreiche Möglichkeiten bietet gewöhnliche Auftragsumsatzerlöse von Rücklieferungserlösminderungen zu unterscheiden. Ich hoffe, dass ihnen die Ausführungen in diesem Beitrag eine Hilfestellung bei der Implementation von Dynamics AX in diesem Bereich geben können.

Produktzugangsbuchung bei Bestellungungen mit Einkaufskategorien

11 Samstag Jul 2015

Posted by Ludwig Reinhard in Kreditoren

≈ Ein Kommentar

Schlagwörter

Dynamics AX 2012, Lieferscheinbuchung Einkaufskategorien

Ohne weitere Einstellungen generiert Dynamics AX bei der Buchung eines Lieferscheins (Produktzugangs) für Bestellungen, die ausschließlich für Einkaufskategorien durchgeführt werden, keinerlei Sachkontobuchung. Im folgenden Screenshot ist dieses Standardverhalten von Dynamics AX am Beispiel der Bestellung von „Staplers“ dargestellt.Dieses Standardverhalten ist aus Finance & Controlling Sicht insbesondere dann nachteilig, wenn zwischen dem Zeitpunkt der Vereinnahmung der Ware und dem Zeitpunkt der Rechnungsstellung ein längerer Zeitraum liegt und es sich um vergleichsweise größere Beträge handelt. Der angesprochene Nachteil besteht darin, dass speziell im Fall monatsübergreifender Abrechnungen der entsprechende Aufwand in der Gewinn- und Verlustrechnung nicht korrekt dargestellt und in der Bilanz nicht abgegrenzt ist.

Glücklicherweise lässt sich dieses Standardverhalten durch eine entsprechende Parametrisierung ändern. Die angesprochene Parametrisierung ist allerdings etwas „versteckt“ und kann über sog. Einkaufsrichtlinien im Beschaffungsmodul vorgenommen werden. Über die Einrichtung einer sog. Kategorierichtlinienregel sowie der Aktivierung des Parameters „Einkaufsausgaben bei Zugang antizipieren“ (siehe die beiden folgenden Screenshots) kann eine entsprechende Abgrenzungsbuchung realisiert werden. Der nächste Screenshot zeigt die Sachkontobuchung, die im Rahmen der Lieferscheinbuchung in diesem Fall durchgeführt wird beispielhaft auf.Zu beachten ist hierbei, dass die Soll-Buchung auf dem Sachkonto durchgeführt wird, welches im Bereich „Einkaufsaufwendungen, nicht fakturiert“ hinterlegt ist. Die Gegenbuchung findet auf dem Einkauf-Abgrenzungskonto statt. Wie in Dynamics AX üblich werden die im Rahmen der Lieferscheinbuchung generierten Sachkontobuchungen mit der Rechnungsbuchung wieder durch eine entsprechende Gegenbuchung aufgehoben.

Fehlervermeidung mit Hilfe der elektronischen Signaturfunktion

04 Samstag Jul 2015

Posted by Ludwig Reinhard in Sonstiges

≈ Hinterlasse einen Kommentar

Schlagwörter

Datenbankprotokoll, Dynamics AX 2012, Elektronische Unterschrift

In den beiden vorherigen Beiträgen habe ich aufgezeigt wie man das Datenbankprotokoll einrichten kann, um Änderungen an Feldern/Tabellen mitprotokollieren zu lassen.

Trotz der unbestreitbaren Vorteile des Datenbankprotokolls ist dieses lediglich in der Lage Fehler ex post festzuhalten und aufzuzeigen. Eine Möglichkeit Fehler ex ante zu vermeiden bietet das Datenbankprotokoll hingegen nicht. Die Standardfunktion der elektronischen Signaturen in Dynamics AX bietet hingegen diese Möglichkeit. Wie diese Funktion (leicht modifiziert) zur Vermeidung von Fehlern eingesetzt werden kann, wird anhand des nachfolgenden Beispiels kurz dargestellt. (Hinweis: Zur Standardfunktion der elektronischen Signatur, siehe diese verknüpfte TechNet Seite).

Beispiel:
Im Organisationsverwaltungsmodul wurde für die Lagerbuchungseinstellungen eine Anforderung für die elektronische Signatur eingerichtet.

Versucht nun ein Mitarbeiter die Buchungseinstellungen zu verändern indem er ein anderes Sachkonto hinterlegt, …

… so öffnet sich automatisiert das folgende Fenster:

Da kein elektronisches Unterschriftszertifikat eingerichtet wurde, kann dieses Fenster nur mit „Abbrechen“ verlassen werden ohne die vorgenommene Änderung speichern zu können.

Zusammenfassend lässt sich somit festhalten, dass über die Standardfunktion der elektronischen Unterschriften kritische Felder/Tabellen in Dynamics AX abgesichert werden können ohne dass hierfür eine Systemanpassung erforderlich ist.

Datenbankprotokoll – Wichtige Felder Finanzbereich (2)

20 Samstag Jun 2015

Posted by Ludwig Reinhard in Sonstiges

≈ Hinterlasse einen Kommentar

Schlagwörter

Datenbankprotokoll, Dynamics AX 2012

Basierend auf die im vorherigen Post dargestellten Anpassungen werden nachfolgend die wichtigsten Tabellen aufgezeigt, die aus Finanzsicht grundsätzlich immer mitprotokolliert werden sollten.

Hinweis: Die folgenden Screenshots sind alle in Englisch (en-us) dargestellt, um Verwechslungen aufgrund der andersartigen deutschen Übersetzungen zu vermeiden.

Anlagen
Einstellungen

Anlagevermögen

Wertmodelle

Organisationsweite Anlagenbezeichner (soweit verwendet)

Lagerverwaltung & Produktinformationsverwaltung
Einstellungen

Artikel

Kreditoren
Einstellungen

Lieferanten

Debitoren
Einstellungen

Kunden

Bank
Einstellungen

Bankkonten

Hauptbuch
Einstellungen

An dieser Stelle soll nochmals explizit darauf hingewiesen werden dass die obenstehenden Einstellungen die persönliche Meinung des Verfassers darstellen und keinen Anspruch auf Vollständigkeit erheben. Ungeachtet der Einstellungen, die Sie im Datenbankprotokoll im Einzelnen vornehmen, sollten Sie immer darauf achten es möglichst zu vermeiden Transaktionstabellen mitprotokollieren zu lassen, da die Protokollierung selbiger sich negativ auf die Systemleistung auswirken kann.

Wenn Sie wichtige Tabellen und Felder vermissen, die grundsätzlich immer mitprotokolliert werden sollten, dann wäre ich Ihnen über einen kurzen Kommentar dankbar, damit auch andere Dynamics AX Benutzer hiervon profitieren können.

Datenbankprotokoll – Wichtige Felder Finanzbereich (1)

20 Samstag Jun 2015

Posted by Ludwig Reinhard in Sonstiges

≈ Hinterlasse einen Kommentar

Schlagwörter

Datenbankprotokoll, Dynamics AX 2012

Wer schon einmal versucht hat das Datenbankprotokoll in Dynamics AX einzurichten, wird festgestellt haben, dass es häufig sehr schwierig ist die richtigen Tabellen und Felder, die protokolliert werden sollen, zu identifizieren. Ein Grund hierfür ist, dass sich die im Einrichtungsassistenten angezeigten Namen von denen im AOT unterscheiden. Einige Tabellen und Felder stehen sogar mehrfach zur Auswahl. Der folgende Screenshot zeigt ein solches Beispiel auf.

Um dieses Problem zu umgehen wurden für die nachfolgenden Darstellungen die folgenden beiden System-Anpassungen vorgenommen:

1. Über die erste Modifikation wird sichergestellt, dass die AOT Namen anstatt der entsprechenden Labels im Datenbankprotokollassistenten angezeigt werden.

Durch die in den beiden letzten Screenshots dargestellten Anpassungen wird sichergestellt, dass die AOT Namen und nicht hiervon abweichende Bezeichnungen (Labels) im Datenbankprotokoll Einrichtungsfenster angezeigt werden.

2. Die zweite Anpassung wird aus Darstellungsgründen vorgenommen um den ursprünglich verwendeten Bezeichnungen die AOT Namen gegenüberzustellen.
Im Ergebnis können nun die AOT Namen neben den ursprünglich vorhandenen Label Bezeichnungen in der Spalte „Table name“ identifiziert werden um sicherzustellen, dass die richtigen Tabellen und Felder ausgewählt wurden.

Max. Anzahl von Finanzdimensionen

07 Sonntag Jun 2015

Posted by Ludwig Reinhard in Hauptbuch

≈ Hinterlasse einen Kommentar

Schlagwörter

Anzahl Finanzdimensionen, Dynamics AX 2012, Hauptbuch, Kontostruktur

Wer mehr als 10 Finanzdimensionen – zusätzlich zum Hauptkonto – benötigt, wird bei der Einrichtung der Kontostrukturkonfiguration feststellen, dass keine Möglichkeit besteht mehr als 10 Finanzdimensionen in der folgenden Kontostrukturkonfigurationsmaske hinzuzufügen.

Dies bedeutet allerdings nicht, dass man in Dynamics AX 2012 nicht mit mehr als 10 Finanzdimensionen arbeiten kann, denn über die Einrichtung sog. erweiterter Regelstrukturen besteht die Möglichkeit weitere 11 Finanzdimensionen hinzuzufügen, so dass man zusätzlich zum Hauptkonto mit 21 Finanzdimensionen arbeiten kann. Siehe hierzu beispielhaft die folgenden Screenshots.

All diese Finanzdimensionen lassen sich problemlos über den Management Reporter auswerten. Beispiel:

Eine Auswertung aller 21 Finanzdimensionen (zusätzlich zum Hauptkonto) über die Dynamics AX Zwischenbilanzmaske ist allerdings ohne weitergehende Anpassungen nicht möglich, da in der hierfür notwendigen Finanzdimensionssatzmaske maximal 11 Finanzdimensionen aufgenommen werden können.

Aufgrund dessen bleibt für eine Auswertung im Standard von Dynamics AX 2012 nur die Möglichkeit mehrere Finanzdimensionssätze mit max. 11 Finanzdimensionen anzulegen um alle Finanzdimensionen auswerten zu können.

T-Konto Funktionalität

04 Donnerstag Jun 2015

Posted by Ludwig Reinhard in Hauptbuch

≈ Hinterlasse einen Kommentar

Schlagwörter

Dynamics AX 2012, Splitbuchung, T-Konto

Wenn Sie mit der Handhabung der im Standard von Dynamics AX verfügbaren Splitbuchungsfunktion Probleme haben, dann kann Ihnen die im Folgenden beschriebene T-Konto Funktion evtl. Erleichterung verschaffen.

Betrachten wir zunächst die Standard Splitbuchungsfunktion und wie diese für die Eingabe der folgenden Rechnung genutzt werden kann:

Die Erfassung dieser Rechnung mit Hilfe der Splitbuchungsfunktion erfordert die folgenden Schritte:

Schritt 1: Wählen Sie zunächst das Kreditorenkonto aus, tragen Sie den Rechnungsbetrag ein und treffen Sie anschließend die Auswahl „Funktionen-Splitbuchung“

Schritt 2: Erfassen Sie im oberen Bereich der Splitbuchungsmaske die Steuer und Betragsinformationen und im unteren Bereich das entsprechend zugehörige Sachkonto. Bitte beachten Sie dass diese Eingaben pro Steuerkombination vorzunehmen sind, was u.U. eine mehrfache Navigation zwischen den beiden Bereichen der Splitbuchungsmaske erforderlich macht.

Schritt 3: Sobald sich die Soll- und Habenbeträge entsprechen, wird der Aktualisieren-Button aktiv, der es Ihnen erlaubt die Splitbuchungszeilen in das Journal zu übertragen.

Schauen wir uns nun zum Vergleich die Erfassung der gleichen Rechnung über die T-Konto Funktion an:

Schritt 1: Wählen Sie zunächst das Kreditorenkonto aus, tragen Sie dann den Rechnungsbetrag ein und treffen Sie anschließend die Auswahl “T-Konto”

Schritt 2: Beim Öffnen der T-Konto Maske können Sie die erfassten Kreditoren Informationen bereits erkennen.

Vervollständigen Sie die Buchung indem Sie die zugehörigen Soll-Positionen eingeben wie dies im folgenden Screenshot dargestellt ist.

Hinweis: Für eine schnellere Buchungserfassung können Sie die T-Konto Maske personalisieren indem Sie bspw. die Steuerfelder in die T-Konto Zeilen aufnehmen.

Schritt 3: Mit dem Schließen der T-Konto Maske werden die Buchungszeilen in das Journal übertragen

Hinweis: Wie aufgezeigt erlaubt Ihnen die T-Konto Maske eine größere Flexibilität in Bezug auf die Erfassung von Buchungszeilen. Im Gegensatz zur Splitbuchungsmaske ist es über die T-Konto Maske bspw. auch möglich andere Kontotypen (Debitoren, Kreditoren, Sachanlagen, usw.) auszuwählen. Darüber hinaus erfordert der Übertrag der Splitbuchungszeilen in das Buchungsjournal nicht, dass die Splitbuchung vollständig fertiggestellt ist wie die folgenden beiden Screenshots aufzeigen.

Die Übertragung unvollständiger Splitbuchungszeilen bedeutet natürlich nicht dass eine solche Buchung durchgeführt werden kann; es erlaubt Ihnen allerdings eine größere Flexibilität in der Erfassung und im Übertrag der einzelnen Buchungszeilen.

Nach der Darstellung der T-Konto Funktionalität wird im Folgenden dargestellt wie diese Standardfunktion bereitgestellt werden kann. Für diese Bereitstellung sind die folgenden geringfügigen Systemmodifikationen erforderlich.

Modifikation 1: Aktivieren Sie den Extended Data Type “LedgerTAccountEnabled_JP” für die Länder in denen Sie diese Funktion benötigen.

Nach der Bereitstellung dieses Parameters wird der folgende Hauptbuchparameter aktiv, den Sie auswählen sollten.

Modifikation 2: Tragen Sie die iso Ländercodes die Sie benötigen in der LedgerParameters Tabellenmethode “isTAccount” ein.

Modifikation 3: Aktivieren Sie die Länderschlüssel für den TAccount menu item button in der LedgerJournalTransDailyTAccount Maske wie nachfolgend dargestellt

Modifikation 4: Erlauben Sie das Editieren der Kontotypen in der T-Konto Maske für die Soll- und Habenseite wie in den folgenden beiden Screenshots aufgezeigt.

Modifikation 5: Passen Sie die Lookup Methode für die Soll- und Habenseite wie nachfolgend beispielhaft dargestellt an um die entsprechenden Konten für die verschiedenen Kontotypen die Sie benötigen auswählen zu können. Beispiel:

Modifikation 6: Passen Sie die SegmentValueChanged Methoden in der LedgerJournalTransDailyTAccount Maske an wie im folgenden Screenshot aufgezeigt.

Modifikation 7: Passen Sie das Label @GLS60236 nach Bedarf an

Bitte beachten Sie dass die aufgeführten Modifikationen die T-Konto Maske lediglich für Hauptbuchjournale bereitstellt. Eine Erweiterung auf andere Journale wie z.B. Kreditorenrechnungsjournale ist – basieren auf den aufgezeigten Modifikationen – vergleichsweise einfach analog möglich.

Anschaffungsnebenkosten – Teil 1

24 Sonntag Mai 2015

Posted by Ludwig Reinhard in Lager

≈ Hinterlasse einen Kommentar

Schlagwörter

Aktivierung Frachtkosten, Anschaffungsnebenkosten, Dynamics AX 2012, Lagerbewertung

Der folgende Beitrag befasst sich mit der Abbildung von Anschaffungsnebenkosten, die regelmäßig von Warenlieferanten entweder unmittelbar im Zusammenhang mit einer Bestellung oder unabhängig von bestimmten Bestellungen von Spediteuren/Paketdienstleister u.ä. pauschaliert in Rechnung gestellt werden.

Ausgangspunkt für die nachführenden Ausführungen ist §255 HGB, der u.a. definiert was unter dem Begriff „Anschaffungskosten“ zu verstehen ist. Demzufolge gehören auch sog. Nebenkosten wie Frachtkosten, Kosten der Transportversicherung, usw. zu den Anschaffungskosten eines Vermögensgegenstandes. (Hinweis: Diese Vorschrift unterscheidet sich de facto nicht von denen anderer Rechnungslegungsstandards sowie den Vorgaben der Steuerverwaltung).

Die Legaldefinition der Anschaffungskosten ist aus Sicht von Dynamics AX deshalb wichtig, weil sie explizit eine Aktivierung der Anschaffungsnebenkosten in der Bilanz erfordert.

Eine Möglichkeit dieser gesetzlichen Anforderung nachzukommen besteht darin Frachtkosten, welche von Warenlieferanten unmittelbar in Rechnung gestellt werden über einen sog. sonstigen Zuschlag auf Bestellebene zu erfassen und zu buchen. Wird dieser sonstige Zuschlag mit dem Soll-Buchungstyp „Artikel“ eingerichtet, wie dies im folgenden Screenshot dargestellt ist, so erhöht sich der Bilanzwert des Artikels den gesetzlichen Vorgaben entsprechend um den Wert des gebuchten sonstigen Zuschlags.

Schwierig gestaltet sich die aufgezeigte Nutzung von sonstigen Zuschlägen in solchen Fällen in denen diese nicht unmittelbar einer bestimmten Bestellung bzw. einem bestimmten Artikel zugeordnet werden können, weil bspw. ein Frachtführer eine Sammelrechnung für durchgeführte Lieferungen innerhalb eines bestimmten Zeitraums stellt. Wie in solchen Situationen dennoch eine Aktivierung der in Rechnung gestellten Frachtkosten im Standard von Dynamics AX erfolgen kann, soll nachfolgend anhand der folgenden Beispieldaten aufgezeigt werden.

Beispiel:

Im Beispielfall wird davon ausgegangen, dass in einem bestimmten Jahr, Waren für insgesamt 100 mio. EUR eingekauft wurden. Für diese Einkäufe wurden insgesamt 1,4 mio. EUR an Frachtkosten in Rechnung gestellt, die den verschiedenen Bestellungen und Artikeln direkt zugeordnet werden konnten. Aufgrund des weiter oben aufgezeigten verwendeten sonstigen Zuschlages wurden diese Frachtkosten bilanziell erfasst und erhöhten den Lagerbestandswert unmittelbar.

Neben diesen direkt zuordenbaren Frachtkosten wurden 600 TEUR an Frachtkosten gebucht, die keinem Artikel bzw. keiner Bestellung unmittelbar zugeordnet werden konnten. Die derart von Lieferanten in Rechnung gestellten Frachtkosten wurden über Rechnungserfassungsjournale sofort erfolgswirksam in der Gewinn- und Verlustrechnung (GuV) auf dem Konto 600725 erfasst.
Aufgrund der unmittelbar erfolgswirksamen Erfassung der indirekten Frachtkosten sind die Lagerbestände insgesamt um 600 TEUR zu niedrig bewertet.

Um diese Unterbewertung in den Folgejahren zu vermeiden, wurde für das Folgejahr im ersten Schritt ein neuer sonstiger Zuschlag („FRACHTALLOKATION“) angelegt, der dafür Sorge trägt, dass die über diesen Zuschlag gebuchten Kosten die Anschaffungskosten der Artikel erhöhen. Als Gegenkonto wurde für die Habenbuchung ein Fracht-Verrechnungskonto (600735) verwendet.

Der derart eingerichtete sonstige Zuschlag wurde im zweiten Schritt als sog. automatischer Zuschlag hinterlegt, welcher dafür sorgt, dass bei jeder Bestellbuchung einen Zuschlag in Höhe von 2% des Warenwertes bilanziell erfasst wird. (Hinweis: Der Prozentwert von 2% wurde basierend auf den im vergangenen Jahr tatsächlich angefallenen Frachtkosten im Verhältnis zum Einkaufsvolumen ermittelt).

Um zu verhindern, dass es aufgrund dieses automatischen Zuschlages sowie den direkt zuordenbaren Frachtkosten zu einer mehrfachen Berücksichtigung von Frachtkosten auf Artikeln und somit zu einer Überbewertung der Bestände kommt, wurde im dritten Schritt ein neuer sonstiger Zuschlag für direkt zuordenbare Frachtkosten angelegt, der den eingangs aufgezeigten Frachtkostenzuschlag ersetzt.
Zu beachten ist an dieser Stelle, dass dieser neue Zuschlag zu einer unmittelbaren erfolgswirksamen Erfassung der Frachtkosten in der GuV führt.

Im folgenden Jahr traten nun 2,64 mio. EUR an direkt und indirekt erfassbaren Frachtkosten auf, die alle erfolgswirksam in der GuV auf den Sachkonten 600720 bzw. 600725 erfasst wurden. Aufgrund des eingerichteten Automatikzuschlags wurden hiervon 2,4 mio. EUR auf den Artikelbestand über das Sachkonto 600735 verrechnet und in der Bilanz aktiviert. Die insgesamt verbleibende Differenz in Höhe von 240 TEUR – welche sich aus der Summe der auf den Frachtkostenkonten 600720, 600725 und 600735 gebuchten Beträge ergibt – stellt demnach den Betrag dar um den die Lagerbestände insgesamt unterbewertet sind.

Die folgende Grafik stellt den Zusammenhang zwischen den tatsächlich angefallenen Frachtkosten, den über den Automatikzuschlag verrechneten Frachtkosten sowie der auftretenden Über-/Unterallokation dar.

An dieser Stelle stellt sich die Frage wie mit den nicht auf die Artikel verrechneten Frachtkosten umgegangen werden kann. Hierfür bieten sich unterschiedliche Möglichkeiten an.

Möglichkeit 1
Unter der Annahme, dass es sich bei den verbleibenden Frachtkosten um einen aus Gesamtunternehmenssicht „unwesentlichen“ Betrag handelt und ausgehend davon, dass sich Über- und Unterallokationen im Zeitablauf gegenseitig ausgleichen, besteht die erste Möglichkeit darin, die zu viel oder zu wenig verrechneten Frachtkosten erfolgswirksam in der GuV zu belassen.

Möglichkeit 2
Alternativ können die zu viel oder zu wenig verrechneten Frachtkosten über eine Umlage im Hauptbuch auf entsprechende Lagerbestandsunterkonten übertragen werden. Wie dies realisiert werden kann, ist beispielhaft im folgenden Screenshot dargestellt, der aufzeigt wie die Summe der auf den Frachtkostenkonten 600720 bis 600735 gebuchten Beträge über ein GuV-Verrechnungskonto (600740) auf ein manuell bebuchbares Bestandskonto in der Bilanz (140201) umgebucht werden.
Im Ergebnis führt diese Allokation dazu, dass im Hauptbuch auf den Bestandskonten 140201 bis 140240 ein Lagerwert in Höhe von insgesamt 122,64 mio. EUR ausgewiesen wird, der sowohl die unmittelbaren Warenkosten als auch sämtliche Frachtkosten beinhaltet. Gleichlaufend hierzu beläuft sich der Saldo auf dem GuV-Frachtkostenkonten 600720 bis 600740 insgesamt auf 0 EUR. M.a.W. alle in Rechnung gestellten direkten und indirekten Frachtkosten wurden in die Bilanz übernommen und dort aktiviert.
Ungeachtet der Attraktivität dieses Ansatzes ist zu beachten, dass eine derart aufgezeigte Umlage rein auf Hauptbuchebene durchgeführt wird, die keinerlei Rückwirkung auf die im Lagermodul ausgewiesenen Bestandswerte hat. Aufgrund dessen sollte bei Nutzung dieser Möglichkeit akribisch darauf geachtet werden, dass derartige Umlagen über eigene Lagerbestandsunterkonten durchgeführt werden.

Möglichkeit 3
Eine dritte Möglichkeit besteht darin über eine entsprechende Lagerwertkorrektur die Bestandswerte im Lager unmittelbar anzupassen. Diese Anpassung kann bspw. über die Abschluss- und Regulierungsmaske im Lager durchgeführt werden, wie im folgenden Screenshot aufgezeigt.
Ein wesentlicher Vorteil dieser Möglichkeit besteht darin, dass die Lagerbestandswerte nicht nur im Hauptbuch, sondern auch im Nebenbuch Lager angepasst werden. Diesem Vorteil steht allerdings ein deutlich höherer Aufwand bei der Ermittlung und Umsetzung der entsprechenden Lagerbestandskorrekturwerte gegenüber. (Zu klären ist in diesem Zusammenhang u.a. wie der verbleibende Frachtrestbetrag auf die verschiedenen Artikel im Lager verteilt werden soll).

Unabhängig wie mit den verbleibenden nicht-verrechneten Frachtkosten umgegangen wird, sollte der weiter oben aufgeführte automatische Frachtkostenzuschlag mindestens einmal im Jahr einer Überprüfung und ggf. Anpassung unterzogen werden um sicherzustellen, dass die verbleibenden Fracht-Über-/Unterallokationen möglichst gering gehalten werden.