Wie ZUGFeRD Demo von SH17 verwenden?

[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)

[Rollo62]

Zitat von Harry Stahl:

@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 von Harry Stahl:

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

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

[jziersch]

Zitat von Rollo62:

Zitat von Harry Stahl:

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 von 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.

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 von Harry Stahl:

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

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

Zitat von Harry Stahl:

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.


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.

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

[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.

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
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.