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

Microsoft BizApps Finance & Controlling

Microsoft BizApps Finance & Controlling

Schlagwort-Archiv: Kreditorenzahlungen

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.

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.

Rechnungsgruppen & Rechnungszahlungsgruppen

01 Sonntag Nov 2015

Posted by Ludwig Reinhard in Kreditoren

≈ Hinterlasse einen Kommentar

Schlagwörter

Dynamics AX 2012 R3, Kreditorenzahlungen, Rechnungen

Der nachfolgende Beitrag beschreibt die neu in Dynamics AX 2012 R3 hinzugekommenen Funktionen der Rechnungsgruppen und Rechnungszahlungsgruppen.

Rechnungsgruppen
Die erste hier beschriebene Funktion der Rechnungsgruppen kann über die Aktivierung des Kreditorenparameters „Rechnungsgruppen für dieses Unternehmenskonto verwenden“ bereitgestellt werden.
DE_17-RG-1Nach Aktivierung dieses Parameters ist zu festzulegen, welche Kennung für die Rechnungsgruppen standardmäßig verwendet werden soll. Zur Auswahl stehen an dieser Stelle:

  • Benutzername,
  • Datum und
  • Benutzerdefiniert.

Unmittelbar nach Durchführung dieser Parametrisierungen kann in der Kreditorenrechnungserfassungsmaske ein neues Feld „Rechnungsgruppe“ identifiziert werden, welches standardmäßig mit den in den Kreditorenparametern definierten Werten vorbelegt wird. Im gewählten Beispiel mit meiner Benutzerkennung „$1D58“.
DE_17-RG-3
Wird eine derart erfasste Rechnung gebucht, so kann im Anschluss an die Buchung die entsprechende Rechnungsgruppe in der Rechnungserfassungsmaske identifiziert werden.
DE_17-RG-4
Aufgrund dieser Kennzeichnung können anschließend bspw. Auswertungen im Hinblick auf die Anzahl der erfassten Rechnungen pro Tag oder pro Mitarbeiter durchgeführt werden, die ein Teilelement eines Activity Based Cost Managements bilden können.

Ungeachtet der Vorteile dieser möglichen Zusatzauswertungen gilt es im Zusammenhang mit der Aktivierung des Rechnungsgruppenparameters die folgenden Nachteile/Probleme zu beachten:

  • Ein erster Nachteil besteht darin, dass das Rechnungsgruppenfeld standardmäßig nicht in den häufig in der Praxis genutzten Rechnungsjournalen zur Verfügung steht und über eine Personalisierung dieser Journale aufgrund fehlender Verknüpfungen auch nicht bereitgestellt werden kann. Um Rechnungsgruppen daher umfassend nutzen zu können ist eine entsprechende Systemanpassung erforderlich.
  • Ein zweiter Nachteil besteht darin, dass die standardmäßig vorbelegten Werte beliebig und ohne weitere Prüfung überschrieben werden können. So kann bspw. trotz einer Parametrisierung „Benutzername“ der von Dynamics AX vorgeschlagene Wert abgeändert und mit einer beliebigen Kombination aus Buchstaben und Ziffern überschrieben werden.
  • Eine Zusammenfassung (Sammelaktualisierung) von Rechnungen nach Rechnungsgruppen steht standardmäßig derzeit nicht zur Verfügung.

 

Rechnungszahlungsgruppen
Bei der zweiten neuen hier beschriebenen Funktion der Rechnungszahlungsgruppen handelt es sich um eine Funktion aus dem Bereich des öffentlichen Sektors, welche über eine entsprechende Einstellung der Lizenzkonfiguration grundsätzlich bereitgestellt werden kann.

Ähnlich wie bei den zuvor erwähnten Rechnungsgruppen handelt es sich auch bei den Rechnungszahlungsgruppen um eine Funktion, die nach der Aktivierung des entsprechenden Kreditorenparameters ein neues Feld in der Kreditorenrechnungserfassungsmaske bereitstellt. Siehe hierzu die folgenden beiden Screenshots.
DE_17-RZG-1 DE_17-RZG-2
Nach Buchung der Rechnung kann auf dieses Feld dann bspw. im Rahmen von Zahlungsläufen gefiltert werden. Beispiel:
DE_17-RZG-4Wird hierbei eine Rechnung, die einer bestimmten Zahlungsgruppe zugeordnet wurde, vom Zahlungslauf ausgenommen, so wird ein Warnhinweis der folgenden Art angezeigt:
DE_17-RZG-5

Aus diesem Warnhinweis erkennt man, dass der wesentliche Vorteil der Aktivierung des Rechnungszahlungsgruppenparameters darin besteht, dass Benutzer einen Hinweis daraufhin erhalten ob alle Rechnungen welche zur gleichen Rechnungszahlungsgruppe gehören bezahlt werden oder nicht. Ein konkreter Anwendungsfall für diese Funktion besteht bspw. in der Kennzeichnung von dringend zu zahlenden Rechnungen.

Leider hat die hier aufgezeigte Standardfunktion auch einige Nachteile.

  • Zunächst ist zu erwähnten, dass ein Zahlungsgruppencode standardmäßig auf ein bestimmtes Kreditorenkonto beschränkt ist und beim Versuch den Zahlungsgruppencode im Rahmen der Rechnungserfassung für ein anderes Kreditorenkonto zu verwenden eine Fehlermeldung generiert wird. Für einen Praxiseinsatz ist dies natürlich wenig tauglich und es empfiehlt sich daher eine Codeanpassung durchzuführen.
  • Darüber hinaus ist zu beachten dass es sich hierbei – wie eingangs erwähnt – um eine Funktion des öffentlichen Sektors handelt, welche an der einen oder anderen Stelle unnötige Fehlermeldungen/-hinweise generiert, die ausgeblendet werden sollten.

 

Zusammenfassend kann man somit festhalten, dass die neu in Dynamics AX aufgenommenen Funktionen der Rechnungsgruppen und Rechnungszahlungsgruppen interessante Einsatzmöglichkeiten bieten. Gleichzeitig haben die obenstehenden Ausführungen allerdings auch aufgezeigt, dass beide Funktionen nicht unmittelbar und ohne weitere Anpassungen in einer Liveumgebung verwendet werden können.

← Ä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 …