ich wollte heute bei https://xrechnung-bdr.de die XRechnung an die Behörde übermitteln, aber die PDF-Datei wird dort nicht angenommen. Es muss eine XML-Datei sein.
Im Document Builder sehen meine Einstellungen wie folgt aus:
Ich bin bis jetzt davon ausgegangen, dass die XML-Daten in der PDF-Datei mit eingebunden sind oder nicht?
Gibt es vielleicht anderen Weg, wie man die X-Rechnung im PDF-Format an OZG-RE übermitteln kann oder fehlen mir noch weitere Einstellung im Plenty?
Viele Grüße
Juri
Nachtrag: Wie es aussieht, darf man an OZG-RE nur Rechnungen als XML-Datei übermitteln. Daraus ergibt sich weitere Frage. Ist es möglich im Plenty zusätzlich zu der PDF/A3-Xrechnung Datei eine XML-Datei zu generieren?
XRechnung ist grundsätzlich ein reines XML-Format.
Das ist nur bei hybriden Formaten wie ZUGFeRD/Facture-X der Fall, aber nicht bei einer XRechnung.
Ja, grundsätzlich muss die Bereitstellung via Upload/Peppol als XRechnung – und damit als XML-Dokument – erfolgen.
Ein hybrides Format (XML-Datei + PDF-Sichtkomponente) kann also keine XRechnung darstellen und ist unzulässig.
Das XML-Dokument im Anhang des PDFs basiert auch auf einer anderen Taxonomie (XML-Struktur, Namespaces, Profilkennzeichnung und Validierungsregeln).
ABER:
Ab ZUGFeRD 2.2.0 existiert ein optionales „XRechnung-Profil“.
Im UKS würde dies bedeuten: Falls gemäß den Einstellungen in plenty auch tatsächlich eine valide PDF/A3-Datei im ZUGFeRD-Format mit dem XRechnung-Profil erstellt wird, dann ist es möglich, das XML-Dokument im Anhang des PDFs separat zu speichern und es anschließend über Peppol hochzuladen.
Wenn das also durch plenty wirklich korrekt erstellt wird, dann ist das auf diesem Wege möglich; obgleich ja schon seit Beginn an Probleme bei plenty aufgetreten sind…
Andernfalls müsste man die Datei selbst erzeugen und diese Datei dann auch dauerhaft archivieren.
VG
Marlon
P.S.:
Eigentlich ist/wäre das per Definition natürlich absurd, weil eine XRechnung nun einmal ausschließlich das XML-Dokument umfasst, aber es ist und bleibt plenty.
Ich kann die von Plenty erzeugte X-Rechnung mit dem Quba-Programm öffnen und sehe dort die ganzen XML-Daten. Somit gehe ich davon aus, dass die PDF/A3-Datei valide ist. Es haben sich bis jetzt keine Kunden über unsere Rechnungen beschwert.
Aber wie Du an der Bezeichnung siehst, handelt es sich offensichtlich um eine Facture-X-Datei, also eine ZUGFeRD-Datei, und eben keine XRechnung.
Wie gesagt handelt es sich um unterschiedliche Taxonomien. Und nur, weil Du Daten visualisierst, bedeutet das ja nicht die Validierung. Und ob die Kunden die E-Rechnung auch wirklich als solche verarbeiten und validieren, steht nochmals auf einem anderen Blatt.
Das wird auch im B2G-Kontext nicht „unterstützt“ werden, weil dies auf der ERechV basiert; und ganz allgemein stellt die eigentliche E-Rechnung grundsätzlich die XML-Datei dar – und eine Sichtkomponente ausschließlich ein Mehrstück der Rechnung.
…dass nicht einfach eine XML-Datei durch plenty erzeugt wird, wenn es um eine B2G-Transaktion geht.
wie hast Du das denn nun geschafft?
Hast Du eine reine XRechnung erzeugt?
Wir hatten ein ähnliches Problem mit dem Portal vom Bund.
Haben dazu eine neue Kundenklasse mit gesondertem Rechnungsdokument als XRechnung geschaffen.
Indem er den Anhang im PDF separat abgespeichert hat.
Aber das ist (mittlerweile) mutmaßlich nicht mehr erforderlich (wenn ich mich recht erinnere, dann wurde zu Beginn trotzdem eine PDF-Datei erzeugt) in plenty @JuriKern, da man das Augabeformat auf XML (statt PDF/A3) stellen muss:
Ich hab mit Plenty schon zig Diskussionen gehabt, warum Sie nicht eine reine XML-Rechnung uns ein PDF separat ausstellen, so wie es zb die Rechnungen von Jera Software - PDF und XML-Rechnung einzeln getrennt zusenden:
Die Diskussion hatte ich ja auch mit Plenty, JTL erzeugt auf Wunsch bspw. sowohl XML als auch PDF.
Wir haben es über Kundenklassen gelöst. Wenn bei uns jemand bestellt, der als Anforderung eine XML-Rechnung stellt, so weisen wir den Auftraggeber der XML-Kundenklasse zu. Diese Kundenklasse ist mit einer XML-Vorlage verknüpft und somit wird dann statt einer ZUGFeRD-Rechnung eine reine XML-Rechnung erstellt:
Jupp, wir auch. Besonders für Universitäten ist das am sinnvollsten.
Schade das man das Format am Kunden nicht wählen kann, dann wäre es einfacher.
Wir haben uns da die Klassen nach Typ der Dokumente angelegt.
pauschal existieren als 3 PDF-Klassen und 3 XML-Klassen. Nicht schön aber zumindest funktioniert das