This document describes the new version of EHF Despatch Advice (called "EHF Pakkseddel"). The document is part of Norwegian Agency for Public and Financial Management (DFØ) standardization work related to electronic commerce.

1. Principles and prerequisites

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

1.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 being sent, as well as details about the goods for cross checking with the order and ultimately the Electronic Despatch Advice is used for declaring how the despatched goods are packed.

The main activities supported by this message are:

  • Transport Full description of how the goods are packed and 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; the quantity of goods shipped and what is outstanding.

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

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

The consignee is the person or organization to which the products will be shipped and who is taking possession. The role is carried out by the customer or on behalf of the customer.

Despatch Party

(UBL: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)

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)

The party who will eventually receive and consume the goods and on whose behalf the buyer makes the purchase.

The diagram below shows the roles in the fulfillment process.

image

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

2. Process and typical Use Cases

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

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

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

2.4. Use case 1 - Simple Despatch

Description

This use case is a simple despatch where no handling units are used in the Despatch Advice. There are only two parties (legal entities) in this use case.

Parties involved

Despatch party (In UBL: DespatchSupplierParty) (same legal entity as the Supplier/Seller in this use case)
Consignee party (In UBL: DeliveryCustomerParty) (same legal entity as the Customer/Buyer in this use case)

Assumptions

  1. The Seller has received one order from the Buyer with

    1. 2 lines (2 articles)

    2.  to be delivered at one delivery address

    3. at the same time.

  2. The Seller has accepted the order without changes.

  3. The Despatch party delivers the complete order as accepted

Flow

  1. The Seller collects the ordered articles

  2. The Seller loads the articles in boxes

  3. The Despatch party creates a Despatch advice message

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

    1. Two despatch lines, two items (No handling units in the message)

Result

  1. The Despatch advice message helped the Consignee party to prepare receipt

    1. At the right time

    2. At the right place (address)

  2. The Despatch advice message helped the Consignee party in the process of register receipt to identify the

    1. Order

    2. The order lines

    3. The articles

    4. The delivered quantity

2.5. Use case 2 - Simple Despatch with outstanding quantity

Description

This use case is a simple Despatch where there are no transport handling units, but an outstanding quantity on line level. There are various examples on use of the outstanding quantity and the outstanding reason. There are four parties (legal entities) in this use case.

Parties involved

Buyer (In UBL: BuyerCustomerParty)
Seller (In UBL: SellerSupplierParty)
Despatch party (In UBL: DespatchSupplierParty) (Different legal entity than the Seller in this use case)
Consignee party (In UBL: DeliveryCustomerParty) (Different legal entity than the Buyer in this use case)

Assumptions

  1. The Seller has received one order from the Buyer with

    1. 5 lines (5 different items)

    2.  To be delivered at one delivery address

    3. At the same time.

  2. The Seller has accepted the order without changes.

  3. The Seller can’t deliver the complete order as accepted.

  4. The first line contains the ordered quantity

  5. The second line contains a delivery of 6 of 10 ordered items. The remaining 4 items will be delivered in another Despatch.

  6. The third line contains a delivery of 6 of 10 ordered items. The remaining 4 items will not be delivered.

  7. The fourth line contains a delivery of 6 of 10 items. 3 items will be delivered in another Despatch and 1 item will not be delivered.

  8. The fifth line contains a delivery of 12 of 10 ordered items.

Flow

  1. The Seller collects the ordered items

  2. The Seller loads the articles in boxes

  3. The Despatch party creates a Despatch advice message

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

  5. The Consignee party receives the Despatch advice message

  6. The Consignee party uses the content in Despatch advice message for registration receipt.

    1. Five Despatch lines with different articles, but a part of the articles related to line 2-5 is either outstanding or can’t be delivered at all. (No handling units in the message)

Result

  1. The Despatch advice message helped the Consignee party to prepare receipt

    1. At the right time

    2. At the right place (address)

  2. The Despatch advice message helped the Consignee party in the process of register receipt to identify the

    1. Order

    2. The order lines

    3. The items

    4. The delivered quantity

    5. The outstanding quantity to be delivered at a later time

    6. The outstanding quantity which will never be delivered

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

This use case is a refined use of the Despatch Advice where several GS1 keys are applied within the Despatch Advice to identify various entities in the despatch advice, namely; Parties, Endpoints, Shipment id, consignment ids, logistic unit ids and product identification.

Description

Describes a complete process whereby a Despatch party generates a Despatch Advice based on information about the order and the product. The Despatch Advice enables the supplier (carrier) to provide detailed information about the content of a shipment and enables a Buyer to reconcile, or confirm, the physical shipment against the order; it provides a mirror of the shipment’s packaging details and structure of the delivery. The Despatch Advice is sent by the Despatch party to the Consignee party when the goods are sent.

Parties involved

Despatch party In UBL: DespatchSupplierParty) (Different legal entity than the Seller in this use case)
Seller (In UBL: SellerSupplierParty)
Consignee party (In UBL: DeliveryCustomerParty) (Different legal entity than the Buyer in this use)
Buyer (In UBL: BuyerCustomerParty)

Pre Conditions

Master data alignment of locations (GLNs) and products (GTINs).

Post Conditions

Despatch advice is received by the receiver of the goods.

Assumptions

  1. The Despatch Advice has one shipment id (GSIN) assigned by the seller

  2. The Despatch Advice has one consignment id which has been assigned by the carrier (GINC)

  3. One delivery point (no cross docking) which is identified by a GLN.

  4. The four despatch lines are each an orderable unit – a GTIN.

  5. Two ordered units (GTINS) are packed on each pallet.

  6. There are two pallets in the shipment.

  7. Each standard pallet is assigned one logistics’ unit id (SSCC).

  8. A logistics’ label has been applied to each of the pallets where the SSCC is used rendered as clear text numbers, address details and GS1 128 barcode

    Relationship between the GTIN and the SSCC keys

    image

Flow

The Seller has accepted the order without changes.

  1. The Seller collects the ordered goods

  2. The ordered goods consist of one pallet per ordered 2 line items.

  3. The Despatch party loads the goods onto the transport.

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

  5. The Consignee party receives the Despatch advice message.

    1. The Consignee party uses the content in the Despatch advice message for registration receipt.

Result

  1. The Despatch advice message helped the Consignee party to prepare for receipt of goods:

    1. At the right time

    2. At the right location (address)

  2. The Despatch advice helped the Consignee party in the process of receipt registration to identify the:

    1. Order

    2. The order lines

    3. The logistics’ handling units

    4. The goods description

    5. The delivered quantity

    6. The parties involved in the process

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

Description

This use case demonstrates the use of the Despatch Advice, where the Seller is despatching items which are priced on weight, length and/or volume. Therefore the weight, length or volume of the items is important. Transport handling units are used to indicate how the items are packed.

The use case also demonstrates:

  • The use of different party identifiers (GLN and Swedish organization number)

  • The use of ItemBestBeforeDate, ItemExpiryDate, ItemBatchNumber, ItemSerialNumbers,

  • The use of SSCC keys,

  • The use of ItemSellersIdentifier and ItemStandardIdentifier (GTIN).

    Parties involved

    Despatch party (In UBL: DespatchSupplierParty) (same legal entity as the Supplier/Seller in this use case)
    Consignee party (In UBL: DeliveryCustomerParty) (same legal entity as the Customer/Buyer in this use case)

    Assumptions

    1. The Seller has received one order from the Buyer with

      1. 4 lines (4 items) which are priced by the weight

      2. To be delivered at one delivery address

      3. At the same time.

    2. The Seller has accepted the order without changes.

    3. The Seller delivers the complete order as accepted.

    4. The items are in four separate transport handling units.

image

Flow

  1. The Seller collects the ordered items

  2. The Seller weighs the items.

  3. The Seller loads the items into transport handling units (Boxes)

  4. The Despatch party creates the Despatch Advice message

  5. The Despatch party sends the Despatch Advice message to the Consignee

  6. The Consignee party receives the Despatch Advice message

  7. The Consignee party uses the content in the Despatch Advice message for registration receipt.

    1. Four despatch lines, four items.

    2. Handling units are identified using SSCC identifiers

    3. The delivered weight is used in the receipt activity (for verification)

  8. The Consignee party uses the content in the Despatch Advice message for storing- and handling.

    1. Items can be stored by BestBeforeDate or ExpiryDate

    2. Items can be stored by batch and/or serial numbers

    3. Items can be handled according to the weight of the handling unit

Result

  1. The Despatch Advice message helped the Consignee party to prepare receipt

    1. At the right time

    2. At the right place (address)

    3. With appropriate storage facilities

  2. The Despatch Advice message helped the Consignee party in the process of register receipt to identify the

    1. Order

    2. The order lines

    3. The transport handling units

    4. The items

    5. The delivered quantity/weight

2.8. Use case 5 – Advanced Despatch demonstrating most of the business terms

Description

This use case is a very complex use of the Despatch Advice which will demonstrate the use of all of the existing business terms available in the electronic Despatch advice message. The use case will also demonstrate different use of:

  • Party identification

  • Item identification

  • Packages

Parties involved

Buyer (In UBL: BuyerCustomerParty)
Seller (In UBL: SellerSupplierParty)
Despatch party (In UBL: DespatchSupplierParty) (Different legal entity than the Seller in this use case)
Consignee party (In UBL: DeliveryCustomerParty) (Different legal entity than the Buyer in this use case) Originating party (In UBL: OriginatorCustomerParty)

Assumptions

  1. The Seller party and Despatch party are different legal entities

  2. The Buyer party and Consignee party are different legal entities

  3. The Seller has received one order from the Buyer

    1. 5 order lines (5 items)

    2. Order line 4 is not delivered in this despatch

    3. The second Despatch line contains a delivery 6 of 10 ordered items. The remaining 4 items will be delivered in another despatch.

    4. The third Despatch line is weight based

    5. Order to be delivered at one delivery address

    6. At the same time.

    7. Despatch line 4 contain hazardous items

  4. The Seller has accepted the order without changes

  5. The Despatch party is responsible for the delivery and is using a carrier for the physical transportation

  6. The items in the first and second line are in the same transport handling unit

  7. The items in line three and four are in two separate transport handling units

image

Flow

  1. The Seller collects the ordered items

  2. The Seller loads the items into transport handling units (Boxes, crates, pallets etc.)

  3. The Despatch party identifies all shipping details

  4. The carrier picks up the goods for transport

  5. The Despatch party creates the Despatch advice message

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

  7. The Consignee can use the tracking ID to track the shipment

  8. The Consignee party receives the Despatch advice message

  9. The carrier delivers the goods to the Consignee

  10. The Consignee party uses the content in the Despatch advice message for registration receipt.

    1. Four Despatch lines, four items.

    2. Handling units are identified using SSCC identifiers

  11. The Consignee party uses the content in the Despatch advice message for storing- and handling.

    1. Handling unit with Hazardous items are identified

    2. Items can be stored by best before date, by batch and serial number

    3. Items can be handled according to the weight of the handling unit

Result

  1. The Despatch advice message helped the Consignee party to prepare receipt

    1. At right time

    2. At the right place (address)

    3. With appropriate tools and storage facilities

    4. In a secure manner

  2. The Despatch advice message helped the Consignee party in the process of register receipt to identify the

    1. Order

    2. The order lines

    3. The transport handling units

    4. The articles

    5. The delivered quantity/weight

3. Description of selected parts of the despatch advice message

3.1. Parties

The following parties/roles may be specified in the message. The same actor may play more than one role depending on the handling routine.

3.1.1. Despatch party (DespatchSupplierParty)

The Despatch Party is the person or organization who provides (despatch) the goods or services. The role is carried out by the supplier or on behalf of the supplier. (Despatch Party is sometimes known as the Consignor). The Despatch Party is mandatory information in the Despatch Advice message.

Example:

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

3.1.2. Consignee (DeliveryCustomerParty)

The Consignee is the person or organization to which the products will be shipped and who is taking possession. The role is carried out by the customer or on behalf of the customer. The Consignee is mandatory information in the Despatch Advice message.

Example:

<cac:DeliveryCustomerParty>
  <cac:Party>
    <cbc:EndpointID schemeID="0184">DK12345678</cbc:EndpointID>
    <cac:PartyIdentification>
      <cbc:ID schemeID="0088">7300010000001</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>Consignee Company</cbc:RegistrationName>
    </cac:PartyLegalEntity>
  </cac:Party>
  <cac:DeliveryContact>
    <cbc:Name>Tim</cbc:Name>
    <cbc:Telephone>987654321</cbc:Telephone>
    <cbc:ElectronicMail>Tim@RecieverCompany.dk</cbc:ElectronicMail>
  </cac:DeliveryContact>
</cac:DeliveryCustomerParty>

3.1.3. Buyer (BuyerCustomerParty)

The buyer is the legal person or organization who buys or purchases the goods or services. The role is carried out by the customer or on behalf of the customer.

The Buyer is optional information in the Despatch Advice message.

Example:

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

3.1.4. Seller (SellerSupplierParty)

The seller is the legal person or organization who sells goods or services to the customer. The role is carried out by the supplier or on behalf of the supplier. The Seller is optional information in the Despatch Advice message.

Example:

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

3.1.5. Originating party (OriginatorCustomerParty)

The party who will eventually receive and consume the goods and on whose behalf the buyer makes the purchase. The Originator Party is optional information in the Despatch Advice message.

Example:

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

3.2. Order reference

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

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

It is also possible to refer to more than one order in one single despatch advice. In this case there must not be an order reference on header level.

3.3. Shipment

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

3.3.1. Shipment ID

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

Example:

<cac:Shipment>
  <cbc:ID>NA</cbc:ID>
  <cbc:Information>Free text information relating to the Shipment</cbc:Information>
  <cbc:GrossWeightMeasure unitCode="KGM">23</cbc:GrossWeightMeasure>
  <cbc:GrossVolumeMeasure unitCode="MTQ">27</cbc:GrossVolumeMeasure>
  <cac:Consignment>
    <cbc:ID>12345</cbc:ID>
    <cac:CarrierParty>
      <cac:PartyName>
        <cbc:Name>CarrierPart</cbc:Name>
      </cac:PartyName>
    </cac:CarrierParty>
  </cac:Consignment>
  <cac:Delivery>
    <cac:EstimatedDeliveryPeriod>
      <cbc:StartDate>2013-03-15</cbc:StartDate>
      <cbc:StartTime>08:00:00</cbc:StartTime>
      <cbc:EndDate>2013-03-16</cbc:EndDate>
      <cbc:EndTime>12:00:00</cbc:EndTime>
    </cac:EstimatedDeliveryPeriod>
    <cac:Despatch>
      <cbc:ActualDespatchDate>2013-03-13</cbc:ActualDespatchDate>
      <cbc:ActualDespatchTime>08:00:00</cbc:ActualDespatchTime>
    </cac:Despatch>
  </cac:Delivery>
</cac:Shipment>

4. Despatch line

Description of items that are being despatched.

4.1. Item description and identification

Each despatch line contains elements for description and identification of the item. Normally only one of the identifiers is needed in the message.

Example:
<cac:Item>
  <cbc:Name>Item123</cbc:Name>
  <cac:SellersItemIdentification>
    <cbc:ID>010120401</cbc:ID>
  </cac:SellersItemIdentification>
  <cac:StandardItemIdentification>
    <cbc:ID schemeID="0160">7611104117056</cbc:ID>
  </cac:StandardItemIdentification>
</cac:Item>

4.2. Outstanding quantity

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

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

Example 1:

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

Quantity ordered: 10

Quantity delivered: 6

Outstanding quantity: 4

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

Example 2:

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

Quantity ordered: 10

Quantity delivered: 6

Outstanding quantity: 0

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

Example 3:

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

Quantity ordered: 10

Quantity delivered: 6

Outstanding quantity: 3

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

Ref. use case 2 above.

4.3. Hazardous item

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

UBL example of declaring hazardous items.
<cac:HazardousItem>
  <cbc:UNDGCode>ADR</cbc:UNDGCode>
  <cbc:HazardClassID>2.3</cbc:HazardClassID>
</cac:HazardousItem>

4.4. Item properties

If additional item information such as properties and identifier are needed they can be added by using "Name" to identify the type of information and "Value" for the information.

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

4.5. Serial numbers

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

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

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

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

Expiry date is used for medical drugs.

Best before date is often used for food.

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

4.7. Transport handling unit

The items on a Despatch line may be packed in several transport handling units which are the physical handling units such as box, container, pallet, etc. containing the consignment.

Serial shipping container code (SSCC) issued by GS1 may be used to identify the transport handling unit. Note that the same physical handling unit may contain items from different despatch lines. Implemented by referencing the same SSCC code in the ID element of the TransportHandlingUnit on several despatch lines.

Example:

<cac:TransportHandlingUnit>
  <cbc:ID>5454</cbc:ID>
  <cbc:TransportHandlingUnitTypeCode>4H</cbc:TransportHandlingUnitTypeCode>
  <cbc:HazardousRiskIndicator>false</cbc:HazardousRiskIndicator>
  <cbc:ShippingMarks>text</cbc:ShippingMarks>
  <cac:MeasurementDimension>
    <cbc:AttributeID>AAW</cbc:AttributeID>
    <cbc:Measure unitCode="LTR">1</cbc:Measure>
  </cac:MeasurementDimension>
</cac:TransportHandlingUnit>

Appendix A: UBL 2.2

This implementation guide builds on UBL 2.2 Schemas, available from OASIS.

These schemas are used when performing syntax validation.

Please see the homepage for information about the standard or further resources available.

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

B.1. Primitive types

Semantic data type content may be of the following primitive types. These primitive types were taken from ISO 15000-5:2014, Annex 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.

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

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

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

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

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

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

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

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

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

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

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

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

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