ZUGFeRD XML erstellen

[rapante]

Hallo,
kennt jemand Lib's oder Komponenten mit denen man komfortabel ZUGFeRD-konforme XML-Dateien erstellen kann?

[mjustin]

Anbieter von Software Development Kits (SDK) zur Erstellung Zugferd unterstützender Software

http://rechnungsaustausch.org/zugfer...pement-kit.htm

[sh17]

aufbauend darauf

https://github.com/search?utf8=%E2%9...e=Repositories

[rapante]

Zitat:

Zitat von mjustin (Beitrag 1373865)

Anbieter von Software Development Kits (SDK) zur Erstellung Zugferd unterstützender Software

http://rechnungsaustausch.org/zugfer...pement-kit.htm

Sorry, ich hatte vergessen zu erwähnen das ich eine Implementierung/Komponente in Delphi suche.

Die Liste hatte ich auch schon gefunden. Bei vielen der Anbieter ist das Erstellen der XML-Dateien nicht Bestandteil des SDK und die anderen
sind für Java/.Net

Zitat:

Zitat von sh17 (Beitrag 1373869)

aufbauend darauf

https://github.com/search?utf8=%E2%9...e=Repositories

auch hier: Java/.Net

[Thomas Necke]

Hallo,

ich habe einen Dienstleister gefunden, der aus PDF-Dateien ZUGFeRD erstellt. Auf deren Seite http://www.high-end-konvertierung.de kann man den Service testen. Nach einigen wenigen Minuten bekommt man die ZUGFeRD-Datei per Mail zugesandt.

Danach hat mich ein freundlicher Mitarbeiter der Firma zurückgerufen, ob ich mit dem Ergebnis zufrieden sei und hat mit mir das weitere Vorgehen einer möglichen Bestellung besprochen. Ich kann den Service empfehlen, da das Ergbnis und der Service (Ansprechpartner, telefonische Erreichbarkeit, etc.) passen.

[BerndS]

Hallo
Wir sind ebenfalls auf der Suche nach einer Lösung mit Delphi. Da wir für die PDF-Erstellung aus dem Quickpeport und zur Anzeige einer PDF optional Gnostice verwenden, haben wird da mal nachgefragt was mit ZUGFeRD ist.
Laut Information meines Kollegen arbeiten die bereits daran eine ZUGFeRD XML zu erstellen und auch auszulesen. Wann das sein wird konnte Gnostice noch nicht sagen, haben aber von ca. einem Monat gesprochen.
Gruß Bernd

[Elspass]

Im Lazarus Forum ist die Suche auch im Gange.
Dort ist die Überlegung fpPdf (https://github.com/alrieckert/freepa...f/src/fppdf.pp) zu erweitern.
fpPdf kann schon Fonts in eine PDF laden, somit sollte auf diesem Weg auch eine XML sich integrieren lassen.
Leider fehlt bei mir die Zeit mich in diesem Source einzuarbeiten. Der Vorteil, alles ist schon in Pascal.

Gruß Jörg

[rapante]

Hallo,
in Ermangelung einer brauchbaren alternative erstelle ich die ZUGFeRD-XML-Dateien jetzt selbst. Da der Standard sehr gut dokumentiert ist (Download (Schema-Dateien, Codelisten Beispiele)) und es ein kostenloses Validierungs-Portal gibt, war die Implementierung einfacher als erwartet.

Offen ist allerdings die Frage wie ich jetzt diese XML-Datei mit meinem PDF (PDF/A 1) zusammenbringe und ein konformes PDF/A 3 heraus bekomme. Ich habe mir bereits das Tool-Kit von Intarsys angeschaut (https://www.intarsys.de/ZUGFeRD). Damit ist es möglich via Kommandozeile PDF und XML zusammenzuführen. Das Tool benötigt aber zwingend eine Installation, sowie die JRE - das würde ich gerne vermeiden.

BTW:

Zitat:

Zitat von Thomas Necke (Beitrag 1373960)

Hallo,

ich habe einen Dienstleister gefunden, der aus PDF-Dateien ZUGFeRD erstellt. Auf deren Seite http://www.high-end-konvertierung.de kann man den Service testen. Nach einigen wenigen Minuten bekommt man die ZUGFeRD-Datei per Mail zugesandt.

Danach hat mich ein freundlicher Mitarbeiter der Firma zurückgerufen, ob ich mit dem Ergebnis zufrieden sei und hat mit mir das weitere Vorgehen einer möglichen Bestellung besprochen. Ich kann den Service empfehlen, da das Ergbnis und der Service (Ansprechpartner, telefonische Erreichbarkeit, etc.) passen.

Das kann jetzt auch Zufall sein, aber der freundliche Mitarbeiter der mich zurückrief hieß auch Thomas Necke ;)

[Elspass]

Bei der Zusammenführung kann Dir wie schon geschrieben fpPdf helfen. Es ist Open Source und ermöglicht schon Fonts in die PDF zu binden.
Somit sollte es mit etwas fleiß kein Problem sein.
Leider konnte ich mir aus Zeitgründen den Source noch nicht anschauen. Wird aber auch bei uns bald ein Thema sein...

Gruß Jörg

[rapante]

Zitat:

Zitat von Elspass (Beitrag 1375515)

Bei der Zusammenführung kann Dir wie schon geschrieben fpPdf helfen.

Ich habe den Quelltext jetzt nur überflogen, aber ich sehe nicht wir mir das helfen kann!?

- die Lib bietet scheinbar nicht die Möglichkeit ein bestehendes PDF zu laden/ändern (nur neue zu erstellen).
- auf der Todo-Liste steht auch noch die Implementierung des Archive-Formats (PDF/A)

Mit ein "bisschen" Fleiß ist das hier IMHO nicht getan...

[Elspass]

Du müsstest die Komponente zu erzeugen der PDF nutzen und die XML Datei wären des erstellen einbinden. Auf dem gleichen Weg wie fpPDF die Font-Dateien einbinden kann.
Das Archiv-Format ist ein Problem. Wobei man den Entwickler man anhauen kann.

[rapante]

Der Vollständigkeit halber hier meine letzten Erkenntnisse für das Einfügen der XML in ein PDF:

Das ZUGFeRD-SDK von CIB scheint sehr vielversprechend (ich habe es nicht getestet). Eine DLL mit 2 Funktionen (Einfügen und Extrahieren) und zudem Freeware. C-Header ist vorhanden - somit sollte auch die Delphianbindung schnell realisiert sein. Einziger Wermutstropfen: das PDF muss bereits im Standard PDF/A-3 vorliegen.

Da wir unsere Dokumente mit List & Label erzeugen, werden wir auf die neueste Version updaten. Dort ist es mittlerweile auch möglich ZUGFeRD-Dateien zu erstellen (Das XML-File muss selbst erstellt werden).

[RAlbiez]

Zitat:

Zitat von rapante (Beitrag 1375512)

Offen ist allerdings die Frage wie ich jetzt diese XML-Datei mit meinem PDF (PDF/A 1) zusammenbringe und ein konformes PDF/A 3 heraus bekomme. Ich habe mir bereits das Tool-Kit von Intarsys angeschaut (https://www.intarsys.de/ZUGFeRD). Damit ist es möglich via Kommandozeile PDF und XML zusammenzuführen. Das Tool benötigt aber zwingend eine Installation, sowie die JRE - das würde ich gerne vermeiden.

Falls das noch irgendjemand interessiert die PDF/A Formate sind rückwärtskompatibel, eine PDF/A1 konforme PDF ist also auch immer PDF/A3 konform, die Umwandlung erfordert lediglich das ändern der relevanten Zeile in den PDF Metadaten:

<rdf: Description rdf:about="" xmlns:pdfaid="http://www.aiim.org/pdfa/ns/id/">
<pdfaid:part>1</pdfaid:part>
<pdfaid:conformance>B</pdfaid:conformance>
</rdf: Description>

Also an dieser Stelle aus der 1 eine 3 machen.

[sh17]

Noch in den Anfängen, aber wenn es jemandem nützt, ich bin dran

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

[Codehunter]

Zitat:

Zitat von Thomas Necke (Beitrag 1373960)

Hallo,

ich habe einen Dienstleister gefunden, der aus PDF-Dateien ZUGFeRD erstellt. Auf deren Seite http://www.high-end-konvertierung.de kann man den Service testen. Nach einigen wenigen Minuten bekommt man die ZUGFeRD-Datei per Mail zugesandt.

Danach hat mich ein freundlicher Mitarbeiter der Firma zurückgerufen, ob ich mit dem Ergebnis zufrieden sei und hat mit mir das weitere Vorgehen einer möglichen Bestellung besprochen. Ich kann den Service empfehlen, da das Ergbnis und der Service (Ansprechpartner, telefonische Erreichbarkeit, etc.) passen.

U-Boot-Sirene... DSGVO...

[exilant]

Zitat:

Zitat von sh17 (Beitrag 1401115)

Noch in den Anfängen, aber wenn es jemandem nützt, ich bin dran

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

Vielen Dank für die Arbeit. Ich werde mir das mal anschauen.

[Codehunter]

Geht es nur mir so: Ich finde das ZUGFeRD-Format zäumt das Pferd irgendwie von hinten auf - um mal im Bild zu bleiben ^^ Es erhebt ein proprietäres Format (PDF) zum Defakto-Standard. Wäre es nicht sinniger gewesen, die XML-Daten als Ursprungsformat zu nutzen und darin das Rechnungsdokument als BLOB zu integrieren? Dann hätte man auch andere Formate (Rastergrafiken, SVG...) für die Visualisierung nutzen und die BLOB-Prüfsummen etc. im XML verankern können.

[jobo]

Zitat:

Zitat von Codehunter (Beitrag 1401138)

Geht es nur mir so: Ich finde das ZUGFeRD-Format zäumt das Pferd irgendwie von hinten auf - um mal im Bild zu bleiben ^^

Also ein Schubpferd?
;)

Ich schätze, solche Fragen sind zwar berechtigt, aber müßig. Siehe SEPA, BEA usw.
Es wird halt irgendwie angeleiert und wenn das Schiff mal Kurs genommen hat, ist es nur noch schwer zu steuern. Man muss sich ja wahrscheinlich überhaupt freuen, dass es so eine Art "Initiative" gibt. (Jetzt, wo wir plötzlich Digitalisierung haben!)

Vielleicht hat irgendjemand der Planer sich gedacht, Mensch so ein PDF kann ich nicht mal in Word editieren, und nur lesen, und sogar extra zum Lesen ein Programm installieren (der Programmname ..Reader ist vielleicht hilfreich für diese Assoziation).
Damit war die Idee für dieses tolle Format geboren.

Heute noch im Radio ein tolles Zitat zum Thema Bearbeitung von Geldwäschvorfällen beim Zoll gehört: ~".. die Datenübertragung (der Meldungen) ist von Fax auf 'Elektronisch' umzustellen.." Weiß leider nicht von wann diese Ansage ist.
Ich stell mir das besonders toll vor, wenn noch dieses alte Thermopapier genutzt wird. Automatische "Verjährung" nach ca 12 Monaten, scheint mal Sonne auf den Schreibtisch vielleicht auch eher..

[Codehunter]

Zitat:

Zitat von jobo (Beitrag 1401145)

Also ein Schubpferd?

Wenn schon, dann SCHUBFeRD :roll:

Zitat:

Zitat von jobo (Beitrag 1401145)

Ich schätze, solche Fragen sind zwar berechtigt, aber müßig. Siehe SEPA, BEA usw.

Haste leider Recht.

[jobo]

Zitat:

Zitat von Codehunter (Beitrag 1401147)

Zitat:

Zitat von jobo (Beitrag 1401145)

Also ein Schubpferd?

Wenn schon, dann SCHUBFeRD :roll:

Ja, natürlich! Wie konnte ich so daneben hauen?! :stupid:

[bnreimer42]

Ich finde auf einige Fragen rund um ZUGFeRD auch keine Antwort, z.B. wenn Rechnungsbetrag oder andere Angaben in XML und PDF differieren, was ist dann gültig?

Es gibt im öffentlichen Bereich das Format XRechnung, was es besser macht, d.h. nur XML ohne PDF. Nur da ist die Frage, wie man das anzeigt. Bei dem Format muss also die Software die Rechnung visualisieren.

[sh17]

Also wenn die Beträge differieren dürfte eine Fehler vorliegen, meiner Meinung nach.

[Fritzew]

Zitat:

Ich finde auf einige Fragen rund um ZUGFeRD auch keine Antwort, z.B. wenn Rechnungsbetrag oder andere Angaben in XML und PDF differieren, was ist dann gültig?

Auszug aus der ZUGFeRD Doku:

Zitat:

Bei korrekter Implementierung durch den Rechnungsaussteller besteht bei ZUGFeRD- Rechnungen inhaltliche Identität zwischen den XML-Daten und dem PDF-Rechnungsbild. Die korrekte Implementierung sollte der Rechnungsaussteller vor der Inbetriebnahme der Rechnungsversendung von ZUGFeRD-Rechnungen ausreichend testen. Unter Berücksichtigung dieser Voraussetzungen führt die Nutzung dieses Rechnungsformats trotz Ausweis der Umsatzsteuer in beiden Formaten nicht zur doppelten Umsatzsteuerbelastung.

Der Empfänger einer ZUGFeRD-Rechnung muss sich zwischen der Verarbeitung der XML- Daten oder des PDF-Rechnungsbildes entscheiden. Die Prüfung der inhaltlichen Identität zwischen XML-Daten und PDF-Rechnungsbild ist grundsätzlich nicht erforderlich. Gegebenenfalls wird er jedoch die XML-Daten für den Rechnungsverarbeitungsprozess in sein IT- System einlesen und den Mitarbeitern seines Rechnungswesens zusätzlich das PDF-Rechnungsbild zur Prüfung der sachlichen Richtigkeit und Zahlungsfreigabe anzeigen. Hierbei sollte eine Sichtprüfung der übernommenen Rechnungsdaten anhand des PDF-Rechnungsbildes erfolgen. Diese Prüfung wird der Unternehmer allerdings schon aus kaufmännischem Eigeninteresse vornehmen. Sofern es Abweichungen zwischen den eingelesenen Daten und dem PDF-Rechnungsbild gibt, ist die Rechnung vom Rechnungsempfänger zurückzuweisen.

Also sollten wir als Software-Hersteller und Co schon dafür sorgen dass alles zusammenpasst. ;-)
Solange man immer schön brav die gleichen Daten verwendet sollte dies auch kein grosses Problem darstellen.

[Codehunter]

@Fritz: Danke für den Doku-Auszug. Wieder ein schönes Beispiel, weshalb Datenredundanz zusätzliche Arbeit verursacht. XRechnung kannte ich bis dato noch gar nicht, klingt aber sinnvoller als ZUGFeRD. Spart Speicherplatz und ist eindeutig. Aber eben ohne Firmenlogo rechts oben, das dürfte wohl am meisten gestört haben und Grund für dieses Doppelkonstrukt gewesen sein.

[Fritzew]

Ach so schlecht finde ich das nicht,
es kommt natürlich auf den Kundenkreis an. Aber alles in einem File ist keine so schlechte Idee.
So kann es egal sein was der Empfänger damit macht. Ausdrucken und abheften oder nur elektronisch verarbeiten.

[Codehunter]

Zitat:

Zitat von Fritzew (Beitrag 1401220)

Ach so schlecht finde ich das nicht,
es kommt natürlich auf den Kundenkreis an. Aber alles in einem File ist keine so schlechte Idee.
So kann es egal sein was der Empfänger damit macht. Ausdrucken und abheften oder nur elektronisch verarbeiten.

Darum geht es mir primär eigentlich gar nicht. Es wird ohnehin immer mehr in Richtung elektronische Belegführung gehen. Da sind Rastergrafiken oder PDF eigentlich nur schmückendes Beiwerk.

Stell dir mal vor, es gäbe ausschließlich strukturierte Belegdaten. Diese gedankliche Papierbindung würde entfallen. Es käme nicht mehr auf die Gestaltung einer Rechnung an, weil sie der Empfänger frei gestalten könnte, solange inhaltlich alles gleich bliebe. Belege würden dann, wenn überhaupt in Papierform, in einer hausintern vereinheitlichten Form abgehangen. Bankverbindungen könnten gleich ins Onlinebanking einfließen, sodass händisches Abtippen von IBANs entfällt.

Spinnt man den Gedanken weiter, so könnte Buchhalter einer der ersten Berufe sein, die durch KI überflüssig werden. Denn Buchhaltung folgt strikten, wenn auch komplizierten Regeln. Erfolgen Input und Output als strukturierte Daten, wäre dem stark Vorschub geleistet.

[generic]

Die IX von Heise hatte einen schönen Artikel inkl. konkurierende Versionen und Standards.

https://www.heise.de/ix/heft/Struktu...h-3997217.html

[bnreimer42]

Zitat:

Zitat von Fritzew (Beitrag 1401211)

Zitat:

Ich finde auf einige Fragen rund um ZUGFeRD auch keine Antwort, z.B. wenn Rechnungsbetrag oder andere Angaben in XML und PDF differieren, was ist dann gültig?

Also sollten wir als Software-Hersteller und Co schon dafür sorgen dass alles zusammenpasst. ;-)
Solange man immer schön brav die gleichen Daten verwendet sollte dies auch kein grosses Problem darstellen.

Und wenn ich empfangene Rechnungen verarbeiten will muss ich im Zweifelsfall mit einer Texterkennung das Bitmap PDF parsen?

[Harry Stahl]

Zitat:

Zitat von sh17 (Beitrag 1401115)

Noch in den Anfängen, aber wenn es jemandem nützt, ich bin dran

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

Mich interessiert dieser Punkt auch gerade (Integration der Rechnungsdaten als XML-file nach dem ZugFeRD-Standard).

Frage: Was macht Dein Demo? Kann man damit schon spezifische XML-Tags schreiben? Oder generiert es derzeit nur den XML-Rahmen (so sieht es für mich nach einem ersten Blick in den Source aus)?

Ist das Crosscompile-fähig?

[sh17]

ich müsste mal meine lokalen Änderungen einpflegen, die liegen momentan noch in einer Delphi 6 Codebasis, die ich aber nicht integrieren möchte.

Crosscompile-fähig?, Keine Ahnung, arbeite nur mit VCL

[Harry Stahl]

OK. Falls Du irgendwann mal eine Aktualisierung vornehmen würdest wäre es schön, wenn Du hier einen Hinweis geben könntest.

[mlc42]

Hallo,

gibts zu dem Thema schon neue Erkenntnisse. Ab Herbst wird das ja nun aktuell.
Am einfachsten scheint wohl xRechnung zu sein.

Martin

[sh17]

XRechnung hat überhaupt nichts mit ZUGFeRD zu tun

siehe hier https://mind-forms.de/e-rechnung/zugferd-vs-xrechnung/

Es gibt noch Factur-X, das ist der französische Standard und entspricht ZUGFeRD, nur der PDF-Anhang heisst anders

[Lemmy]

Zitat:

Zitat von mlc42 (Beitrag 1462984)

Hallo,

gibts zu dem Thema schon neue Erkenntnisse. Ab Herbst wird das ja nun aktuell.

sorry für die Frage: Kannst Du mir sagen, was ab Herbst aktuell wird? Danke

[sh17]

Offentliche Auftraggeber nehmen ab Nov. 2020 Rechnungen nur noch elektronisch entgegen.

https://www.verband-e-rechnung.org/xrechnung/

Zitat:

Zitat von Lemmy (Beitrag 1463021)

Zitat:

Zitat von mlc42 (Beitrag 1462984)

Hallo,

gibts zu dem Thema schon neue Erkenntnisse. Ab Herbst wird das ja nun aktuell.

sorry für die Frage: Kannst Du mir sagen, was ab Herbst aktuell wird? Danke

Besonders interessant:

Zitat:

Die E-Rechnungsverordnung stellt sogar klar, dass eine E-Rechnung grundsätzlich als XRechnung einzureichen ist. Da der Standard XRechnung auf eine bildhafte Darstellung der Rechnung (z. B. PDF) verzichtet, sind hybride Rechnungen (z. B. XML-Rechnung in eine PDF/A-3-Rechnung eingebettet) streng genommen nicht zulässig.

ZUGfERD ist dann quasi nicht zulässig. "Schön, wie wieder alle an einem Strang ziehen."

[Lemmy]

Zitat:

Zitat von sh17 (Beitrag 1463049)

Offentliche Auftraggeber nehmen ab Nov. 2020 Rechnungen nur noch elektronisch entgegen.

https://www.verband-e-rechnung.org/xrechnung/

Danke. Werde ich mir nachher rein ziehen.

[Incocnito]

Zitat:

Zitat von sh17 (Beitrag 1463049)

Offentliche Auftraggeber nehmen ab Nov. 2020 Rechnungen nur noch elektronisch entgegen.

https://www.verband-e-rechnung.org/xrechnung/
...

ZUGfERD ist dann quasi nicht zulässig. "Schön, wie wieder alle an einem Strang ziehen."

Auf der Seite die du verlinkt hast steht sogar explizit,
dass Mischformate wie ZUGFeRD zulässig sind.
Nur reine PDF-Dateien nicht: "Reine Bilddateien wie PDF-Rechnungen hingegen, erfüllen die genannten Vorgaben nicht."

Oder habe ich da was falsch gelesen?

MfG
Incocnito

[sh17]

Zitat:

Zitat von Incocnito (Beitrag 1463053)

Auf der Seite die du verlinkt hast steht sogar explizit,
dass Mischformate wie ZUGFeRD zulässig sind.
Nur reine PDF-Dateien nicht: "Reine Bilddateien wie PDF-Rechnungen hingegen, erfüllen die genannten Vorgaben nicht."

Dein Zitat finde ich auf den beiden Seiten nicht. Wenn der öffentliche Auftraggeber ab Nov 2020 nur noch XRechnung entgegen nimmt, ist eben nicht
eine Hybridrechnung erlaubt (PDF + maschinenlesbares Format). XRechnung ist nur XML ohne Bild. Sie darf nicht in eine PDF eingebettet werden.

[bnreimer42]

Wer eine Primärquelle will:

Anhang zu dem Durchführungsbeschluss (EU) 2017/1870 ansehen.
Dort sind zwei XRechnungssyntaxen (ist das der korrekte Plural?) genannt:
UN/CEFACT und UBL

Die kann man als XRechnung einzeln als XML-Datei senden oder als aktuelle ZUGFeRD Spezifikation mit PDF.

Man kann sich den Aufwand der PDF-Erstellung für neue Projekte sparen, wenn man nur XML-Dateien versenden will. Im Hintergrund gibt es an allen Stellen, die ich kenne, eine eigene Visualisierung der Rechnungsdaten und oft - zumindest angedacht - eine elektronische Verarbeitung der reinen XML-Daten.

Was ich mir noch nicht angesehen habe: Diverse Länder akzeptieren E-Rechnungen nicht per Mail (Hier in Bayern dagegen erstmal nur per Mail), sondern sie müssen über ein Portal hochgeladen werden, welches dann gleich prüft.

Das ist für den Empfänger praktisch, da nur valide Rechnungsinformationen hinten raus kommen.

Man kann übrgiens nicht alle öffentlichen Einrichtungen über einen Kamm scheren. Je weiter untergeordnet Behörden sind, desto länger haben sie i.R. Zeit für die Umsetzung und dann gibt es da immer noch Variablen, die den Betrag der Rechnung enthalten.
Im Oberschwellenbereich ab 221.000€ (Ich glaube, da leigt die Grenze) müssen elektronische Rechnungen angenommen werden. Unter 1000€ müssen bis auf wetieres nicht. Das ist aber alles nicht ganz einfach, da von Bundesland zu Bundesland anders geregelt.

Also: Großer Spaß weil Infos Mangelware sind.

Gruß

Björn

[Lemmy]

Zitat:

Zitat von bnreimer42 (Beitrag 1463056)

Also: Großer Spaß weil Infos Mangelware sind.

und am Ende heißt es: Die Firmen hatten lange genug Zeit für die Umsetzung *g*