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.
Link to main site of documentation
1. Introduction to OpenPeppol and BIS
This Peppol BIS (Business Interoperability Specification) is a result of work within the 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.
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 Transport Execution Plan Request and the Transport Execution Plan message in the European market, and to facilitate an efficient implementation and increased use of electronic collaboration regarding the transportation process based on these formats.
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 with Request.
The Transport Execution Plan Request and the Transport Execution Plan are 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. A Transport Execution Plan Request is used by a Transport User to request if a Transport Service Provider can provide the required service. A Transport Execution Plan is used by the Transport Service Provider as a response to the request from the Transport User. A Transport Execution Plan is also used as a receipt message to confirm or reject a change or cancellation of the plan from either the Transport User or the Transport Service Provider.
A Transport Execution Plan may also be forwarded to a Freight Forwarder or a Carrier involved in the transportation.
2.1. Business processes in scope
The processes covered by this profile are:
-
The Transport Execution Plan Request is sent by the Transport User to request a transportation service.
-
The Application Response is sent by the Transport Service Provider (typically) to confirm or reject that the transportation service can be delivered.
-
The Transportation Status Request is sent from the Transport service provider or the Transport User with the event status 125 (no status) and a description of a question regarding the transportation status he needs an answer for.
-
The Transportation Status is sent fron the opponent (Transport service provider or the Transport User) with the event status 125 (no status) and a description as the answer.
-
The Transport Execution Plan is sent by the Transport Service Provider about the despatch, required delivery service for the goods being sent or other requested transportation service as a final confimation. 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 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 and roles
The table below gives the definitions of the parties and roles involved in the Transport Execution Plan with Request process.
| Business partners | 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, consignor, despatch party, economic operator. |
| Role/actor | Definition |
|---|---|
Sender (cac:SenderParty) |
The party issuing the document.This can be the supplier or the customer or a party on behalf of them. |
Receiver (cac:ReceiverParty) |
The party receiving the document. This can be the supplier or the customer or a party on behalf of them. |
Transport User (cac:TransportUserParty) |
The party requesting the transport services referenced in the Transport Execution Plan Request and the sender of the Transport Execution Plan. |
Transport Service Provider (cac:TransportServiceProviderParty) |
The party providing the transport services referenced in the Transport Execution Plan Request. The receiver of the Transport Execution Plan. |
Consignor (cac:ConsignorParty) |
Consignor is the seller of the goods and is often referred to as the seller or shipper. The role is carried out by the supplier or on behalf of the supplier. |
Consignee (cac:ConsigneeParty) |
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. |
Payee (cac:PayeeParty) |
The party that will pay for the transport service(s) referred to in the Transport Execution Plan. This role is used in the Transport Execution Plan Request. NB! This is the same as BillToParty in the Transport Execution Plan, and PayeeParty will be replaced in the next UBL-version. |
Bill to (cac:BillToParty) |
The party that will pay for the transport service(s) referred to in the Transport Execution Plan. This role is used in the Transport Execution Plan. |
The diagram below shows the roles in the Transport Execution with Request 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. Can be identified by a GS1 GINC (Global Identification Number for Consignments) or an identity in any other format. |
Customs Declaration |
In international trade an important part of the consignment can be information about how do declare the goods for customs. The customs declaration it selft is done in an other process, but information about it can be carried in the consignment. |
Transport Handling Unit |
A description of individual handling units in which the line items are packed. The Transport Handling Unit is identified by a GS1 SSCC. |
GoodsItem |
A goods item is describing a piece of goods during transport. It describes the classification of the goods, the dangerousness, the product numbers, and the instances such as lots and serial numbers. |
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.
3.2. Process overview
The process has four phases:
-
The request for a transportation service by sending a TransportExecutionPlanRequest
-
An initial answer by sending an Application Response
-
A dialog phase with informal messages sent as TransportationStatusRequest og TransportationStatus
-
Sending The agreed Transport Execution Plan
The diagram below gives an overview of the main processes in this profile.
The following section and diagrams show the choreography of the business process involving various parties.
3.3. Typical use cases
3.3.1. Use case 1 – Consignor requests a transport from a Carrier
| Use Case Number | 1 |
|---|---|
Use Case Name |
Consignor requests a transport from a Carrier. |
Use Case Description |
Consignor in the role of Transport User provides instructions to a Carrier in the role of Transport Service Provider for the transport of a consignment. |
Parties involved |
Sender |
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 |
|
XML example file |
See Examples files Appendix A for sample files illustrating Use Case 1. |
3.3.2. Use case 2 – Consignee requests a transport from a Carrier
| Use Case Number | 2 |
|---|---|
Use Case Name |
Consignee requests a transport from a Carrier. |
Use Case Description |
Consignee in the role of Transport User provides instructions to the Carrier in the role of Transport Service Provider for the transport of a consignment. |
Parties involved |
Sender |
Assumptions |
The Consignee has a consignment to be received and has agreed terms with a 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 |
|
XML example file |
See Examples files Appendix A for sample files illustrating Use Case 2. |
3.3.3. Use case 3 – Consignor requests a transport from a Freight Forwarder
| Use Case Number | 3 |
|---|---|
Use Case Name |
Consignor requests a transport from a Freight Forwarder. |
Use Case Description |
Consignor in the role of Transport User provides instructions to the Freight Forwarder in the role of Transport Service Provider for the transport of a consignment. |
Parties involved |
Consignor |
Assumptions |
The Consignor has a consignment to be transported and has agreed terms with the Freight Forwarder for its transportation. The Freight Forwarder chooses a Carrier that 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 |
|
XML example file |
See Examples files Appendix A for sample files illustrating Use Case 3. |
3.3.4. Use case 4 – Carrier request a customs declarations at border crossing from the Freight Forwarder
| Use Case Number | 4 |
|---|---|
Use Case Name |
Two parties involved Carrier acting as the Transport User and Freight Forwarder acting as the Transport Service Provider. |
Use Case Description |
The Carrier provides detailed instructions to the Freigt Forwarder about the goods he is carrying for the customs declarations. |
Parties involved |
Carrier |
Assumptions |
The Carrier is working on a contract with the Freight Forwarder about carrying goods. The Carrier controls what goods there will be picked up in witch truck. The Consignor has a consignment to be transported and knows the type of means of transport required and has agreed terms with the Carrier for its transportation. The consignment has been or will be loaded into one or more specific pieces of transport equipment. The Consignment will be picked up from different addresses. The Carrier has space available on a specific means of transport. The Consignor and the Carrier have a business relationship. The Consignor has ordered transportation from the Carrier. |
The flow |
|
Remarks |
It is assumed the that represent for the Carrier, often the driver and the Freight Forwarder is in direct electronic connection e.g. through a mobile phone during the communication. The goods is considered being uder transport for the use case. |
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. |
| 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. |
| 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.
| 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 |
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 under Code lists in the top-menu bar. There 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 Logistics documents. Below are examples on usage of code lists for identifiers being used in all formats.
5.2. Code list for identifiers - Examples of usage
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 ICD code list.
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 the ICD code list. |
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.
Valid values are found in the EAS code list.
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 Request and Transport Execution Plan.
6.1. Overview
The Advanced Transport Execution Plan includes five different transactions of two kinds * Business information documents Transport Execution Plan Request Transport Execution Plan * Status information documents Application Response Transportation Status Request ** Transportation Status
The business informations documents 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. The goods item contains one item that may have information about commodity codes and desription about dangerous goods.
The status information documents consists besides sender and receiver party of Document Response, Transport Event and document references.
6.2. Parties and roles
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 table below shows how the parties are used in the different transactions:
| Party | Transport Execution Plan Request | Transport Execution Plan | Application Response | Transportation Status Request | Transportation Status |
|---|---|---|---|---|---|
Sender Party |
x |
x |
x |
x |
|
Receiver Party |
x |
x |
x |
x |
|
Transport User Party |
x |
x |
|||
Service Provider Party |
x |
x |
|||
Consignor Party |
x |
x |
|||
Consignee Party |
x |
x |
|||
Payee Party |
x |
||||
BillToParty |
x |
6.2.1. Sender (SenderParty)
The sender is the sender of the document. This is often the same as Transport User for the Transport Execution Plan Request and the Transport Service Provider for the Transport Execution Plan. Example:
6.2.2. Receiver (ReceiverParty)
The Receiver is the sender of the document. This is often the Transport Service Provider but can also be a party who receives it on behalf of the Transport Service Provider. Example:
6.2.3. Transport User (TransportUserParty)
The Transport User is the user of the transport service, often the Consignor when it comes to movement services. For other services like requesting a customs declaration it can also be the carrier.
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>6.2.4. Transport Service Provider (TransportServiceProviderParty)
The Transport Service Provider is the party providing the transport services, often a freight forwarder party.
Example:
<cac:TransportServiceProviderParty>
<cbc:EndpointID schemeID="0198">41955619</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 user</cbc:Name>
<cbc:Telephone>0158 1233714</cbc:Telephone>
<cbc:ElectronicMail>transport-user@transportuser.dk</cbc:ElectronicMail>
</cac:Contact>
</cac:TransportServiceProviderParty>6.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>
<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: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:ConsignorParty>6.2.6. Consignee (ConsigneeParty)
Consignee is known as the DeliveryCustomerParty in the Despatch and receive 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>
<cac:PartyName>
<cbc:Name>HUS Hospital</cbc:Name>
</cac:PartyName>
<cac:PostalAddress>
<cbc:StreetName>Topeliuksenkatu 5</cbc:StreetName>
<cbc:CityName>Helsinki</cbc:CityName>
<cbc:PostalZone>00260</cbc:PostalZone>
<cac:Country>
<cbc:IdentificationCode>FI</cbc:IdentificationCode>
</cac:Country>
</cac:PostalAddress>
<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:ConsigneeParty>6.2.7. Payee (PayeeParty)
Used in the Transport Execution Plan Request to identify the party paying for the transport. NB! This is the same as BillToParty in the Transport Execution Plan, and PayeeParty will be replaced in the next UBL-version.
Example:
<cac:PayeeParty>
<cac:PartyIdentification>
<cbc:ID schemeID="0088">7300010000001</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:AdditionalStreetName>way 1</cbc:AdditionalStreetName>
<cbc:CityName>Køge</cbc:CityName>
<cbc:PostalZone>4600</cbc:PostalZone>
<cbc:CountrySubentity>Region Hovedstaden</cbc:CountrySubentity>
<cac:AddressLine>
<cbc:Line>Bygning 5</cbc:Line>
</cac:AddressLine>
<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:PayeeParty>6.2.8. Bill To (BillToParty)
Used in the Transport Execution Plan to identify the party paying for the transport.
Example:
<cac:BillToParty>
<cac:PartyIdentification>
<cbc:ID schemeID="0088">7300010000001</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:BillToParty>6.3. Document identification
The Transport Execution Plan Request and Transport Execution Plan are identified by the Document ID on header level. The Document ID is also referred to as the Booking identifier.
Example:
<cbc:ID>141278571829041241241</cbc:ID>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. If the ID is a GS1 GINC (Global Identification Number for Consignment), it should be indicated by the attribute @schemeID. If it is not, the attribute can be omitted. This number identifies a consignment, which is a logical grouping of goods (one or more logistics units) transferred to a freight forwarder to be transported for a specific journey. The consignment number must be allocated by a freight forwarder (or a carrier acting as a freight forwarder) or a consignor, but only if prior agreement of the freight forwarder is given.
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:
<cac:PlannedPickupTransportEvent>
<cac:Location>
<cac:Address>
<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:PlannedPickupTransportEvent>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>3</cbc:TransportModeCode>
<cac:TransportMeans>
<cbc:RegistrationNationalityID>NO</cbc:RegistrationNationalityID>
<cac:RoadTransport>
<cbc:LicensePlateID>AB12345</cbc:LicensePlateID>
</cac:RoadTransport>
</cac:TransportMeans>
</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. If the ID has the format of an SSCC, the attribute @schemeID should be included to indicate it. A consignment must have at least one Transport handling unit. Includes the description of the transport equipment related to the transport handling unit and the measurment information with the length, width or height of the goods item.
See also description of Goods item in the next chapter.
The following is an example of a transport handling unit:
<cac:TransportHandlingUnit>
<cbc:ID>1</cbc:ID>
<cbc:TransportHandlingUnitTypeCode>AG</cbc:TransportHandlingUnitTypeCode>
<cac:TransportEquipment>
<cbc:ID>1234567</cbc:ID>
<cbc:TransportEquipmentTypeCode>CN</cbc:TransportEquipmentTypeCode>
</cac:TransportEquipment>
<cac:GoodsItem>
<cbc:ID>1</cbc:ID >
<cbc:Description>Torsk sl u/h fersk fulliset 20kg iso 2-4 kg</cbc:Description>
</cac:GoodsItem>
<cac:ShipmentDocumentReference>
<cbc:ID>243452326</cbc:ID>
<cbc:DocumentTypeCode>N741</cbc:DocumentTypeCode>
</cac:ShipmentDocumentReference>
</cac:TransportHandlingUnit>6.8. Goods item
Goods item describes on a need to know basis an item under transport. The item can be identified with a textual description or an item specification containing the commodity classification and the hazardous information for an item connected to dangerous goods.
Example:
<cac:GoodsItem>
<cbc:ID>10</cbc:ID>
<cbc:Description>Goods item description</cbc:Description>
<cbc:HazardousRiskIndicator>false</cbc:HazardousRiskIndicator>
<cac:Item>
<cbc:Name>Torsk</cbc:Name>
<cac:CommodityClassification>
<cbc:ItemClassificationCode listID="ZZZ" listVersionID="3.0.2" name="SBMI">KO2012140200 </cbc:ItemClassificationCode>
</cac:CommodityClassification>
<cac:HazardousItem>
<cbc:UNDGCode>ADR</cbc:UNDGCode>
<cbc:HazardClassID>2</cbc:HazardClassID>
<cbc:NetWeightMeasure unitCode="KGM">40.8</cbc:NetWeightMeasure>
</cac:HazardousItem>
</cac:Item>
</cac:GoodsItem>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 Request (Trdm123) |
urn:fdc:peppol.eu:logistics:trns:transport_execution_plan_request:1 |
urn:fdc:peppol.eu:logistics:bis:advanced_transport_execution_plan:1 |
Transport Execution Plan (Trdm124) |
urn:fdc:peppol.eu:logistics:trns:transport_execution_plan:1 |
|
Transportation Status Request(Trdm126) |
urn:fdc:peppol.eu:logistics:trns:transportation_status_request:1 |
|
Transportation Status (Trdm127) |
urn:fdc:peppol.eu:logistics:trns:transportation_status:1 |
|
Application Response (Trdm129) |
urn:fdc:peppol.eu:logistics:trns:application_response:1 |
7.3. Namespaces
The Transport Execution Plan Request data model is bound to UBL 2.4 of the document type {ubl-transport-execution-plan-request}. The target namespace for the UBL2.4 TransportExecutionPlanRequest is: urn:oasis:names:specification:ubl:schema:xsd:TransportExecutionPlanRequest-2
The Transport Execution Plan data model is bound to UBL 2.4 of the document type {ubl-transport-execution-plan}. The target namespace for the UBL2.4 TransportExecutionPlan is: urn:oasis:names:specification:ubl:schema:xsd:TransportExecutionPlan-2
The Transportation Status Request data model is bound to UBL 2.3 of the document type {ubl-transportation-status-request}. The target namespace for the UBL2.3 TransportationStatusRequest is: urn:oasis:names:specification:ubl:schema:xsd:TransportationStatusRequest-2
The Transportation Status data model is bound to UBL 2.3 of the document type {ubl-transportation-status}. The target namespace for the UBL2.3 TransportationStatus is: urn:oasis:names:specification:ubl:schema:xsd:TransportationStatus-2
The Application Response data model is bound to {ubl21} of the document type {ubl-application-response}. The target namespace for the UBL2.1 ApplicationResponse is: urn:oasis:names:specification:ubl:schema:xsd:ApplicationResponse-2