ImplementierungNewsWissen

Aber es sind doch Pflichtfelder!

Diese Information ist doch in der Dokumentation als Pflichtfelder definiert. Sie muss in der Rechnung vorkommen! Oder doch nicht? Diese Frage erreicht mich in letzter Zeit wieder häufiger. Oftmals bestehen die meisten Rechnungsdokumentationen nicht nur aus einer Liste von Informationen, sondern aus Datenstrukturen.

Hierarchische Datenstrukturen

In hierarchischen Datenstrukturen werden Informationen in der Regel zunächst zu logischen Einheiten zusammengefasst. So kann eine Anschrift zum Beispiel aus Straße, Postleitzahl, Ort und Land bestehen. Alle diese Elemente werden dann zu einer Einheit „Anschrift“ zusammengefasst. Anschriften stehen jedoch auf Rechnungen nicht für sich alleine, sondern gehören in der Regel zu einem Geschäftspartner, der an dieser Anschrift anzutreffen ist. Ein Geschäftspartner wird in der Regel durch seinen Namen und seine Anschrift beschrieben. Weitere mögliche Informationen sind zum Beispiel dessen Umsatzsteueridentnummer. Die Kombination aus diesen drei Informationen bildet dann den Geschäftspartner. Eine Rechnung enthält in der Regel wenigstens zwei Geschäftspartner, den Käufer und den Verkäufer. Genau auf diese Art entsteht nun also eine baumartige Struktur von Informationen: Eine hierarchische Datenstruktur.

Hierarchische Struktur

Kardinalitäten

In technischen Dokumentationen und Datenmodellen werden häufig die Wiederholhäufigkeiten der einzelnen Informationen definiert, die so genannte Kardinalität. Sie wird häufig in dem Format x..y angegeben. Dabei steht x für die minimale Häufigkeit und y für die maximale Häufigkeit. Diese Angaben beziehen sich auf die technischen Dokumentationen. Zum Beispiel ein Datenmodell oder eine XML basierte Syntax. Klar definierte Geschäftsregeln liefern in der Regel die Grundlage bei der Definition der Kardinalitäten. Es existiert jedoch nicht zu jeder Kardinaltät zwangsweise auch eine Geschäftsregel. Typische Werte für Kardinalitäten sind

  • 0..1 Die Information ist optional. Sie darf weggelassen werden. Wird sie angegeben, darf sie maximal 1 mal angegeben werden. Ein Beispiel für diese Kardinalität ist die Angabe der Nummer der zugehörigen Bestellung. Existiert diese nicht, braucht das Informationsfeld auch nicht zu übermittelt werden.
  • 1..1 Die Information ist verpflichtend anzugeben. Sie darf nicht weggelassen werden. Wird sie angegeben, darf sie maximal 1 mal angegeben werden. Ein Beispiel hierfür ist die Rechnungsnummer.
  • 0..n oder 0..unbounded Die Information ist optional. Sie darf weggelassen werden. Wird sie angegeben, darf sie beliebig häufig angegeben werden. Freitext zu einer Rechnung wird in der Regel auf diese Art eingebunden. Es besteht kein Zwang zur Angabe von Freitext. Es darf jedoch beliebig viel Text übermittelt werden.
  • 1..n oder 1..unbounded Die Information ist verpflichtend anzugeben. Sie darf nicht weggelassen werden. Wird sie angegeben, darf sie beliebig häufig angegeben werden. Der Positionsteil einer Rechnung hat in der Regel diese Kardinalität. Eine Rechnung benötigt die Angabe wenigstens einer zu berechnenden Leistung oder Ware.

Statusangaben

Anders als die technischen Kardinalitäten werden in Dokumentationen häufig noch ergänzende Statusangaben ergänzt. Dies wird insbesondere in Anwendungsempfehlungen genutzt. Diese definiert die Anwendung eines technischen Standards für eine bestimmte Empfängergruppe. Für die optimale Verarbeitung elektronischer Rechnungen können bestimmte Angaben erforderlich sein, die im technischen Standard nur optional angebbar sind. In der Praxis werden häufig solche Informationen als erforderliche Angabe definiert, die die eindeutige Zuordnung einer Rechnung im Empfängersystem ermöglicht. Dies könnte zum Beispiel die Bestellnummer, eine Transaktionsnummer oder ein Kassenzeichen sein. Typische Angaben für einen Status in einer Dokumentation sind

  • R Required. Im technischen Standard liegt eine optionale Kardinalität vor. (z.B. 0..1) Die Information ist für die Verarbeitung im Empfängersystem erforderlich. Technisch entspricht dies also einer Kardinalität von 1..y.
  • A Adviced. Im technischen Standard liegt eine optionale Kardinalität vor. (z.B. 0..1) Die Information wird von einigen Empfängern der Gruppe benötigt. Für eine einfachere Umsetzung sollte dieser Wert wann immer möglich mitgeliefert werden.
  • D Dependent. Im technischen Standard liegt eine optionale Kardinalität vor. (z.B. 0..1) Ob die Information im empfangenden System benötigt wird, hängt von einer Bedingung ab. Diese Bedingung sollte in der Anwendungsempfehlung klar definiert werden. Ein Beispiel ist die Möglichkeit, statt einer Umsatzsteueridentnummer eine nationale Steuernummer anzugeben. Die Angabe hängt von Art und Ort der Lieferung und Leistung ab.
  • O Optional. Im technischen Standard liegt eine optionale Kardinalität vor. (z.B. 0..1) Die Anwendungsempfehlung macht keine Aussage zu dieser Information. Die Kardinalität bleibt erhalten.
  • N Not used. Im technischen Standard liegt eine optionale Kardinalität vor. (z.B. 0..1) Die Anwendungsempfehlung verbietet die Übermittlung dieser Information. Technisch entspräche dies der Kardinalität 0..0. Bei diesem Status ist zu beachten, dass dies die Interoperabilität eines Standards einschränkt. Siehe hierzu auch hier.

Pflichtfelder in hierarchischen Strukturen

Uff. Das war eine ganze Menge Information. Beschäftigen wir uns daher nun endlich mit der Frage, warum bestimmte Informationen weggelassen werden können, obwohl sie als Pflichtfeld 1..1 definiert sind.

In dem Bild zu diesem Beitrag ist ein Baum zu sehen. Dieser Baum hat Äste und an jedem Ast sind Blätter. Der Einfachheit halber gehe ich davon aus, dass Blätter nur direkt an den Ästen wachsen. Der Baum benötigt die Blätter zum Leben. Die Blätter des Baumes sind also zu dessen fortwährender Existenz erforderlich. Ich definierte also eine Regel, dass jeder Ast wenigstens ein Blatt tragen muss. Jedoch kann ich auch alle Äste abschneiden. Dann greift die Regel nicht mehr.

Ein Beispiel bei der Rechnung dafür ist die Angabe einer abweichenden Lieferanschrift. Nicht jede Rechnung hat eine abweichende Lieferanschrift. Jedoch benötigt jede Anschrift ein Mindestmaß an Informationen (z.B. Land, Ort und ggf. Postleitzahl), damit die Ware auch tatsächlich ankommt. Ähnlich sieht in der EN16931 die Angabe von Zahlungsbedingungen aus. In der Gruppe BG-16 (PAYMENTINSTRUCTIONS) ist die Angabe der Art der Zahlung (Kreditkarte, Überweisung, etc…) verpflichtend. Die gesamt Gruppe kann jedoch weggelassen werden:

  • BG-16 0..1 PAYMENTINSTRUCTIONS
    • BT-81 1..1 Payment means type code

Solche Situationen kommen häufig in hierarchischen Datenstrukturen vor. Im letzten Beispiel (Art der Zahlung) existieren in der Praxis noch weitere Verbindungen. So kann die Wahl einer bestimmten Zahlungsbedingung die Bereitstellung weiterer Informationen nach sich ziehen. So macht die Angabe der Zahlungsmethode SEPA-Lastschrift nur dann Sinn, wenn auch die erforderlichen Daten wie Mandatsreferenz und Gläubiger-ID übermittelt werden. Genau hier greifen dann zusätzliche Geschäftregeln, auf die jedoch an anderer Stelle eingegangen werden kann.

Ich freue mich auf weitere Fragen, Anregungen oder Artikel für diese Seite!

Andreas Pelekies

Andreas Pelekies ist Senior Business Development Manager bei GEFEG mbH. GEFEG Lösungen bieten Produktivitätssteigerungen und optimierte Entwicklung von Datenschnittstellen, um Geschäftsprozesse zu verbinden und deren Fachinhalte zu planen, abzubilden und während des gesamten Anwendungszyklus zu managen. Zu den Lösungen gehören die Software GEFEG.FX für Entwicklung und Management von Datenmodellen, eStandards und Schnittstellen. Andreas Pelekies ist aktives Mitglied in nationalen und internationalen Gremien, wie z.B. DIN, CEN, UN/CEFACT. Unter seiner technischen Leitung wurde im Forum elektronische Rechnung Deutschland (FeRD) das ZUGFeRD Formats entwickelt. Nach 18 Jahren Softwareentwicklung für kaufmännische Software war er als Manager für globale XML Standards bei GS1 Germany tätig und betreute die Themen Bargeldlogistik und Elektronische Rechnung auf nationaler und internationaler Ebene. Er ist Master of Business Administration und studierte Wirtschaftsinformatik an der Hochschule für Ökonomie und Management.

2 Gedanken zu „Aber es sind doch Pflichtfelder!

  • Roland

    Auf Deiner Seite ist ein Fehler. Die Gruppe BG-16 Paymentinstructions kann nicht weggelassen werden. Sie muss genau einmal vorkommen.

    Eine Frage aufgrund der wir auf diesen Artikel gestoßen sind ist, an welcher Stelle im UBL-Standard die Gläubiger-ID einzufügen ist (/Invoice:Invoice/cac:PayeeParty/cac:PartyIdentification/cbc:ID oder /Invoice:Invoice/cac:AccountingSupplierParty/cac:Party/cac:PartyIdentification/cbc:ID).

    Antwort
    • Hallo Roland,
      vielen Dank für Deinen Kommentar.
      Die Angabe auf der Seite ist jedoch korrekt. Das Beispiel bezieht sich auf das semantische Datenmodell im Original. In diesem ist die Gruppe optional. Übrigens ebenso bei UBL. cac:PaymentMeans hat eine Wiederholbarkeit von 0..1.

      Ich vermute, dass Du hier die Anforderungen aus der EN16931 mit den nationalen Anforderungen aus der CIUS der deutschen Verwaltung (XRechnung) verwechselst. In der XRechnung existiert als erste (von mittlerweile 21) zusätzliche nationale Regel, dass BG-16 verpflichtend zu übermitteln ist (BR-DE-1).

      Zu Deiner Frage bezüglich der Gläubiger-ID: Diese wird semantisch im Feld Bank assigned creditor identifier (BT-90) abgebildet.
      Wenn Du UBL als Syntax nutzt, hängt es davon ab, ob es einem vom Verkäufer abweichenden Zahlungsempfänger gibt. Sind Käufer und Zahlungsempfänger identisch, wird die Gruppe Payee gar nicht übermittelt. Dies entspricht dann dem Pfad /Invoice/cac:AccountingSupplierParty/cac:Party/cac:PartyIdentification/cbc:ID.
      Gibt es jedoch einen vom Käufer abweichenden Zahlungsempfänger, ist die Gläubiger-ID im Pfad /Invoice/cac:PayeeParty/cac:PartyIdentification/cbc:ID zu übermitteln.
      Bitte bedenke, dass Du dasselbe auch noch ein zweites Mal für eine Rechnungskorrektur / Gutschrift umsetzen musst, da hier ja /CreditNote statt /Invoice verwendet wird.
      Hinweis: Bei beiden Fällen muss @schemeID zusätzlich den festen Wert SEPA haben.

      Solltest Du die CII verwenden, ist eine solche Unterscheidung nicht notwendig. Hier lautet der Pfad für die Gläubiger-ID /rsm:CrossIndustryInvoice/ram:SupplyChainTradeTransaction/ram:ApplicableHeaderTradeSettlement/ram:CreditorReferenceID.

      Hat Dir das erst einmal weiter geholfen?

      Antwort

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert