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

[haentschman]

Zitat:

IMO finde die Lösung XML mit PDF als Anhang eh schicker als umgekehrt.

...du vergißt die kleinen Firmen die ihre Rechnungen noch manuell prüfen...bis eine Software existiert die eine ÜBERSICHTLICHE Prüfung erlaubt. Bei dem Java Gedöns hast du auf einer Anzeigeseite eine Position und jede Menge evt. nicht benötigte Informationen. Jedes PDF Programm kann die Rechung anzeigen, auch wenn die XML die eigentliche Rechnung ist.

:wink:

PS:
Hat keiner eine Antwort auf meine Frage https://www.delphipraxis.net/1543516-post184.html bezüglich der Verwendung in Threads der XRechnung Unit? :gruebel:

[stalkingwolf]

ja klar die würden alle einen externen Viewer benötigen.
Aber die Dinger gibt es mittlerweile im Web wie Sand am Meer.

[t2000]

Hat sich den mal jemand mit anderer Software beschäftigt? Ich meine die Produkte der "großen" Firmen?

Bis zur Fertigstellung unserer eigenen Software, mit der wir auch Rechnungen schreiben können, nutzen wir Sage 50 Connected. Dort ist seit Sommer die E-Rechnung enthalten.
Ich kann XRech und ZUGFeRD auswählen. Da wir ein PDF wollen, habe ich natürlich ZUGFeRD ausgewählt. Ich bekomme nun meine "normale" Rechnung, wie schon seit vielen Jahren, als PDF. Nur ist jetzt der factur-x.xml Anhang für die E-Rechnung Daten entghalten. Das Ganze ist dann ZUGFeRD 2.x

Also eine "normale" Rechnung wie immer, mit eingebettetem XML. Kann jeder lesen. Ich wüsste keinen Grund, irgendwas anderes zu wollen. Es spielt hier auch keine Rolle, ob der Endkunde eine Firma oder ein Privatkunde ist. Alle bekommen dasselbe. Mit Behörden haben wir nichts zu tun.

Und genauso würde/möchte ist es in unserer Software auch einbinden.

Gibt es Erfahrungen mit anderer Software?

[sh17]

Genormt ist die sicher nicht. Nur eine Umsetzung, die sämtliche Varianten einer Rechnung visuell abbildet. Ist schon eine Herausforderung, das überhaupt zu tun. Für optisch ansprechende Varianten ist sicher noch viel Arbeit nötig. Man möchte ja auch nicht größere Abhängigkeiten, wie Bootstrap etc.

[stalkingwolf]

Zitat:

Zitat von sh17 (Beitrag 1543905)

Genormt ist die sicher nicht. Nur eine Umsetzung, die sämtliche Varianten einer Rechnung visuell abbildet. Ist schon eine Herausforderung, das überhaupt zu tun. Für optisch ansprechende Varianten ist sicher noch viel Arbeit nötig. Man möchte ja auch nicht größere Abhängigkeiten, wie Bootstrap etc.

d.h was t2000 schreibt könnte man theoretisch auch machen?
Man nimmt seine eigentlich Rechnung als PDF und fügt dort die XML Datei ein?

Ich glaube nicht mal das einer unserer Kunden das ablehnen würde. Wir sind Branchensoftware und mit den meisten sogar per Du.
Frage ist nur ob in X Jahre dann ein Steuerprüft kommt und sagt "Nö!".

Das wird nächstes Jahr.
Mich rufen Kunden an die Komplett überfordert sind und nicht mal was von X-Rechnung gehört haben und sich nur wundern warum Ihre Lieferanten sie fragen welches Format sie haben sollen ab 2025.

[sh17]

Zitat:

Zitat von stalkingwolf (Beitrag 1543909)

d.h was t2000 schreibt könnte man theoretisch auch machen?
Man nimmt seine eigentlich Rechnung als PDF und fügt dort die XML Datei ein?

Natürlich, das meine ich doch, warum kompliziert machen. Muss am Ende halt eine PDF A3 sein. wPDF kann das und sicher auch noch andere.
Wer keine passende PDF-Lib hat, kann Mustangproject nehmen.

[AuronTLG]

Also unsere Kunden drehen durch, wenn sie keine althergebrachte Rechnung lesen, ausdrucken und in der Hand halten können und Gott bewahre, was passieren würde, wenn wir deren liebevoll zusammengebauten individuellen Rechnungsformulare durch eine hässliche automatisch visualisierte PDF ersetzten. Fackeln und Mistgabeln wären das mindeste.
Von daher beschwere ich mich nicht zu sehr darüber, dass es sowohl ZUGFeRD als auch XRechnung als Format gibt, da ZUGFeRD dieses Problem recht simpel löst, solange man technisch dafür Sorge trägt, dass XML und PDF identisch sind.

Um die erwähnten Vorlieben der Kunden mit den Anforderungen der öffentlichen Stellen, die nur XRechnungs-XMLs akzeptieren, in Einklang zu bringen und nicht verschiedene Formate pflegen zu müssen, verwenden wir ZUGFeRD mit dem Profil XRECHNUNG, was quasi nichts anderes als eine PDF mit der zugehörigen XRechnungs-XML drin ist.
Damit schreiben wir grundsätzlich nur XRechnungen, die dann in die zugehörigen gewohnten Rechnungs-PDFs reingeknäult werden, womit jeder glücklich ist.

Eine Visualisierung von XRechnungen zu bauen, die anpassbare Formulare erzeugt, ist zwar theoretisch möglich, aber ein derartig großer Aufwand, dass ich das garantiert nicht selbst angehen werde. Wenn sich wer anders das antun will, bitte, aber solange bleibe ich einfach bei ZUGFeRD.

[stalkingwolf]

Zitat:

Zitat von sh17 (Beitrag 1543911)

Zitat:

Zitat von stalkingwolf (Beitrag 1543909)

d.h was t2000 schreibt könnte man theoretisch auch machen?
Man nimmt seine eigentlich Rechnung als PDF und fügt dort die XML Datei ein?

Natürlich, das meine ich doch, warum kompliziert machen. Muss am Ende halt eine PDF A3 sein.

passt danke für die Info.

[Rollo62]

Zitat:

Zitat von stalkingwolf (Beitrag 1543880)

Was natürlich super mega hyper cool wäre. Eine Lib welche aus der Zugferd XML die passende PDF generiert und die XML hinzufügt.

Ist es nicht eigentlich genau andersherum?
Du hast eine perfekt designte unmd layoutete PDF-Rechnung die mit einem Papier-Briefbogen der von teuren Designern erstellt wurde kompatibel ist und wo jeder Millimeter Space darauf genau verplant ist und seine Berechtigung hat.
Die Kunden kennen Dich seit Jahrzehnten unter deinem CI mit eigenem, coolem Briefbogen und den möchtest Du natürlich deswegen auch unbedingt beibehalten.

Also möchtest Du eigentlich nur deine bisherige PDF-Rechnung möglichst unverändert übernehmen und
nur den blöden XML-Teil irgendwie dazufrickeln.

Oder sehe ich das mal wieder zu sehr durch die rosarote Brille? :gruebel:

[stalkingwolf]

Zitat:

Zitat von Rollo62 (Beitrag 1543928)

Zitat:

Zitat von stalkingwolf (Beitrag 1543880)

Was natürlich super mega hyper cool wäre. Eine Lib welche aus der Zugferd XML die passende PDF generiert und die XML hinzufügt.

Ist es nicht eigentlich genau andersherum?

Thema ist ja schon geklärt. Ich war mir nicht sicher ob das neue PDF Layout Pflicht ist. Weil in den ganzen Beispiele ich habe und sehe diese immer gleich aussahen.

Ich habe mir mal den mustang validator heruntergeladen und eine normale PDF auf PDFA gespeichert reicht wohl nicht aus.
Habe unzählige Fehlermeldungen vor allem wegen den Metadaten.
die XML ist ok wenn ich diese einzeln validiere.

[Rollo62]

[QUOTE=stalkingwolf;1543929]

Zitat:

Zitat von Rollo62 (Beitrag 1543928)

Habe unzählige Fehlermeldungen vor allem wegen den Metadaten.
die XML ist ok wenn ich diese einzeln validiere.

Hast Du die XML auch mal damit validiert, das scheint sehr gute Ergebnisse zu liefern, ist aber nur für XML und XRechnung.
https://jcthiele.github.io/OpenXRechnungToolbox/

Einen simplen Validator für PDF suche ich auch noch.
Vielleicht funktioniert dies für Dich mit PDF?
https://belegmeister.de/zugferd-e-re...line-anzeigen/

[Papaschlumpf73]

Zitat:

Zitat von t2000 (Beitrag 1543901)

Also eine "normale" Rechnung wie immer, mit eingebettetem XML. Kann jeder lesen. Ich wüsste keinen Grund, irgendwas anderes zu wollen. Es spielt hier auch keine Rolle, ob der Endkunde eine Firma oder ein Privatkunde ist. Alle bekommen dasselbe. Mit Behörden haben wir nichts zu tun.

Ich wüsste einen Grund: Der Empfänger muss beide Rechnungsteile neben der PDF auch die XML überprüfen, da diese für das FA relevant ist. Dann muss er auch XML und PDF vergleichen, damit das FA ihm da nicht 2 Rechnungen draus macht. Alle, die weiter nach PDF-Rechnungen schreien, kapieren das anscheinend nicht. Haben wir hier auch schon mal besprochen.

[sh17]

Zitat:

Zitat von stalkingwolf (Beitrag 1543929)

Ich habe mir mal den mustang validator heruntergeladen und eine normale PDF auf PDFA gespeichert reicht wohl nicht aus.
Habe unzählige Fehlermeldungen vor allem wegen den Metadaten.
die XML ist ok wenn ich diese einzeln validiere.

Wegen den XMP Metadaten, die man in die PDF stecken muss, liefere ich noch etwas. Siehe auch hier

https://github.com/LandrixSoftware/X...lphi/issues/41

[stalkingwolf]

[QUOTE=Rollo62;1543935]

Zitat:

Zitat von stalkingwolf (Beitrag 1543929)

Zitat:

Zitat von Rollo62 (Beitrag 1543928)

Habe unzählige Fehlermeldungen vor allem wegen den Metadaten.
die XML ist ok wenn ich diese einzeln validiere.

Hast Du die XML auch mal damit validiert, das scheint sehr gute Ergebnisse zu liefern, ist aber nur für XML und XRechnung.
https://jcthiele.github.io/OpenXRechnungToolbox/

Einen simplen Validator für PDF suche ich auch noch.
Vielleicht funktioniert dies für Dich mit PDF?
https://belegmeister.de/zugferd-e-re...line-anzeigen/

Die Meldung welche ich erhalte sind.

Code:

08:24:59.698 [main] ERROR o.m.validator.ZUGFeRDValidator - Error 11: XMP Metadata: ConformanceLevel not found
08:24:59.699 [main] ERROR o.m.validator.ZUGFeRDValidator - Error 12: XMP Metadata: ConformanceLevel contains invalid value
08:24:59.700 [main] ERROR o.m.validator.ZUGFeRDValidator - Error 13: XMP Metadata: DocumentType not found
08:24:59.700 [main] ERROR o.m.validator.ZUGFeRDValidator - Error 14: XMP Metadata: DocumentType invalid
08:24:59.701 [main] ERROR o.m.validator.ZUGFeRDValidator - Error 21: XMP Metadata: DocumentFileName not found
08:24:59.701 [main] ERROR o.m.validator.ZUGFeRDValidator - Error 19: XMP Metadata: DocumentFileName contains invalid value
08:24:59.701 [main] ERROR o.m.validator.ZUGFeRDValidator - Error 15: XMP Metadata: Version not found
08:24:59.701 [main] ERROR o.m.validator.ZUGFeRDValidator - Error 16: XMP Metadata: Version contains invalid value

als letztes schreibt er raus. Das bezieht sich dann wohl auf die XML in der PDF Datei.

Code:

08:25:01.232 [main] INFO  o.m.validator.ZUGFeRDValidator - Parsed PDF:invalid XML:invalid Signature:null Checksum:30276051287C8F286998E70BFFDEF804B756BEA4 Profile:urn:cen.eu:en16931:2017#compliant#urn:xeinkauf.de:kosit:xrechnung_3.0 Version:2 Took:2774ms Errors:[]

Zitat:

Zitat von sh17 (Beitrag 1543955)

Zitat:

Zitat von stalkingwolf (Beitrag 1543929)

Ich habe mir mal den mustang validator heruntergeladen und eine normale PDF auf PDFA gespeichert reicht wohl nicht aus.
Habe unzählige Fehlermeldungen vor allem wegen den Metadaten.
die XML ist ok wenn ich diese einzeln validiere.

Wegen den XMP Metadaten, die man in die PDF stecken muss, liefere ich noch etwas. Siehe auch hier

https://github.com/LandrixSoftware/X...lphi/issues/41

ok danke für die Info.

Aber ist das nun egal oder wird die PDF abgelehnt?

[t2000]

Zitat:

Zitat von Papaschlumpf73 (Beitrag 1543944)

Zitat:

Zitat von t2000 (Beitrag 1543901)

Also eine "normale" Rechnung wie immer, mit eingebettetem XML. Kann jeder lesen. Ich wüsste keinen Grund, irgendwas anderes zu wollen. Es spielt hier auch keine Rolle, ob der Endkunde eine Firma oder ein Privatkunde ist. Alle bekommen dasselbe. Mit Behörden haben wir nichts zu tun.

Ich wüsste einen Grund: Der Empfänger muss beide Rechnungsteile neben der PDF auch die XML überprüfen, da diese für das FA relevant ist. Dann muss er auch XML und PDF vergleichen, damit das FA ihm da nicht 2 Rechnungen draus macht. Alle, die weiter nach PDF-Rechnungen schreien, kapieren das anscheinend nicht. Haben wir hier auch schon mal besprochen.

Nun ja, das stimmt wohl.
Aber ich glaube, wir werden alle in 2 Jahren ein wenig schlauer sein.

NOCH kann ich mir nicht vorstellen, dass unsere Kunden sich mit XML beschäftigen. Wir haben in diesem Jahr, 2024, immer noch Kunden, die mit TSE hadern und es nicht, nicht richtig, unvollständig, einsetzen. Ich denke, erst wenn die ersten größeren Probleme bei Prüfungen kommen, werden die aufwachen. Es gibt bei unseren Kunden noch wirklich viele, die meinen sie bräuchten nichts "Digitales". Verarbeiten aber das meiste mit PC und Software.

[sh17]

Zitat:

Zitat von stalkingwolf (Beitrag 1543957)

Aber ist das nun egal oder wird die PDF abgelehnt?

Probier mal

https://www.portinvoice.com/

[stalkingwolf]

Zitat:

Zitat von sh17 (Beitrag 1543960)

Zitat:

Zitat von stalkingwolf (Beitrag 1543957)

Aber ist das nun egal oder wird die PDF abgelehnt?

Probier mal

https://www.portinvoice.com/

die gibt aus.

Code:

Nein, kann keines der folgenden Elemente finden: "/rsm:CrossIndustryDocument/rsm:SpecifiedExchangedDocumentContext/ram:GuidelineSpecifiedDocumentContextParameter/ram:ID", "/rsm:CrossIndustryInvoice/rsm:ExchangedDocumentContext/ram:GuidelineSpecifiedDocumentContextParameter/ram:ID" oder "/Invoice/cbc:CustomizationID"

Interessant ist wenn ich nur die XML reinwerfe, dann ist Mustang und Koordinationsstelle für IT Standards korrekt und valitool gibt die Meldung oben aus.

[sh17]

wie lautet der Dateiname der xml in der pdf?

[stalkingwolf]

Zitat:

Zitat von sh17 (Beitrag 1543962)

wie lautet der Dateiname der xml in der pdf?

ne das hat sich erledigt. Er hat an was anderem gemeckert. ( Datei heißt factur-x.xml )
Interessanterweise war das anderen Validatoren egal. Wir hatten kein Leistungsdatum gefüllt. (DeliveryInformation.ActualDeliveryDate)


Die Seite lehnt unsere PDF immer ab.
Ich vermute das dieser von einer anderen XML Datei ausgeht.

Wir generieren die XML Datei über ZUGFeRDExtendedVersion_232 : TXRechnungInvoiceAdapter301.SaveDocumentUNCEFACT(_ Invoice,_Xml,false);
Ich denke das wir in die XMP Metadaten der PDF die falschen Infos schreiben.
Aber ich kann gerade nicht erkennen welche korrekt wären.

Meldung:

Code:

Nein, kann keines der folgenden Elemente finden: "/rsm:CrossIndustryDocument/rsm:SpecifiedExchangedDocumentContext/ram:GuidelineSpecifiedDocumentContextParameter/ram:ID", "/rsm:CrossIndustryInvoice/rsm:ExchangedDocumentContext/ram:GuidelineSpecifiedDocumentContextParameter/ram:ID" oder "/Invoice/cbc:CustomizationID"

unsere Metadaten:

Code:

<xmp:DocumentType>INVOICE</xmp:DocumentType>
<xmp:DocumentFileName>factur-x.xml</xmp:DocumentFileName>
<xmp:Version>2.3</xmp:Version>
<xmp:ConformanceLevel>EN 16931</xmp:ConformanceLevel>

[jziersch]

Kann es sein, dass Dein namespace "xmp" falsch ist?

Ich verwende dies:

Code:

   '<rdf:Description xmlns:fx="urn:factur-x:pdfa:CrossIndustryDocument:invoice:1p0#"' + #32 + 'rdf:about="">' + #10 +
   '<fx:DocumentType>INVOICE</fx:DocumentType>' + #10 +
   '<fx:DocumentFileName>factur-x.xml</fx:DocumentFileName>' + #10 +
   '<fx:Version>1.0</fx:Version>' + #10 +
   '<fx:ConformanceLevel>EXTENDED</fx:ConformanceLevel></rdf:Description>' + #10;

Validiert habe ich das hier:
https://portal3.gefeg.com/invoice/page/validation

[stalkingwolf]

Zitat:

Zitat von jziersch (Beitrag 1543970)

Kann es sein, dass Dein namespace "xmp" falsch ist?

Ich verwende dies:

Code:

   '<rdf:Description xmlns:fx="urn:factur-x:pdfa:CrossIndustryDocument:invoice:1p0#"' + #32 + 'rdf:about="">' + #10 +
   '<fx:DocumentType>INVOICE</fx:DocumentType>' + #10 +
   '<fx:DocumentFileName>factur-x.xml</fx:DocumentFileName>' + #10 +
   '<fx:Version>1.0</fx:Version>' + #10 +
   '<fx:ConformanceLevel>%s</fx:ConformanceLevel></rdf:Description>' + #10;

Validiert habe ich das hier:
https://portal3.gefeg.com/invoice/page/validation

btw der Validator erkennt die XML in der PDF und prüft diese auch

Bei uns ist es so

Code:

 '<rdf:Description xmlns:fx="urn:factur-x:pdfa:CrossIndustryDocument:invoice:1p0#" rdf:about="">'+
                '<fx:DocumentType>'+Info.Zugferd_DocumentType+'</fx:DocumentType>'+
                '<fx:DocumentFileName>'+Info.Zugferd_DocumentFileName+'</fx:DocumentFileName>'+
                '<fx:Version>'+Info.Zugferd_Version+'</fx:Version>'+
                '<fx:ConformanceLevel>'+Info.Zugferd_ConformanceLevel+'</fx:ConformanceLevel>'+
                '</rdf:Description>'));

Mustang erkennt das auch und meldet nicht das es fehlt.
Schreibe ich eins falsch oder etwas falsches z.b in Version, dann wird wird das gemeldet

weiß jemand wie wichtig folgendes ist

Code:

die Einbettung der XML-Datei [B]über eine Beziehung vom Typ "Alternative"[/B] mit Bezug auf das gesamte Dokument.

weil ich füge die XML in die PDF mit PDFium ein und der kann keine Relationship oder Bezeichnung setzen.

Ich vermute das die Tools die XML nicht finden/erkennen und dann die Meldung ausgeben.
Aber auch nur eine Vermutung. Aktuell bin ich etwas aufgeschmissen wo das Problem liegt

[Kostas]

Muss die Komponente aus dem Github als Komponewnte installiert werden oder nur die Files in das Projekt kopieren. Es gibt keine Anleitung über die Installation.

[sh17]

Zitat:

Zitat von Kostas (Beitrag 1544138)

Muss die Komponente aus dem Github als Komponewnte installiert werden oder nur die Files in das Projekt kopieren. Es gibt keine Anleitung über die Installation.

Die Dateien müssen im Suchpfad verfügbar sein.

[Papaschlumpf73]

Kurzer Erfahrungsbericht zu E-Rechnungsportalen:

Wir versenden inzwischen ausschließlich XRechnungen, da unsere Kunden fast ausschließlich Körperschaften des öffentlichen Rechts sind - die zwei gewerblichen Kunden müssen sich damit arrangieren :-) Dazu verwenden wir die Bibliothek XRechnung-for-Delphi von Sven Harazim bzw. Landrix Software - das funktioniert wirklich super.

Beim Versand über die E-Rechnungsportale hatte ich am Anfang so meine Bedenken. Inzwischen haben die sich aber alle in Luft aufgelöst. Bei einigen Portalen muss man sich einmalig registrieren; bei anderen nicht. Bei allen (von unseren Kunden verwendeten) Portalen können wir die Rechnungen einfach per E-Mail an das Portal senden. Einfach die XRechnungs-XML anhängen und ohne Text absenden. Dafür muss man sich weder jedesmal irgendwo einloggen oder die Rechnungen separat irgendwo hochladen.

Hoffentlich kommt nicht nächsten Monat ein Kunde mit einem ganz exotischen Portal um die Ecke… :-)

[Kostas]

Ich habe eine Frage zum Konzept der Komponente:

Ist das so richtig: Vor E-Rechnung haben wir aus unserer Anwendung heraus eine Rechnung.pdf erzeugt. Jetzt erzeugen wir eine E-Rechnung.xml über die Komponenten und fügen E-Rechnung.xml in unsere bisherige Rechnung.pdf als Anhang über Fastreport ein. Der E-Rechnungs-Viewer, ich meine das Java Projekt welches mit der Komponente mitkommt, kann nur einen Report, eine Art Aufstellung aus dem E-Rechnung.xml erzeugen jedoch NICHT aus dem E-Rechnung.xml ein standardisierte Rechnung.pdf erzeugen. Ist da so korrekt? Benötigt man überhaupt die Möglichkeit aus der E-Rechnung.xml eine Rechnung.pdf zu erzeugen?

[sh17]

Die XML stellt die tatsächliche Rechnung dar. Im Falle einer XRechnung fehlt also das Belegbild, damit auch ein Mensch die Rechnung lesen kann. Dafür nimmt man die beiliegende Java Komponente und lässt aus der XML ein Belegbild erzeugen - eine Visualisierung. Dieses Belegbild ist keine Rechnung - die XML ist die Rechnung.
Im Falle von ZUGFeRD liefert man selbst das Belegbild mit und steckt seine Rechnung in XML hinein.

[Kostas]

Wie kann ich so ein Belegbild erzeugen?

oder ist es das hier wie im Bild?

Dann bitte noch eine Kleinigeit. In meinen Rechnungen sind normale Artikel-Positionen enthalten und eine Gruppen von Unterpositonen. Das sind eine Auflistung an Wiegescheinen die berechnet werden.
Bei ZUGFerD können keine Unterpositionen angelegt wewrden bei UBL-E-Rechnung schon. Ist das eine Limitierung des Formats oder der Komponente?

[Kostas]

Zitat:

Zitat von sh17 (Beitrag 1545282)

...Im Falle von ZUGFeRD liefert man selbst das Belegbild mit und steckt seine Rechnung in XML hinein.

verste ich das richtig? die Rechnung.pdf als Anhang in der Rechnung.xml in Base64? codiert? oder umgekehrt. In dem PDF wird das xml integriert, so haben wir das umgesetzt.

[sh17]

XRechnung - die Rechnung.pdf als Anhang in der Rechnung.xml in Base64 codiert (muss man aber nicht)

ZUGFeRD - In dem PDF wird das xml integriert


wegen den Subinvoicelines bei CII muss ich schauen, gehört normal nicht zum Standard, das ist eine Erweiterung

[stalkingwolf]

Moin,

die Zugferd Dateien welche wir in 2024 bei unseren Test erstellt haben funktionieren nicht mehr.
Wir erhalten nun die Meldung

Code:

[BR-DE-21] Das Element "Specification identifier" (BT-24) soll syntaktisch der Kennung des Standards XRechnung entsprechen.
Pfad: /rsm:CrossIndustryInvoice/rsm:ExchangedDocumentContext[1]

Wir erstellen diese ZUGFeRDExtendedVersion_232 -> TXRechnungInvoiceAdapter301.SaveDocumentUNCEFACT
Dateien mit XRechnungVersion_30x_UBL generiert funktionieren einwandfrei.

Wenn ich das korrekt lese ist damit folgender Teil gemeint oder?

Code:

<ram:GuidelineSpecifiedDocumentContextParameter>
<ram:ID>urn:cen.eu:en16931:2017#conformant#urn:factur-x.eu:1p0:extended</ram:ID>
</ram:GuidelineSpecifiedDocumentContextParameter>

[sh17]

Also eine ZUGFeRDExtendedVersion_232 Version kann man mit dem XRechnung Validator nicht testen.

[stalkingwolf]

Zitat:

Zitat von sh17 (Beitrag 1545763)

Also eine ZUGFeRDExtendedVersion_232 Version kann man mit dem XRechnung Validator nicht testen.

Das hatte bis Ende 2024 einwandfrei funktioniert z.b mit https://sbw.landbw.de/serviceportal ( ist heute Morgen in Wartung ).
angeblich hab es eine Änderung am 1.1.2025 gegeben bezüglich Specified Document.

https://portal3.gefeg.com/invoice/validation lief auch einwandfrei durch. Auch das bringt nun einen Fehler

Evtl bin ich auch aktuell mächtig auf dem Holzweg.

Wenn ich unseren Kunden eine PDF mit E-Rechnung als Anhang senden will. Was nehme ich dann am besten für ein Format?

[sh17]

Zitat:

Zitat von stalkingwolf (Beitrag 1545765)

Wenn ich unseren Kunden eine PDF mit E-Rechnung als Anhang senden will. Was nehme ich dann am besten für ein Format?

Man kann alle Formate in die PDF packen, man muss es nur richtig tun.

[AuronTLG]

Zitat:

Wenn ich unseren Kunden eine PDF mit E-Rechnung als Anhang senden will. Was nehme ich dann am besten für ein Format?

Das hängt von den geschäftlichen Umständen ab.

Ich persönlich benutze das ZUGFeRD-Profil XRECHNUNG. Dieses besteht darin, dass man eine XRechnung (auf Grundlage des XRechnungsformates) in die PDF steckt.
Hintergrund ist, dass meine Kunden häufig ERechnungen an öffentliche Stellen schicken, die nur reine XRechnungen und keine ZUGFeRDs akzeptieren während die Geschäfts- oder Privatkunden ihre normalen PDFs haben wollen. Mit dem ZUGFeRD-Profil XRECHNUNG erzeugt man in allen Fällen gültige XRechnungen, die man entweder in eine PDF stecken kann, für B2B oder B2C, oder auch nicht, wie eben im Falle einer öffentlichen Stelle als Empfänger. Man muss also nur ein Format pflegen.

Edit: Ups, glaube ich habe das missverstanden. Es geht nicht darum, ein ZUGFeRD-Erzeugung bereitzustellen, sondern nur darum, selbst ZUGFeRDs an Kunden zu verschicken, oder?

[stalkingwolf]

Zitat:

Zitat von AuronTLG (Beitrag 1545778)

Zitat:

Wenn ich unseren Kunden eine PDF mit E-Rechnung als Anhang senden will. Was nehme ich dann am besten für ein Format?

Das hängt von den geschäftlichen Umständen ab.

Ich persönlich benutze das ZUGFeRD-Profil XRECHNUNG. Dieses besteht darin, dass man eine XRechnung (auf Grundlage des XRechnungsformates) in die PDF steckt.
Hintergrund ist, dass meine Kunden häufig ERechnungen an öffentliche Stellen schicken, die nur reine XRechnungen und keine ZUGFeRDs akzeptieren während die Geschäfts- oder Privatkunden ihre normalen PDFs haben wollen. Mit dem ZUGFeRD-Profil XRECHNUNG erzeugt man in allen Fällen gültige XRechnungen, die man entweder in eine PDF stecken kann, für B2B oder B2C, oder auch nicht, wie eben im Falle einer öffentlichen Stelle als Empfänger. Man muss also nur ein Format pflegen.

Edit: Ups, glaube ich habe das missverstanden. Es geht nicht darum, ein ZUGFeRD-Erzeugung bereitzustellen, sondern nur darum, selbst ZUGFeRDs an Kunden zu verschicken, oder?

Hallo. Danke für die Info. Wir haben das ganze umgestellt und damit hat es direkt funktioniert.
Die Datei werden ohne Warnings akzeptiert.

[Rollo62]

Ist vielleicht auch interessant, zum Thema Kleinunternehmer
https://www.onlinehaendler-news.de/r...men-verwirrung
http://www.dstv.de/stellungnahmen-po...vom-18.03.2025
https://www.bundesfinanzministerium....cationFile&v=3

[sqlman]

Hallo zusammen,

auch wir sind, wie viele andere, gerade in der Implementierungvon ZUGFerD, XRechnung usw.

Erst einmal vorweg vielen Dank an die vorherigen Verfasser, das ihr euer Vorgehen hier darstellt. Ich bleibe mit meiner Frage daher mal hier im Thread (wenn falsch, bitte Hinweis), da es - so denke ich - hier ganz gut reinpasst (Zukunft mit XRechnung/ZugPferd).

Unser aktuelles Vorgehen wird sein, die aktuelle PDF-Rechnungserzeugung mit dem XML-Rechnungsanhang zu versehen. Für unsere Kunden scheint das momentan der einfachste Weg.

Folgende Dinge, liegen aber bei uns noch im Nebel verborgen. Zumindest hatte ich bei diesen Frage Probleme, das hier im Thread herauszulesen:

Validierung: aktuell gehe ich davon aus das diese nur während der Implementierung beim Test nötig ist? Manchmal klingt es, als ob jede Rechnung nach Erzeugung validiert werden sollte? Das verstehe ich da dann doch falsch, oder?

Ausgehend davon, das nicht jede Rechnung validiert werden muss: Was passiert eigentlich, wenn die XML dann mal "kaputt" ist? Storno der Rechnung und neue Rechnung unter neuer Rechnungsnummer mit korrigierter Programmversion erzeugen? Oder wird nur die Rechnung wie früher als Duplikat gedruckt und der XML-Teil korrigiert?
Geht ja auch nicht, weil ja nach dem Druck/erzeugen der Rechnung diese unveränderbar archiviert werden sollte. Im obigen Beispiel habe ich dann eine fehlerhafte ZugFerd-Rechnung im Archiv. Was erst einmal seltsam ist, aber (Annahme) aus Prüfersicht richtig, weil die ja ganz normal storniert und neu erzeugt würde?

Wie oft sind solche Fälle (Rechnung ist im XML-Format fehlerhaft und wirft beim Kunden Probleme auf) in euren Implementierungen vorgekommen und wie seid ihr damit umgegangen?

Kurze Info: Unser Softwareprojekt ist eine Software für Heizkostenabrechner/Energielieferanten/Stadtwerken. Von Sachbearbeitern werden hunderte Rechnungen erzeugt, die meisten davon automatisiert.

Danke im voraus
Gruß
Ralf

[BlueStarHH]

Jede Rechnung sollte validiert werden. Durch andere Inhalte könnte die Rechnung ja ungültig werden.

[AuronTLG]

Auf irgendeine Weise MUSS unbedingt validiert werden, entweder durch einen selbst oder durch einen externen Validator wie Mustang.
Es sollte für den Anwender nicht möglich sein, eine ungültige oder gar kaputte XRechnung zu erzeugen, und wenn, muss er deutlichst darauf hingewiesen werden.
Was für einen Sinn macht es, still und heimlich eine kaputte oder nicht valide XRechnung zu erzeugen, die dann vom nichts ahnenden Anwender irgendwohin geschickt, mit 100%iger Wahrscheinlich abgelehnt und dann zurückgeschickt wird, woraufhin sich der Anwender einen Ast freut?

Ich mache vor meinem "Druckvorgang" quasi zwei Validierungen. Die erste ist intern von mir selbst erstellt und schaut nach typischen Fehlern und häufig fehlenden Informationen, zu denen sie programmspezifische Hinweise gibt, wie die zu beheben sind.
Ist die interne Validierung in Ordnung, erzeuge ich eine XRechnung und jage den Mustang-Validator drüber. Gibt der auch sein OK, wird der "Rechnungsdruck" ausgeführt.

[Rollo62]

Validieren ist schon sinnvoll.
Aber ist es nicht so, dass eigentlich der Empfänger validieren muss, sonst darf er kann er das nicht weiterverarbeiten?

Meine Kunden sind aktuell noch in der Umsetzung und manchen ist die Validität ziemlich Wurscht.
Ich frage mich, ob DATEV oder sonstige Rechnungswesen Apps da validieren ( und nein, meine Kunden haben kein SAP sondern eigene Lösungen ).

Gibt es vielleicht schon eine Liste kompatibler Software?