float:center

XBestellung: Profilierung BIS Order only

Lutz Rabe <lutz.rabe@finanzen.bremen.de>, Entwurfsfassung V0.1, 2020-10-27: Analge von Struktur und ersten Inhalten

Hinweise an die Editoren zur Nutzung von Admonition
NOTE - so sollen Hinweis an den intendierten Leser gegeben werden. Die Hinweise der Peppol-BIS wurden in entsprechender Weise übernommen.
TIP - bitte nicht verwenden
IMPORTANT - so sollen deutliche Hinweis an den intendierten Leser gegeben werden. Die Hinweise der Peppol-BIS wurden in entsprechender Weise übernommen.
WARNING - bitte nicht verwenden
CAUTION - so sollen Hinweise an die Editoren der Spezifikation XBestellung gegeben werden
Statement of copyright
Hier muss ein eigenes Statement ergänzt werden This PEPPOL Business Interoperability Specification (BIS) document is based on the CEN CWA prepared by the BII workshop specified in the introduction below. The original CEN CWA document contains the following copyright notice which still applies:

© 2012 CEN All rights of exploitation in any form and by any means reserved worldwide for CEN national Members.

The CEN CWA documents and profiles prepared by the BII workshop are not specific to a business area. Subject to agreement with CEN, customizations have been made by PEPPOL to establish the PEPPOL BIS, detailing and adding further guidance on the use of BII profiles.

OpenPEPPOL AISBL holds the copyright in the customizations made to the original document. The customizations appear from the corresponding conformance statement which is attached to this document. For the purpose of national implementations, customizations covered by the conformance statement may be further refined and detailed by PEPPOL Authorities and/or other entities authorized by OpenPEPPOL AISBL, provided that interoperability with PEPPOL BIS is ensured. This PEPPOL BIS document may not be modified, re-distributed, sold or repackaged in any other way without the prior consent of CEN and/or OpenPEPPOL AISBL.

1. Einleitung

Die vorliegende Spezifikation XBestellung profiliert die Peppol Spezifikation (Business Interoperability Specification, kurz BIS) "Order only 3.1" auf die Anforderungen der öffentlichen Verwaltung von Bund, Ländern und Kommunen.[1]

Die Peppol BIS wurde von der OpenPeppol AISBL Post Award Coordinating Community entwickelt und wird als Teil der PEPPOL Spezifikationen veröffentlicht. Mit ihr werden die Anforderungen hinsichtlich einer gesamteuropäisch interoperablen elektronischen Beschaffung erläutert und Richtlinien zur Umsetzung der Anforderungen beschrieben. Die Peppol BIS basiert wiederum auf dem CEN WS/BII Profile “BII Profile 03 Order Only”.

Zweck der vorliegenden Spezifikation XBestellung ist die Beschreibung eines europaweit einheitlichen Formats einer Bestellnachricht aus der Perspektive der deutschen Verwaltung. Die Spezifikation soll die Nutzung der zugrundeliegenden Standards aus der Sicht der deutschen Verwaltung vereinfachen, die effiziente Umsetzung des Standards und seiner Bestandteile unterstützen und den Betrieb des Standards mit dem bestehender Lösungen harmonisieren.

Hinweise zu fehlenden Inhalten
hier soll der Bezug zu XRechnung bzw. der Umsetzung der EN16931 in DE dargestellt werden.

1.1. Zielgruppe und Zweck

Zielgruppe dieses Spezifikationsdokuments sind Organisationen, die im Kontext des Kooperationsprojekts eBeschaffung Peppol-Spezifikationen anwenden möchten, um elektronische Bestelldokumente auszutauschen, und / oder deren Dienstleister.

Dies umfasst u. a. die folgenden Typen von Organisationen:

  • Service-Anbieter

  • Öffentliche Auftraggeber

  • Lieferanten

  • Software-Entwickler

Insbesondere die folgenden Rollen werden in diesem Dokument adressiert:

  • Software-Architekten

  • Software-Entwickler

  • Wirtschaftsexperten

2. Profilierung und Konformität

Hinweis zur Fortschreibung
Unter diesem Abschnitt wird das Profilierungskonzept und seiner Auswirkung auf die Konformität von Bestelldokumenten zum Standard XBestellung und Peppol BIS Order only beschrieben. Das Profilierungskonzept basiert wesentlich auf den in der Norm EN16931 beschriebenen Mechanismen zur Bildung von sogenannten Core Invoice Usage Specifications (kurz CIUS). Ob und in welchem Umfang sich die einzelnen Mechanismen zur Profilierung von Peppol-Spezifikationen eigenen, muss im Rahmen der Pilotierung evaluiert werden.

Die Spezifikation XBestellung ist eine Profilierung der Peppol Standard BIS Order only 3.1 und des zugrundeliegenden Transaktionsdatenmodells Peppol Order transaction 3.1 (T01).

Die Profilierung der Peppol-Spezifikationen kann als Konkretisierung des zugrundeliegenden Peppol-Standards verstanden werden und soll deren Anwendung für Auftraggeber bei Bund, Ländern und Kommunen vereinfachen und gleichzeitig eine Harmonisierung der resultierenden Umsetzungen bewirken.

Die auf der Profilierung XBestellung basierende Bestellinstanz entspricht weiterhin allen Anforderungen des zugrundeliegenden Peppol-Informationsmodell und zugehörigen Regelungen. Infolgedessen kann ein Empfänger die Bestellung ohne Änderung seiner Verarbeitung verarbeiten. Der Empfänger kann jedoch die in XBestellung definierten Konkretisierungen nutzen, um seine Bestellverarbeitung weiter zu optimieren.

2.1. Konformität

Ein (Bestell-)Dokument ist konform zum einem Standard, wenn es sämtliche Regeln des Standards einhält. [2].

Mit der Spezifikation XBestellung wird der zugrundeliegende Standard BIS Order only 3.1 konkretisiert und / oder eingeschränkt. Jedes zum Standard XBestellung konformes Bestelldokument ist konform zu den genutzten Peppol-Spezifikationen.

Das in diesem Dokument beschriebene Konzept der Konformität bezieht sich ausdrücklich nicht auf die Umsetzung der Standards XBestellung und BIS Order only in empfangenden oder sendenden IT-Systemen.

2.2. Methode der Profilierung

Der Ansatz der Profilierung erlaubt die in der folgenden Tabelle dargestellten Änderungen an den zugrundeliegenden Peppol-Spezifikationen.

Table 1. Geschäftsregeln XBestellung
Typ der Anpassung Beispiel / Anmerkung

Semantik: Konkretisierung der semantischen Bedeutung

Die Konkretisierung ist eine engere semantische Definition eines BTs, sodass die übermittelte Bedeutung immer noch innerhalb der durch die Peppol-Standards definierten Bedeutung liegt.

Semantik: Ergänzung um Synonyme

Da Synonyme die ursprünglichen BTs nur ergänzen, aber nicht ersetzen, ist der ursprüngliche Begriff immer noch normativ. Ein Empfänger, der seine Verarbeitung auf der Grundlage der Peppol-Standards entworfen hat, kann dies weiterhin tun. Beispiele für Synonyme sind die Zuordnung der nationalen oder sektoralen Terminologie zu der in der Peppol-Spezifikation verwendeten Terminologie.

Semantik: Ergänzung um erläuternde Informationen

Hinzufügen eines erläuternden Textes, der beispielsweise erklärt, wie ein Bt in einem bestimmten Anwendungsfall zu verwenden ist. Ein solcher Text verändert nicht die ursprüngliche semantische Definition des Bts. Für erläuternde Informationen sind keine weiteren Maßnahmen des Empfängers erforderlich, und die automatische Verarbeitung der empfangenen Bestellung ist ohne Anpassungen möglich.

Häufigkeit: Nutzung optionaler BTs ausschließen

Einschränkung der Multiplizität von 0..n zu 0..0

Häufigkeit: Nutzung optionaler BTs fordern

Wenn ein optionales BT obligatorisch gemacht wird, wird damit eine Option seiner ursprünglich vorgesehenen Verwendung vorgegeben. Der Empfänger muss seine Verarbeitung nicht ändern.

Häufigkeit: Anzahl möglicher Wiederholungen einschränken

Die Anzahl möglicher Wiederholungen wird beispielsweise von 1..n auf 1..1 verringert. Somit bleibt die Anzahl der Übermittelten elemente innerhalb der vom Empfänger vorgesehenen Grenze und der Empfänger muss seine Verarbeitung nicht ändern.

Datentyp: Anpassung des semantischen Datentyps "String"

Bei der Änderung des semantischen Datentyps eines BTs von "String" zu einem anderen (primitiven) semantischen Datentyp kann der Empfänger den übermittelten Wert immer noch als String interpretieren.

Codeliste: Codes ausschließen

Einschränkung der zur Übermittlung vorgesehenen Codes einer Codeliste

Codeliste: Codes konkretisieren

Die semantische Konkretisierung eines Codelisteneintrags ist als semantische Einschränkung der ursprünglichen Bedeutung zu verstehen.

Geschäftsregel: Ergänzung um weitere Regeln

Mit der Einführung weiterer Geschäftsregeln zur Verwendung von BTs und BGs, können zusätzliche Einschränkung für den zulässigen Inhalt einer Bestellung formuliert werden. XBestellung-Geschäftsregeln stehen nicht im konflikt zu bestehenden (Peppol-)Geschäftsregeln.

Geschäftsregel: Konkretisierung einer bestehenden Geschäftsregel

Die Konkretisierung einer bestehenden BR führt zu einer Einschränkung der zu übermittelnden Inhalte einer Bestellung.

Wertebereiche: Einschränkung

Einschränkung der Menge der in einer konformen Bestellung übertragbaren Werte eines BTs

Wertebereiche: Strukturvorgabe

Vorgaben zur strukturellen Ausgestaltung der in einer konformen Bestellung übertragbaren Werte eines BTs

Wertebereiche: Nachkommastellen

Vorgaben zu TBD

3. Grundsätze und Voraussetzungen

Dieses Kapitel beschreibt die Prinzipien und Annahmen, welche der Nutzung von Peppol Ordering zugrunde liegen. Es stützt sich auf dem CEN BII2 Profile 03, Order Only.

3.1. Anwendungsbereich

Diese Spezifikation beschreibt den Prozess, der das Versenden einer elektronischen Bestellung durch einen Käufer ohne eine Bestellbestätigung durch den Verkäufer umfasst.

3.1.1. Definition grundlegender Begriffe

Für die Betrachtung von Bestellprozessen ist eine klare Unterscheidung von Waren und Dienstleistungen relevant. Daher werden im folgenden diese beide Begriffe zur weiteren Verwendung in diesem Dokument definiert.

Waren

Eine Ware ist eine "bewegliche Sache, die Gegenstand des Handelsverkehrs ist". (Gabler Wirtschaftlexikon).

Dienstleistungen

"In Abgrenzung zur Warenproduktion (materielle Güter) spricht man bei den Dienstleistungen von immateriellen Gütern. Als ein typisches Merkmal von Dienstleistungen wird die Gleichzeitigkeit von Produktion und Verbrauch angesehen (z.B. Taxifahrt, Haarpflege in einem Frisiersalon, Theateraufführung)" (Gabler Wirtschaftslexikon)

3.1.2. Hauptaktivitäten

Die Hauptaktivitäten, die in diesem Profil unterstützt werden sind:

Strukturierte Bestellung

Die Bestellvorgang sollte das strukturierte Bestellen von Waren und Dienstleistungen, unter Verwendung von Freitext oder eindeutigen Bezeichnungen bzw. Kennungen, unterstützen. Die Informationsquelle für die bestellten Produkte kann ein (papierbasierter oder elektronischer) Katalog sein.

Rechnungsverarbeitung

Der Bestellprozess muss die Kontigentierung unterstützen, sodass der Mengenwert der bestellten Produkte angegeben werden kann. Der Käufer kann Informationen bereitstellen, die der Verkäufer in der Rechnung angeben muss, um die Rechnungsverarbeitung und deren Automatisierung zu unterstützen.

Rechnungsverifizierung

Der Käufer kann Informationen bereitstellen, die der Verkäufer in der Rechnung angeben muss, um die Rechnungsfreigabe und deren Automatisierung zu unterstützen.

Steuerberichtswesen

Die Unterstützung des Steuerberichtswesens ist keine generelle Anforderung an Bestellungen. In diesem Kontext wird TAX als Verallgemeinerung von Steuern, wie Umsatzsteuer (VAT), "Goods and Services Tax" (GST) oder "Sales Tax" verwendet. In einer Bestellung soll das Steuerberichtswesen insoweit unterstützt werden, dass:

  • die Berichterstattung in Rechnungen durch Bereitstellen der Steuernummer des Käufers ermöglicht wird und

  • Steuern als Schätzung angegeben werden können, um dem Käufer die Möglichkeit zu geben, einen erwarteten Wert für die Bestellung zu benennen. Dies kann für automatisierte Zuordnungen von Bestellungen und Rechnungen hilfreich sein.

Transport und Lieferung

Es besteht nur eine eingeschränkte Unterstützung von transportbezogenen Informationen. Dennoch wird berücksichtigt, dass der Käufer, die Möglichkeit haben muss, wichtige Angaben zum gewünschten Lieferort, grundlegenden Bedingungen, zum Lieferzeitpunkt bzw. -raum und zum Ansprechpartner der Lieferung anzugeben.

Bestandsmanagement

Die Unterstützung des Bestandsmanagements liegt nicht im Regelungsbereich, dennoch können strukturierte Bestellungen auf der Basis von Katalogen zur automatisierten Kommissionierung in Warenlagern der Lieferanten genutzt werden.

3.2. Geschäftsparteien und Rollen

Die in dieser Spezifikation dargestellten Anwendungsfälle und Geschäftsprozesse, basieren auf den im Folgenden dargestellten Geschäftsparteien (Business Parties) und deren Rollen (Roles).

3.2.1. Geschäftsparteien und ihre Bedeutung

Table 2. Übersicht der Geschäftsparteien
Geschäftspartei Beschreibung

Kunde (Customer)

Der Kunde ist die juristische Person oder Organisation, die eine Ware oder eine Dienstleistung nachfragt.<br/>Beispiele für Kundenrollen: Bedarfsträger, Käufer, Rechnungsempfänger, Leistungsempfänger und Wareneingang.

Lieferant (Supplier)

Der Lieferant ist die juristische Person oder Organisation, die eine Ware oder eine Dienstleistung anbietet. Beispiele für Lieferantenrollen: Verkäufer und Versender.

Die durch die Geschäftsparteien genutzten Rollen und deren Bedeutung sind in der folgenden Tabelle dargestellt.

3.2.2. Rollen und ihre Bedeutung

Table 3. Übersicht der Rollen
Rolle Beschreibung

Bedarfsträger

Organisation (-seinheit), deren Bedarf Auslöser des Erwerbs ist.

Käufer

Organisation (-seinheit), die die Waren oder Dienstleistungen erwirbt. Die Rolle wird vom Bedarfsträger selber oder in seinem Auftrag übernommen.

Rechnungsempfänger

Person oder Organisationseinheit, die die Rechnung empfängt. Die Rolle wird vom Kunden selber oder in seinem Auftrag übernommen.

Verkäufer

Organisation (-seinheit), die die Waren oder Dienstleistungen verkauft. Die Rolle wird vom Lieferanten selber oder in seinem Auftrag übernommen.

Versender

Organisation (-seinheit), von der die Waren oder Dienstleistungen versendet werden. Die Rolle wird vom Lieferanten selber oder in seinem Auftrag übernommen.

Leistungsempfänger

Organisation (-seinheit), an die die Waren oder Dienstleistungen final geliefert bzw. an dem sie final erbracht werden (wenn abweichend vom Wareneingang).

Wareneingang

Organisation (-seinheit), an die die Waren oder Dienstleistungen geliefert bzw. an dem sie erbracht werden. Die Rolle wird vom Käufer übernommen oder in seinem Auftrag.

3.3. Nutzen

Mit Blick auf die Erfolge der Automatisierung im Bereich des Rechnungswesens, besteht auch ein wachsendes Interesse an der Automatisierung des Bestellwesens. Dieser Ansatz hat zwei Dimensionen:

  • Unterstützung einer weiteren Automatisierung des Rechnungswesens und die Nutzung von strukturierten Katalogen als Grundlage für den Bestellprozess.

  • Die Umsetzung dieser BIS ist ein wichtiger Schritt für viele Unternehmen und Behörden bei der vollständigen Automatisierung der Beschaffung.

Seitens der Verkäufer zeigen sich deutliche Automatisierungspotenziale für die Schritte Genehmigung/ Freigabe, Kommissionierung und Rechnungsstellung. In der beschaffenden Behörde können die Freigabe und Rechnungsverarbeitung automatisiert sowie der Bestellprozess unter Verwendung von Katalogen strukturiert werden. Weitere potenzielle Vorteile dieser BIS sind unter anderem:

  • Kann von beschaffenden Behörden als Schritt in Richtung der Automatisierung der Beschaffung genutzt werden. Die Flexibilität der Spezifikationen erlaubt den Käufern eine sukzessive Automatisierung und Strukturierung des Bestellprozesses, auf Grundlage einer Kosten-Nutzen-Betrachtung.

  • KMUs können ihren Geschäftspartnern die Möglichkeit eines standardisierten Dokumentenaustauschs in einheitlicher Art und Weise anbieten und damit alle Bestellungen in elektronische Form überführen.

  • Große Unternehmen können diese BIS als standardisierte Dokumente für allgemeine Geschäftstätigkeiten umsetzen und kundenspezifische Anbindungen für große Geschäftspartner entwickeln.

  • Kann als Grundlage für die Umstrukturierung der internen Bestell- und Rechnungsverarbeitungsprozesse genutzt werden.

  • Seitens der beschaffenden Behörde können erheblich Einsparungen durch eine Automatisierung und Rationalisierung der internen Prozesse realisiert werden.

  • Seitens der Verkäufer können erhebliche Einsparungen durch die Automatisierung und Rationalisierung der internen Prozesse realisiert werden. Die Anbindung zur Kommissionierung und Rechnungsstellung können durch eine erhöhte Qualität der Bestellungen, Umstrukturierung von Beilegungsverfahren zu Rechnungsstreitigkeiten und kürzeren Zahlungszyklen signifikant verbessert werden.

  • Seitens der beschaffenden Behörde können Rechnungsautomatisierung und Bestellprozesse strukturiert werden.

3.4. Interoperabilität

Die dieser Spezifikation zugrundeliegende Peppol BIS Struktur basiert auf dem European Interoperability Framework 2.0 (EIF). Die BIS setzt das EIF 2.0 wie folgt um.

3.4.1. Rechtliche Interoperabilität

  • In Verfahren, die Käufer im öffentlichen Sektor unterstützen, muss die Nutzung der BIS überwacht werden, um sicherzustellen, dass die Geschäftsparteien unter Einhaltung der EU Direktiven zur Beschaffung handeln.

3.4.2. Organisatorische Interoperabilität

Organisation (Organisation/Unternehmen):

  • Die Peppol BIS unterstützt die Beziehungen Unternehmen-zu-Unternehmen (engl. Business to Business, kurz B2B) und Unternehmen-zu-Behörde (engl. Business to Government, kurz B2G).

  • Die Peppol BIS unterstützt grenzüberschreitende, regionale und nationale Bestellprozesse in der EU und dem Europäischen Wirtschaftsraum (EWR).

  • Die Peppol BIS kann als Komponente in einer Übereinkunft zum elektronischen Datenaustausch (engl. electronic data interchange, kurz EDI) innerhalb einer Handelsgemeinschaft (trading community) eingesetzt werden.

  • Die Peppol BIS unterstützt die Anbindung von Geschäftsprozessen in der sendenden und der empfangenden Organisation. Der Prozess einer elektronischen Übermittlung einer Bestellung kann sowohl in die internen Prozesse des Senders als auch in die internen Prozesse des Empfängers eingebunden werden, welche aus sich aus verschiedenen Gründen unterscheiden können.

Organisation (Prozess):

  • Die Peppol BIS unterstützt eine Reihe von „Allgemeinen Geschäftsprozessen“, für die angenommen wird, dass in den meisten öffentlichen und privaten Organisationen unterstützt werden. Hierbei handelt es sich um Prozesse, die weit verbreitet eingesetzt werden oder als relevant für die meisten Unternehmen angesehen werden.

3.4.3. Semantische Interoperabilität

Semantik:

Die Menge der Informationselemente wird als hinreichend angenommen, um den oben genannten organisatorischen Anforderungen aus geschäftlicher und Verarbeitungssicht gerecht zu werden.

Eine Kern-Geschäftsnachricht:

  • Datenmodell: eine Menge von Elementen, die der Empfänger verarbeiten können muss.

  • Geschäftsregeln: eine Menge von Geschäftsregeln, die eine einheitliche Verarbeitung der Informationselemente sicherstellt. Die Regeln sind so spezifiziert, dass eine automatisierte Validierung der Dokument-Instanzen möglich ist. Die Aussteller und Empfänger können die Konformität der ausgetauschten Dokumente gegenüber den Regeln der BIS verifizieren.

  • PEPPOL ergänzt über die Regeln des Datenmodells hinausgehende Geschäftsregeln, um Design-Entscheidungen zu verdeutlichen, die vom (CEN WS/BII) offen gelassen wurden. Diese Entscheidungen sollen die Hürden herabsetzen, indem die Auswahlmöglichkeiten bei der Umsetzung begrenzt werden. Dadurch wird die Interoperabilität der Peppol Transaktionen erhöht.

3.4.4. Technische Interoperabilität

Technisches Zusammenspiel (Prozess und semantische Umsetzung):

  • Bindung an OASIS UBL 2.1, (UBL 2.1)

  • ISO/IEC 19757-3 Schematron, für die Automatisierung der Dokumenten-Validierung, siehe Schematron

Technisches Zusammenspiel (eSignature Validation):

  • In dieser Peppol BIS nicht zwingend vorgeschrieben. Wird nicht unterstützt.

4. Prozesse und typische Anwendungsfälle

4.1. Prozessschritte

Der Bestellablauf kann wie folgt beschrieben werden:

  1. Ein Käufer sendet eine Bestellung an den Verkäufer, in der er die Lieferung von Waren oder Dienstleistungen anfordert

  2. Die Beauftragung kann sich hinsichtlich der Geschäftsbedingungen auf eine Rahmenvereinbarung beziehen. Andernfalls gelten die Allgemeinen Geschäftsbedingungen des Käufers.

  3. Eine Bestellung kann Artikel (Waren oder Dienstleistungen) mit Artikelkennungen oder Artikel mit Freitextbeschreibung enthalten.

4.2. Geschäftsprozessdiagramm

Bestellung ohne Rückantwort
Figure 1. bpmn_order_only

4.3. Anwendungsfall 1 - Bestellung von Artikeln mit Artikelnummer

Dieser Anwendungsfall stellt eine Bestellung von Artikeln mit Artikelnummer dar.

Anwendungsfall-Nummer 1

Name des Anwendungsfalls

Bestellung von Artikeln mit Artikelnummer

Beschreibung des Anwendungsfalls

Die Bestellung gibt dem Verkäufer die Lieferadresse vor. Der Verkäufer kann einen Teil der bestellten Artikel liefern, aber nicht alle. Ein Artikel muss ersetzt werden.

Beteiligte Geschäftsparteien

Käufer, Verkäufer

Annahmen

Der Käufer verwendet einen Katalog oder eine Produktliste für die Bestellung. Der Katalog enthält die Artikelnummern, Namen und die Art der Artikeleinheiten.

Prozessablauf

Der Käufer legt eine Bestellung mit drei verschiedenen Bestellzeilen an.

Ergebnis

Der Käufer und der Verkäufer erreichen eine Einigung. Wenn die Rechnung auf die Bestellung referenziert, dann kann die Rechnung automatisch zugeordnet werden.

XML Beispiel-Datei

Anwendungsfallbeispiele

4.4. Anwendungsfall 2 - Freitextbestellung

Dieser Anwendungsfall stellt eine Freitextbestellung dar.

Anwendungsfall-Nummer 2

Name des Anwendungsfalls

Freitextbestellung

Beschreibung des Anwendungsfalls

Eine Bestellung von Artikeln durch eine Freitext-Beschreibung und Attribute/ value pairs.

Beteiligte Geschäftsparteien

Käufer, Verkäufer, Bedarfsträger

Annahmen

Der Käufer hat keine strukturierten Informationen zu dem Artikel. Der Käufer muss die Artikel so genau beschreiben, dass der Verkäufer die gewünschten Artikel eindeutig identifizieren kann.

Prozessablauf

Der Käufer legt eine Bestellung mit zwei verschiedenen Bestellzeilen an. Der Verkäufer erhält die Bestellung.

Ergebnis

Der Käufer und der Verkäufer erreichen eine Einigung. Wenn die Rechnung auf die Bestellung referenziert, dann kann die Rechnung automatisch zugeordnet werden.

XML Beispiel-Datei

Anwendungsfallbeispiele

4.5. Anwendungsfall 3 - Bestellung von Leistungen

Dieser Anwendungsfall stellt die Bestellung einer Dienstleistung dar.

Anwendungsfall-Nummer 3

Name des Anwendungsfalls

Bestellung von Dienstleistungen

Beschreibung des Anwendungsfalls

Eine Bestellung von Übersetzungsleistungen. Der Lieferort und Lieferzeitraum sind angegeben.

Beteiligte Geschäftsparteien

Käufer, Verkäufer

Annahmen

Der Käufer verwendet ein Bestellformular mit vordefinierter Dienstleistungsbeschreibung.

Prozessablauf

Der Käufer legt eine Bestellung mit einer Bestellzeile für Übersetzungsleistungen Schwedisch-Spanisch an. Der Verkäufer erhält die Bestellung.

Ergebnis

Der Käufer und der Verkäufer erreichen eine Einigung. Wenn die Rechnung auf die Bestellung referenziert, dann kann die Rechnung automatisch zugeordnet werden.

XML Beispiel-Datei

Anwendungsfallbeispiele

4.6. Anwendungsfall 4 - Komplexe Bestellung

Dieser Anwendungsfall stellt eine Bestellung dar, die fast alle Elemente der Bestellnachricht verwendet.

Anwendungsfall-Nummer 4

Name des Anwendungsfalls

Komplexe Bestellung

Beschreibung des Anwendungsfalls

Eine Bestellung mit Artikelnummern, die Rabatte und Kosten auf Bestell- und Bestellzeilenebene sowie im Preis beinhaltet.

Beteiligte Geschäftsparteien

Käufer, Verkäufer, Bedarfsträger

Annahmen

Der Käufer verwendet einen Katalog oder eine Produktliste für die Bestellung. Der Katalog enthält die Artikelnummern, Namen und die Art die Artikeleinheiten. Der Käufer hat sich mit dem Verkäufer auf Rabatte auf Bestell- und Bestellzeilenebene und den Gesamtpreis geeinigt.

Prozessablauf

Der Käufer legt eine Bestellung mit vier Bestellzeilen an. Der Verkäufer erhält die Bestellung.

Ergebnis

Der Käufer und der Verkäufer erreichen eine Einigung. Wenn die Rechnung auf die Bestellung referenziert, dann kann die Rechnung automatisch zugeordnet werden.

XML Beispiel-Datei

Anwendungsfallbeispiele

4.7. Anwendungsfall 5 - Bestellung mit Lieferant und Leistungsempfänger

Dieser Anwendungsfall stellt eine Bestellung von Artikeln mit Artikelnummer dar. Sie enthält Angaben zum Lieferort sowie dem Leistungsempfänger.

Anwendungsfall-Nummer 5

Name des Anwendungsfalls

Bestellung mit Lieferant und Leistungsempfänger

Referenz zu Anwendungsfällen der Pilot-Partner

Zentrale Bestellung im Auftrag, Nicht-Konfigurierbare Artikel

Beschreibung des Anwendungsfalls

Eine Bestellung mit Artikelnummern, die Rabatte und Kosten auf Bestell- und Bestellzeilenebene sowie im Preis beinhaltet.

Beteiligte Geschäftsparteien

Käufer, Verkäufer, Lieferant, Leistungsempfänger

Annahmen

Der Käufer verwendet einen Katalog oder eine Produktliste für die Bestellung. Der Katalog enthält die Artikelnummern, Namen und die Art die Artikeleinheiten.

Prozessablauf

Der Käufer legt eine Bestellung mit drei Bestellzeilen an. Der Verkäufer erhält die Bestellung. Zum Lieferzeitpunkt verpackt der Verkäufer alle Artikel, druckt und bringt Warenbeschreibungen auf jeden verpackten Artikel an. Die gesamte Lieferung wird gemeinsam verpackt und mit einem Lieferschein versehen. Die gesamte Lieferung wird an den Wareneingang geliefert und entladen. Die gesamte Lieferung wird wieder verladen und durch internen Transport an den Leistungsempfänger geliefert.

Ergebnis

Der Käufer und der Verkäufer erreichen eine Einigung. Die bestellten Artikel haben den Leistungsempfänger erreicht. Wenn die Rechnung auf die Bestellung referenziert, dann kann die Rechnung automatisch zugeordnet werden.

XML Beispiel-Datei

Anwendungsfallbeispiele

5. Datentypen

In diesem Abschnitt werden die primitiven (Grund-)Datentypen sowie die auf ihnen basierenden semantischen Datentypen beschrieben.

5.1. Primitive Datentypen

Inhalte semantischer Datentypen lassen sich den folgenden primitiven Datentypen zuordnen. Diese primitiven Datentypen stammen aus ISO 15000-5:2014, Anhang A.

Primitiver Datentyp Definition

Binary

Eine Reihe von Binärziffernfolgen begrenzter Länge.

Date

Zeitangabe, die einen Kalendertag auf einer Zeitskala darstellt, die aus einem Ursprung und aufeinanderfolgenden Kalendertagen besteht (ISO 8601:2004).

Decimal

Eine Untermenge der reellen Zahlen, die als Dezimalzahlen dargestellt werden kann.

String

Eine begrenzte Zeichenfolge.

5.2. Semantische Datentypen

Semantische Datentypen werden verwendet, um die Kluft zwischen den semantischen Konzepten, die durch die im semantischen Modell definierten Informationselemente ausgedrückt werden, und die technische Implementierung zu überbrücken. Die semantischen Datentypen definieren den für den jeweiligen Inhalt zulässigen Wertebereich und die zusätzlichen Informationskomponenten (Attribute), die erforderlich sind, um eine präzise Interpretation des Inhalts sicherzustellen.

In den folgenden Abschnitten werden die verschiedenen semantischen Datentypen beschrieben. Jeder Abschnitt enthält eine Tabelle, in der Informationen zum Inhalt (Content) des jeweiligen semantischen Datentyps aufgeführt sind (Kardinalität, zugeordneter primitiver Datentyp, Beispielwert) sowie ggf. die zusätzlichen Informationskomponenten und deren Eigenschaften.

Der Inhalt (Content) eines semantischen Datentyps repräsentiert den Wert, den ein Informationselement, das auf diesem Datentypen basiert, in einem Instanzdokument besitzt. Da ein Informationselement in einem Instanzdokument immer einen Wert besitzen muss, ist der Inhalt (Content) aller semantischen Datentypen als mandatorisch gekennzeichnet.

5.2.1. Amount

Mit diesem Datentyp wird ein Geldbetrag in numerischer Form abgebildet. Dem Betrag wird über ein separates Informationselement eine Währung zugeordnet.

Werte des Typs Amount werden mit zwei Nachkommastellen angegeben.
Komponente Primitiver Datentyp Kardinalität Beispiel

Content

Decimal

1

10000,25

5.2.2. Price Amount

Mit diesem Datentyp wird der dem Preis eines Einzelpostens entsprechende Geldbetrag in numerischer Form abgebildet. Dieser Geldbetrag kann mit der jeweiligen Mengenangabe zum Einzelposten multipliziert werden.

Für Werte des Typs Price Amount besteht, im Unterschied zur Regelung für Werte des Datentyps Amount, keine Beschränkung der Anzahl von Nachkommastellen.
Komponente Primitiver Datentyp Kardinalität Beispiel

Content

Decimal

1

10000,1234

5.2.3. Percentage

Mit diesem Datentyp wird eine Prozentangabe abgebildet. Prozentangaben erfolgen als Teile von Hundert. Der Wert "34,78" entspricht somit beispielsweise 34,78 %.

Für Werte des Typs Percentage besteht keine Beschränkung der Anzahl von Nachkommastellen.
Komponente Primitiver Datentyp Kardinalität Beispiel

Content

Decimal

1

34,7812

5.2.4. Quantity

Mit diesem Datentyp wird die Mengenangabe zu einem Einzelposten abgebildet. Der Mengenangabe wird über ein eigenständiges Informationselement eine Maßeinheit zugeordnet.

Für Werte des Typs Quantity besteht keine Beschränkung der Anzahl von Nachkommastellen.
Komponente Primitiver Datentyp Kardinalität Beispiel

Content

Decimal

1

10000,1234

5.2.5. Code

Mit diesem Datentyp wird ein Code abgebildet, der in einer Codeliste spezifiziert ist.

Eine Codeliste ist eine Liste von Codes und der Beschreibung ihrer jeweiligen Bedeutung. Die Bedeutung von Codes kann dabei beispielsweise in Form von Namen (Augsburg, Bremen, München, etc.), Begrifflichkeiten (ledig, verheiratet, geschieden, etc.) oder Statusbeschreibungen (Antrag übermittelt, Antrag empfangen, Antrag unvollständig, etc.) vorliegen. Codelisten werden eingesetzt, um die für einen bestimmten Kontext relevanten Sachverhalte eindeutig zu bezeichnen und in der erforderlichen Form zu beschreiben. Für jedes auf dem Datentyp Code basierende Informationselement ist die zugrundeliegende Codeliste im semantischen Modell spezifiziert.

Somit unterscheiden sich Werte des Typs Code von Werten des Typs Identifier, da Codes eine standardisierte Bedeutung haben, die allen Kommunikationspartnern im Vorfeld bekannt ist.

Jeweils ist die jüngste veröffentlichte Version der Codeliste zu nutzen.
Ein Code muss genau so angegeben werden, wie er in der jeweiligen Codeliste vorliegt.
Komponente Primitiver Datentyp Kardinalität Beispiel

Content

String

1

Abc123

5.2.6. Identifier

Mit diesem Datentyp werden eindeutige Bezeichnungen bzw. Kennungen abgebildet (engl. Identifier, kurz ID), die von verschiedenen Stellen vergeben werden können.

Für jede Bezeichnung bzw. jede Kennung, die innerhalb des semantischen Datenmodells auftritt, ist festgelegt, ob über die Komponenten "Scheme identifier" und "Scheme version identifier" ein bestimmtes Bildungsmuster verwendet werden kann bzw. muss. Im letzteren Fall wird eine Liste der nutzbaren Bildungsmuster spezifiziert.
Komponente Primitiver Datentyp Kardinalität Beispiel

Content

String

1

abc:123-DEF

Scheme identifier

String

0..1

0088

Scheme version identifier

String

0..1

1.0

5.2.7. Date

Mit diesem Datentyp wird ein kalendarisches Datum der Form YYYY-MM-DD abgebildet, wie es in der ISO 8601 Spezifikation "Calendar date complete representation" beschrieben ist (siehe ISO 8601:2004).

Datumsangaben dürfen keine Angaben zur Zeitzone enthalten.
Komponente Primitiver Datentyp Kardinalität Beispiel

Content

Date

1

2017-12-01

5.2.8. Time

Mit diesem Datentyp wird eine Uhrzeit der Form [hh]:[mm]:[ss] abgebildet, wie sie in der ISO 8601 Spezifikation "Extended time format" beschrieben ist (siehe ISO 8601:2004).

Uhrzeiten dürfen keine Angaben zur Zeitzone enthalten.
Sekunden dürfen nicht um Dezimalstellen erweitert werden.
Komponente Primitiver Datentyp Kardinalität Beispiel

Content

Date

1

09:30:12

5.2.9. Document Reference

Mit diesem Datentyp werden eindeutige Bezeichnungen bzw. Kennungen abgebildet, die ein Dokument oder eine Dokumentenzeile eindeutig identifizieren.

Komponente Primitiver Datentyp Kardinalität Beispiel

Content

String

1

abc:123-DEF

5.2.10. Text

Mit diesem Datentyp wird ein geschriebener bzw. gedruckter Text abgebildet, inklusive möglicher Zeilenumbrüche. Zeilenumbrüche sollen auf der Empfängerseite beibehalten und berücksichtigt werden.

Komponente Primitiver Datentyp Kardinalität Beispiel

Content

String

1

5% allowance when paid within 30 days

5.2.11. Binary Objects

Mit diesem Datentyp wird eine das Geschäftsdokument begleitende Datei in der Form eines Binärobjekts abgebildet. Derartige Anhänge müssen zusammen mit dem Geschäftsdokument übermittelt werden.

Gegebenenfalls liegen Größenbeschränkungen vor. Eine Orientierung ist im Übermittlungsleitfaden CEN/TR 16931-4 gegeben.

Mit der Komponente "Mime Code" wird der MIME-Typ (Multipurpose Internet Mail Extensions) der Datei angegeben. Der Empfänger des Geschäftsdokuments muss Anhänge der folgenden MIME-Typen annehmen und verarbeiten können. (Übliche Dateiendungen sind in Klammern angegeben.)

  • application/pdf (.pdf)

  • image/png (.png)

  • image/jpeg (.jpg)

  • text/csv (.csv)

  • application/vnd.openxmlformats-officedocument.spreadsheetml.sheet (.xslx)

  • application/vnd.oasis.opendocument.spreadsheet (.ods)

Mit der Komponente "Filename" wird der Dateiname angegeben.

Komponente Primitiver Datentyp Kardinalität Beispiel

Content

Binary

1

QmFzZTY0IGNvbnRlbnQgZXhhbXBsZQ==

Mime Code

String

1

image/jpeg

Filename

String

1

drawing5.jpg

5.2.12. Boolean

Mit diesem Datentyp werden die Booleschen Wert true und false abgebildet. Alle Informationselemente des Typs Boolean müssen entweder den Wert true oder false besitzen.

Komponente Primitiver Datentyp Kardinalität Beispiel

Content

String

1

true

6. Beschreibung ausgewählter Bestandteile der Bestellnachricht

6.1. Rollen

Die folgenden Rollen können in der Bestellnachricht spezifiziert werden:

6.1.1. Verkäufer/ Anbieter

Der Verkäufer ist die Organisationseinheit des Anbieters, die dem Käufer Waren oder Dienstleistungen anbietet.

Die Angaben zum Verkäufer sind in der Peppol BIS Bestellnachricht verpflichtend.
UBL-Beispiel für Verkäufer-Angaben mit Kennung, Name, Adresse, Ansprechpartner etc.:
<cac:SellerSupplierParty>
  <cac:Party>
    <cbc:EndpointID schemeID="0192">987654325</cbc:EndpointID>
    <cac:PartyIdentification>
      <cbc:ID schemeID="0192">987654325</cbc:ID>
    </cac:PartyIdentification>
    <cac:PostalAddress>
      <cbc:StreetName>Harbour street</cbc:StreetName>
      <cbc:AdditionalStreetName>Dock 45</cbc:AdditionalStreetName>
      <cbc:CityName>Bergen</cbc:CityName>
      <cbc:PostalZone>5005</cbc:PostalZone>
      <cbc:CountrySubentity>Region West</cbc:CountrySubentity>
      <cac:AddressLine>
        <cbc:Line>Gate 34</cbc:Line>
      </cac:AddressLine>
      <cac:Country>
        <cbc:IdentificationCode>NO</cbc:IdentificationCode>
      </cac:Country>
    </cac:PostalAddress>
    <cac:PartyLegalEntity>
      <cbc:RegistrationName>Cod Liver Oil Limited</cbc:RegistrationName>
    </cac:PartyLegalEntity>
    <cac:Contact>
      <cbc:Name>Öystein</cbc:Name>
      <cbc:Telephone>+47555444333</cbc:Telephone>
      <cbc:ElectronicMail>oystein@codliveroil.no</cbc:ElectronicMail>
    </cac:Contact>
  </cac:Party>
</cac:SellerSupplierParty>

6.1.2. Käufer/ Kunde

Der Käufer ist die Organisationseinheit des Kunden, die Waren oder Dienstleistungen einkauft.

Die Angaben zum Käufer sind in der Peppol BIS Bestellnachricht verpflichtend.
UBL-Beispiel für Käufer-Angaben mit Kennung, Name, Adresse, Ansprechpartner etc.:
<cac:BuyerCustomerParty>
  <cac:Party>
    <cbc:EndpointID schemeID="0007">5541277711</cbc:EndpointID>
    <cac:PartyIdentification>
      <cbc:ID schemeID="0007">5541277711</cbc:ID>
    </cac:PartyIdentification>
    <cac:PartyName>
      <cbc:Name>City Hospital</cbc:Name>
    </cac:PartyName>
    <cac:PartyLegalEntity>
      <cbc:RegistrationName>City Hospital 345433</cbc:RegistrationName>
      <cbc:CompanyID schemeID="0007">5541277711</cbc:CompanyID>
      <cac:RegistrationAddress>
        <cbc:CityName>Eurocity</cbc:CityName>
        <cac:Country>
          <cbc:IdentificationCode>SE</cbc:IdentificationCode>
        </cac:Country>
      </cac:RegistrationAddress>
    </cac:PartyLegalEntity>
    <cac:Contact>
      <cbc:Name>Martin Foggerty</cbc:Name>
      <cbc:Telephone>+46555785488</cbc:Telephone>
      <cbc:ElectronicMail>martin.foggerty@cityhospital.se</cbc:ElectronicMail>
    </cac:Contact>
  </cac:Party>
</cac:BuyerCustomerParty>

6.1.3. Bedarfsträger/ Kunde

Die Organisationseinheit, die den Bedarf für eine Bestellung kommuniziert. Sie ist meistens auch der Empfänger der Waren oder Dienstleistungen.

Die Angaben zum Bedarfsträger sind in der Peppol BIS Bestellnachricht optional.
UBL-Beispiel für Bedarfsträger-Angaben mit Kennung, Name, Adresse, Ansprechpartner etc:
<cac:OriginatorCustomerParty>
  <cac:Party>
    <cac:PartyIdentification>
      <cbc:ID schemeID="0088">7300010000001</cbc:ID>
    </cac:PartyIdentification>
    <cac:PartyName>
      <cbc:Name>Surgery Department</cbc:Name>
    </cac:PartyName>
    <cac:Contact>
      <cbc:Name>Dr Bengt</cbc:Name>
      <cbc:Telephone>+46555444777</cbc:Telephone>
      <cbc:ElectronicMail>bengt@cityhospital.no</cbc:ElectronicMail>
    </cac:Contact>
  </cac:Party>
</cac:OriginatorCustomerParty>

6.1.4. Rechnungsempfänger

Der Rechnungsempfänger ist die Organisationseinheit des Kunden, welche die Rechnungen für Bestellungen erhält.

Die Angaben zum Rechnungsempfänger sind in der Peppol BIS Bestellnachricht optional.
UBL-Beispiel für Rechnungsempfänger-Angaben mit Kennung, Name, Adresse, Ansprechpartner etc:
<cac:AccountingCustomerParty>
  <cac:Party>
    <cbc:EndpointID schemeID="0007">5544332211</cbc:EndpointID>
    <cac:PartyIdentification>
      <cbc:ID schemeID="0007">5544332211</cbc:ID>
    </cac:PartyIdentification>
    <cac:PartyName>
      <cbc:Name>Swedish Hospitals</cbc:Name>
    </cac:PartyName>
    <cac:PostalAddress>
      <cbc:StreetName>High Street 23</cbc:StreetName>
      <cbc:AdditionalStreetName>First floor</cbc:AdditionalStreetName>
      <cbc:CityName>Trondheim</cbc:CityName>
      <cbc:PostalZone>7005</cbc:PostalZone>
      <cbc:CountrySubentity>Region M</cbc:CountrySubentity>
      <cac:AddressLine>
        <cbc:Line>Room 18</cbc:Line>
      </cac:AddressLine>
      <cac:Country>
        <cbc:IdentificationCode>NO</cbc:IdentificationCode>
      </cac:Country>
    </cac:PostalAddress>
    <cac:PartyLegalEntity>
      <cbc:RegistrationName>Swedish Hospitals AB</cbc:RegistrationName>
      <cbc:CompanyID>5544332211</cbc:CompanyID>
      <cac:RegistrationAddress>
        <cbc:CityName>Stockholm</cbc:CityName>
        <cac:Country>
          <cbc:IdentificationCode>SE</cbc:IdentificationCode>
        </cac:Country>
      </cac:RegistrationAddress>
    </cac:PartyLegalEntity>
  </cac:Party>
</cac:AccountingCustomerParty>
Um die Verwendung von Informationen aus der Bestellung in der resultierenden Rechnung zu vereinfachen, wird empfohlen, neben PartyName und PartyIdentification so viele weitere Informationen wie möglich anzugeben, z. B. PostalAddress, PartyTaxScheme und PartyLegalEntity.

6.2. Anhänge

Dateien, welche nicht im XML-Format vorliegen, können als Anhänge einer PEPPOL BIS Bestellnachricht versendet werden. Dies können Zeichnungen, Arbeitszeitnachweise oder weitere für die Bestellung relevante Dokumente sein. Anhänge können entweder als binäre Objekte mit Base64-Codierung in die Nachricht eingebunden werden oder in Form eines URI als Link an eine externe Adresse versendet werden.

Es wird empfohlen, Anhänge als eingebettete binäre Objekte und nicht als externe Referenzen zu senden.

Valide Codes können dem Abschnitt zu Codelisten entnommen werden.

UBL-Beispiel für Anhänge als eingebettete, binäre Objekte:
<cac:AdditionalDocumentReference>
  <cbc:ID>100</cbc:ID>
  <cbc:DocumentType>Drawing</cbc:DocumentType>(1)
  <cac:Attachment>
    <cbc:EmbeddedDocumentBinaryObject mimeCode="application/pdf" filename="blueprint.pdf" >Ymx1ZXByaW50</cbc:EmbeddedDocumentBinaryObject>(2)
  </cac:Attachment>
</cac:AdditionalDocumentReference>
1 Der Einsatz des Elements cac:AdditionalDocumentReference/cbc:DocumentType für das Versenden einer Kurzbeschreibung zum Inhalt des Anhangs wird empfohlen.
2 Der Dateiname und Erweiterung sollen in dem Attribut Filename im Element cbc:EmbeddedDocumentBinaryObject genannt werden.
Anhänge sollten für zusätzliche Informationen und nicht als Bestellkopien verwendet werden.

6.3. Bedarfsträger-Referenzdokument

Das Element cac:OriginatorDocumentReference/cbc:ID referenziert auf ein Dokument, welches der Bestellung zugrunde liegt. Dies kann eine interne Bedarfsmeldung auf Seite des Käufers sein, welche die Bestellung initiiert hat.

UBL-Beispiel einer Bedarfsträger-Referenz mit Kennung des Referenzdokuments:
<cac:OriginatorDocumentReference>
  <cbc:ID>2139239</cbc:ID>
</cac:OriginatorDocumentReference>

6.4. Produkt-Identifikator

Für die Produktbestimmung müssen die folgenden Identifikatoren verwendet werden:

  • Verkäufer ID

  • Standard ID, z.B. die GS1 Global Trade Item Number (GTIN) oder die EAN (Europäische Artikelnummer, engl. European Article Number)

Der Verwendung einer konkreten Art von Identifikatoren ist abhängig vom Informationsstand zum Zeitpunkt der Bestellabgabe oder den meist verwendeten Angaben des jeweiligen Wirtschaftssektors.

Jede Bestellposition muss einen Identifikator und/oder einen (Produkt-)Namen besitzen
UBL-Beispiel einer Bestellposition, die gleichzeitig die Verkäufer-ID und die Standard-ID nutzt:
<cac:SellersItemIdentification>
  <cbc:ID>SN-33</cbc:ID>
</cac:SellersItemIdentification>

<cac:StandardItemIdentification>
  <cbc:ID schemeID="0160">05704066204093</cbc:ID>
</cac:StandardItemIdentification>

6.5. Produktname und Produktbeschreibung

Der Produktname soll in dem tag cac:Item/cbc:Name auf Ebene der Bestellzeile übermittelt werden. Die Produktbeschreibung kann in folgendem Element übermittelt werden cac:Item/cbc:Description.

Der Produktname wird meistens in der Bestellung vom Käufer zum Verkäufer übermittelt.

Abbildung von Produktnamen und -beschreibung in der Bestellnachricht:
<cac:Item>
 <cbc:Description>1x12 pack sauce bags</cbc:Description>
 <cbc:Name>White sauce</cbc:Name>

  <!-- Code omitted for clarity -->

6.6. Mengenangaben und Mengeneinheiten

Es können eine Reihe von Mengenangaben und Mengeneinheiten in einer Peppol-Bestellung abgebildet werden. Beide sind Bestandteil des Bestell- und Lieferprozesses.

Die unten aufgeführte Tabelle enthält eine Auflistung der Mengen und Mengeneinheiten im vorgegeben Format. Alle angegeben Mengen müssen einer validen Mengeneinheit, welche in den Codelisten aufgeführt wird, zugeordnet sein.

Name des Elements/ (Tag name) Beschreibung

Mengenpreis (cbc:BaseQuantity)

Bei Abnahme einer größeren Menge eingeräumter günstigerer Preis

Bestellmenge (cbc:Quantity)

Menge, die bestellt wird, z.B. Stückzahl oder Volumen in Liter
UBL-Beispiel einer Bestellposition der Menge 120 Liter (cbc:Quantity) und der Preisangabe pro Liter:
<cbc:Quantity unitCode="LTR">120</cbc:Quantity>

<cac:Price>
  <cbc:PriceAmount currencyID="EUR">6</cbc:PriceAmount>
  <cbc:BaseQuantity unitCode="LTR">1</cbc:BaseQuantity>
</cac:Price>

6.7. Preis

Preise können sowohl für Artikel mit oder ohne Artikelnummer als auch für Freitextbestellungen übermittelt werden. Wenn in der Bestellung keine Preise angegeben sind, so wird im Normalfall im Prozess der Rechnungsprüfung ein Vergleich vom Preis in der Rechnung mit dem Preis im Katalog vorgenommen.

Der übermittelte Preis bezieht sich auf die Artikel oder Leistungen der Bestellung.

Preisen sollen Rabatte und/oder Kosten einbeziehen, die steuerlichen Abgaben (z.B. Mehrwertsteuer, etc.) hier ausgenommen.

UBL-Beispiel für Preisinformation in einer Bestellnachricht mit der Artikelanzahl 2 über den Betrag von 30 EUR:
<cac:Price>
  <cbc:PriceAmount currencyID="EUR">30</cbc:PriceAmount>
  <cbc:BaseQuantity unitCode="NAR">2</cbc:BaseQuantity>
</cac:Price>

6.8. Rabatte und Kosten (Gebühren)

Die Bestell-Transaktion weist Elemente für Rabatte und Kosten auf zwei Ebenen aus.

Das Element cac:AllowanceCharge mit dem Unterelement cbc:ChargeIndicator zeigt an, ob es sich bei der Instanz um Kosten (wahr) oder Rabatte (falsch) handelt.

Dokumenten-Ebene: Bezieht sich auf die gesamte Bestellung und wird in die Berechnung des Gesamtbetrags der Bestellung einbezogen, sofern dieser angegeben ist.

  • Mehrere Rabatte und Kosten können angegeben werden.

  • Die steuerlichen Angaben für Rabatte und Kosten sollen im Unterelement cac:TaxCategory angegeben werden.

  • Die Summe aller Rabatte und Kosten soll auf der Dokumentenebene in den Elementen cbc:AllowanceTotalAmount und cbc:ChargeTotalAmount angegeben werden. Zur Berechnung der Gesamtbeträge siehe Berechnung der Gesamtbeträge (nächster Abschnitt).

Das Element Preis auf Bestellzeilen-Ebene Preise sollen immer als Netto-Preis angegeben werden, z.B. der Grundbetrag abzüglich des Rabatts.

  • Es darf nur ein Rabatt auf dieser Ebene vorkommen.

  • Steuerliche Angaben sollen nicht gemacht werden.

  • Rabatt auf den Preis darf nicht Bestandteil weiterer Berechnungen sein.

  • Rabatt auf den Preis kann sich auf den Betrag und den Grundbetrag beziehen.

6.8.1. Berechnung von Rabatt und Kosten

Rabatt und Kosten auf Dokumenten-Ebene umfassen Elemente, die Information zu dem Grundbetrag und Prozentsatz von Rabatt bzw. Kosten. Diese Informationen, sofern sie im Bereich der Rechnung angegeben sind, werden zur Berechnung der Rabatt- bzw. Kostenbeträge herangezogen.

Wenn der Grundbetrag angegeben ist, dann soll der Prozentsatz ebenfalls angegeben werden. Wenn der Prozentsatz angegeben ist, dann soll der Grundbetrag angegeben werden. Die Berechnung der Beträge soll wie folgt vorgenommen werden:

\("Betrag" = "Grundbetrag" \times ("Prozentsatz" \div 100)\)

UBL-Beispiel für Rabatte und Kosten auf Dokumenten-Ebene mit Lieferkosten in Höhe von 20 EUR und Rabatt auf Produktionsfehler von 10 EUR:
<cac:AllowanceCharge>
  <cbc:ChargeIndicator>true</cbc:ChargeIndicator>(1)
  <cbc:AllowanceChargeReasonCode>FC</cbc:AllowanceChargeReasonCode>
  <cbc:AllowanceChargeReason>Freight service</cbc:AllowanceChargeReason>
  <cbc:MultiplierFactorNumeric>2</cbc:MultiplierFactorNumeric>(4)
  <cbc:Amount currencyID="EUR">20</cbc:Amount> (5)
  <cbc:BaseAmount currencyID="EUR">1000</cbc:BaseAmount>(3)
  <cac:TaxCategory>
    <cbc:ID>S</cbc:ID>
    <cbc:Percent>25</cbc:Percent>
    <cac:TaxScheme>
      <cbc:ID>VAT</cbc:ID>
    </cac:TaxScheme>
  </cac:TaxCategory>
</cac:AllowanceCharge>
<cac:AllowanceCharge>
  <cbc:ChargeIndicator>false</cbc:ChargeIndicator>(2)
  <cbc:AllowanceChargeReasonCode>65</cbc:AllowanceChargeReasonCode>
  <cbc:AllowanceChargeReason>Production error discount</cbc:AllowanceChargeReason>
  <cbc:Amount currencyID="EUR">10</cbc:Amount>
  <cac:TaxCategory>
    <cbc:ID>S</cbc:ID>
    <cbc:Percent>25</cbc:Percent>
    <cac:TaxScheme>
      <cbc:ID>VAT</cbc:ID>
    </cac:TaxScheme>
  </cac:TaxCategory>
</cac:AllowanceCharge>
1 ChargeIndicator = true to indicate a charge
2 ChargeIndicator = false to indicate an allowance
3 Base amount, to be used with the percentage to calculate the amount
4 Charge percentage
5 \("Betrag" = "Grundbetrag" \times ("Prozentsatz" \div 100)\)
UBL-Beispiel für einen Rabatt von 10 EUR auf den Preis:
<cac:Price>
  <cbc:PriceAmount currencyID="EUR">40</cbc:PriceAmount>
  <cac:AllowanceCharge>
    <cbc:ChargeIndicator>false</cbc:ChargeIndicator>
    <cbc:Amount currencyID="EUR">10</cbc:Amount>
    <cbc:BaseAmount currencyID="EUR">50</cbc:BaseAmount>
  </cac:AllowanceCharge>
</cac:Price>

6.9. Berechnung der Gesamtbeträge (Erwartete finanzielle Gesamtsumme)

Die folgenden Elemente zeigen die erwartete finanzielle Gesamtsumme für eine Bestellung:

Element Beschreibung Berechnungsformel

<cbc:LineExtensionAmount>

Sum of line amounts

\(\sum("cac:OrderLine/cac:LineItem/cbc:LineExtensionAmount")\)

<cbc:AllowanceTotalAmount>

Allowances on document level

\(\sum("cac:AllowanceCharge[ChargeIndicator='true']/cbc:Amount")\)

<cbc:ChargeTotalAmount>

Charges on document level

\(\sum("cac:AllowanceCharge[ChargeIndicator='false']/cbc:Amount")\)

<cbc:TaxExclusiveAmount>

Order total amount without TAX

\(\ \ \ \ "cac:LegalMonetaryTotal/cbc:LineExtensionAmount"\)
\(– \ "cac:LegalMonetaryTotal/cbc:AllowanceTotalAmount"\)
\(+ \ "cac:LegalMonetaryTotal/cbc:ChargeTotalAmount"\)

<cbc:TaxInclusiveAmount>

Order total amount included TAX

\(\ \ \ \ "cac:LegalMonetaryTotal/cbc:TaxExclusiveAmount"\)
\(+ \ "cac:TaxTotal/cbc:TaxAmount"\)

<cbc:PrepaidAmount>

Any amounts that have been paid a-priory

Not applicable

<cbc:PayableRoundingAmount>

Rounding of Order total

Not applicable

<cbc:PayableAmount>

The amount that is expected to be paid

\(\ \ \ \ "cac:LegalMonetaryTotal/cbc:TaxInclusiveAmount"\)
\(- \ "cac:LegalMonetaryTotal/cbc:PrepaidAmount"\)
\(+ \ "cac:LegalMonetaryTotal/cbc:PayableRoundingAmount"\)

  • Beträge müssen mit genau zwei Dezimalstellen angegeben werden, ausgenommen sind Preise, die maximal vier Dezimalstellen haben.

  • Der erwartete Gesamtzahlungsbetrag darf nicht negativ sein

  • Die erwartete Summe der Bestellzeilen-Beträge darf nicht negativ sein.

Note that the AnticipatedMonetaryTotals class is optional. If the class is included in the message, the only mandatory elements are the cbc:LineExtensionAmount and the cbc:PayableAmount elements. All other elements are optional. When optional elements are used, the content MUST be according to the formulas in the table above.*

6.9.1. Element für den Rundungsbetrag (PayableRoundingAmount)

Es ist möglich, den erwarteten Zahlungsbetrag zu runden. Die Regel für das Runden stützt sich auf die Standard-Regel, welche besagt, dass Dezimalstellen größer oder gleich 0,5 werden aufgerundet und Dezimalstellen kleiner werden abgerundet.

Das Element cac:AnticipatedMonetaryTotal/cbc:PayableRoundingAmount wird für das Runden verwendet und wird auf der Kopfzeilen-Ebene spezifiziert.

Beispiel: Betrag 999.81 wird gerundet auf 1000. PayableRounding Amount = 0.19.

6.9.2. Beispiel-Berechnung

Beschreibung Element Beispiel-Wert

Summe der Bestellzeilen-Beträge

cbc:LineExtensionAmount

700

Rabatt auf Dokumenten-Ebene

cbc:AllowanceTotalAmount

100.00

Kosten auf Dokumenten-Ebene

cbc:ChargeTotalAmount

200.00

Gesamtbetrag der Bestellung ohne Steuern

cbc:TaxExclusiveAmount

800

Steuer-Gesamtbetrag

cac:TaxTotal/cbc:TaxAmount

85.63

Rundung des Gesamtbetrags der Bestellung

cbc:PayableRoundingAmount

0.37

Gesamtbetrag der Bestellung mit Steuern

cbc:TaxInclusiveAmount

885.63

Gezahlte Beträge

cbc:PrepaidAmount

135.00

Erwarteter Zahlungsbetrag

cbc:PayableAmount

751.00
Das oben aufgeführte Beispiel wird in der Bestellung in folgender Weise dargestellt
<cac:TaxTotal>
  <cbc:TaxAmount currencyID="EUR">85.63</cbc:TaxAmount>
</cac:TaxTotal>

<cac:AnticipatedMonetaryTotal>
  <cbc:LineExtensionAmount currencyID="EUR">700</cbc:LineExtensionAmount>
  <cbc:TaxExclusiveAmount currencyID="EUR">800</cbc:TaxExclusiveAmount>
  <cbc:TaxInclusiveAmount currencyID="EUR">885.63</cbc:TaxInclusiveAmount>
  <cbc:AllowanceTotalAmount currencyID="EUR">100</cbc:AllowanceTotalAmount>
  <cbc:ChargeTotalAmount currencyID="EUR">200</cbc:ChargeTotalAmount>
  <cbc:PrepaidAmount currencyID="EUR">135</cbc:PrepaidAmount>
  <cbc:PayableRoundingAmount currencyID="EUR">0.37</cbc:PayableRoundingAmount>
  <cbc:PayableAmount currencyID="EUR">751.00</cbc:PayableAmount>
</cac:AnticipatedMonetaryTotal>

6.9.3. Steuer-Gesamtbetrag

Es ist möglich, den Steuerbetrag der Bestellung auf Kopfzeilen-Ebene und Bestellzeilen-Ebene anzugeben.

UBL-Beispiel eines Steuergesamtbetrags auf Kopfebene über 268.75 EUR:
<cac:TaxTotal>
  <cbc:TaxAmount currencyID="EUR">268.75</cbc:TaxAmount>
</cac:TaxTotal>

6.9.4. Art der Steuer auf Bestellzeilen-Ebene

Steuerangaben auf Bestellzeilen-Ebene werden in der Klasse cac:ClassifiedTaxCategory angegeben.

Jede Bestellzeile soll das Element Steuerangaben mit dem Code der Steuerart und dem Prozentsatz enthalten. Dies trifft nicht zu, wenn die Rechnung steuerbefreit ist. In diesem Fall soll der Prozentsatz nicht auf der Bestellzeilen-Ebene angegeben werden.

UBL-Beispiel der Steuer auf Bestellzeilen-Ebene mit Code der Steuerart, Prozentsatz der Steuer von 18 % und Steuer-Kennung VAT
<cac:ClassifiedTaxCategory>
    <cbc:ID>S</cbc:ID> (1)
    <cbc:Percent>18</cbc:Percent>(2)
    <cac:TaxScheme>
        <cbc:ID>VAT</cbc:ID>(3)
    </cac:TaxScheme>
</cac:ClassifiedTaxCategory>
1 TAX category according to codelist {vat-codes}
2 TAX percentage. For EN must be present unless TAX category code is O (the value "O" means "Out of scope for TAX").
3 Value must identify the correct tax type. For example VAT, GST or sales tax.

7. Geschäftsregeln

In diesem Abschnitt werden die Geschäftsregel des Standards XBestellung beschrieben. In der Spalte Übersetzung wurden Verweise auf Elemente des Semantischen Datenmodells. Diese dienen einer Zuordnung der Geschäftregeln zu Informationselementen des Datenmodells.

die dargestellte Tabelle enthält ausschließlich die fachlichen Geschäftsregeln der Peppol Order Transaction (T01). Sie wird in Art und Darstellung verändert und um die fachlichen Geschäftsregeln der Profilierung für die deutsche öffentliche Verwaltung ergänzt.
Table 4. Geschäftsregeln XBestellung
Identifier Übersetzung Fehlerart

PEPPOL-T01-CL001

Der Reason code muss einem Code aus der Teilmenge der Codeliste UNCL 5189 in der Version D.16B entsprechen.

fatal

PEPPOL-T01-CL002

Der Reason code muss einem Code aus der Codeliste UNCL 5189 in der Version D.16B entsprechen.

fatal

PEPPOL-T01-R001

Jede Bestellzeile muss eine für die Bestellung eindeutige Dokument-Zeilen-Kennung aufweisen.

fatal

PEPPOL-T01-R002

Eine Bestellung soll Informationen zum Enddatum der Gültigkeit (PEPPOL-T01-12) enthalten.

warning

PEPPOL-T01-R003

Eine Bestellung muss in einer einzigen Währung (BT-T01-9) angegeben werden.

fatal

PEPPOL-T01-R004

In einer Bestellzeile darf die Angabe der bestellten Menge (BT-T01-128) nicht negativ sein.

fatal

PEPPOL-T01-R005

Der Nettopreis (BT-T01-142) eines Bestellzeilen-Artikels darf keinen negativen Wert aufweisen.

fatal

PEPPOL-T01-R006

Der erwartete Gesamtzahlungsbetrag (BT-T01-125) darf keinen negativen Wert aufweisen.

fatal

PEPPOL-T01-R007

Die erwartete Gesamtsumme der Bestellzeilen-Menge (BT-T01-118) darf keinen negativen Wert aufweisen.

fatal

PEPPOL-T01-R008

Die erwartete Gesamtsumme der Bestellzeilen-Menge (BT-T01-118) muss gleich der erwarteten Gesamtzahlungshöhe (BT-T01-118) sein.

fatal

PEPPOL-T01-R009

Die erwartete Gesamtsumme der Rabatte auf Dokumenten-Ebene muss gleich der Summe der Rabatte auf Dokumenten-Ebene sein.

fatal

PEPPOL-T01-R010

Die erwartete Gesamtsumme der Kosten auf Dokumenten-Ebene muss gleich der Summe der Kosten auf Dokumenten-Ebene sein.

fatal

PEPPOL-T01-R011

Der erwartete Gesamtbetrag ohne Steuer = Erwartete Gesamtsumme der Beträge auf Zeilen-Ebene - Summe der Rabatte auf Dokumenten-Ebene + Summe der Kosten auf Dokumenten-Ebene.

fatal

PEPPOL-T01-R013

Jede Bestellzeile soll eine Bestellmenge haben.

warning

PEPPOL-T01-R014

Die Bestellung muss einen Namen des Bedarfsträgers der Bestellung oder eine Kennung aufweisen.

fatal

PEPPOL-T01-R016

Zahlungsbetrag = Gesamtrechnungsbetrag mit Steuern - Gezahlter Betrag + Rundungbetrag

fatal

PEPPOL-T01-R017

Erwarteter Gesamtbetrag mit Steuern = Erwarteter Gesamtbetrag ohne Steuern + Gesamt-Steuerbetrag der Bestellung

fatal

PEPPOL-T01-R019

Der Artikel-Netto-Preis muss gleich (Brutto-Preis - Rabatte) sein, wenn der Brutto-Preis angegeben ist.

fatal

PEPPOL-T01-R020

Freibetrags*-/ Kosten-Basis-Betrag muss angegeben sein, wenn Freibetrags-/ Kosten-Prozentsatz gegeben ist.

fatal

PEPPOL-T01-R021

Der Rabatt-/ Kosten-Prozentsatz muss angegeben sein, wenn der Rabatt-/ Kosten-Grundbetrag gegeben ist.

fatal

PEPPOL-T01-R022

Der Rabatt-/ Kostenbetrag muss gleich Grundbetrag * Prozentsatz/100 falls Grundbetrag und Prozentsatz existieren.

fatal

PEPPOL-T01-R023

Jeder Rabatt auf Dokumenten- oder Zeilen-Ebene muss einen Rabatt-Grund in Textform oder als Code haben.

fatal

PEPPOL-T01-R024

Der Bestellzeilen-Nettobetrag muss gleich (Bestellte Menge * (Artikel Nettopreis / Artikel Mengenpreis) + Bestellzeilen-Kostenbetrag - Bestellzeilen-Rabattbetrag sein.

fatal

PEPPOL-T01-R025

Der Grundbetrag muss eine positive Zahl über Null sein.

fatal

PEPPOL-T01-R026

Wenn unter TAX die Mehrwertsteuer gemeint ist, dann müssen die Mehrwehrsteuer-Kennungen in Übereinstimmung mit dem ISO code ISO 3166-1 alpha-2, mit dem das steuererhebende Land identifiziert wird, angegeben sein. Griechenland kann davon abweichend den Präfix "EL" verwenden.

fatal

PEPPOL-T01-R027

Der Artikel-Brutto-Preis darf nicht negativ sein.

fatal

PEPPOL-T01-R028

Elemente des Datentyps Amount (Betrag) dürfen nicht mehr als zwei Nach-Komma-Stellen haben. (Alle Beträge mit Ausnahme des Mengenpreises)

fatal

PEPPOL-T01-R029

Für jede Steuer-Art muss ein Prozentsatz angegeben sein, ausgenommen wenn die Bestellung steuerbefreit ist.

fatal

PEPPOL-T01-R030

Wenn der Code der TAX-Kategorie "Standard rated" (S) ist, dann muss TAX größer als Null sein.

fatal

PEPPOL-T01-R031

Eine Bestellprozess muss das Profil order only oder ordering nutzen.

fatal

PEPPOL-T01-R032

Rabattbeträge oder Kostenbeträge sollen nicht negativ sein.

fatal

PEPPOL-T01-R033

Freibetrag oder Kostenbetrag sollen nicht negativ sein.

fatal

PEPPOL-T01-R034

Die Kennung der Spezifikation (PEPPOL-T01-R034) soll mit dem Wert 'urn:fdc:peppol.eu:poacc:trns:order:3' beginnen.

fatal

8. Identifikatoren

8.1. Peppol

Peppol hat in der PEPPOL Policy for identifiers, policy 8 festgelegt, wie Identifikatoren auf Ebene der Transport-Infrastruktur als auch auf Nachrichten-Ebene zu verwenden sind. In dieser Richtlinie werden Prinzipien für alle in der Peppol-Umgebung eingesetzten Identifikatoren erläutert. Folgende Aspekte sind für die BIS von Relevanz:

8.2. XBestellung

Dem Konzept der Profilierung folgend sind für alle zur Spezifikation XBestellung konformen Dokumente die Identifikatoren der zugrundeliegenden Peppol-Spezifikation zu verwenden. Die Bildung eigener nationaler Dokumententypen und zugehöriger Identifikatoren in im Kontext dieses vorhaben nicht vorgesehen.

8.2.1. Profile und Nachrichten

Alle Nachrichten enthalten eine ProfileID und eine CustomizationID. Die ProfileID ordnet die Nachricht einem Geschäftsprozess zu und die CustomizationID legt fest, um welche Art von Nachricht es sich handelt und welche Regeln auf sie anzuwenden sind.

Profile sind einem Geschäftsprozess zugeordnet und können verschieden Arten von Dokumenten enthalten. Valide Dokumente sollen die dazugehörigen ProfileID und CustomizationID aufweisen.

Hinweis: Die CustomizationID ist ein string ohne Leerzeichen. Die unten stehende Liste weist Leerstellen in der CustomizationID auf, dies dient der besseren Lesbarkeit. Diese müssen vor einer Verwendung entfernt werden.

8.2.2. Anpassungs- und Profil-Identifikatoren

In der unten stehenden Tabelle sind Werte angegeben, welche für Beschreibung der Identifikatoren und der Art des Geschäftsprozesses für das Profil genutzt werden.

Typ Element cbc:CustomizationID Element cbc:ProfileID

Bestellung (Trdm01)

urn:fdc:peppol.eu:poacc:trns:order:3

urn:fdc:peppol.eu:poacc:bis:order_only:3

8.2.3. Namensraum

Der Ziel-Namensraum für die UBL2.1 Bestellung ist: urn:oasis:names:specification:ubl:schema:xsd:Order-2

Appendix A: Semantisches Datenmodell XBestellung

In diesem Abschnitt werden Informationselemente (Business Terms, kurz BTs) und Strukturen (Business Groups, kurz BGs) einer Bestellung beschrieben. Die Beschreibung der Informationselemente basiert auf der Profilierung des Peppol Order Transaction V3.1 (T01).

Bei der u. s. Tabelle handelt es sich um das aktuell Peppol Transaktionsmodell T01, welches zur weiteren Behandlung mit IDs ausgezeichnet wurde. Darstellungsform und Inhalte entsprechen nicht der geplanten Dareichung.
Table 5. Informationselemente XBestellung
ID Ebene Name Häufigkeit Beschreibung Datentyp / Codeliste Bemerkung

BG-T01-1

1

Order

1..1

BT-T01-1

2

Specification identification

1..1

Identifies the specification of content and rules that apply to the transaction.

Identifier

Beispiel-Wert: urn:fdc:peppol.eu:poacc:trns:order:3

BT-T01-2

2

Business process type identifier

1..1

Identifies the BII profile or business process context in which the transaction appears. Values to be used are either urn:fdc:peppol.eu:poacc:bis:order_only:3 or urn:fdc:peppol.eu:poacc:bis:ordering:3

Identifier

Beispiel-Wert: urn:fdc:peppol.eu:poacc:bis:order_only:3

BT-T01-3

2

Order identifier

1..1

A transaction instance must have an identifier. The identifier enables referencing the transaction for various purposes such as from other transactions that are part of the same process.

Identifier

Beispiel-Wert: 0-123

BT-T01-4

2

Sales order reference

0..1

An identifier of a referenced sales order, issued by the Seller.

Document Reference

Beispiel-Wert: 112233

BT-T01-5

2

Order issue date

1..1

The date on which the transaction instance was issued.

Date

Beispiel-Wert: 2018-06-01

BT-T01-6

2

Order issue time

0..1

The time assigned by the buyer on which the order was issued.

Time

Beispiel-Wert: 14:12:32

BT-T01-7

2

Consignment order indication

0..1

Indicates wether the order is a purchase order or consignement order. Default is purchase order.

CL: UNCL1001_T01

Beispiel-Wert: 220

BT-T01-8

2

Document level textual note

0..1

Free form text applying to the Order. This element may contain notes or any other similar information that is not contained explicitly in another structure.

Text

Beispiel-Wert: Packages of other sizes are OK

BT-T01-9

2

Currency

1..1

The default currency for the order.

Code, CL: ISO4217

Beispiel-Wert: NOK

BT-T01-10

2

Buyer contact

0..1

The element is used for the reference of who ordered the products/services. Example being the name of the person ordering, employee number or a code identifying this person or department/group. Also known as "Your reference", and should also be sent in the corresponding invoice.

Text

Beispiel-Wert: oik987

BT-T01-11

2

Buyers accounting string

0..1

Used by the buyer to specify a reference that should be repeated in e.g. invoice to enable the buyer to automatically book e.g. to the right project, or account.

text

Beispiel-Wert: 1234:45435:243234

BT-T01-12

2

Validity period

0..1

BT-T01-12_1

3

Order validity end date

1..1

The end date for when the order is valid. The end date for the time period within which the seller must respond. An order should contain the validity end date

Date

Beispiel-Wert: 2018-06-02

BT-T01-13

2

Quotation reference

0..1

Reference to quotation which is basis for the order

BT-T01-13_1

3

Quotation document reference

1..1

A requirement to give a unique reference to the quotation that is the base for the order.

Document reference

Beispiel-Wert: 1232424

BT-T01-14

2

Order reference

0..1

BT-T01-14_1

3

Order document reference

1..1

Used to reference the initial order that was rejected and a new order is issued.

Document reference

Beispiel-Wert: 4832423

BT-T01-15

2

Originator document

0..1

BT-T01-15_1

3

Originator document reference

1..1

A reference to Originator Document. To be able to give a reference to the internal requisition on the buyer site on which the order is based.

Document reference

Beispiel-Wert: 5435235

BG-T01-2

2

Additional documents

0..n

BT-T01-16

3

Document identifier

1..1

An identifier for the referenced document.

Beispiel-Wert: doc-34

BT-T01-17

3

Document description

0..1

Textual description of the document.

Text

Beispiel-Wert: Timesheet

BG-T01-3

3

Attachment(s)

0..1

BT-T01-18

4

Attached document

0..1

The attached document embeded as binary object, coded as Base64. The binary object has two supplementary components: a Mime Code, which specifies the Mime type of the attachment and a Filename that is provided by (or on behalf of) the sender of the document

Binary object

Beispiel-Wert: QklTIE9yZGVyIEFncmVlbWVudCAtIDQyQQ==

BT-T01-18_1

5

Attached document Mime code

1..1

The mime code of the attached document.

CL: MimeCode

Beispiel-Wert: application/vnd.openxmlformats-officedocument.spreadsheetml.sheet

BT-T01-18_2

5

Attached document filename

1..1

The file name of the attached document

Beispiel-Wert: Hours-spent.xsl

BT-T01-19

4

External reference

0..1

Reference to external document

BT-T01-19_1

5

External document URI

1..1

The Uniform Resource Identifier (URI) that identifies where the external document is located.

Text

Beispiel-Wert: http://www.test.eu/image.jpg

BT-T01-20

2

Contract information

0..1

Reference to contract

BT-T01-20_1

3

Reference identifier

1..1

Positive identification of the reference such as a unique identifier.

Document reference

BG-T01-4

2

Buyer information

1..1

Description of buyer

BG-T01-5

3

Party information

1..1

BT-T01-21

4

Buyer party electronic address

1..1

Identifies the buyer party’s electronic address

Identifier

Beispiel-Wert: 7300010000001

BT-T01-21_1

5

Scheme identifier

1..1

Scheme identifier for the electronic address

CL: eas

Beispiel-Wert: 0088

BT-T01-22

4

Party identification

0..1

BT-T01-22_1

5

Buyer party identification

1..1

An identification for the buyer party.

Beispiel-Wert: 7300010000001

BT-T01-22_2

6

Scheme identifier

0..1

Scheme identifier for party identification

CL: ICD

Beispiel-Wert: 0088

BT-T01-23

4

Party name

0..1

BT-T01-23_1

5

Buyer name

1..1

Name of buyer The name of the party who orders the listed items.

Text

Beispiel-Wert: Buyer name

BG-T01-6

4

Postal address

0..1

Postal address of the buyer

BT-T01-24

5

Address line 1

0..1

The main address line in a postal address usually the street name and number.

Text

BT-T01-25

5

Address line 2

0..1

An additional address line in a postal address that can be used to give further details supplementing the main line. Common use are secondary house number in a complex or in a building.

Text

BT-T01-26

5

City

0..1

The common name of the city where the postal address is. The name is written in full rather than as a code.

Text

BT-T01-27

5

Post code

0..1

The identifier for an addressable group of properties according to the relevant national postal service, such as a ZIP code or Post Code.

Text

BT-T01-28

5

Country subdivision

0..1

For specifying a region, county, state, province etc. within a country by using text.

Text

BT-T01-29

5

Address line

0..1

BT-T01-29_1

6

Address line 3

0..1

An additional address line in an address that can be used to give further details supplementing the main line.

Text

Beispiel-Wert: Gate 34

BT-T01-30

5

Country

1..1

BT-T01-30_1

6

Country code

1..1

A code that identifies the country.The lists of valid countries are registered with the ISO 3166-1 Maintenance agency, "Codes for the representation of names of countries and their subdivisions". Codes must be according to the alpha-2 representation.

Code, CL: ISO3166

Beispiel-Wert: NL

BG-T01-7

4

Buyer tax information

0..1

Buyer tax information

BT-T01-31

5

Buyer TAX identifier

1..1

The buyers registered Value Added Tax identifier. To be stated in case reverse charge is to apply to the purchase.

Identifier

BT-T01-32

5

Tax scheme

1..1

BT-T01-32_1

6

Tax scheme identifier

1..1

Mandatory element. E.g. "VAT" or "GST"

Identifier

Beispiel-Wert: VAT or GST

BG-T01-8

4

Buyer legal information

1..1

BT-T01-33

5

Buyers legal registration name

1..1

The official name of the party as registered with the relevant fiscal authority.

Text

BT-T01-34

5

Buyers legal registration identifier

0..1

Identifies a company as registered with the company registration scheme.

Identifier

Beispiel-Wert: 987654321

BT-T01-34_1

6

Scheme identifier

0..1

The identification scheme identifier of the buyer legal registration identifier.

CL: ICD

Beispiel-Wert: 0002

BG-T01-9

5

Legal address

0..1

BT-T01-35

6

Buyers legal registration address city name

0..1

Associates with the registered address of the party within a Corporate Registration Scheme. The name of a city, town, or village.

Text

BT-T01-36

6

Country

1..1

BT-T01-36_1

7

Country code

1..1

A code that identifies the country.The lists of valid countries are registered with the ISO 3166-1 Maintenance agency, "Codes for the representation of names of countries and their subdivisions". Codes must be according to the alpha-2 representation.

Code, CL: ISO3166

Beispiel-Wert: NL

BG-T01-10

4

Contact information

0..1

Buyer contact information

BT-T01-37

5

Contact person name

0..1

The name of the contact person.

Text

BT-T01-38

5

Contact telephone number

0..1

A phone number for the contact person. If the person has a direct number, this is that number.

Text

BT-T01-39

5

Contact email address

0..1

The e-mail address for the contact person. If the person has a direct e-mail this is that email.

Text

BG-T01-11

2

Seller information

1..1

Description of seller

BG-T01-12

3

Party information

1..1

BT-T01-40

4

Seller party electronic address

1..1

Identifies the seller party’s electronic address

Identifier

Beispiel-Wert: 7300010000001

BT-T01-40_1

5

Scheme identifier

1..1

Scheme identifier for the electronic address

CL: eas

Beispiel-Wert: 0088

BT-T01-41

4

Party identification

0..1

BT-T01-41_1

5

Seller party identification

1..1

Identifies a party.

Identifier

Beispiel-Wert: 7300010000001

BT-T01-41_2

6

Scheme identifier

0..1

Scheme identifier for party identification

CL: ICD

Beispiel-Wert: 0088

BT-T01-42

4

Party name

0..1

Name of seller

BT-T01-42_1

5

Seller party trading name

1..1

The trading name of the party.

Text

Beispiel-Wert: Seller name

BG-T01-13

4

Postal address

1..1

Postal address of the Seller

BT-T01-43

5

Address line 1

0..1

The main address line in a postal address usually the street name and number.

Text

BT-T01-44

5

Address line 2

0..1

An additional address line in a postal address that can be used to give further details supplementing the main line. Common use are secondary house number in a complex or in a building.

Text

BT-T01-45

5

City

0..1

The common name of the city where the postal address is. The name is written in full rather than as a code.

Text

BT-T01-46

5

Post code

0..1

The identifier for an addressable group of properties according to the relevant national postal service, such as a ZIP code or Post Code.

Text

BT-T01-47

5

Country subdivision

0..1

For specifying a region, county, state, province etc. within a country by using text.

Text

BT-T01-48

5

Address line

0..1

BT-T01-48_1

6

Address line 3

0..1

An additional address line in an address that can be used to give further details supplementing the main line.

Text

Beispiel-Wert: Gate 34

BT-T01-49

5

Country

1..1

BT-T01-49_1

6

Country code

1..1

A code that identifies the country.The lists of valid countries are registered with the ISO 3166-1 Maintenance agency, "Codes for the representation of names of countries and their subdivisions". Codes must be according to the alpha-2 representation.

Code, CL: ISO3166

Beispiel-Wert: NL

BG-T01-14

4

Seller legal information

1..1

BT-T01-50

5

Seller legal registration name

1..1

The official name of the party as registered with the relevant fiscal authority.

Text

BT-T01-51

5

Seller legal registration identifier

0..1

Identifies a company as registered with the company registration scheme.

Identifier

Beispiel-Wert: 987654321

BT-T01-51_1

6

Scheme identifier

0..1

The identification scheme identifier of the buyer legal registration identifier.

CL: ICD

Beispiel-Wert: 0002

BG-T01-15

5

Legal address

0..1

BT-T01-52

6

Sellers legal registration address city name

0..1

Associates with the registered address of the party within a Corporate Registration Scheme. The name of a city, town, or village.

Text

BT-T01-53

6

Country

1..1

BT-T01-53_1

7

Country code

1..1

A code that identifies the country.The lists of valid countries are registered with the ISO 3166-1 Maintenance agency, "Codes for the representation of names of countries and their subdivisions". Codes must be according to the alpha-2 representation.

Code, CL: ISO3166

Beispiel-Wert: NL

BG-T01-16

4

Contact

0..1

Seller contact information

BT-T01-54

5

Contact person name

0..1

The name of the contact person.

Text

BT-T01-55

5

Contact telephone number

0..1

A phone number for the contact person. If the person has a direct number, this is that number.

Text

BT-T01-56

5

Contact email address

0..1

The e-mail address for the contact person. If the person has a direct e-mail this is that email.

Text

BG-T01-17

2

Originator party

0..1

Information regarding the originator of the order

BG-T01-18

3

Party information

1..1

Description of the originator party

BT-T01-57

4

Party identification

0..1

Identification of the originator

BT-T01-57_1

5

Originator identifier

1..1

Identifies a party.

Identifier

Beispiel-Wert: 7300010000001

BT-T01-57_2

6

Scheme identifier

0..1

Scheme identifier for party identification

CL: ICD

Beispiel-Wert: 0088

BT-T01-58

4

Party name

0..1

Name of the originator

BT-T01-58_1

5

Originator name

1..1

The name of the party.

Text

Beispiel-Wert: Originator name

BG-T01-19

4

Contact

0..1

The originators contact information

BT-T01-59

5

Contact person name

0..1

The name of the contact person.

Text

BT-T01-60

5

Contact telephone number

0..1

A phone number for the contact person. If the person has a direct number, this is that number.

Text

BT-T01-61

5

Contact email address

0..1

The e-mail address for the contact person. If the person has a direct e-mail this is that email.

Text

BG-T01-20

2

Invoicee party

0..1

Information regarding the receiver of the invoice based on the order (Invoicee)

BG-T01-21

3

Party information

1..1

Description of the invoicee party

BT-T01-62

4

Invoicee party electronic address

0..1

Identifies the invoicee party’s electronic address

Identifier

Beispiel-Wert: 7300010000001

BT-T01-62_1

5

Scheme identifier

1..1

Scheme identifier for the electronic address

CL: eas

Beispiel-Wert: 0088

BT-T01-63

4

Party identification

0..1

Identification of the invoicee party

BT-T01-63_1

5

Invoicee identifier

1..1

An identifer for the invoicee party.

Identifier

Beispiel-Wert: 7300010000001

BT-T01-63_2

6

Scheme identifier

0..1

Scheme identifier for party identification

CL: ICD

Beispiel-Wert: 0088

BT-T01-64

4

Party name

0..1

BT-T01-64_1

5

Invoicee name

1..1

The name of the party who should be invoiced for the ordered items (invoicee).

Text

Beispiel-Wert: Invoicee name

BG-T01-22

4

Postal address

1..1

Postal address of the invoicee

BT-T01-65

5

Address line 1

0..1

The main address line in a postal address usually the street name and number.

Text

Beispiel-Wert: The main address line in the postal address, usually the street name and number

BT-T01-66

5

Address line 2

0..1

An additional address line in a postal address that can be used to give further details supplementing the main line. Common use are secondary house number in a complex or in a building.

Text

BT-T01-67

5

City

0..1

The common name of the city where the postal address is. The name is written in full rather than as a code.

Text

BT-T01-68

5

Post code

0..1

The identifier for an addressable group of properties according to the relevant national postal service, such as a ZIP code or Post Code.

Text

BT-T01-69

5

Country subdivision

0..1

For specifying a region, county, state, province etc. within a country by using text.

Text

BT-T01-70

5

Address line

0..1

BT-T01-70_1

6

Address line 3

0..1

An additional address line in an address that can be used to give further details supplementing the main line.

Text

Beispiel-Wert: Gate 34

BT-T01-71

5

Country

1..1

BT-T01-71_1

6

Country code

1..1

A code that identifies the country.The lists of valid countries are registered with the ISO 3166-1 Maintenance agency, "Codes for the representation of names of countries and their subdivisions". Codes must be according to the alpha-2 representation.

Code, CL: ISO3166

Beispiel-Wert: NL

BG-T01-23

4

Party tax scheme

0..1

Tax information of the invoicee party

BT-T01-72

5

Invoicee TAX identifier

1..1

The invoicees registered Value Added Tax identifier

Identifier

BT-T01-73

5

Tax scheme

1..1

BT-T01-73_1

6

Tax scheme identifier

1..1

Tax scheme identifier. E.g. "VAT" or "GST"

Identifier

Beispiel-Wert: VAT or GST

BG-T01-24

4

Party legal entity

1..1

Legal information of the invoicee party

BT-T01-74

5

Invoicee’s Legal registration name

1..1

The official name of the invoicee party as registered with the relevant fiscal authority.

Text

BT-T01-75

5

Company identifier

0..1

Identifies a company as registered with the company registration scheme.

Identifier

Beispiel-Wert: 987654321

BT-T01-75_1

6

Buyer legal registration identifier identification scheme identifier

0..1

The identification scheme identifier of the buyer legal registration identifier.

CL: ICD

Beispiel-Wert: 0002

BG-T01-25

5

Legal registration address

0..1

BT-T01-76

6

City name

0..1

Associates with the registered address of the party within a Corporate Registration Scheme. The name of a city, town, or village.

Text

BT-T01-77

6

Country

1..1

BT-T01-77_1

7

Country code

1..1

A code that identifies the country.The lists of valid countries are registered with the ISO 3166-1 Maintenance agency, "Codes for the representation of names of countries and their subdivisions". Codes must be according to the alpha-2 representation.

Code, CL: ISO3166

Beispiel-Wert: NL

BG-T01-26

4

Contact

0..1

Invoicee contact information

BT-T01-78

5

Contact person name

0..1

The name of the contact person.

Text

BT-T01-79

5

Contact telephone number

0..1

A phone number for the contact person. If the person has a direct number, this is that number.

Text

BT-T01-80

5

Contact email address

0..1

The e-mail address for the contact person. If the person has a direct e-mail this is that email.

Text

BG-T01-27

2

Delivery information

0..1

BG-T01-28

3

Delivery location

0..1

BT-T01-81

4

Delivery location ID

0..1

An identifer for the location to where the ordered items should be delivered.

Identifier

Beispiel-Wert: 7300010000001

BT-T01-81_1

5

Deliver to location identifier identification scheme identifier

0..1

The identification scheme identifier of the Deliver to location identifier.

CL: ICD

Beispiel-Wert: 0088

BT-T01-82

4

Delivery location name

0..1

A name of the location to where the ordered items should be delivered.

Text

Beispiel-Wert: South side goods arrival dock

BG-T01-29

4

Delivery address

1..1

BT-T01-83

5

Address line 1

0..1

The main address line in a postal address usually the street name and number.

Text

BT-T01-84

5

Address line 2

0..1

An additional address line in a postal address that can be used to give further details supplementing the main line. Common use are secondary house number in a complex or in a building.

Text

BT-T01-85

5

City

0..1

The common name of the city where the postal address is. The name is written in full rather than as a code.

Text

BT-T01-86

5

Post code

0..1

The identifier for an addressable group of properties according to the relevant national postal service, such as a ZIP code or Post Code.

Text

BT-T01-87

5

Country subdivision

0..1

For specifying a region, county, state, province etc. within a country by using text.

Text

BT-T01-88

5

Address line

0..1

BT-T01-88_1

6

Address line 3

1..1

An additional address line in an address that can be used to give further details supplementing the main line.

Text

Beispiel-Wert: Gate 34

BT-T01-89

5

Country

1..1

BT-T01-89_1

6

Country code

1..1

A code that identifies the country.The lists of valid countries are registered with the ISO 3166-1 Maintenance agency, "Codes for the representation of names of countries and their subdivisions". Codes must be according to the alpha-2 representation.

Code, CL: ISO3166

Beispiel-Wert: NL

BG-T01-30

3

Requested delivery period

0..1

BT-T01-90

4

Period start date

0..1

The date on which the period starts. The start dates counts as part of the period.Format ="YYYY-MM-DD"

Date

BT-T01-91

4

Period end date

0..1

The date on which the period ends. The end date counts as part of the period.Format ="YYYY-MM-DD"

Date

BG-T01-31

3

Delivery party

0..1

BT-T01-92

4

Party identification

0..1

Identification of the delivery party. The party to whom the goods are delivered

BT-T01-92_1

5

Delivery party identifier

1..1

In this BIS: The identifier of the party that should receive the ordered items

Beispiel-Wert: 987654321

BT-T01-92_2

6

Deliver party registration identifier identification scheme identifier

0..1

The identification scheme identifier of the deliverparty identifier.

CL: ICD

Beispiel-Wert: 0002

BT-T01-93

4

Party name

1..1

BT-T01-93_1

5

Delivery party name

1..1

In this BIS: The name of the party that should receive the delivery

Text

Beispiel-Wert: Surgery department

BG-T01-32

4

Contact information

0..1

Contact information for the delivery party

BT-T01-94

5

Contact person name

0..1

The name of the contact person.

Text

BT-T01-95

5

Contact telephone number

0..1

A phone number for the contact person. If the person has a direct number, this is that number.

Text

BT-T01-96

5

Contact email address

0..1

The e-mail address for the contact person. If the person has a direct e-mail this is that email.

Text

BG-T01-33

4

Final Delivery address

0..1

The final address for the delivery

BT-T01-97

5

Address line 1

0..1

The main address line in a postal address usually the street name and number.

Text

BT-T01-98

5

Address line 2

0..1

An additional address line in a postal address that can be used to give further details supplementing the main line. Common use are secondary house number in a complex or in a building.

Text

BT-T01-99

5

City

0..1

The common name of the city where the postal address is. The name is written in full rather than as a code.

Text

BT-T01-100

5

Post code

0..1

The identifier for an addressable group of properties according to the relevant national postal service, such as a ZIP code or Post Code.

Text

BT-T01-101

5

Country subdivision

0..1

For specifying a region, county, state, province etc. within a country by using text.

Text

BT-T01-102

5

Address line

0..1

BT-T01-102_1

6

Address line 3

1..1

An additional address line in an address that can be used to give further details supplementing the main line.

Text

Beispiel-Wert: Gate 34

BT-T01-103

5

Country

1..1

BT-T01-103_1

6

Country code

1..1

A code that identifies the country.The lists of valid countries are registered with the ISO 3166-1 Maintenance agency, "Codes for the representation of names of countries and their subdivisions". Codes must be according to the alpha-2 representation.

Code, CL: ISO3166

Beispiel-Wert: NL

BG-T01-34

2

Terms of delivery

0..1

BT-T01-104

3

Delivery terms identifier

0..1

Delivery terms identifier, normally Incoterms

Text

Beispiel-Wert: FOB

BT-T01-105

3

Delivery special terms

0..1

A description of special conditions relating to the Delivery Terms.

Text

BT-T01-106

3

Delivery location information

0..1

BT-T01-106_1

4

Delivery terms location

1..1

The location to which the delivery terms refer. Used to qualify the delivery terms e.g. "Terms of delivery are FOB Rotterdam"

Text

Beispiel-Wert: Rotterdam

BT-T01-107

2

Payment terms

0..1

BT-T01-107_1

3

Payment terms

1..1

Payment terms for the order described in text

Text

BG-T01-35

2

Allowance and charge information

0..n

Allowances and charges for the order

BT-T01-108

3

AllowanceChargeIndicator

1..1

Indicator used to state if the following is an allowance or charge. true = Charge, false = Allowance

Boolean, CL: TrueFalse

Beispiel-Wert: false

BT-T01-109

3

Document level allowance or charge reason code

0..1

The reason for the document level allowance or charge, expressed as a code. For allowances a subset of codelist UNCL5189 is to be used, and for charges codelist UNCL7161 applies. The Document level allowance reason code and the Document level allowance reason shall indicate the same allowance reason

Code, CL: UNCL5189 UNCL7161

Beispiel-Wert: 95

BT-T01-110

3

Allowance and charges reason

1..1

A textual reason for the allowance or the charge. Can also be its name. The Document level allowance reason code and the Document level allowance reason shall indicate the same allowance reason

Text

BT-T01-111

3

Document level allowance or charge percentage

0..1

The percentage that may be used, in conjunction with the document level allowance base amount, to calculate the document level allowance or charge amount. To state 20%, use value 20.

Percentage

Beispiel-Wert: 20

BT-T01-112

3

Allowance and charge amount

1..1

The net amount of the allowance or the charge exluding TAX.

Amount

Beispiel-Wert: 200

BT-T01-112_1

4

Currency identifier

1..1

Currency identifier, value must be the same as what is used in tir01-007, DocumentCurrencyCode.

CL: ISO4217

Beispiel-Wert: EUR

BT-T01-113

3

Document level allowance or charge base amount

0..1

The base amount that may be used, in conjunction with the document level allowance or charge percentage, to calculate the document level allowance or charge amount. Must be rounded to maximum 2 decimals

Amount

Beispiel-Wert: 1000

BT-T01-113_1

4

Currency identifier

1..1

Currency identifier, value must be the same as what is used in tir01-007, DocumentCurrencyCode.

CL: ISO4217

Beispiel-Wert: EUR

BG-T01-36

3

Tax category

0..1

BT-T01-114

4

TAX category code

1..1

The TAX category code that applies to the document level allowance or charge.

Code, CL: UNCL5305

Beispiel-Wert: S

BT-T01-115

4

TAX rate

0..1

The TAX rate, represented as percentage that applies to the document level allowance or charge. As this element is of data type percentage, please note that no %-sign should be used. To state 25 %, use value 25.00

Percentage

Beispiel-Wert: 25.00

BT-T01-116

4

Tax scheme information

1..1

BT-T01-116_1

5

Tax scheme identifier

1..1

Tax scheme identifier. E.g. “VAT” or “GST”

Identifier

Beispiel-Wert: VAT or GST

BT-T01-117

2

Tax total

0..1

Specification of expected tax amount

BT-T01-117_1

3

TAX total amount

1..1

The total TAX amount that is "added to the document total w/o TAX". This is the sum of all TAX subcategory amounts. The expected Tax Total in the corresponding invoice.

Amount

Beispiel-Wert: 200

BT-T01-117_2

4

Currency identifier

1..1

Currency identifier, value must be the same as what is used in tir01-007, DocumentCurrencyCode.

CL: ISO4217

Beispiel-Wert: EUR

BG-T01-37

2

Anticipated monetary total

0..1

Estimated total amounts for the order

BT-T01-118

3

Sum of line amounts

1..1

Sum of line amounts in the document.The total of Line Extension Amounts net of tax and settlement discounts. Must be rounded to maximum 2 decimals.

Amount

Beispiel-Wert: 200

BT-T01-118_1

4

Currency identifier

1..1

Currency identifier, value must be the same as what is used in tir01-007, DocumentCurrencyCode.

CL: ISO4217

Beispiel-Wert: EUR

BT-T01-119

3

Document total without TAX

0..1

The "Sum of line amounts" plus "sum of allowances on document level" plus "sum of charges on document level". Must be rounded to maximum 2 decimals.

Amount

Beispiel-Wert: 200

BT-T01-119_1

4

Currency identifier

1..1

Currency identifier, value must be the same as what is used in tir01-007, DocumentCurrencyCode.

CL: ISO4217

Beispiel-Wert: EUR

BT-T01-120

3

Document total including TAX

0..1

The total value including TAX. Must be rounded to maximum 2 decimals.

Amount

Beispiel-Wert: 200

BT-T01-120_1

4

Currency identifier

1..1

Currency identifier, value must be the same as what is used in tir01-007, DocumentCurrencyCode.

CL: ISO4217

Beispiel-Wert: EUR

BT-T01-121

3

Sum of allowances on document level

0..1

Sum of all allowances on header level in the document. Allowances on line level are included in the line amount and summed up into the "sum of line amounts". Must be rounded to maximum 2 decimals.

Amount

Beispiel-Wert: 200

BT-T01-121_1

4

Currency identifier

1..1

Currency identifier, value must be the same as what is used in tir01-007, DocumentCurrencyCode.

CL: ISO4217

Beispiel-Wert: EUR

BT-T01-122

3

Sum of charges on document level

0..1

Sum of all charge on header level in the document. Charges on line level are included in the line amount and summed up into the "sum of line amounts". Must be rounded to maximum 2 decimals.

Amount

Beispiel-Wert: 200

BT-T01-122_1

4

Currency identifier

1..1

Currency identifier, value must be the same as what is used in tir01-007, DocumentCurrencyCode.

CL: ISO4217

Beispiel-Wert: EUR

BT-T01-123

3

Prepaid amounts

0..1

Any amounts that have been paid a-priory. Must be rounded to maximum 2 decimals.

Beispiel-Wert: 200

BT-T01-123_1

4

Currency identifier

1..1

Currency identifier, value must be the same as what is used in tir01-007, DocumentCurrencyCode.

CL: ISO4217

Beispiel-Wert: EUR

BT-T01-124

3

Rounding of document total

0..1

The amount to be added to the total to round the amount to be paid. Must be rounded to maximum 2 decimals.

Amount

Beispiel-Wert: 200

BT-T01-124_1

4

Currency identifier

1..1

Currency identifier, value must be the same as what is used in tir01-007, DocumentCurrencyCode.

CL: ISO4217

Beispiel-Wert: EUR

BT-T01-125

3

Payable amount

1..1

The amount that is expected to be paid. Must be rounded to maximum 2 decimals.

Amount

Beispiel-Wert: 200

BT-T01-125_1

4

Currency identifier

1..1

Currency identifier, value must be the same as what is used in tir01-007, DocumentCurrencyCode.

CL: ISO4217

Beispiel-Wert: EUR

BG-T01-38

2

Order line

1..n

Specification of order lines

BT-T01-126

3

Order line note

0..1

Free-form text applying to the Order Line. This element may contain notes or any other similar information that is not contained explicitly in another structure. Is to capture any free form description related to the order line as a whole.

Text

BG-T01-39

3

Line item

1..1

Description of line item

BT-T01-127

4

Line item identifier

1..1

Identifies the Line Item assigned by the buyer, the identifier must be unique within the order.

Identifier

Beispiel-Wert: 1

BT-T01-128

4

Ordered quantity

1..1

The quantity of Items for the Line Item. The quantity for the order line.

Quantity

Beispiel-Wert: 10

BT-T01-128_1

5

Ordered quantity unit of measure

1..1

The unit of measure that applies to the ordered quantity.

Code, CL: UNECERec20

Beispiel-Wert: C62

BT-T01-129

4

Order line amount

0..1

The total amount for the Line Item, including Allowance Charges but net of taxes. The expected line amount excluding TAX but inclusive of other charges, allowances and taxes.

Amount

Beispiel-Wert: 200

BT-T01-129_1

5

Currency identifier

1..1

Currency identifier, value must be the same as what is used in tir01-007, DocumentCurrencyCode.

CL: ISO4217

Beispiel-Wert: EUR

BT-T01-130

4

Partial delivery indicator

0..1

Indicates if the line items must be delivered in a single shipment. Default is that partial delivery is allowed (true)

Boolean, CL: TrueFalse

Default-Wert: true

BT-T01-131

4

Buyers accounting string

0..1

The buyer’s accounting information applied to the Line Item, expressed as text.

Text

BG-T01-40

4

Line delivery information

0..1

Delivery information for the order line

BG-T01-41

5

Order line requested delivery period

1..1

Requested delivery period for the order line

BT-T01-132

6

Period start date

0..1

The date on which the period starts. The start dates counts as part of the period. Format ="YYYY-MM-DD"

Date

Beispiel-Wert: 2018-09-03

BT-T01-133

6

Period end date

0..1

The date on which the period ends. The end date counts as part of the period.Format ="YYYY-MM-DD"

Date

Beispiel-Wert: 2018-09-15

BG-T01-42

4

Originator information

0..1

Information regarding the originator of the order line

BT-T01-134

5

Party identification

0..1

Identification of the originator

BT-T01-134_1

6

Order line originator party ID

1..1

The party who originated Order.

Beispiel-Wert: 7300010000001

BT-T01-134_2

7

Scheme identifier

0..1

Scheme identifier for party identification

CL: ICD

Beispiel-Wert: 0088

BT-T01-135

5

Party name

0..1

Name of the originator

BT-T01-135_1

6

Order line originator party name

1..1

The party who originated Order.

Text

Beispiel-Wert: Originator name

BG-T01-43

4

Order line allowance and charges

0..n

A group of business terms providing information about allowances or charges applicable to the individual order line.

BT-T01-136

5

ChargeIndicator

1..1

Use “true” when informing about Charges and “false” when informing about Allowances

Beispiel-Wert: false

BT-T01-137

5

Line level allowance or charge reason code

0..1

The reason for the line level allowance or charge, expressed as a code. For allowances a subset of codelist UNCL5189 is to be used, and for charges codelist UNCL7161 applies. The Document level allowance reason code and the Document level allowance reason shall indicate the same allowance reason

Code, CL: UNCL5189 UNCL7161

Beispiel-Wert: 95

BT-T01-138

5

Line level allowance or charge reason

0..1

The reason for the line level allowance or charge, expressed as text. The Document level allowance reason code and the Document level allowance reason shall indicate the same allowance reason

Text

Beispiel-Wert: Discount

BT-T01-139

5

Line level allowance or charge percentage

0..1

The percentage that may be used, in conjunction with the line level allowance base amount, to calculate the line level allowance or charge amount.

Percentage

Beispiel-Wert: 20

BT-T01-140

5

Line level allowance or charge amount

1..1

The amount of an allowance or a charge, without TAX. Must be rounded to maximum 2 decimals

Amount

Beispiel-Wert: 200

BT-T01-140_1

6

Currency identifier

1..1

Currency identifier, value must be the same as what is used in tir01-007, DocumentCurrencyCode.

CL: ISO4217

Beispiel-Wert: EUR

BT-T01-141

5

Line level allowance or charge base amount

0..1

The base amount that may be used, in conjunction with the line level allowance or charge percentage, to calculate the line level allowance or charge amount. Must be rounded to maximum 2 decimals

Amount

Beispiel-Wert: 1000

BT-T01-141_1

6

Currency identifier

1..1

Currency identifier, value must be the same as what is used in tir01-007, DocumentCurrencyCode.

CL: ISO4217

Beispiel-Wert: EUR

BG-T01-44

4

Price information

0..1

BT-T01-142

5

Item price

1..1

The net price of the item including all allowances, charges and taxes but exluding TAX. Although price is an optional element in an order it recommended as best practice to either state the price or provide reference to an appropriate source from which the price can be identified such as a contract, catalogue or a quote.

Price amount

Beispiel-Wert: 211.124

BT-T01-142_1

6

Currency identifier

1..1

Currency identifier, value must be the same as what is used in tir01-007, DocumentCurrencyCode.

CL: ISO4217

Beispiel-Wert: EUR

BT-T01-143

5

Item price base quantity

0..1

The actual quantity to which the price applies.

Default-Wert: 1

BT-T01-143_1

6

Base quantity unit of measure

0..1

The unit of measure that applies to the base quantity.

Code, CL: UNECERec20

Beispiel-Wert: C62

BG-T01-45

5

Price discount information

0..1

Information on discounts connected to the price

BT-T01-144

6

AllowanceChargeIndicator

1..1

Only discounts are allowed for the price, hence the only valid value is false (meaning an allowance)

Boolean

Fixed-Wert: false

BT-T01-145

6

Discount amount

1..1

Discount amount connected to the price

Price amount

Beispiel-Wert: 200

BT-T01-145_1

7

Currency identifier

1..1

Currency identifier, value must be the same as what is used in tir01-007, DocumentCurrencyCode.

CL: ISO4217

Beispiel-Wert: EUR

BT-T01-146

6

Item list price

0..1

The gross price of the item before subtracting discounts. E.g. list price.

Price amount

Beispiel-Wert: 200

BT-T01-146_1

7

Currency identifier

1..1

Currency identifier, value must be the same as what is used in tir01-007, DocumentCurrencyCode.

CL: ISO4217

Beispiel-Wert: EUR

BG-T01-46

4

Item information

1..1

BT-T01-147

5

Item description

0..1

Free-form field that can be used to give a text description of the item. A detailed description of the item.

Text

BT-T01-148

5

Item name

1..1

A short name for an item. A short name given to an item, such as a name from a Catalogue, as distinct from a description.

Text

BT-T01-149

5

Buyers item identification

0..1

BT-T01-149_1

6

Buyers item identifier

1..1

An identifier, assigned by the buyer, for the item. Associates the item with its identification according to the buyer’s system.

Identifier

Beispiel-Wert: abc32432

BT-T01-150

5

Sellers item identification

0..1

BT-T01-150_1

6

The Sellers item identifier

1..1

An identifier, assigned by the seller, for the item. Associates the item with its identification according to the seller’s system.

Identifier

Beispiel-Wert: 3249834

BT-T01-151

5

Standard item identification

0..1

BT-T01-151_1

6

Item standard identifier

1..1

An item identifier based on a registered scheme. Associates the item with its identification according to a standard system.

Identifier

Beispiel-Wert: 05704066204093

BT-T01-151_2

7

Item standard identifier identification scheme identifier

1..1

The identification scheme identifier of the Item standard identifier

CL: ICD

Beispiel-Wert: 0160

BT-T01-152

5

Item specification reference

0..n

Referece to an item specification document

BT-T01-152_1

6

Document reference identifier

1..1

Reference to an external document (ID) when it is necessary to specify the details of the item.

Document reference

Beispiel-Wert: doc4353.pdf

BT-T01-153

5

Commodity classification information

0..n

BT-T01-153_1

6

Item classification code

0..1

A code for classifying the item by its type or nature. Classification codes are used to allow grouping of similar items for a various purposes e.g. public procurement (CPV), e-Commerce (UNSPSC) etc.

Code

Beispiel-Wert: 9873242

BT-T01-153_2

7

Item classification identifier identification scheme identifier

1..1

The identification scheme identifier of the Item classification identifier

CL: UNCL7143

Beispiel-Wert: STI

BT-T01-153_3

7

Item classification identifier version identification scheme identifier

0..1

The identification scheme version identifier of the Item classification identifier

Beispiel-Wert: 20.0602

BT-T01-153_4

7

Clear text name equivalent of classification code

0..1

The textual equivalent of the code value

Beispiel-Wert: Office furniture

BG-T01-47

5

Line TAX information

0..1

BT-T01-154

6

Item TAX category code

1..1

The TAX category code for the item.

Code, CL: UNCL5305

Beispiel-Wert: S

BT-T01-155

6

Line TAX rate

0..1

The TAX percentage rate that applies to the line amount.

Percentage

Beispiel-Wert: 25

BT-T01-156

6

Tax scheme information

1..1

BT-T01-156_1

7

Tax scheme identifier

1..1

Tax scheme. E.g. “VAT” or “GST”

Identifier

Beispiel-Wert: VAT or GST

BG-T01-48

5

Additional item property information

0..n

A group of business terms providing information about properties of the goods and services invoiced.

BT-T01-157

6

Item property name

1..1

The name of the property.The name must be sufficiently descriptive to define the value. The definition may be supplemented with the property unit of measure when relevant.

Text

Beispiel-Wert: Color

BT-T01-158

6

Item property code

0..1

Code for the item property according to a property code system.

Code

BT-T01-158_1

7

Name code list id.

1..1

An identifier for the code list used for the Name code, this is bilaterally agreed

BT-T01-159

6

Item property value

1..1

The value of the item property.

Text

Beispiel-Wert: Red

BT-T01-160

6

Item property unit of measure

0..1

The unit of measure in which the property value is stated, if relevant. May not be relevant when properties are descriptive.

Quantity

Beispiel-Wert: 10

BT-T01-160_1

7

Value quantity unit of measure

1..1

The unit of measure that applies to the value quantity.

Code, CL: UNECERec20

Beispiel-Wert: C62

BT-T01-161

6

Property classification

0..1

Standardized and predefined classification of items properties.

Text

BG-T01-49

5

Item instance information

0..n

Information relevant to an item instance or shared by the items in the order line.

BT-T01-162

6

Item serial identification

0..1

An identifier that is specific to the items in the order line.

BT-T01-163

6

Item lot information

0..1

Information about the production lot which the order line items come from.

BT-T01-163_1

7

Item lot identifier

0..1

An identifier for the production lot which the order line items come from.

Appendix B: Codelisten

Übersicht der über die Peppol-Spezifikation betriebenen und veröffentichten Codelisten.

  1. Action code (UNCL1229)

  2. Allowance reason codes (UNCL5189 subset)

  3. Application Response type code (UNCL4343 Subset)

  4. Boolean indicator (openPEPPOL)

  5. Catalogue Action code, header level (openPEPPOL)

  6. Catalogue Action code, line level (openPEPPOL)

  7. Charge reason code (UNCL7161)

  8. Clarification list identifier (openPEPPOL)

  9. Country codes (ISO 3166-1:Alpha2)

  10. Currency codes (ISO 4217)

  11. Dangerous goods regulations code (UNCL8273)

  12. Document name code, full list (UNCL1001)

  13. Duty or tax or fee category code (UNCL5305)

  14. Electronic Address Scheme (EAS)

  15. Image code (openPEPPOL)

  16. Invoice status code (UNCL4343 Subset)

  17. ISO 6523 ICD list

  18. Item type identification code (UNCL7143)

  19. Measured attribute code (UNCL6313)

  20. Measured attribute code for despatch advice (UNCL6313 Subset)

  21. Mime code (IANA Subset)

  22. Order Response type code (UNCL4343 Subset)

  23. Order type code (UNCL1001 subset)

  24. Packaging level code (GS1 7009)

  25. Price type codes (UNCL5387)

  26. Recommandation 20, including Recommondation 21 codes - prefixed with X (UN/ECE)

  27. Recommandation 21 (UN/ECE)

  28. Status Clarification Action (OpenPEPPOL)

  29. Status Clarification Reason (OpenPEPPOL)

  30. Status reason code (openPEPPOL)

hier könnte die Bereitstellung der Codelisten über die KoSIT und die Platform XRepository beschrieben werden.
1. siehe hierzu Abschnitt 2.1. Profilierung und Konformität
2. Der Begriff "konform" wird hier synonym zum Begriff "compliant" aus der Norm EN16931 zur elektronischen Rechnung verwendet