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.

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!