BT-17 & BT-18: AdditionalReferencedDocumentTypeCode

[lukas-vts]

Hi,

um die Felder BT-17 (Vergabenummer) und BT-18 zu setzen, habe ich jetzt folgenden Code verwendet:

desc.AdditionalReferencedDocuments.Add(new() { ID = "<Vergabenummer>", TypeCode = AdditionalReferencedDocumentTypeCode.PriceSalesCatalogueResponse });
desc.AdditionalReferencedDocuments.Add(new() { ID = "<Objektkennung>", TypeCode = AdditionalReferencedDocumentTypeCode.InvoiceDataSheet });

Dabei erschließt sich mir die Benennung der Wert in AdditionalReferencedDocumentTypeCode nicht so ganz. Wie kommen die zustande?

PriceSalesCatalogueResponse = 50 / Vergabenummer
InvoiceDataSheet = 130 / Objektkennung

[tobitege]

Die Dokumentation(en) sind da wirklich wenig intuitiv und geben kaum Hintergrundinformationen.
In z.B. XRechnung (Visualisierungs-)Dateien sind die auch explizit so genannt:

  <entry key="xr:Tender_or_lot_reference" id="BT-17">Vergabenummer</entry> 
  <entry key="xr:Invoiced_object_identifier" id="BT-18">Objektkennung</entry>

In Beispieldateien:

<ram:AdditionalReferencedDocument>
  <ram:IssuerAssignedID>ANG987654321</ram:IssuerAssignedID> 
  <ram:TypeCode>50</ram:TypeCode> 
</ram:AdditionalReferencedDocument>
<ram:AdditionalReferencedDocument>
  <ram:IssuerAssignedID>OK987654321</ram:IssuerAssignedID> 
  <ram:TypeCode>130</ram:TypeCode> 
</ram:AdditionalReferencedDocument>

[mightyScoop]

Hallo zusammen,

ist die oben genannte Methode (AddAdditionalReferencedDocuments) zum Hinzufügen der BT-17 Vergabenummer noch immer aktuell?
Wie bekomme ich den die tatsächliche Vergabenummer (in dem Beispiel ANG987654321) in die E-Rechnung?

Grüße

[stephanstapel]

Am Ende hängt es gerade bei solch speziellen Konstrukten nicht so sehr vom Standard ab, sondern mehr davon, was der Empfänger erwartet. Meines Erachtens kann man so gut starten. Ein Datum gibt es für das Dokument nicht?

[IsThatUniqueEnough]

Darf ich anmerken, dass bei BT-17 und BT-18 kein "Name" (und < EXTENDED auch kein Datum) vorgesehen ist? Ohne den Namen wird das "Dokument" dann auch nicht in den Anlagen der Visualisierung aufgeführt.
@mightyScoop Lass mal "name" weg/leer, wenn ZUGFeRD-csharp das zulässt.

[mightyScoop]

Oh sehr interessant. Danke für die Anmerkung. Das macht die ganze Sache aber noch ein bisschen komplizierter. Wie soll man dann die Vergabenummer bei einer Änderung wieder finden?

Ich lege die Vergabenummer folgendermaßen an:

_invoiceDescriptor.AddAdditionalReferencedDocument(
id: value,
typeCode: AdditionalReferencedDocumentTypeCode.PriceSalesCatalogueResponse,
name: "Vergabenummer"
);

Falls der Benutzer die Vergabenummer noch ändern will passiert folgendes:

var vergabenummer = addDocuments.Where(x => x.Name == "Vergabenummer").SingleOrDefault();
if (vergabenummer != null)
{
vergabenummer.ID = value;
}
else
{
....

Wie finde ich die Vergabenummer, falls der Name leer ist?
Oder wird DocumentType 50 (PricesSalesCatalogueResponse) nur für die Vergabenummer verwendet?

Danke für Dein Input. Das ist sehr hilfreich!

Grüße

[IsThatUniqueEnough]

Also ich persönlich würde die Datenstrukturen so einer Library nur als Transportmittel zum Lesen/Schreiben von E-Rechnungen verwenden und die Daten ansonsten in eigenen Datenstrukturen halten.

Grundsätzlich: Die Werte der TypeCodes der Dokumente sind komisch. Die meisten scheinen aus UNTDID 1001 zu kommen (wie es aber z.B. zu 130 für BT-18 und BT-128 kommt, ist mir schleierhaft).

XRechnung lässt den Wert 50 an der Stelle nur einmal zu, ZUGFeRD prüft das nicht. Es könnte dort also jemand auf die Idee kommen, die 50 mehrmals zu liefern. Da Du aber ja nach einer selbst eingestellten Vergabenummer suchst, sollte das kein Problem sein, so lange Du nur eine Vergabenummer reinpackst :-)

[mightyScoop]

[...]

XRechnung lässt den Wert 50 an der Stelle nur einmal zu, ZUGFeRD prüft das nicht. Es könnte dort also jemand auf die Idee kommen, die 50 mehrmals zu liefern. Da Du aber ja nach einer selbst eingestellten Vergabenummer suchst, sollte das kein Problem sein, so lange Du nur eine Vergabenummer reinpackst :-)

Ach ja, schau mal ... das wusste ich nicht. Wenn die 50 eigentlich nur einmal enthalten sein darf, ist es bei der Erstellung natürlich einfach zu implementieren.
Danke ... Du hast mir sehr geholfen.

Grüße

[IsThatUniqueEnough]

Dabei erschließt sich mir die Benennung der Wert in AdditionalReferencedDocumentTypeCode nicht so ganz. Wie kommen die zustande?

PriceSalesCatalogueResponse = 50 / Vergabenummer InvoiceDataSheet = 130 / Objektkennung

Der Begriff "Price/sales catalogue response" wird so in der ZUGFeRD-Dokumentation zu BT-17 verwendet. In UNTDID 1001 ist das die Bezeichnung für den Code 51, während der Code 50 dort "Validated Priced Tender" heißt. Vielleicht sind Ähnlichkeiten mit UNTDID 1001 aber auch nur rein zufällig und es steht eine ganz andere Codeliste dahinter?

[IsThatUniqueEnough]

So richtig einig scheint sich die ZUFeRD-Doku aber auch nicht zu sein...