Der Ivan hier aus dem Forum hatte mir vor einigen Tagen seine XML-Datei zum Test zur Verfügung gestellt, damit ich einmal meinen installierten Validator darüber laufen lassen kann. Dabei ist herausgekommen, dass die von Fakturama erzeugten XML-Dateien offensichtlich nicht valide sind und so nicht die E-Rechnungspflicht erfüllen, weil dazu geraten wird, diese nicht zu akzeptieren!
Da ich heute nun selbst Fakturama auf Ubuntu ans Laufen bekommen habe, konnte ich nun selbst eine PDF mit XML-Anhang erzeugen und habe diese XML-Datei ebenfalls über den Validator laufen lassen. Auch diese XML-Datei ist ungültig, weil der "Dokumenttyp" nicht erkannt wird.
Hier liegt offensichtlich ein Fehler in der Definition des Dokumenttyp vor. Sehr wahrscheinlich nur eine Kleinigkeit.
Wer seine Dokumente selbst einmal überprüfen möchte, kann es hier machen:
https://erechnungsvalidator.service-bw.de/
Bei der im ZUGFeRD- PDF enthaltenen XML handelt es sich nicht um eine XRechnung, auch wenn sich beide Formate sehr ähnlich sind. Da der von dir verlinkte E-Rechnungs-Validator nur gem. XRechnungs- Standard prüft, ist es demnach logisch das der Dokumentyp als nicht Valide ermittelt wird.
Fakturama 2.1.3 auf Win10 pro x64 an MariaDB auf ner DiskStation
@lastboyscout Ich arbeite seit längerer Zeit an einem System, welches unter anderem auch die XML-Dateien im Rahmen der E-Rechnungen prüft und hier gibt es einen offiziellen Validator, der die verschiedenen Formate testet und da fallen sämtliche mit Fakturama erzeugten Dateien durch. Gerne kannst Du es einmal hier selber testen: https://validator.invoice-portal.de/result.php
So sieht der obere Teil der XML-Datei aus Fakturama aus:
<rsm:CrossIndustryInvoice xmlns:qdt="urn:un:unece:uncefact:data:standard:QualifiedDataType:100" xmlns:ram="urn:un:unece:uncefact:data:standard:ReusableAggregateBusinessInformationEntity:100" xmlns:rsm="urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100" xmlns:udt="urn:un:unece:uncefact:data:standard:UnqualifiedDataType:100">
<rsm:ExchangedDocumentContext>
<ram:GuidelineSpecifiedDocumentContextParameter>
<ram:ID>urn:cen.eu:en16931:2017#compliant#urn:xoev-de:kosit:standard:xrechnung_2.1</ram:ID>
</ram:GuidelineSpecifiedDocumentContextParameter>
</rsm:ExchangedDocumentContext>
<rsm:ExchangedDocument>
<ram:ID>RE-000001</ram:ID>
<ram:TypeCode>380</ram:TypeCode>
<ram:IssueDateTime>
<udt:DateTimeString format="102">20241129</udt:DateTimeString>
</ram:IssueDateTime>
-------------------
Und dies ein oberer Teil aus einer offiziellen "funktionierenden" Version:
In der aktuellen Version 2.1.3c verwendet Fakturama noch den ZUGFeRD-Standard in der Version 2.1 (Comfort). Es bedarf also eines Validator welches auch dieses Format prüfen kann (Der Invoice-Portal Validator tut dies nicht).
In der kommenden Version 2.2.0 sollen auch die Programmteile zu Erzeugung von eRechnungen aktualisiert werden, so das dann vermutlich aktuelle Standards untersetzt werden.
Fakturama 2.1.3 auf Win10 pro x64 an MariaDB auf ner DiskStation
@lastboyscout Dies wirft der aktuelle und offizielle Validator von KoSIT aus:
Konformitätsprüfung: Das geprüfte Dokument entspricht keinem zulässigen Dokumenttyp und ist damit nicht konform zu den formalen Vorgaben.
Übersicht der Validierungsergebnisse:
| Prüfschritt | Fehler | Warnungen | Informationen |
|---|---|---|---|
| (val-xml) | 1 | 0 | 0 |
Validierungsergebnisse im Detail:
| Pos | Code | Adj. Grad | Text |
|---|---|---|---|
| val-xml.1 | generic-error | error | IOException while reading resource /tmp/ramdisk/x/scanbymail_20241203_1.xml: org.xml.sax.SAXParseException; systemId: file:///tmp/ramdisk/x/scanbymail_20241203_1.xml; lineNumber: 91; columnNumber: 21; Auf "&" in der Entityreferenz muss umgehend der Entityname folgen. |
Bewertung: Es wird empfohlen das Dokument zurückzuweisen. Da kein Pruefszenario gegriffen hat.
Hi, ich nutze die Beta 2.2 seit Mai.
der Validator spuckt mir folgenden Report aus:
Übersicht der Validierungsergebnisse:
| Prüfschritt | Fehler | Warnungen | Informationen |
|---|---|---|---|
| XML Schema for UN/CEFACT XML (SCRDM - CII uncoupled) (val-xsd) | 0 | 0 | 0 |
| Schematron rules for EN16931 (CII) (val-sch.1) | 1 | 0 | 0 |
| Schematron rules for CIUS XRechnung (CII) (val-sch.2) | 1 | 3 | 0 |
| (val-xml) | 0 | 0 | 0 |
Validierungsergebnisse im Detail:
| Pos | Code | Adj. Grad | Text |
|---|---|---|---|
| val-sch.1.1 | BR-CO-09 | error | [BR-CO-09]-The Seller VAT identifier (BT-31), the Seller tax representative VAT identifier (BT-63) and the Buyer VAT identifier (BT-48) shall have a prefix in accordance with ISO code ISO 3166-1 alpha-2 by which the country of issue may be identified. Nevertheless, Greece may use the prefix ‘EL’. |
| Pfad: /ns2:CrossIndustryInvoice/ns2:SupplyChainTradeTransaction[1]/ApplicableHeaderTradeAgreement[1]/SellerTradeParty[1]/SpecifiedTaxRegistration[1]/ID[1] | |||
| val-sch.2.1 | PEPPOL-EN16931-R001 | information | Business process MUST be provided. |
| Pfad: /ns2:CrossIndustryInvoice/ns2:ExchangedDocumentContext[1] | |||
| val-sch.2.2 | PEPPOL-EN16931-R010 | information | Buyer electronic address MUST be provided |
| Pfad: /ns2:CrossIndustryInvoice/ns2:SupplyChainTradeTransaction[1]/ApplicableHeaderTradeAgreement[1]/BuyerTradeParty[1] | |||
| val-sch.2.3 | BR-DE-15 | error | [BR-DE-15] Das Element "Buyer reference" (BT-10) muss übermittelt werden. |
| Pfad: /ns2:CrossIndustryInvoice | |||
| val-sch.2.4 | BR-DE-21 | warning | [BR-DE-21] Das Element "Specification identifier" (BT-24) soll syntaktisch der Kennung des Standards XRechnung entsprechen. |
| Pfad: /ns2:CrossIndustryInvoice/ns2:ExchangedDocumentContext[1] |
Wie bereits erwähnt soll das mit der neuen Version 2.2.0 behoben werden... Die Entwickler sind da bereits dran!
Fakturama 2.1.3 auf Win10 pro x64 an MariaDB auf ner DiskStation