1Lieferschein Standard Standard
Die Initiative 1Lieferschein gibt einen Standard für digitale Lieferscheine vor. Der Standard verwendet etablierte internationale Standards zur Abbildung von Belegen zu Geschäftsvorfällen und gestaltet innovative Standards aus existierenden Komponenten für Kommunikation und Transport der Daten.
Die Datenhoheit für jeden einzelnen Datensatz liegt ausschließlich bei den an diesem einen Logistikprozess beteiligten Geschäftspartnern.
Die uneingeschränkt freie Verfügbarkeit der Standards und Komponenten ist ein Kriterium für deren Auswahl. Alle Ergänzungen und Änderungen folgen dieser Vorgabe.
1Lieferschein Standard
Der Austausch von Lieferscheinen ist im deutschsprachigen Raum bisher ein papiergetriebener Prozess. Erstellung, Weitergabe, Übergabe beim Empfang, Bestätigung gegenüber den Lieferanten, Transport ins Büro und dort sorgfältige Aufbewahrung mit Prüfung und regelkonformer Archivierung von Lieferscheinen kann nur mit hohem zeitlichen und personellen Aufwand erfolgen.
1Lieferschein bildet eine nachvollziehbare Kette strukturierter Daten aller Prozessschritte in der Logistik ab. Jegliche transportierte Gegenstände, verwendete Transportmittel und erbrachte Leistungen können mit 1Lieferschein dokumentiert werden.
Der digitale Lieferschein ist eine „kleine Revolution”. Er beruht auf disruptiven, aber erprobten, Technologien und verwendet internationale Standards. Das zugrunde liegende Datenformat wird in anderen Ländern (z.B. Skandinavien, Südamerika) bereits sehr häufig verwendet.
Die Übertragungsverfahren setzen auf bewährte und neue Internet-Standards. Bei Bedarf kann auch über Blockchain übertragen werden.
1Lieferschein Standard Mitmachen!
Der Standard entsteht mit dem Ziel, als RFC (Request for Comments) veröffentlicht zu werden. „Work in progress” mit der dringenden Bitte um Feedback unter:
1Lieferschein Standard
1Lieferschein Standard
Abstract
The 1Lieferschein initiative provides a standard for digital despatch advices. 1Lieferschein uses established international standards for mapping documents and data to business transactions and thus designs innovative standards from existing components for communication and transport of data. The data sovereignty for each individual data record lies exclusively with the business partners involved in this logistics process. The unrestricted free availability of the standards and components is a criterion for their selection. All additions and changes follow this specification.
Introduction
Up to now, the exchange of dispatch advices has been a paper-driven process in German-speaking countries. Creation, forwarding, handover at receipt, confirmation to suppliers, transport to the office and careful storage with checking and archiving of despatch advices in accordance with the rules can only be done with a high time expenditure. The 1Lieferschein initiative provides a standard for digital despatch advices. It uses established international standards for mapping documents to business transactions and designs innovative standards from existing components for communication and transport of data. It is to be stressed that the data sovereignty for each individual data record lies exclusively with the business partners involved in this logistics process. The unrestricted free availability of the standards and components is a criterion for their selection. All additions and changes follow this specification.
Use of 1Lieferschein
1Lieferschein are simple XML documents in UBL format: The supplier sends a 1Lieferschein „DespatchAdvice“ to the recipient, followed by a confirmed 1Lieferschein „ReceiptAdvice“ to the supplier. For the automatic receipt of the 1Lieferschein at the receiving company, only the corresponding DNS entries have to be set via DTRANS. Sending and receiving can also be done as an e-mail attachment. The handover on the construction site between two smartphones takes place via NFC for Android and the iOS alternatives. E-mail attachments can also be used here. Therefore, complex delivery and transport chains, with route deliveries, logistics subcontractors and changing means of transport are mapped and all participants are automatically informed.
The 1Lieferschein standard
Within 1Lieferschein a certain structure based on the UBL-syntax is used. The UBL-syntax is already spread by its use in the invoice standard XRechnung. This structure allows the user to fill the despatch advice with a variety of data. A brief overview of this structure is provided below. Although most elements are optional, there are some elements that are mandatory to use in in 1Lieferschein (also required by XML-format and UBL-syntax, respectively), i.e., the XML-declaration and the used UBL-scheme. Beyond these, the use of the following elements are to be used:
XML-Version | An XML declaration gives the program running your page instructions. |
DocumentType | Specifies the used UBL-scheme (in case of an 1Lieferschein the scheme “despatch advice” has to be used.) |
UBL-Version | Specifies the earliest version of the UBL schema for this document type, which defines all elements that can occur in the current instance. |
CustomizationID | An identification of the specification that contains the entire set of rules regarding semantic content, cardinalities, and business rules to which the data contained in the instance document corresponds. |
ProfileID | Identifies a user-defined profile of the UBL fitting used. |
ID | An identifier for this document assigned by the sender. |
IssueDate | The date, assigned by the sender, on which this document was issued. |
DespatchAdviceTypeCode | A code signifying the type of the Despatch Advice. |
OrderReference | A reference to the order containing the referenced order line. |
CustomerReference | Text used for tagging purchasing card transactions. |
DespatchSupplierParty | Information on the despatch party, e.g., the address |
DeliveryCustomerParty | Information on the delivery recipient,e.g., the address |
Delivery | A class to describe a delivery, e.g., the delivered item, delivery specifications |
Please note that information on multiple parties that are involved in the delivery process, can be added, e.g.,
- the buyer,
- the seller,
- a customer party as the originator.
For other elements that are optional to be included in the 1Lieferschein, please see: http://docs.oasis-open.org/ubl/os-UBL-2.2/mod/summary/reports/UBL-DespatchAdvice-2.2.html Furthermore, please find examples on an 1Lieferschein, represented as an XML file as well as a PDF file at https://github.com/1Lieferschein/samples. To self-generate a sample XML file, we recommend you to use the following link: https://cranesoftwrights.github.io/resources/Crane-UBL-2.1-Skeleton/Crane-UBL-DespatchAdvice-2.1.html.
Convert and create 1Lieferschein
For creating an XML-based UBL despatch advice an editor application is not necessarily required but recommended. There is a large variety of free software for the creation and display of XML documents. Special editors for XML documents can already be found on the Internet, e.g., XMetal or Microsoft XML Notepad. These can be used in order to create an 1Lieferschein.
Transferring an 1Lieferschein
For 1Lieferschein there is no mandatory transmission standard. Different options are possible, though, e.g. blockchain, https, Peppol or DTRANS. The initiative 1Lieferschein prefers DTRANS as transmission standard, For more information on these opportunities, see:
- DTRANS: https://docs.google.com/document/d/1YNdo-U2zE4ypU7cFhTP44TmakUkQZrDI0NzuzTyjGJs/edit#heading=h.bp3lsxmo6a7e
- Peppol
- Blockchain
- NFC for Offline transmission
- Multipeer Connectivity for Offline transmission IOS https://developer.apple.com/documentation/multipeerconnectivity
Outlook
In the future, the initiative will extend the standard for other document types, i.e., purchase order, receipt advice, inquiry, delivery call-off. To increase the level of service, support for companies and their service providers in setting up 1Lieferschein and DTRANS will be established. In addition, a community will be established for software developers and system operators to develop software components for the use of 1Lieferschein and DTRANS in existing systems. Members of this initiative
Rösch Unternehmensberatung Peter Rösch | www.roesch-unternehmensberatung.de Haar bei München |
bobbie Deutschland GmbH Alexander Gran | www.bobbie.de Aachen |
AS-Bau Hof GmbH Dr. Thomas Dick | www.as-hof.de Hof |
LEONHARD WEISS GmbH & Co. KG Uwe Immel | www.leonhard-weiss.de Satteldorf |
EUROVIA Services GmbH Anke Vatter | www.eurovia.de Bottrop |
qbound GmbH Artur Rösch | www.qbound.io Gilching |
MWM Software & Beratung GmbH Wilhelm Veenhuis | www.mwm.de Bonn |
tabya GmbH Tobias Müller | www.tabya.de Münster |
CATHAGO Technology UG Philipp Dressler | www.cathago.de Berlin |
DTRANS Standard
Mit DTRANS steht ein neuer webnativer, offener und freier Übertragungsweg für Geschäftsdaten bereit. DTRANS macht die vollautomatisierte Übertragung zu beliebig vielen Empfängern möglich und bietet einen sicheren Weg für eine Empfangsbestätigung. DTRANS verwendet bewährte Internetstandards: DNS SRV Einträge zum Entdecken (neudeutsch Discovery) bzw. Aushandeln des Kommunikationskanals und Formats und dann HTTPS + .well-known URLs zum Übertragen der Dokumente. Eine aufwändige und zeitintensive Einrichtung zwischen den Geschäftspartnern ist nicht erforderlich. Für den automatischen Erhalt des 1Lieferschein müssen lediglich via DTRANS die entsprechenden DNS-Einträge gesetzt werden und der Webserver entsprechend konfiguriert sein. Die Einstiegshürde gerade für DTRANS und damit auch 1Lieferschein ist somit sehr gering.
Abstract
There are various standards that define standard business documents, most notably UBL and UN/CEFACT, plus lots of derivative work, e.g. X-Rechnung, Order-X, ZuGFERD or 1Lieferschein and competing ones like openTRANS. Those standards define the structure and format of the documents, however they either do not define a standard way to exchange the documents between parties or lack a discovery process to find out which standard to use. This RFC closes this gap by providing a standard way of discovery and transmission of standard business documents that requires zero configuration for the sending and receiving parties.
Introduction
In order to submit transactional data from the sender to the receiver, the sending party will need to know from the receiver:
- Which data format to use to encode the data
- Which mechanism of transport to use
- And how to use it the transport mechanism
This document specifies 1.) & 2.) for most established business documents, using DNS SRV and defines a transport standard for 3.) using .well-known URI. First, the sender will discover a receiving server using a defined DNS lookup, then connect via https to the receiving server, reaching out to a .well-known URI. The sender sends the document via the transmission standard that is also specified in the DNS SRV record.
Notational Conventions
The key words „MUST“, „MUST NOT“, „REQUIRED“, „SHALL“, „SHALL NOT“, “SHOULD“, „SHOULD NOT“, „RECOMMENDED“, „NOT RECOMMENDED“, „MAY“, and „OPTIONAL“ in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
Discovery
The sender uses the DNS SRV record discovery approach of RFC2782 to discover the target server responsible for the recipient’s domain. Determining the domain name of the recipient is out of scope of this RFC, typically this can be derived from existing email addresses. The new SRV records defined are listed in table 1 in section Supported Document Types. As both a sender and a receiver might support multiple, alternative document formats and transmission schemes, this lookup process can be used as a way to negotiate the used protocol, with the sender making the final choice and the receiver giving priorities. Example record for format UBL, specifying domain erp.example.com as receiving server: _dtrans_https_ubl._tcp SRV 0 0 443 erp.example.com.
Record Format
The DNS Records follow the format _dtrans_TRANSID_FORMATID with TRANSID listed in the Supported Transaction Standards table 2 and FORMATID listed in the Supported Document Types table 1. The rest of the record is per RFC2782.
Transmission Standards
There are multiple standard ways to transmit documents to a target system. DTRANS specifies its own below, others can be standardized in other RFCs or by general agreement of the participating parties. See following table:
Transmission Standard | TRANSID | Reference |
DTRANS | https | This RFC |
qBound cleverschein Blockchain | cleverschein | https://www.qbound.io/produkt |
PEPPOL | peppol | https://peppol.eu/what-is-peppol/peppol-transport-infrastructure/ |
AS/2 | as2 | https://datatracker.ietf.org/doc/html/rfc4130 |
Table 1: Defined Transmission Standards It is up to the Transmission Standard to define how to submit a document. The sender of the document can select from the available transmission and document formats which one to use. It SHOULD respect the servers priorities.
DTRANS Document Transmission
Once the destination server has been discovered, the sender will connect to it using standard HTTPS mechanism, accessing the defined URL dtrans in the .well-known name space according to RFC 8615, adding the FORMATID as parameter format: https://servername/.well-known/dtrans?format=FORMATID For the example receiving server erp.example.com in format UBL, that results in the following URI: https://erp.example.com/.well-known/dtrans?format=ubl The client then uses HTTP POST to transmit the xml document in the request body. The server replies using a standard HTTP return code. For document standards that specify multiple document types, e.g. UBL and UN/CEFACT, the server should reply with http 501 Not Implemented when the submitted document type is not supported.
Test Transmission
In order to validate a connection, the client may append URL parameter test=true to the URL. The server MUST IGNORE the document for operational purpose but SHOULD try to validate the document against internal rules as much as possible. This results in sample URLs like https://servername/.well-known/dtrans?format=FORMATID&test=true
Cryptographic proof of delivery
In case of a successful transmission (HTTP Code 200), the server also returns a cryptographic acknowledgment of receipt inspired by DKIM [RFC 6376] signature as such: Using any currently valid DKIM signature algorithm, and retrieving the valid keys using the selector dtrans as per DKIM, the server will generate a signature over: T=,S=,M= Adding the fields t, v, a, b, q, s, as per RFC 6376 in the signature. Other fields are not supported, specifically no canonicalization will take place. The signature always covers the whole document. The timestamp in the signed part has the same format and value as the t value of the signature. It is also signed, as having a proof of the time of reception might be crucial for some document types. The client SHOULD validate that value against it’s own clock to be sure that the receipt is useful. <
Key Retrieval
Using DKIM, with:
- Selector “dtrans”, or any DNS style subspace of that, in case larger organizations choose to use multiple keys. See RFC 6376 section 3.1 for details. Given a signature field with a „d=“ tag of example.com, the DNS query will be for „dtrans._domainkey.example.com“, or any subspace thereof, e.g.
„erp.dtrans._domainkey.example.com“
- Service type “dtrans” in the key data as per RFC 6376 section 3.6.1
Supported Document Standards
The following document specifications can be supported by this standard. Others are to be added later by updating this RFC.
Format | FORMATID | Reference |
Universal Business Language | ubl | http://docs.oasis-open.org/ubl/UBL-2.3.html |
United Nations Economic Commission for Europe | unece | https://unece.org/trade/uncefact/mainstandards |
Factur-X | facturx | https://fnfe-mpe.org/factur-x/factur-x_en/ |
Order-X | orderx | https://www.ferd-net.de/standards/order-x/index.html |
1Lieferschein | 1lieferschein | TBA |
openTRANS | openTRANS | https://www.opentrans.de/ |
Table 1: Defined Document Standards
Contributions
Acknowledgments
Internationalization Considerations
References
Security Considerations
The use of unauthenticated transmission is desired, as this is a prerequisite to allow zero configuration on the sending side. Server operators MUST take care of potential attack vectors, similar to e-mail, i.e. DOS, spam etc. The UBL standard supports inline signatures, which verify the authenticity of the server. E-Mail doesn’t support proof of delivery for a historic reason: When E-Mail was invented it was common practice that the receiving party’s computer is offline, and only the email infrastructure was up and running, but very likely a system not under control of the receiving party. As such, delays and multi hop connections were the common case. With DTRANS we expect this not to be the common case, and albeit multi hop is technically possible the receiving server is supposed to be under (contractual) control of the receiving legal entity. This allows it to sign the reception. The server MUST make sure not to reveal business secrets when validating test transactions.
IANA Considerations
_dtrans needs to get registration via https://datatracker.ietf.org/doc/html/rfc8552 dtrans needs to get gestiration via https://datatracker.ietf.org/doc/html/rfc8615