The PEPPOL Business Interoperability Specification, “BIS” from here on after, has been developed by the Peppol Logistics Incubation Project and is published as part of the PEPPOL specifications.

Statement of copyright

This PEPPOL Business Interoperability Specification (BIS) document is based on the CEN CWA prepared by the BII workshop specified in the introduction below. The original CEN CWA document contains the following copyright notice which still applies:

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

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

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

Link to main site of documentation

Main documentation site

1. Introduction to OpenPeppol and BIS

This Peppol BIS (Business Interoperability Specification) is a result of work within Peppol Logistics Incubation Project.

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

BII relationship
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 Transport Execution Plan.

The Transport Execution Plan is used to give instructions for the transportation services required for a consignment of goods to any party who is contracted to provide the transportation services. The Transport Execution Plan is initially sent from the Transport Service provider but may later be changed or cancelled by both the Transport User and the Transport Service Provider.

2.1. Business processes in scope

The processes covered by this profile are:

  • The Transport Execution Plan is sent by the Transport Service Provider to inform about the despatch and required delivery service for the goods being sent. Additionally, it can convey details about the goods for cross checking with the order and ultimately the Transport Execution Plan is used for declaring how the despatched goods are to be transported and how they are packed.

  • The Transport Execution Plan may be sent by either the Transport User or the Transport Service Provider to change an existing plan.

  • The Transport Execution Plan may be sent by either the Transport User or the Transport Service Provider to cancel an existing plan.

The main activities supported by this message are:

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

  • The type of transport required for the despatch and delivery of the goods being shipped. The means of transport, routing and arrival details.

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

The diagram below shows the parties and roles in this profile.

image

2.2.1. Receiver (ReceiverParty)

The Receiver is the receiver of the Transport Execution Plan.

Example:

<cac:ReceiverParty>
        <cbc:EndpointID schemeID="0198">13246149</cbc:EndpointID>
        <cac:PartyIdentification>
                <cbc:ID schemeAgencyName="GS1" schemeName="GLN">4058673827000</cbc:ID>
        </cac:PartyIdentification>
        <cac:PartyName>
                <cbc:Name>Consignor</cbc:Name>
        </cac:PartyName>
        <cac:Contact>
                <cbc:Name>SomeName</cbc:Name>
                <cbc:Telephone>+8687878763</cbc:Telephone>
                <cbc:ElectronicMail>SomeName@consignor.cn</cbc:ElectronicMail>
        </cac:Contact>
</cac:ReceiverParty>

2.2.2. Sender (SenderParty)

The Sender is the sender of the Transport Execution Plan.

Example:

<cac:SenderParty>
        <cbc:EndpointID schemeID="0198">13246149</cbc:EndpointID>
        <cac:PartyIdentification>
                <cbc:ID schemeAgencyName="GS1" schemeName="GLN">4058673827641</cbc:ID>
        </cac:PartyIdentification>
        <cac:PartyName>
                <cbc:Name>NECOSS</cbc:Name>
        </cac:PartyName>
        <cac:Contact>
                <cbc:Name>SomeName</cbc:Name>
                <cbc:Telephone>+49450557000</cbc:Telephone>
                <cbc:ElectronicMail>SomeName@necoss.de</cbc:ElectronicMail>
        </cac:Contact>
</cac:SenderParty>

2.2.3. Transport User (TransportUserParty)

The Transport User is the user of the transport service, often the consignor. The Transport User may change or cancel the Transport Execution Plan.

Example:

<cac:TransportUserParty>
        <cbc:EndpointID schemeID="0198">13246149</cbc:EndpointID>
        <cac:PartyIdentification>
                <cbc:ID schemeAgencyName="GS1" schemeName="GLN">4058673827000</cbc:ID>
        </cac:PartyIdentification>
        <cac:PartyName>
                <cbc:Name>Novo Nordisk Pharmatech A/S</cbc:Name>
        </cac:PartyName>
        <cac:PostalAddress>
                <cbc:StreetName>Københavnsvej 216</cbc:StreetName>
                <cbc:CityName>Køge</cbc:CityName>
                <cbc:PostalZone>4600</cbc:PostalZone>
                <cac:Country>
                        <cbc:IdentificationCode>DK</cbc:IdentificationCode>
                </cac:Country>
        </cac:PostalAddress>
        <cac:PartyTaxScheme>
                <cbc:CompanyID>GB325456788</cbc:CompanyID>
                <cac:TaxScheme>
                        <cbc:ID>VAT</cbc:ID>
                </cac:TaxScheme>
        </cac:PartyTaxScheme>
        <cac:PartyLegalEntity>
                <cbc:RegistrationName>Consortial</cbc:RegistrationName>
                <cbc:CompanyID schemeID="0089">SC234567</cbc:CompanyID>
                <cac:RegistrationAddress>
                        <cbc:CityName>Farthing</cbc:CityName>
                        <cac:Country>
                                <cbc:IdentificationCode>GB</cbc:IdentificationCode>
                        </cac:Country>
                </cac:RegistrationAddress>
        </cac:PartyLegalEntity>
        <cac:Contact>
                <cbc:Name>Mr Transport user</cbc:Name>
                <cbc:Telephone>0158 1233714</cbc:Telephone>
                <cbc:ElectronicMail>transport-user@transportuser.dk</cbc:ElectronicMail>
        </cac:Contact>
</cac:TransportUserParty>

2.2.4. Transport Service Provider (TransportServiceProviderParty)

The Transport Service Provider is the sender of the original Transport Execution Plan and later changes to the plan.

Example:

<cac:TransportServiceProviderParty>
        <cbc:EndpointID schemeID="0198">13246149</cbc:EndpointID>
        <cac:PartyIdentification>
                <cbc:ID schemeAgencyName="GS1" schemeName="GLN">4058673827641</cbc:ID>
        </cac:PartyIdentification>
        <cac:PartyName>
                <cbc:Name>Leman</cbc:Name>
        </cac:PartyName>
        <cac:PostalAddress>
                <cbc:StreetName>Ventrupvej 6</cbc:StreetName>
                <cbc:CityName>Greve</cbc:CityName>
                <cbc:PostalZone>2670</cbc:PostalZone>
                <cac:Country>
                        <cbc:IdentificationCode>DK</cbc:IdentificationCode>
                </cac:Country>
        </cac:PostalAddress>
        <cac:PartyTaxScheme>
                <cbc:CompanyID>GB325456788</cbc:CompanyID>
                <cac:TaxScheme>
                        <cbc:ID>VAT</cbc:ID>
                </cac:TaxScheme>
        </cac:PartyTaxScheme>
        <cac:PartyLegalEntity>
                <cbc:RegistrationName>Consortial</cbc:RegistrationName>
                <cbc:CompanyID schemeID="0089">SC234567</cbc:CompanyID>
                <cac:RegistrationAddress>
                        <cbc:CityName>Farthing</cbc:CityName>
                        <cac:Country>
                                <cbc:IdentificationCode>GB</cbc:IdentificationCode>
                        </cac:Country>
                </cac:RegistrationAddress>
        </cac:PartyLegalEntity>
        <cac:Contact>
                <cbc:Name>Mr Transport provider</cbc:Name>
                <cbc:Telephone>0158 1233714</cbc:Telephone>
                <cbc:ElectronicMail>post@transportprovider.dk</cbc:ElectronicMail>
        </cac:Contact>
</cac:TransportServiceProviderParty>

2.2.5. Consignor (ConsignorParty)

Consignor, also known as the shipper, is the sender of the goods. The Consignor is often the buyer of the freight services. If the Consignor is the same for all consignments in the Waybill, the consignor can be described on the document level instead of in each consignment.

Example:

<cac:ConsignorParty>
        <cbc:EndpointID schemeID="0198">13246149</cbc:EndpointID>
        <cac:PartyIdentification>
                <cbc:ID schemeAgencyName="GS1" schemeName="GLN">4058673827000</cbc:ID>
        </cac:PartyIdentification>
        <cac:PartyName>
                <cbc:Name>Consignor</cbc:Name>
        </cac:PartyName>
        <cac:PostalAddress>
                <cbc:ID schemeAgencyName="GS1" schemeName="GLN">4058673827000</cbc:ID>
        </cac:PostalAddress>
        <cac:PartyLegalEntity>
                <cbc:RegistrationName>Novo Nordisk Pharmatech A/S</cbc:RegistrationName>
                <cbc:CompanyID schemeID="0198">13246149 </cbc:CompanyID>
                <cac:RegistrationAddress>
                        <cbc:CityName>Køge</cbc:CityName>
                        <cac:Country>
                                <cbc:IdentificationCode>DK</cbc:IdentificationCode>
                        </cac:Country>
                </cac:RegistrationAddress>
        </cac:PartyLegalEntity>
        <cac:Contact>
                <cbc:Name>SomeName</cbc:Name>
                <cbc:Telephone>+8676576456</cbc:Telephone>
                <cbc:ElectronicMail>SomeName@consignor.cn</cbc:ElectronicMail>
        </cac:Contact>
</cac:ConsignorParty>

2.2.6. Consignee (ConsigneeParty)

Consignee is known as the DeliveryCustomerParty in the Despatch Advice. The Consignee is the person or organisation 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 a mandatory party in the consignment element and can be the Transportation Buyer.

Example:

<cac:ConsigneeParty>
        <cbc:EndpointID schemeID="0198">13246149</cbc:EndpointID>
        <cac:PartyIdentification>
                <cbc:ID schemeAgencyName="GS1" schemeName="GLN">4058673827123</cbc:ID>
        </cac:PartyIdentification>
        <cac:PartyName>
                <cbc:Name>Consignee</cbc:Name>
        </cac:PartyName>
        <cac:PartyLegalEntity>
                <cbc:RegistrationName>HUS Hospital </cbc:RegistrationName>
                <cbc:CompanyID schemeID="0212">1567535-0 </cbc:CompanyID>
                <cac:RegistrationAddress>
                        <cbc:CityName>Helsinki </cbc:CityName>
                        <cac:Country>
                                <cbc:IdentificationCode>FI </cbc:IdentificationCode>
                        </cac:Country>
                </cac:RegistrationAddress>
        </cac:PartyLegalEntity>
        <cac:Contact>
                <cbc:Name>SomeName</cbc:Name>
                <cbc:Telephone>+4987878763</cbc:Telephone>
                <cbc:ElectronicMail>SomeName@consignee.de</cbc:ElectronicMail>
        </cac:Contact>
</cac:ConsigneeParty>

2.2.7. Carrier (CarrierParty)

Carrier is the party providing the transport of goods between named points.

Example:

<cac:CarrierParty>
        <cac:PartyName>
                <cbc:Name>Finnair Oyj</cbc:Name>
        </cac:PartyName>
        <cac:PostalAddress>
                <cbc:StreetName>Tietotie 9</cbc:StreetName>
                <cbc:CityName>Vantaa</cbc:CityName>
                <cbc:PostalZone>4600</cbc:PostalZone>
                <cac:Country>
                        <cbc:IdentificationCode>FI </cbc:IdentificationCode>
                </cac:Country>
        </cac:PostalAddress>
        <cac:PartyLegalEntity>
                <cbc:RegistrationName>Leman </cbc:RegistrationName>
                <cbc:CompanyID schemeID="0212">0108023-3 </cbc:CompanyID>
                <cac:RegistrationAddress>
                        <cbc:CityName>Vantaa </cbc:CityName>
                        <cac:Country>
                                <cbc:IdentificationCode>FI </cbc:IdentificationCode>
                        </cac:Country>
                </cac:RegistrationAddress>
        </cac:PartyLegalEntity>
</cac:CarrierParty>
<cac:CarrierParty>
        <cac:PartyName>
                <cbc:Name>MAERSK</cbc:Name>
        </cac:PartyName>
        <cac:Contact>
                <cbc:Name>SomeName</cbc:Name>
                <cbc:Telephone>+4598786765</cbc:Telephone>
                <cbc:ElectronicMail>SomeName@maersk.dk</cbc:ElectronicMail>
        </cac:Contact>
</cac:CarrierParty>

2.3. Other important concepts

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

Term Definition

Shipment

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

Consignment

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

Transport Handling Unit

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

Master Data

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

Logistics Label

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

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

image

3.2. Process overview

The diagram below gives an overview of the main processes in this profile.

image

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

3.3. Initial Transport Execution Plan from Transport Service Provider

The following diagram shows a process where the Transport Service Provider sends an initial Transport Execution Plan to the Transport Service User. The Transport Execution Plan is sent

image

Parties involved:

Transport Service Provider: The party sending the Transport Execution Plan.

Transport User: The party receiving the Transport Execution Plan.

3.4. Change of Transport Execution Plan

3.4.1. Change of Transport Execution Plan from Transport User

The following diagram shows a process where the Transport User changes an existing Transport Execution Plan. The change must have been agreed with the Transport Service Provider before the change is sent.

image

Parties involved:

Transport User: The party sending a change to a Transport Execution Plan.

Transport Service Provider: The party receiving a change to a Transport Execution Plan.

3.4.2. Change of Transport Execution Plan from Transport Service Provider

The following diagram shows a process where the Transport Service Provider changes an existing Transport Execution Plan. The change must have been agreed with the Transport User before the change is sent.

image

Parties involved:

Transport User: The party receiving a change to a Transport Execution Plan.

Transport Service Provider: The party sending a change to a Transport Execution Plan.

3.5. Cancellation of Transport Execution Plan

3.5.1. Cancellation of Transport Execution Plan from Transport User

The following diagram shows a process where the Transport User cancels an existing Transport Execution Plan. The cancellation must have been agreed with the Transport Service Provider before the cancellation is sent.

image

Parties involved:

Transport User: The party sending a cancellation of a Transport Execution Plan.

Transport Service Provider: The party receiving a cancellation of a Transport Execution Plan.

3.5.2. Cancellation of Transport Execution Plan from Transport Service Provider

The following diagram shows a process where the Transport Service Provider cancels an existing Transport Execution Plan. The cancellation must have been agreed with the Transport User before the cancellation is sent.

image

Parties involved:

Transport User: The party receiving a cancellation of a Transport Execution Plan.

Transport Service Provider: The party sending a cancellation of a Transport Execution Plan.

3.6. Typical use cases

3.6.1. Use case 1 – Consignor and Carrier plan a transport

Use Case Number 1

Use Case Name

Consignor and Carrier plan a transport.

Use Case Description

Consignor in the role of Transport User and Carrier in the role of Transport Service Provider exchange a Transport Execution Plan to plan a transport of a consignment.

Parties involved

Consignor
Carrier

Assumptions

The Consignor has a consignment to be transported and has agreed terms with the Carrier for its transportation.

The Carrier has space available on a specific means of transport.

The consignment has been or will be loaded into one or more specific pieces of transport equipment.

The flow

  1. The Carrier as Transport Service Provider sends a Transport Execution Plan to a Consignor as Transport User based on agreed terms.

  2. The Consignor or the Carrier may update the content of the plan by returning a Transport Execution Plan with changes.

  3. The Transport Execution Plan may also be cancelled by both the Consignor and the Carrier.

  4. The Consignor packs the goods ready for collection by the Carrier.

  5. The Carrier collects the Shipment and transports it to the Consignee.

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.

4.2. Semantic data types

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

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

4.2.1. Amount

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

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

Content

Mandatory

Decimal

10000.25

4.2.2. Price Amount

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

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

Content

Mandatory

Decimal

10000.1234

4.2.3. Percentage

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

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

Content

Mandatory

Decimal

34.7812

4.2.4. Quantity

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

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

Content

Mandatory

Decimal

10000.1234

4.2.5. Code

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

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

Content

Mandatory

String

Abc123

4.2.6. Identifier

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

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

Content

Mandatory

String

abc:123-DEF

Scheme identifier

Conditional

String

0088

Scheme version identifier

Conditional

String

1.0

4.2.7. Date

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

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

Content

Mandatory

Date

2017-12-01

4.2.8. Time

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

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

Content

Mandatory

Date

09:30:12

4.2.9. Document Reference

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

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

Content

Mandatory

String

abc:123-DEF

4.2.10. Text

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

Component Use Primitive Type Example

Content

Mandatory

String

5% allowance when paid within 30 days

4.2.11. Binary objects

Binary objects can be used to describe files which are transmitted together with the business document. Attachments shall be transmitted together with the business document. The binary object has two supplementary components: a Mime Code, which specifies the Mime type of the attachment and a Filename that is provided by (or on behalf of) the sender of the business document.

Component Use Primitive Type Example

Content

Mandatory

Binary

QmFzZTY0IGNvbnRlbnQgZXhhbXBsZQ==

Mime Code

Mandatory

String

image/jpeg

Filename

Mandatory

String

drawing5.jpg

4.2.12. Boolean

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

Component Use Primitive Type Example

Content

Mandatory

String

true

5. Code lists

5.1. Code lists for coded elements

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

5.2. Code list for identifiers

5.2.1. Party identifiers and party legal registration identifier scheme

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

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

5.2.2. Electronic address identifier scheme identifier

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

Valid values are found here: EAS codes.

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

6. Description of selected parts of the Transport Execution Plan.

6.1. Overview

The Transport Execution Plan consist of one consignment, a number of document references, a signature (optional) and several parties.

The consignment refers to a shipment and describes the transport events, the shipment stages, the transport contract and the transport handling units that carries the goods items in the consignment. The transport handling unit can use some transport equipment e.g., a container that again has seals (not displayed in the figure). The goods items in in transport handling unit refers to the package where they are contained, and a package can contain other packages. In this way the package becomes the placeholder for the barcodes and other stuff physical identified. The goods item contains one item that can consist of several item instances (from different lots etc.) and can also refer to a description of dangerous goods.

image

6.2. Document identification

The Transport Execution Plan is identified by the Document ID on header level. The Document ID is also referred to as the Booking identifier.

Example:

<cbc:ID>TEP_1</cbc:ID>

6.3. Shipment

A shipment is the contractual arrangement whereby an identifiable collection of goods items is to be transported from one party (the Consignor) to another party (Consignee). The Shipment is a mandatory element in the Transport Execution Plan. There is one and only one shipment in a Transport Execution Plan. A Shipment contains the consignment and the Goods Items being transported. The shipment ID is an important identifier that tracks the transport of the goods, door to door.

6.4. Consignment

A consignment is the transportation of an identifiable collection of goods items from one party (the consignor) to another (the consignee) via one or more modes of transport. There are often conflicts between the terms "Shipment" and "Consignment", but in this model the Shipment is focused on the contract and the movement of the goods (what is being shipped), while the Consignment is focused on the service of moving the goods (how it will be done). The consignment can consist of a number of transport handling units, the shipment stages relate to how they are transported and the events during the transport.

6.5. Transport event

The transport event supports an event-oriented document exchange. It represents a time and a location where the event took or is supposed to take place. The context (name) of the event indicates why it is applied. The transport events used in the Transport Execution Plan are:

  • Requested Pickup Transport Event

  • Actual Pickup Transport Event

  • Requested Delivery Transport Event

  • Actual Delivery Transport Event

  • Estimated Departure Transport Event

  • Estimated Arrival Transport Event

  • Transport Event (general)

The difference in requested and actual is that the requested event comes from the Transport user and the actual event comes from the Transport service provider. An example of a transport event is shown below:

6.6. Shipment stage

The shipment stage describes a stage of a shipment. This can be from door to door, from door to terminal or form terminal to door. A shipment stage has at least one transport mode and one carrier Party. If the carriers are the same for all shipment stages, it can be defined in the consignment. In a consignment there can be many shipment stages, that is:

  • Main carriage. The shipment stage that is the primary leg for the shipment often used for carrying the goods from on country to another or from one harbour (or airport) or another. For trucks and rails, it can be fixed long distance routes.

  • Pre carriage. The transport from the first pickup to a terminal or port. There can be many pre carriages per consignment

  • On carriage. The transport from the arrival port or terminal of the main carriage on the way to the final destination. The shipment stage serves to list the route for the shipment. There can be transport event defined at departure or at arrival.

Example:

<cac:MainCarriageShipmentStage>
        <cbc:TransportModeCode>4 </cbc:TransportModeCode>
        <cbc:HazardousRiskIndicator>false </cbc:HazardousRiskIndicator>
        <cac:CarrierParty>
                <cac:PartyName>
                        <cbc:Name>Finnair Oyj</cbc:Name>
                </cac:PartyName>
                <cac:PostalAddress>
                        <cbc:StreetName>Tietotie 9</cbc:StreetName>
                        <cbc:CityName>Vantaa</cbc:CityName>
                        <cbc:PostalZone>4600</cbc:PostalZone>
                        <cac:Country>
                                <cbc:IdentificationCode>FI </cbc:IdentificationCode>
                        </cac:Country>
                </cac:PostalAddress>
                <cac:PartyLegalEntity>
                        <cbc:RegistrationName>Leman </cbc:RegistrationName>
                        <cbc:CompanyID schemeID="0212">0108023-3 </cbc:CompanyID>
                        <cac:RegistrationAddress>
                                <cbc:CityName>Vantaa </cbc:CityName>
                                <cac:Country>
                                        <cbc:IdentificationCode>FI </cbc:IdentificationCode>
                                </cac:Country>
                        </cac:RegistrationAddress>
                </cac:PartyLegalEntity>
        </cac:CarrierParty>
        <cac:TransportMeans>
                <cac:AirTransport>
                        <cbc:AircraftID>JA8088 </cbc:AircraftID>
                </cac:AirTransport>
        </cac:TransportMeans>
        <cac:PlannedDepartureTransportEvent>
                <cac:Location>
                        <cac:Address>
                                <cbc:ID schemeAgencyName="UN" schemeName="UN/LOCODE">DEHAM</cbc:ID>
                                <cbc:StreetName>Neuer Wandrahm 4</cbc:StreetName>
                                <cbc:CityName>Hamburg</cbc:CityName>
                                <cbc:PostalZone>29400</cbc:PostalZone>
                                <cac:Country>
                                        <cbc:IdentificationCode>DE</cbc:IdentificationCode>
                                </cac:Country>
                        </cac:Address>
                </cac:Location>
                <cac:Period>
                        <cbc:StartDate>2011-10-03</cbc:StartDate>
                        <cbc:StartTime>09:30:10+01:00</cbc:StartTime>
                        <cbc:EndDate>2011-10-03</cbc:EndDate>
                        <cbc:EndTime>12:30:10+01:00</cbc:EndTime>
                </cac:Period>
        </cac:PlannedDepartureTransportEvent>
        <cac:PlannedArrivalTransportEvent>
                <cac:Location>
                        <cac:Address>
                                <cbc:StreetName>Grosse strasse 34</cbc:StreetName>
                                <cbc:CityName>Nurnberg</cbc:CityName>
                                <cbc:PostalZone>28400</cbc:PostalZone>
                                <cac:Country>
                                        <cbc:IdentificationCode>DE</cbc:IdentificationCode>
                                </cac:Country>
                        </cac:Address>
                </cac:Location>
                <cac:Period>
                        <cbc:StartDate>2011-10-06</cbc:StartDate>
                        <cbc:StartTime>12:30:10+01:00</cbc:StartTime>
                        <cbc:EndDate>2011-10-06</cbc:EndDate>
                        <cbc:EndTime>15:30:10+01:00</cbc:EndTime>
                </cac:Period>
        </cac:PlannedArrivalTransportEvent>
</cac:MainCarriageShipmentStage>

6.7. Transport handling unit

Transport handling units are the units dealt with under transport. It describes a uniquely identifiable unit consisting of one or more packages, goods items, or pieces of transport equipment. A consignment must have at least one Transport handling unit. The following is an example of a transport handling unit:

<cac:TransportHandlingUnit>
        <cbc:ID>CON_THU_1</cbc:ID>
        <cbc:TransportHandlingUnitTypeCode>4</cbc:TransportHandlingUnitTypeCode>
        <cbc:HazardousRiskIndicator>false</cbc:HazardousRiskIndicator>
        <cbc:TotalGoodsItemQuantity>500</cbc:TotalGoodsItemQuantity>
        <cbc:TotalPackageQuantity>10</cbc:TotalPackageQuantity>
        <cbc:ShippingMarks>General Cargo</cbc:ShippingMarks>
        <cac:TransportEquipment>
                <cbc:ID>CON_TE_1</cbc:ID>
                <cbc:TransportEquipmentTypeCode>CN</cbc:TransportEquipmentTypeCode>
                <cbc:RefrigeratedIndicator>false</cbc:RefrigeratedIndicator>
                <cbc:Description>SomeDescription</cbc:Description>
                <cbc:PowerIndicator>false</cbc:PowerIndicator>
        </cac:TransportEquipment>
        <cac:MeasurementDimension>
                <cbc:AttributeID>Length</cbc:AttributeID>
                <cbc:Measure unitCode="MTR">6.1</cbc:Measure>
        </cac:MeasurementDimension>
        <cac:MeasurementDimension>
                <cbc:AttributeID>Height</cbc:AttributeID>
                <cbc:Measure unitCode="MTR">2.6</cbc:Measure>
        </cac:MeasurementDimension>
        <cac:MeasurementDimension>
                <cbc:AttributeID>Width</cbc:AttributeID>
                <cbc:Measure unitCode="MTR">2.44</cbc:Measure>
        </cac:MeasurementDimension>
        <cac:Package>
                <cbc:ID>CON_P_1</cbc:ID>
                <cbc:Quantity>10</cbc:Quantity>
                <cbc:PackagingTypeCode>PL</cbc:PackagingTypeCode>
                <cac:GoodsItem>
                        <cac:Item>
                                <cac:CommodityClassification>
                                        <cbc:CargoTypeCode>12</cbc:CargoTypeCode>
                                </cac:CommodityClassification>
                        </cac:Item>
                </cac:GoodsItem>
        </cac:Package>
</cac:TransportHandlingUnit>

6.8. Transport equipment

The transport equipment describes the equipment related to the transport handling unit.

Example:

<cac:TransportEquipment>
        <cbc:ID>CON_TE_1</cbc:ID>
        <cbc:TransportEquipmentTypeCode>CN</cbc:TransportEquipmentTypeCode>
        <cbc:RefrigeratedIndicator>false</cbc:RefrigeratedIndicator>
        <cbc:Description>SomeDescription</cbc:Description>
        <cbc:PowerIndicator>false</cbc:PowerIndicator>
</cac:TransportEquipment>

6.9. Goods item

A goods item specifies an item under transport. It is used to specify the goods that is transported. A goods item can consist of one or more items.

Example:

6.10. Measurement dimension

Information ablut the length, width or height of the goods item.

Example:

6.11. Item instance

The Item instance describes the physical properties for an item, that can differ from item to item. The item instance is often not known before the time of delivery.

Example:

6.12. Hazardous item

The hazardous items describe the properties for an item connected to the dangerous goods.

Example:

6.13. Pickup

In case a goods item needs to be picked up separately, the pickup component can be used.

Example:

Unresolved directive in description/index.adoc - include::package.adoc[]

6.14. Document reference

A reference to other documents relevant for this Transport Execution Plan.

Example:

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

Transport execution plan (Trdm123)

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

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

7.3. Namespaces

The Transport Execution Plan data model is bound to UBL 2.3 of the document type UBL Transport Execution Plan 2.3. The target namespace for the UBL2.3 TransportExecutionPlan is: urn:oasis:names:specification:ubl:schema:xsd:TransportExecutionPlan-2