Mehrere Payment_due_date (Skonto) und pdf-Visualisierung

[Thomas Sporbeck]

Hallo,

wir haben relativ viele E-Rechnungen mit mehreren Payment_due_dates aufgrund von Skontokonditionen. Das führt bei Konvertierung nach .pdf (machen wir zur optionalen Anzeige) mit der Version 2.15.2 zu einem Fehler im Stylesheet content-templates.xsl.

Ich habe mir erlaubt, das Stylesheet entsprechend zu erweitern, s. Anlage ab Zeile 197.

Vielleicht kann man das in die Standardversion aufnehmen. Es geht möglicherweise noch etwas eleganter aber meine Version funktioniert immerhin.

Grüße
Thomas Sporbeck

[Joachim Tuchel]

Hallo,

ich bin jetzt etwas verwirrt. Abetr das muss nichts heißen, ich bin selbst mehr Suchender als Wissender.
Geht es hier um das Feld BT-9 Payment Due Date? Die Kardinalität dieses Felds ist laut EN 16931 und auch nach XRechnung-Standard 0..1. 

Zudem war ich bisher auf dem Stand, dass Skonto in EN 16931 derzeit nicht abbildbar ist, und dass entweder XRechnung oder ZUGFeRD (ich habe da den Überblick etwas verloren) in irgendeinem Profil so eine mehr oder weniger textuelle Darstellung in einem "Standardformat" in den Payment Terms (iuch sag mal) vorschlägt. Aber ein Payment Due Date ist nach meinem bisherigen betrebswirtschaftlichen Verständnis heraus auch nicht wirklich mit einem Skonto verbunden. Skonto ist ja nur ein Angebot, etwas zu sparen, indem man schneller bezahlt, aber keine Fälligkeit....

Für mich klingt das ein bisschen, als wenn Ihr da mit etwas hantiert, das nicht dafür gedacht ist. Validiert denn eine XML-Rechnung mit mehreren Payment Due Dates erfolgreich, etwa im Mustang CLI oder anderen Validatoren?

Grundsätzlich finde ich es super, dass Du / Sie mit einem konkreten Fix bzw. Verbesserungsvorschlag hier poste[st/n]. Das tun wir alle viel zu wenig.
Ich denke aber, der Vorschlag wäre an anderer Stelle besser aufgehoben (nämlich dort, wo die EN 16931 erarbeitet wird: Technisches Komitee CEN/TC 434).

Joachim

[Thomas Sporbeck]

Hallo Joachim,

Danke zunächst für die auch aus meiner Sicht fachlich korrekte Darstellung der EN 16931.

Wir sind ja bei EXSO. überwiegend auf der Seite der automatischen Verarbeitung von Eingangsrechnungen aktiv und wir begleiten aktuell natürlich eine Anzahl von Projekten, die unsere Lösung einsetzt.

Dabei ist uns eine Vielzahl von eingehenden E-Rechnungen aufgefallen, die allesamt XML-Inhalte wie den folgenden enthalten (es gibt Projekte, in denen ungefähr die Hälfte aller von verschiedensten Lieferanten eingehenden E-Rechnungen so aussieht):

<ram:SpecifiedTradePaymentTerms>
<ram:Description>Zahlbar netto bis zum 15.01.25</ram:Description>
<ram:DueDateDateTime>
<udt:DateTimeString format="102">20250115</udt:DateTimeString>
</ram:DueDateDateTime>
</ram:SpecifiedTradePaymentTerms>
<ram:SpecifiedTradePaymentTerms>
<ram:Description>Zahlbar bis zum 30.12.24 abzueglich 3.00% Skonto Zahlbar Netto bis zum 15.01.25</ram:Description>
<ram:DueDateDateTime>
<udt:DateTimeString format="102">20241230</udt:DateTimeString>
</ram:DueDateDateTime>
<ram:ApplicableTradePaymentDiscountTerms>
<ram:BasisAmount currencyID="EUR">1711.9300</ram:BasisAmount>
<ram:CalculationPercent>3.00</ram:CalculationPercent>
<ram:ActualDiscountAmount currencyID="EUR">51.36</ram:ActualDiscountAmount>
</ram:ApplicableTradePaymentDiscountTerms>
</ram:SpecifiedTradePaymentTerms>

Die HTML-Visualisierung in Mustang stellt beide Datumswerte in ein und demselben Feld lesbar dar, lediglich bei der Konvertierung über FOP zu PDF gibt es eine Fehlermeldung, die darauf zurückzuführen ist, dass der vorhandene Feldinhalt am im Stylesheet erwarteten Datumsformat ("dd.MM.yyyy") scheitert.

Unsere Anwender erwarten mit großer Sicherheit, dass eine solche Rechnung zumindest angezeigt wird - aber im Grunde erwarten sie auch, dass sie in irgendeiner sinnvollen Weise verarbeitet wird.

Natürlich könnte man alle diese E-Rechnungen ablehnen mit dem Hinweis, sie entsprächen nicht der EN 16931. Dann hätten wir uns 8 Zeilen Code gespart, aber vermutlich jede Menge Beschwerden eingehandelt.

Ich gehe davon aus, dass ein "größerer" Hersteller von ERP-Systemen die Skonto-Thematik auf diese Weise implementiert hat. 

Ob dieser Hersteller seinen Anwendern nun mitteilen kann, die EN 16931 unterstütze nun einmal nur ein Zahlungsdatum oder ob kurzfristig Änderungen der EN 16931 erfolgen, kann und will ich nicht beurteilen. 

Ich breche daher - wie ich das immer tue und auch schon oft dafür geprügelt wurde - eine Lanze für den Pragmatismus.

Grüße
Thomas

[jochen...@gmail.com]

Hi,

ich halte es für sinnvoll zwischen der Visualisierung und der Validierung (mustang-cli --action validate) zu unterscheiden und erst bei erfolgloser Validierung die Beweislast umzukehren. Bei einer XRechnung basiert zwar beides weitestgehend auf Kosit-Quellen, die Visualisierung auf den XSLTs und die Validierung auf den (in XSLT umgewandelten Schematron-Dateien) aber es kann durchaus Fehler in beiden Komponenten geben und dem Lieferanten eine Rechnung um die Ohren zu hauen weil man selbst nicht in der Lage ist sie richtig zu visualisieren halte ich für nicht fair. Bug resports gerne in die Issues ich upstreame ggf..

ciao

Jochen

[Thomas Sporbeck]

Hallo,

perfekt, genau so sehe ich das auch, daher hatte ich das geänderte Template überhaupt gepostet.

Grüße
Thomas Sporbeck

[Joachim Tuchel]

Hallo,

tja, natürlich macht es Sinn, erstmal anzeigen zu können, was da reinkommt, und letztlich muss der Anwender ja entscheiden, ob diese Rechnung nachher bezahlt wird, oder nicht. Er muss ja auch verantworten, wenn eine Außenprüfung hier beanstandungen findet. 

Wir sehen ja auch alle möglichen Rechnungen, die nicht so recht ins Bild passen. Wir sind auch noch auf der Suche nach dem korrekten Umgang mit z.B. älteren ZUGFeRD-Rechnungen im EXTENDED-Profil. Es steckt alles an Pflichbetsandteilen drin, aber es ist eben keine EN-16931 - konforme Rechnung. Für 2025 ist das ja alles noch relativ unkritisch, und vielleicht muss man einfach gelassen an die Sache rangehen und darauf setzen, dass sich die offenen Themen jetzt in den kommenden Monaten zurecht rütteln.

Interessant ist dennoch die Frage, wie man jetzt mit etwas umgeht, das in einer Rechnung steckt, was über den Standard hinaus geht. Im konkreten Fall: wann ist eine Rechnung wirklich fällig, wenn ein "überschüssiges" Fälligkeitsdatum ankommt?

Wir haben gerade konkret die Anforderung auf dem Tisch, Unterzeilen und Ziwschensummenzeilen in eine E-Rechnung zu packen. Verständliche und sehr praxisrelevante Anforderung, mMn. Aber eben nicht in EN 16931 abzubilden, so weit ich das verstehe. Ganz anderes Thema. aber auch spannend.

Joachim

[jochen...@gmail.com]

Hallo,

>Interessant ist dennoch die Frage, wie man jetzt mit etwas umgeht, das in einer Rechnung steckt, was über den Standard hinaus geht. Im konkreten Fall: wann ist eine Rechnung wirklich fällig, wenn ein "überschüssiges"

>Fälligkeitsdatum ankommt?

Halte ich nicht für fällig, dafür ist die Norm da zu sagen zahle das bis dann.

[Joachim Tuchel]

Hallo Jochen,

ich verstehe Deinen Kommentar ehrlich gesagt nicht. Was willst Du damit sagen?

Wie ist das nun Deiner Meinung nach, wenn eine Rechnung sowohl nach 14 als auch nach 30 Tagen zur Zahlung fällig ist? PaymentDueDate bedeutet übersetzt ja Fälligkeitsdatum.

Der OP hat ja ausgeführt, dass es in der von ihm angesprochenen Rechnung eigentlich um das Datum geht, bis zu dem man zahlen kann, um Skonto abziehen zu dürfen. Das ist aber nicht das Fälligkeits-Datum der Rechnung. Man kommt nicht in Verzug, wenn man dieses Datum verstreichen lässt, ohne zu zahlen.

Wie soll man beim Einlesen einer solchen Rechnung vorgehen? Ist das späteste Datum die "echte" Fälligkeit? Das zuletzt eingelesene? Wo findet man Details dazu, was das "unechte" Fälligkeitsdatum ist.

Ich habe inzwischen verstanden, dass es zwar nicht normgerecht, aber bei Vorliegen einer Verainbarung zwischen Rechnungssteller und Empfänger okay ist, wenn man sich nicht an die EN16931 hält, das ist gar nicht mehr meine Frage (obwohl das natürlich einen riesen Sack an neuen fragen aufwirft), sondern die Frage ist: was mache ich als Rechnungen einlesender mit sowas?

Joachim

[jochen...@gmail.com]

Hallo,

EN16931 sagt, dass ich bis zum Due Date zu zahlen habe und sieht kein Skonto vor. 

Die XRechnung sieht ein Skonto in eigener Notation vor,

Factur-X Extended verwendet die in CII definierten XML-Felder für Skonto. Factur-X Extended setzt eine bilaterale Vereinbarung voraus. 

Und die Inanspruchnahme von Skonto ist auch eine bilaterale Vereinbarung (ausgelöst durch Konkludenten handeln).

In allen Fällen ist die Rechnung meines Erachtens erst ab dem DueDate wirklich "fällig" i.S.v. mahnbar.

mit freundlichen Grüßen

Jochen Stärk

[Joachim Tuchel]

Hallo Jochen,

alles richtig (und ärgerlich, was die Abbildung von Skonto in den diversen Formaten angeht).

Aber meine Ursprungsfrage ist, was man tut, wenn 2 unterschiedliche DueDates in einer Rechnung stehen.

Dass der Lieferant in diesem Falle seine eigene (uni- oder bilaterale) Auffassung von der Abbildung von Skonto umsetzt, ist ja zunächst mal immer dann eher problematisch, wenn der Lieferant groß ist und ich klein. Natürlich kann ich meine Steinschleuder auspacken und dem Goliath breitschultrig eröffnen, dass ich diese Rechnung nicht akzeptiere/zahle. Er wird halt sein uncharmantestes Lächeln aufsetzen und mir viel Spaß mit seinem Inkasso-Büro wünschen und das war's dann.

So weit, so gut, wenn ich ein großes Unternehmen bin und meine IT-Abteilung so schöne Sonderregeln im Rechnungseingangsprozess reinbasteln kann. Wenn das aber nicht so ist, kann die Lösung ja auch nicht sein, dass Software auf sowas vorbereitet sein muss...? Das führt doch eine Norm letztlich ad absurdum.

Joachim

Am 13.02.25 um 14:17 schrieb jochen...@gmail.com:

--
You received this message because you are subscribed to a topic in the Google Groups "ZUGFeRD" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/zugferd/Iq8MdW3Kd1o/unsubscribe.
To unsubscribe from this group and all its topics, send an email to zugferd+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/zugferd/02483cd9-1e6d-4b3c-a653-6b147a8f984fn%40googlegroups.com.

-- 

----------------------------------------------------------------------- 
Objektfabrik Joachim Tuchel              mailto:jtu...@objektfabrik.de 
Fliederweg 1                                 http://www.objektfabrik.de
D-71640 Ludwigsburg                  http://joachimtuchel.wordpress.com
Telefon: +49 7141 56 10 86 0                    Fax: +49 7141 56 10 86 1