Parameter zur Wiederverwendung von Nummernkreisen

08 Samstag Aug 2015

Schlagwörter

Vielleicht haben Sie sich schon einmal gefragt, welchen Zweck die Parameter „Nummer wiederverwenden“ in den Debitoren-, Kreditoren- und Projektmodulparametermasken dienen und ob man diese Parameter aktivieren soll oder nicht.

Die nachfolgenden Ausführungen zeigen Ihnen anhand eines einfachen Beispiels die Auswirkungen der Aktivierung und Nicht-Aktivierung des Debitorenrechnungsparameters auf.

Ausgangspunkt für dieses Beispiel ist die Hinterlegung des Nummernkreises „Sale_69“ für Debitorenrechnungen und „Sale_72“ für den Debitorenrechnungsbeleg. Siehe hierzu den folgenden Screenshot.

Der Nummernkreis „Sale_69“ wurde hierbei zur besseren Identifikation mit einer Konstante „CIV“ angelegt.

Ähnlich gestaltet sich die Einrichtung des Nummernkreises „Sale_72“, der mit der Konstante „INV“ angelegt wurde.

Wird nun ein Kundenauftrag fakturiert, so verwendet Dynamics AX für das Rechnungsdokument eine Nummer aus dem Nummernkreis „Sale_69“ und für den Fibu-Buchungsbeleg eine Nummer aus dem Nummernkreis „Sale_72“ wie nachfolgend dargestellt.

Wird nun der Parameter für die Wiederverwendung der Nummernkreise aktiviert, …

…, so verwendet Dynamics AX sowohl für den externen Rechnungsbeleg, als auch für den internen Fibu-Buchungsbeleg die gleiche Nummer.

Der wesentliche Vorteil der Aktivierung des Parameters für die Wiederverwendung von Nummernkreisen besteht demnach darin, dass man hierdurch eine gleichlautende Verknüpfung zwischen Dokumenten wie Rechnungen, Lieferscheinen, Gutschriften, usw. und internen Fibu-Buchungsbelegen herstellen kann, was sich speziell bei der Suche nach Belegen als hilfreich erweisen kann.

Hinweis: Die Nummernkreisparameter in den anderen Dynamics AX Modulen verhalten sich bei Aktivierung der Nummernkreiswiederverwendung analog. Aufgrund dessen kann an dieser Stelle auf weitere Ausführungen verzichtet werden.

Hinweise zur Debitoren Inkassimaske

01 Samstag Aug 2015

Posted by Ludwig Reinhard in Debitoren

≈ Hinterlasse einen Kommentar

Schlagwörter

Dynamics AX, Fälligkeitsmomentaufnahme, Inkassi

Vor kurzem hat mich ein Kollege danach gefragt, wie die in der Inkassimaske (siehe die folgende Abbildung) angezeigten Werte ermittelt werden und wie man diese Werte mit den im Standard verfügbaren Kundenberichten abgleichen kann. Da ich auf Anhieb keine Antwort parat hatte, habe ich verschiedene Tests durchgeführt, die ich in diesem Beitrag aufgenommen habe, weil ich annehme, das der ein oder andere bestimmt auf ähnliche Probleme bzw. Fragestellungen stößt.

Abschnitt 1: Berechnung der angezeigten Werte
Um die Beträge, welche in der Spalte „Saldo fälliger Beträge“ der Inkassimaske angezeigt werden nachvollziehen zu können habe ich zunächst den periodischen Verarbeitungsprozess „Fälligkeitsmomentaufnahme für Debitor“, wie in den beiden folgenden Screenshots dargestellt, für den 31. Dezember 2012, 31. Dezember 2013 und den 31. Dezember 2014 aufgerufen.

Nachdem die Berechnungen durchgelaufen waren, habe ich die Ergebnisse nach Excel exportiert und jeweils die Summe der in der Spalte „Saldo fälliger Beträge“ angezeigten Werte gebildet (siehe den folgenden Screenshot).

Interessanterweise erhielt ich immer die gleiche Gesamtsumme, so dass ich zunächst von einem Fehler im Aufruf bzw. der Verarbeitung des Berechnungsprozesses ausging.

Nachdem ich die aufgezeigten Tests allerdings in anderen System wiederholt habe und dort auf das gleiche Phänomen gestoßen bin, habe ich den Programmcode in der Klasse CustAgingSnaphot sowie die Informationen auf der folgenden TechNet Seite geprüft.

Ergebnis dieser Prüfung war, dass Dynamics AX in der Spalte „Saldo fälliger Beträge“ grundsätzlich immer den Gesamtsaldo aller aktuell offenen Kundentransaktionen anzeigt und zwar vollkommen unabhängig davon welche Auswahl im „Fälligkeit per…“ Datumsfeld beim Aufruf des periodischen Verarbeitungsprozesses getroffen wird.

Interessanterweise werden in der Inkassimaske auch solche Transaktionen angezeigt, die in zukünftigen Perioden erfasst wurden. Um dies zu verifizieren habe ich eine Freitextrechnung über 1000 USD mit den folgenden Datumswerten erfasst und gebucht.

Nach Buchung dieser Freitextrechnung habe ich den periodischen Verarbeitungsprozess erneut mit den folgenden Einstellungen gestartet…

… um in der Inkassimaske festzustellen, dass auch die Transaktion mit dem Buchungsdatum „01. Januar 2016” enthalten ist. Siehe den folgenden Screenshot.
Die letzte Prüfung, die ich in diesem Zusammenhang durchgeführt habe bestand darin den periodischen Verarbeitungsprozess mit einer anderen Zahlungsfristdefinition durchzuführen. Doch auch hier erhielt ich das gleiche Ergebnis wie zuvor.
Nach der Prüfung welche Werte in der Spalte „Saldo fälliger Beträge“ angezeigt werden, habe ich weitere Tests durchgeführt um zu prüfen welchen Einfluss die Einstellungen im Kriterienbereich und im „Fälligkeit per“ Datumsfeld haben. Siehe hierzu die folgenden fünf „Test-runs“.

Test run 1:
Zunächst habe ich den periodischen Verarbeitungsprozess mit den folgenden Einstellungen gestartet:Ergebnis test run 1:
Wie erwartet und bereits weiter oben festgestellt ist die am 01 Januar 2016 gebuchte Rechnung in der Inkassimaske enthalten und wird in der Spalte “not due / nicht fällig” angezeigt.

Test run 2:
Im Rahmen des zweiten Testlaufs habe ich den periodischen Verarbeitungsprozess mit dem Buchungskriterium „31. Januar 2016“ gestartet, da die gebuchte Freitextrechnung an diesem Tag 30 Tage dem Buchungsdatum entsprechend überfällig ist und demnach in der 30-Tage Spaltet auftauchen sollte.
Ergebnis test run 2:
Wie auch hier erwartet, wird nun der Betrag in der Spalte „30 days“ angezeigt.

Test run 3:
Im dritten Testlauf habe ich das Kriterium für die Fälligkeitsmomentaufnahme von „Buchungsdatum“ auf “Fälligkeitsdatum” abgeändert.Ergebnis test run 3:
Ergebnis war nun, dass der gebuchte Betrag in der Spalte „not due/nicht fällig“ aufgenommen wird.

Test run 4:
Anschließend habe ich den Verarbeitungslauf aufgerufen; diesmal allerdings mit dem Fälligkeitsdatum 4. März 2016.Ergebnis test run 4:
Nun erscheint der Buchungsbetrag in der Spalte „30 Tage“ da er am 4. März bis 30 Tage überfällig ist.

Test run 5:
Den letzten Testlauf habe ich schließlich mit dem Fälligkeitsdatum 04. April 2016 durchgeführt.Ergebnis test run 5:
Nun wird der Buchungsbetrag in der Spalte bis 60 Tage überfällig angezeigt, wie im folgenden Screenshot dargestellt.

Zusammenfassend kann somit an dieser Stelle als Zwischenergebnis festgehalten werden, dass das Kriterium (Buchungsdatum, Fälligkeitsdatum oder Dokumentendatum) und das „Fällig per“ Datumsfeld lediglich einen Einfluss darauf haben in welcher Fälligkeits-Spalte ein bestimmter Betrag angezeigt wird. Die beiden Feldeinstellungen haben allerdings keinerlei Einfluss darauf ob und was in der Spalte „Saldo fälliger Beträge“ aufgeführt wird, da hier grundsätzlich alle aktuell offenen Kundentransaktionen enthalten sind.

Abschnitt 2: Abstimmung der angezeigten Werte
Die Tatsache, dass die Inkassimaske alle aktuell offenen Kundentransaktionen enthält und hierbei auch in der Zukunft gebuchte Transaktionen beinhaltet erlaubt es nicht die in dieser Maske angezeigten Werte mit einem Bericht abzustimmen, welcher Kundentransaktionen zu einem bestimmten Stichtag in der Vergangenheit anzeigt.

Aufgrund dessen besteht die einzige Möglichkeit der Abstimmung darin einen der im Standard verfügbaren Berichte entweder zum aktuellen Tagesdatum oder – bei bereits in zukünftigen Perioden gebuchten Transaktionen – zu einem in der Zukunft liegenden Datum abzustimmen nach dem keine weiteren Buchungen durchgeführt wurden. Ein Beispiel für eine solche mögliche Abstimmung ist im folgenden Screenshot festgehalten.

Abschließend kann somit als Ergebnis festgehalten werden, dass die Inkassimaske grundsätzlich immer alle aktuell offenen Kundentransaktionen beinhaltet und es regelmäßig nicht möglich ist die hier angezeigten Werte mit einem Bericht abzustimmen der diese Transaktionen zu einem bestimmten Stichtag in der Vergangenheit anzeigt.

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.