Wie sieht die Zukunft mit XRechnung, ZUGFerD, Peppol und Co. aus ?

[Rollo62]

Hallo Leute,

ich habe zum Glück (noch) nichts mit dem Thema oben zu tun, und schaue nur mal gelegentlich da rein.
Deswegen würde ich gerne mal fragen wie die Experten hier das Thema einschätzen, denn ich habe dazu ein paar Gedanken:

X-Rechnung
- Ist klar, das müssen wir demnächst für Behördenaufträge machen.
Das ist blöd, aber nun mal Pflicht, ist wohl nur ein deutsches Phänomen.
- Darf das dann noch per EMail geschickt werden, oder muss Peppol genutzt werden ?
- Ich frage mich ob auch schon die Behörden alle soweit sind ?

Der ganze Rest (B2B):
- Ich verstehe sicher die Vorteile einer E-Rechnung, verstehe aber nicht ganz warum man damit wieder abgezockt werden muss.
- Wer arbeitet schon mit E-Rechnungen und Peppol-Service ?
Wenn ich mal suche scheint mir das mehr NL, BE aber auch Singapore zentriert zu sein,
die Deutschen scheinen da zum Glück noch etwas zurückhaltend zu sein.
- Jedenfalls sind Online-Größen wie Conrad Elektronik, Amazon, etc. dort nicht dabei, und für die müsste es doch Sinn machen.
Autohersteller auch nur vereinzelt, selten in DE., Ikea ist in nordischen Ländern drin.
- Kann man E-Rechnungen ohne Peppol-Service verschicken, z.B. per Mail, oder ist das Peppol schon auf dem Vormarsch und wird irgendwann Pflicht ?
- Es gibt noch französische und werweissnoch was für Systeme, wird das eventuell mal harmonisiert und die jetzigen Systeme werden überflüssig ?
- Wer steht dahinter, wenn es sowas wie SAP ist, dann habe ich meine Meinung dazu schon gebildet ?
- Ich verstehe das E-Rechnung Geld sparen kann. Aber wozu muss Peppol >= 500 EUR/Mon. verlangen, nur um eine Rechnung von A nach B zu schicken.
- Haben den so langsam Alle den Verstand verloren, und vergessen sich auf das Wesentliche zu konzentrieren ?
Wann werden mal wieder einfache, handhabbare Standards entworfen, denen Jeder gerne folgen möchte ?

Ich hoffe dass hier jemand konkret damit zu tun hat, jetzt mal ausserhalb der Behörden,
und einschätzen kann wie sich das in der Praxis wohl im B2B durchsetzen wird.
Ist das relevant für uns Alle, oder endet das bestenfalls wie die PKW-Maut oder vielleicht wie der VHS und Betamax-Streit ?

[Papaschlumpf73]

Sehr spannendes Thema. Meine Firma liefert u.a. an bundesunmittelbare Krankenkassen. Diese sind Körperschaften des öffentlichen Rechts und somit vergleichbar mit Bundesbehörden. Von denen wollte bisher - zum Glück - noch keine eine X-Rechnung. Einfache PDF-Rechnung hat bisher immer gereicht, obwohl die Pflicht zur X-Rechnung ja schon seit dem 27.11.2020 besteht.

[mkinzler]

Sven hat ja die nötige Vorarbeit schon geleistet

https://github.com/LandrixSoftware/XRechnung-for-Delphi

Bei X-Rechnung kann der XML-Datensatz ja in einer separaten Datei vorliegen

[Rollo62]

Zitat:

Zitat von mkinzler (Beitrag 1486376)

Sven hat ja die nötige Vorarbeit schon geleistet

Mir geht es weniger um die Technik, als um die Akzeptanz von ZUGFerD und Konsorten allgemein.
Das es bei Behörden verlangt wird ist die eine Sache, wie es aber ausserhalb aussieht die Andere.

Es sieht für mich nicht so aus als wäre das Ganze schon in trockenen Tüchern, oder zumindest großflächig unterstützt.
Zumindest scheint es das in DE die meisten abwarten, während NL, BE (meines Wissens NL als Vorreiter) die Sache eher vorantreiben.

Müsste da nicht gleich ein internationaler Standard ran, das Ganze sieht für mich sehr EU-zentriert aus ( wenn nicht sogar DE-zentriert bei X-Rechnung ).
Ich vermute mal dass es dann wieder in die Tonne kommt, falls mal ein neuer, "weltweiter" Standard kommt.

[mkinzler]

ZUGFerd war deutsch, XRechnung ist aber ein EU-Standard

[sh17]

Also XRechnung 2.0.1 entspricht der ZUGFeRD 2.1.1

Die aktuelle ZUGFeRD 2.1.1 ist auch gleich der französischen Faktur-X

Beide Formate haben aus deutscher gesetzlicher Sicht noch viele Lücken, weil es in Deutschland ja gern für jeden Kram eine
Sonderbehandlung gibt. Also aus der Praxis kann ich sagen, dass nicht jeder der XRechnung schicken muss/möchte dies auch kann, weil er seine Rechnungen
einfach nicht abgebildet bekommt. Pepol ist mir bisher nicht bekannt, wer das benötigt. Ich nutze die bisher nur zum Validieren von Rechnungen bei der Entwicklung.

Alle Empfänger der XRechnung erhalten die entweder per Mail oder über
ein eigenes Portal. Bekannt sind mir bisher nur Behörden, Kommunen und die DB.

Im B2B wird sich eher ZUGFeRD durchsetzen. Da kenne ich viele Großhändler, die darauf setzen. Das hätte der Bund auch mal gleich nehmen sollen und auf die XRechnung verzichten. Aber das kennt man ja.

[Rollo62]

Zitat:

Zitat von sh17 (Beitrag 1486379)

Also XRechnung 2.0.1 entspricht der ZUGFeRD 2.1.1

Die aktuelle ZUGFeRD 2.1.1 ist auch gleich der französischen Faktur-X

...

Im B2B wird sich eher ZUGFeRD durchsetzen.

Danke für die Infos.
Aber XRechnung = ZUGFerD = Faktur-X, das verstehe ich nicht ganz ?
Was bedeutet dann "gleich", ist es technisch 1:1 dieselbe XML, nur der Name ist anders ?

Das was Du schreibst hiesse ja: nimm XRechnung, es ist eh Alles eine Soße.
Denn mit XRechnung wäre man zumindest schonmal EU-konform.

Trotzdem scheint das von einem international gültigen IEC-Standard noch etwas entfernt, oder nicht ?
Was macht man denn in USA, Australien oder Asien ?

[sh17]

ZUGFerD = Faktur-X ist technisch das selbe

Bei XRechnung muss man unterscheiden, gebe ich eine XRechnung im UBL-Format (XML-Variante 1) oder im CII-Format (XML-Variante 2 entspricht ZUGFeRD 2.1.1.)

Theoretisch könnte man es mit XRechnung CII-Format probieren, um alle Empfänger zu unterstützen. Was mit Asien USA ist, keine Ahnung. Da hab ich mich nicht damit beschäftigt.

[hstreicher]

Zitat:

Zitat von Rollo62 (Beitrag 1486371)

Hallo Leute,
- Jedenfalls sind Online-Größen wie Conrad Elektronik, Amazon, etc. dort nicht dabei, und für die müsste es doch Sinn machen.
Autohersteller auch nur vereinzelt, selten in DE., Ikea ist in nordischen Ländern drin.

das Problem mit Zugferd und Co ist dass man damit nicht den ganzen Geschäftsablauf abbilden kann
also Angebot Bestellung Rechnung Lieferschein Abverkaufsmeldungen Bestandmeldungen

ich kann hier nur zu Amazon sagen das läuft per EDI EANCOM 96 (aber eben nicht nur die Rechnung sondern alle Formate

mfg Hannes

[Rollo62]

Also ist das nie als EinerFürAlle gedacht gewesen, sondern nur ein weiteres Format in freier Wildbahn der ganzen Edifact Formate.
Dann machen ja wohl Konverter mehr Sinn, als so Was als Basis einzusetzen.

[himitsu]

Es ist wie immer ... groß gedacht, als DAS Ding für Alle ... alle die hier genannten Dinge.

Ist wie beim USB.
Wir machen Einen für ALLE, aber Einer denkt sich kurz vor knapp "nee, ich erfinde meinen eigenen iStecker".
Aber egal. Grade wird wieder an der nächsten Version gearbeitet und DIE soll es dann werden ....
nja, mal sehn.


Und dass Einiges so streng geheim ist, dass man nur gegen Geld an die Spezifikation kommt, dass hilf nicht grade bei der Verbreitung.

[Rollo62]

Zitat:

Zitat von himitsu (Beitrag 1486411)

"nee, ich erfinde meinen eigenen iStecker".

Ja, anfangs ist das wahrscheinlich immer so, aber das Thema ist ja auch bei EDIFACT und Co schon Jahrzehnte bekannt.

Es ist doch mehr vergleichbar mit Wifi, wo auch alle Beteiligten ein starkes Interesse daran haben müssten dass der Daten-Austausch ohne Reibung klappt.

Wer dann noch einen Sonderweg erfindet, der kommt nicht in den (Netz)Club.

Eigentlich sollte sich das mit dem ganzen angesammelten Wissen für alle Branchen doch universell lösen lassen,
aber OK, dann hätten wohl tausende Programmierer keinen Job mehr :stupid:

[sh17]

EDI ist inzwischen auch ein Monster, das ohne die ganzen Firmen, die mit Konvertern zu dieser Schnittstelle ihr Geld verdienen, kaum zu beherrschen ist.

[TiGü]

Auch wenn Off-Topic, aber es muss wieder sein:
https://xkcd.com/927/

[omnibrain]

Mit der kommenden E-Rechnungspflicht fragen Kunden jetzt auch wieder nach ZUGFeRD.

XRechnungen sind kein Problem, die erstelle ich mit der XRechnungskomponente von Landrix/sh17.

PDF erstellen wir eh schon immer.
Jetzt fehlt mir nur eine Lösung um aus dem was ich schon habe eine ZUGFeRD-Rechnung zu erstellen. Das heißt das PDF ggf. in das passende PDF/A-Format umwandeln und dann die Rechnungs-XML anhängen. Hat da vielleicht jemand schon eine Lösung? Ich brauche nicht unbedingt eine Komponente, eine aus Delphi nutzbare DLL tuts mir auch und zur Not geht auch ein Kommandozeilenprogramm.

[BlueStarHH]

Zitat:

Zitat von omnibrain (Beitrag 1535027)

Jetzt fehlt mir nur eine Lösung um aus dem was ich schon habe eine ZUGFeRD-Rechnung zu erstellen.

Gnostice (https://www.gnostice.com/XtremeDocum...dio_Delphi.asp) hat da das "Gnostice Document Studio" im Angebot:

Zitat:

Report-export PDF/A support includes PDF/A 1b, 2b, and 3b versions. PDF/A-3b support complies with ZUGFeRD electronic invoicing standard.

Ich selbst habe das aber noch nichts genutzt/ausprobiert. Daher keine Anhang, ob das gut ist. Evtl. reicht auch die "eDocEngine VCL", die günstiger ist.

[sh17]

Ich bin auch an einer ZUGFeRD Version als Open source dran. Die erscheint unter der Apache Lizenz. Ich denke Ende April mache ich das GitHub repository öffentlich

[BlueStarHH]

Zitat:

Zitat von sh17 (Beitrag 1535029)

Ich bin auch an einer ZUGFeRD Version als Open source dran. Die erscheint unter der Apache Lizenz. Ich denke Ende April mache ich das GitHub repository öffentlich

Was heißt das genau? Man kann mit Deiner Lib ein PDF erstellen und dort die mit Deiner Lib erstellen XML-Datein einbetten?

[sh17]

Man kann zumindest die XML erstellen. Wegen PDF Einbettung müsste ich schauen, ob das separat möglich ist. Evtl über Synopse pdf

[omnibrain]

Zitat:

Zitat von sh17 (Beitrag 1535032)

Man kann zumindest die XML erstellen. Wegen PDF Einbettung müsste ich schauen, ob das separat möglich ist. Evtl über Synopse pdf

Die XML ist ja das kleinere der Probleme.
Diese XML in ein PDF reinzubringen und das PDF dem Standard PDF/A-3 genügen zu lassen schon eher.
Wir erzeugen unsere PDFs im Moment schon mit synpdf, aber das kann nur A-1 und das in den letzten Tests (ein paar Jahre her) auch nicht sauber. Einbettungsmöglichkeit kenne ich keine.

[himitsu]

Findet sich da irgendwas nutzbares?

https://www.heise.de/download/product/zugferd-cmd-96167
https://www.codeproject.com/Question...XML-attachment
https://www.textcontrol.com/blog/202...nic-documents/
https://www.foxit.com/blog/pdfa-3-en...bedded-in-pdf/
...

[Achim Kalwa]

Moin,

Zitat:

Zitat von sh17 (Beitrag 1535032)

Man kann zumindest die XML erstellen. Wegen PDF Einbettung müsste ich schauen, ob das separat möglich ist. Evtl über Synopse pdf

Wir hatten lange Zeit auch Synopse PDF im Einsatz, aber das ist leider am vielen Stellen unvollständig oder fehlerbehaftet (z.B. Clipping von Bitmaps). Seit ca. 2 Jahren nutzen wir statt dessen wPDF5 von WPcubed/Julian Ziersch als DLL. Nicht ganz billig, funktioniert aber einwandfrei und kann auch XML für ZUGFeRD einbetten. In der Doku gibt es entsprechenden Beispielcode. Die fertige PDF hat bislang alle Validatoren zufriedengestellt. Ich glaube Julian ist auch hier im Forum aktiv.

Alternativ soll die Verknüpfung von XML und PDF wohl auch mit Ghostscript und einem Schwung Kommandozeilenparameter funktionieren:
https://ghostscript.com/blog/zugferd.html

Für X-Rechnung 3.0.1 (ab 2025) kann man sich das Einbetten aber auch sparen, denn dann besteht die elektronische Rechnung nur noch aus der XML-Datei; der PDF-Teil entfällt. Mit Hilfe von Visualisierern kann eine X-Rechnung wieder in eine Menschenlesbare Form gebracht werden, z.B. https://github.com/itplr-kosit/xrechnung-visualization konvertiert X-Rechnung zu HTML. Natürlich nur die Nutzinformationen mit festem Layout. Firmenlogo, Schriftarten, Zeilenabstände usw. sind da nicht vorgesehen.

HTH
Achim

[BlueStarHH]

Zitat:

Zitat von Achim Kalwa (Beitrag 1535051)

Für X-Rechnung 3.0.1 (ab 2025) kann man sich das Einbetten aber auch sparen, denn dann besteht die elektronische Rechnung nur noch aus der XML-Datei; der PDF-Teil entfällt.

So formuliert stimmt das nicht. Es bleibt dem Versender überlassen, ob er eine PDF mit XML oder nur XML versendet. PDF entfällt nicht. Die meisten werden noch das PDF haben wollen, da es schöner aussieht und mehr Formatierungsmöglichkeiten bietet. Gerade wenn es um zusätzliche Spalten in den Rechnungspositionen geht, die in XRechnung nicht abbildbar sind, weil es sie einfach in diesem Format nicht gibt.

Code:

Erfüllt werden die Formatanforderungen z.B. von der XRechnung, die u. a. im öffentlichen Auftragswesen bereits zum Einsatz kommt, oder dem hybriden ZUGFeRD-Format (Kombination aus PDF-Dokument und XML-Datei). Dies hat das BMF in seinem Schreiben v. 2.10.2023 an die Verbände ausdrücklich bestätigt (für ZUGFeRD erst ab Version 2.0.1).

Quelle https://www.haufe.de/steuern/gesetzg...68_605558.html

[omnibrain]

Zitat:

Zitat von Achim Kalwa (Beitrag 1535051)

Wir hatten lange Zeit auch Synopse PDF im Einsatz, aber das ist leider am vielen Stellen unvollständig oder fehlerbehaftet (z.B. Clipping von Bitmaps). Seit ca. 2 Jahren nutzen wir statt dessen wPDF5 von WPcubed/Julian Ziersch als DLL. Nicht ganz billig, funktioniert aber einwandfrei und kann auch XML für ZUGFeRD einbetten. In der Doku gibt es entsprechenden Beispielcode. Die fertige PDF hat bislang alle Validatoren zufriedengestellt. Ich glaube Julian ist auch hier im Forum aktiv.

Danke. Das ist genau die Art von Tip die ich brauche.

[BerndS]

Wir haben hier noch eine ewtas in die Jahre gekommene Version der Gnostice eDocEngine 5 aus dem Jahr 2019 im Einsatz. Die Quellen musste ich etwas anpassen, damit ZUGFeRD funtioniert.
Der wird im Quickreport verwendet um die PDF zu erstellen und gleichzeitig die XML anzuhängen.
Laut PDF-Validator kommt da eine PDF/A-3 heraus.

[stifflersmom]

Kann man eigentlich die geforderte XML separat mit versenden?
Meine Wunschvorstellung wäre es, die PDF-Erstellung so zu lassen wie sie ist und die ab 2025 geforderte XML als separaten Anhang mit der Mail zu versenden, die auch die PDF verschickt.

[BlueStarHH]

Zitat:

Zitat von stifflersmom (Beitrag 1535194)

Kann man eigentlich die geforderte XML separat mit versenden?
Meine Wunschvorstellung wäre es, die PDF-Erstellung so zu lassen wie sie ist und die ab 2025 geforderte XML als separaten Anhang mit der Mail zu versenden, die auch die PDF verschickt.

Keine Ahnung, ob das so erlaubt ist oder nicht. Ich weiss aber schon von den ersten Großkunden meiner Kunden, die beides in einer Datei haben möchten. Die möchten das einfach so haben, sonst gibt es keine Aufträge mehr. Vieles wird sich so über diesen Weg durchsetzen ist mein Gefühl.

[t2000]

Wir haben auch eine ältere Lizenz von Gnostice und würden das ganze Paket auch gerne nutzen wollen.
Aber ein (eher einfacher) Fehler in 2022 wurde von deren Support einfach ignoriert und unsere Mails nicht beantwortet. (im Jahr 2022)
Und wenn ich auf die Homepage sehe
https://www.delphipraxis.net/attachm...1&d=1712053515
passiert da auch nichts mehr.

Eigentlich schade, wir hätten gerne mit dem gesamten System gearbeitet.

Was gäbe es noch für Alternativen? Nach Möglichkeit unabhängig von Windows, da wir eine Menge auf einem Linux-Server machen.

[BlueStarHH]

Zitat:

Zitat von t2000 (Beitrag 1535196)

Wir haben auch eine ältere Lizenz von Gnostice und würden das ganze Paket auch gerne nutzen wollen.
Aber ein (eher einfacher) Fehler in 2022 wurde von deren Support einfach ignoriert und unsere Mails nicht beantwortet. (im Jahr 2022)

Danke für die Info. Damit ist Gnostice für mich raus. Ich werden mal das wPDF5 von Julian Ziersch antesten:

Zitat:

Zitat von Achim Kalwa (Beitrag 1535051)

Seit ca. 2 Jahren nutzen wir statt dessen wPDF5 von WPcubed/Julian Ziersch als DLL. Nicht ganz billig, funktioniert aber einwandfrei und kann auch XML für ZUGFeRD einbetten. In der Doku gibt es entsprechenden Beispielcode. Die fertige PDF hat bislang alle Validatoren zufriedengestellt. Ich glaube Julian ist auch hier im Forum aktiv.

[Frickler]

Zitat:

Zitat von t2000 (Beitrag 1535196)

Was gäbe es noch für Alternativen? Nach Möglichkeit unabhängig von Windows, da wir eine Menge auf einem Linux-Server machen.

In früheren Artikeln wurde DynaPDF empfohlen. Das ist eine DLL bzw. Shared Library, die man auch aus Delphi ansteuern kann. Unterstützt wird außer Windows auch MacOS, iOS, Android und Linux.

[t2000]

Zitat:

Zitat von Frickler (Beitrag 1535208)

Zitat:

Zitat von t2000 (Beitrag 1535196)

Was gäbe es noch für Alternativen? Nach Möglichkeit unabhängig von Windows, da wir eine Menge auf einem Linux-Server machen.

In früheren Artikeln wurde DynaPDF empfohlen. Das ist eine DLL bzw. Shared Library, die man auch aus Delphi ansteuern kann. Unterstützt wird außer Windows auch MacOS, iOS, Android und Linux.

Stimmt, Danke, hatte ich vergessen.
Ne Firma aus der Gegend bei Osnabrück, Quellcode kann auch gekauft werden.
Ohne Quellcode kommt bei uns sonst nichts ins Projekt.

[bernau]

Ich verwenden die PdfiumLib von Andreas Hausladen um PDF anzuzeigen.

https://github.com/ahausladen/PdfiumLib

In der Lib gibt es auch Funktionen um Attachements anzuhängen. Weis nicht, ob das dafür geeignet ist und habe es auch noch nicht getestet. Einfach mal schauen.

[sh17]

Wenn es um die E-Rechnungspflicht geht, dann ist die Einbettung einer XML in die PDF sowieso nicht erforderlich, weil diese Bestimmung vorsieht, dass
das nackte XML die vollständige Rechnung darstellt und eine parallele optische Darstellung nicht vorgesehen ist.

[t2000]

Ja sicher, aber ich kenne meine Kunden :roll:
Habe jetzt schon den Hinweis von einem Kunden bekommen, dass die zukünftig nur eine Rechnung versenden wollen, die man auch lesen kann. Finde ich persönlich (als Nutzer) auch sinnvoll.

[himitsu]

Nja, "direkt" lesbar wäre es auch, wenn die XML neben der PDF liegen täte, damit der Kunde dort mit Notepad/Browser reingucken kann. :duck:

[sh17]

Wenn das gesetzlich alles abgestimmt ist, sicher. Es sind halt zwei unabhängige Dokumente (wie ehemals Papier und gescannte PDF), wie kann man sicherstellen, dass beide übereinstimmen? Deswegen wird nur ein Dokument rechtsgültig sein.

[BlueStarHH]

Zitat:

Zitat von sh17 (Beitrag 1535652)

Wenn das gesetzlich alles abgestimmt ist, sicher. Es sind halt zwei unabhängige Dokumente (wie ehemals Papier und gescannte PDF), wie kann man sicherstellen, dass beide übereinstimmen? Deswegen wird nur ein Dokument rechtsgültig sein.

Wenn X-Rechnung (XML) und PDF ausgliefert werden, muss der Empfänger beides auf Unterschiede prüfen. Trotzdem sagen schon jetzt einige Kunden, dass Sie beides haben wollen.

[sh17]

Zitat:

Zitat von omnibrain (Beitrag 1535027)

Mit der kommenden E-Rechnungspflicht fragen Kunden jetzt auch wieder nach ZUGFeRD.

XRechnungen sind kein Problem, die erstelle ich mit der XRechnungskomponente von Landrix/sh17.

PDF erstellen wir eh schon immer.
Jetzt fehlt mir nur eine Lösung um aus dem was ich schon habe eine ZUGFeRD-Rechnung zu erstellen. Das heißt das PDF ggf. in das passende PDF/A-Format umwandeln und dann die Rechnungs-XML anhängen. Hat da vielleicht jemand schon eine Lösung? Ich brauche nicht unbedingt eine Komponente, eine aus Delphi nutzbare DLL tuts mir auch und zur Not geht auch ein Kommandozeilenprogramm.

Mittels PDFBox und https://github.com/konik-io/pdfbox-carriage als Vorlage könnte man sich was in JAVA basteln.

Oder auch das hier https://www.mustangproject.org/commandline/

Ich werde das dann zu gegebener Zeit hier https://github.com/LandrixSoftware/ZUGFeRD-for-Delphi mit dazu packen. Im Moment muss
ich noch den Write-Support fertigstellen.

[BlueStarHH]

Zitat:

Zitat von sh17 (Beitrag 1536089)

Mittels PDFBox und https://github.com/konik-io/pdfbox-carriage als Vorlage könnte man sich was in JAVA basteln.

Wer möchte denn Java mit seinem Delpi-Programm, das sonst wenige oder keine Abhängikeiten hat, ausliefern? Oder welcher Kunde möchte Java haben? Ich beobachte ehr, dass viele Kunden das inzwischen als sicherheitskritisch sehen und keine Java-Runtime mehr installiert haben oder installieren möchten.

[sh17]

XRechnung kommt ebenfalls mit einer Reihe von Java-basierenden Tools, um die Validierung oder Visualisierung von XRechnung zu ermöglichen. Ich sehe keine Problem darin, dies ebenfalls bei ZUGFeRD so zu handhaben, wenn es mir einen Mehrwert liefert. Alle Tools sind OpenSource und können geprüft werden. Von daher, nehmen oder lassen oder selbst machen. Deswegen ist es ja OpenSource, um Abhängigkeiten zu vermeiden. Aber das kann jeder für sich selbst entscheiden.