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

Statement of copyright

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

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

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

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

Link to main site of documentation

Main documentation site

1. Introduction to openPEPPOL and BIS

This BIS is a result of work within BEAst Supply 4.0 Project and Peppol Logistics Incubation Project.

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

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

1.1. Background and objective

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

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

1.2. Audience

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

These organizations may be:

  • Service providers

  • Contracting Authorities

  • Economic Operators

  • Software Developers

More specifically it is addressed towards the following roles:

  • ICT Architects

  • ICT Developers

  • Business Experts

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

2. Principles and prerequisites

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

2.1. Despatch Advice message in general

The electronic transaction described in this implementation guide is the Despatch Advice message. The Despatch Advice message is used in the fulfillment process by the supplier to notify the receiver about, the despatch and delivery period for the goods or services being delivered, as well as details about the agreed delivery for cross checking with the order and ultimately the Electronic Despatch Advice is used for detailing the delivery.

The main activities supported by this message are:

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

  • Ordering States what is shipped or delivered; the quantity of the delivery and what is outstanding.

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

2.2. Parties and roles

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

Parties Definition

Customer

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

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

Supplier

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

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

Carrier

The carrier handles the physical delivery/transportation of the despatched shipment. Used if a third party is handling the physical transport.
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.

image

2.3. Other important concepts

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

Term Definition

Shipment

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

Consignment

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

Transport Handling Unit

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

Master Data

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

Logistics Label

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

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

3.1. Legend for BPMN diagrams

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

image

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

3.2. Simple process – two parties involved

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

image

3.3. More advanced process – use of Despatch party

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

image

3.4. Typical use cases

The table below lists the twelve use cases.

Use Case Number Definition Link

1

Despatch Advice for goods (not bulk goods) where the Receiver is responsible for transportation.

Link to use case 1

2

Despatch Advice for transport of goods (not bulk goods) where the Supplier is responsible for transportation.

Link to use case 2

3

Despatch Advice for services provided at one location without vehicle

Link to use case 3

4

Despatch Advice for services provided at one location using a vehicle.

Link to use case 4

5

Despatch Advice for services between two locations, including a vehicle.

Link to use case 5

6

Despatch Advice for bulk goods

Link to use case 6

7

Despatch Advice for bulk goods including the transport

Link to use case 7

8

Despatch Advice for waste treatment service, no transport.

Link to use case 8

9

Despatch Advice for waste treatment service, including the transport.

Link to use case 9

10

Despatch Advice for transport of bulk goods (service only)

Link to use case 10

11

Despatch Advice for transport of non-bulk goods (service only)

Link to use case 11

12

Despatch Advice for transports where Serial IDs must be kept track of in where they are packed.

Link to use case 12

3.4.1. Use case 1 – Despatch Advice for goods (not bulk goods) where the Receiver is responsible for transportation.

This use case is based on the recommended requirements for a Despatch Advice that informs the Consignee that goods is ready to be picked up.

Use Case number 1

Use Case Name

Despatch Advice for goods (not bulk goods) where the Receiver is responsible for transportation.

Use Case Description

Describes a complete process whereby a Despatch party generates a Despatch Advice containing information about the goods that is ready to be picked up. It always contains Items and Quantities but can also include a list of Transport Handling Units and a full description of how the goods is packed. It also can contain information about Environmental data (EPD) and Dangerous Goods.

The Despatch Advice enables the goods provider to give full information about the goods that is ready to be picked up. This enables the Receiver to plan the pick-up and to reconcile the shipment with the order and manage any difference.

Parties involved

Buyer (In UBL: BuyerCustomerParty)

Seller (In UBL: SellerSupplierParty)

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

Consignee party (In UBL: DeliveryCustomerParty) (Same legal entity as the Buyer, but different address in this use case).

Pre conditions

Despatch Advice is sent when goods is ready to be picked up. Supplier is not responsible for transportation.

Post conditions

Despatch advice is received by the receiver of the goods.

Assumptions

  1. The Seller has received one order from the Buyer with one (1) article to be picked up by the Customer at the Supplier’s site on a specific date.

  2. The Seller has accepted the order without changes.

  3. The Despatch party delivers the complete order as accepted

The flow

  1. The Despatch party picks and packs the ordered quantity of the item.

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

  3. The Consignee party receives the Despatch advice message

  4. The Consignee party uses the content in the Despatch advice message to check it against the order, and to plan the pick-up of the goods.

  5. The goods is picked up by the Carrier Party contracted by the Consignee party to pick the goods up.

  6. The goods is delivered to the Consignee party.

Result

  1. The Despatch advice message helped the Consignee party to plan the pick-up and to confirm delivery.

    1. At the right time

    2. At the right location

    3. At the correct transportation price

  2. The Despatch advice message helped the Consignee party in the process of confirming delvery to identify the

    1. Order

    2. The order lines

    3. The articles

    4. The delivered quantity of goods

XML example file

See Examples files Appendix A for a sample file illustrating Use Case 1.

3.4.2. Use case 2 – Despatch Advice for transport of goods (not bulk goods) where the Supplier is responsible for transportation.

This is a use case based on the recommended requirements for a Despatch Advice regarding a delivery of goods to a delivery location.

Use Case number 2

Use Case Name

Despatch Advice for transport of goods (not bulk goods) where the Supplier is responsible for transportation.

Use Case Description

Describes a complete process whereby a Despatch party generates a Despatch Advice based on information about what is about to be shipped, or being in transit, the customer’s delivery location. It always contains Items and Quantities but can also include a list of Transport Handling Units and a full description of how the goods is packed. It also can contain information about Environmental data (EPD) and Dangerous Goods. In this use-case the Consignee is an external warehouse.

The Despatch Advice enables the goods provider to give full information about the goods that is being shipped to the receiver. This enables the Receiver to plan for the arrival and to reconcile the shipment with the order and manage any difference.

Parties involved

Buyer (In UBL: BuyerCustomerParty)

Seller (In UBL: SellerSupplierParty)

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

Consignee party (In UBL: DeliveryCustomerParty) (Different legal entity than the Buyer, an external warehouse for temporary storage).

Carrier party (In UBL: CarrierParty)

Originating party (In UBL: OriginatorCustomerParty) (In case the Consignee party is a Consignment warehouse, this party is the final receiver of the shipped goods.)

Pre conditions

Despatch Advice is sent when goods is about to be shipped. Supplier is responsible for transportation.

Post conditions

Despatch advice is received by the receiver of the goods.

Assumptions

  1. The Seller has received one order from the Buyer with one (1) article to be delivered to the Customer at the Consigne address on a specific date.

  2. The Seller has accepted the order without changes.

  3. The Despatch party delivers the complete order as accepted

The flow

  1. The Despatch party picks and packs the ordered quantity of the item.

  2. The Seller aranges for transportation of shipment.

  3. The Despatch party, together with the Carrier party delivers the shipment.

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

  5. The Consignee party receives the Despatch advice message.

  6. The Consignee party uses the content in the Despatch advice message for receiving the goods.

Result

  1. The Despatch advice message helped the Consignee party to confirm delivery.

    1. At the right time

    2. At the right location

    3. At the correct transportation price

  2. The Despatch advice message helped the Consignee party in the process of confirming delvery to identify the

    1. Order

    2. The order lines

    3. The articles

    4. The delivered quantity of goods

XML example file

See Examples files Appendix A for a sample file illustrating Use Case 2.

3.4.3. Use case 3 – Despatch Advice for services provided at one location without vehicle

This is a use case based on the recommended requirements for a Despatch Advice regarding a delivery of services on one single location.

Use Case number 3

Use Case Name

Despatch Advice for services provided at one location without vehicle

Use Case Description

Describes a complete process whereby a Despatch party generates a Despatch Advice based on information about the service provided at one location when a vehicle is not required, e.g. build scaffolding or build fences.

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

Parties involved

Buyer (In UBL: BuyerCustomerParty)

Seller (In UBL: SellerSupplierParty)

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

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

Pre conditions

Services are delivered for a period of time before Despatch Advice is sent.

Post conditions

Despatch advice is received by the receiver of the services.

Assumptions

  1. The Seller has received one order from the Buyer with one (1) article to be provided at a specified location, e.g building a fence around a property.

  2. The Seller has accepted the order without changes.

  3. The Despatch party delivers the complete order as accepted

The flow

  1. The Seller arange delivery of agreed services.

  2. The Despatch party deliver agreed services.

  3. The Despatch party sends Despatch advice message to the Consignee when ready with the order.

  4. The Consignee party receives the Despatch advice message

  5. The Consignee party uses the content in the Despatch advice message for validating against the order.

Result

  1. The Despatch advice message helped the Consignee party to check delivery against the order.

    1. At the right time

    2. At the right location

    3. At the correct price

  2. The Despatch advice message helped the Consignee party in the process of confirming delvery to identify the

    1. Order

    2. The order lines

    3. The articles

    4. The delivered quantity of services

XML example file

See Examples files Appendix A for a sample file illustrating Use Case 3.

3.4.4. Use case 4 – Services provided at one location using a vehicle.

This is a use case based on the recommended requirements for a Despatch Advice regarding a delivery of services at one single location.

Use Case number 4

Use Case Name

Services provided at one location using a vehicle.

Use Case Description

Describes a complete process whereby a Despatch party generates a Despatch Advice based on information about the service provided on one single location, e.g. tasks executed by an excavator or a wheel loader.

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

Parties involved

Buyer (In UBL: BuyerCustomerParty)

Seller (In UBL: SellerSupplierParty)

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

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

Pre conditions

Services are delivered before Despatch Advice is sent.

Post conditions

Despatch advice is received by the receiver of the services.

Assumptions

  1. The Seller has received one order from the Buyer with one (1) service-article to be provided on one location, e.g executing tasks with an excavator.

  2. The Seller has accepted the order without changes.

  3. The Despatch party delivers the complete order as accepted

The flow

  1. The Seller arranges delivery of agreed services.

  2. The Despatch party delivers agreed services.

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

  4. The Consignee party receives the Despatch advice message

  5. The Consignee party uses the content in the Despatch advice message to verify the delivery of the service.

Result

  1. The Despatch advice message helped the Consignee party to verify delivery.

    1. At the right time

    2. At the right location

    3. At the correct price

  2. The Despatch advice message helped the Consignee party in the process of verifying the delvery to identify the

    1. Order

    2. The order lines

    3. The articles

    4. The delivered quantity of services and the price.

XML example file

See Examples files Appendix A for a sample file illustrating Use Case 4.

3.4.5. Use case 5 – Despatch Advice for services between two locations, including a vehicle.

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

Use Case number 5

Use Case Name

Despatch Advice for services between two locations, including a vehicle.

Use Case Description

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

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

Parties involved

Buyer (In UBL: BuyerCustomerParty)

Seller (In UBL: SellerSupplierParty)

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

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

Locations involved

Ship-from (In UBL: DespatchAddress) (Defines the starting point of the service.)

Ship-to (In UBL: DeliveryLocation) (Defines the destination of the service.)

Pre conditions

Services are delivered before Despatch Advice is sent.

Post conditions

Despatch advice is received by the receiver of the services.

Assumptions

  1. The Seller has received one order from the Buyer with one (1) article to be provided between two locations, e.g transport of goods between locations A and B.

  2. The Seller has accepted the order without changes.

  3. The Despatch party delivers the complete order as accepted

The flow

  1. The Seller arange delivery of agreed services.

  2. The Despatch party deliver agreed services.

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

  4. The Consignee party receives the Despatch advice message

  5. The Consignee party uses the content in the Despatch advice message to verify the delivery.

Result

  1. The Despatch advice message helped the Consignee party to verify the delivery.

    1. At the right time

    2. At the right location

    3. At the correct price

  2. The Despatch advice message helped the Consignee party in the process of verifying the delvery of the service to identify the

    1. Order

    2. The order lines

    3. The articles

    4. The delivered quantity of services

XML example file

See Examples files Appendix A for a sample filegoodsItem illustrating Use Case 5.

3.4.6. Use case 6 – Despatch Advice for bulk goods

This is a use case based on the recommended requirements for a Despatch Advice regarding a delivery of bulk goods not including the transport.

Use Case number 6

Use Case Name

Despatch Advice for bulk goods

Use Case Description

Describes a complete process whereby a Despatch party generates a Despatch Advice based on information about delivered bulk material not including the transport.

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

Parties involved

Buyer (In UBL: BuyerCustomerParty)

Seller (In UBL: SellerSupplierParty)

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

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

Locations involved

Ship-from (In UBL: DespatchAddress) (Defines the place the bulk goods is coming from.)

Pre conditions

Bulk goods is delivered after Despatch Advice is sent.

Post conditions

Despatch advice is received by the receiver of the bulk goods.

Assumptions

  1. The Seller has received one order from the Buyer with one (1) article (bulk goods) to be picked up.

  2. The Seller has accepted the order without changes.

  3. The Despatch party delivers the complete order as accepted

The flow

  1. The Seller arrange delivery of agreed bulk goods.

  2. The Despatch party deliver agreed bulk goods when customer or customer’s representative arrives.

  3. The bulk goods is weighed and a Weight statement is created.

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

  5. The Consignee party receives the Despatch advice message

  6. The Consignee party uses the content in the Despatch advice message to verify the delivery.

Result

  1. The Despatch advice message helped the Consignee party to verify the delivery.

    1. At the right time

    2. At the right location

    3. At the correct price

  2. The Despatch advice message helped the Consignee party in the process of verifying the delvery to identify the

    1. Order

    2. The order lines

    3. The articles

    4. The delivered quantity of services

XML example file

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

3.4.7. Use case 7 – Despatch Advice for bulk goods including the transport

This is a use case based on the recommended requirements for a Despatch Advice regarding a delivery of bulk goods and including the transport.

Use Case number 7

Use Case Name

Despatch Advice for bulk goods with transport

Use Case Description

Describes a complete process whereby a Despatch party generates a Despatch Advice based on information about delivered bulk material and the transport.

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

Parties involved

Buyer (In UBL: BuyerCustomerParty)

Seller (In UBL: SellerSupplierParty)

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

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

Locations involved

Ship-from (In UBL: DespatchAddress) (Defines the place the bulk goods is coming from.)

Pre conditions

Bulk goods is delivered before or after Despatch Advice is sent. Both cases are possible.

Post conditions

Despatch advice is received by the receiver of the bulk goods.

Assumptions

  1. The Seller has received one order from the Buyer with one (1) article (bulk goods) to be picked up.

  2. The Seller has accepted the order without changes.

  3. The Despatch party delivers the complete order as accepted

The flow

  1. The Seller arrange delivery of agreed bulk goods.

  2. The Despatch party deliver agreed bulk goods when customer or customer’s representative arrives.

  3. The bulk goods is weighed and a Weight statement is created.

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

  5. The Consignee party receives the Despatch advice message

  6. The Consignee party uses the content in the Despatch advice message to verify the delivery.

Result

  1. The Despatch advice message helped the Consignee party to verify the delivery.

    1. At the right time

    2. At the right location

    3. At the correct price

  2. The Despatch advice message helped the Consignee party in the process of verifying the delvery to identify the

    1. Order

    2. The order lines

    3. The articles

    4. The delivered quantity of services

XML example file

See Examples files Appendix A for a sample file illustrating Use Case 7.

3.4.8. Use case 8 – Despatch Advice for waste treatment service, no transport.

This use case covers waste treatment services or similar services where the buyer brings the material to the supplier and leaves it there.

Use Case number 8

Use Case Name

Despatch Advice for waste treatment service, no transport

Use Case Description

The Despatch Advice enables the service provider (seller) to give detailed information about the service provided and the location where the material has been treated. In some cases the service provider can report the location where the material has been collected. Which enables a Buyer to reconcile, or confirm, the services provided against the order.

Parties involved

Buyer (In UBL: BuyerCustomerParty)

Seller (In UBL: SellerSupplierParty)

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

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

Pre conditions

Material is delivered to the seller and the services are delivered before Despatch Advice is sent.

Post conditions

Despatch advice is received by the receiver of the services.

Assumptions

  1. The Seller has received one order from the Buyer with one (1) line for the serices to be provided.

  2. The Seller has accepted the order without changes.

  3. The Despatch party delivers the services specified in the order.

The flow

  1. The Buyer arrange delivery of material to the seller either by the sellers transport service or other carrier services.

  2. The Despatch party deliver agreed services.

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

  4. The Consignee party receives the Despatch advice message

  5. The Consignee party uses the content in the Despatch advice message for confirmation of delivery.

Result

  1. The Despatch advice message helped the Consignee party to confirm delivery.

    1. At the right time

    2. At the right location (Delivery Location)

    3. Optionally, the location of the origin of the waste (Despatch Address) Note that the addresses are following the material flow, so the despatch address is the address where the material started it’s journey, even if this address belongs to the buyer.

  2. The Despatch advice message helped the Consignee party in the process of confirming delvery to identify the

    1. Order

    2. The order lines

    3. The articles

    4. The delivered quantity of services

XML example file

See Examples files Appendix A for a sample file illustrating Use Case 8.

3.4.9. Use case 9 – Despatch Advice for waste treatment service, including the transport.

This use case covers waste treatment services or similar services where the supplier picks the material up and takes it to the recycling station.

Use Case number 9

Use Case Name

Despatch Advice for waste treatment service, including the transport

Use Case Description

The Despatch Advice enables the service provider (seller) to give detailed information about the service provided and the location where the material has been treated. In some cases the service provider can report the location where the material has been collected. Which enables a Buyer to reconcile, or confirm, the services provided against the order.

Parties involved

Buyer (In UBL: BuyerCustomerParty)

Seller (In UBL: SellerSupplierParty)

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

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

Pre conditions

Material is delivered to the seller and the services are delivered before Despatch Advice is sent.

Post conditions

Despatch advice is received by the receiver of the services.

Assumptions

  1. The Seller has received one order from the Buyer with one (1) line for the serices to be provided.

  2. The Seller has accepted the order without changes.

  3. The Despatch party delivers the services specified in the order.

The flow

  1. The Buyer arrange delivery of material to the seller either by the sellers transport service or other carrier services.

  2. The Despatch party deliver agreed services.

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

  4. The Consignee party receives the Despatch advice message

  5. The Consignee party uses the content in the Despatch advice message for confirmation of delivery.

Result

  1. The Despatch advice message helped the Consignee party to confirm delivery.

    1. At the right time

    2. At the right location (Delivery Location)

    3. Optionally, the location of the origin of the waste (Despatch Address) Note that the addresses are following the material flow, so the despatch address is the address where the material started it’s journey, even if this address belongs to the buyer.

  2. The Despatch advice message helped the Consignee party in the process of confirming delvery to identify the

    1. Order

    2. The order lines

    3. The articles

    4. The delivered quantity of services

XML example file

See Examples files Appendix A for a sample file illustrating Use Case 9.

3.4.10. Use case 10 – Despatch Advice for transport of bulk goods (service only)

The use case covers transport of bulk goods and other types of transports that needs a weight statement and are not packaged. e.g. gravel, oil, milk, soil and waste. Note that the use case only covers the transprotation service, if the despach advice also covers material, additional information needs to be added from the relevant use cases.

Use Case number 10

Use Case Name

Despatch Advice for transport of bulk goods (service only)

Use Case Description

Describes a complete process whereby a Despatch party (the service provider) generates a Despatch Advice based on information about the service provided of bulk goods transport between two locations.

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

Parties involved

Buyer (In UBL: BuyerCustomerParty)

Seller (In UBL: SellerSupplierParty)

Pre conditions

Services are delivered before Despatch Advice is sent.

Post conditions

Despatch advice is received by the receiver of the services.

Assumptions

  1. The Seller has received one order from the Buyer with one (1) line describing the service to be provided between two locations, e.g transport of goods between locations A and B.

  2. The Seller (transporter) has accepted the order without changes.

  3. The Despatch party delivers the complete order as accepted

The flow

  1. The Seller arange delivery of agreed services.

  2. The Seller party deliver agreed services.

  3. The Seller party sends Despatch advice message to the Buyer

  4. The Buyer party receives the Despatch advice message

  5. The Buyer party uses the content in the Despatch advice message for confirmation of delivery.

Result

  1. The Despatch advice message helped the Buyer party to confirm the serivce delivered.

    1. At the right time

    2. At the right location ..(At the correct price)

  2. The Despatch advice message helped the Buyer party in the process of confirming delvery to identify the

    1. Order

    2. The order lines

    3. The articles

    4. The delivered quantity of services

XML example file

See Examples files Appendix A for a sample file illustrating Use Case 10.

3.4.11. Use case 11 – Despatch Advice for transport of non-bulk goods (service only)

The use case covers transport of non-bulk goods and other types of transports that does not need a weight statement. e.g. pallets, bundles, containers, vehicles etc. Note that the use case only covers the transprotation service, if the despach advice also covers material, additional information needs to be added from the relevant use cases.

Use Case number 11

Use Case Name

Despatch Advice for transport of non-bulk goods (service only)

Use Case Description

Describes a complete process whereby a Despatch party (the service provider) generates a Despatch Advice based on information about the service provided of non-bulk goods transport between two locations.

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

Parties involved

Buyer (In UBL: BuyerCustomerParty)

Seller (In UBL: SellerSupplierParty)

Pre conditions

Services are delivered before Despatch Advice is sent.

Post conditions

Despatch advice is received by the receiver of the services.

Assumptions

  1. The Seller has received one order from the Buyer with one (1) line describing the service to be provided between two locations, e.g transport of goods between locations A and B.

  2. The Seller (transporter) has accepted the order without changes.

  3. The Despatch party delivers the complete order as accepted

The flow

  1. The Seller arange delivery of agreed services.

  2. The Seller party deliver agreed services.

  3. The Seller party sends Despatch advice message to the Buyer

  4. The Buyer party receives the Despatch advice message

  5. The Buyer party uses the content in the Despatch advice message for confirmation of delivery.

Result

  1. The Despatch advice message helped the Buyer party to confirm the serivce delivered.

    1. At the right time

    2. At the right location ..(At the correct price)

  2. The Despatch advice message helped the Buyer party in the process of confirming delvery to identify the

    1. Order

    2. The order lines

    3. The articles

    4. The delivered quantity of services

XML example file

See Examples files Appendix A for a sample file illustrating Use Case 11.

3.4.12. Use case 12 – Despatch Advice for transport of goods where SerialIDs must be reported for each package.

This is a use case based on the recommended requirements for a Despatch Advice regarding a delivery of goods to a delivery location.

Use Case number 12

Use Case Name

Despatch Advice for transport of goods where SerialIDs must be reported for each package.

Use Case Description

Describes a complete process whereby a Despatch party generates a Despatch Advice based on information about what is about to be shipped, or being in transit, the customer’s delivery location. In this usecase it is important to know how the individual SerialIDs are packed - in which package a SerialId can be found.

The Despatch Advice enables the goods provider to give full information about the goods that is being shipped to the receiver. This enables the Receiver to plan for the arrival and to reconcile the shipment with the order and manage any difference.

Parties involved

Buyer (In UBL: BuyerCustomerParty)

Seller (In UBL: SellerSupplierParty)

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

Consignee party (In UBL: DeliveryCustomerParty) (Different legal entity than the Buyer, an external warehouse for temporary storage).

Carrier party (In UBL: CarrierParty)

Originating party (In UBL: OriginatorCustomerParty) (In case the Consignee party is a Consignment warehouse, this party is the final receiver of the shipped goods.)

Pre conditions

Despatch Advice is sent when goods is about to be shipped. Supplier is responsible for transportation.

Post conditions

Despatch advice is received by the receiver of the goods.

Assumptions

  1. The Seller has received one order from the Buyer with one (1) article to be delivered to the Customer at the Consigne address on a specific date.

  2. The Seller has accepted the order without changes.

  3. The Despatch party delivers the complete order as accepted

The flow

  1. The Despatch party picks and packs the ordered quantity of the item. In this process each SerialID is kept track of so that it is reported into which package it is packed in.

  2. The Seller aranges for transportation of shipment.

  3. The Despatch party, together with the Carrier party delivers the shipment.

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

  5. The Consignee party receives the Despatch advice message.

  6. The Consignee party uses the content in the Despatch advice message for receiving the goods.

Result

  1. The Despatch advice message helped the Consignee party to confirm delivery.

    1. At the right time

    2. At the right location

    3. At the correct transportation price

  2. The Despatch advice message helped the Consignee party in the process of confirming delvery to identify the

    1. Order

    2. The order lines

    3. The articles

    4. The delivered quantity of goods

    5. Where the SerialIDs are located

XML example file

See Examples files Appendix A for a sample file illustrating Use Case 12.

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

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

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

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

6.1. Document Status Code

6.1.1. Orginal

Document status code 9 indicates the original Despatch Advice and is used to notify the receiver that updates may follow. This code is used to indicate that the current Despatch Advice is the first and original version of the document, and that additional updates may be sent in the future if necessary. The use of status code 9 ensures that the receiver is aware of the original Despatch Advice and any subsequent updates. If the Despatch Advice is rejected by the network or the receiver, indicating that the receiver did not receive it, the next transmission of the Despatch Advice should still be considered as the first one, and the code 9 should still be used.

6.1.2. Replace

The document status code 5 indicates "replace" and is used to replace a previously sent Despatch Advice that was received by the receiver. It allows for multiple iterations of the Despatch Advice to be sent in case not all necessary information was available at the time of the first transmission. For example, the Consignee may require the Despatch Advice to document the delivery of goods or services, but all information may not be readily available. It is also in some situations possible to first send the Advanced Despatch Advice before shipping as an alert, and then again after shipping when all information is known. The replacements must include all information, not just the changes, and should include the Issue time so that the receiver can identify the most recent version. The updates should not be sent after a Receipt Advice (confirming that the goods and/or services has been received by the buyer) has been received by the supplier or when the goods or services have been invoiced. If, however, updates on parts that are not relevant for the invoicing need to be updated (like environmental information). the Despatch Advice can be sent after.

6.1.3. Cancellation

Document status code 1 indicates "ignore and delete" and is used to notify the receiver to disregard and remove the Despatch Advice from their system. This code is used when the Despatch Advice was sent in error and the intended recipient of the message was not intended to receive it. The use of status code 1 ensures that the receiver does not process or store any incorrect or unintended information.

6.1.4. Final transmission

Document status code 22 indicates "final" and is used to notify the receiver that no further updates to the Despatch Advice will be sent. This code indicates that the current Despatch Advice is the final version and that no additional changes or updates will be made. The use of status code 22 ensures that the receiver can process the Despatch Advice with confidence that it represents the final state of the document.

Example:
<cbc:IssueDate>2021-09-10</cbc:IssueDate>
<cbc:IssueTime>12:00:00+01:00</cbc:IssueTime>
<cbc:DocumentStatusCode>5</cbc:DocumentStatusCode>

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

6.2.1. Despatch party (DespatchSupplierParty)

The Despatch Party is the person or organization who provides (despatch) the goods or services. The role is carried out by the supplier or on behalf of the supplier. (Despatch Party is sometimes known as the Consignor). The Despatch Party is mandatory information in the Despatch Advice message. Defines the company that provides the goods or the service. It also defines the sender of the Despatch Advice. Should the ship-from address differ from DespatchSupplierParty, the real ship-from address must be sent in DespatchAddress.

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

6.2.2. Consignee (DeliveryCustomerParty)

The Consignee is the person or organization to which the products will be shipped and who is taking possession or is the receiver of the service delivered. The role is carried out by the customer or on behalf of the customer. The Consignee is mandatory information in the Despatch Advice message. It also is the receiver of the Despatch Advice. Should the ship-to address be different from the DeliveryCustomerParty, the real ship-to address must be sent in DeliveryLocation.

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

6.2.3. Buyer (BuyerCustomerParty)

The buyer is the legal person or organization who buys or purchases the goods or services.

The Buyer is optional information in the Despatch Advice message.

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

6.2.4. Seller (SellerSupplierParty)

The seller is the legal person or organization who sells goods or services to the customer. The Seller is optional information in the Despatch Advice message.

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

6.2.5. Originating party (OriginatorCustomerParty)

The party who will eventually receive and consume the goods and on whose behalf the buyer makes the purchase. The Originator Party is optional information in the Despatch Advice message. For 3PL shipments, this party defines the final receiver of the goods.

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

6.2.6. Carrier party (CarrierParty)

This is the party that executes the transport when the Despatch Advice shows a delivery of goods. In other cases this party may be omitted.

Example:
<cac:CarrierParty>
        <cac:PartyIdentification>
                <cbc:ID schemeID="0088">5790000435951</cbc:ID>
        </cac:PartyIdentification>
        <cac:PartyName>
                <cbc:Name>CarrierPart</cbc:Name>
        </cac:PartyName>
</cac:CarrierParty>

6.3. Locations

Sometimes the parties DespatchSupplierParty and DeliveryCustomerParty are not the same as the Ship-from and Ship-to locations. Then it is important to provide information about the real from- and to addresses. An example when this must be used is for transporting waste from the customer’s location to a recycling unit. The DeliveryCustomerParty then is the ship-from address and the DespatchSupplierParty can be the ship-to. To describe this situation we need to use DespatchAddress and DeliveryLocation.

6.3.1. Ship-from (DespatchAddress)

The Ship-from is the real address where the goods is picked up. Must be included when it is different from the DespatchSupplierParty. (If DespatchAddress is omitted the DespatchSupplierParty is assumed to be the real ship-from address.) The Ship-from includes the option to give gps coordinates. They may be added along with the address, but in case there is no address (like picking up waste from a construction of a new road) the gps coordinates can be used instead of the address.

Example:
<cac:DespatchAddress>
        <cbc:StreetName>Avon Way</cbc:StreetName>
        <cbc:AdditionalStreetName>way 2</cbc:AdditionalStreetName>
        <cbc:CityName>Bridgtow</cbc:CityName>
        <cbc:PostalZone>ZZ99 1ZZ</cbc:PostalZone>
        <cbc:CountrySubentity>Avon</cbc:CountrySubentity>
        <cac:AddressLine>
                <cbc:Line>3rd Floor, Room 5</cbc:Line>
        </cac:AddressLine>
        <cac:Country>
                <cbc:IdentificationCode>GB</cbc:IdentificationCode>
        </cac:Country>
        <cac:LocationCoordinate>
                <cbc:CoordinateSystemCode>EPSG:3857</cbc:CoordinateSystemCode>
                <cbc:LatitudeDegreesMeasure unitCode="DD">59.33169866504851</cbc:LatitudeDegreesMeasure>
                <cbc:LongitudeDegreesMeasure unitCode="DD">18.063330898492403</cbc:LongitudeDegreesMeasure>
                <cbc:AltitudeMeasure unitCode="MTR">12.5</cbc:AltitudeMeasure>
        </cac:LocationCoordinate>
</cac:DespatchAddress>

6.3.2. Ship-to (DeliveryLocation)

The Ship-to is the real address to which the goods is delivered. Must be included when it is different from the DeliveryCustomerParty. (If DeliveryLocation is omitted the DeliveryCustomerParty is assumed to be the real ship-to address.) The Ship-to includes the option to give gps coordinates. They may be added along with the address, but in case there is no address (like delivering goods to a construction of a new road) the gps coordinates can be used instead of the address.

Example:
<cac:DeliveryLocation>
        <cbc:ID schemeID="0088">5790000435951</cbc:ID>
        <cbc:Name>Name</cbc:Name>
        <cac:Address>
                <cbc:StreetName>Avon Way</cbc:StreetName>
                <cbc:AdditionalStreetName>Purchasing</cbc:AdditionalStreetName>
                <cbc:CityName>Bridgtow</cbc:CityName>
                <cbc:PostalZone>ZZ99 1ZZ</cbc:PostalZone>
                <cbc:CountrySubentity>Avon</cbc:CountrySubentity>
                <cac:AddressLine>
                        <cbc:Line>3rd Floor, Room 5</cbc:Line>
                </cac:AddressLine>
                <cac:Country>
                        <cbc:IdentificationCode>GB</cbc:IdentificationCode>
                </cac:Country>
                <cac:LocationCoordinate>
                        <cbc:CoordinateSystemCode>EPSG:3857</cbc:CoordinateSystemCode>
                        <cbc:LatitudeDegreesMeasure unitCode="DD">59.331660358041425</cbc:LatitudeDegreesMeasure>
                        <cbc:LongitudeDegreesMeasure unitCode="DD">18.063363084988005</cbc:LongitudeDegreesMeasure>
                        <cbc:AltitudeMeasure unitCode="MTR">12.5</cbc:AltitudeMeasure>
                </cac:LocationCoordinate>
        </cac:Address>
</cac:DeliveryLocation>

6.4. Order reference

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

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

6.5. Shipment

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

6.5.1. Shipment ID

Normally the Freight Forwarder’s identity of the shipment should be used.

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

Example:

<cac:Shipment>
        <cbc:ID>NA</cbc:ID>
        <cbc:Information>Free text information relating to the Shipment</cbc:Information>
        <cbc:GrossWeightMeasure unitCode="KGM">492</cbc:GrossWeightMeasure>
        <cbc:GrossVolumeMeasure unitCode="MTQ">14.2</cbc:GrossVolumeMeasure>

6.5.2. Vehicle ID

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

If you need to specify more than one license plate, use a semi-colon (;) between the license plate id:s. For foreign license plates, set the countrycode in front of the license plate id, with a dash between. See example. If no countrycode is provided, a domestic license plate is assumed. If a license plate is unknow, use "UNKNOWN" as the license plate id. If a license plate is not relevant, use "NA" as the license plate id.

Example:
<cac:ShipmentStage>
        <cbc:TransportModeCode>3</cbc:TransportModeCode>
        <cac:TransportMeans>
                <cac:RoadTransport>
                        <cbc:LicensePlateID>SE-ABC123;SE-DEF456</cbc:LicensePlateID>
                </cac:RoadTransport>
        </cac:TransportMeans>
</cac:ShipmentStage>

6.6. Delivery Date

There are in the structure four date/times that can be used to define the delivery time or -period. They are:

  • EstimatedDeliveryPeriod/StartDate and StartTime.

  • EstimatedDeliveryPeriod/EndDate and EndTime.

  • ActualDespatchDate and ActualDespatchTime.

  • ActualDeliveryDate and ActualDeliveryTime.

They should be used as follows in the different situations:

  • When sending the DespatchAdvice before delivery, the EstimatedDeliveryPeriod is used for the calculated arrival date/time. At least the StartDate must be given, but a full period with both Start and End date and time is possible. The ActualDespatchDate and Time is used to inform about when the truck departs.

  • When sending the DespatchAdvice after delivery, the ActualDeliveryDate and Time is used for the real arrival date/time. The EstimatedDeliveryPeriod may be used to inform about what was expected, so that it is possible to measure the difference. The ActualDespatchDate and Time is also here the real the time the truck departs.

  • When the DespatchAdvice is for a service and therefore sent after delivery, the delivery period should be sent so that the service start is sent in ActualDespatchDate and the service end in ActualDeliveryDate. The EstimatedDeliveryPeriod is not used in this case.

Note that the delivery dates are dependent on the delivery term. E.g, if the delivery term is Incoterms Ex Works it means that the goods is ready for pickup at the supplier the given delivery date.

6.7. Transport handling unit

In the Advanced Despatch Advice you can provide a full description of how the packing structure is in up to four levels. The top level is the TransportHandlingUnit (THU). A THU can be of different types - containers, pallets, boxes etc. The receiver will receive a THU as it is packed by the sender. The carrier will move it unchanged. On a THU it is possible to pack items and/or packages. These packages can contain items and/or smaller packages, and these smaller packages items and/or even smaller packages. These can only contain items. So it is possible to describe a structure where a package can be inside a bigger package that can be in a bigger package that is in a THU. See image below. Additionally to this it is also possible to pack the THUs in a container.

image

6.7.1. Transport Handling Unit ID

Serial shipping container code (SSCC) issued by GS1 should be used to identify the transport handling unit. Note that the same physical handling unit may contain items from different despatch lines. Besides the ID you also need to provide a Type-code of the THU from the code-list.

Example:
<cac:TransportHandlingUnit>
        <cbc:ID>11111222222222</cbc:ID>
        <cbc:TransportHandlingUnitTypeCode>AG</cbc:TransportHandlingUnitTypeCode>
        <cbc:HandlingCode listID="TRED4079">1</cbc:HandlingCode>
        <cbc:HandlingInstructions>To be set vertical</cbc:HandlingInstructions>
        <cbc:HazardousRiskIndicator>false</cbc:HazardousRiskIndicator>
        <cbc:ShippingMarks>Text</cbc:ShippingMarks>
        <cac:MeasurementDimension>
                <cbc:AttributeID>AAB</cbc:AttributeID>
                <cbc:Measure unitCode="KGM">123</cbc:Measure>
        </cac:MeasurementDimension>
        <cac:MeasurementDimension>
                <cbc:AttributeID>AAW</cbc:AttributeID>
                <cbc:Measure unitCode="MTQ">3.55</cbc:Measure>
        </cac:MeasurementDimension>
        <cac:MinimumTemperature>
                <cbc:AttributeID>TC</cbc:AttributeID>
                <cbc:Measure unitCode="CEL">-40</cbc:Measure>
        </cac:MinimumTemperature>
        <cac:MaximumTemperature>
                <cbc:AttributeID>TC</cbc:AttributeID>
                <cbc:Measure unitCode="CEL">-10</cbc:Measure>
        </cac:MaximumTemperature>
</cac:TransportHandlingUnit>

6.7.2. Transport Equipment

In case the THU is a container, the container-specific data is defined here.

Example:
<cac:TransportEquipment>
        <cbc:ID>7677766555</cbc:ID>
        <cbc:TransportEquipmentTypeCode>AM</cbc:TransportEquipmentTypeCode>
        <cbc:RefrigerationOnIndicator>true</cbc:RefrigerationOnIndicator>
        <cbc:Description>A 20 foot refrigerated container that is not actively controlling temperature of the product.</cbc:Description>
        <cbc:PowerIndicator>true</cbc:PowerIndicator>
</cac:TransportEquipment>

6.7.3. Goods Item

If any item is packed directly in/on the THU, you specify that here. The ID is the reference to the DespatchLine/ID. All information about the item itself will be found on the Despatch Line. Besides the ID you also need to provide information of the quantity packed in/on this THU. Here also is a TraceID that can be used for multiple purposes. With the attribute schemeID you can describe what type of trace you use.

Example:
<cac:GoodsItem>

        <!--Reference to the Despatch line number - DespatchLine/ID-->
        <cbc:ID>3</cbc:ID>
        <cbc:HazardousRiskIndicator>false</cbc:HazardousRiskIndicator>
        <cbc:DeclaredStatisticsValueAmount currencyID="USD">10</cbc:DeclaredStatisticsValueAmount>

        <!--Quantity of the item on the referred despatch line packed in this THU.-->
        <cbc:Quantity unitCode="EA">84</cbc:Quantity>
        <cbc:TraceID schemeID="SGTIN">345699634527</cbc:TraceID>
</cac:GoodsItem>

6.7.4. Package

If the THU contains any package, you specify that here. You may give an ID on this package too, but it is optional. The type-code, however, you need to give. Like for the THU you also can describe what is inside the package. There can be items and/or smaller packages.

Example:
<cac:Package>
        <cbc:ID>3453</cbc:ID>
        <cbc:ReturnableMaterialIndicator>true</cbc:ReturnableMaterialIndicator>
        <cbc:PackagingTypeCode>4H</cbc:PackagingTypeCode>
        <cbc:PackingMaterial>Carbon box</cbc:PackingMaterial>
        <cac:ContainedPackage>
                <!--Insert information about packages inside the package here.-->
                <cbc:PackagingTypeCode>4H</cbc:PackagingTypeCode>
        </cac:ContainedPackage>
        <cac:GoodsItem>
                <!--Insert information about items packed in this package here.-->
                <cbc:ID>3</cbc:ID>
                <cbc:Quantity unitCode="EA">84</cbc:Quantity>
        </cac:GoodsItem>
        <cac:MeasurementDimension>
                <cbc:AttributeID>LN</cbc:AttributeID>
                <cbc:Measure unitCode="MMT">400</cbc:Measure>
        </cac:MeasurementDimension>
</cac:Package>

6.7.5. Contained Package

In the two last levels of the packing structure the ContainedPackage is used. They should be used the same way as described above for Package.

Example:
<cac:ContainedPackage>
        <cbc:ID>3454</cbc:ID>
        <cbc:ReturnableMaterialIndicator>true</cbc:ReturnableMaterialIndicator>
        <cbc:PackagingTypeCode>4H</cbc:PackagingTypeCode>
        <cbc:PackingMaterial>Carbon box</cbc:PackingMaterial>
        <cac:ContainedPackage>
                <!--Insert information about packages inside the package here.-->
                <cbc:PackagingTypeCode>4H</cbc:PackagingTypeCode>
        </cac:ContainedPackage>
        <cac:GoodsItem>
                <!--Insert information about items packed in this package here.-->
                <cbc:ID>3</cbc:ID>
                <cbc:Quantity unitCode="EA">84</cbc:Quantity>
        </cac:GoodsItem>
        <cac:MeasurementDimension>
                <cbc:AttributeID>LN</cbc:AttributeID>
                <cbc:Measure unitCode="MMT">400</cbc:Measure>
        </cac:MeasurementDimension>
</cac:ContainedPackage>

Finally an example of a full packing structure where the THU contains one goods item and one package, the package contains one goods item and one package, this package contains again one goods item and one smaller package. Finally this package contains two goods items.

Example:
<!-- Start of Transport Handling Unit. -->
<cac:TransportHandlingUnit>
        <cbc:ID>11111222222222</cbc:ID>
        <cbc:TransportHandlingUnitTypeCode>AG</cbc:TransportHandlingUnitTypeCode>
        <cbc:HandlingCode listID="TRED4079">1</cbc:HandlingCode>
        <cbc:HandlingInstructions>To be set vertical</cbc:HandlingInstructions>
        <cbc:HazardousRiskIndicator>false</cbc:HazardousRiskIndicator>
        <cbc:ShippingMarks>Text</cbc:ShippingMarks>
        <!-- Here we can have a reference to a container (TransportEquipment). -->
        <cac:MeasurementDimension>
                <cbc:AttributeID>AAB</cbc:AttributeID>
                <cbc:Measure unitCode="KGM">123</cbc:Measure>
        </cac:MeasurementDimension>
        <cac:MeasurementDimension>
                <cbc:AttributeID>AAW</cbc:AttributeID>
                <cbc:Measure unitCode="MTQ">3.55</cbc:Measure>
        </cac:MeasurementDimension>
        <cac:MinimumTemperature>
                <cbc:AttributeID>TC</cbc:AttributeID>
                <cbc:Measure unitCode="CEL">-40</cbc:Measure>
        </cac:MinimumTemperature>
        <cac:MaximumTemperature>
                <cbc:AttributeID>TC</cbc:AttributeID>
                <cbc:Measure unitCode="CEL">-10</cbc:Measure>
        </cac:MaximumTemperature>
        <cac:GoodsItem>
                <!--Reference to the Despatch line number - DespatchLine/ID-->
                <cbc:ID>3</cbc:ID>
                <cbc:HazardousRiskIndicator>false</cbc:HazardousRiskIndicator>
                <cbc:DeclaredStatisticsValueAmount currencyID="USD">10</cbc:DeclaredStatisticsValueAmount>
                <!--Quantity of the item on the referred despatch line packed in this THU.-->
                <cbc:Quantity unitCode="EA">84</cbc:Quantity>
                <cbc:TraceID schemeID="SGTIN">345699634527</cbc:TraceID>
        </cac:GoodsItem>
        <!-- Start of second level - package on THU. -->
        <cac:Package>
                <cbc:ID>3453</cbc:ID>
                <cbc:ReturnableMaterialIndicator>true</cbc:ReturnableMaterialIndicator>
                <cbc:PackagingTypeCode>4H</cbc:PackagingTypeCode>
                <cbc:PackingMaterial>Carbon box</cbc:PackingMaterial>
                <!-- Start of third level - package in package on THU. -->
                <cac:ContainedPackage>
                        <cbc:ID>3454</cbc:ID>
                        <cbc:PackagingTypeCode>4H</cbc:PackagingTypeCode>
                        <!-- Start of fourth level - package in package in package on THU. -->
                        <cac:ContainedPackage>
                                <cbc:ID>3455</cbc:ID>
                                <cbc:PackagingTypeCode>4H</cbc:PackagingTypeCode>
                                <cac:GoodsItem>
                                        <cbc:ID>1</cbc:ID>
                                        <cbc:Quantity unitCode="EA">12</cbc:Quantity>
                                </cac:GoodsItem>
                                <cac:GoodsItem>
                                        <cbc:ID>2</cbc:ID>
                                        <cbc:Quantity unitCode="EA">80</cbc:Quantity>
                                </cac:GoodsItem>
                                <cac:MeasurementDimension>
                                        <cbc:AttributeID>LN</cbc:AttributeID>
                                        <cbc:Measure unitCode="MMT">400</cbc:Measure>
                                </cac:MeasurementDimension>
                        </cac:ContainedPackage>
                        <!-- End of fourth level - package in package in package on THU. -->
                        <cac:GoodsItem>
                                <cbc:ID>3</cbc:ID>
                                <cbc:Quantity unitCode="EA">40</cbc:Quantity>
                        </cac:GoodsItem>
                </cac:ContainedPackage>
                <!-- End of third level - package in package on THU. -->
                <cac:GoodsItem>
                        <cbc:ID>2</cbc:ID>
                        <cbc:Quantity unitCode="EA">72</cbc:Quantity>
                </cac:GoodsItem>
        </cac:Package>
        <!-- End of second level - package on THU. -->
</cac:TransportHandlingUnit>
<!-- End of Transport Handling Unit. -->

6.8. Environmental Data

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

6.8.1. Fuel

The fuel consumption and related information regarding the fuel type, that is used to calculate emissions for the transport or other service that consumes fuel. The table below shows which information that can be sent, and by repeating the group MeasurementDimension you can send several. The value in the table is sent in element AttributeID and the value of it in Measure or Description. See example below.

Table 4. Definitions of the AttributeID:s.
AttributeID Definition

ConversionFactor

Conversion and emission factor CO2 equivalent for calculating CO2 according to the fuel specified in the group.

DrivingDistance

Driving distance in kilometers that has been used for the assignment.

DrivingTime

Driving time in hours that has been used for the assignment.

EnergyContent

Amount of energy content (KWh) in the fuel specified in the group.

EngineType

Environment class for the type of engine that has been used for the assignment.

FuelConsumption

The consumed amount of fuel in the assignment.

FuelMeasurementMethod

The method that the fuel consumption has been measured.

RenewableFuel

Share of renewable fuel in percent.

Contains the possible values for the Description element when the AttributeID is FuelMeasurementMethod.

Table 5. Definitions of the FuelMeasurementMethod values.
FuelMeasurementMethod Definition

AutomaticMeasurement

Automatic measurement via CAN bus, OBD2 or similar

StandardEstimate

The values have been calculated by using standard consumption for a machine or vehicle.

ManualMeasurement

The values have been calculated by manually measure, e.g. fuel consumption for a machine between two refueling occasions.
Table 6. Definitions of the EngineType values. Contains the possible values for the Description element when the AttributeID is EngineType.
EngineType Definition

Euro2

Euro 2

Euro3

Euro 3

Euro4

Euro 4

Euro5

Euro 5

Euro6

Euro 6

EuroStep2

Euro Step 2

EuroStep3A

Euro Step 3A

EuroStep3B

Euro Step 3B

EuroStep4

Euro Step 4

EV

EV

FuelCell

Fuel Cell

Hybrid

Hybrid
Example:
<cac:OriginalDespatchTransportationService>
        <cbc:TransportServiceCode>FuelReport</cbc:TransportServiceCode>
        <cac:TransportEquipment>
                <cbc:TransportEquipmentTypeCode listID="FuelGroup" listAgencyID="Trafikverket" listVersionID="2023:1">HVO</cbc:TransportEquipmentTypeCode>
                <cbc:Description>HVO Diesel</cbc:Description>
                <cac:MeasurementDimension>
                        <cbc:AttributeID>FuelConsumption</cbc:AttributeID>
                        <cbc:Measure unitCode="LTR">115.6</cbc:Measure>
                </cac:MeasurementDimension>
                <cac:MeasurementDimension>
                        <cbc:AttributeID>EnergyContent</cbc:AttributeID>
                        <cbc:Measure unitCode="3B">3927</cbc:Measure>
                </cac:MeasurementDimension>
                <cac:MeasurementDimension>
                        <cbc:AttributeID>ConversionFactor</cbc:AttributeID>
                        <cbc:Measure unitCode="EA">0.52</cbc:Measure>
                </cac:MeasurementDimension>
                <cac:MeasurementDimension>
                        <cbc:AttributeID>DrivingDistance</cbc:AttributeID>
                        <cbc:Measure unitCode="KMT">86</cbc:Measure>
                </cac:MeasurementDimension>
                <cac:MeasurementDimension>
                        <cbc:AttributeID>DrivingTime</cbc:AttributeID>
                        <cbc:Measure unitCode="HUR">7.3</cbc:Measure>
                </cac:MeasurementDimension>
                <cac:MeasurementDimension>
                        <cbc:AttributeID>RenewableFuel</cbc:AttributeID>
                        <cbc:Measure unitCode="P1">100.00</cbc:Measure>
                </cac:MeasurementDimension>
                <cac:MeasurementDimension>
                        <cbc:AttributeID>FuelMeasurementMethod</cbc:AttributeID>
                        <cbc:Description>AutomaticMeasurement</cbc:Description>
                </cac:MeasurementDimension>
                <cac:MeasurementDimension>
                        <cbc:AttributeID>EngineType</cbc:AttributeID>
                        <cbc:Description>EURO4</cbc:Description>
                </cac:MeasurementDimension>
                <cac:ProviderParty>
                        <cac:PartyIdentification>
                                <cbc:ID schemeID="0007">5560726977</cbc:ID>
                        </cac:PartyIdentification>
                        <cac:PartyName>
                                <cbc:Name>Preem AB</cbc:Name>
                        </cac:PartyName>
                </cac:ProviderParty>
                <cac:GoodsItem>
                        <cac:Item>
                                <cac:SellersItemIdentification>
                                        <cbc:ID>123</cbc:ID>
                                </cac:SellersItemIdentification>
                                <cac:StandardItemIdentification>
                                        <cbc:ID schemeID="0160">1234567891234</cbc:ID>
                                </cac:StandardItemIdentification>
                        </cac:Item>
                </cac:GoodsItem>
        </cac:TransportEquipment>

6.8.2. Environmental Emission

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

For all other AttributeIDs, the element Measure is used instead of Description.

Table 7. Definitions of the EnvironmentalEmissionTypeCode:s.
AttributeID Definition

CO2

Amount of fossil CO2-eq based on a life cycle perspective, well to wheel, according to EN15804 amendment version A1

CO2_WtW_vA2

Amount of fossil CO2-eq based on a life cycle perspective, well to wheel, according to EN15804 amendment version A2

CO2_WtW_vA3

Amount of fossil CO2-eq based on a life cycle perspective, well to wheel, according to EN15804 amendment version A3

HC

Amount of emission of hydro carbon for the assignment.

NOX

Amount of emission of nitroge oxide for the assignment.

PM

Amount of emission of particulate matter.
Example:
<cac:EnvironmentalEmission>
        <cbc:EnvironmentalEmissionTypeCode listID="UN785" name="Carbon Dioxide">CO2</cbc:EnvironmentalEmissionTypeCode>
        <cbc:ValueMeasure unitCode="MGM">2.8</cbc:ValueMeasure>
</cac:EnvironmentalEmission>

<cac:EnvironmentalEmission>
        <cbc:EnvironmentalEmissionTypeCode listID="UN785" name="Hydrocarbon">HC</cbc:EnvironmentalEmissionTypeCode>
        <cbc:ValueMeasure unitCode="KGM">0.6</cbc:ValueMeasure>
</cac:EnvironmentalEmission>

<cac:EnvironmentalEmission>
        <cbc:EnvironmentalEmissionTypeCode listID="UN785" name="Nitric Oxide">NOX</cbc:EnvironmentalEmissionTypeCode>
        <cbc:ValueMeasure unitCode="KGM">6</cbc:ValueMeasure>
</cac:EnvironmentalEmission>

<cac:EnvironmentalEmission>
        <cbc:EnvironmentalEmissionTypeCode listID="UN785" name="Particular Matter">PM</cbc:EnvironmentalEmissionTypeCode>
        <cbc:ValueMeasure unitCode="GRM">0.07</cbc:ValueMeasure>
</cac:EnvironmentalEmission>

6.8.3. Product Climate Data

To determine the CO2 equivalent in kilograms for the despatch line, in total, the following calculation must be performed:

CO2eq despatch line = (Net net weight) x (GWP GHG value per kilogram) x Quantity

Where GWP GHG value per kilogram is one of the following

  • GWP GHG A1-3 vA1 EPD value

  • GWP GHG A1-3 vA2 EPD value

  • GWP GHG A1-3 vA3 EPD value

According to table 9 and 10 below.

The GWP GHG value per kilogram can be either a generic value from an authority or specific value from an Enviromental Product Declaration (EPD).

To be able to calculate product climate data the related CO2 value and the weight of products are needed. The net weight per item is the recommended way to provide the weight information to the customer. See related information here: cac-Dimension

Example:
<cac:Dimension>
        <cbc:AttributeID>AAF</cbc:AttributeID>
        <cbc:Measure unitCode="KGM">12.3</cbc:Measure>
</cac:Dimension>

Item identifiers are used for the receiver to understand what article has been received, at least one identifier is required, see related information here: Item description and identification In some cases, the authority has specific requirements carbon accounting in regards to where the products are beeing used. This requirement can be fulfilled by the use of Buyers item identification. See related information here: cac:BuyersItemIdentification

Example:
<cac:BuyersItemIdentification>
        <cbc:ID>123321</cbc:ID>
</cac:BuyersItemIdentification>
Generic Product Climate Data

Generic product climate data is often provided from an authority and are related to a product category codes such as UNSPSC or similar. Below you will find two examples from Swedish authorities that provide generic product climate data.

The list id IPNC is a reference to the code list Item Property Name Code list[Item Property Name Code (openPEPPOL)]

Table 8. Reference external generic climate data list.
Name NameCode listID Definition

Boverket Resource ID

BoVResourceID

IPNC

A representative Resource ID according to the Swedish National Board of Housing, Building and Planning (Boverket) generic product type. Use NA as value if no relevant Resource ID exists.

Trafikverket Resource ID

TrVResourceID

IPNC

A representative Resource ID according to the Swedish Transport Administration (Trafikverket) generic product type. Use NA as value if no relevant Resource ID exists.

If no suitable generic value can be found in the resource lists, it is recommended to use 'NA' to indicate that there are no applicable resources available for the item.

Example:
<!-- Generic climate data -->
<cac:AdditionalItemProperty>
        <cbc:Name>Boverket Resource ID</cbc:Name>
        <cbc:NameCode listID="IPNC">BoVResourceID</cbc:NameCode>
        <cbc:Value>6000000020</cbc:Value>
</cac:AdditionalItemProperty>
<cac:AdditionalItemProperty>
        <cbc:Name>Trafikverket Resource ID</cbc:Name>
        <cbc:NameCode listID="IPNC">TrVResourceID</cbc:NameCode>
        <cbc:Value>123456789</cbc:Value>
</cac:AdditionalItemProperty>
Environmental Product Declaration (EPD)

Environmental Product Declaration (EPD) provides specific CO2 data related to the product. EPD:s are related to despatch line but since it is environmental related information it is presented in this section.

Please note that "GWP-GHG" and "GWP-IOBC" are interchangable terms and can be used interchangeably, but in this document "GWP-GHG" is used. The term "GWP-IOBC" is commonly utilized by certain program operators, which are organizations responsible for publishing Environmental Product Declarations (EPDs).

Table 9. Definitions of the EPD related properties for machine readable information.
Name NameCode listID Definition

EPD Dataset ID

EPDDatasetID

IPNC

The EPD dataset id gives the digital reference to a produkt type in the EDP

EPD Dataset URL

EPDDataSetURL

IPNC

URL to fetch the machine readable digital information from a source assigned by the supplier

GWP GHG A1-3 vA1 EPD value

GWP-GHG_A1-3_vA1

IPNC

Global warming potential green house gases for process A1-3 100 EPD calculated per kilograms (unitCode="KGM") according to EN15804 amendment version A1

GWP GHG A1-3 vA2 EPD value

GWP-GHG_A1-3_vA2

IPNC

Global warming potential green house gases for process A1-3 100 EPD calculated per kilo grams (unitCode="KGM") according to EN15804 amendment version A2

GWP GHG A1-3 vA3 EPD value

GWP-GHG_A1-3_vA3

IPNC

Global warming potential green house gases for process A1-3 100 EPD calculated per kilo grams (unitCode="KGM") according to EN15804 amendment version A3

Mother EPD ID

MotherEPDID

IPNC

If a daughter EPD is utilized, the identifier of the corresponding mother EPD should be provided in this element.
Table 10. Definition of the EPD related properties for human readable information, e.g. EPD published as PDF.
Name NameCode listID Definition

Program Operator

ProgramOperator

IPNC

The name of the program operator that has published the EPD, if applicable.

EPD Number

EPDNumber

IPNC

The number of the published EDP

EPD Product name

EPDProductName

IPNC

The product name relating to an individual dataset in the EPD

EPD HR URL

EPDHRURL

IPNC

URL to the human readable version of an EPD, for verification purposes

GWP GHG A1-3 vA1 EPD value

GWP-GHG_A1-3_vA1

IPNC

Global warming potential green house gases for process A1-3 100 EPD calculated per kilo grams (unitCode="KGM") according to EN15804 amendment version A1

GWP GHG A1-3 vA2 EPD value

GWP-GHG_A1-3_vA2

IPNC

Global warming potential green house gases for process A1-3 100 EPD calculated per kilo grams (unitCode="KGM") according to EN15804 amendment version A2

GWP GHG A1-3 vA3 EPD value

GWP-GHG_A1-3_vA3

IPNC

Global warming potential green house gases for process A1-3 100 EPD calculated per kilo grams (unitCode="KGM") according to EN15804 amendment version A3

Mother EPD ID

MotherEPDID

IPNC

If a daughter EPD is utilized, the identifier of the corresponding mother EPD should be provided in this element.

See Reference to other documents for more info how to link or attach the PDF.

Example:
<!-- Specific climate data, machine readable EPD -->
<cac:AdditionalItemProperty>
        <cbc:Name>EPD Dataset ID</cbc:Name>
        <cbc:NameCode listID="IPNC">EPDDataSetID</cbc:NameCode>
        <cbc:Value>165f8554-00cd-43ad-aeb7-ba769854554a</cbc:Value>
</cac:AdditionalItemProperty>
<!-- Specific climate data, machine readable EPD -->
<cac:AdditionalItemProperty>
        <cbc:Name>EPD Dataset URL</cbc:Name>
        <cbc:NameCode listID="IPNC">EPDDataSetURL</cbc:NameCode>
        <cbc:Value>https://epdnorway.lca-data.com/resource/processes/165f8554-00cd-43ad-aeb7-ba769854554a?format=xml&amp;version=00.01.000</cbc:Value>
</cac:AdditionalItemProperty>

<!-- Specific climate data, human readable EPD -->
<cac:AdditionalItemProperty>
        <cbc:Name>Program Operator</cbc:Name>
        <cbc:NameCode listID="IPNC">ProgramOperator</cbc:NameCode>
        <cbc:Value>The Norwegian EPD Foundation</cbc:Value>
</cac:AdditionalItemProperty>
<!-- Specific climate data, human readable EPD -->
<cac:AdditionalItemProperty>
        <cbc:Name>EPD Number</cbc:Name>
        <cbc:NameCode listID="IPNC">EPDNumber</cbc:NameCode>
        <cbc:Value>NEPD-2154-978-SE</cbc:Value>
</cac:AdditionalItemProperty>
<!-- Specific climate data, human readable EPD -->
<cac:AdditionalItemProperty>
        <cbc:Name>EPD Product Name</cbc:Name>
        <cbc:NameCode listID="IPNC">EPDProductName</cbc:NameCode>
        <cbc:Value>Sweexp55 C30/37</cbc:Value>
</cac:AdditionalItemProperty>
<!-- Specific climate data, human readable EPD -->
<cac:AdditionalItemProperty>
        <cbc:Name>EPD HR URL</cbc:Name>
        <cbc:NameCode listID="IPNC">EPDHRURL</cbc:NameCode>
        <cbc:Value>https://www.epd-norge.no/getfile.php/1313397-1680247896/EPDer/Byggevarer/Ferdig%20betong/NEPD-2154-978_Sweexp55-C30-37-%281%29.pdf</cbc:Value>
</cac:AdditionalItemProperty>

<!-- Specific climate data, GWP value calculated by the supplier  -->
<cac:AdditionalItemProperty>
        <cbc:Name>GWP GHG A1-3 EPD total value for line</cbc:Name>
        <cbc:NameCode listID="IPNC">GWP-GHG_A1-3_vA1</cbc:NameCode>
        <cbc:Value>NA</cbc:Value>
        <cbc:ValueQuantity unitCode="KGM">0.251</cbc:ValueQuantity>
</cac:AdditionalItemProperty>

<!-- If the EPD is a daughter EPD, the corresponding mother EPD ID is added here -->
<cac:AdditionalItemProperty>
        <cbc:Name>Mother EPD ID</cbc:Name>
        <cbc:NameCode listID="IPNC">MotherEPDID</cbc:NameCode>
        <cbc:Value>NEPD-1717-700-SE</cbc:Value>
</cac:AdditionalItemProperty>

6.9. Reference to other documents

Both at header and line levels of the Despatch Advice it is possible to refer to, or attach, other documents to the Despatch Advice. As a minimum the Document ID and Document Type must be provided. Optionally the document itself, or the URL to the document, can be added.

Example, Header level:
<!-- Attached invoice -->
<cac:AdditionalDocumentReference>
        <cbc:ID>7648779</cbc:ID>
        <cbc:DocumentTypeCode>380</cbc:DocumentTypeCode>
        <cac:Attachment>
                <cbc:EmbeddedDocumentBinaryObject mimeCode="application/pdf" filename="Invoice_7648779.pdf">aHR0cHM6Ly90ZXN0LXZlZmEuZGlmaS5uby9wZXBwb2xiaXMvcG9hY2MvYmlsbGluZy8zLjAvYmlzLw==</cbc:EmbeddedDocumentBinaryObject>
                <cac:ExternalReference>
                        <cbc:URI>www.beast.se</cbc:URI>
                </cac:ExternalReference>
        </cac:Attachment>
</cac:AdditionalDocumentReference>

<!-- Attached drawing -->
<cac:AdditionalDocumentReference>
        <cbc:ID>67654</cbc:ID>
        <cbc:DocumentTypeCode>174</cbc:DocumentTypeCode>
        <cac:Attachment>
                <cbc:EmbeddedDocumentBinaryObject mimeCode="application/pdf" filename="Drawing_67654.pdf">aHR0cHM6Ly90ZXN0LXZlZmEuZGlmaS5uby9wZXBwb2xiaXMvcG9hY2MvYmlsbGluZy8zLjAvYmlzLw==</cbc:EmbeddedDocumentBinaryObject>
        </cac:Attachment>
</cac:AdditionalDocumentReference>

<!-- Reference to drawing -->
<cac:AdditionalDocumentReference>
        <cbc:ID>334421</cbc:ID>
        <cbc:DocumentTypeCode>174</cbc:DocumentTypeCode>
</cac:AdditionalDocumentReference>

<!-- Reference to project -->
<cac:AdditionalDocumentReference>
        <cbc:ID>P-7678</cbc:ID>
        <cbc:DocumentType>ProjectReference</cbc:DocumentType>
</cac:AdditionalDocumentReference>

<!-- Reference to accounting information -->
<cac:AdditionalDocumentReference>
        <cbc:ID>P-7678:776:1287</cbc:ID>
        <cbc:DocumentType>AccountingCost</cbc:DocumentType>
</cac:AdditionalDocumentReference>
Example, Line level:
<!-- Attached test report -->
<cac:DocumentReference>
        <cbc:ID>6675</cbc:ID>
        <cbc:DocumentTypeCode>4</cbc:DocumentTypeCode>
        <cac:Attachment>
                <cbc:EmbeddedDocumentBinaryObject mimeCode="application/pdf" filename="TestReport_6675.pdf">aHR0cHM6Ly90ZXN0LXZlZmEuZGlmaS5uby9wZXBwb2xiaXMvcG9hY2MvYmlsbGluZy8zLjAvYmlzLw==</cbc:EmbeddedDocumentBinaryObject>
                <cac:ExternalReference>
                        <cbc:URI>www.beast.se</cbc:URI>
                </cac:ExternalReference>
        </cac:Attachment>
</cac:DocumentReference>

<!-- Material Ticket (weight certificate) -->
<cac:DocumentReference>
        <cbc:ID>98987</cbc:ID>
        <cbc:DocumentTypeCode>14</cbc:DocumentTypeCode>
</cac:DocumentReference>

<!-- Material Ticket Reference (weight list) -->
<cac:DocumentReference>
        <cbc:ID>98987</cbc:ID>
        <cbc:DocumentTypeCode>15</cbc:DocumentTypeCode>
</cac:DocumentReference>

7. Despatch line

Description of items that are being despatched.

7.1. Item description and identification

Each despatch line contains elements for description and identification of the item. It is mandatory to have at least SellersItemIdentification or StandardItemIndentification, but the sender could send all the identifiers that they have.

Identifier Definition

cac:BuyersItemIdentification

An identifier, assigned by the buyer, for the item. Associates the item with its identification according to the buyer’s system.

cac:SellersItemIdentification

An identifier, assigned by the seller, for the item. Associates the item with its identification according to the seller’s system.

cac:ManufacturersItemIdentification

Identifying information for this item, assigned by the manufacturer.

cac:StandardItemIdentification

Global Trade Item Number (GTIN) or other standardized identification. An attribute (@schemeID) is set to the element to identify which standard the element contains, e.g schemeID="0160" specifies GTIN as the identifier.
Example:
<cac:Item>
        <cbc:Name>Item123</cbc:Name>
        <cac:BuyersItemIdentification>
                <cbc:ID>123321</cbc:ID>
        </cac:BuyersItemIdentification>
        <cac:SellersItemIdentification>
                <cbc:ID>010120401</cbc:ID>
        </cac:SellersItemIdentification>
        <cac:ManufacturersItemIdentification>
                <cbc:ID>010120401</cbc:ID>
        </cac:ManufacturersItemIdentification>
        <cac:StandardItemIdentification>
                <cbc:ID schemeID="0160">7611104117056</cbc:ID>
        </cac:StandardItemIdentification>

</cac:Item>

7.2. Commodity classification

Item classifications refer to the categorization or grouping of products or services based on various attributes such as type, purpose, industry standards, or any other relevant criteria. These classifications help in organizing and managing the vast array of items that a company might need to procure and follow up upon.

When procurement data is categorized based on item classifications and article numbers, it becomes easier to generate reports and conduct data analysis. This can help organizations identify spending patterns, track inventory levels, and make informed decisions about procurement strategies.

image

Besides the classification code itself, you need to include information on which code-list it belongs to. This you primarily do by referring to a @listID. The @listID is linked to UNCL7143. Select the correct @listID there. You may also specify the version in @listVersionID. If you use a codelist that is not in UNCL7143 you do like this: 1. Use "ZZZ" as the @listID. 2. Define the name of your codelist in attribute @name. You may also specify the version in @listVersionID.

Example - to classify the item according to BEAst’s codelist over SBMI items:
<cac:CommodityClassification>
        <cbc:ItemClassificationCode listID="ZZZ" listVersionID="3.0.2" name="SBMI">KO2012140200</cbc:ItemClassificationCode>
</cac:CommodityClassification>

7.3. Outstanding quantity

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

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

Example 1:

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

Quantity ordered: 10

Quantity delivered: 6

Outstanding quantity: 4

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

Example 2:

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

Quantity ordered: 10

Quantity delivered: 6

Outstanding quantity: 0

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

Example 3:

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

Quantity ordered: 10

Quantity delivered: 6

Outstanding quantity: 3

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

7.4. Hazardous item

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

UBL example of declaring hazardous items.
<cac:HazardousItem>
        <cbc:ID>123</cbc:ID>
        <cbc:AdditionalInformation>Information about the hazardous item</cbc:AdditionalInformation>
        <cbc:UNDGCode>ADR</cbc:UNDGCode>
        <cbc:TechnicalName>Corrosive liquid, n.o.s., 8, UN 1760, II (contains Octanoyl chloride)</cbc:TechnicalName>
        <cbc:CategoryName>Acute toxicity</cbc:CategoryName>
        <cbc:HazardousCategoryCode>123</cbc:HazardousCategoryCode>
        <cbc:HazardClassID>2.3</cbc:HazardClassID>
        <cbc:NetWeightMeasure unitCode="KGM">12345</cbc:NetWeightMeasure>
        <cbc:NetVolumeMeasure unitCode="MTQ">12.3</cbc:NetVolumeMeasure>
        <cac:HazardousGoodsTransit>
                <cbc:PackingCriteriaCode>123</cbc:PackingCriteriaCode>
        </cac:HazardousGoodsTransit>
        <cac:EmergencyTemperature>
                <cbc:AttributeID>ABC</cbc:AttributeID>
                <cbc:Measure unitCode="CEL">78</cbc:Measure>
        </cac:EmergencyTemperature>
</cac:HazardousItem>

7.5. Item properties

If additional item information such as properties and identifier are needed they can be added by using "Name" or "NameCode" to identify the type of information and "Value" for the information. In some situations also the ValueQuantity and ValueQualifier are needed.

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

<!-- Information about the price. -->
<cac:AdditionalItemProperty>
        <cbc:Name>NA</cbc:Name>
        <cbc:NameCode listID="IPNC">Price</cbc:NameCode>
        <cbc:Value>1200</cbc:Value>
        <!-- Price is for 10 pieces and the type of price is Contract. -->
        <cbc:ValueQuantity unitCode="C62">10.00</cbc:ValueQuantity>
        <cbc:ValueQualifier>CON</cbc:ValueQualifier>
</cac:AdditionalItemProperty>

<!-- The item is rented, not purchased. -->
<cac:AdditionalItemProperty>
        <cbc:Name>NA</cbc:Name>
        <cbc:NameCode listID="IPNC">Rental</cbc:NameCode>
        <cbc:Value>Purchase</cbc:Value>
</cac:AdditionalItemProperty>

7.6. Serial numbers

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

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

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

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

Expiry date is used for medical drugs.

Best before date is often used for food.

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

8. Peppol Identifiers

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

8.1. Profiles and messages

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

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

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

8.2. Customization and Profile identifiers

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

Type Element cbc:CustomizationID Element cbc:ProfileID

Despatch Advice (Trdm120)

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

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

8.3. Namespaces

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

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