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

[Rollo62]

Genau, nur dass auch PDF und XML schon unterschiedlich sein können, je nachdem wie pingelig der Prüfer ist.
Deshalb bin ich mittlerweile fast der Meinung, vielleicht verzichtet man besser gleich auf das PDF, was ja nur optisches Beiwerk ist und hat einen Haufen Probleme weniger (technischer und finanzamtlicher Natur).

[sh17]

Zitat:

Zitat von stalkingwolf (Beitrag 1542956)

Hallo,

erstmal super Projekt. Funktioniert sehr gut.
Allerdings wird scheinbar eine Info nicht ausgelesen welche IMO ganz wichtig wäre.

Code:

 
<ram:SpecifiedTradeProduct>
    <ram:GlobalID schemeID="0160">4012345001235</ram:GlobalID>
    <ram:SellerAssignedID>TB100A4</ram:SellerAssignedID>
    <ram:Name>Trennblätter A4</ram:Name>
</ram:SpecifiedTradeProduct>

Und zwar die GlobalD. Das ist in der Regel die GLN und damit kann man Verkäufer identifizieren.
Ich sehe aktuell die Info nicht das ich dort dran komme.

Die Beispiele habe ich mir von der Seite www.awv-net.de heruntergeladen.

Anforderungen etc bitte nur über Github. Ich lese hier nicht alles mit und übernehme von hier auch keine Anregungen. Ansonsten gilt für mich auch der OpenSource Gedanke.

[jziersch]

Für diejenigen die PDFs mit ZUGFeRD Daten erzeugen müssen habe ich gerade die neue WPXOrder Bibliothek fertiggestellt.

https://www.delphipraxis.net/216155-...-erzeugen.html

Diese Bibliothek basiert auf einer Vielzahl von Klassen, die immer genau einen Sachverhalt wie er im XML stehen soll, enthalten.

Beim Lesen eine XML wird ein entsprechender Baum von Instanzen erzeugt, beim speichern rekursiv durchlaufen und geschrieben. Es werden nur Objekte und Eigenschaften geschrieben, die auch vorher erzeugt wurden, d.h. es werden keine undefinierte Objekte als leer geschrieben.

Es lassen sich alle Werte durch ansprechend der Objekt auslesen. Zu beachten ist, dass hierbei noch nicht erzeugte Objekte automatisch angelegt werden. Somit ist der Code zum Erzeugen der Daten und zum Auslesen sehr ähnlich.

Es steht ein Programm zur Verfügung, welches XML Daten automatisch in Delphi Code umwandelt. Damit sollte der Einstieg recht einfach sein.

Die eingebaute Berechnung kann das Summierungsobjekt automatisch befüllen - es wurde mit verfügbaren Beispieldaten getestet. Garantieren kann ich für die Funktionalität nicht da viele Sonderfälle (z.b. vielfache Währungen) nicht getestet werden konnten.

[haentschman]

Hallöle...8-)

@sh17:
Ich habe die Units in einem Thread verwendet. Fehlermeldung "MSXML ist nicht installiert" :? CoInitialize/CoUnitialize beim Erzeugen/Freigeben des Threads hats gebracht. (wegen TXMLDocument)

Frage:
Sind noch andere Bereiche beim Verwenden der Klassen in Threads betroffen? :gruebel:

:wink:

Nachtrag:
CoInitialize funktioniert nur direkt vor dem Aufruf

Delphi-Quellcode:

FInvoiceVersion := TXRechnungValidationHelper.GetXRechnungVersion(XMLStream);

Wenn ich das im Constructor augfrufe...gleicher Fehler. Warum? :gruebel:

[sh17]

https://github.com/LandrixSoftware/X...s/tag/v3.0.2.3

Die Bibliothek hat ein größeres Update bekommen. Neben der Umsetzung einiger Wünsche wird nun auch neben dem Profil XRechnung das Extended-Profil von ZUGFeRD 2.3.2 direkt unterstützt. Dieses Profil ist bei einigen Anforderungen (mehrere Abzugsrechnungen) schon weiter als die XRechnung-Definition. Ebenso eignet es sich besser zu Integration in eine Pdf.

Durch die Integration von Mustangproject können pdf und xml zu einer ZUGFeRD-PDF A3 kombiniert werden, wenn jemand keine entsprechenden PDF-Komponenten hat.

[BlueStarHH]

Zitat:

Zitat von sh17 (Beitrag 1543683)

https://github.com/LandrixSoftware/X...s/tag/v3.0.2.3

Die Bibliothek hat ein größeres Update bekommen. Neben der Umsetzung einiger Wünsche wird nun auch neben dem Profil XRechnung das Extended-Profil von ZUGFeRD 2.3.2 direkt unterstützt. Dieses Profil ist bei einigen Anforderungen (mehrere Abzugsrechnungen) schon weiter als die XRechnung-Definition. Ebenso eignet es sich besser zu Integration in eine Pdf.

Durch die Integration von Mustangproject können pdf und xml zu einer ZUGFeRD-PDF A3 kombiniert werden, wenn jemand keine entsprechenden PDF-Komponenten hat.

Super, danke!

[AuronTLG]

Mal am Rande: Ich bin mir zwar sicher, dass es das Thema schonmal gab, kann aber momentan leider nicht danach suchen, da die Suchfunktion kaputt ist, also frage ich es hier nochmal:

Wenn man das ZUGFeRD Profil XRECHNUNG bzw direkt die XRechnung 3.0 verwendet, so ist die Käuferreferenz (BT-10) TECHNISCH Pflicht, soll heißen, der Knoten MUSS in der XML existieren und einen Inhalt haben, um durch die Validierung durch zu kommen.

Meine einfache Frage ist: Gibt es eine Vorgabe, was da bei Rechnungen an private Unternehmen/Personen drin zu stehen hat oder kann? Bei der italienischen Fattura Elettronica gab es beim LeitwegID-Äquivalent "Codice Destinatario" explizite Vorgaben, was dort bei privaten Rechnungsempfängern drin zu stehen hat.

Für die XRechnung hierzulande finde ich dazu aber nur, was da bei Rechnungen an öffentlichen Stellen drin zu stehen hat.

[BlueStarHH]

Zitat:

Zitat von sh17 (Beitrag 1543683)

Durch die Integration von Mustangproject können pdf und xml zu einer ZUGFeRD-PDF A3 kombiniert werden, wenn jemand keine entsprechenden PDF-Komponenten hat.

Werden dabei auch die XMP-Metadaten geschrieben? Sonst validiert das PDF ja nicht mit dem Mustangproject.

Ich frage mich nämlich, was im Versionsfeld der XMP-Metadaten stehen muss: Die Version des Profils z.B. XRechnung? Die Version der Metadaten? Oder was ganz anderes? Irgendwo hatte jemand die Behauptung aufgestellt, dass dort bei XRechnung 3.0.1 die Unterversionsnummer dieser Version, also 1 oder 1.0 stehen muss. Ich finde es aber nicht mehr und halte ich auch für merkwürdig.

Code:

<rdf:Description xmlns:zf="urn:ferd:pdfa:CrossIndustryDocument:invoice:2p0#
    rdf:about=""
    zf:ConformanceLevel="XRECHNUNG"
    zf:DocumentFileName="xrechnung.xml"
    zf:DocumentType="INVOICE" 
    zf:Version="???? Was steht hier ????"/>

[sh17]

Ja die XMP-Metadaten werden da auch geschrieben.

Wie man die generell selbst generiert ist mir aber noch nicht ganz klar. Hab da noch keine klare Quelle gefunden außer die
Quellen von Mustangproject. Steig da aber noch nicht so richtig durch. Bin für Hinweise durchaus dankbar

[sh17]

Zitat:

Zitat von AuronTLG (Beitrag 1543688)

Mal am Rande: Ich bin mir zwar sicher, dass es das Thema schonmal gab, kann aber momentan leider nicht danach suchen, da die Suchfunktion kaputt ist, also frage ich es hier nochmal:

Wenn man das ZUGFeRD Profil XRECHNUNG bzw direkt die XRechnung 3.0 verwendet, so ist die Käuferreferenz (BT-10) TECHNISCH Pflicht, soll heißen, der Knoten MUSS in der XML existieren und einen Inhalt haben, um durch die Validierung durch zu kommen.

Meine einfache Frage ist: Gibt es eine Vorgabe, was da bei Rechnungen an private Unternehmen/Personen drin zu stehen hat oder kann? Bei der italienischen Fattura Elettronica gab es beim LeitwegID-Äquivalent "Codice Destinatario" explizite Vorgaben, was dort bei privaten Rechnungsempfängern drin zu stehen hat.

Für die XRechnung hierzulande finde ich dazu aber nur, was da bei Rechnungen an öffentlichen Stellen drin zu stehen hat.

Im Falle XRechnung und B2B einfach non-existent reinschreiben.