Wie ZUGFeRD Demo von SH17 verwenden?

[Harry Stahl]

Ja, wie so viele muss ich mich nun auch daran machen, die elektronische Rechnung in mein Rechnungsprogramm zu integrieren.

Diesbezüglich wurde ja hier immer wieder im Forum die von SH17 entwickelte Lösung angesprochen.

Ich haben mir nun die (gepackt) 354 MB mal von Github runtergeladen, fühle ich jetzt aber ein wenig erschlagen von den ganzen zugferd1.x und zugferd 2.x Dateien (alles zusammen 2357 Dateien). Was ist da nun für mich relevant, was nicht, was ist inzwischen evtl. überholt?

Ich habe im Ordner "Samples" ein Projekt gefunden, weiß aber nicht so recht damit was anzufangen (es hat nur 3 Buttons ohne weitere Erklärungen).

Ich suche eigentlich nur ein Beispiel, wo ich gezeigt bekomme, wie ich typische Rechnungsdaten (sozusagen die Basics) in ein XML-Format (die erwartete XML-Datei "ZUGFeRD-invoice.xml") bekomme.

Gibt es da so ein Beispiel und ich habe es nur übersehen?

[omnibrain]

Ich hab mich mehrfach mit beschäftigt und an seinem Webinar teilgenommen, weiß aber immer noch nicht so recht was sein ZUGFeRD-Projekt macht. Ich glaube du willst erstmal https://github.com/LandrixSoftware/XRechnung-for-Delphi dort ist in den Samples alles drin um das XML zu erzeugen. Damit haben wir vor längerem schon erfolgreich XRechnung implementiert. Für den Anfang haben wir einfach den Code aus dem Sample kopiert und dann alles mit eigenen Daten gefüllt.
Für ZUGFeRD musst du die Variante XRechnungVersion_30x_UNCEFACT nehmen und das XML dann irgendwie in dein PDF kriegen. Das hängt davon ab was du benutzt um das PDF zu erzeugen.

[Harry Stahl]

Danke Dir sehr!:-D Da hätte ich ja lange suchen können...

[sh17]

Oder mich fragen

Im November werden die beiden Github-Repositories ZUGFeRD und XRechnung zusammengelegt. Dann hat das ganze Drama ein Ende. Nähere Infos im November.

[Harry Stahl]

Zitat:

Zitat von sh17 (Beitrag 1542432)

Oder mich fragen

Ja, danke, mache ich mal direkt.

1. Wenn ich das richtig sehe, muss ich eine JAVA-Runtime Bibliothek auf meinem PC installieren, um die Validierung mit Deinem Tool durchzuführen?
2. Wenn das so ist, müsste dann JAVA auch auf dem PC des Users zur Verfügung stehen, wenn man die Validierung dort auch nutzen wollte?
3. Ich gehe davon aus, dass die Lösung nur für Windows gedacht ist, aber nicht auch für macOS und Linux funktioniert?

[BlueStarHH]

Zitat:

Zitat von Harry Stahl (Beitrag 1542457)

Ja, danke, mache ich mal direkt.

1. Wenn ich das richtig sehe, muss ich eine JAVA-Runtime Bibliothek auf meinem PC installieren, um die Validierung mit Deinem Tool durchzuführen?
2. Wenn das so ist, müsste dann JAVA auch auf dem PC des Users zur Verfügung stehen, wenn man die Validierung dort auch nutzen wollte?
3. Ich gehe davon aus, dass die Lösung nur für Windows gedacht ist, aber nicht auch für macOS und Linux funktioniert?

Ich hoffe ich darf das auch beantworten ;-)
Du und der Anwender Deiner Software brauchen Java. Java gibt es auch für macOS und Linux. SH17 hat eine freie Java-Implementation in die Lib aufgenommen. Rufe mal die installtools.ps1 auf, die lädt alle benötigten Dateien herunter.

[sh17]

Danke BlueStarHH :)

Alles zu finden unter

https://github.com/LandrixSoftware/X...r/Distribution

MacOS und Linux hab ich noch nicht geprüft, da wird es generell an MSXML scheitern. Was steht da in
Delphi zur Verfügung? Ich hab keine Ahnung.

[BlueStarHH]

Zitat:

Zitat von sh17 (Beitrag 1542459)

MacOS und Linux hab ich noch nicht geprüft, da wird es generell an MSXML scheitern. Was steht da in
Delphi zur Verfügung? Ich hab keine Ahnung.

Zumindest für das TXMLDocument kann man die Eigenschaft DomVendor von MSXML auf z.B. auf "Omni XML (CrossPlatform)" stellen.

[Harry Stahl]

Und noch ne Frage: Ist der Source-Code nun kostenlos nutzbar oder muss man eine kommerzielle Lizenz erwerben?

Im Source selber steht:

"License XRechnung-for-Delphi

Copyright (C) 2024 Landrix Software GmbH & Co. KG
Sven Harazim, [e-mail]
Version 3.0.2

This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version."

Also hier "Free Software", andererseits auf Github diese Aussagen: https://github.com/LandrixSoftware/X...ial.license.md

Um es direkt klar zu stellen, wenn ich hiervon etwas nutzen würde, wäre es kein Problem dafür etwas zu zahlen, mir geht es nur darum zu wissen, was nun gilt.

[shebang]

Die beiden Lizenzen sind aus meiner Sicht kein Widerspruch. Du hast halt 2 Optionen:
- GPL v3
- kommerzielle Lizenz
Wenn du die (kostenlose) GPL nutzen möchtest, dann musst du deine Software ebenfalls unter der GPL veröffentlichen. Wenn das für dich nicht in Frage kommt, dann kannst du eine kommerzielle Lizenz erwerben. Falls diese Darstellung nicht korrekt ist, wird mich sh17 sicher korrigieren.

[Harry Stahl]

Zitat:

Zitat von shebang (Beitrag 1542480)

Die beiden Lizenzen sind aus meiner Sicht kein Widerspruch. Du hast halt 2 Optionen:
- GPL v3
- kommerzielle Lizenz
Wenn du die (kostenlose) GPL nutzen möchtest, dann musst du deine Software ebenfalls unter der GPL veröffentlichen. Wenn das für dich nicht in Frage kommt, dann kannst du eine kommerzielle Lizenz erwerben. Falls diese Darstellung nicht korrekt ist, wird mich sh17 sicher korrigieren.

OK, alles klar, danke für die Info.

[himitsu]

Sowas nennt sich Dual- bzw. Multi-Lizenz.

Hier werden Zwei angeboten, wovon du dir eine aussuchen kannst, welche zu deinem Projekt am Besten passt.
Es müssen nicht Beide gleichzeitig angewendet werden.

Wie shebang schon sagte: Ist dein Programm quasi OpenSource, dann nimm die GPL und wenn nicht, dann "kauf" die andere Lizenz. :stupid:

Ich nutze für meine OpenSource-Sachen z.B. eine Lizenz, welche aus MPL, GPL und LGPL besteht.
Also auch andersrum, wenn z.B. dein Programm selbst unter der GPL steht, dann sind viele andere Lizenzvereinbarungen oftmals blockiert, aber so kannst du dir hier dann einfach ebenfalls die GPL nehmen und schon passt es.

[Harry Stahl]

So, ich habe jetzt mal bei den units:

intf.XRechnungHelper.pas
intf.XRechnung_3_0.pas
intf.XRechnung_2_3.pas
intf.XRechnung.pas
intf.Invoice.pas

wo irgendwelche Verweise auf Windows XML drin waren rausgenommen. Da sind dann die hälfte aller Funktionen rot unterkringelt. Es reicht hier leider nicht, irgendwo eine DomVendor Eigenschaft zu ändern.

Leider kenn ich mich mit XML überhaupt nicht aus (im Sinne der Erzeugung, wie man es normalerweise macht), daher könnte ich den Code hier auch nicht umarbeiten (was wahrscheinlich mehr Arbeit macht, als das was ich nun machen werde).

Werde mir daher hier wohl einige Beispiel-XML-Vorlagen machen und da den Text jeweils ersetzen, ergänzen oder löschen. Da mein Programm eh nur ganz einfache Rechnungen (so im BASIC-Stil) erzeugen kann, sollte das erst mal ausreichen.

Vielleicht gibt es die Library ja irgendwann noch mal für Crosscompile, dann kann ich mir das ja noch mal ansehen...

Davon mal abgesehen: Wow: Was für eine Fleißarbeit da drin steckt, sieht ja für die Nutzung unter Windows sehr gut aus.:thumb:

Nachtrag: Habe mal ChatGPT befragt und eine Funktion für die XML-Basic-Erstellung im Cross-Compatiblen XML-Format bekommen. Werde es dann doch erst mal über die XML-Variante (mit Hilfe von ChatGPT) versuchen.

[sh17]

Also wenn du nur XML erzeugen möchtest, dann müsste man nur den ganzen lesenden Teil entfernen und es sollte dann auch unter Linux funktionieren. Nur der lesende Teil benötigt XPath. Ich kann dir gern helfen, mich kann man auf Stundenbasis beauftragen :)

[Harry Stahl]

Zitat:

Zitat von sh17 (Beitrag 1542497)

Also wenn du nur XML erzeugen möchtest, dann müsste man nur den ganzen lesenden Teil entfernen und es sollte dann auch unter Linux funktionieren. Nur der lesende Teil benötigt XPath. Ich kann dir gern helfen, mich kann man auf Stundenbasis beauftragen :)

Ich werde das mal versuchen. Was ich noch nicht so ganz verstanden habe: Die Demo in "XRechnung-for-Delphi-master" kann ja sowohl eine XML-Datei für X-Rechnung erstellen, als auch eine XML-Datei für das ZUGFeRD Format.

Warum steht in der unit "intf.XRechnung" der Hinweis "setzt ZugFeRD-for-Delphi voraus"? und dann das Define "{.$DEFINE ZUGFeRD_Support}".
Ich habe das nicht aktiviert.

Die XML wird doch auch ohne das erstellt?

Ferner: Wärst Du dafür offen, Deine Unit-Struktur ein wenig zu ändern und den lesenden und schreibenden Teil in 2 unterschiedliche units zu verlagern? Ich möchte nicht jedesmal wenn es updates oder fixes gibt die unit auseinander dividieren, damit ich den schreibenden Teil im CrossCompile-Modus verwenden kann.

Oder zumindest in den Units per IFDEFs die "

Xml.Win.msxmldom, Winapi.MSXMLIntf, Winapi.msxml

units nur aktivierst, wenn ein "IFDEF "LOADXML" gesetzt ist? ( Oder mit einem "IFNDEF SKIPLoad" sie standardmaäßig aktiviert hast, aber man mit einem einfachen define das alles deaktivieren kann?)

Entsprechend für alle "Load" - Funktionen.

Ich habe es jetzt soweit unter Linux zum Laufen gebracht, indem ich in allen units die genannten ausgeklammert habe und in der Unit Rechnungshelper in der Klasse die SelectNode-Prozeduren ausgeklammert habe.

[sh17]

Zitat:

Warum steht in der unit "intf.XRechnung" der Hinweis "setzt ZugFeRD-for-Delphi voraus"? und dann das Define "{.$DEFINE ZUGFeRD_Support}".
Ich habe das nicht aktiviert.

Der Hinweis bezieht sich auf das DEFINE. Es funktioniert auch alles ohne, wenn man sich auf das ZUGFeRD-Profil "XRechnung" beschränkt. (was vollkommen ausreicht, um eine ERechnung zu erstellen)

Die Zusammenhänge kannst Du Dir gern in der Dokumentation der Standards erlesen, da ist viel beschrieben. Die sollte man sowieso mal gelesen haben, damit man weiß, was alles mit ERechnung geht.

Dein Wunsch kann ich gern im Hinterkopf behalten, momentan ist das zeitlich nicht zu machen, es sei denn du beauftragst mich offiziell.

[Harry Stahl]

Zitat:

Zitat von sh17 (Beitrag 1542559)

Zitat:

Warum steht in der unit "intf.XRechnung" der Hinweis "setzt ZugFeRD-for-Delphi voraus"? und dann das Define "{.$DEFINE ZUGFeRD_Support}".
Ich habe das nicht aktiviert.

Dein Wunsch kann ich gern im Hinterkopf behalten, momentan ist das zeitlich nicht zu machen, es sei denn du beauftragst mich offiziell.

Na, man Dir ja nicht nachsagen, dass Du nicht geschäftstüchtig bist...

Aber eine Auftragsvergabe für max. 20 Minuten Arbeit bringt weder mir noch Dir was, zumal ich die Sache schon erledigt habe. Ich kann Dir gerne die units mit den entsprechenden IFDFES zur Verfügung stellen, so dass diese auch unter FMX bzw. Crossplattform einsetzbar sind. Für VCL bleibt alles wie es ist. Für FMX, ab Delphi 11.1 funktioniert das automatisch, Anwender mit früheren Delphi-Versionen müssen bei FMX-apps im Projekt nur einmal die Bedingung "FrameWork_FMX" setzen (ab 11.1 ist es automatisch bei FMX-Anwendungen gesetzt).

Die Units haben die Fassung, die ich am 21. Oktober von Github geladen habe. Wenn Du zwischenzeitlich da Änderungen eingebaut hast, können wir auch warten, bis Du im November alles zusammengeführt hast, dann mache ich das gern noch einmal (um es dann nie mehr machen zu müssen).

Ich habe Dir übrigens per PN eine Bestellung für die Lizenz zukommen lassen.

[Harry Stahl]

Ich hatte vergeblich nach einer Möglichkeit gesucht, auch ein Betreff in die X-Rechnung zu integrieren und dann in Deinem Code gesehen, dass Du da noch ein offenes TODO dafür hattest.

Das habe ich jetzt mal schnell selbst ergänzt:

1. Neue Variable "InvoiceSubjectCode" in der Klasse "TInvoice" eingeführt (unit intf.invoice).
2. Code in unit 'intf.XRechnung_3_0" und unit 'int.XRechnung_2_3' wie folgt ergänzt / geändert:

Delphi-Quellcode:

with AddChild('ram:IncludedNote') do
    begin
      AddChild('ram:SubjectCode').Text := _Invoice.InvoiceSubjectCode; // BT-21

      for i := 0 to _Invoice.Notes.Count-1 do begin
      //with AddChild('ram:IncludedNote') do
      //begin
        AddChild('ram:Content').Text := _Invoice.Notes[i].Content; // BT-22
        //TODO <ram:SubjectCode>ADU</ram:SubjectCode>, bei UBL auch
      end;
    end;

Scheint zu funktionieren, der Validator Quba weist es jedenfalls so aus (Zeile Betreff, für BT-21), siehe screenshot in Anlage.

Wenn Du der Ansicht bist, dass das so richtig ist, wäre meine Anregung, das Du das so in Deine Implementierung übernimmst.

Generelle Frage: Ist es Dir lieber, solche Hinweise / Anregungen hier auf der DP zu sehen, in einem Kommentar auf GitHub oder sollte man Dir das per Mail zusenden?

Übrigens: Die Basic-Implementation für ZUGFeRD habe ich somit fertig, inklusive ordnungsgemäße Einbettung der XML-Datei "factur-x.xml" in ein PDF/A-3 Dokument (wobei ich das mit den Komponenten gemacht habe, die ich auch für mein Programm "PDF-Manager" verwende). Ich denke, das ging jetzt doch sehr viel schneller als eine Hin und Her mit ChatGPT. Hoffe der Rest geht auch flott (wobei der Rest bedeutet die Formate "Comfort und Extended" zu implementieren, dafür muss ich eine Reihe von neuen Feldern in meine Masken aufnehmen. Das wird ja wohl auch schon für die X-Rechnung B2G notwendig sein, weil da ja auch eine Reihe zusätzlicher Felder benötigt werden).

EDIT: Nee, das funktioniert so leider nicht, das hatte ich nicht richtig verstanden. SubjectCode ist wohl immer eine Erklärung für den Content.

Dh. man müsste wohl eher die Klasse TInvoiceNote um einen Member "ID" ergänzen, der kann dann "ADU", "AAI" etc. enthalten.

Aber im Betreff erhalte ich dann auch nur "ADU". Kann das so richtig sein? Wohl eher nicht, oder?

[Harry Stahl]

Weiterer Vorschlag: Du hast die BT-82 (Information für das Zahlungsmittel) noch nicht abgedeckt. Daher habe ich in der Klasse TInvoice aufgenommen:

PaymentMeansInformation : String;

In procedure "SaveDocumentUNCEFACT" (jeweils in units "intf.XRechnung_2_3 und intf.XRechnung_3_0) habe ich wie folgt ergänzt:

Delphi-Quellcode:

...
  with AddChild('ram:SpecifiedTradeSettlementPaymentMeans') do
      begin
        AddChild('ram:TypeCode').Text := TXRechnungHelper.InvoicePaymentMeansCodeToStr(_Invoice.PaymentMeansCode);

        AddChild('ram:Information').Text := _Invoice.PaymentMeansInformation; // Meine Ergänzung

Schlage auch die Übernahme dieser Erweiterung vor. In der Anlage ein Screenshot vom Ergebnis (für Zahlungsmittel).

Hinweis: In den Load-Prozeduren habe ich nichts ergänzt, da ich die ja wie bereits erwähnt nicht unter FMX nutzen kann, da müsstest Du dann selber mal schauen.

[Rollo62]

Zitat:

Zitat von Harry Stahl (Beitrag 1542626)

Weiterer Vorschlag: Du hast die BT-82 (Information für das Zahlungsmittel) noch nicht abgedeckt.

Ich finde für viele solcher Elemente beim besten Willen keine passenden Textbausteine oder Beispiele

Zitat:

Payment means text BT-82 Text 0..1 58
Das in Textform ausgedrückte erwartete oder genutzte Zahlungsmitte

https://www.google.com/url?sa=t&sour...MOagIK2hYVrraG
Ist so ziemlich das Beste was ich da finden kann.

Was genau würde man denn da reinschreiben, ist das genormt, oder kann ich da "Kreditkarte", "Online-Payment" "PayPal", "Bar", "Überweisung" oder was auch sonst je nach Gusto reinschreiben?
Oder soll da konkreter nur "MasterCard", "Visa", "PayPal", Apple Pay" rein?

Woran sehe ich, ob es vordefinierte Textbausteine gibt, oder nicht?
Gibt es vielleicht irgendwo eine gute Beschreibung aller Felder mit verschiedenen Beispielen?

[Harry Stahl]

@Rollo62: Ich orientiere mich an:

ZUGFeRD-for-Delphi-main\documentation\zugferd23-facturx1007\factur-x1.0.07en\3. FACTUR-X 1.0.07 - 2024 09 18 - EN FR VF.xlsx

In dieser Excel-Datei sind die XML-Pfade beschrieben und die Namen der Value-Knoten.

Für BT-82 findest Du dann:

/rsm:CrossIndustryInvoice
/rsm:SupplyChainTradeTransaction
/ram:ApplicableHeaderTradeSettlement
/ram:SpecifiedTradeSettlementPaymentMeans

/ram:Information

Was man da rein schreiben kann: Wenn die Erläuterung heißt "Information" oder ähnliches, dann kannst Du recht frei schreiben, was halt Sinn macht. Viel kann man lernen, wenn man sich von Sven die unit "Testusecases" anschaut, da gibt es für unterschiedliche Anwendungsfälle schon eine Reihe von Beispielen. Die finde ich sehr hilfreich, denn bis man ansonsten selber rausgefunden hat, was ich bei einer "Innergemeinschaftlichen Lieferung" oder bei der "Kleinunternehmer-Regelung" bei den XML-Werten anders gestalten muss, finde ich es da schon bei den Beispielen. Da ich das in meinem Rechnungsprogramm natürlich alles schon drin hatte, muss ich hier nur ein paar entsprechende Anpassungen vornehmen (schon erledigt).

Übrigens: Lustiger Download-Pfad, den Du da gepostet hast (auf Dein C: Laufwerk):-D

[Rollo62]

Zitat:

Zitat von Harry Stahl (Beitrag 1542628)

@Rollo62:
Was man da rein schreiben kann: Wenn die Erläuterung heißt "Information" oder ähnliches, dann kannst Du recht frei schreiben, was halt Sinn macht.

Gut, ich kann schreiben was mir Spass macht, die Frage ist was die da akzeptieren würden.
Ist aber vielleicht so wie bis bisherigen Rechnungen auch, die Eine so, die Andere so.
Ich hätte nur gedacht, dass es da bei so generellen Feldern ein paar mehr Vorgaben über die Form der Inhalte gibt.

Zitat:

Zitat von Harry Stahl (Beitrag 1542628)

Übrigens: Lustiger Download-Pfad, den Du da gepostet hast (auf Dein C: Laufwerk):-D

Genau, komm vorbei und schau nach :-D
Ich hab den Link korrigiert.

[jziersch]

Zitat:

Zitat von Rollo62 (Beitrag 1542627)

Zitat:

Zitat von Harry Stahl (Beitrag 1542626)

Weiterer Vorschlag: Du hast die BT-82 (Information für das Zahlungsmittel) noch nicht abgedeckt.

Ich finde für viele solcher Elemente beim besten Willen keine passenden Textbausteine oder Beispiele

Diese XML sollte helfen
https://www.xrepository.de/api/xrepo...teilGenericode

Der Link ist in der PDF
XRechnung-v3.0.2.pdf aus dem ZIP xrechnung-3.0.2-bundle-2024-06-20

alle dokumente sind hier: https://xeinkauf.de/dokumente/

Ich weiss allerdings nicht inwieweit dies alles auch auf ZUGFeRD anwendbar ist. Mit ZUGFeRD beschäftige ich mich gerade hauptsächlich. Mein Delphi Klassenmodell ist auch schon fast fertig. Damit geht dann solcher code

Code:

item:=WPXOrder1.Transaction.Items.Add;
with item.Line do
begin
   AssociatedDocumentLineDocument.LineID.SetValue('1',{schemeID=}'');
   SpecifiedTradeProduct.GlobalID.SetValue('4123456000014',{schemeID=}'0160');
   SpecifiedTradeProduct.SellerAssignedID.SetValue('ZS997',{schemeID=}'');
   SpecifiedTradeProduct.Name.SetValue('Zitronensäure 100ml');
   SpecifiedTradeProduct.ApplicableProductCharacteristic.Description.SetValue('Verpackungsart');
   SpecifiedTradeProduct.ApplicableProductCharacteristic.Value.SetValue('BO');
   SpecifiedLineTradeAgreement.GrossPriceProductTradePrice.ChargeAmount.SetValue(1.0000);
   SpecifiedLineTradeAgreement.NetPriceProductTradePrice.ChargeAmount.SetValue(1.0000);
   SpecifiedLineTradeDelivery.BilledQuantity.SetValue('100.0000',{unitCode=}'H87');
   SpecifiedLineTradeDelivery.PackageQuantity.SetValue('4.0000',{unitCode=}'XCT');
   SpecifiedLineTradeSettlement.ApplicableTradeTax.TypeCode.SetValue('VAT');
   SpecifiedLineTradeSettlement.ApplicableTradeTax.CategoryCode.SetValue(TTaxCategory.S_Standard_rate);
   SpecifiedLineTradeSettlement.ApplicableTradeTax.RateApplicablePercent.SetValue('19.00');
   SpecifiedLineTradeSettlement.SpecifiedTradeSettlementLineMonetarySummation.LineTotalAmount.SetValue(100.00);
end;

[BlueStarHH]

Zitat:

Zitat von Harry Stahl (Beitrag 1542626)

Weiterer Vorschlag: Du hast die BT-82 (Information für das Zahlungsmittel) noch nicht abgedeckt. Daher habe ich in der Klasse TInvoice aufgenommen:

PaymentMeansInformation : String;

In procedure "SaveDocumentUNCEFACT" (jeweils in units "intf.XRechnung_2_3 und intf.XRechnung_3_0) habe ich wie folgt ergänzt:

Delphi-Quellcode:

...
  with AddChild('ram:SpecifiedTradeSettlementPaymentMeans') do
      begin
        AddChild('ram:TypeCode').Text := TXRechnungHelper.InvoicePaymentMeansCodeToStr(_Invoice.PaymentMeansCode);

        AddChild('ram:Information').Text := _Invoice.PaymentMeansInformation; // Meine Ergänzung

Schlage auch die Übernahme dieser Erweiterung vor. In der Anlage ein Screenshot vom Ergebnis (für Zahlungsmittel).

Hinweis: In den Load-Prozeduren habe ich nichts ergänzt, da ich die ja wie bereits erwähnt nicht unter FMX nutzen kann, da müsstest Du dann selber mal schauen.

So wie ich das verstehe ist BT-82 "Information für das Zahlungsmittel" eine textuelle Beschreibung vom Code in BT-81 und nicht für alternative Zahlungsarten. Für Zahlungsarten, für die es keine Code gibt wie z.B. PayPal muss BT-81 auf ZZZ und dann BT-82 gefüllt werden:

Code:

2.2.4 Electronic Wallet e.g. PayPal, AfterPay or other vendors.

Many vendors now provide online payment gateways that enable a user to view a web UI and enter card or online payment account information. The following example highlight how this information MAY be conveyed to the end user:

<cac:PaymentMeans>
  <cbc:ID>Online Payment Gateway</cbc:ID>
  <cbc:PaymentMeansCode listID="UN/ECE 4461">ZZZ</cbc:PaymentMeansCode>   //BT-81
<cbc:InstructionNote>https://mypaymentgateway.example.com/resource</cbc:InstructionNote> //BT-82
</cac:PaymentMeans>

Some payment gateways MAY require additional information beyond a URI. In this circumstance, the FinancialAccount ABIE can be used to provide this information. <--!!!! D.h. die PayPal-Empfänger-EMail (=PayPal-Konto) muss hier hinterlegt werden.

Quelle: https://docs.oasis-open.org/ubl/UBL-...l#_Toc26865417

[Harry Stahl]

@BluestarHH

Du sagst: "So wie ich das verstehe ist BT-82 "Information für das Zahlungsmittel" eine textuelle Beschreibung vom Code in BT-81 und nicht für alternative Zahlungsarten. Für Zahlungsarten, für die es keine Code gibt wie z.B. PayPal muss BT-81 auf ZZZ und dann BT-82 gefüllt werden".

Ja, so verstehe ich das auch. Mein Beispiel ist da nicht so perfekt. Ich frage mich nur, wie man darstellt, dass man mehrere Zahlungsarten akzeptiert. Und für PayPal gibt es keinen Code (oder was meinst Du mit "ZZZ").

[BlueStarHH]

Zitat:

Zitat von Harry Stahl (Beitrag 1542635)

Ich frage mich nur, wie man darstellt, dass man mehrere Zahlungsarten akzeptiert.

So weit ich weiß, ist das im Moment nicht möglich.

Zitat:

Zitat von Harry Stahl (Beitrag 1542635)

Und für PayPal gibt es keinen Code (oder was meinst Du mit "ZZZ").

ZZZ bedeutet, es gibt keinen Code. So müsste es aussehen (UBL-Syntax), wenn ich es richtig verstanden habe für PayPal:

Code:

  <cac:PaymentMeans>
    <cbc:PaymentMeansCode listID="UN/ECE 4461">ZZZ</cbc:PaymentMeansCode>
    <cbc:PaymentID>Mein Verwendungszweck</cbc:PaymentID>
    <cbc:InstructionNote>https://www.paypal.de</cbc:InstructionNote>
    <cac:PayeeFinancialAccount>
      <cbc:ID>[e-mail]</cbc:ID>
      <cbc:Name>Name des Zahlungsempfängers</cbc:Name>
    </cac:PayeeFinancialAccount>
  </cac:PaymentMeans>

[Rollo62]

Es gibt ja nicht nur mehrere, verschiedene Zahlungsarten, es kann auch z.B. mehrere IBAN geben.
Anhang 57222

Das sollte technisch möglich sein und mein Verständnis ist, dass man mehrere IBAN parallel angeben kann und darf.
Es scheint mir aber irgendwie so, dass hier Jeder seine eigene Interpretation haben darf. :-D

Irgendwie komme ich wohl noch zu sehr aus der Richtung Pflichten- und Lastenheft, wo alles sehr detailgenau beschrieben sein sollte. :gruebel:

[Rollo62]

Aus dem anderen Thread:
https://www.delphipraxis.net/1542586-post66.html

Danke für den Hinweis an BlueStarHH: DATEV ist wirklich eine sehr, sehr gute Anlaufstelle für solche Fragen, weil die ja ganz nah an diesem Themen sind.
Hatte ich gar nicht mehr dran gedacht. :stupid:

Zum Beispiel
https://apps.datev.de/help-center/documents/9217074

Zitat:

Liste Zahlungsart

> Wählen Sie:
kein Zahlungsverkehr

Scheck

Barzahlung

SEPA-Überweisung

Wenn Sie SEPA-Überweisung wählen, erfassen Sie die Felder IBAN und BIC/Bankbezeichnung.

"Bezahlt-Kennzeichen", "Teilzahlungen", "Lastschriften":
https://apps.datev.de/help-center/documents/9231351

Zitat:

Kennzeichnung übergebener Posten


Standardmäßig erhalten Überweisungen bzw. Lastschriften und Schecks mit der Übergabe an den Zahlungsverkehr ein Bezahlt-Kennzeichen. Dieses wird gesetzt, wenn die Kontrollkästchen hier aktiviert sind.

Das Kennzeichen wird bei dem jeweiligen offenen Posten im OPOS-Konto eingetragen. Gekennzeichnete offene Posten werden bei der Neuerstellung eines Zahlungsvorschlags nicht mehr berücksichtigt.

Folgende Kennzeichen werden gesetzt:

U*: Überweisung

L*: Lastschrift

S*: Scheck

Wenn eine Teilzahlung (d. h. Verminderung des vorgeschlagenen Zahlbetrags) vorliegt, wird das Kennzeichen (Stern *) nicht gesetzt und der offene Posten mit dem Hinweis auf eine bereits erfolgte Teilzahlung in den nächsten Zahlungsvorschlag aufgenommen.

Die Kennzeichnung ist vor allem hilfreich, wenn Sie Ausgleichsbuchungen nicht automatisch generieren lassen, sondern manuell buchen.

Eine Aktivierung ist nur notwendig, wenn die entsprechenden Kontrollkästchen zwischenzeitig deaktiviert wurden.

PayPal:
https://download.datev.de/download/ratgeberpaypal.ppsx


Je tiefer man da gräbt, umso schlimmer wird es mit den verschiedenen Möglichkeiten in der realen Welt :-D
Das hilft aber sehr um die richtigen Begriffe zu finden und die exakte Verwendung zu klären, wenn man kein Steuerberater ist.

[Harry Stahl]

@SH17 Frage / Anregung:

Ich habe mir mal die proceduren

class procedure TXRechnungInvoiceAdapter230.SaveDocumentUBL und
class procedure TXRechnungInvoiceAdapter301.SaveDocumentUBL

in einem Differenz-Viewer angesehen.

Danach gibt es nur 2 kleine Unterschiede:

1x beim der CustomizationID
1x bei TaxcurrencyCode (in Version 301), in der Hinsicht, dass der Wert dort nicht gesetzt werden soll.

Ist es bei der Sachlage nicht besser, nur eine Procedure zu machen und mit einem weiteren Parameter zwischen 2.31 / 3.01 zu unterscheiden und dann an den beiden Stellen mit einer Versionsabfage unterschiedlich zu reagieren?

[sh17]

Vielen Dank für die Infos. Die Trennung der beiden Versionen in jeweils eine Unit war eine bewusste Entscheidung von mir. Mag sein, dass die Unterschiede in diesem Fall marginal ausfallen mögen, das kann sich in zukünftigen Versionen aber ändern. Der Grund ist die einfache langzeitliche Unterstützung für zukünftig alte Versionen. Ich bevorzuge Diskussionen zum Sourcecode auf Github, das vereinfacht das Handling der verschiedenen Anliegen.

[Harry Stahl]

Zitat:

Zitat von sh17 (Beitrag 1542671)

Vielen Dank für die Infos. Die Trennung der beiden Versionen in jeweils eine Unit war eine bewusste Entscheidung von mir. Mag sein, dass die Unterschiede in diesem Fall marginal ausfallen mögen, das kann sich in zukünftigen Versionen aber ändern. Der Grund ist die einfache langzeitliche Unterstützung für zukünftig alte Versionen. Ich bevorzuge Diskussionen zum Sourcecode auf Github, das vereinfacht das Handling der verschiedenen Anliegen.

OK, alles klar. Weitere Kommentare zum Source-Code dann auf Github. Hier dann nur noch generelle Fragen / Aspekte, die allgemein zum Theme elektronische Rechnung interessant sein könnten.

[Harry Stahl]

Ich würde in der X-Rechnung gerne sowohl eine Bestellnummer als auch eine Auftragsnummer angeben.

Der Code in der unit läßt aber nur eine Angabe zu:

Delphi-Quellcode:

  if _Invoice.PurchaseOrderReference <> '' then
    xRoot.AddChild('cac:OrderReference').AddChild('cbc:ID').Text := _Invoice.PurchaseOrderReference
  else
  if _Invoice.SellerOrderReference <> '' then
    xRoot.AddChild('cac:OrderReference').AddChild('cbc:ID').Text := _Invoice.SellerOrderReference;

Wie erreiche ich es, beide Werte zu befüllen?

[Frickler]

Zitat:

Zitat von Harry Stahl (Beitrag 1542763)

Ich würde in der X-Rechnung gerne sowohl eine Bestellnummer als auch eine Auftragsnummer angeben.

Die Doku sagt dazu: https://docs.peppol.eu/poacc/billing...rderReference/

Interessanterweise findet sich auf der Webseite der Deutschen Bahn eine durchdokumentierte Beispielrechnung: https://www.deutschebahn.com/resourc...-UBL--data.pdf

[BlueStarHH]

Zitat:

Zitat von Frickler (Beitrag 1542769)

Zitat:

Zitat von Harry Stahl (Beitrag 1542763)

Ich würde in der X-Rechnung gerne sowohl eine Bestellnummer als auch eine Auftragsnummer angeben.

Die Doku sagt dazu: https://docs.peppol.eu/poacc/billing...rderReference/

Interessanterweise findet sich auf der Webseite der Deutschen Bahn eine durchdokumentierte Beispielrechnung: https://www.deutschebahn.com/resourc...-UBL--data.pdf

Die Bahn hat beide Angaben in Ihrem Beispiel:

Code:

<cac:OrderReference>
<cbc:ID>Bestellnummer (BT-13)</cbc:ID>
<cbc:SalesOrderID>Auftragsnummer (BT-14)</cbc:SalesOrderID>
</cac:OrderReference>

[sh17]

ich schaue es mir an

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

[Harry Stahl]

Ja, Prima, Danke.

Was ich auch noch nicht so ganz verstanden habe: Habe gelesen, es gäbe die Standards "Basic", "Comfort" und "Extended" im ZUGFeRD-Format.

Kann man das irgendwie auch in Deiner Library abbilden?
Bzw. was ist letztlich der Unterschied an Informationen, die man zur Verfügung stellen muss / kann?

[Harry Stahl]

Noch mal die Frage, ob jemand meine letzte Frage beantworten kann. Ich habe mal in den Verzeichnissen von "ZUGFerD-for-Delphi-main" gesucht, dort tauchen die Unterscheidungsmerkmale "basicwl" oder "extended" auf, nicht aber in "X-Rechnung-for-Delphi-Master".

Bislang hatte ich das so verstanden, dass ich "ZugFedR-for-Delphi-Master" gar nicht brauche, da ja das ZugFerD-format auch im Branch "X-Rechnung-for-Delphi-Master" erstellbar ist.

Wozu ist also der ZugFerD-Branch gut? Muss ich das etwa doch einbauen, bzw. noch eine Bedingung setzen, dass es eingebunden wird?

[sh17]

Neben Base, Comfort, Extended und anderen gibt es eben auch XRechnung. Nur dieses wird in der XRechnung-Lib erstellt.
ZUGFeRD-Extended wird nur von der ZUGFeRD Lib unterstützt. Dafür müsste man aber selbst die Objektbaum zusammensetzen. Es gibt
momentan keine Unterstützung durch TInvoice. Langfristig wird nur noch Extended und XRechnung relevant sein. Basic ist nächstes Jahr gar nicht
mehr erlaubt.

Warum benötigst Du überhaupt die Unterscheidungen?

[BlueStarHH]

Zitat:

Zitat von sh17 (Beitrag 1543261)

Langfristig wird nur noch Extended und XRechnung relevant sein. [...] Warum benötigst Du überhaupt die Unterscheidungen?

Auch wenn die Frage nicht an mich ging, antworte ich mal:

Vor einigen Tagen hörte ich in einem Webinar, von einem Vorstandsmitglieds des Verbandes elektronische Rechnung (VeR), folgende Aussagen:

Wenn man eine vollständig (rechtskonforme) Schlussrechnung erstellen wolle, sei das nur mit ZUGFeRD Extended möglich. In XRechnung würden einige Angaben nicht möglich sein.

Ich meine es müssten ALLE Abschlagsrechnungen inkl. der Beträge (Netto UND USt.) aufgelistet werden.

[Harry Stahl]

Zitat:

Zitat von sh17 (Beitrag 1543261)

Neben Base, Comfort, Extended und anderen gibt es eben auch XRechnung. Nur dieses wird in der XRechnung-Lib erstellt.
ZUGFeRD-Extended wird nur von der ZUGFeRD Lib unterstützt. Dafür müsste man aber selbst die Objektbaum zusammensetzen. Es gibt
momentan keine Unterstützung durch TInvoice. Langfristig wird nur noch Extended und XRechnung relevant sein. Basic ist nächstes Jahr gar nicht
mehr erlaubt.

Warum benötigst Du überhaupt die Unterscheidungen?

Na, ich hatte halt von den unterschiedlichen "Profilen" gelesen und dachte mir, ich mach es so, wie im anliegenden Screenshot gezeigt, halt ZUGFeRD für B2B, mit den wählbaren profilen "Basic", "Comfort" und "Extended" und B2G mit dem X-Rechnungsformat. Nur hatte ich halt keine Definition für die Profile in den X-Rechnungsunits gefunden (die aber doch sehr wohl auch die XML-im ZugFerD-Format erstellen können, die dann in der PDF eingebettet werden).

Mit anderen Worten heißt es also, das ZUGFerd-Extended-Format wird nicht mit den X-Rechnungs-Units abgedeckt, sondern "quasi" nur die Standards "Basic" und "Comfort". Was mir derzeit wohl erst mal reichen würde. Dann würde ich aber die Unterscheidung weg lassen und nur noch die Auswahl "X-Rechnung" oder "ZUGFeRD" anbieten.