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 (Business Interoperability Specification) is a result of work within BEAst Supply 4.0 Project and Peppol Logistics Incubation Project. After the incubation project it will be part of the specifications in new Logistics domain in OpenPeppol.

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 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 with Response.

2.1. Business process in scope

This Peppol BIS supports a process for suppliers to send an Advanced Despatch Advice and for buyers to return an Advanced Despatch Advice Response. It is intended to support transmission of electronic messages for processing in automated processes by the receiver.

The main activities supported by this BIS 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
Responding Response from the buyer with two alternative usages:
- a) Report status of the receipt of an Advanced Despatch Advice message
- b) Report status on the actual delivery

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 it differs from what is in the Delivery Customer Party.
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 if it differs from what is in Despatch Supplier Party.
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 it differs from what is in the Delivery Customer Party.

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 if it differs from what is in Despatch Supplier Party.

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. If the Delivery Location is omitted, the Delivery Customer Party is the actual Delivery Location
Despatch Address	The Despatch Address is used to define the Ship-from when the Despatch Supplier Party is not. If the Dedspatch Address is omitted, the Despatch Supplier Party is the actual Despatch Address

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. If the Delivery Location is omitted, the Delivery Customer Party is the actual Delivery Location

Despatch Address

The Despatch Address is used to define the Ship-from when the Despatch Supplier Party is not. If the Dedspatch Address is omitted, the Despatch Supplier Party is the actual Despatch Address

3. Process and use cases

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. Scenario 1 - Process with response before the delivery of the goods

This process implies the sending of an Advanced Despatch Advice and return of the Advanced Despatch Advice Response before the actual delivery has taken place. This enables the parties to correct any errors in the transactions and/or the delivery before the goods are transported from the Despatch party.

An Advanced Despatch Advice sent before the delivey should have a defined DespatchAdviceTypeCode.

The following controls should be done by the consignee after reception of the Advanced Despatch Advice:

Check that the message validates OK against all business rules
Check that the order reference is correct
Check that any other references are correct

3.3. Scenario 2 - Process with response after the delivery of the goods

This process implies the sending of an Advanced Despatch Advice and return of the Advanced Despatch Advice Response after the actual delivery has taken place. This enables the Consignee also to approve or reject the actual delivery of the goods.

3.4. Typical use cases

The uses cases for this BIS are the same as the use cases described in the BIS for Advanced Despatch Advice. Example files for Despatch Advice in Appendix A are also the same except for different CustomizationID and ProfileID. Example files for Despatch Advice Response are included in Appendix A.

See Examples files Appendix A for example files.

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 Despatch Advice Response

Description of selected parts of Advanced Despatch Advice can be found in the BIS for Advanced Despatch Advice.

6.1. Parties

The following parties/roles are mandatory in the message.

6.1.1. Sender party (SenderParty)

The party sending an electronic message level response message back to the sending party of the business document.

Example:

<cac:SenderParty>
    <cbc:EndpointID schemeID="0192">987654325</cbc:EndpointID>
</cac:SenderParty>

6.1.2. Receiver party (ReceiverParty)

The party the Despatch Advice Response message was addressed to, and who is supposed to process the response. This is the same party as the sender of the business document.

Example:

<cac:ReceiverParty>
    <cbc:EndpointID schemeID="0088">7315458756328</cbc:EndpointID>
</cac:ReceiverParty>

6.2. Document response

Used to provide information about the status of the response with a status code and a description. Legal values for status code according to Application Response type code (UNCL4343 Subset):

AB = Message acknowledgement (before delivery of goods)
AP = Accepted (after delivery of goods)
RE = Rejected

Example:

<cac:Response>
    <cbc:ResponseCode>AB</cbc:ResponseCode>
    <cbc:Description>The document was accepted without any validations being performed.</cbc:Description>
</cac:Response>

6.3. Document reference

The document reference is used to provide a reference to the envelope of the business document on which the Despatch Advice Response is based. The Despatch Advice Response may only contain one business document. The element 'cac:DocumentResponse/cac:DocumentReference/cbc:ID' MUST contain the instance identifier of the envelope of the original business document.

Example:

<cac:DocumentReference>
          <cbc:ID>EnvelopeID-12456789</cbc:ID>
</cac:DocumentReference>

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

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

7.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`
Advanced Despatch Advice (Trdm120)	urn:fdc:peppol.eu:logistics:trns:advanced_despatch_advice:1	urn:fdc:peppol.eu:logistics:bis:despatch_advice_w_receipt_advice:1
Receipt Advice (Trdm128)	urn:fdc:peppol.eu:logistics:trns:receipt_advice:1

Advanced Despatch Advice (Trdm120)

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

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

Receipt Advice (Trdm128)

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

7.3. Namespaces

The despatch advice data reponse model is bound to UBL 2.1 of the document type UBL Application Response 2.1. The target namespace for the UBL 2.1 Application Response is:

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