05 Samstag Jan 2019
Posted in Kreditoren
Schlagwörter
Dieser Webcast stellt dar, wie man das Standard Zahlungsavisdokument mit firmenspezifischen Logos und Designvorgaben konfigurieren kann. Darüber hinaus wird aufgezeigt wie man Zahlungsavise als PDF Dokumentenanhang an Lieferanten per Email übermitteln kann.
04 Sonntag Sep 2016
Posted in Kreditoren
Schlagwörter
Vor kurzem wurde ich mit einer Anforderung konfrontiert, bei der alle Kreditorenzahlungsbuchungen, welche von einem Bankkonto aus vorgenommen wurden, zusammengefasst und nicht einzeln gebucht werden sollten. Im konkreten Fall erstellte Dynamics AX allerdings eine Vielzahl von Buchungen auf dem Bankkonto, da die unterschiedlichen Journalzeilen verschiedene Finanzdimensionskombinationen aufwiesen. Dieser Umstand erschwerte den Bankabstimmungsprozess, weil einer einzigen summierten Bankabbuchung auf dem Kontoauszug eine Vielzahl von Belegbuchungen in Dynamics AX gegenüberstanden.
Beispiel
Das nachfolgend dargestellte Beispiel soll die eben beschriebene Problemstellung verdeutlichen.
Beispiel – Erstellung Zahlungsvorschlag
Beispiel – Generierter Buchungsbeleg für die erste Journalzeile
Beispiel – Gebuchte Banktransaktionen
A) Änderung Journaleinstellungen
Um nicht eine Vielzahl von Zahlungsbuchungen auf dem Bankkonto, welches für die Buchung des Zahlungslaufes verwendet wird, zu erhalten wurden an den Buchungsjournaleinstellungen die beiden folgenden Parameteränderungen in Bezug auf die Verwendung von Belegnummern und den Detailgrad der Buchungen vorgenommen:
Hinweis: Ursprünglich wies der Parameter ‚neuer Beleg‘ die Einstellung ‚im Zusammenhang mit Ausgleich‘ und der Parameter ‚Detailebene‘ die Einstellung ‚Detaildaten‘ auf.
Nach Umstellung dieser Journaleinstellungen wurde ein weiterer Zahlungslauf erstellt und gebucht. Das Ergebnis dieser Buchung ist im folgenden Screenshot dargestellt und zeigt auf, dass zwar eine einzige Belegnummer für alle Zahlungsbuchungen verwendet wurde, gleichzeitig allerdings keine Zusammenfassung der unterschiedlichen Bankbuchungen erfolgte.
B) Änderung Bankkontoeinstellungen
Die Ursache weshalb im vorstehenden Beispiel keine Buchungszusammenfassung erfolgte lag darin begründet, dass die Kreditorenrechnungen mit unterschiedlichen Finanzdimensionskombinationen gebucht wurden und diese Finanzdimensionskombinationen auf die Bankbuchungen vererbt wurden. Im obenstehenden Screenshot kann man dies an den Buchungen auf dem Bankkonto erkennen, welche mit den Kostenstellen Nr. 022, 023 und 024 durchgeführt wurden.
Um dieses Problem zukünftig zu vermeiden, wurden auf Ebene des verwendeten Bankkontos die folgenden Standardfinanzdimensionseinstellungen hinterlegt:
Vor dem Hintergrund der vorgenommenen Standardfinanzdimensionseinstellungen auf Ebene des Bankkontos wurde nun erwartet, dass Dynamics AX eine entsprechende Buchungszusammenfassung der Bankbuchungen vornimmt.
Dies war allerdings nicht der Fall, wie die nachfolgende Darstellung aufzeigt, was darin begründet lag, dass die Finanzdimensionseinstellungen, welche mit der Rechnungsbuchung vorgenommen wurden, die hinterlegten Standardfinanzdimensionseinstellungen auf Ebene des Bankkontos überschrieb.
C) Änderung Sachkontoeinstellungen
Um die Problematik mit der Finanzdimensionsvererbung gelöst zu bekommen wurden schließlich auf Ebene des Sachkontos, welches mit dem Bankkonto verknüpft ist, feste Finanzdimensionsgrößen hinterlegt.
Der anschließend durchgeführte Zahlungslauf generierte schließlich die folgende ersehnte zusammengefasste Bankbuchung.
D) Modifikation 1 – Unterschiedliche Zahlungstage
Um die Zuverlässigkeit und Stabilität der gewählten Parametrisierung zu testen wurde ein weiterer Zahlungslauf initiiert, diesmal allerdings in der Form, dass die zu zahlenden Rechnungen mit unterschiedlichen Zahlungs-/Buchungsdatumswerten versehen wurden.
Im Ergebnis generierte Dynamics AX nun mehrere Belegbuchungen – jeweils eine pro angegebenem Buchungsdatum – verwendete hierbei allerdings lediglich eine einzige Belegnummer. Das Ergebnis dieser Testbuchung ist im nächsten Screenshot ersichtlich.
Hinweis: Problematisch an den hier dargestellten Buchungen ist, dass Dynamics AX die gleiche Belegnummer für Buchungen mit unterschiedlichem Buchungsdatum verwendet. Diese Art der Belegbuchung ist nach den gängigen Rechnungslegungsvorschriften regelmäßig nicht erlaubt und kann zu Problemen mit den Wirtschafts- und Steuerprüfern führen.
E) Modifikation 2 – Unterschiedliche Zahlungsmethoden
In einem weiteren Test wurde abschließend untersucht, welche Auswirkungen die Verwendung unterschiedlicher Zahlungsmethoden auf die generierten Belegbuchungen hat. Das Ergebnis dieses Tests ist in der nachfolgenden Grafik dargestellt und zeigt auf, dass die Buchungszusammenfassung auch in diesem Fall einwandfrei funktioniert.
Zusammenfassung
Innerhalb dieses Beitrags wurde die Zusammenfassung von Zahlungsbuchungen aufgezeigt. Ohne dies explizit anhand von Beispielen auszuführen gilt das oben Gesagte natürlich auf in solchen Fällen, in denen ein Zahlungstransferkonto zum Einsatz kommt, vorausgesetzt eine entsprechende Finanzdimensionsverknüpfung wurde auf Ebene des Sachkontos vorgenommen.
Neben der festen Finanzdimensionsverknüpfung als zwingende Voraussetzung für die Anwendung der hier dargestellten Buchungsdarstellung gilt es insbesondere den dargestellten Zusammenhang zum verwendeten Buchungsdatum zu beachten, da es andernfalls zu Unstimmigkeiten mit den Prüfern des Unternehmens kommen kann.
08 Mittwoch Jun 2016
Posted in Kreditoren
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:
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.
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.
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.
Aufgrund der aus Demonstrationsgründen absichtlich vorgenommenen Eingabefehler wurde die Rechnung letztendlich viermal im System erfasst.
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.
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.
Der dritte und wichtigste Einrichtungsschritt besteht in der Spezifikation der sog. Überwachungsrichtlinienregel.
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.
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.
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.
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.
Das identifizierte Standardverhalten von Dynamics AX impliziert nun folgendes:
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.
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.
03 Dienstag Mai 2016
Posted in Kreditoren
Schlagwörter
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.
A. Überblick
Aufgrund dieser zusätzlichen Funktionalität lässt sich die Findung des für Skontobuchungen verwendeten Sachkontos wir folgt darstellen:
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:
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.
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.
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.
Bei der Zahlung dieser vier Rechnungen unter Skontoabzug wurden die folgenden Sachkontobuchungen generiert:
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.
Bei der Zahlung dieser beiden Rechnungen unter Skontoabzug wurden die folgenden Buchungen generiert:
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.
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).
Nach der Zahlung beider Rechnungen unter Skontoabzug können die folgenden Buchungen identifiziert werden:
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.
Ergebnis:
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.
Anschließend werden zwei identische Bestellungen angelegt, fakturiert und anschließend bezahlt um die hierbei durchgeführten Skontobuchungen vergleichen zu können. 
Ergebnis:
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.
01 Sonntag Nov 2015
Posted in Kreditoren
Schlagwörter
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.
Nach Aktivierung dieses Parameters ist zu festzulegen, welche Kennung für die Rechnungsgruppen standardmäßig verwendet werden soll. Zur Auswahl stehen an dieser Stelle:
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“.
Wird eine derart erfasste Rechnung gebucht, so kann im Anschluss an die Buchung die entsprechende Rechnungsgruppe in der Rechnungserfassungsmaske identifiziert werden.
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:
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.
Nach Buchung der Rechnung kann auf dieses Feld dann bspw. im Rahmen von Zahlungsläufen gefiltert werden. Beispiel:
Wird hierbei eine Rechnung, die einer bestimmten Zahlungsgruppe zugeordnet wurde, vom Zahlungslauf ausgenommen, so wird ein Warnhinweis der folgenden Art angezeigt:
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.
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.
26 Sonntag Apr 2015
Posted in Hauptbuch
Schlagwörter
Bei der Buchung und Zahlung von Fremdwährungsrechnungen kann es vorkommen, dass Kursgewinne bzw. Kursverluste auf dem falschen Sachkonto gebucht und ausgewiesen werden. Wie es zu solchen falschen Ausweisen kommen kann und welche Möglichkeiten bestehen diese zu korrigieren, soll im folgenden Beitrag aufgezeigt werden.
Ausgangssituation
Für die folgenden Ausführungen werden die folgenden fiktiven EUR/USD Währungskurse verwendet (Unternehmenswährung ist hierbei EUR): 
Ausgehend von diesen Wechselkursen wird am 1 Januar 2015 zunächst eine Kreditorenrechnung in Höhe von 1000 USD in einem Kreditorenrechnungsjournal erfasst und gebucht. Aufgrund des zum Zeitpunkt der Rechnungsbuchung gültigen Wechselkurses von 80 EUR/100 USD ergibt sich ein zugehöriger EUR-Wert in Höhe von 800 EUR. 
Da die Rechnung bis zum Monatsletzten noch nicht ausgeglichen ist, wird zum Ende des Monats Januar 2015 eine entsprechende Neubewertung der Fremdwährung durchgeführt. Dank des auf 75 EUR/100 USD gesunkenen Wechselkurses ergibt sich hieraus ein unrealisierter Wechselkursgewinn in Höhe von 50 EUR (1000 USD * [80/100 EUR/USD – 75/100 EUR/USD]), den Dynamics AX auf dem entsprechenden Sachkonto für unrealsisierte Kursgewinne bucht. Die zugehörige Buchung ist im folgenden Screenshot dargestellt. 
Am 5 Februar 2015 wird die Kreditorenrechnung schließlich durch eine Überweisung beglichen. Diese Überweisung wird wie im Standard von Dynamics AX üblich über ein Kreditorenzahlungserfassungsjournal durchgeführt. Da der Wechselkurs zum Zeitpunkt der Zahlung auf 87 EUR/100 USD gestiegen ist, ergibt sich aus der Zahlung in Höhe von 1000 USD bzw. 870 EUR ein Kursverlust in Höhe von 70 EUR. Dieser Verlust wird auf dem Konto für realisierte Kursverluste erfasst. Gleichzeitig wird der zuvor gebuchte unrealisierte Kursgewinn in Höhe von 50 EUR storniert. Die zugehörigen Buchungen sind in den folgenden beiden Screenshots dargestellt. 
An dieser Stelle ist zu beachten, dass die Zahlung der Kreditorenrechnung nicht unmittelbar über das Bankkonto, sondern über ein Zahlungstransferkonto – im Beispiel Sachkonto „109052 Transfer Bank Bravo“ – abgebildet wird. Mit der Erfassung der Bankbuchung drei Tage später wird das erwähnte Zahlungstransferkonto wieder entlastet. 
Da zum Zeitpunkt der Zahlungsbuchung am 5 Februar und zum Zeitpunkt der Bankbuchung am 8 Februar unterschiedliche Wechselkurse galten, verbleibt auf dem Transferkonto ein Saldo in Höhe von 40 EUR. Dieser Saldo erklärt sich aus der Kursdifferenz die zwischen dem 5 Februar (87 EUR/100 USD) und dem 8 Februar (83 EUR/100 USD) auftrat. 
Um nun diese Differenz zu „bereinigen“ wird im Hauptbuch eine Kursregulierung für das Zahlungstransferkonto angestoßen, die dazu führt dass der Saldo auf dem Zahlungstransferkonto glattgestellt wird. 
Betrachtet man sich die über die Kursregulierung durchgeführte Buchung in Höhe von 40 EUR im Detail, so erkennt man dass diese über das Sachkonto für unrealisierte Kursgewinne durchgeführt wurde. 
Die Abbildung über das Konto für unrealisierte Kursgewinne ist falsch und führt zu einem falschen Erfolgsausweis. Die folgende Grafik, zeigt diese falsche Darstellung zusammen mit den im Beispiel durchgeführten Sachkontobuchungen nochmals im Detail auf.
Insgesamt ergibt sich zwar aus den durchgeführten Buchungen ein korrekter Gesamt-Kursverlust in Höhe von 30 EUR; die Abbildung über das unrealisierte Kursgewinnkonto ist allerdings fehlerhaft.
Lösungsmöglichkeit
Eine Möglichkeit wie dieser fehlerhafte Ausweis vermieden werden kann soll nachfolgend dargestellt werden. Für diese Darstellung werden zunächst einige kleine Systemmodifikationen durchgeführt.
Schritt 1
Im ersten Schritt werden die beiden Elemente „FinancialGain“ und „FinancialLoss“ des BaseEnums „CurrencyGainLossAccountType“ für die Länder Deutschland und USA bereitgestellt.
Schritt 2
Im zweiten Schritt werden die beiden Labels @GLS109008 und @GLS109005 umbenannt.
Schritt 3
Im dritten Schritt findet eine Erweiterung der „LedgerExchAdj“ Klasse auf die Länder Deutschland und USA statt.
Schritt 4
Schließlich findet eine gleichlaufende Erweiterung der Form „Ledger“ für die Länder Deutschland und USA statt.
Ergebnis dieser Modifikationen ist, dass nun zwei neue Kursregulierungstypen in der Sachkontomaske im Hauptbuch zur Verfügung stehen und eingerichtet werden können.
Werden basierend auf diesen Einstellungen die vorherigen Buchungen auf „frischen“ Bank- und Transferkonten wiederholt, so erkennt man, dass die Buchung des Wechselkursgewinns auf dem Zahlungstransferkonto nun auf dem neu eingerichteten Sachkonto „801800“ für realisierte Wechselkursgewinne durchgeführt wird, was zu einem korrekten Ergebnisausweis führt.
Hinweis: Die hier aufgezeigten Systemmodifikationen beeinflussen auch Kursregulierungen, die über das Bankmodul durchgeführt werden. Wie diese Kursregulierungsfunktionalität eingerichtet werden kann wurde im vorherigen Beitrag dargestellt. Zu Einzelheiten, siehe dort.
03 Freitag Apr 2015
Posted in Kreditoren
Schlagwörter
Manchmal stößt man in Dynamics AX auf Situationen in denen Standardberichte nicht bzw. nicht in der gewünschten Form zur Verfügung stehen. In solchen Situationen muss man nicht unmittelbar einen Kollegen aus der IT-Abteilung einbinden um eine Systemanpassung in Form eines neuen Berichtes umzusetzen, sondern man kann sich auch Dokumentenvorlagen für die Berichterstattung bzw. Kommunikation mit externen Partnern/Stakeholdern zu Nutze machen.
Wie derartige Dokumentenvorlagen in Dynamics AX erstellt und genutzt werden können ist bereits an verschiedenen Stellen beschrieben. Siehe hierzu bspw. die Ausführungen auf TechNet und auf den auf diesem Blog verfügbaren Dynamics AX Links. Ein Nachteil dieser Beschreibungen besteht darin, dass diese regelmäßig sehr abstrakt gehalten sind und daher allenfalls als Idee für eine Umsetzung in Dynamics AX verwendet werden können. Aufgrund dessen soll in diesem Beitrag die Nutzung von Dokumentenvorlagen anhand eines konkreten Beispiels aufgezeigt werden.
Ausgangspunkt für dieses Beispiel ist die Problemstellung dass Lieferanten eine durchgeführte Zahlung keiner Rechnung zuordnen können und daher um die Übermittlung einer Zahlungsinformation bitten. Grundsätzlich bestehen hier die Möglichkeit dem Lieferanten ein zuvor abgespeichertes Zahlungsavis – Hinweis: Standardmäßig unterstützt Dynamics AX keinen Wiederholungsdruck von Zahlungsavisen – oder einen Screenshot bzw. Ausdruck der Zahlungshistorienmaske zukommen zu lassen. Da sich die Suche nach abgespeicherten Zahlungsavisen häufig als schwierig erweist und die Übermittlung eines Bildschirmdrucks nicht immer gewünscht ist, wird nachfolgend die Nutzung von Dokumentenvorlagen für die Übermittlung von Zahlungsinformationen an Lieferanten aufgezeigt.
Zu beachten ist in diesem Zusammenhang, dass sich Dokumentenvorlagen nicht für die Massenkommunikation mit externen Stakeholdern (Kunden, Lieferanten, etc.) eignen, sondern für unregelmäßig vorkommende einmalige Kommunikationen. Dies liegt darin begründet, dass bei Dokumentenvorlagen die Funktion der Mehrfachauswahl – sog. multi-select – nicht zur Verfügung steht. Darüber hinaus ist zu beachten, dass die Nutzung der hier aufgezeigten Funktionalität nicht auf die Übermittlung von Zahlungsinformationen beschränkt ist, sondern sich für alle Arten unregelmäßiger Kommunikation mit externen Stakeholdern eignet. Weitere Einsatzmöglichkeiten der hier aufgezeigten Funktion bestehen z.B. in der Erstellung und Übermittlung von offenen Kunden-/Lieferanten-Kontopositionen, Saldenbestätigungen, der Anforderung von Informationen wie Bankdaten, Zertifikaten, usw.
Die nachfolgenden Darstellungen zeigen Schrittweise auf, wie eine Dokumentenvorlage für die Übermittlung von Zahlungsinformationen an Lieferanten genutzt werden kann.
Schritt 1: Parameter für die Dokumentenverwaltung
In den Dokumentenverwaltungsparametern im Organisationsverwaltungsmodul ist zunächst sicherzustellen, dass eine Position für MS Word Templates aufgeführt ist.
Schritt 2: Einrichtung von Abfragen
Für die Darstellung der Dynamics AX Werte im Dokument das später an den Lieferanten gesendet wird ist es erforderlich, dass entsprechende Abfragen im AOT angelegt sind. Für das hier aufgeführt Beispiel wurde die standardmäßig verfügbare Abfrage „Vend“ zweifach dupliziert. Das erste Duplikat wurde lediglich in „Vend_VendTrans“ umbenannt. Das zweite Duplikat wurde in „Vend_VendTrans_VendSettlement“ umbenannt und um die Tabelle VendSettlement erweitert, wie dies im folgenden Screenshot dargestellt ist. 
Hinweis: Wichtig bei den hier verwendeten Abfragen ist, dass die erste Tabelle – im obenstehenden Screenshot „VendTable“ – gleichlaufend mit dem Bereich angelegt wird, in welche die Dokumentenvorlage eingebunden wird.
Schritt 3: Einrichtung von Dokumentendatenquellen
Im nächsten Schritt sind die eingerichteten Abfragen als Dokumentendatenquellen im Organisationsverwaltungsmodul zu hinterlegen. Bei dieser Hinterlegung ist darauf zu achten, dass als Datenquellentyp „Abfragereferenz“ ausgewählt ist.
Schritt 4: Einrichtung der MS Word-Vorlage
Schließlich kann basierend auf den eingerichteten Dokumentendatenquellen über das MS Dynamics AX Addin auf die eingerichteten Abfragen referenziert werden. 
Nachdem die Abfragen ausgewählt wurden, können die im Dokument dargestellten Daten per drag & drop in das entsprechende Dokument eingefügt werden. Im Beispiel wurde dies derart realisiert, dass die entsprechenden Felder in MS Word Tabellen eingebunden wurden. 
Im Rahmen der Erstellung der Vorlage sind folgende Besonderheiten zu beachten:
Im oberen Bereich der Vorlage wurden die Belegnummer, das Belegdatum, usw. aus der Abfrage „Vend_VendTrans“ verwendet, was durch die blau hervorgehobene Überschrift gekennzeichnet ist. Um an dieser Stelle lediglich Zahlungen auszuweisen wurde für die Abfrage ein entsprechender Filter auf den Transaktionstyp „Payment“ eingerichtet. Um nicht alle Zahlungen die in der Vergangenheit an einen bestimmten Lieferanten geleistet wurden in dem Dokument aufzunehmen, wurde zudem in einer eigenen Dokumentenversion ein Datumsfilter eingefügt, der dafür sorgt, dass lediglich Zahlungen der letzten sieben Tage ausgewiesen werden. 
Im unteren Bereich der Vorlage wird auf die Abfrage „Vend_VendTrans_VendSettlement“ referenziert, was ebenfalls durch eine blau hervorgehobene Überschrift gekennzeichnet ist. Um im unteren Dokumentenbereich lediglich die Rechnungsinformationen zu den oben aufgeführten Zahlungen anzuzeigen wurde schließlich auch für die zweite Abfrage ein Filter definiert, der dafür Sorge trägt, dass lediglich entsprechende Rechnungen aufgeführt werden. Darüber hinaus wurde auch hier ein entsprechender Datumsfilter eingefügt um die Anzahl der anzuzeigenden Zahlungen zu begrenzen. 
Das so erstellte Vorlagendokument wurde schließlich als Word-Template abgespeichert. 
Schritt 5: Hinterlegung der Dokumentenvorlage auf Sharepoint
Anschließend wurde die Dokumentenvorlage in einer eigens eingerichteten Dokumentenbibliothek auf Sharepoint abgespeichert. 
Schritt 6: Einrichtung Dokumententypen
Nach der Speicherung der Dokumentenvorlage kann diese schließlich im Organisationsverwaltungsmodul mit dem Dynamics AX Client synchronisiert werden. Hierbei ist darauf zu achten, dass die entsprechende Sharepoint Seite und die verwendete Dokumentenbibliothek korrekt referenziert und die Vorlagendokumente für die Nutzung in Dynamics AX aktiviert werden. 
Schritt 7: Nutzung der Vorlage
Nach Durchführung all dieser Schritte kann schließlich die Dokumentenvorlage über die Kreditorenseite aufgerufen werden. 
Im hier verwendeten Beispiel wurden zwei Vorlagen verwendet – eine für die Anzeige alle durchgeführten Zahlungen und eine für die Anzeige aller Zahlungen der letzten sieben Tage. Über die Beleg und Ausgleichsbelegnummer können nun die einer bestimmten Zahlung zugeordneten Rechnung identifiziert werden. 
Derart generierte Dokumente können schließlich z.B. als Emailanhang über die Standard MS Office Funktionen an Lieferanten übermittelt werden.
Zu beachten ist, dass die Dokumente automatisch als Dokumenten-Anhang am Kreditorenstammsatz abgespeichert werden. Dies erweist sich als hilfreich, da man später einfach nachvollziehen kann zu welchem Zeitpunkt bestimmte Informationen generiert und übermittelt wurden. 
Zusammenfassend lässt sich an dieser Stelle festhalten, dass es nicht immer erforderlich ist für zu erstellende Berichte Kollegen aus der IT-Abteilung einzubinden, sondern dass diese auch selbständig von Endanwendern erstellt und genutzt werden können. Auch wenn es sich hierbei nicht um eine Ideallösung handelt, eignen sich derartige Dokumentenvorlagen nach Meinung des Verfassers zumindest für einfache und in unregelmäßigen Zeitabständen wiederkehrende Dokumente, welche an externe Stakeholder des Unternehmens zu übermitteln sind.
