The Peppol Business Interoperability Specification, “BIS” from here on after, has been developed by the OpenPeppol AISBL Post Award Coordinating Community and is published as part of the Peppol specifications.

Statement of copyright

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.

Link to main site of documentation

Main documentation site

1. Introduction to openPeppol and BIS

This BIS is a result of work within Peppol project and is published as part of Peppol specifications.

This Peppol BIS provides a set of specifications for implementing a Peppol business process. The document is concerned with clarifying requirements for ensuring interoperability of pan-European Public eProcurement and provides guidelines for supporting these requirements and how to implement them. This Peppol BIS is based on the CEN WS/BII2 Profile “Profile BII30 Dispatch Only”. A conformance statement is included in this BIS, see annex B.

BII relationship
Figure 1. Relationship between BII profiles and Peppol BIS

1.1. Background and objective

The Peppol BIS (Business Interoperability Specification) provides a set of specifications for implementing Peppol business documents. The specifications enable any company to issue electronic documents that fulfill legal and business processing requirement within the European Union and the EEA. It supports a subset of information that is used by most industries and enables users to issue documents (invoices, orders, despatch advices, etc…) that are valid for cross border trade within the European Union and the EEA.

The purpose of this document is to describe a common format for the despatch advice message in the European market, and to facilitate an efficient implementation and increased use of electronic collaboration regarding the fulfillment process based on this format.

1.2. Audience

The audience for this document is organizations wishing to be Peppol enabled for exchanging electronic business documents, and/or their ICT-suppliers.

These organizations may be:

  • Service providers

  • Contracting Authorities

  • Economic Operators

  • Software Developers

More specifically it is addressed towards the following roles:

  • ICT Architects

  • ICT Developers

  • Business Experts

For further information, please see Peppol BIS common text and introduction.

2. Principles and prerequisites

This chapter describes the principles and assumptions that underlie the use of the Peppol Despatch Advice. It is based on the CEN BII 30 Dispatch only profile.

2.1. Despatch Advice message in general

The electronic transaction described in this implementation guide is the Despatch Advice message. The Despatch Advice message is used in the fulfillment process by the supplier to notify the receiver about, the despatch and delivery period for the goods being sent, as well as details about the goods for cross checking with the order and ultimately the Electronic Despatch Advice is used for declaring how the despatched goods are packed.

The main activities supported by this message are:

  • Transport Full description of how the goods are packed and delivered. A delivery is taken to be a number of items that are despatched as a single consignment to a single delivery address.

  • Ordering States what is shipped; the quantity of goods shipped and what is outstanding.

  • Receiving goods Full support of the process of receiving goods into a warehouse, inventory, in stores or simply at a reception counter.

2.2. Parties and roles

The table below gives the definitions of the parties and roles of the fulfillment process.

Parties Definition

Customer

The customer is the legal person or organization who is in demand of a product or service.

Examples of customer roles: buyer, consignee, debtor, contracting authority.

Supplier

The supplier is the legal person or organization who provides a product or service.

Examples of supplier roles: seller, despatch party, creditor, economic operator.

Carrier

The carrier handles the physical delivery/transportation of the despatched shipment. Used if a third party is handling the physical transport.
Roles Definition

Consignee

(UBL:DeliveryCustomerParty)

The consignee is the person or organization to which the products will be shipped and who is taking possession. The role is carried out by the customer or on behalf of the customer.

Despatch Party

(UBL:DespatchSupplierParty)

The Despatch Party is the person or organization who provides (despatch) the goods or services. The role is carried out by the supplier or on behalf of the supplier. (Despatch Party is sometimes known as the Consignor)

Buyer

(UBL:BuyerCustomerParty)

The buyer is the legal person or organization who buys or purchases the goods or services. The role is carried out by the customer or on behalf of the customer.

Seller

(UBL:SellerSupplierParty)

The seller is the legal person or organization who sells goods or services to the customer. The role is carried out by the supplier or on behalf of the supplier.

Originating party

(UBL:OriginatorCustomerParty)

The party who will eventually receive and consume the goods and on whose behalf the buyer makes the purchase.

The diagram below shows the roles in the fulfillment process.

image

2.3. Other important concepts

The table below gives the definitions of key concepts of the fulfillment process.

Term Definition

Shipment

A contractual arrangement whereby an identifiable collection of goods items is to be transported from one party (usually a Supplier) to another party (usually a Customer).

Consignment

The transportation of an identifiable collection of goods items from one party (the Despatch Party) to another party (the Consignee) via one or more modes of transport.

Transport Handling Unit

A description of individual handling units in which the line items are packed.

Master Data

Master data is data which is generally static.  Data such as locations or product item can be considered master data. The process of data alignment is the exchange, “up-front”, between trading partners of location and/or item data.  In a GS1 context, master data is referenced by GS1 identification keys; the GLN – the global location number for locations, and the GTIN – global trade item number for item products.

Logistics Label

A logistics’ label has been applied to each of the pallets where the SSCCs are used and rendered as clear text numbers, address details and GS1 128 barcode.  NB where multiple SSCCs are applied to logistics’ units on one pallet, there needs to be a GS1 logistics label applied and exterior of the pallet.  The subordinate SSCCs on the individual logistics units should be packaged in such a way that they are not visible to the naked eye (in this scenario). For a full description of how to apply SSCCs and the GS1 Logistic label  see link; http://www.gs1.eu/?page=&tudasbazis=60&lister=26

3. Process and typical scenarios

3.1. Legend for BPMN diagrams

The diagrams are expressed in the BPMN notation. The diagram below serves as an explanation for the diagrams used in the process descriptions.

image

The following section and diagrams show the choreography of the business process involving various parties.

3.2. Simple process – two parties involved

Following the establishment of a contract for purchase the Supplier, in the role of Despatch party, delivers or provides the contracted goods or services to the customer, who has the role of a consignee.

image

3.3. More advanced process – use of Despatch party

The more advanced process is based on the simple process above with the addition of the Despatch party who is responsible for the physical preparation of the goods for delivery. This situation will typically occur when the supplier has outsourced the logistics function to another company.

image

3.4. Typical use cases

3.4.1. Use case 1 - Simple Despatch

This use case is a simple despatch where no handling units are used in the Despatch Advice. There are only two parties (legal entities) in this use case.

Use Case number 1

Use Case Name

Simple Despatch

Use Case Description

This use case is a simple despatch where no handling units are used in the Despatch Advice. There are only two parties (legal entities) in this use case.

Parties involved

Despatch party (In UBL: DespatchSupplierParty) (same legal entity as the Supplier/Seller in this use case)

Consignee party (In UBL: DeliveryCustomerParty) (same legal entity as the Customer/Buyer in this use case)

Assumptions

  1. The Seller has received one order from the Buyer with

    1. 2 lines (2 articles)

    2.  to be delivered at one delivery address

    3. at the same time.

  2. The Seller has accepted the order without changes.

  3. The Despatch party delivers the complete order as accepted

The flow

  1. The Seller collects the ordered articles

  2. The Seller loads the articles in boxes

  3. The Despatch party creates a Despatch advice message

  4. The Despatch party sends Despatch advice message to the Consignee

  5. The Consignee party receives the Despatch advice message

  6. The Consignee party uses the content in the Despatch advice message for registration receipt.

    1. Two despatch lines, two items (No handling units in the message)

Result

  1. The Despatch advice message helped the Consignee party to prepare receipt

    1. At the right time

    2. At the right place (address)

  2. The Despatch advice message helped the Consignee party in the process of register receipt to identify the

    1. Order

    2. The order lines

    3. The articles

    4. The delivered quantity

XML example file

See Appendix A for a sample file illustrating Use Case 1 in the download section on the main page.

3.4.2. Use case 2 - Simple Despatch with outstanding quantity.

This use case is a simple Despatch where there are no transport handling units, but an outstanding quantity on line level. There are various examples on use of the outstanding quantity and outstanding reason There are four parties (legal entities) in this use case.

Use Case number 2

Use Case Name

Simple Despatch with outstanding quantity

Use Case Description

This use case is a simple Despatch where there are no transport handling units, but an outstanding quantity on line level. There are various examples on use of the outstanding quantity and the outstanding reason. There are four parties (legal entities) in this use case.

Parties involved

Buyer (In UBL: BuyerCustomerParty)

Seller (In UBL: SellerSupplierParty)

Despatch party (In UBL: DespatchSupplierParty) (Different legal entity than the Seller in this use case)

Consignee party (In UBL: DeliveryCustomerParty) (Different legal entity than the Buyer in this use case)

Assumptions

  1. The Seller has received one order from the Buyer with

    1. 5 lines (5 different items)

    2.  To be delivered at one delivery address

    3. At the same time.

  2. The Seller has accepted the order without changes.

  3. The Seller can’t deliver the complete order as accepted.

  4. The first line contains the ordered quantity

  5. The second line contains a delivery of 6 of 10 ordered items. The remaining 4 items will be delivered in another Despatch.

  6. The third line contains a delivery of 6 of 10 ordered items. The remaining 4 items will not be delivered.

  7. The fourth line contains a delivery of 6 of 10 items. 3 items will be delivered in another Despatch and 1 item will not be delivered.

  8. The fifth line contains a delivery of 12 of 10 ordered items.

The flow

  1. The Seller collects the ordered items

  2. The Seller loads the articles in boxes

  3. The Despatch party creates a Despatch advice message

  4. The Despatch party sends Despatch advice message to the Customer

  5. The Consignee party receives the Despatch advice message

  6. The Consignee party uses the content in Despatch advice message for registration receipt.

    1. Five Despatch lines with different articles, but a part of the articles related to line 2-5 is either outstanding or can’t be delivered at all. (No handling units in the message)

Result

  1. The Despatch advice message helped the Consignee party to prepare receipt

    1. At the right time

    2. At the right place (address)

  2. The Despatch advice message helped the Consignee party in the process of register receipt to identify the

    1. Order

    2. The order lines

    3. The items

    4. The delivered quantity

    5. The outstanding quantity to be delivered at a later time

    6. The outstanding quantity which will never be delivered

XML example file

See Appendix A for a sample file illustrating Use Case 2 in the download section on the main page.

3.4.3. Use case 3 - Despatch with Logistic units using GS1 Keys

This use case is a refined use of the Despatch Advice where several GS1 keys are applied within the Despatch Advice to identify various entities in the despatch advice, namely; Parties, Endpoints, Shipment id, consignment ids, logistic unit ids and product identification.

Use Case number 3

Use Case Name

Despatch Advice with Logistic units using GS1 Keys

Use Case Description

Describes a complete process whereby a Despatch party generates a Despatch Advice based on information about the order and the product.

The Despatch Advice enables the supplier (carrier) to provide detailed information about the content of a shipment and enables a Buyer to reconcile, or confirm, the physical shipment against the order; it provides a mirror of the shipment’s packaging details and structure of the delivery.

The Despatch Advice is sent by the Despatch party to the Consignee party when the goods are sent.

Parties involved

Despatch party In UBL: DespatchSupplierParty) (Different legal entity than the Seller in this use case)

Seller (In UBL: SellerSupplierParty)

Consignee party (In UBL: DeliveryCustomerParty) (Different legal entity than the Buyer in this use)

Buyer (In UBL: BuyerCustomerParty)

Pre conditions

Master data alignment of locations (GLNs) and products (GTINs).

Post conditions

Despatch advice is received by the receiver of the goods.

Assumptions

  1. The Despatch Advice has one shipment id (GSIN) assigned by the seller

  2. The Despatch Advice has one consignment id which has been assigned by the carrier (GINC)

  3. One delivery point (no cross docking) which is identified by a GLN.

  4. The four despatch lines are each an orderable unit – a GTIN.

  5. Two ordered units (GTINS) are packed on each pallet.

  6. There are two pallets in the shipment.

  7. Each standard pallet is assigned one logistics’ unit id (SSCC).

  8. A logistics’ label has been applied to each of the pallets where the SSCC is used rendered as clear text numbers, address details and GS1 128 barcode

    Relationship between the GTIN and the SSCC keys

    image

The flow

The Seller has accepted the order without changes.

  1. The Seller collects the ordered goods

  2. The ordered goods consist of one pallet per ordered 2 line items.

  3. The Despatch party loads the goods onto the transport.

  4. The Despatch party sends the Despatch advice to the Consignee

  5. The Consignee party receives the Despatch advice message

    1. The Consignee party uses the content in the Despatch advice message for registration receipt.

Result

  1. The Despatch advice message helped the Consignee party to prepare for receipt of goods:

    1. At the right time

    2. At the right location (address)

  2. The Despatch advice helped the Consignee party in the process of receipt registration to identify the:

    1. Order

    2. The order lines

    3. The logistics’ handling units

    4. The goods description

    5. The delivered quantity

    6. The parties involved in the process

XML example file

See Appendix A for a sample file illustrating Use Case 3 in the download section on the main page.

The following provides additional details and clarifications about the various keys and identifiers used in this Use Case, as well as the benefits implementers can obtain when using them. Ultimately there are two pictures clarifying the relationship between the GSIN and the GINC identifiers.

Beneath are an overview and an explanation of the keys used in the Use Case.

GLN:

Global location number

Despatch party - Organizational identification.

Despatch party - Endpoint identification

Consignee - Organizational identification.

Consignee - Endpoint identification

Buyer - Organizational identification.

Seller - Organizational identification

SSCC:

Serial Shipping Container Code

Each transport handling unit is assigned an SSCC.

The SSCC is the GS1 Identification Key for an item of any composition established for transport and/or storage which needs to be managed through the supply chain. The SSCC is assigned for the life time of the transport item and is a mandatory element on the GS1 Logistic Label

GSIN:

Global Shipment Identification Number

Shipment identification. One shipment number for the despatch advice.

A document level id that specifies the number of the Shipment along the entire shipment, which, may consist of several consignments.

  • Number assigned by the seller to identify a logical grouping of logistic or transport units that are typically assembled by the seller for a transport shipment.

  • It meets the World Customs Organisation (WCO) requirement for a Unique Consignment Reference (URC).

It is endorsed by ISO/IEC 15459 (ISO License Plate)

GINC:

Global Identification Number of Consignment

One consignment number for the Despatch Advice

  • Used to identify a logical grouping of logistic or transport units that are assembled to be transported under one transport document.

  • It is used to identify a logical grouping of logistic units during a specific journey of which there may be multiple consignment stages.

GTIN:

Global trade Item Number

Each ordered item as a GTIN.

Product identification.
Beneath are an overview of the benefits implementers can get when using the keys and identifiers.

GTIN:

Global trade Item Number

  • Correct goods and associated data have been sourced through upfront data alignment

GLN

Global Location Number

  • Precise and trustworthy location data has been achieved through GS1 master data alignment location registers.

SSCC:

Serial Shipping Container Code

  • Logistic units are individually identified with the SSCC (Serial Shipping Container Code)

  • The item (goods) details accessed by scanning (bar code) or reading (EPC/RFID) the SSCC on the logistic unit and accessing the relevant information.

  • The usage of the SSCC on a logistic unit is subject to rules, namely that multiple visible SSCCs on one logistics unit can only be used for transit purposes.

    • If two or more SSCCs are applied on a logistics unit then the units associated to a given SSCC have to be individually wrapped or bound together to form individual logistics units.

    • Multiple SSCCs can be applied to individual units on one logistic unit for subsequent cross docking but they HAVE to be wrapped so that they are not visible.

  • Additionally, a master logistics label needs to be applied to the whole logistics unit for the consignment to the distribution center.

GSIN:

Global Shipment Identification Number

  • A globally recognised shipping number used to uniquely identify the shipment as a whole as specified by the seller

GINC:

Global Identification Number of Consignment

  • A globally recognised consignment number used to uniquely identify the consignment as specified by the shipper.

Supplementary clarification on the usage of the GSIN and the GINC.

Assembling of the keys:

image

3.4.4. Use case 4 - Despatch with weight, length and/or volume based items (ie vegetables, meat)

This use case demonstrates the use of the Despatch Advice, where the Seller is despatching items which are priced on weight, length and/or volume.

Use Case number 4

Use Case Name

Despatch with weight, length and/or volume based items (ie vegetables, meat)

Use Case Description

This use case demonstrates the use of the Despatch Advice, where the Seller is despatching items which are priced on weight, length and/or volume. Therefore the weight, length or volume of the items is important. Transport handling units are used to indicate how the items are packed.

The use case also demonstrates:

  • The use of different party identifiers (GLN and Swedish organization number)

  • The use of ItemBestBeforeDate, ItemExpiryDate, ItemBatchNumber, ItemSerialNumbers,

  • The use of SSCC keys,

  • The use of ItemSellersIdentifier and ItemStandardIdentifier (GTIN).

Parties involved

Despatch party (In UBL: DespatchSupplierParty) (same legal entity as the Supplier/Seller in this use case)

Consignee party (In UBL: DeliveryCustomerParty) (same legal entity as the Customer/Buyer in this use case)

Assumptions

  1. The Seller has received one order from the Buyer with

    1. 4 lines (4 items) which are priced by the weight

    2. To be delivered at one delivery address

    3. At the same time.

  2. The Seller has accepted the order without changes.

  3. The Seller delivers the complete order as accepted.

  4. The items are in four separate transport handling units.

image

The flow

  1. The Seller collects the ordered items

  2. The Seller weighs the items.

  3. The Seller loads the items into transport handling units (Boxes)

  4. The Despatch party creates the Despatch Advice message

  5. The Despatch party sends the Despatch Advice message to the Consignee

  6. The Consignee party receives the Despatch Advice message

  7. The Consignee party uses the content in the Despatch Advice message for registration receipt.

    1. Four despatch lines, four items.

    2. Handling units are identified using SSCC identifiers

    3. The delivered weight is used in the receipt activity (for verification)

  8. The Consignee party uses the content in the Despatch Advice message for storing- and handling.

    1. Items can be stored by BestBeforeDate or ExpiryDate

    2. Items can be stored by batch and/or serial numbers

    3. Items can be handled according to the weight of the handling unit

Result

  1. The Despatch Advice message helped the Consignee party to prepare receipt

    1. At the right time

    2. At the right place (address)

    3. With appropriate storage facilities

  2. The Despatch Advice message helped the Consignee party in the process of register receipt to identify the

    1. Order

    2. The order lines

    3. The transport handling units

    4. The items

    5. The delivered quantity/weight

XML example file

See Appendix A for a sample file illustrating Use Case 4 in the download section on the main page.

3.4.5. Use case 5 – Advanced Despatch demonstrating most of the business terms

This use case is a relatively more complex use of the Despatch Advice which will demonstrate the use of most of the business terms available in the electronic Despatch Advice message.

Use Case number 5

Use Case Name

Advanced Despatch Advice demonstrating most of the business terms

Use Case Description

This use case is a very complex use of the Despatch Advice which will demonstrate the use of all of the existing business terms available in the electronic Despatch advice message.

The use case will also demonstrate different use of:

  • Party identification

  • Item identification

  • Packages

Parties involved

Buyer (In UBL: BuyerCustomerParty)

Seller (In UBL: SellerSupplierParty)

Despatch party (In UBL: DespatchSupplierParty) (Different legal entity than the Seller in this use case)

Consignee party (In UBL: DeliveryCustomerParty) (Different legal entity than the Buyer in this use case) Originating party (In UBL: OriginatorCustomerParty)

Assumptions

  1. The Seller party and Despatch party are different legal entities

  2. The Buyer party and Consignee party are different legal entities

  3. The Seller has received one order from the Buyer

    1. 5 order lines (5 items)

    2. Order line 4 is not delivered in this despatch

    3. The second Despatch line contains a delivery 6 of 10 ordered items. The remaining 4 items will be delivered in another despatch.

    4. The third Despatch line is weight based

    5. Order to be delivered at one delivery address

    6. At the same time.

    7. Despatch line 4 contain hazardous items

  4. The Seller has accepted the order without changes

  5. The Despatch party is responsible for the delivery and is using a carrier for the physical transportation

  6. The items in the first and second line are in the same transport handling unit

  7. The items in line three and four are in two separate transport handling units

image

The flow

  1. The Seller collects the ordered items

  2. The Seller loads the items into transport handling units (Boxes, crates, pallets etc.)

  3. The Despatch party identifies all shipping details

  4. The carrier picks up the goods for transport

  5. The Despatch party creates the Despatch advice message

  6. The Despatch party sends the Despatch advice message to the Consignee

  7. The Consignee can use the tracking ID to track the shipment

  8. The Consignee party receives the Despatch advice message

  9. The carrier delivers the goods to the Consignee

  10. The Consignee party uses the content in the Despatch advice message for registration receipt.

    1. Four Despatch lines, four items.

    2. Handling units are identified using SSCC identifiers

  11. The Consignee party uses the content in the Despatch advice message for storing- and handling.

    1. Handling unit with Hazardous items are identified

    2. Items can be stored by best before date, by batch and serial number

    3. Items can be handled according to the weight of the handling unit

Result

  1. The Despatch advice message helped the Consignee party to prepare receipt

    1. At right time

    2. At the right place (address)

    3. With appropriate tools and storage facilities

    4. In a secure manner

  2. The Despatch advice message helped the Consignee party in the process of register receipt to identify the

    1. Order

    2. The order lines

    3. The transport handling units

    4. The articles

    5. The delivered quantity/weight

XML example file

See Appendix A for a sample file illustrating Use Case 5 in the download section on the main page.

4. Semantic datatypes

Semantic data types are used to bridge the gap between the semantic concepts expressed by the information elements and the technical implementation. The semantic data types define the allowed value domain for the content, and any additional information components (attributes) needed in order to ensure its precise interpretation.

4.1. Primitive types

Semantic data type content may be of the following primitive types. These primitive types were taken from ISO 15000-5:2014, Annex A.

Primitive type Definition

Binary

A set of finite-length sequences of binary digits.

Date

Time point representing a calendar day on a time scale consisting of an origin and a succession of calendar ISO 8601:2004.

Decimal

A subset of the real numbers, which can be represented by decimal numerals.

String

A finite sequence of characters.

4.2. Semantic data types

The different semantic data types are described in the tables below, where various features such as attributes, format, and decimals as well as the basic type are defined for each semantic data type. They are based on ISO 15000-5:2014.

When used in an instance document, each data element will contain data. In the below tables this is identified as the “content”. Whenever a business term is used this term shall always have content and therefore the content is always mandatory.

4.2.1. Amount

An amount states a numerical monetary value. The currency of the amount is defined as a separate business term.

Amount is floating up to two fraction digits.
Component Use Primitive Type Example

Content

Mandatory

Decimal

10000.25

4.2.2. Price Amount

A price amount states a numerical monetary amount value for data elements that contain item prices that may be multiplied by item quantities. The currency of the amount is defined as a separate business term.

Unit price amount does not set restrictions on number of decimals, as contrast to the Amount type
Component Use Primitive Type Example

Content

Mandatory

Decimal

10000.1234

4.2.3. Percentage

Percentages are given as fractions of a hundred (per cent) e.g. the value 34,78 % in percentage terms is given as 34,78.

No restriction on number of decimals for percentages.
Component Use Primitive Type Example

Content

Mandatory

Decimal

34.7812

4.2.4. Quantity

Quantities are used to state a number of units such as for items. The code for the Unit of Measure is defined as a separate business term.

No restriction on number of decimals for quantities.
Component Use Primitive Type Example

Content

Mandatory

Decimal

10000.1234

4.2.5. Code

Codes are used to specify allowed values in elements as well as for lists of options. Code is different from Identifier in that allowed values have standardized meanings that can be known by the recipient.

Codes shall be entered exactly as shown in the selected code list
Component Use Primitive Type Example

Content

Mandatory

String

Abc123

4.2.6. Identifier

Identifiers (IDs) are keys that are issued by the sender or recipient of a document or by a third party.

The use of the attributes is specified for each information element.
Component Use Primitive Type Example

Content

Mandatory

String

abc:123-DEF

Scheme identifier

Conditional

String

0088

Scheme version identifier

Conditional

String

1.0

4.2.7. Date

Dates shall be in accordance to the “Calendar date complete representation” as specified by ISO 8601:2004, format YYYY-MM-DD.

Dates shall not include timezone information.
Table 1. EN 16931_ Date. Type
Component Use Primitive Type Example

Content

Mandatory

Date

2017-12-01

4.2.8. Time

Time shall be in accordance to the “Extended time format” as specified by ISO 8601:2004, format [hh]:[mm]:[ss].

Time shall not include timezone information. Decimal fraction on seconds SHALL not be used.
Table 2. EN 16931_ Date. Type
Component Use Primitive Type Example

Content

Mandatory

Date

09:30:12

4.2.9. Document Reference

Document Reference Types are identifiers that were assigned to a document or document line.

Table 3. Document Reference. Type
Component Use Primitive Type Example

Content

Mandatory

String

abc:123-DEF

4.2.10. Text

Text is the actual wording of anything written or printed. Line breaks in the text may be present, and any line breaks should be preserved and respected by the receiver’s system

Component Use Primitive Type Example

Content

Mandatory

String

5% allowance when paid within 30 days

4.2.11. Binary objects

Binary objects can be used to describe files which are transmitted together with the business document. Attachments shall be transmitted together with the business document. 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 business document.

Component Use Primitive Type Example

Content

Mandatory

Binary

QmFzZTY0IGNvbnRlbnQgZXhhbXBsZQ==

Mime Code

Mandatory

String

image/jpeg

Filename

Mandatory

String

drawing5.jpg

4.2.12. Boolean

Boolean indicators are used to specify the two allowed values, true or false. All elements of datatype Boolean, must have either true or false as their value.

Component Use Primitive Type Example

Content

Mandatory

String

true

5. Code lists

5.1. Code lists for coded elements

Any element with the semantic data type = code, can mandate the use of a specific code list (or a fixed value). The applicable code lists can be found in the Code list section. In this section, you can find the valid codes, their names and description, and also links to where the same code list is used elsewhere in the transaction, or in other Peppol BIS v3. documents.

5.2. Code list for identifiers

5.2.1. Party identifiers and party legal registration identifier scheme

All party identifiers (cac:PartyIdentification/cbc:ID) and party legal registration identifier (cac:PartyLegalEntity/cbc:CompanyID) has an optional scheme identifier attribute (@schemeID). If used, the value shall be chosen from the code list ICD codes

Examples of usage in cac:PartyIdentification
<cac:PartyIdentification>
        <cbc:ID schemeID="0088">5790000435968</cbc:ID> (1)
</cac:PartyIdentification>
1 schemeID attribute is optional, but when used, the codes must be from ICD codes

5.2.2. Electronic address identifier scheme identifier

All electronic address identifiers (cbc:EndpointID/@schemeID) use the Electronic Address Scheme code list (EAS), maintained by CEF (CEF Code lists).

Valid values are found here: EAS codes.

Examples of usage in cbc:EndpointID
<cbc:EndpointID schemeID="0184">DK87654321</cbc:EndpointID> (1)
1 schemeID attribute is mandatory

6. Description of selected parts of the despatch advice message

6.1. Parties

The following parties/roles may be specified in the message. The same actor may play more than one role depending on the handling routine.

6.1.1. Despatch party (DespatchSupplierParty)

The Despatch Party is the person or organization who provides (despatch) the goods or services. The role is carried out by the supplier or on behalf of the supplier. (Despatch Party is sometimes known as the Consignor). The Despatch Party is mandatory information in the Despatch Advice message.

Example:

<cac:DespatchSupplierParty>
        <cac:Party>
                <cbc:EndpointID schemeID="0184">DK87654321</cbc:EndpointID>
                <cac:PartyIdentification>
                        <cbc:ID schemeID="0088">7300010000001</cbc:ID>
                </cac:PartyIdentification>
                <cac:PartyLegalEntity>
                        <cbc:RegistrationName>Sender Company</cbc:RegistrationName>
                </cac:PartyLegalEntity>
                <cac:Contact>
                        <cbc:Name>John</cbc:Name>
                        <cbc:Telephone>123456789</cbc:Telephone>
                        <cbc:ElectronicMail>John@SenderCompany.dk</cbc:ElectronicMail>
                </cac:Contact>
        </cac:Party>
</cac:DespatchSupplierParty>

6.1.2. Consignee (DeliveryCustomerParty)

The Consignee is the person or organization to which the products will be shipped and who is taking possession. The role is carried out by the customer or on behalf of the customer. The Consignee is mandatory information in the Despatch Advice message.

Example:

<cac:DeliveryCustomerParty>
        <cac:Party>
                <cbc:EndpointID schemeID="0184">DK12345678</cbc:EndpointID>
                <cac:PartyIdentification>
                        <cbc:ID schemeID="0088">7300010000001</cbc:ID>
                </cac:PartyIdentification>
                <cac:PostalAddress>
                        <cbc:StreetName>Reciever Street 1</cbc:StreetName>
                        <cbc:AdditionalStreetName>Reciever Building</cbc:AdditionalStreetName>
                        <cbc:CityName>Reciever City</cbc:CityName>
                        <cbc:PostalZone>9000</cbc:PostalZone>
                        <cbc:CountrySubentity>Region A</cbc:CountrySubentity>
                        <cac:AddressLine>
                                <cbc:Line>Gate 34</cbc:Line>
                        </cac:AddressLine>
                        <cac:Country>
                                <cbc:IdentificationCode>DK</cbc:IdentificationCode>
                        </cac:Country>
                </cac:PostalAddress>
                <cac:PartyLegalEntity>
                        <cbc:RegistrationName>Consignee Company</cbc:RegistrationName>
                </cac:PartyLegalEntity>
        </cac:Party>
        <cac:DeliveryContact>
                <cbc:Name>Tim</cbc:Name>
                <cbc:Telephone>987654321</cbc:Telephone>
                <cbc:ElectronicMail>Tim@RecieverCompany.dk</cbc:ElectronicMail>
        </cac:DeliveryContact>
</cac:DeliveryCustomerParty>

6.1.3. Buyer (BuyerCustomerParty)

The buyer is the legal person or organization who buys or purchases the goods or services. The role is carried out by the customer or on behalf of the customer.

The Buyer is optional information in the Despatch Advice message.

Example:

<cac:BuyerCustomerParty>
        <cac:Party>
                <cac:PartyIdentification>
                        <cbc:ID schemeID="0088">1251513513245</cbc:ID>
                </cac:PartyIdentification>
                <cac:PartyName>
                        <cbc:Name>Buyer Company</cbc:Name>
                </cac:PartyName>
        </cac:Party>
</cac:BuyerCustomerParty>

6.1.4. Seller (SellerSupplierParty)

The seller is the legal person or organization who sells goods or services to the customer. The role is carried out by the supplier or on behalf of the supplier. The Seller is optional information in the Despatch Advice message.

Example:

<cac:SellerSupplierParty>
        <cac:Party>
                <cac:PartyIdentification>
                        <cbc:ID schemeID="0088">1231612366324</cbc:ID>
                </cac:PartyIdentification>
                <cac:PartyName>
                        <cbc:Name>Seller Company</cbc:Name>
                </cac:PartyName>
        </cac:Party>
</cac:SellerSupplierParty>

6.1.5. Originating party (OriginatorCustomerParty)

The party who will eventually receive and consume the goods and on whose behalf the buyer makes the purchase. The Originator Party is optional information in the Despatch Advice message.

Example:

<cac:OriginatorCustomerParty>
        <cac:Party>
                <cac:PartyIdentification>
                        <cbc:ID schemeID="0088">1234415341925</cbc:ID>
                </cac:PartyIdentification>
                <cac:PartyName>
                        <cbc:Name>Originator</cbc:Name>
                </cac:PartyName>
        </cac:Party>
</cac:OriginatorCustomerParty>

6.2. Order reference

Used to provide a reference to the purchase order on which the Despatch Advice is based. There may be multiple Despatch Advices to cover one purchase order. When all the lines of the Despatch Advice relate to the same purchase order, the order reference is indicated only in the header. When the lines of the Despatch Advice relate to different purchase orders, the order references must be indicated in the lines. The reference to Order Line-ID is required in the UBL syntax. To cater for scenarios where no order line reference exist a dummy value must be applied. The dummy value must consist of the characters NA.

Example header level
<cac:OrderReference>
        <cbc:ID>4321</cbc:ID>
</cac:OrderReference>
Example 1 of Line level
<cac:OrderLineReference>
        <cbc:LineID>1</cbc:LineID>
        <cac:OrderReference>
                <cbc:ID>879865</cbc:ID>
        </cac:OrderReference>
</cac:OrderLineReference>
Example 2 of Line level
<cac:OrderLineReference>
        <cbc:LineID>NA</cbc:LineID>
        <cac:OrderReference>
                <cbc:ID>9898654</cbc:ID>
        </cac:OrderReference>
</cac:OrderLineReference>

It is also possible to refer to more than one order in one single despatch advice. In this case there must not be an order reference on header level.

6.3. Shipment

Description of the actual shipment that contains the goods that are being despatched.

6.3.1. Shipment ID

In some uses of the Despath Advice, there is no unique identifier assigned to the shipment. However, the UBL syntax requires the Shipment ID. Consequently, to be able to use elements such as GrossWeightMeasure or CarrierParty, the Shipment/ID must be filled in. To cater for scenarios where no ID exist a dummy value must be applied. The dummy value must consist of the characters NA.

Example:

<cac:Shipment>
        <cbc:ID>NA</cbc:ID>
        <cbc:Information>Free text information relating to the Shipment</cbc:Information>
        <cbc:GrossWeightMeasure unitCode="KGM">23</cbc:GrossWeightMeasure>
        <cbc:GrossVolumeMeasure unitCode="MTQ">27</cbc:GrossVolumeMeasure>
        <cac:Consignment>
                <cbc:ID>12345</cbc:ID>
                <cac:CarrierParty>
                        <cac:PartyName>
                                <cbc:Name>CarrierPart</cbc:Name>
                        </cac:PartyName>
                </cac:CarrierParty>
        </cac:Consignment>
        <cac:Delivery>
                <cac:EstimatedDeliveryPeriod>
                        <cbc:StartDate>2013-03-15</cbc:StartDate>
                        <cbc:StartTime>08:00:00</cbc:StartTime>
                        <cbc:EndDate>2013-03-16</cbc:EndDate>
                        <cbc:EndTime>12:00:00</cbc:EndTime>
                </cac:EstimatedDeliveryPeriod>
                <cac:Despatch>
                        <cbc:ActualDespatchDate>2013-03-13</cbc:ActualDespatchDate>
                        <cbc:ActualDespatchTime>08:00:00</cbc:ActualDespatchTime>
                </cac:Despatch>
        </cac:Delivery>
</cac:Shipment>

7. Despatch line

Description of items that are being despatched.

7.1. Item description and identification

Each despatch line contains elements for description and identification of the item. Normally only one of the identifiers is needed in the message.

Example:
<cac:Item>
        <cbc:Name>Item123</cbc:Name>
        <cac:SellersItemIdentification>
                <cbc:ID>010120401</cbc:ID>
        </cac:SellersItemIdentification>
        <cac:StandardItemIdentification>
                <cbc:ID schemeID="0160">7611104117056</cbc:ID>
        </cac:StandardItemIdentification>
</cac:Item>

7.2. Outstanding quantity

The outstanding element on the Despatch line is both used to signal the outstanding quantity and to inform about delivery discrepancies.

The handling of “The outstanding quantity which will never be delivered” is done like this: The amount that is declared in the element OutstandingQuantity is equivalent to the amount that will be delivered in a later Despatch. This implicitly means that the missing items that are NOT declared in the OutstandingQuantity cant or will not will be delivered.

Example 1:

10 items are ordered, 6 items are delivered and the rest of 4 items will be delivered later:

Quantity ordered: 10

Quantity delivered: 6

Outstanding quantity: 4

<cbc:DeliveredQuantity unitCode="EA">6</cbc:DeliveredQuantity>
<cbc:OutstandingQuantity unitCode="EA">4</cbc:OutstandingQuantity>
<cbc:OutstandingReason>Backorder</cbc:OutstandingReason>

Example 2:

10 items are ordered. 6 items are delivered and the rest of 4 items will NOT be delivered:

Quantity ordered: 10

Quantity delivered: 6

Outstanding quantity: 0

<cbc:DeliveredQuantity unitCode="EA">6</cbc:DeliveredQuantity>
<cbc:OutstandingQuantity unitCode="EA">0</cbc:OutstandingQuantity>
<cbc:OutstandingReason>Out of stock</cbc:OutstandingReason>

Example 3:

10 items are ordered. 6 items are delivered and 3 will be delivered later and 1 item will NOT be delivered:

Quantity ordered: 10

Quantity delivered: 6

Outstanding quantity: 3

<cbc:DeliveredQuantity unitCode="EA">6</cbc:DeliveredQuantity>
<cbc:OutstandingQuantity unitCode="EA">3</cbc:OutstandingQuantity>
<cbc:OutstandingReason>Production error</cbc:OutstandingReason>

Ref. use case 2 above.

7.3. Hazardous item

The Peppol Despatch Advice also contains the possibility to inform the Consignee about Hazardous Items. This is done by informing the dangerous regulation code for example ADR (Road transport), IMDG (transport by sea) or RID (railroad transport). When declaring hazardous items it is recommended to use the UNDG code to inform about the convention the item is declared hazardous under. When the UNDG code has been declared the Hazard class is declared. The Hazard class corresponds to the hazardous class of the item for example class 2.3 which indicates Poisonous Gas.

UBL example of declaring hazardous items.
<cac:HazardousItem>
        <cbc:UNDGCode>ADR</cbc:UNDGCode>
        <cbc:HazardClassID>2.3</cbc:HazardClassID>
</cac:HazardousItem>

7.4. Item properties

If additional item information such as properties and identifier are needed they can be added by using "Name" to identify the type of information and "Value" for the information.

UBL example of item properties
<cac:AdditionalItemProperty>
        <cbc:Name>NPLId</cbc:Name>
        <cbc:Value>20300709400050</cbc:Value>
</cac:AdditionalItemProperty>

7.5. Serial numbers

If each of the delivered items is marked with an individual serial number, these numbers may be sent in the Despatch Advice on Item level.

<cac:ItemInstance>
        <cbc:SerialID>OR250RHZ444</cbc:SerialID>
</cac:ItemInstance>
<cac:ItemInstance>
        <cbc:SerialID>OR250RHZ4445</cbc:SerialID>
</cac:ItemInstance>
<cac:ItemInstance>
        <cbc:SerialID>OR250RHZ4446</cbc:SerialID>
</cac:ItemInstance>

7.6. Batch/Lot numbers, Expiry Date and Best Before Date

The Batch number (Lot number) applies to all items in the despatch line.

Expiry date is used for medical drugs.

Best before date is often used for food.

Example 1:
<cac:ItemInstance>
        <cac:LotIdentification>
                <cbc:LotNumberID>898A129</cbc:LotNumberID>
                <cbc:ExpiryDate>2015-07-01</cbc:ExpiryDate>
        </cac:LotIdentification>
</cac:ItemInstance>
Example 2:
<cac:ItemInstance>
        <cbc:BestBeforeDate>2015-04-15</cbc:BestBeforeDate>
</cac:ItemInstance>

7.7. Transport handling unit

The items on a Despatch line may be packed in several transport handling units which are the physical handling units such as box, container, pallet, etc. containing the consignment.

Serial shipping container code (SSCC) issued by GS1 may be used to identify the transport handling unit. Note that the same physical handling unit may contain items from different despatch lines. Implemented by referencing the same SSCC code in the ID element of the TransportHandlingUnit on several despatch lines.

Example:

<cac:TransportHandlingUnit>
        <cbc:ID>5454</cbc:ID>
        <cbc:TransportHandlingUnitTypeCode>4H</cbc:TransportHandlingUnitTypeCode>
        <cbc:HazardousRiskIndicator>false</cbc:HazardousRiskIndicator>
        <cbc:ShippingMarks>text</cbc:ShippingMarks>
        <cac:MeasurementDimension>
                <cbc:AttributeID>AAW</cbc:AttributeID>
                <cbc:Measure unitCode="LTR">1</cbc:Measure>
        </cac:MeasurementDimension>
</cac:TransportHandlingUnit>

8. Peppol Identifiers

Peppol has defined a Peppol Policy for identifiers, policy 8 that specifies how to use identifiers in both its transport infrastructure and within the documents exchanged across that infrastructure. It also introduces principles for any identifiers used in the Peppol environment. The policies that apply to this BIS are the following:

8.1. Profiles and messages

All messages contains ProfileID and CustomizationID. ProfileID identifies what business process a given message is part of, and CustomizationID identifies the kind of message and the rules applied.

Profiles are connected to one business process, and may contain multiple document types. Valid document instances shall contain corresponding ProfileID and CustomizationID.

CustomizationID is a string without spaces. The list below contains spaces in CustomizationID to make them easier to read. Make sure to remove any spaces before use.

8.2. Customization and Profile identifiers

In the table below you will find the values to be used as the specification identifier and the business process type for this profile

Type Element cbc:CustomizationID Element cbc:ProfileID

Despatch Advice (Trdm16)

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

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

8.3. Namespaces

The despatch advice data model is bound to UBL 2.1 of the document type UBL Despatch Advice 2.1. The target namespace for the UBL2.1 Despatch Advice is:

urn:oasis:names:specification:ubl:schema:xsd:DespatchAdvice-2