Dynamics AX Debitorenmodul

Parallele Abbildung des Gesamt- und Umsatzkostenverfahrens (1)

18 Samstag Jun 2016

Posted by Ludwig Reinhard in Anlagen, Debitoren, Hauptbuch, Kreditoren, Lager

Schlagwörter

Buchungseinstellungen, GKV, Gliederung GuV, UKV

Insbesondere international agierende Unternehmen sehen sich häufig mit der Anforderung konfrontiert Finanzberichte in unterschiedlichen Strukturierungsformen erstellen zu müssen.

Häufig liegt dies darin begründet, dass ein nach lokalen Rechnungslegungsvorschriften bilanzierendes Unternehmen Finanzberichte an eine Muttergesellschaft im Ausland übermitteln muss, für die andere Rechnungslegungsvorschriften zur Anwendung kommen.

Speziell im europäischen Raum trifft man häufig auf Firmen, die lokal nach dem sog. Gesamtkostenverfahren (GKV) bilanzieren, Finanzberichte an die Muttergesellschaft im Ausland allerdings nach dem Umsatzkostenverfahren (UKV) erstellen müssen.

Ungeachtet von Bewertungsunterschieden, soll nachfolgend aufgezeigt werden, wie man Dynamics AX so parametrisieren kann um beide Verfahren parallel abzubilden.

Bevor auf Einzelheiten zu den entsprechenden Einstellungen in Dynamics AX eingegangen wird, sollen in nächsten Unterkapitel zunächst die grundlegenden Unterschiede des Gesamt- und Umsatzkostenverfahrens betrachtet werden.

A. Überblick über die grundlegenden Unterschiede zwischen dem GKV und UKV
Im deutschen Rechtsraum kann man entsprechende Regelungen zum GVK und UKV zum einen dem §275 HGB entnehmen. Eine weitere Rechtsquelle stellen EU Richtlinien dar, welche in diesem Zusammenhang von einer GuV-Strukturierung nach den „Eigenarten der Aufwendung“ (GKV) bzw. nach den „Funktionen der Aufwendung“ (UKV) sprechen.
Ungeachtet der unterschiedlichen Begrifflichkeiten werden im folgenden Screenshot die grundlegenden Unterschiede in der Gliederung der Gewinn- und Verlustrechnung (GuV) nach dem GKV und UKV vergleichend einander gegenübergestellt.

Hinweis: Die hier aufgezeigten GuV-Strukturierungen wurden der oben erwähnten EU-Richtlinie entnommen.

Der vorstehende Screenshot zeigt auf der linken Seite die grundlegende Gliederung der GuV nach dem UKV und auf der rechten Seite nach dem GKV auf. Unterschiede in der GuV-Gliederung zwischen den beiden Verfahren wurden in Gelb hervorgehoben.

Trotz der stark vereinfachten und zusammengefassten Darstellung können der obenstehenden Abbildung wesentliche Unterschiede in der Behandlung bzw. Abbildung von Bestandsgrößen und deren Änderung, sowie wesentliche Unterschiede in der Abbildung von Kosten im Personal- und Abschreibungsbereich bzw. Verwaltungs- und Vertriebsbereich entnommen werden.

Aus Finance- & Controllingsicht manifestieren sich die unterschiedlichen Strukturierungen in den Datenquellen aus denen die verschiedenen Berichtsformen (GKV und UKV) gespeist werden. D.h. während das GKV im Wesentlichen auf Daten aus der Finanzbuchhaltung zurückgreift, ist das UKV – vorausgesetzt der Kontenplan des Unternehmens ist nicht nach Funktionen strukturiert – auch auf Daten aus der Kostenrechnung angewiesen.

Im folgenden Unterkapitel werden zunächst die verwendeten Beispieldaten erläutert, bevor sich im Anschluss hieran die Darstellung der verschiedenen Buchungen – einschließlich der zugehörigen Einstellungen in Dynamics AX – und deren Auswirkungen auf die Finanzberichte des Unternehmens anschließt.

B. Beispieldaten
Um die Unterschiede in den beiden Rechnungslegungsverfahren darzustellen wurden zahlreiche Beispielbuchungen generiert, die auf dem folgenden Prozessablauf basieren:

Der hier verwendete Prozessablauf startet idealtypisch mit der Beschaffung von Rohmaterialien, die aufgrund von festgestellten Qualitätsproblemen teilweise an den Lieferanten zurückgesendet werden. Diesem Beschaffungsprozess schließen sich verschiedene Korrekturbuchungen im Lager (z.B. aufgrund von Schwund/Zerstörung) an. Anschließend werden Buchungen in den indirekten Leistungsbereichen, d.h. aus der Lohn- und Anlagenbuchhaltung dargestellt, bevor im Anschluss hieran die Abbildung des Produktionsprozesses aufgezeigt wird. Der Prozessablauf endet schließlich mit dem Verkauf der produzierten Fertigerzeugnisse an Kunden.

C. Prozessdarstellung
Die oben aufgezeigten farblich gleichartig hervorgehobenen Prozessschritte werden nachfolgend zusammengefasst in jeweils eigenen Unterkapiteln dargestellt.

C.1. Bestellung & Rücklieferung von Materialien
Der wesentliche Unterschied in der Abbildung von bestellbezogenen Materialbuchungen nach dem GKV und UKV besteht darin, dass das UKV diese Buchungen rein bilanziell, d.h. ergebnisneutral abbildet, während diese Buchungen nach dem GKV sofort und vollständig ergebniswirksam in die GuV übernommen werden. Eventuelle Veränderungen in den Materiallagerbeständen werden im GKV entsprechend über eine am Ende der Buchungsperiode durchgeführte (manuelle) Bestandsveränderungsbuchung korrigiert. Im folgenden Screenshot werden die beiden Prinzipien der Darstellung von materialbezogenen Beschaffungsbuchungen nach dem GKV und UKV nochmals stark vereinfacht einander gegenübergestellt.
Aus dem vorstehenden Screenshot kann man zum einen auf der linken Seite die ergebnisneutrale Zugangsbuchung des UKVs erkennen, welche die Materialien unmittelbar in der Bilanz auf dem entsprechenden Lagerbestandskonto – hier für Roh-, Hilfs- und Betriebsstoffe (RHB) – erfasst.

Im Gegensatz hierzu wird die Materialzugangsbuchung der RHB-Stoffe im GKV zunächst über Materialaufwandskonten in die GuV übernommen (siehe die erste Buchungszeile im obenstehenden Screenshot auf der rechten Seite). Am Monatsletzten erfolgt dann ein Vergleich der Veränderung der Bestandswerte, die über eine entsprechende Korrekturbuchung anschließend in die Bilanz übertragen wird (siehe die zweite Buchungszeile im obenstehenden Screenshot auf der rechten Seite). Für den Fall dass es – wie hier dargestellt – zu keinen weiteren Materialbewegungen im Laufe einer Buchungsperiode kommt, entsprechen sich die Buchungen des GKV und UKV, da sich die ergebniswirksamen Aufwands- und Bestandsveränderungsbuchungen gegenseitig ausgleichen.

Dem Vorgesagten kann man bereits an dieser Stelle zwei wesentliche Nachteile des GKVs entnehmen.

Ein erster Nachteil besteht darin, dass während einer Buchungsperiode bis zur Durchführung der Bestandsveränderungsbuchung kein Überblick über die finanziellen Lagerbestandswerte besteht und man sich somit finanzbuchhalterisch im „lagerbestandsmäßigen Blindflug“ befindet.
Ein zweiter Nachteil des GKVs besteht darin, dass die Buchung der Bestandsveränderung i.d.R. summarisch, d.h. nicht auf Artikelebene erfolgt. Aufgrund dessen erlaubt das GKV regelmäßig keine artikelbezogenen Auswertungen, was sich nachteilig auf Produktanalysen und hiermit zusammenhängende Prozesse auswirkt.

Unabhängig von den aufgeführten Nachteilen stellt sich an dieser Stelle die Frage, wie das GKV und UKV parallel abgebildet werden können?

Betrachtet man sich die obenstehende vergleichende Gegenüberstellung der Materialzugangsbuchungen nach dem GKV und UKV nochmals im Detail, so lässt sich die Frage dergestalt beantworten, dass über eine parallel mitlaufende Buchung der Bestandsveränderung beide Verfahren gleichzeitig abgebildet werden können. In der folgenden Darstellung ist die hier angesprochene mitlaufende Buchung der Bestandsveränderung nochmals beispielhaft dargestellt:

Ausgehend von der Annahme dass im Laufe einer Buchungsperiode zwei Materialzugangsbuchungen über 2 TEUR und 3 TEUR zu zwei unterschiedlichen Zeitpunkten durchgeführt werden, kann man aus dem vorstehenden Screenshot erkennen, dass die für das GKV erforderliche Bestandsveränderungsbuchung in der parallelen Darstellungsweise der beiden Rechnungslegungsverfahren anteilig durchgeführt wird. Mit anderen Worten, statt einer einzigen „großen“ Bestandsveränderungsbuchung am Ende der Buchungsperiode wird mit jeder Materialzugangsbuchung anteilig eine „kleine“ Bestandsveränderungsbuchung mitgebucht. Dies hat zur Folge, dass am Monatsletzten keinerlei weitergehenden (manuellen) Bestandsveränderungsbuchungen für die Abbildung des GKVs erforderlich sind.

Hinweis: Da es sich beim Materialaufwandskonto und dem Bestandsveränderungskonto um GuV-Konten handelt, deren Buchungen sich betragsmäßig gegenseitig ausgleichen, ergibt sich aufgrund dieser Zusatzbuchung kein weiterer Ergebniseffekt. Für die Darstellung des UKVs empfiehlt es sich beide Konten in der gleichen GuV-Position aufzunehmen. Siehe hierzu auch weiter unten im Detail.

Nachdem die Frage der parallelen Abbildung des GKVs und UKVs beantwortet wurde stellt sich nun die Frage, wie die Buchungseinstellungen in Dynamics AX vorgenommen werden müssen, um die erwähnten „kleinen“ Bestandsveränderungsbuchungen automatisiert mitgebucht zu bekommen. Hierfür gibt es grundsätzlich zwei Einstellmöglichkeiten:

Einstellmöglichkeit 1: Aktivierung des Kreditorenparameters „Auf Belastungskonto im Sachkonto buchen“

Die im vorstehenden Screenshot aufgezeigte Parametrisierung sorgt dafür, dass zusätzlich zur Lagerzugangsbuchung parallel eine Materialaufwands- und Bestandsveränderungsbuchung durchgeführt wird. Auf den ersten Blick erscheint dies genau die Einstellung zu sein, welche für die oben erwähnte parallele und mitlaufende Buchung des Materialaufwandes und der Bestandsveränderung sorgt.

Bei genauer Betrachtung dieser Parametrisierung stellt sich allerdings heraus, dass die Materialaufwand- und Bestandsveränderungsbuchungen nur für Zugangsbuchungen durchgeführt werden. Für den Fall das Materialien (bspw. aufgrund von Qualitätsmängeln) über die Dynamics AX Bestellmaske an Lieferanten zurückgesendet und gutgeschrieben werden, findet keine gleichlaufende automatisierte Bestandsveränderungsbuchung statt. Aufgrund dessen wird nachfolgend von dieser Einstellmöglichkeit kein Gebrauch gemacht.

Einstellmöglichkeit 2: Einrichtung eines automatischen Belastungscodes
Da der zuvor erwähnte Kreditorenparameter und die hierdurch durchgeführten Zusatzbuchungen nicht für Rücklieferungen durchgeführt werden, wird stattdessen im Folgenden von sog. automatischen Zuschlägen/-Belastungen Gebrauch gemacht.

Hierfür wird im ersten Schritt ein Belastungscode eingerichtet, welcher Buchungen auf dem Materialaufwandskonto (hier Konto 53130 für RHB-Stoffe) und auf dem zugehörigen Bestandsveränderungskonto (hier Konto 53140) durchführt. Der folgende Screenshot zeigt beispielhaft die hierfür notwendigen Einstellungen auf.

Über die Einrichtung und Hinterlegung von Artikelbelastungs-Gruppen auf Ebene der eingekauften Produkte, sowie der Einrichtung einer Auto-Belastung der folgenden Art – siehe den nächsten Screenshot – können demnach alle für die Abbildung des GKVs und UKVs erforderlichen Buchungen in Dynamics AX umgesetzt werden.

Um das eben Gesagte besser nachvollziehen zu können, werden basierend auf den dargestellten Einstellungen für Automatik-Belastungen die folgenden Beispielbuchungen in Dynamics AX erfasst und analysiert:

Zunächst wird am 01. & 02. Januar eine Lieferschein- und Rechnungsbuchung für die Beschaffung eines ersten Rohmaterials durchgeführt. Hierbei werden 1000 Stück des Materials vom Lieferanten zu einem Preis von 10 EUR / Stück geliefert und berechnet.
Am 03. & 04. Januar werden ebenfalls 1000 Stück eines zweiten Rohmaterials für 10 EUR / Stück bestellt und bestandsmäßig vereinnahmt. Aufgrund von Änderungen an den Rohmaterialpreisen berechnet der Lieferant tatsächlich allerdings 12 EUR / Stück. Der höhere Preis wird von unserem Unternehmen akzeptiert.
Bei der letzten hier dargestellten bestellbezogenen Transaktion am 05. & 06. Januar handelt es sich um eine Rücklieferung von 50 Stück des ersten Rohmaterials, welches aufgrund von Qualitätsproblemen an den Lieferanten zurückgesendet wird.

Die folgende Grafik fasst die hier beschriebenen Buchungen nochmals in zeitlicher chronologischer Reihenfolge zusammen.

Fortsetzung folgt in Teil (2)

„Schattenbuchhaltung“ in Dynamics AX am Beispiel des stillen Factorings

28 Samstag Mai 2016

Posted by Ludwig Reinhard in Debitoren

≈ Hinterlasse einen Kommentar

Schlagwörter

Factoring, Forderungsverkauf, Schattenbuchhaltung

Innerhalb dieses Beitrags möchte ihnen den Einsatz einer sog. „Schattenbuchhaltung“ in Dynamics AX im Rahmen des stillen Factorings aufzeigen. Die Besonderheit, die es im Rahmen der nachfolgenden Darstellungen zu berücksichtigen gilt, besteht darin, dass auf der einen Seite die Forderungen durch den Verkauf aus den Büchern des Unternehmens verschwinden sollen, auf der anderen Seite deren Bearbeitung allerdings nach wie vor durch das verkaufende Unternehmen sichergestellt werden muss.

Für die Darstellung, wie eine solche „Schattenbuchhaltung“ im Standard von Dynamics AX umgesetzt werden kann, wird vom folgenden beispielhaften Prozessablauf ausgegangen:

Schritt 1: Buchung Verkaufsrechnung über eine Freitextrechnung in Höhe von 100 EUR.
Schritt 2: Ausbuchung der offenen Kundenforderung und Übertrag in die Schattenbuchhaltung.
Schritt 2a: Verarbeitung einer Zuordnungsregel für die Abbildung bzw. den Ausgleich der Schattenbuchhaltung.
Schritt 3: Zahlungseingang des mit der Factoring-Gesellschaft vereinbarten Kaufpreises in Höhe von 90 EUR auf einem eigens hierfür eingerichteten Bankkonto.
Schritt 3a: Verarbeitung einer Zuordnungsregel für die Abbildung bzw. den Ausgleich der Schattenbuchhaltung.
Schritt 4: Der Kunde überweist einen Betrag in Höhe von 95 EUR auf unserem Bankkonto.
Schritt 5: Wir leiten den Zahlungseingang des Kunden in Höhe von 95 EUR an die Factoring-Gesellschaft weiter.

Die nachfolgende Abbildung fasst die verschiedenen Buchungsschritte im Prozessablauf nochmals in Form einer T-Konto Darstellung zusammen.

Hinweise:

Im der obenstehenden Abbildung sind Bilanzkonten aus der originären Buchhaltung in blau und GuV-Konten aus der originären Buchhaltung in rot dargestellt. Die Konten der Schattenbuchhaltung zeichnen sich durch die schwarze Schriftfarbe aus.
Die für die verschiedenen Buchungen verwendeten 4-stelligen Sachkonten wurden in eckigen Klammern aufgenommen.
Die Nummern neben den Buchungsbeträgen referenzieren die oben aufgeführte Prozessschrittfolge.
Die hier gewählte und nachfolgend noch im Detail erläuterte Abbildung, stellt lediglich eine mögliche Option zur Abbildung einer „Schattenbuchhaltung“ dar.

Lassen sie uns nun die in der obenstehenden Abbildung aufgezeigten Buchungen und deren Umsetzung einschließlich der hierfür notwendigen Einstellungen im Detail betrachten.

Schritt 1: Buchung Verkaufsrechnung über Freitextrechnung über 100 EUR
Im ersten Schritt wird zunächst die offene Kundenforderung über die Erfassung einer Freitextrechnung eingebucht. Über die Fakturierung werden die im nächsten Screenshot aufgezeigten Buchungen auf den Sachkonten 1400 („Forderungen Kunden“) und 5000 („Umsatzerlöse“) in der originären Buchhaltung generiert.

Schritt 2: Ausbuchung der offenen Kundenforderung und Übertrag in die Schattenbuchhaltung
Aufgrund des bestehenden Vertrages mit der Factoring-Gesellschaft wird im nächsten Schritt die offene Kundenforderung über ein Debitorenzahlungsjournal auf ein anderes „Dummy“ Kundenkonto umgebucht. Da letzteres mit einem Sammelkonto (Nr. 9499) aus dem Schattenbuchhaltungsbereich eingerichtet wurde, verschwindet die offene Forderung aus den originären Büchern unseres Unternehmens.

Im folgenden Screenshot ist das Ergebnis dieser Umbuchung nochmals farblich hervorgehoben.

Neben der farblich hervorgehobenen Umbuchung kann man aus dem obenstehenden Screenshot erkennen, dass die Bilanz und GuV der originären Buchhaltung nicht aufgehen. Insgesamt verbleibt in der originären Buchhaltung ein Betrag in Höhe von 100 EUR, dem keine entsprechende Gegenposition gegenübersteht.

Schritt 2a: Verarbeitung einer Zuordnungsregel für die Abbildung bzw. den Ausgleich der Schattenbuchhaltung
Was im vorherigen Schritt fehlt ist neben der Reduzierung des Kundensaldos eine entsprechende Aufwandsgegenbuchung. Anders ausgedrückt erfolgte die Ausbuchung der Forderung einseitig ohne entsprechendes Gegenkonto aus der originären Buchhaltung.
Um diesen Mangel zu beseitigen wurde die folgende Sachkontozuordnungsregel eingerichtet, die entsprechend zu verarbeiten ist.

Die Einrichtung der Zuordnungsregel erfolgte hierbei so, dass basierend auf den Buchungen auf dem Sachkonto 9499 aus der Schattenbuchhaltung („Quelle“), eine Buchung auf dem Aufwandskonto Nr. 6250 („Ziel“) in der originären Buchhaltung erfolgt.
Die entsprechende Gegenbuchung erfolgt hierbei auf dem Konto 9999 aus der Schattenbuchhaltung.

Wird diese Zuordnungsbuchungsregel schließlich verarbeitet, so generiert Dynamics AX die folgenden Sachkontobuchungen, …

… die dazu führen, dass Bilanz und GuV aus der originären Buchhaltung wieder aufgehen (Summe aller Buchungen aus der originären Buchhaltung = 0,00 EUR).

Schritt 3: Zahlungseingang des mit der Factoring-Gesellschaft vereinbarten Kaufpreises in Höhe von 90 EUR auf einem eigens hierfür eingerichteten Bankkonto
Im nächsten Prozessschritt wird nun der Betrag, den die Factoring-Gesellschaft für den Verkauf der Forderung überweist, vereinnahmt. Im Beispiel wurde hier von einem Zahlungsbetrag in Höhe von 90 EUR ausgegangen, der gegen das Dummy-Debitorenkonto aus der der Schattenbuchhaltung gebucht wird um dieses auszugleichen.

Die hierbei generierte Sachkontobuchung führt nun zu einer SOLL-Buchung auf dem Bankkonto aus der originären Buchhaltung und zu einer HABEN-Buchung auf dem Forderungssammelkonto Nr. 9499 aus der Schattenbuchhaltung. Siehe den folgenden Screenshot.

Ergebnis dieser buchhaltungsübergreifenden Transaktion ist, dass nun erneut Bilanz und GuV der originären Buchhaltung nicht aufgehen. Dies kann der Kontodarstellung aus dem folgenden Screenshot entnommen werden.

Schritt 3a: Verarbeitung einer Zuordnungsregel für die Abbildung bzw. den Ausgleich der Schattenbuchhaltung
Wie zuvor besteht die Lösung dieses Problems darin, dass – basierend auf den Buchungen auf dem Factoringbankkonto Nr. 1801 („Quelle“) – über eine weitere Zuordnungsregel eine Buchung auf dem Schattenbuchhaltungskonto Nr. 9999 („Ziel“) generiert wird.

Als Gegenkonto wird hierfür erneut das bereits zuvor verwendete Ertragskonto Nr. 6250 verwendet. Dies lässt sich dadurch rechtfertigen, dass über die erste Zuordnungsregel die Ausbuchung der Forderung voll aufwandswirksam durchgeführt wurde und nun über die zweite Zuordnungsregel aufgrund des Zahlungseingangs der Factoring-Gesellschaft ein entsprechender Ertrag gebildet wird. Insgesamt verbleibt auf dem Konto 6250 somit ein Aufwand in Höhe von 10 EUR, der sich aus der Differenz zwischen dem Verkaufspreis der Forderung in Höhe von 90 EUR und dem ursprünglichen Forderungswert in Höhe von 100 EUR erklärt.

Mit der Verarbeitung der zweiten Zuordnungsregel wird demzufolge – basierend auf den obenstehenden Einstellungen – die folgende Sachkontobuchung generiert.

Nach Durchführung der Buchung ergibt sich folgendes „stimmiges“ Bild in Bilanz und GuV in der originären Buchhaltung.

(Hinweis: Erfolgt die Ausbuchung der Kundenforderung in die Schattenbuchhaltung aus Schritt 2 und die Buchung des Zahlungseingangs durch die Factoring-Gesellschaft aus Schritt 3 unmittelbar nacheinander und nicht wie hier dargestellt zeitlich voneinander getrennt, so ist die Verarbeitung der ersten Zuordnungsregel (z.B. am Monatsende) für die korrekte Darstellung der verschiedenen Buchhaltungswelten – originäre Buchhaltung & Schattenbuchhaltung – ausreichend. Die Verarbeitung der zweiten Zuordnungsregel erübrigt sich in diesem Fall. Ob demnach die Einrichtung und Verarbeitung einer einzigen oder mehrere Zuordnungsregeln erforderlich ist, hängt entscheidend vom Prozessablauf im Unternehmen ab).

Schritt 4: Der Kunde überweist einen Betrag in Höhe von 95 EUR auf unserem Bankkonto
Im vorletzten Prozessschritt wird nun davon ausgegangen dass der Kunde 95 EUR überweist.

Da die Buchung dieser Zahlungsvereinnahmung über Konten der originären Buchhaltung abgebildet wird, ergibt sich keinerlei Differenz zwischen und innerhalb der Buchhaltungswelten.

Hinweis: Statt die Buchung wie obenstehend aufgezeigt unmittelbar über ein Verbindlichkeitenkonto (im Beispiel Konto 4599) abzubilden, kann alternativ auch ein Transfer-Kreditorenkonto verwendet werden, welches das gleichnamige Sachkonto im Kreditorenbuchungsprofil hinterlegt hat.

Schritt 5: Wir leiten den Zahlungseingang des Kunden in Höhe von 95 EUR an die Factoring-Gesellschaft weiter
Das Gleiche gilt für die Zahlungsweiterleitung des Kunden an die Factoring-Gesellschaft. Da auch diese ausschließlich über Sachkonten aus der originären Buchhaltung abgebildet wird, ergibt sich sowohl eine in sich geschlossene originäre Buchhaltung als auch eine in sich geschlossene Schattenbuchhaltung. Siehe die folgenden beiden Screenshots.

Zusammenfassung
Das in diesem Beitrag aufgezeigte Beispiel des Einsatzes einer Schattenbuchhaltung für die Abbildung eines stillen Factorings lässt sich auf viele weitere alternative (Schatten-) Buchungsszenarien übertragen. Wichtig für eine solche Abbildung ist die aufgezeigte Einrichtung und Verarbeitung von Sachkontozuordnungsregeln um die verschiedenen Buchhaltungswelten entsprechend ausgleichen zu können. Ob hierfür eine Zuordnungsregel ausreicht oder wie hier dargestellt mehrere Zuordnungsregeln eingerichtet und verarbeitet werden müssen hängt entscheidend vom individuellen Prozessablauf in ihrem Unternehmen ab.

Neubewertung der Fremdwährung

13 Freitag Mai 2016

Posted by Ludwig Reinhard in Debitoren, Kreditoren

≈ Hinterlasse einen Kommentar

Schlagwörter

Debitoren, Fremdwährung, Fremdwährungsneubewertung, Kreditoren

Dieser Beitrag beschäftigt sich mit der Fremdwährungsneubewertungsfunktion im Kreditorenmodul und zeigt auf welchen Einfluss unterschiedliche Parametereinstellung auf die Neubewertungsfunktion haben. Bitte beachten Sie dass die im Folgenden gemachten Ausführungen und Erläuterungen gleichermaßen für den Debitorenbereich gelten, da sich die Fremdwährungsneubewertungsfunktion im Kreditoren- und Debitorenmodul de facto nicht voneinander unterscheiden.

Die nachfolgend dargestellten Beispiele wurden alle in der sog. Dynamics AX Contoso Firma DEMF durchgeführt, welche den EURO als Buchhaltungswährung hinterlegt hat. Alle Fremdwährungsbeispielrechnungen in USD wurden in den Monaten Januar und Februar 2022 erfasst. Für diese Monate wurden die folgenden Währungswechselkurse hinterlegt.

Aufgrund der Vielzahl der Parametrisierungsmöglichkeiten wurde dieser Beitrag in vier Kapitel (Teile) unterteilt. Im ersten Teil werden unterschiedliche Einstellungen an der Neubewertungsmethode untersucht. Anschließend werden die Auswirkungen unterschiedlicher Einstellungen im Dimensionsbereich (Teil 2) und Buchungsprofilbereich (Teil 3) analysiert bevor im letzten Unterkapitel die Auswirkung unterschiedlicher Datumseinstellungen untersucht wird.

Teil 1: Neubewertung der Fremdwährung – Methode
Lassen sie uns zuerst die Auswirkung der drei verschiedenen Neubewertungsmethoden (Standard, Rechnungsdatum und Minimum) im Detail betrachten. Hierfür wurde am 1. Januar eine Fremdwährungsrechnung in Höhe von 1000 USD in Dynamics AX erfasst, als der Wechselkurs zwischen dem EUR und dem USD bei 1,00 lag.

Um den Unterschied in der Auswahl der verschiedenen Neubewertungsmethoden identifizieren zu können, werden nachfolgend drei Wechselkursregulierungen am 28. Januar bzw. 31. Januar durchgeführt. Für diese Tage waren die folgenden Wechselkurse in Dynamics AX hinterlegt.

Die erste Fremdwährungsneuberechnung wurde am 28. Januar mit der „Standardmethode“ durchgeführt, wie dies im folgenden Screenshot aufgezeigt ist.

Da es zwischen dem 01. Januar und dem 28. Januar zu einer Aufwertung des USD kam entstand ein Wechselkursverlust in Höhe von 250 EUR, dessen Ermittlung im folgenden Screenshot im Detail dargestellt ist.

Auf Sachkontoebene wird dementsprechend ein nicht realisierter Wechselkursverlust in Höhe von 250 EUR gebucht.

Unmittelbar im Anschluss an diese erste Fremdwährungsneubewertung wurde eine Fremdwährungsneubewertung mit der Methode „Rechnungsdatum“ durchgeführt. Bitte beachten sie, dass eine Änderung des Kursdatums in diesem Fall nicht möglich ist. Um dennoch einen möglichen Unterschied zur ersten Kursregulierung identifizieren zu können, wurde der Bewertungsstichtag auf den 31. Januar abgeändert.

Im Ergebnis führte die zweite Fremdwährungsneubewertung zu einer Aufhebung (Stornierung) der ersten Fremdwährungsneubewertung, die mit der Standardmethode durchgeführt wurde. Beachtenswert ist in diesem Zusammenhang, dass der hinterlegte Bewertungsstichtag das Buchungsdatum der Fremdwährungsneubewertung determiniert. Weitere Einzelheiten können den folgenden beiden Screenshots entnommen werden.

Die dritte Fremdwährungsneubewertung wurde schließlich mit der Minimum-Methode durchgeführt. Im Unterschied zu den vorherigen Neubewertungen wurde diesmal das Kursdatum auf den 31. Januar festgelegt.

Ergebnis:
In diesem Beispielfall generiert Dynamics AX keinerlei Wechselkursregulierung bzw. zugehörige Sachkontobuchung. Dies liegt darin begründet, dass die Kursänderung zum 31. Januar zu einem nicht realisierten Wechselkursgewinn führen würde und die Minimum-Methode den Ausweis und die Buchung eines solchen unrealisierten Gewinns verhindert.

Teil 2: Neubewertung der Fremdwährung – Dimensionen
Nach der Analyse der verschiedenen Neubewertungsmethoden soll in diesem Unterkapitel die Auswirkung der Dimensionsparametrierung betrachtet werden. Hierfür wurde der eingangs gebuchte Rechnungsbeleg nochmals zur besseren Nachvollziehbarkeit im folgenden Screenshot dargestellt.

Zu beachten ist in diesem Zusammenhang, dass die ursprüngliche Rechnungsbuchung mit der Finanzdimension „Business Unit 002“ durchgeführt wurde.

Vor dem Hintergrund dieser Rechnungsbuchung wurde erneut eine Fremdwährungsneuberechnung mit der Standardmethode und der Dimensionseinstellung „Kein“ gestartet.

Beim Aufruf des Fremdwährungsneubewertungsprozesses mit dieser Parametereinstellung wird zunächst die folgende Hinweismeldung eingeblendet:

Wird diese mit Yes bestätigt, so generiert Dynamics AX einen Neubewertungsbuchungsbeleg ohne jedwede Finanzdimension, wie dies im nächsten Screenshot dargestellt ist.

Um nun den Unterschied zu den anderen Dimensionseinstellungen identifizieren zu können wurde die zuvor durchgeführte Fremdwährungsneubewertung zunächst mit Hilfe der „Rechnungsdatumsmethode“ storniert. Anschließend wurde die Fremdwährungsneubewertung mit der Dimensionseinstellung „Buchung“ wiederholt.

Ergebnis:
Der nun generierte Neubewertungsbuchungsbeleg wird mit den Finanzdimensionen erstellt, die im Rahmen der Rechnungsbuchung verwendet wurden.

Um auch die dritte und letzte Dimensionseinstellung („Tabelle“) prüfen zu können wurde die vorherige Fremdwährungsneubewertung zunächst wieder mit Hilfe der Rechnungsdatumsmethode storniert und anschließend wie folgt nochmals gestartet:

Ergebnis:
Nun verwendet Dynamics AX für die Buchung der Fremdwährungsneubewertung die Finanzdimension „Business Unit 001“, die in den Kreditorenstammdaten hinterlegt ist. Siehe hierzu die folgenden beiden Screenshots.

Teil 3: Neubewertung der Fremdwährung – Buchungsprofile
Nach einer erneuten Stornierung der vorherigen Fremdwährung soll in diesem Kapitel nun die Auswirkung von geänderten Buchungsprofileinstellungen geprüft werden. Hierfür wurde die Neubewertung mit den folgenden Einstellungen erneut gestartet:

Hinweis: Im ausgewählten Buchungsprofil „FX“ wurde ein eigenes Sammelkonto (Nr. 200101) hinterlegt.

Ergebnis:
Interessanterweise wurde die Fremdwährungsneubewertung nicht auf dem im Buchungsprofil „FX“ hinterlegten Sammelkonto durchgeführt.

Dies liegt darin begründet dass die Dimensionseinstellung „Buchung“ die Buchungsprofileinstellung übersteuert. Um dies zu verifizieren wurde die Neubewertung zunächst wieder storniert und anschließend mit den folgenden Einstellungen erneut durchgeführt.

Ergebnis:
Nun wird die Fremdwährungsneubewertung über das im Buchungsprofil „FX“ hinterlegte Sammelkonto abgebildet.

Hinweis:
Die Erfassung und Buchung von unrealisierten Kursgewinnen bzw. Kursverlusten auf eigenen Sammelkonten kann Unternehmen in zweierlei Hinsicht helfen:
Zum einen darin, dass es hierdurch möglich wird das sog. Fremdwährungsexposure besser und einfacher identifizieren zu können. Hierunter ist folgendes zu verstehen; geht man davon aus, dass unrealisierte Kursgewinne bzw. Kursverluste alle auf den entsprechenden Kursgewinn-/Kursverlustkonten gegen das Verbindlichkeitensammelkonto des zugehörigen Kreditors gebucht werden, so können Kurseffekte die aufgrund konzerngruppeninterner Transaktionen entstehen nicht von konzerngruppenexternen Kurseffekten unterschieden werden, da diese Kurseffekte im Sammelkonto untergehen. Informationen über das Ausmaß potentieller Währungsrisiken sind allerdings für die Entscheidung ob und welcher Anteil dieses Risikos ggf. abgesichert werden soll von entscheidender Bedeutung.
Ein zweiter Vorteil der sich aus der Abbildung von Kursregulierungseffekten über eigene Sammelkonten ergibt besteht in einem vereinfachten Konsolidierungsprozess.

Teil 4: Neubewertung der Fremdwährung – Datumswerte
Um den Einfluss der Datumswerte in der Neubewertungsparametermaske in diesem letzten Kapitel zu untersuchen wurde zunächst eine zweite Kreditorenrechnung in Höhe von 2000 USD zum 01. Februar eingebucht. An diesem Tag lag der Wechselkurs erneut bei 1,00 EUR/USD.

Nach Buchung dieser zweiten Kreditorenrechnung wurde die Fremdwährungsneuberechnung mit den folgenden Einstellungen neu gestartet:

Ergebnis:
Für die Kursregulierung wurde der am 28. Februar gültige Wechselkurs von 0,6 EUR/USD bzw. 1,6667 USD/EUR herangezogen. Gleichzeitig kann man dem Kursregulierungsbericht entnehmen, dass lediglich die erste im Januar gebuchte Rechnung aufgrund des gewählten Bewertungsstichtags kursreguliert wurde.

Nach einer erneuten Stornierung der vorherigen Kursregulierung wurde diese mit einem geänderten Bewertungsstichtagswert durchgeführt.

Ergebnis:
Grundgrund des geänderten Bewertungsstichtags wird nun sowohl die im Januar als auch die am 01. Februar gebuchte Rechnung berücksichtigt und wechselkursreguliert.

[Rechnung 1: 1000 USD, Rechnung 2: 2000 USD => Gesamt: 3000 USD * Kurs vom 28 Februar (1,6667 USD/EUR) = 5000 EUR => 2000 EUR unrealisierter Kursverlust]

Ich hoffe sie konnten diesem Beitrag den ein oder anderen nützlichen Hinweis entnehmen und freue mich sie auch in den nächsten Beiträgen wiederzusehen.

Rechnungssuche AX2012 vs. AX7 (Teil 2)

01 Freitag Apr 2016

Posted by Ludwig Reinhard in Debitoren

≈ Hinterlasse einen Kommentar

Schlagwörter

Kunde, Rechnung, Rechnungssuche, Suche

Teil 2: Rechnungssuchfunktionen AX7
In diesem zweiten Teil zum Thema Rechnungssuche sollen die Suchfunktionen aus AX2012 mit denen in AX7 verglichen werden. Die Unterteilung der verschiedenen Unterkapitel bzw. Optionen folgt hierbei der im ersten Teil gewählten Unterteilung.

Option 1: Debitoren Rechnungserfassung Abfragemaske
Bei einer Rechnungssuche über die Rechnungserfassungsmaske in AX7 fällt zunächst auf, dass die Eingabe von Wildcards im Suchfeld scheinbar zu keinerlei Ergebnis führt. Beispiel:

Statt Rechnungen über das Suchfeld versuchen zu finden kann über die neue Filteroption nach Teilelementen der Rechnungsnummer gesucht werden.

Alternativ kann eine vergleichbare Suche auch unmittelbar über die Rechnungsspalte erfolgen, wie dies im folgenden Screenshot dargestellt ist.

Da die neuen hier aufgezeigten Filteroptionen zu vielen Suchergebnissen führen können, weil eine Suche nach der Endung einer bestimmten Rechnung (derzeit) nicht möglich ist, kann alternativ auch von der erweiterten Suchoption Gebrauch gemacht werden. Siehe hierzu den folgenden Screenshot.

Interessanterweise besteht über die erweiterte Suchmaske die Möglichkeit mit Wildcards zu arbeiten, …

… um hierdurch schnell an die gesuchte Rechnungsinformation zu gelangen.

Hinweis: Ein wesentlicher Unterschied und Vorteil im Vergleich zur Rechnungssuche über die AX2012 Maske besteht darin dass im Standardsuchfeld z.B. auch nach dem Kundennamen…

… und weiteren Kriterien gefiltert werden kann.

Option 2: Suche über Debitorenstammdatenmaske
Wie in AX2012, kann auch im neuen AX7 über die Debitorenstammdatenmaske nach Rechnungsnummern gesucht werden. Die Suche über die Debitorenstammdatenmaske läuft hierbei prinzipiell wie in AX2012 über die Erweiterung des erweiterten Suchfilters, wie dies in den folgenden Screenshots dargestellt ist.

Wie auch bei der erweiterten Suche über das Rechnungsjournal kann auch hier mit Wildcards gearbeitet werden.

Nachteilig ist – wie in AX2012 –das über eine zweite Abfrage z.B. über die Buchungsmaske die Rechnungsinformation herausgesucht werden muss.

Option 3: Suche über offene Debitorenrechnungsmaske
Wie auch in AX2012 besteht eine weitere Möglichkeit der Rechnungssuche über die offene Debitorenbuchungsmaske, die allerdings auch nur dann zu einem Suchergebnis führt, wenn die Rechnung noch nicht ausgeglichen ist. Da dies im gewählten Beispiel nicht der Fall ist, wird auch keine Rechnung gefunden.

Option 4: Suche über Inkassimaske
Die Rechnungssuche über die Inkassimaske (neue Bezeichnung „Saldenrückblick“) funktioniert wie in AX2012.

D.h. über einen erweiterten Filter ist zunächst das Kundenkonto herauszusuchen für das eine bestimmte Rechnung erfasst wurde …

… bevor in einem zweiten Filterschritt im zugehörigen Detailfenster die Rechnung schließlich identifiziert werden kann.

Option 5: Suche über Kundendienstmaske
Die Rechnungssuche über die Kundendienstmaske in AX7 läuft genau wie in AX2012 über die Eingabe einer Rechnungsnummer bzw. eines Teils der Rechnungsnummer ab, wie dies im folgenden Screenshot aufgezeigt ist.

Interessanterweise unterstützt Dynamics AX in der Kundendienstmaske die Nutzung von sog. Wildcards und findet daher schnell den zugehörigen Kunden …

… sowie die zugehörige Rechnung.

Option 6: Suche über Enterprise Kundenportal Seiten
Da das Enterprise Portal kein Bestandteil von AX7 mehr darstellt, besteht auch keine Möglichkeit mehr über diese Seite nach Rechnungen zu suchen.

Option 7: Suche über Globale Suchfunktion
Was für die Enterprise Kundenportalseite gesagt wurde gilt gleichermaßen für die globale Suchfunktion, die ebenfalls kein Bestandteil von AX7 mehr ist und demnach nicht mehr für Rechnungssuchzwecke zur Verfügung steht.

Wenn Sie weitere Tipps und Tricks für die Suche nach Kundenrechnungen haben, die auch anderen Dynamics AX Benutzern nützlich sein könnten, wäre ich Ihnen über einen kurze Hinweis über das Kommentarfeld dankbar.

Rechnungssuche AX2012 vs. AX7 (Teil 1)

01 Freitag Apr 2016

Posted by Ludwig Reinhard in Debitoren

≈ Hinterlasse einen Kommentar

Schlagwörter

Kunde, Rechnung, Rechnungssuche, Suche

Speziell Mitarbeiter aus dem Vertriebs- und Debitorenbuchhaltungsbereich sehen sich häufig mit der Situation konfrontiert schnell nach Rechnungen suchen zu müssen, um im Gespräch mit dem Kunden am Telefon eine aktuelle Auskunft erteilen zu können.

Innerhalb dieses Beitrags möchte ich Ihnen verschiedene Möglichkeiten aufzeigen wie man in Dynamics AX schnell an Rechnungs- und Zahlungsinformationen gelangen kann, um Kunden eine entsprechende Auskunft erteilen zu können.

Die nachfolgenden Ausführungen sind hierbei so gegliedert, dass zunächst verschiedene Suchmöglichkeiten in AX2012 aufgezeigt werden, die im Anschluss mit den Suchmöglichkeiten in Dynamics AX7 verglichen werden.

Hinweis: Bei der im Rahmen dieses Beitrags verwendeten Dynamics AX7 Version handelt es sich um die sog. RTW (Ready To Web) Version die am 24.02.2016 veröffentlicht wurde.

Teil 1: Rechnungssuchfunktionen AX2012
Für die folgenden Darstellungen soll nach der Kundenrechnung „CIV-000015“ gesucht werden.

Option 1: Debitoren Rechnungserfassung-Abfragemaske
Eine erste Möglichkeit nach Rechnungen zu suchen besteht über die Rechnungserfassungsmaske im Debitorenmodul.

Über eine entsprechende Filterung z.B. nach der Rechnungsnummer, kann man über die Debitorenbuchungsmaske die Zahlungsinformationen abrufen, wie dies im folgenden Screenshot dargestellt ist.

Zu beachten sind bei dieser Suche die folgenden Problemstellungen (Nachteile):

Kundenrechnungen, die über das Projektmodul generiert werden können über diese Maske nicht abgefragt werden und
eine Suche über den Kundennamen ist in der Rechnungserfassungsmaske nicht möglich.

Option 2: Suche über Debitorenstammdatenmaske
Eine zweite Möglichkeit an die gewünschten Rechnungsinformationen zu gelangen besteht über eine Suche in den Debitorenstammdaten.

Hierbei empfiehlt es sich von der erweiterten Filterfunktion Gebrauch zu machen, da über eine entsprechende Filtererweiterung unmittelbar nach Rechnungsnummern gesucht werden kann. Siehe hierzu auch die Darstellungen in den folgenden Screenshots.

Bei einer Rechnungssuche über die Debitorenmaske sind folgende Besonderheiten zu beachten:

Zum einen werden in der Maske Rechnungsinformationen nicht unmittelbar angezeigt, sondern müssen über den Aufruf der Buchungsmaske nochmals gefiltert werden.
Darüber hinaus kann es vorkommen, dass eine Suche zu keinem eindeutigen Ergebnis führt. Im folgenden Screenshot ist ein solcher Sachverhalt dargestellt, bei dem für mehr als ein Debitorenkonto eine Rechnung mit der Endung „015“ gefunden wurde.

Hinweis: Ursache für das oben dargestellte mehrdeutige Suchergebnis war eine Projektrechnung mit gleicher Endung („015“). Über eine entsprechende Erweiterung des Filters, können allerdings auch Projektrechnungen entsprechend aus der Suche ausgeschlossen werden. Siehe hierzu beispielhaft den folgenden Screenshot.

Option 3: Suche über offene Debitorenrechnungsmaske
Eine dritte Möglichkeit nach Debitorenrechnungen zu suchen besteht über die offene Debitorenrechnungsmaske.

Diese führt allerdings nur dann zu einer korrekten Filterung und Rechnungsanzeige, wenn die gesuchte Rechnung auch tatsächlich noch offen, d.h. unbezahlt ist. Im gewählten Beispiel ist dies nicht der Fall, so dass aufgrund dessen auch keine Rechnung in der Maske angezeigt wird.

Option 4: Suche über Inkassimaske
Eine weitere alternative Suchmöglichkeit besteht über die Inkassimaske im Debitorenmodul. Für eine Rechnungssuche über diese Maske gilt das Gleiche, was bereits für die Suche über die Debitorenmaske gesagt wurde; d.h. zum einen kann eine solche Suche zu mehrdeutigen Ergebnissen führen und zum anderen ist nach erfolgreicher Suche eine zweite Suchabfrage in den zugehörigen Buchungsmasken erforderlich, wie dies beispielhaft in den folgenden Screenshots dargestellt ist.

Da die gesuchte Rechnung im Beispielfall bereits beglichen ist, muss an dieser Stelle zusätzlich noch die Beleganzeige auf „offene und abgeschlossene“ abgeändert werden, um letztendlich an die Rechnungsinformation zu gelangen.

Option 5: Suche über Kundendienstmaske
Für den Fall dass in ihrem System die Retail-Funktionalitäten aktiviert wurden, kann darüber hinaus auch über die Kundendienstmaske im Callcenter-Modul nach Rechnungen gesucht werden.

Beispiel:

Im Ergebnis gelangt man über die Kundendienstmaske vergleichsweise schnell an die Kundenrechnung und kann über die standardmäßig verfügbaren Hyperlinks unmittelbar die Rechnungs- und Zahlungsinformationen abfragen.

Hinweis: Unabhängig von den Such- und Filtermöglichkeiten in der Kundendienstmaske gilt es zu beachten, dass über diese Maske ohne weitere Anpassung keine Projektrechnungen gefiltert werden können.

Option 6: Suche über Enterprise Kundenportal Seiten
Sollten Sie neben dem AX-Client auch die Enterpriseportal Funktionen nutzen, so können sie über die dort verfügbare Debitorenrechnungsmaske schnell und einfach nach Rechnungen suchen.

Ein wesentlicher Vorteil, der sich aus der Suche über das Enterpriseportal ergibt besteht in der Vielzahl der Filtermöglichkeiten wie im folgenden Screenshot dargestellt.

Hinweis: Auch bei einer Rechnungssuche über das Enterprise Portal gilt es zu beachten, dass in der im vorherigen Screenshot aufgezeigten Maske lediglich eine Filterung nach „gewöhnlichen“ Kundenrechnungen erfolgt. Für eine Suche nach Projektrechnungen ist die entsprechende Portalseite für Projektrechnungen zu nutzen.

Option 7: Suche über Globale Suchfunktion
Die letzte hier aufgezeigte Rechnungssuchfunktion besteht in der Nutzung der sog. globalen Suchfunktion. Über eine entsprechende Eingabe der Rechnungsnummer, Teile hiervon, des Kundennamen, usw. werden die Suchergebnisse unmittelbar im Dynamics AX-Client angezeigt und erlauben dem Anwender über die verfügbaren Hyperlinks eine schnelle Navigation zur Rechnung. Beispiel:

Um die globale Suchfunktion nutzen zu können ist diese über das Systemverwaltungsmodul zunächst individuell einzurichten.

Die hierbei auswählbaren Abfragen müssen alle die „Searchable“ Eigenschaft ausgewählt haben und dürfen keine „Best-Practice Verletzungen“ aufweisen.

Darüber hinaus ist eine entsprechende Konfiguration und periodische Verarbeitung des globalen Suchlaufes erforderlich.

Weitere Informationen zur globalen Suchfunktion können Sie den folgenden Seiten entnehmen: Seite 1, Seite 2.

Bereinigung von Kleinsalden – Ergänzung

06 Sonntag Mrz 2016

Posted by Ludwig Reinhard in Debitoren

≈ Hinterlasse einen Kommentar

Schlagwörter

Ausgleich, Dynamics AX, Kunden, Zahlungen

In einem vorherigen Beitrag habe ich Ihnen aufgezeigt wie Kleinsalden über die Einrichtung eines Debitorenpools und einer entsprechenden Filterung in der Inkassimaske ausgebucht werden können. Hier nochmals die zugehörigen Screenshots zur Erinnerung.

Problem
Was in dem vorherigen Beitrag nicht im Detail angesprochen wurde ist ein Problem, das immer dann zu Tage tritt, wenn negative Kleinsalden ausgebucht werden sollen. In diesen Fällen generiert Dynamics AX die folgende Fehlermeldung und unterbricht den Ausbuchungsvorgang.

Ursächlich für diese Fehlermeldung ist die Aktivierung des folgenden Debitorenparameters, welcher sicherstellt, dass bei der Ausbuchung der offenen Position eine entsprechende Steuerkorrektur durchgeführt wird (siehe den folgenden Screenshot).

Hinweis: Ist der Parameter „Separate Mehrwertsteuer“ nicht aktiviert, so wird die Fehlermeldung nicht generiert und die Abschreibung der offenen Posten kann gebucht werden. Eine Deaktivierung des Parameters ist allerdings keine Option, da eine Steuerkorrektur regelmäßig erforderlich ist.

Neben der aufgezeigten Problematik der Abschreibung negativer Debitorensalden tritt die oben erwähnte Fehlermeldung auch dann auf, wenn auf den ersten Blick alles in Ordnung erscheint. Beispiel:

In solchen Fällen liegt die Ursache für die Fehlermeldung zumeist in dem Umstand begründet, dass der Gesamtsaldo des Debitors einen negativen Betrag beinhaltet.

Lösungsmöglichkeit 1
Um die aufgezeigten Probleme zu beheben bestehen grundsätzlich zwei Möglichkeiten. Die erste Möglichkeit den Fehler zu vermeiden besteht darin, die in den folgenden beiden Screenshots aufgezeigten Codeanpassungen umzusetzen.

Im Ergebnis lässt sich nun zum einen der negative Debitorensaldo – einschließlich der zugehörigen Steuerkorrektur – ausbuchen.

Zum anderen können durch die Codeanpassung auch solche Kleinsalden ausgebucht werden, die Gutschriftspositionen beinhalten. Beispiel:

Hinweis: Wie man aus dem obenstehenden Screenshot erkennen kann, fasst Dynamics AX die zugehörigen Sachkontobuchungen zusammen und bucht diese nicht einzeln aus. Für den Fall dass die auszubuchenden Positionen mit unterschiedlichen Steuersätzen gebucht wurden, erfolgt eine entsprechende anteilige Steuerkorrektur entsprechenden verschiedenen Steuersätzen.

Lösungsmöglichkeit 2
Für den Fall dass keine Codeanpassung erwünscht ist bzw. für den Fall dass Sie mit älteren Dynamics AX Versionen arbeiten, in denen die Inkassifunktion noch nicht zur Verfügung steht, bietet sich die folgende alternative Vorgehensweise zur Ausbuchung von Kleinsalden an, auf die mich ein Kollege aufmerksam gemacht hat.

Schritt 1: Anlage eines neuen Debitoren Zahlungserfassungsjournals

Schritt 2: Erstellung eines Zahlungsvorschlags

Schritt 3: Filterung der auszubuchenden Kleinbeträge

Hinweise:
Die Selektion der auszubuchenden Beträge findet hier über ein SQL statement statt. Siehe hierzu auch die Hinweis auf der folgenden Seite.
Im Gegensatz zur weiter oben aufgezeigten Lösungsmöglichkeit 1 wird aufgrund der hier verwendeten Abfrage nicht auf den Gesamtsaldo des Debitors abgestellt, sondern auf Einzelbuchungen.

Schritt 4: Änderung der Zahlungsmethode
Um sicherstellen zu können dass die hier durchgeführten Ausbuchungen nicht gegen ein Zahlungs-(Bank-)Konto durchgeführt werden, empfiehlt sich die Einrichtung einer eigenen Zahlungsmethode mit einem entsprechend hinterlegten Abschreibungskonto (im Beispiel Konto 618170). Für die auszubuchenden Transaktionen ist demnach die Zahlungsmethode in der Zahlungsvorschlagsmaske entsprechend abzuändern, wie dies im folgenden Screenshot dargestellt ist.

Schritt 5: Auswahl Steuergruppen
Um sicherstellen zu können dass die entsprechenden Ausbuchungen auf den Debitorenkonten mit einer steuerlichen Wertkorrektur durchgeführt werden ist schließlich im letzten Schritt vor der Journalbuchung sicherzustellen, dass die entsprechenden Mehrwertsteuergruppen und Artikelmehrwertsteuergruppen hinterlegt werden.

Wie kann man Kleinsalden auf Kundenkonten vermeiden?

02 Dienstag Feb 2016

Posted by Ludwig Reinhard in Debitoren

≈ Hinterlasse einen Kommentar

Schlagwörter

Ausgleich, Dynamics AX, Kunden, Zahlungen

Dieser Beitrag befasst sich damit, wie mit Kleinsalden auf Kundenkonten umgegangen werden kann, bzw. wie sich diese vermeiden lassen.

Hinweis: Die nachfolgenden Ausführungen haben keine Bewandtnis in Dynamics AX Systemen in denen der Debitorenparameter „automatischer Ausgleich“ aktiviert ist.

Beispiel: Nach Buchung einer Freitextrechnung über 5000 $ kann man in der Debitorenbuchungsmaske den folgenden Eintrag erkennen.

Nach Fälligkeit der offenen Position überweist der Kunde lediglich 4995 $, d.h. er zahlt 5 $ zu wenig. Die Kundenzahlung wird hierbei über ein Kundenzahlungserfassungsjournal erfasst und mit der offenen Position für den Ausgleich markiert wie dies in den folgenden beiden Screenshots dargestellt ist.

Hinweis: Anders als im vorstehenden Screenshot aufgezeigt kann der auszugleichende Betrag von 5000 $ auch auf 4995 $ reduziert werden, was allerdings nichts am Ergebnis ändert. Wird diese Reduktion nicht vorgenommen – wie im aufgezeigten Beispiel – so erscheint beim Schließen der Maske die folgende Meldung:

Nach Buchung der Kundenzahlung verbleibt schließlich aufgrund der Unterzahlung von 5 $ ein gleichlautender Saldo auf dem Kundenkonto. Der folgende Screenshot zeigt dies nochmals auf.

Wenn Sie solchen offenen Kleinbeträgen z.B. aus Kostengründen nicht nachgehen möchten, dann stellt sich zum einen die Frage wie mit solchen Kleinsalden umgegangen werden kann, d.h. wie diese schnell und effizient bereinigt werden können. Zum anderen stellt sich in diesem Zusammenhang die Frage, wie sich solche Kleinsalden von vorne herein vermeiden lassen.

Bereinigung von Kleinsalden
Eine Möglichkeit Kleinsalden auf Kundenkonten zu bereinigen besteht darin, einen Debitorenpool im Debitorenmodul anzulegen und die hierüber identifizierten Beträge abzuschreiben. Die folgenden Screenshots zeigen Ihnen diese Vorgehensweise beispielhaft auf.

Schritt 1: Einrichtung eines Debitorenpools mit Filterung auf Kleinsalden

Schritt 2: Verarbeitung der periodischen Debitorenfunktion “Fälligkeitsmomentaufnahme für Debitor“

Schritt 3: Abschreibung der über den Debitorenpool identifizierten Kleinsalden

Vermeidung von Kleinsalden
Um Kleinsalden auf Kundenkonten gänzlich zu vermeiden kann von der vollständigen Ausgleichsfunktion Gebrauch gemacht werden, die standardmäßig für Dynamics AX Unternehmen in Deutschland, Österreich und der Schweiz zur Verfügung steht. Um diese Funktion auch in anderen Ländern nutzen zu können, sind einfach die Länderschlüssel in der Maske „CustOpenTrans“ zu löschen bzw. alternativ weitere Länderschlüssel hinzuzufügen.

Das folgende Beispiel zeigt die Auswirkung dieser Systemmodifikation auf.

Beispiel: Für den gleichen Kunden der bereits im eingangs dargestellten Beispiel verwendet wurde, wird erneut eine Freitextrechnung erfasst; diesmal allerdings in Höhe von 6000 $. Des Weiteren wird angenommen, dass der Kunde 10 $ zu wenig zahlt, d.h. lediglich 5990 $ bei Fälligkeit der Rechnung überweist. Wie zuvor wird auch in diesem Beispiel die Kundenzahlung über ein Kundenzahlungsjournal erfasst und mit der offenen Position markiert.

Im Unterschied zum vorherigen Beispiel wird nun allerdings der durch die Anpassungsprogrammierung neu hinzugekommene Parameter „vollständiger Ausgleich“ ausgewählt. Das Ergebnis dieser Parameterauswahl ist, dass die 10 $ Unterzahlung als gewährter Debitorenskonto klassifiziert und gebucht werden. (Hinweis: Das für diese Buchung verwendete Sachkonto stammt hierbei aus den im Hauptbuch eingestellten Automatikkonten).

Nachdem die Buchung der Kundenzahlung derart durchgeführt wurde, kann man schließlich auf dem Kundenkonto neben der Rechnungs- und Zahlungsbuchung eine Skontobuchung in Höhe der akzeptierten Unterzahlung des Kunden erkennen.

Abschließender Hinweis: Die hier dargestellte vollständige Ausgleichsfunktion ist auch auf Kreditorenseite verfügbar und kann durch eine Modifikation der VendOpenTrans Maske allgemein verfügbar gemacht 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.

Dynamics 365FO/AX Finance & Controlling

Kategorien-Archiv: Debitoren

Parallele Abbildung des Gesamt- und Umsatzkostenverfahrens (1)

„Schattenbuchhaltung“ in Dynamics AX am Beispiel des stillen Factorings

Neubewertung der Fremdwährung

Rechnungssuche AX2012 vs. AX7 (Teil 2)

Rechnungssuche AX2012 vs. AX7 (Teil 1)

Bereinigung von Kleinsalden – Ergänzung

Wie kann man Kleinsalden auf Kundenkonten vermeiden?

Hinweise zur Debitoren Inkassimaske

Trennung von Auftragserlösen und Rücklieferungsauftragserlösminderungen