search

ZUGFeRD / mustangproject

Open Source Java e-Invoicing library, validator and tool (Factur-X/ZUGFeRD, UNCEFACT/CII XRechnung)
http://www.mustangproject.org
Apache License 2.0
204 stars 114 forks source link

Validierungsfehler bei mehrfacher Angabe von "ReceivableSpecifiedTradeAccountingAccount" im Extended-Profile #279

Open Alpini1980 opened 2 years ago

Alpini1980 commented 2 years ago

Hallo,

ich bin mir hier nicht sicher, ob es ein Problem im Mustangproject ist (ich vermute nicht), oder ich die ZUGFeRD-Doku falsch verstehe (gut möglich), oder es ein Bug in der Schematron-Datei oder der ZUGFeRD-Dokumentation ist:

Beim Validieren unserer Testrechnung (mit Extended-Profile) erhalte ich zwei Meldungstypen, die beide die gleiche Ursache haben - die mehrfache Angabe von receivablespecifiedtradeaccountingaccount in den Rechnungspositionen:

Einmalig kommt diese Meldung (die Zeile 58 entspricht dem 2. Vorkommen des ram:ReceivableSpecifiedTradeAccountingAccount bei der ersten Rechnungsposition): 2022-07-20 14:52:10.743 [main] ERROR o.m.validator.ZUGFeRDValidator - Error 18: schema validation fails:org.xml.sax.SAXParseException; lineNumber: 58; columnNumber: 56; cvc-complex-type.2.4.d: Invalid content was found starting with element 'ram:ReceivableSpecifiedTradeAccountingAccount'. No child element is expected at this point.

Sich wiederholend für jede Rechnungsposition diese Meldung: 2022-07-20 14:52:33.344 [main] INFO o.m.validator.XMLValidator - FailedAssert 2022-07-20 14:52:33.358 [main] ERROR o.m.validator.ZUGFeRDValidator - Error 4: Element 'ram:ReceivableSpecifiedTradeAccountingAccount' may occur at maximum 1 times. (From /xslt/ZF_220/FACTUR-X_EXTENDED.xslt)

Aus der ZUGFeRD-Dukumentation "ZUGFeRD-2.1.1 - Spezifikation_TA.pdf" lese ich zum "receivablespecifiedtradeaccountingaccount" auf Seite 53 Folgendes heraus:

Datentyp: ram:TradeAccountingAccountType: Kardinalität: 0 .. unbounded Verwendung im Extended Profil zugelassen, ohne eine abweichende Kardinalität:

Zusammenfassend würde ich meinen, dass die mehrfache Angabe des "receivablespecifiedtradeaccountingaccount" laut Doku im Extended-Profil erlaubt ist und wundere mich über die Validierungsfehler. Wir verwenden die doppelte Angabe des receivablespecifiedtradeaccountingaccount zur Angabe einer Kostenstelle sowie eines internen Buchungskontos des Kunden.

Unsere .xml sieht wie folgt aus (auf das Wesentliche reduziert):

<rsm:SupplyChainTradeTransaction>
  <ram:IncludedSupplyChainTradeLineItem>
    <ram:SpecifiedLineTradeSettlement>
      <ram:ReceivableSpecifiedTradeAccountingAccount>
        <ram:ID>10.3</ram:ID>
        <ram:TypeCode>2</ram:TypeCode>
      </ram:ReceivableSpecifiedTradeAccountingAccount>
      <ram:ReceivableSpecifiedTradeAccountingAccount>
        <ram:ID>9630000019</ram:ID>
        <ram:TypeCode>1</ram:TypeCode>
      </ram:ReceivableSpecifiedTradeAccountingAccount>
    </ram:SpecifiedLineTradeSettlement>
  </ram:IncludedSupplyChainTradeLineItem>
</rsm:SupplyChainTradeTransaction>

Ich würde mich freuen hier andere Meinungen zu hören.

Viele Grüße, Stefan Wagner

jstaerk commented 2 years ago

Hallo, mit einem kompletten XMl-Beispiel kann ich das gerne mal upstreamen, nur ein Hinweis: im Extended-Profil ist das wirklich 0..n aber im EN16931-Profil ist es wohl 0..1 vgl image

Da sich die validierermeldung allerdings bereits explizit auf Extended bezieht ist das wahrscheinlich tatsächlich ein Fehler in den Schematrons.

msccip commented 2 years ago

Hallo, in ZUGFeRD 2.1 war es noch analog der Dokumentation deklariert. In 2.2 fehlt die Angabe maxOccurs="unbounded":

grafik

grafik

s. jeweils FACTUR-X_EXTENDED_urn_un_unece_uncefact_data_standard_ReusableAggregateBusinessInformationEntity_100.xsd

Alpini1980 commented 2 years ago

Hallo Jochen,

hier gezippt eine komplette .xml Anlage (anonymisiert) mit mehreren ReceivableSpecifiedTradeAccountingAccount's:

zugferd-invoice.zip

Werden die Schematron-Dateien eigentlich auch in einem Github-Projekt gepflegt, so dass man es dorthin upstreamen bzw. als issue melden kann? Ansonsten schon einmal besten Dank für's weitermelden. Aber selbst wenn der Fehler korrigiert wird, frage ich mich in welcher Form das erfolgen würde. Bei einer Korrektur in Version 2.2 müsste ja jeder Verwender die Schema-Dateien neu herunterladen?

@msccip: interessante Entdeckung, dass es in der älteren Version schon einmal mit der Doku konform war. Danke für den Hinweis.

Viele Grüße, Stefan Wagner

jstaerk commented 2 years ago

Hallo, es könnte in den nächsten Monaten wohl ein ZUGFeRD 2.2.1 Version geben und ich kann nur hoffen dass es dabei korrigiert wird. Meines Wissens wird der öffentliche Governance-Prozess überarbeitet, und das Gitlab ist derzeit leider auch noch nicht geöffnet, das heißt ein Upstream wäre nur per mail an die info@ferd-net.de möglich. Da die Schematron-Dateien aber generiert werden müsste aber selbst eine korrigierte Schematrondatei erstmal nachbearbeitet werden um nachhaltig zu werden.

msccip commented 2 years ago

@Alpini1980 Ich habe mir Ihre Beispieldatei auch mal angesehen. Sie geben ja dort für jede Rechnungsposition dieselben 2 ReceivableSpecifiedTradeAccountingAccounts an. Ich weiß ja nicht, ob das immer so ist, aber falls ja, können Sie die Angabe auch auf Rechnungsebene machen. Dort ist auch unter 2.2 die Deklaration korrekt (maxOccurs="unbounded).

grafik

msccip commented 2 years ago

auch interessant: https://www.zugferd-community.net/forum/viewtopic.php?f=4&t=149

hier ist das Extended-Profil korrekt aber zumindest in EN16931 fehlt auch hier seit 2.2 maxOccurs="unbounded"

Alpini1980 commented 2 years ago

...leider nein, das ist nicht immer so, sondern nur in dem stark gekürzten Beispiel. Das stimmt, in dem Beispiel könnte das über eine einmalige Angabe beider Felder im Header gelöst werden.

Im Normalfall haben unsere Rechnungen aber schnell 5000 Positionen pro Monat, die sich dann auf 50-100 Kostenstellen und bis zu 25 kundeninterne Sachkonten verteilen können. In Papier bzw. PDF-Form sind das dann schnell viele hunderte Seiten, in welchen dann pro Sachkonto und Kostenstelle Zwischensummen enthalten sind.

Alpini1980 commented 2 years ago

hier ist das Extended-Profil korrekt aber zumindest in EN16931 fehlt auch hier seit 2.2 maxOccurs="unbounded"

Ich kann den Link mangels Registrierung in dem Forum zwar nicht öffnen, aber da ohne maxOccurs-Angabe ja "1" als default genutzt wird, stimmt es ja dann für das EN 16931 Profil, da dieses ja die abweichende Kardinalität 0..1 hat (siehe 2. Beitrag). Oder verstehe ich etwas falsch?

msccip commented 2 years ago

in diesem Fall geht es die Bankverbindungen:

Alpini1980 commented 2 years ago

Diese sind aber ausschließlich dem "ApplicableHeaderTradeSettlement" untergeordnet und können nicht pro Position angegeben werden. Angegeben werden in den "SpecifiedTradeSettlementPaymentMeans" die verfügbaren Konten des Zahlungsempfängers,

msccip commented 2 years ago

@Alpini1980 Ja, aber im EN16931 kann man entgegen der Spezifikation nur eine Bankverbindung angeben. Es ist letztlich derselbe Fehler, wie bei Ihrem Problem: es fehlt im 2.2 der maxOccurs="unbounded":

2.1 richtig (0..n): grafik

2.2 falsch (0..1): grafik

Alpini1980 commented 2 years ago

Sorry, jetzt habe ich erst verstanden worum es geht (und konnte es vorher nicht, ohne die Forenbeiträge zu sehen). Es wurde der gleiche Fehler noch bei einem weiteren Element (SpecifiedTradeSettlementPaymentMeans) gemacht und nun kann in der 2.2 beim EN 16931-Profil nur noch eine Bankverbindung angegeben werden, obwohl vorher eine unbegrenzte Anzahl erlaubt war.

jstaerk commented 2 years ago

Ja. Und das ist ein Fehler in den offiziellen Prüfdateien die von ZUGFeRD veröffentlicht werden und nicht im Mustang Validierer der sie nur anwendet (deren Issue 123). Da das ein vergleichsweise dramatischer Fehler ist gehe ich fast davon aus, dass die Behebung im entsprechenden Meeting am Freitag in einer Woche für ZUGFeRD 2.2.1 eingeplant werden wird.