Vor kurzem hat mich ein Kollege danach gefragt, wie die in der Inkassimaske (siehe die folgende Abbildung) angezeigten Werte ermittelt werden und wie man diese Werte mit den im Standard verfügbaren Kundenberichten abgleichen kann. Da ich auf Anhieb keine Antwort parat hatte, habe ich verschiedene Tests durchgeführt, die ich in diesem Beitrag aufgenommen habe, weil ich annehme, das der ein oder andere bestimmt auf ähnliche Probleme bzw. Fragestellungen stößt.

Abschnitt 1: Berechnung der angezeigten Werte
Um die Beträge, welche in der Spalte „Saldo fälliger Beträge“ der Inkassimaske angezeigt werden nachvollziehen zu können habe ich zunächst den periodischen Verarbeitungsprozess „Fälligkeitsmomentaufnahme für Debitor“, wie in den beiden folgenden Screenshots dargestellt, für den 31. Dezember 2012, 31. Dezember 2013 und den 31. Dezember 2014 aufgerufen.

Nachdem die Berechnungen durchgelaufen waren, habe ich die Ergebnisse nach Excel exportiert und jeweils die Summe der in der Spalte „Saldo fälliger Beträge“ angezeigten Werte gebildet (siehe den folgenden Screenshot).

Interessanterweise erhielt ich immer die gleiche Gesamtsumme, so dass ich zunächst von einem Fehler im Aufruf bzw. der Verarbeitung des Berechnungsprozesses ausging.

Nachdem ich die aufgezeigten Tests allerdings in anderen System wiederholt habe und dort auf das gleiche Phänomen gestoßen bin, habe ich den Programmcode in der Klasse CustAgingSnaphot sowie die Informationen auf der folgenden TechNet Seite geprüft.

Ergebnis dieser Prüfung war, dass Dynamics AX in der Spalte „Saldo fälliger Beträge“ grundsätzlich immer den Gesamtsaldo aller aktuell offenen Kundentransaktionen anzeigt und zwar vollkommen unabhängig davon welche Auswahl im „Fälligkeit per…“ Datumsfeld beim Aufruf des periodischen Verarbeitungsprozesses getroffen wird.

Interessanterweise werden in der Inkassimaske auch solche Transaktionen angezeigt, die in zukünftigen Perioden erfasst wurden. Um dies zu verifizieren habe ich eine Freitextrechnung über 1000 USD mit den folgenden Datumswerten erfasst und gebucht.

Nach Buchung dieser Freitextrechnung habe ich den periodischen Verarbeitungsprozess erneut mit den folgenden Einstellungen gestartet…

… um in der Inkassimaske festzustellen, dass auch die Transaktion mit dem Buchungsdatum „01. Januar 2016” enthalten ist. Siehe den folgenden Screenshot.
Die letzte Prüfung, die ich in diesem Zusammenhang durchgeführt habe bestand darin den periodischen Verarbeitungsprozess mit einer anderen Zahlungsfristdefinition durchzuführen. Doch auch hier erhielt ich das gleiche Ergebnis wie zuvor.
Nach der Prüfung welche Werte in der Spalte „Saldo fälliger Beträge“ angezeigt werden, habe ich weitere Tests durchgeführt um zu prüfen welchen Einfluss die Einstellungen im Kriterienbereich und im „Fälligkeit per“ Datumsfeld haben. Siehe hierzu die folgenden fünf „Test-runs“.

Test run 1:
Zunächst habe ich den periodischen Verarbeitungsprozess mit den folgenden Einstellungen gestartet:Ergebnis test run 1:
Wie erwartet und bereits weiter oben festgestellt ist die am 01 Januar 2016 gebuchte Rechnung in der Inkassimaske enthalten und wird in der Spalte “not due / nicht fällig” angezeigt.

Test run 2:
Im Rahmen des zweiten Testlaufs habe ich den periodischen Verarbeitungsprozess mit dem Buchungskriterium „31. Januar 2016“ gestartet, da die gebuchte Freitextrechnung an diesem Tag 30 Tage dem Buchungsdatum entsprechend überfällig ist und demnach in der 30-Tage Spaltet auftauchen sollte.
Ergebnis test run 2:
Wie auch hier erwartet, wird nun der Betrag in der Spalte „30 days“ angezeigt.

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

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

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

Zusammenfassend kann somit an dieser Stelle als Zwischenergebnis festgehalten werden, dass das Kriterium (Buchungsdatum, Fälligkeitsdatum oder Dokumentendatum) und das „Fällig per“ Datumsfeld lediglich einen Einfluss darauf haben in welcher Fälligkeits-Spalte ein bestimmter Betrag angezeigt wird. Die beiden Feldeinstellungen haben allerdings keinerlei Einfluss darauf ob und was in der Spalte „Saldo fälliger Beträge“ aufgeführt wird, da hier grundsätzlich alle aktuell offenen Kundentransaktionen enthalten sind.

 

Abschnitt 2: Abstimmung der angezeigten Werte
Die Tatsache, dass die Inkassimaske alle aktuell offenen Kundentransaktionen enthält und hierbei auch in der Zukunft gebuchte Transaktionen beinhaltet erlaubt es nicht die in dieser Maske angezeigten Werte mit einem Bericht abzustimmen, welcher Kundentransaktionen zu einem bestimmten Stichtag in der Vergangenheit anzeigt.

Aufgrund dessen besteht die einzige Möglichkeit der Abstimmung darin einen der im Standard verfügbaren Berichte entweder zum aktuellen Tagesdatum oder – bei bereits in zukünftigen Perioden gebuchten Transaktionen – zu einem in der Zukunft liegenden Datum abzustimmen nach dem keine weiteren Buchungen durchgeführt wurden. Ein Beispiel für eine solche mögliche Abstimmung ist im folgenden Screenshot festgehalten.

Abschließend kann somit als Ergebnis festgehalten werden, dass die Inkassimaske grundsätzlich immer alle aktuell offenen Kundentransaktionen beinhaltet und es regelmäßig nicht möglich ist die hier angezeigten Werte mit einem Bericht abzustimmen der diese Transaktionen zu einem bestimmten Stichtag in der Vergangenheit anzeigt.