• Home
  • Über mich
  • Kontakt
  • Englisch
  • FAQs

Microsoft BizApps Finance & Controlling

Microsoft BizApps Finance & Controlling

Kategorien-Archiv: Kreditoren

Dynamics AX Kreditorenmodul

Doppelte Rechnungserfassungen

08 Mittwoch Jun 2016

Posted by Ludwig Reinhard in Kreditoren

≈ Ein Kommentar

Schlagwörter

Kreditorenrechnungserfassung, Kreditorenzahlungen, Vermeidung von Doppelzahlungen

Eine grundsätzliche Anforderung bei der Erfassung und Zahlung von Kreditorenrechnungen besteht darin sicherzustellen, dass Kreditorenrechnungen nur einmal erfasst und gezahlt werden. Was sich zunächst wie eine Binsenweisheit anhört, kann in der Praxis zu zahlreichen Problemstellungen führen, vor allem dann, wenn es um die Buchung und Zahlung von sog. Aufwandsrechnungen geht, die nicht über Bestellungen systemseitig nachgehalten werden.

Betrachten wir uns beispielhaft einmal einen Vorgang bei dem ein Mitarbeiter aus der Marketingabteilung Werbebroschüren für die nächste Messe bestellt. Da es sich bei der Bestellung um Verbrauchsmaterial handelt, das einen vergleichsweise kleinen Bestellwert hat, wird die Bestellung der Einfachheit halber unmittelbar per Email an den Lieferanten aufgegeben ohne vom Bestellanforderungs-/Bestellprozess Gebrauch zu machen.

Legt nun der Lieferant eine Rechnung der Sendung bei und verschickt diese nochmals an die Buchhaltung als Email, so kann es vorkommen, dass die gleiche Rechnung mehrfach im Unternehmen eingeht.

Gehen wir nun davon aus, dass der Mitarbeiter im Wareneingang die der Sendung beigefügte Rechnung an den Mitarbeiter aus der Marketingabteilung weiterleitet, der die Broschüren bestellt hat. Nach erfolgter (manueller) Prüfung und Freigabe der Rechnung wird diese anschließend an die Kreditorenbuchhaltung weitergegeben, wo sie zum ersten Mal im ERP-System unter der Nummer „INV1234“ erfasst wird.

Nehmen wir weiter an, dass die Rechnung, die per Email bei einem anderen Mitarbeiter der Kreditorenabteilung einging an den Marketingleiter zur Prüfung und Freigabe weitergeleitet wird. Stimmt sich in dem Fall der Marketingleiter nicht mit seinem Kollegen ab der die Broschüren bestellt hat, so kann es vorkommen dass die Rechnung ein zweites Mal genehmigt und im System erfasst wird bspw. aufgrund eines Tippfehlers bei der Eingabe unter der Nummer „INV 1234“.

Bitte beachten sie dass die zweite Eingabe mit einem Leerzeichen vor der Rechnungsnummer eingegeben wird, so dass es sich systemtechnisch um eine andere Rechnung handelt, weil sich die Nummern „INV1234“ und „INV 1234“ aufgrund des Leerzeichens voneinander unterscheiden.

Basierend auf dieser Darstellung stellen sich drei grundlegende Fragen:

  1. Wie kann man herausfinden ob Rechnungen mehrfach eingegeben wurden?
  2. Wie kann man verhindern eine Rechnung mehrfach zu zahlen? und
  3. Wie kann man mehrfache Rechnungserfassungen vollständig vermeiden?

In den folgenden Unterkapiteln sollen diese Fragestellungen mit Bezug auf Dynamics AX Standardfunktionen beantwortet werden.

 

Frage 1: Wie kann man herausfinden ob Rechnungen mehrfach eingegeben wurden?
Um die nachfolgenden Ausführungen besser nachverfolgen zu können ist es zunächst wichtig zu berücksichtigen, dass der Kreditorenparameter zur Prüfung der Eingabe doppelter Kreditorenrechnungsnummern aktiviert ist.
DE_125_0001
Vor dem Hintergrund dieser Einstellungen werden anschließend zwei Rechnungen über ein Kreditorenrechnungsjournal mit den Rechnungsnummern “INV1234” und “INV 1234” erfasst. Bitte beachten sie, dass die zweite Rechnung – aufgrund eines Tippfehlers – mit einem Leerzeichen vor der Rechnungsnummer erfasst wurde. Aufgrund dieses Leerzeichens erkennt Dynamics AX nicht, dass es sich um die gleiche Rechnungsnummer handelt und lässt die Buchung beider Rechnungen anstandslos zu.
DE_125_0025
Lassen sie uns nun das Beispiel dahingehend erweitern, dass zwei zusätzliche Rechnungen über das Kreditoren Rechnungsworkbench erfasst werden. Um die Kreditorenrechnungsprüfung zu „überlisten“ werden diesmal die Rechnungen mit einem Punkt vor bzw. nach der Rechnungsnummer erfasst, wie dies im folgenden Screenshot dargestellt ist.
DE_125_0030Aufgrund der aus Demonstrationsgründen absichtlich vorgenommenen Eingabefehler wurde die Rechnung letztendlich viermal im System erfasst.
DE_125_0035
Lassen Sie uns nun mit Hilfe der Überwachungsrichtlinienfunktion im Überwachungsworkbench Modul versuchen die doppelten Rechnungen zu identifizieren. (In AX2012 kann die nachfolgend beschriebene Standardfunktion im Modul „Compliance und interne Kontrollen“ gefunden werden).

Das erste was im Rahmen der Einstellung von Überwachungsrichtlinien benötigt wird ist die Einrichtung eines Richtlinienregeltypen, der auf eine dahinterstehende Abfrage – im Beispiel „Kreditorenrechnung“ – verweist. Darüber hinaus ist über den Abfragetyp zu definieren, dass mit Hilfe dieser Überwachungsrichtlinie nach doppelten Kreditorenrechnungen gesucht werden soll. Schließlich ist in der letzten Spalte zu definieren anhand welches Datums eine entsprechende Überprüfung eingegrenzt werden kann. Weitergehende Informationen zu dieser Einrichtung und im speziellen zu den Abfragetypen können der folgenden TechNet Seite entnommen werden.
DE_125_0005
Nach Einrichtung des Richtlinienregeltypen ist im zweiten Schritt eine Überwachungsrichtlinie einzurichten, die auf die Organisationseinheit verweist in der die doppelte Rechnungssuche durchgeführt werden soll.
DE_125_0010
Der dritte und wichtigste Einrichtungsschritt besteht in der Spezifikation der sog. Überwachungsrichtlinienregel.
DE_125_0015
Im Rahmen dieser Spezifikation ist über die Einrichtung von Filterkriterien zu definieren woran eine potentiell doppelt erfasste Rechnung erkannt wird. In meinem Beispiel wurde hierfür bestimmt, dass dies anhand des Rechnungsdatums, des Rechnungsbetrags und des Kreditorenrechnungskontos erfolgt.
DE_125_0020
Bitte beachten sie dass die Rechnungsnummer regelmäßig nicht als Auswahlkriterium verwendet werden kann, da sich die Rechnungsnummern wie weiter oben aufgezeigt aufgrund des Kreditorenprüfparameters systemtechnisch voneinander unterscheiden.

Sobald die Überwachungsrichtlinie eingerichtet ist, muss über einen entsprechenden Batchjob festgelegt werden innerhalb welches Zeitintervalls nach doppelten Rechnungen gesucht werden soll.
DE_125_0050
Findet die Batchjob Suche entsprechend doppelte Rechnungen, so wird automatisiert ein „Ticket“ in Form einer Überwachungsanfrage angelegt, welche die gefundenen potentiell doppelten Datensätze auflistet. Diese Überwachungsanfrage kann anschließend vom zuständigen Sachbearbeiter überprüft und weiterbearbeitet werden. Siehe hier auch den folgenden Screenshot.

Hinweis: Voraussetzung für die automatisierte Anlage einer Anfrage ist die Einrichtung einer Überwachungsanfragekategorie im Organisationsverwaltungsmodul. Einzelheiten hierzu können der folgenden TechNet Seite entnommen werden.
DE_125_0055
Wenn sie sich die im obenstehenden Screenshot identifizierten doppelten Rechnungen im Detail betrachten, so fällt auf, dass Dynamics AX lediglich die Rechnungen identifiziert hat, die mit einem Punkt in der Rechnungsnummer über das Kreditoren Rechnungsworkbench erfasst wurden.

Rechnungen, die hingegen über Kreditorenrechnungsjournale in Dynamics AX eingegeben wurden, konnten hingegen nicht von der Überwachungsrichtlinie als potentiell doppelte Rechnungen identifiziert werden.

Die Ursache für dieses Systemverhalten liegt im Dynamics AX Policy Framework begründet, welches lediglich solche Rechnungen auf doppelte Werte hin prüft, die – unter anderem – einen SourceDocument Header und eine SourceDocumentLine hinterlegt haben. Da dies nur für solche Rechnungen zutrifft, die über das Kreditoren Rechnungsworkbench erfasst wurden, nicht aber für Rechnungen die über Kreditorenrechnungsjournale eingebucht wurden, werden letztere von der Überwachungsrichtlinie auch nicht gefunden. Über den folgenden Screenshot, der die Rechnungsinformationen aus der VendInvoiceJour Tabelle aufzeigt, kann das eben Gesagte für die erfassten Beispieldaten nachvollzogen werden.
DE_125_0060

Das identifizierte Standardverhalten von Dynamics AX impliziert nun folgendes:

  • Wenn von der hier dargestellten Überwachungsrichtlinienfunktion Gebrauch gemacht werden soll, so müssen alle Kreditorenrechnungen über das Kreditoren Rechnungsworkbench erfasst werden.
  • Für den Fall das Rechnungen auch über Kreditorenrechnungsjournale erfasst werden sollen, ist alternativ eine Systemanpassung in Betracht zu ziehen.
  • Ohne Systemanpassung bleibt bei einer Rechnungserfassung über Kreditorenrechnungsjournale lediglich die Option eine manuelle Prüfung auf potentiell doppelt erfasste Rechnungen durchzuführen.

 

Aus Sicht des Verfassers erscheint die erste Option sämtliche Rechnungen über das Kreditoren Rechnungsworkbench zu erfassen allen anderen Optionen überlegen, da sie die Möglichkeit bietet alle Rechnungen – ob mit oder ohne Bestellbezug – in einer einzigen Maske zu erfassen.

Zu beachten ist in diesem Zusammenhang dass die Erfassung von Rechnungen ohne Bestellbezug über das Kreditoren Rechnungsworkbench mittels der Auswahl einer Beschaffungskategorie erfolgt, für die eine entsprechende Kontierung hinterlegt ist. Eine solche Erfassung minimiert nach Ansicht des Verfassers das Risiko von fehlerhaften Buchungen, die z.B. aufgrund von Fehleingaben (Tippfehlern) entstehen können. Darüber hinaus erlaubt eine Kontierung über Kategorien auch temporären Mitarbeitern, Azubis, Trainees, usw. Rechnungen auf einfache Art und Weise fehlerfrei in Dynamics AX zu erfassen. Der folgende Screenshot zeigt eine solche Rechnungserfassung über eine Kategorie auf und verdeutlicht, dass die hinter der Kategorie stehende Kontierung bei Bedarf – entsprechende Berechtigungen vorausgesetzt – überschrieben werden kann.
DE_125_0070
Selbst wenn die AX-Anwender in ihrem Unternehmen mit der Erfassung von Rechnungen über Kreditorenrechnungsjournale vertraut sind kann sich eine Prozessumstellung hin zu einer Erfassung über das Kreditoren Rechnungsworkbench lohnen. Nicht nur weil hierüber die weiter oben vorgestellte Rechnungssuchfunktion vollumfänglich genutzt werden kann, sondern auch aufgrund der standardmäßig mit dem Rechnungsworkbench verbundenen Workflow- und Excel-Importfunktionen, die insgesamt zu einem einfachen und effektiven Rechnungserfassungsprozess beitragen können.

 

Frage 2: Wie kann man verhindern eine Rechnung mehrfach zu zahlen?
Wie weiter oben dargestellt kann eine Prüfung auf potentiell doppelt erfasste Rechnungen mit Hilfe von Überwachungsrichtlinien das Risiko von Mehrfachzahlungen minimieren. Dies erfordert – wie aufgezeigt – eine entsprechende Rechnungserfassung über das Kreditoren Rechnungsworkbench. Wird hiervon kein Gebrauch gemacht, so bleibt alternativ nur eine manuelle zeit- und ressourcenintensive Prüfung auf potentiell doppelt erfasste Kreditorenrechnungen.

 

Frage 3: Wie kann man mehrfache Rechnungserfassungen vollständig vermeiden?
Das Kreditoren Rechnungsworkbench und die Überwachungsrichtlinien erlauben eine Prüfung daraufhin ob Rechnungen mehrfach erfasst wurden um Doppelzahlungen an Kreditoren zu verhindern. Anders ausgedrückt erlauben die beiden Funktionen eine Prüfung im Nachgang, d.h. nachdem ein Fehler bereits aufgetreten ist.
Da Vorsorge in der Regel besser ist als Nachsorge, stellt sich die Frage wie sich Mehrfacherfassungen von Rechnungen von vorneherein vermieden lassen?
Aus Sicht des Verfassers kann dies nur über eine einheitliche und vollumfängliche Nutzung der Dynamics AX Bestellprozessfunktionen sichergestellt werden. Wörtlich genommen erfordert dies, dass für jede auch noch so kleinen Einkäufe eine Bestellung in Dynamics AX angelegt wird. Auf den ersten Blick mag diese Forderung speziell für viele kleine und mittelständische Unternehmen wie der sprichwörtliche Schuss mit Kanonen auf Spatzen erscheinen. Allerdings habe ich in den letzten Jahren die Erfahrung gemacht, dass es speziell in kleinen und mittelständischen Unternehmen zu Problemen mit der Mehrfacherfassung und Mehrfachzahlung kommt, weil es dort häufig an stringenten und einheitlich definierten Prozessen fehlt. Dementsprechend sind es wahrscheinlich genau diese Unternehmen die von einer vollständigen Abwicklung aller Einkäufe über den Dynamics AX Bestellprozess am meisten profitieren.

 

Wenn sie es bis hierhin geschafft haben :-), dann hoffe ich dass ihnen dieser Beitrag gefallen hat. Ich würde mich freuen wenn sie z.B. über einen Kommentar ihre Erfahrungen im Hinblick auf die Mehrfacherfassung und Mehrfachzahlung von Rechnungen hinterlassen können um auch anderen Dynamics AX Nutzern weitere/alternative Standardlösungsmöglichkeiten zur Mehrfacherfassung und Mehrfachzahlung von Rechnungen aufzuzeigen. Vielen Dank hierfür und bis zum nächsten Beitrag.

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

Einige Hinweise zur Buchung von Kreditorenskonti

03 Dienstag Mai 2016

Posted by Ludwig Reinhard in Kreditoren

≈ Hinterlasse einen Kommentar

Schlagwörter

Gegenkonto, Kreditorenzahlungen, Skonti, Skonto

Dieser Beitrag befasst sich mit der Fragestellung welches Sachkonto Dynamics AX für die Buchung von Kreditorenskonti verwendet. Für die meisten von ihnen, die bereits seit langem mit Dynamics AX arbeiten mag die Beantwortung dieser Fragestellung sehr einfach erscheinen. Aufgrund einer mit AX2012 R3 neu hinzugekommenen Funktionalität sah ich mich allerdings dazu veranlasst diesen Beitrag zu verfassen, da sich aufgrund dieser neuen Funktionalität zusätzliche Buchungs- bzw. Darstellungs-/Ausweismöglichkeiten ergeben.

Bei der neuen Funktion auf die ich mich hier beziehe handelt es sich es sich um eine Standardfunktion aus dem Bereich des öffentlichen Sektors, welche über die Aktivierung des entsprechenden Konfigurationsschlüssels allgemein bereitgestellt werden kann. Sobald dieser Konfigurationsschlüssel aktiviert ist kann man in der Skontimaske das folgende neue Feld erkennen, welches es Benutzern erlaubt zu spezifizieren ob Skonti (a) wie bislang auch auf dem in dieser Maske angegebenen Sachkonto gebucht werden (b) oder auf den Sachkonten, die bei der Rechnungserfassung verwendet wurden.
DE_92_0005

A. Überblick
Aufgrund dieser zusätzlichen Funktionalität lässt sich die Findung des für Skontobuchungen verwendeten Sachkontos wir folgt darstellen:
DE_92_0010

Was man dieser Darstellung entnehmen kann ist – das für den Fall dass der neue Parameter auf „Konto aus Rechnungszeilen“ eingestellt ist – sich das Skontokonto aus den Konten bestimmt die bei der Rechnungsbuchung verwendet werden.

Ist dieser Parameter hingegen auf „Hauptkonto für Kreditorenskonti“ eingestellt, so verwendet Dynamics AX das in der Skontimaske hinterlegte Sachkonto vorausgesetzt, dass die Rechnungsbuchung ohne Mehrwertsteuer durchgeführt wird.

Wird bei der Rechnungsbuchung auch Mehrwertsteuer mitgebucht und wurde in den MWST-Sachkontobuchungsgruppen ein Sachkonto für Kreditorenskonti hinterlegt, so verwendet Dynamics AX das dort hinterlegte Konto. Mit anderen Worten, das in der MWST-Sachkontobuchungsmaske hinterlegte Skontokonto überschreibt dasjenige, welches in der Skontimaske hinterlegt ist.

 

B. Einrichtung
Um ihnen den Unterschied in der Aktivierung bzw. Nicht-Aktivierung des neuen Parameters aufzuzeigen habe ich aus Darstellungsgründen der Einfachheit halber zwei Skonticodes angelegt:

  • “CashDisc A” mit einer Einstellungen die bislang auch schon in früheren Dynamics AX Versionen verfügbar war und
  • „CashDisc B“ mit der neuen Parametrisierung (siehe hierzu auch den folgenden Screenshot). DE_92_0015

Da Skontobuchungen auch über das Sachkonto bestimmt werden können welches im Bereich der Hauptbuchautomatikkonten hinterlegt ist habe ich zur Abgrenzung solcher Buchungen ein eigenes Skontokonto (Nr. 520208) hinterlegt.
DE_92_0020
Das gleiche gilt für die MWST-Sachkontobuchungseinstellungen. D.h. auch hier habe ich ein eigenes Skontokonto (Nr. 520209) zur besseren und eindeutigen Identifikation der Sachkontofindungslogik hinterlegt.
DE_92_0025

 

C. Demotransaktionen
Im Folgenden werden – basierend auf den im vorherigen Kapitel dargestellten Einstellungen – einige Demotransaktionen in Dynamics AX erfasst um den Unterschied in der Nutzung der neuen Funktionalität darzustellen. Hierfür werden die folgenden Kreditorenrechnungen in einem gewöhnlichen Kreditorenrechnungsjournal gebucht.
DE_92_0030

  • Die erste Rechnung wurde mit dem „alten“, d.h. bereits in der Vergangenheit verfügbaren Skonticode („cash disc A“) ohne Mehrwertsteuer eingebucht,
  • Die zweite Rechnung wurde ebenfalls mit dem gleichen Skonticode allerdings mit Mehrwertsteuer eingebucht,
  • Die dritte Rechnung wurde mit dem „neuen“ Skonticode („cash disc B“) ohne Mehrwertsteuer und
  • Die vierte Rechnung mit dem neuen Skonticode („cash disc B“) und mit Mehrwertsteuer eingebucht.

Bei der Zahlung dieser vier Rechnungen unter Skontoabzug wurden die folgenden Sachkontobuchungen generiert:

  • Für die Zahlungsbuchung der ersten Rechnung wurde das in der Skontimaske hinterlegte Konto verwendet. DE_92_0035
  • Da die zweite Rechnung mit Mehrwertsteuer gebucht wurde, wird für die Zahlungsbuchung der zweiten Rechnung das Skontokonto verwendet welches in der MWST-Sachkontobuchungsmaske hinterlegt ist. (Bitte beachten sie, dass in diesem Fall eine Aufteilung des Skontobetrages in einen Netto- und Steuerkorrektur-Teil erfolgt, die jeweils gesondert gebucht werden). DE_92_0040
  • Der Skonto für die Zahlung der dritten Rechnung wird auf dem Sachkonto gebucht welches bei der ursprünglichen Rechnungsbuchung verwendet wurde. DE_92_0045
  • Das gleiche gilt für die Skontobuchung der vierten Rechnung mit dem Unterschied dass hier aufgrund der steuerlichen Buchung eine Aufteilung in einen Netto- und Steuerkorrektur-Teil erfolgt.
    DE_92_0050

Die letzten beiden Buchungen verdeutlichen sehr schön den Unterschied in der Nutzung der neuen Skontofunktionalität im Vergleich zu den bereits in der Vergangenheit verfügbaren Skontofunktionen.

 

D. Splitbuchungen
Nachdem im vorherigen Kapitel ausschließlich einfache Kreditorenrechnungen sowie deren Zahlung unter Skontoabzug betrachtet wurden, sollen in diesem Unterkapitel Splitbuchungen betrachtet werden um herauszufinden welchen Einfluss die Nutzung der neuen Skontofunktionalität auf diese Art von Buchungen hat. Um dies zu realisieren wurden zwei weitere Kreditorenrechnungen in Dynamics AX eingebucht, die im nächsten Screenshot dargestellt sind.
DE_92_0055

  • Die fünfte Rechnung wurde hierbei mit dem alten Skonticode (“cash disc A”) und ohne Mehrwertsteuer,
  • die sechste Rechnung hingegen mit dem neuen Skonticode („cash disc B“) und ebenfalls ohne Mehrwertsteuer gebucht.

Bei der Zahlung dieser beiden Rechnungen unter Skontoabzug wurden die folgenden Buchungen generiert:

  • Die fünfte Rechnung wurde wie üblich mit dem Skontocode gebucht der in der Skontimaske hinterlegt ist.
    DE_92_0060
  • Bei der sechsten Rechnung wurde hingegen eine Aufteilung des Skontobetrags auf die verschiedenen im Rahmen der Rechnungsbuchung verwendeten Sachkonten vorgenommen. Der folgende Screenshot zeigt die hierbei durchgeführte Buchung auf.
    DE_92_0065

 

E. Weitere Buchungsarten
In diesem letzten Unterkapitel sollen schließlich noch solche Kreditorenrechnungen bzw. die zugehörigen Skontibuchungen betrachtet werden, die nicht unmittelbar gegen Sachkonten, sondern gegen andere Buchungsarten gebucht werden.

E.1. Sachanlagenbuchungen
Bei Sachanlagenbuchungen handelt es sich im Hinblick auf Skontoabzüge um besondere Buchungen, da über einen gesonderten Anlagenparameter definiert werden kann, ob Skontoabzüge den Buchwert der Anlagengegenstände mindern oder nicht. Der erwähnte Parameter ist im nächsten Screenshot dargestellt.
DE_92_0070
Um herauszufinden welchen Einfluss der neue Skontoparameter auf Sachanlagenbuchungen hat werden nachfolgend zunächst Kreditorenrechnungen unter Aktivierung des Anlagenparameters „Skonto abziehen“ eingebucht und gezahlt, bevor weitere Kreditorenrechnungen eingebucht und bezahlt werden bei denen dieser Parameter nicht aktiviert ist.

E.1.1. Sachanlagenbuchungen – Anlagenparameter “Skonto abziehen” aktiviert
Wie weiter oben beschrieben werden zunächst zwei Kreditorenrechnungen für die Anschaffung von Sachanlagen eingebucht. Die erste Rechnung wird hierbei mit dem ersten „alten“ Skontocode („cash disc A“) und die zweite Rechnung mit dem „neuen“ Skontocode („cash disc B“) erfasst. (Aus Vereinfachungsgründen werden beide Buchungen ohne Mehrwertsteuer gebucht).
DE_92_0075

Nach der Zahlung beider Rechnungen unter Skontoabzug können die folgenden Buchungen identifiziert werden:

  • Zahlungsbuchung der ersten Rechnung
    DE_92_0080
  • Zahlungsbuchung der zweiten Rechnung
    DE_92_0085

Ein Vergleich der beiden Belege zeigt auf, dass es von der Sachkontobuchungsseite, d.h. von den angesprochenen Konten her betrachtet keinerlei Unterschiede in den Buchungsbelegen gibt.


E.1.2. Sachanlagenbuchungen – Anlagenparameter “Skonto abziehen” nicht aktiviert
Nach Buchung und Zahlung der ersten beiden Rechnungen wird der Anlagenparameter „Skonto abziehen“ deaktiviert und zwei weitere Kreditorenrechnungen über die Anschaffung von Sachanlagen wie zuvor eingebucht und gezahlt.
DE_92_0090

Ergebnis:

  • Der Skonto, welcher bei Zahlung der ersten Kreditorenrechnung mit der alten Skontocodeeinstellung gebucht wurde wird auf dem Sachkonto erfasst, welches in der Kreditorenskontimaske hinterlegt ist. Erwartungsgemäß ergibt sich hier aufgrund der gewählten Buchungseinstellung keinerlei Einfluss auf den Sachanlagenwert im Anlagenmodul.
    DE_92_0095
  • Die Zahlungsbuchung der zweiten Kreditorenrechnung führt zu folgendem Beleg:
    DE_92_0100
    Wie man aus dem obenstehenden Screenshot erkennen kann wird der Skontoabzug nun gegen das Sachanlagenkonto gebucht, das auch bei der Rechnungsbuchung verwendet wurde, d.h. das Sachanlagenkonto Nr. 180100. Die Maske „Grundlage der Buchung“ zeigt auf, dass diese Buchung allerdings nur auf Sachkontoebene, nicht aber im Anlagenmodul durchgeführt wird, was unmittelbar zu einer Abweichung zwischen dem im Hauptbuch und im Anlagenmodul ausgewiesenen Anlagensaldo führt!

 

E.2. Bestellbezogene Rechnungen
Bei den letzten Buchungen die im Rahmen dieses Beitrags betrachtet werden handelt es sich um bestellbezogene Kreditorenrechnungen, die unter Skontoabzug bezahlt werden. Um auch hier den Unterschied zwischen der „alten“ und der „neuen“ Skontoeinstellung hervorzuheben werden diesmal der Einfachheit halber zwei Kreditorenkonten verwendet bei dem das erste standardmäßig mit der alten, das zweite standardmäßig mit der neuen Skontoeinstellung eingerichtet wurde.
DE_92_0105

Anschließend werden zwei identische Bestellungen angelegt, fakturiert und anschließend bezahlt um die hierbei durchgeführten Skontobuchungen vergleichen zu können. DE_92_0110 DE_92_0115

Ergebnis:

  • Bei der ersten bestellbezogenen Rechnung wird der Skonto erwartungsgemäß auf dem Sachkonto gebucht welches in der Kreditorenskontimaske hinterlegt ist.
    DE_92_0120
  • Ähnlich wie bei den anlagenbezogenen Rechnungen wird auch im Falle der bestellbezogenen Rechnungen bei Anwendung der neuen Skontofunktionalität der abgezogene Skonto auf dem Lagerbestandskonto (Nr. 140200) gebucht das bei der Bestellrechnungsbuchung verwendet wurde. Leider wird auch diese Buchung lediglich auf Sachkontenebene durchgeführt, wie die Maske “Grundlage der Buchung” verdeutlicht. Aufgrund dessen kommt es auch hier zu einer Abweichung in den Saldenwerten des Hauptbuchs und des Lagermoduls!DE_92_0125

 

Zusammenfassung
Zusammenfassend kann man festhalten, dass die neue Skontofunktionalität die Möglichkeit einräumt in Anspruch genommene Kreditorenskonti auf den Sachkonten zu erfassen die bei der Rechnungserfassung verwendet wurden. Speziell im Bereich aufwandsbezogener Transaktionen ohne Sachanlagen- und Bestellbezug kann dies eine interessante Möglichkeit darstellen da der Nettoeffekt dieser Transaktionen nicht mehr über verschiedene Konten hinweg zusammengesucht werden muss.

Sobald die neue Skontofunktionalität allerdings im Bereich von Sachanlagenbuchungen oder Bestellbuchungen angewandt wird entstehen schnell Probleme die sich in Saldoabweichungen zwischen den Haupt- und Nebenbüchern manifestieren können, so dass für derartige Transaktionen dringend von der Nutzung der neuen Funktionalität abzuraten ist.

← Ältere Beiträge
Neuere Beiträge →

Microsoft BizApps Deutschland Podcast

Meetup Dynamics Deutschland

Kategorien

  • Anlagen
  • Bank
  • Buchrezension
  • Budgetierung
  • Debitoren
  • Hauptbuch
  • Kostenrechnung
  • Kreditoren
  • Lager
  • Management Reporter
  • Nachhaltigkeit
  • Podcast
  • PowerPlatform
  • Projekt
  • Sonstiges
  • Uncategorized

Tags

Artificial Intelligence Budgetierung Controlling Copilot Studio D365 D365FO Dynamics 365 Dynamics AX Dynamics AX 2012 Electronic Reporting Email Finanzberichte Flow Genehmigung Globale Erwaermung Intercompany IOT Kontoauszugsverarbeitung Kostenrechnung Kostenstellenrechnung Kreditorenzahlungen Kuenstliche Intelligenz Lager Lagerabstimmung Lagerbewertung Management Reporter Modern Finance MS Flow MT940 Nachhaltigkeit Neues Kostenrechnungsmodul PowerApps PowerAutomate PowerPlatform Projekt Projektmodul Rechnung Rechnungserfassung RPA SharePoint Steuer Sustainability Sustainability Accounting Sustainability Manager time&attendance Umlagen Umwelt WBS Workflow Zeiterfassung

Wichtige Webseiten

  • Dynamics AX Links

Rechtliches

  • Impressum

Abbonieren

  • RSS - Beiträge
  • RSS - Kommentare

Klicken Sie hier um diesem Blog zu folgen und automatische Emails bei der Veröffentlichung neuer Beiträge zu erhalten.

Archiv

  • März 2024
  • Februar 2024
  • Januar 2024
  • Dezember 2023
  • November 2023
  • Oktober 2023
  • September 2023
  • August 2023
  • Juli 2023
  • Juni 2023
  • Mai 2023
  • April 2023
  • März 2023
  • Februar 2023
  • Januar 2023
  • Dezember 2022
  • November 2022
  • Oktober 2022
  • September 2022
  • August 2022
  • Juli 2022
  • Juni 2022
  • Mai 2022
  • April 2022
  • März 2022
  • Februar 2022
  • Januar 2022
  • Dezember 2021
  • November 2021
  • Oktober 2021
  • September 2021
  • August 2021
  • Juli 2021
  • Juni 2021
  • Mai 2021
  • April 2021
  • März 2021
  • Februar 2021
  • Januar 2021
  • Dezember 2020
  • November 2020
  • Oktober 2020
  • September 2020
  • August 2020
  • Juli 2020
  • Juni 2020
  • Mai 2020
  • April 2020
  • März 2020
  • Februar 2020
  • Januar 2020
  • Dezember 2019
  • November 2019
  • Oktober 2019
  • September 2019
  • August 2019
  • Juli 2019
  • Juni 2019
  • Mai 2019
  • April 2019
  • März 2019
  • Februar 2019
  • Januar 2019
  • Dezember 2018
  • November 2018
  • Oktober 2018
  • September 2018
  • August 2018
  • Juli 2018
  • Juni 2018
  • Mai 2018
  • April 2018
  • März 2018
  • Februar 2018
  • Januar 2018
  • Dezember 2017
  • November 2017
  • Oktober 2017
  • September 2017
  • August 2017
  • Juli 2017
  • Juni 2017
  • Mai 2017
  • April 2017
  • März 2017
  • Februar 2017
  • Januar 2017
  • Dezember 2016
  • November 2016
  • Oktober 2016
  • September 2016
  • August 2016
  • Juli 2016
  • Juni 2016
  • Mai 2016
  • April 2016
  • März 2016
  • Februar 2016
  • Januar 2016
  • Dezember 2015
  • November 2015
  • Oktober 2015
  • September 2015
  • August 2015
  • Juli 2015
  • Juni 2015
  • Mai 2015
  • April 2015
  • März 2015
  • Februar 2015

Bloggen auf WordPress.com.

  • Abonnieren Abonniert
    • Microsoft BizApps Finance & Controlling
    • Schließe dich 121 anderen Abonnenten an
    • Du hast bereits ein WordPress.com-Konto? Melde dich jetzt an.
    • Microsoft BizApps Finance & Controlling
    • Abonnieren Abonniert
    • Registrieren
    • Anmelden
    • Melde diesen Inhalt
    • Website im Reader anzeigen
    • Abonnements verwalten
    • Diese Leiste einklappen
 

Kommentare werden geladen …