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:

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 BEAst Supply 4.0 Project and Peppol Logistics Incubation Project.

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.

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 Logistics Advanced 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 or services being delivered, as well as details about the agreed delivery for cross checking with the order and ultimately the Electronic Despatch Advice is used for detailing the delivery.

The main activities supported by this message are:

Transport Full description of how the goods are packed and delivered, or how and when the services are 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 or delivered; the quantity of the delivery and what is outstanding.
Receiving Full support of the process of receiving goods into a warehouse, inventory, in stores or simply at a reception counter or receiving services at agreed location

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.

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)	Defines the role that receives the goods or the service. It also defines the receiver of the Despatch Advice. The real Ship-to Address must be provided in the Delivery Location if the Despatch Advice describes a movement. If the Despatch address describes a service provided at a specific location, the Delivery Location contains this location.
Despatch Party (UBL:DespatchSupplierParty)	Defines the role that provides the goods or the service. It also defines the sender of the Despatch Advice. The real Ship-from Address must be provided in the Despatch Address when the Despatch Advice describes a movement.
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)	For 3PL shipments, this party defines the final receiver of the goods.

Roles

Definition

Consignee

(UBL:DeliveryCustomerParty)

Defines the role that receives the goods or the service. It also defines the receiver of the Despatch Advice. The real Ship-to Address must be provided in the Delivery Location if the Despatch Advice describes a movement. If the Despatch address describes a service provided at a specific location, the Delivery Location contains this location.

Despatch Party

(UBL:DespatchSupplierParty)

Defines the role that provides the goods or the service. It also defines the sender of the Despatch Advice. The real Ship-from Address must be provided in the Despatch Address when the Despatch Advice describes a movement.

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)

For 3PL shipments, this party defines the final receiver of the goods.

The diagram below shows the roles in the fulfillment process.

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
Delivery	Delivery of goods or services as per agreement and conditions described in the Despatch Advice.
Delivery Location	The Delivery Location is used to define the Ship-to when the Delivery Customer Party is not . When the Despatch Advice describes a movement, the Delivery Location should always be included. When the Despatch Advice describes a service given at a location, the Delivery Location describes this location.
Despatch Address	The Despatch Address is used to define the Ship-from when the Despatch Supplier Party is not. When the Despatch Advice describes a movement, the Despatch Address should be included.

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

Delivery

Delivery of goods or services as per agreement and conditions described in the Despatch Advice.

Delivery Location

The Delivery Location is used to define the Ship-to when the Delivery Customer Party is not . When the Despatch Advice describes a movement, the Delivery Location should always be included. When the Despatch Advice describes a service given at a location, the Delivery Location describes this location.

Despatch Address

The Despatch Address is used to define the Ship-from when the Despatch Supplier Party is not. When the Despatch Advice describes a movement, the Despatch Address should be included.

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.

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.

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.

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	The Seller has received one order from the Buyer with 2 lines (2 articles) to be delivered at one delivery address at the same time. The Seller has accepted the order without changes. The Despatch party delivers the complete order as accepted
The flow	The Seller collects the ordered articles The Seller loads the articles in boxes The Despatch party creates a Despatch advice message The Despatch party sends Despatch advice message to the Consignee The Consignee party receives the Despatch advice message The Consignee party uses the content in the Despatch advice message for registration receipt. Two despatch lines, two items (No handling units in the message)
Result	The Despatch advice message helped the Consignee party to prepare receipt At the right time At the right place (address) The Despatch advice message helped the Consignee party in the process of register receipt to identify the Order The order lines The articles The delivered quantity

Use Case number

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

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.
The Seller has accepted the order without changes.
The Despatch party delivers the complete order as accepted

The flow

The Seller collects the ordered articles
The Seller loads the articles in boxes
The Despatch party creates a Despatch advice message
The Despatch party sends Despatch advice message to the Consignee
The Consignee party receives the Despatch advice message
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

The Despatch advice message helped the Consignee party to prepare receipt
1. At the right time
2. At the right place (address)
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

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	The Seller has received one order from the Buyer with 5 lines (5 different items) To be delivered at one delivery address At the same time. The Seller has accepted the order without changes. The Seller can’t deliver the complete order as accepted. The first line contains the ordered quantity The second line contains a delivery of 6 of 10 ordered items. The remaining 4 items will be delivered in another Despatch. The third line contains a delivery of 6 of 10 ordered items. The remaining 4 items will not be delivered. 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. The fifth line contains a delivery of 12 of 10 ordered items.
The flow	The Seller collects the ordered items The Seller loads the articles in boxes The Despatch party creates a Despatch advice message The Despatch party sends Despatch advice message to the Customer The Consignee party receives the Despatch advice message The Consignee party uses the content in Despatch advice message for registration receipt. 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	The Despatch advice message helped the Consignee party to prepare receipt At the right time At the right place (address) The Despatch advice message helped the Consignee party in the process of register receipt to identify the Order The order lines The items The delivered quantity The outstanding quantity to be delivered at a later time The outstanding quantity which will never be delivered

Use Case number

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

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.
The Seller has accepted the order without changes.
The Seller can’t deliver the complete order as accepted.
The first line contains the ordered quantity
The second line contains a delivery of 6 of 10 ordered items. The remaining 4 items will be delivered in another Despatch.
The third line contains a delivery of 6 of 10 ordered items. The remaining 4 items will not be delivered.
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.
The fifth line contains a delivery of 12 of 10 ordered items.

The flow

The Seller collects the ordered items
The Seller loads the articles in boxes
The Despatch party creates a Despatch advice message
The Despatch party sends Despatch advice message to the Customer
The Consignee party receives the Despatch advice message
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

The Despatch advice message helped the Consignee party to prepare receipt
1. At the right time
2. At the right place (address)
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

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	The Despatch Advice has one shipment id (GSIN) assigned by the seller The Despatch Advice has one consignment id which has been assigned by the carrier (GINC) One delivery point (no cross docking) which is identified by a GLN. The four despatch lines are each an orderable unit – a GTIN. Two ordered units (GTINS) are packed on each pallet. There are two pallets in the shipment. Each standard pallet is assigned one logistics’ unit id (SSCC). 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
The flow	The Seller has accepted the order without changes. The Seller collects the ordered goods The ordered goods consist of one pallet per ordered 2 line items. The Despatch party loads the goods onto the transport. The Despatch party sends the Despatch advice to the Consignee The Consignee party receives the Despatch advice message The Consignee party uses the content in the Despatch advice message for registration receipt.
Result	The Despatch advice message helped the Consignee party to prepare for receipt of goods: At the right time At the right location (address) The Despatch advice helped the Consignee party in the process of receipt registration to identify the: Order The order lines The logistics’ handling units The goods description The delivered quantity The parties involved in the process
XML example file	See Appendix A for a sample file illustrating Use Case 3.

Use Case number

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

The Despatch Advice has one shipment id (GSIN) assigned by the seller
The Despatch Advice has one consignment id which has been assigned by the carrier (GINC)
One delivery point (no cross docking) which is identified by a GLN.
The four despatch lines are each an orderable unit – a GTIN.
Two ordered units (GTINS) are packed on each pallet.
There are two pallets in the shipment.
Each standard pallet is assigned one logistics’ unit id (SSCC).
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

The flow

The Seller has accepted the order without changes.

The Seller collects the ordered goods
The ordered goods consist of one pallet per ordered 2 line items.
The Despatch party loads the goods onto the transport.
The Despatch party sends the Despatch advice to the Consignee
The Consignee party receives the Despatch advice message
1. The Consignee party uses the content in the Despatch advice message for registration receipt.

Result

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)
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.

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. Buyer - Endpoint identification. Seller - Organizational identification Seller - Endpoint 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 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.

Buyer - Endpoint identification.

Seller - Organizational identification

Seller - Endpoint 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.

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:

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	The Seller has received one order from the Buyer with 4 lines (4 items) which are priced by the weight To be delivered at one delivery address At the same time. The Seller has accepted the order without changes. The Seller delivers the complete order as accepted. The items are in four separate transport handling units.
The flow	The Seller collects the ordered items The Seller weighs the items. The Seller loads the items into transport handling units (Boxes) The Despatch party creates the Despatch Advice message The Despatch party sends the Despatch Advice message to the Consignee The Consignee party receives the Despatch Advice message The Consignee party uses the content in the Despatch Advice message for registration receipt. Four despatch lines, four items. Handling units are identified using SSCC identifiers The delivered weight is used in the receipt activity (for verification) The Consignee party uses the content in the Despatch Advice message for storing- and handling. Items can be stored by BestBeforeDate or ExpiryDate Items can be stored by batch and/or serial numbers Items can be handled according to the weight of the handling unit
Result	The Despatch Advice message helped the Consignee party to prepare receipt At the right time At the right place (address) With appropriate storage facilities The Despatch Advice message helped the Consignee party in the process of register receipt to identify the Order The order lines The transport handling units The items The delivered quantity/weight

Use Case number

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

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.
The Seller has accepted the order without changes.
The Seller delivers the complete order as accepted.
The items are in four separate transport handling units.

The flow

The Seller collects the ordered items
The Seller weighs the items.
The Seller loads the items into transport handling units (Boxes)
The Despatch party creates the Despatch Advice message
The Despatch party sends the Despatch Advice message to the Consignee
The Consignee party receives the Despatch Advice message
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)
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

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
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

3.4.5. Use case 5 – Services between two locations

This is a simple use case based on the recommended requirements for a Despatch Advice regarding a delivery of services between two locations.

Use Case number	5
Use Case Name	Services between two locations
Use Case Description	Describes a complete process whereby a Despatch party generates a Despatch Advice based on information about the service provided between two locations, e.g. transport of goods or snow plowing. The Despatch Advice enables the service provider to give detailed information about the service provided between the specified locations once the service has been delivered. Which enables a Buyer to reconcile, or confirm, the services provided against the order.
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)
Pre conditions	Services are delivered before Despatch Advice is sent.
Post conditions	Despatch advice is received by the receiver of the services.
Assumptions	The Seller has received one order from the Buyer with one (1) article to be provided between two locations, e.g transport of goods between locations A and B. The Seller has accepted the order without changes. The Despatch party delivers the complete order as accepted
The flow	The Seller arange delivery of agreed services. The Despatch party deliver agreed services. The Despatch party sends Despatch advice message to the Consignee The Consignee party receives the Despatch advice message The Consignee party uses the content in the Despatch advice message for confirmation of delivery.
Result	The Despatch advice message helped the Consignee party to confirm delivery. At the right time At the right location ..(At the correct price) The Despatch advice message helped the Consignee party in the process of confirming delvery to identify the Order The order lines The articles The delivered quantity of services
XML example file	See Appendix A for a sample file illustrating Use Case 5.

Use Case number

Use Case Name

Services between two locations

Use Case Description

Describes a complete process whereby a Despatch party generates a Despatch Advice based on information about the service provided between two locations, e.g. transport of goods or snow plowing.

The Despatch Advice enables the service provider to give detailed information about the service provided between the specified locations once the service has been delivered. Which enables a Buyer to reconcile, or confirm, the services provided against the order.

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)

Pre conditions

Services are delivered before Despatch Advice is sent.

Post conditions

Despatch advice is received by the receiver of the services.

Assumptions

The Seller has received one order from the Buyer with one (1) article to be provided between two locations, e.g transport of goods between locations A and B.
The Seller has accepted the order without changes.
The Despatch party delivers the complete order as accepted

The flow

The Seller arange delivery of agreed services.
The Despatch party deliver agreed services.
The Despatch party sends Despatch advice message to the Consignee
The Consignee party receives the Despatch advice message
The Consignee party uses the content in the Despatch advice message for confirmation of delivery.

Result

The Despatch advice message helped the Consignee party to confirm delivery.
1. At the right time
2. At the right location ..(At the correct price)
The Despatch advice message helped the Consignee party in the process of confirming delvery to identify the
1. Order
2. The order lines
3. The articles
4. The delivered quantity of services

XML example file

See Appendix A for a sample file illustrating Use Case 5.

3.4.6. Use case 6 – Despatch Advice for services provided at one location.

This is a simple use case based on the recommended requirements for a Despatch Advice regarding a delivery of services between two locations.

Use Case number	6
Use Case Name	Despatch Advice for services provided at one location
Use Case Description	Describes a complete process whereby a Despatch party generates a Despatch Advice based on information about the service provided at one location, e.g. leveling or excavation. The Despatch Advice enables the service provider to give detailed information about the service provided at the specified location once the service has been delivered. Which enables a Buyer to reconcile, or confirm, the services provided against the order.
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)
Pre conditions	Services are delivered before Despatch Advice is sent.
Post conditions	Despatch advice is received by the receiver of the services.
Assumptions	The Seller has received one order from the Buyer with one (1) article to be provided at a specified location, e.g excavation of site A The Seller has accepted the order without changes. The Despatch party delivers the complete order as accepted
The flow	The Seller arange delivery of agreed services. The Despatch party deliver agreed services. The Despatch party sends Despatch advice message to the Consignee The Consignee party receives the Despatch advice message The Consignee party uses the content in the Despatch advice message for confirmation of delivery.
Result	The Despatch advice message helped the Consignee party to confirm delivery. At the right time At the right location ..(At the correct price) The Despatch advice message helped the Consignee party in the process of confirming delvery to identify the Order The order lines The articles The delivered quantity of services
XML example file	See Appendix A for a sample file illustrating Use Case 6.

Use Case number

Use Case Name

Despatch Advice for services provided at one location

Use Case Description

Describes a complete process whereby a Despatch party generates a Despatch Advice based on information about the service provided at one location, e.g. leveling or excavation.

The Despatch Advice enables the service provider to give detailed information about the service provided at the specified location once the service has been delivered. Which enables a Buyer to reconcile, or confirm, the services provided against the order.

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)

Pre conditions

Services are delivered before Despatch Advice is sent.

Post conditions

Despatch advice is received by the receiver of the services.

Assumptions

The Seller has received one order from the Buyer with one (1) article to be provided at a specified location, e.g excavation of site A
The Seller has accepted the order without changes.
The Despatch party delivers the complete order as accepted

The flow

The Seller arange delivery of agreed services.
The Despatch party deliver agreed services.
The Despatch party sends Despatch advice message to the Consignee
The Consignee party receives the Despatch advice message
The Consignee party uses the content in the Despatch advice message for confirmation of delivery.

Result

The Despatch advice message helped the Consignee party to confirm delivery.
1. At the right time
2. At the right location ..(At the correct price)
The Despatch advice message helped the Consignee party in the process of confirming delvery to identify the
1. Order
2. The order lines
3. The articles
4. The delivered quantity of services

XML example file

See Appendix A for a sample file illustrating Use Case 6.

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, Appendix 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.

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

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

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

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

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

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

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

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

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 advanced 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. Defines the company that provides the goods or the service. It also defines the sender of the Despatch Advice. The real Ship-from Address must be provided in the Despatch Address when the Despatch Advice describes a movement.

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">7300010000002</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>Receiver 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. For 3PL shipments, this party defines the final receiver of the goods.

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>
                <cbc:Information>ABC123</cbc:Information>
                <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>

6.3.2. Vehicle ID

In some uses of the Despath Advice, there is a need to report the licence plate number or machine number, i.e. the vehicle ID.

Example:

<cbc:Information>ABC123</cbc:Information>

6.4. 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>

6.5. Environmental data

The environmental data on header level resides within the OriginalDespatchTransportationService element and are .Transport Service Code, which is set to a fixed value of FuelReport since this is the only current application .Transport Equipment, where the fuel consumption and related information resides for the transport .Environmental Emission, that can contain CO2 and other emissions related to the transport or other service that consumes fuel.

6.5.1. Fuel

The fuel consumption and related information regarding the fuel type to be used to caculate emissions tor the tansport or other service that consumes fuel.

Example:

<cac:TransportEquipment>
        <cbc:TransportEquipmentTypeCode>Diesel</cbc:TransportEquipmentTypeCode>
        <cbc:Information>ACP Diesel 50 max 7% RME</cbc:Information>
        <cbc:Description>Euro 4</cbc:Description>
        <cac:MeasurementDimension>
                <cbc:AttributeID schemeAgencyName="BEAst">EnergyContent</cbc:AttributeID>
                <cbc:Measure unitCode="XY">32</cbc:Measure>
        </cac:MeasurementDimension>
        <cac:MeasurementDimension>
                <cbc:AttributeID>CONVERSION_FACTOR</cbc:AttributeID>
                <cbc:Measure unitCode="ZX">27</cbc:Measure>
                <cbc:Description>ConversionFactor</cbc:Description>
        </cac:MeasurementDimension>
        <cac:MeasurementDimension>
                <cbc:AttributeID>FUEL_CONSUMPTION</cbc:AttributeID>
                <cbc:Measure unitCode="LTR">15</cbc:Measure>
                <cbc:Description>FuelConsumption</cbc:Description>
        </cac:MeasurementDimension>
        <cac:MeasurementDimension>
                <cbc:AttributeID>DRIVING_DISTANCE</cbc:AttributeID>
                <cbc:Measure unitCode="KMT">86</cbc:Measure>
                <cbc:Description>DrivingDistance</cbc:Description>
        </cac:MeasurementDimension>
        <cac:MeasurementDimension>
                <cbc:AttributeID>DRIVING_TIME</cbc:AttributeID>
                <cbc:Measure unitCode="HUR">7.3</cbc:Measure>
                <cbc:Description>DrivingTime</cbc:Description>
        </cac:MeasurementDimension>
        <cac:MeasurementDimension>
                <cbc:AttributeID>FUEL_MEASUREMENT_BASIS</cbc:AttributeID>
                <cbc:Measure unitCode="KMT">10</cbc:Measure>
                <cbc:Description>FuelMeasurementBasis</cbc:Description>
        </cac:MeasurementDimension>
        <cac:MeasurementDimension>
                <cbc:AttributeID>FUEL_MEASUREMENT_FREQUENCY</cbc:AttributeID>
                <cbc:Measure unitCode="DAY">1</cbc:Measure>
                <cbc:Description>FuelMeasurementFrequency</cbc:Description>
        </cac:MeasurementDimension>
        <cac:ProviderParty>
                <cbc:IndustryClassificationCode>FUEL</cbc:IndustryClassificationCode>
                <cac:PartyIdentification>
                        <cbc:ID schemeID="0007">5560726977</cbc:ID>
                </cac:PartyIdentification>
                <cac:PartyName>
                        <cbc:Name>Preem AB</cbc:Name>
                </cac:PartyName>
        </cac:ProviderParty>
</cac:TransportEquipment>

6.5.2. Environmental Emission

Caculated envionmental emissions related to the transport or other related service that consumes fuel.

Example:

<cac:EnvironmentalEmission>
        <cbc:EnvironmentalEmissionTypeCode>CO2</cbc:EnvironmentalEmissionTypeCode>
        <cbc:ValueMeasure unitCode="MGM">2.8</cbc:ValueMeasure>
        <cbc:Description>CarbonDioxide</cbc:Description>
</cac:EnvironmentalEmission>
<cac:EnvironmentalEmission>
        <cbc:EnvironmentalEmissionTypeCode>NOx</cbc:EnvironmentalEmissionTypeCode>
        <cbc:ValueMeasure unitCode="MGM">6</cbc:ValueMeasure>
        <cbc:Description>NitrogenOxide</cbc:Description>
</cac:EnvironmentalEmission>
<cac:EnvironmentalEmission>
        <cbc:EnvironmentalEmissionTypeCode>CH4</cbc:EnvironmentalEmissionTypeCode>
        <cbc:ValueMeasure unitCode="MGM">0.6</cbc:ValueMeasure>
        <cbc:Description>HydroCarbon</cbc:Description>
</cac:EnvironmentalEmission>
<cac:EnvironmentalEmission>
        <cbc:EnvironmentalEmissionTypeCode>CPM</cbc:EnvironmentalEmissionTypeCode>
        <cbc:ValueMeasure unitCode="MGM">0.07</cbc:ValueMeasure>
        <cbc:Description>ParticulateMatter</cbc:Description>
</cac:EnvironmentalEmission>
<cac:EnvironmentalEmission>
        <cbc:EnvironmentalEmissionTypeCode>REN</cbc:EnvironmentalEmissionTypeCode>
        <cbc:ValueMeasure unitCode="P1">100.00</cbc:ValueMeasure>
        <cbc:Description>RenewableFuel</cbc:Description>
</cac:EnvironmentalEmission>

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>

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

Type	Element `cbc:CustomizationID`	Element `cbc:ProfileID`
Despatch Advice (Trdm120)	urn:fdc:peppol.eu:logistics:trns:advanced_despatch_advice:1	urn:fdc:peppol.eu:logistics:bis:despatch_advice_only:1

Despatch Advice (Trdm120)

urn:fdc:peppol.eu:logistics:trns:advanced_despatch_advice:1

urn:fdc:peppol.eu:logistics:bis:despatch_advice_only:1

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

Logistics Advanced Despatch Advice Only

Link to main site of documentation

1. Introduction to openPEPPOL and BIS

1.1. Background and objective

1.2. Audience

2. Principles and prerequisites

2.1. Despatch Advice message in general

2.2. Parties and roles

2.3. Other important concepts

3. Process and typical scenarios

3.1. Legend for BPMN diagrams

3.2. Simple process – two parties involved

3.3. More advanced process – use of Despatch party

3.4. Typical use cases

3.4.1. Use case 1 - Simple Despatch

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

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

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

3.4.5. Use case 5 – Services between two locations

3.4.6. Use case 6 – Despatch Advice for services provided at one location.

4. Semantic datatypes

4.1. Primitive types

4.2. Semantic data types

4.2.1. Amount

4.2.2. Price Amount

4.2.3. Percentage

4.2.4. Quantity

4.2.5. Code

4.2.6. Identifier

4.2.7. Date

4.2.8. Time

4.2.9. Document Reference

4.2.10. Text

4.2.11. Binary objects

4.2.12. Boolean

5. Code lists

5.1. Code lists for coded elements

5.2. Code list for identifiers

5.2.1. Party identifiers and party legal registration identifier scheme

5.2.2. Electronic address identifier scheme identifier

6. Description of selected parts of the advanced despatch advice message

6.1. Parties

6.1.1. Despatch party (DespatchSupplierParty)

6.1.2. Consignee (DeliveryCustomerParty)

6.1.3. Buyer (BuyerCustomerParty)

6.1.4. Seller (SellerSupplierParty)

6.1.5. Originating party (OriginatorCustomerParty)

6.2. Order reference

6.3. Shipment

6.3.1. Shipment ID

6.3.2. Vehicle ID

6.4. Transport handling unit

6.5. Environmental data

6.5.1. Fuel

6.5.2. Environmental Emission

7. Despatch line

7.1. Item description and identification

7.2. Outstanding quantity

7.3. Hazardous item

7.4. Item properties

7.5. Serial numbers

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

8. Peppol Identifiers

8.1. Profiles and messages

8.2. Customization and Profile identifiers

8.3. Namespaces