Kategorien-Archiv: Debitoren

Dynamics AX Debitorenmodul

„Schattenbuchhaltung“ in Dynamics AX am Beispiel des stillen Factorings

28 Samstag Mai 2016

Posted by in Debitoren

≈ Hinterlasse einen Kommentar

Schlagwörter

, ,

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.
DE_126_0010
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.
DE_126_0015

 

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.
DE_126_0020
Im folgenden Screenshot ist das Ergebnis dieser Umbuchung nochmals farblich hervorgehoben.
DE_126_0025
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.
DE_126_0030Die entsprechende Gegenbuchung erfolgt hierbei auf dem Konto 9999 aus der Schattenbuchhaltung.
DE_126_0035
Wird diese Zuordnungsbuchungsregel schließlich verarbeitet, so generiert Dynamics AX die folgenden Sachkontobuchungen, …
DE_126_0040
… 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).
DE_126_0045

 

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.
DE_126_0050
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.
DE_126_0060

 

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.
DE_126_0065
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.
DE_126_0070
Mit der Verarbeitung der zweiten Zuordnungsregel wird demzufolge – basierend auf den obenstehenden Einstellungen – die folgende Sachkontobuchung generiert.
DE_126_0075
Nach Durchführung der Buchung ergibt sich folgendes „stimmiges“ Bild in Bilanz und GuV in der originären Buchhaltung.
DE_126_0080
(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.
DE_126_0085
Da die Buchung dieser Zahlungsvereinnahmung über Konten der originären Buchhaltung abgebildet wird, ergibt sich keinerlei Differenz zwischen und innerhalb der Buchhaltungswelten.
DE_126_0090
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.
DE_126_0095 DE_126_0100

 

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 in Debitoren, Kreditoren

≈ Hinterlasse einen Kommentar

Schlagwörter

, , ,

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.
DE_121_0005
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.
DE_121_0010

 

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.
DE_121_0020
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.
DE_121_0015
Die erste Fremdwährungsneuberechnung wurde am 28. Januar mit der „Standardmethode“ durchgeführt, wie dies im folgenden Screenshot aufgezeigt ist.
DE_121_0025
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.
DE_121_0030
Auf Sachkontoebene wird dementsprechend ein nicht realisierter Wechselkursverlust in Höhe von 250 EUR gebucht.
DE_121_0035

 

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.
DE_121_0040
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.
DE_121_0045 DE_121_0050

 

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.
DE_121_0055
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.
DE_121_0060
DE_121_0065

 

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.
DE_121_0070
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.
DE_121_0075
Beim Aufruf des Fremdwährungsneubewertungsprozesses mit dieser Parametereinstellung wird zunächst die folgende Hinweismeldung eingeblendet:
DE_121_0080
Wird diese mit Yes bestätigt, so generiert Dynamics AX einen Neubewertungsbuchungsbeleg ohne jedwede Finanzdimension, wie dies im nächsten Screenshot dargestellt ist.
DE_121_0085

 

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.
DE_121_0090
Ergebnis:
Der nun generierte Neubewertungsbuchungsbeleg wird mit den Finanzdimensionen erstellt, die im Rahmen der Rechnungsbuchung verwendet wurden.
DE_121_0095

 

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:
DE_121_0100
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.
DE_121_0105
DE_121_0110

 

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:
DE_121_0115
Hinweis: Im ausgewählten Buchungsprofil „FX“ wurde ein eigenes Sammelkonto (Nr. 200101) hinterlegt.
DE_121_0120
Ergebnis:
Interessanterweise wurde die Fremdwährungsneubewertung nicht auf dem im Buchungsprofil „FX“ hinterlegten Sammelkonto durchgeführt.
DE_121_0125
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.
DE_121_0130
Ergebnis:
Nun wird die Fremdwährungsneubewertung über das im Buchungsprofil „FX“ hinterlegte Sammelkonto abgebildet.
DE_121_0135
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.
DE_121_0140 DE_121_0145
Nach Buchung dieser zweiten Kreditorenrechnung wurde die Fremdwährungsneuberechnung mit den folgenden Einstellungen neu gestartet:
DE_121_0150
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.
DE_121_0155
Nach einer erneuten Stornierung der vorherigen Kursregulierung wurde diese mit einem geänderten Bewertungsstichtagswert durchgeführt.
DE_121_0160
Ergebnis:
Grundgrund des geänderten Bewertungsstichtags wird nun sowohl die im Januar als auch die am 01. Februar gebuchte Rechnung berücksichtigt und wechselkursreguliert.
DE_121_0165
[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 in Debitoren

≈ Hinterlasse einen Kommentar

Schlagwörter

, , ,

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:
DE_120_0100
Statt Rechnungen über das Suchfeld versuchen zu finden kann über die neue Filteroption nach Teilelementen der Rechnungsnummer gesucht werden.
DE_120_0105
Alternativ kann eine vergleichbare Suche auch unmittelbar über die Rechnungsspalte erfolgen, wie dies im folgenden Screenshot dargestellt ist.
DE_120_0110
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.
DE_120_0115
Interessanterweise besteht über die erweiterte Suchmaske die Möglichkeit mit Wildcards zu arbeiten, …
DE_120_0120
… um hierdurch schnell an die gesuchte Rechnungsinformation zu gelangen.
DE_120_0125
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…
DE_120_0130
… und weiteren Kriterien gefiltert werden kann.
DE_120_0131

 

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.
DE_120_0135
DE_120_0140
Wie auch bei der erweiterten Suche über das Rechnungsjournal kann auch hier mit Wildcards gearbeitet werden.
DE_120_0145
Nachteilig ist – wie in AX2012 –das über eine zweite Abfrage z.B. über die Buchungsmaske die Rechnungsinformation herausgesucht werden muss.
DE_120_0150

 

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.
DE_120_0155

 

Option 4: Suche über Inkassimaske
Die Rechnungssuche über die Inkassimaske (neue Bezeichnung „Saldenrückblick“) funktioniert wie in AX2012.
DE_120_0160
D.h. über einen erweiterten Filter ist zunächst das Kundenkonto herauszusuchen für das eine bestimmte Rechnung erfasst wurde …
DE_120_0165
… bevor in einem zweiten Filterschritt im zugehörigen Detailfenster die Rechnung schließlich identifiziert werden kann.
DE_120_0170

 

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.
DE_120_0175
Interessanterweise unterstützt Dynamics AX in der Kundendienstmaske die Nutzung von sog. Wildcards und findet daher schnell den zugehörigen Kunden …
DE_120_0180
… sowie die zugehörige Rechnung.
DE_120_0185

 

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 in Debitoren

≈ Hinterlasse einen Kommentar

Schlagwörter

, , ,

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.
DE_120_0005
Über eine entsprechende Filterung z.B. nach der Rechnungsnummer, kann man über die Debitorenbuchungsmaske die Zahlungsinformationen abrufen, wie dies im folgenden Screenshot dargestellt ist.
DE_120_0010
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.
DE_120_0015
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.
DE_120_0020 DE_120_0025 DE_120_0030
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.

DE_120_0035
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.
DE_120_0036

 

Option 3: Suche über offene Debitorenrechnungsmaske
Eine dritte Möglichkeit nach Debitorenrechnungen zu suchen besteht über die offene Debitorenrechnungsmaske.
DE_120_0040
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.
DE_120_0045

 

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.
DE_120_0050DE_120_0055
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.
DE_120_0060

 

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.
DE_120_0065
Beispiel:
DE_120_0070
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.
DE_120_0075
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.
DE_120_0076
Ein wesentlicher Vorteil, der sich aus der Suche über das Enterpriseportal ergibt besteht in der Vielzahl der Filtermöglichkeiten wie im folgenden Screenshot dargestellt.
DE_120_0077
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:
DE_120_0080
Um die globale Suchfunktion nutzen zu können ist diese über das Systemverwaltungsmodul zunächst individuell einzurichten.
DE_120_0085
Die hierbei auswählbaren Abfragen müssen alle die „Searchable“ Eigenschaft ausgewählt haben und dürfen keine „Best-Practice Verletzungen“ aufweisen.
DE_120_0090
Darüber hinaus ist eine entsprechende Konfiguration und periodische Verarbeitung des globalen Suchlaufes erforderlich.
DE_120_0095
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 in Debitoren

≈ Hinterlasse einen Kommentar

Schlagwörter

, , ,

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.
DE_50_0030DE_50_0035


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.
DE_99_0005
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).
DE_99_0010
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:
DE_99_0015
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.
DE_99_0020

 

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.
DE_99_0025
DE_99_0030
Im Ergebnis lässt sich nun zum einen der negative Debitorensaldo – einschließlich der zugehörigen Steuerkorrektur – ausbuchen.
DE_99_0035
DE_99_0040
Zum anderen können durch die Codeanpassung auch solche Kleinsalden ausgebucht werden, die Gutschriftspositionen beinhalten. Beispiel:
DE_99_0045 DE_99_0050
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
DE_99_0055

Schritt 2: Erstellung eines Zahlungsvorschlags
DE_99_0060

Schritt 3: Filterung der auszubuchenden Kleinbeträge
DE_99_0065
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.
DE_99_0070

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.
DE_99_0075

Wie kann man Kleinsalden auf Kundenkonten vermeiden?

02 Dienstag Feb 2016

Posted by in Debitoren

≈ Hinterlasse einen Kommentar

Schlagwörter

, , ,

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.
DE_50_0005
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.
DE_50_0010 DE_50_0015
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:
DE_50_0020
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
DE_50_0030

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

Schritt 3: Abschreibung der über den Debitorenpool identifizierten Kleinsalden
DE_50_0035

 

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.
DE_50_0040
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.
DE_50_0045
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).
DE_50_0050
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.
DE_50_0055

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 in Debitoren

≈ Hinterlasse einen Kommentar

Schlagwörter

, ,

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.
DE_26_0000


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.
DE_26_0001 DE_26_0002
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).
DE_26_0003
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.
DE_26_0004
Nach Buchung dieser Freitextrechnung habe ich den periodischen Verarbeitungsprozess erneut mit den folgenden Einstellungen gestartet…
DE_26_0005
… um in der Inkassimaske festzustellen, dass auch die Transaktion mit dem Buchungsdatum „01. Januar 2016” enthalten ist. Siehe den folgenden Screenshot.
DE_26_0006Die letzte Prüfung, die ich in diesem Zusammenhang durchgeführt habe bestand darin den periodischen Verarbeitungsprozess mit einer anderen Zahlungsfristdefinition durchzuführen. DE_26_0007Doch auch hier erhielt ich das gleiche Ergebnis wie zuvor. DE_26_0007a
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:DE_26_0008Ergebnis 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. DE_26_0009

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.
DE_26_0010Ergebnis test run 2:
Wie auch hier erwartet, wird nun der Betrag in der Spalte „30 days“ angezeigt.DE_26_0011

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

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

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

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.DE_26_0018

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 in Debitoren

≈ Hinterlasse einen Kommentar

Schlagwörter

, ,

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. DE_27_0010
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.
DE_27_0015
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.
DE_27_0020

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.DE_27_0040 DE_27_0045
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.
DE_27_0050 DE_27_0055
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.
DE_27_0060

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.
DE_27_0075
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.
DE_27_0065
DE_27_0070
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.
DE_27_0080
Dieses Konto wird entsprechend bei der Buchung der Kundengutschrift verwendet, wie dies in Fortsetzung des gewählten Beispiels im nächsten Screenshot dargestellt ist.
DE_27_0085

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.
DE_27_0105
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.
DE_27_0130_neu

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.DE_27_0155
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.).DE_27_0165
Mit der Buchung der Rücklieferungsgutschrift hat Dynamics AX schließlich die folgenden Sachkontobuchungen durchgeführt:DE_27_0170
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:
DE_27_0175

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.