peppol

BIS Despatch Advice 3.1.0.5

OpenPeppolAISBL, Post-Award Coordinating Community

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

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

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

1. Link to main site of documentation

Main site of documentation

2. Introduction to openPeppol and BIS

This BIS is a result of work within Peppol project and is published as part of Peppol specifications.

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.

In this document, italian usage rules and paragraphs deriving from the italian e-procurement model are highlighted in yellow.

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

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

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

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

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

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

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

4. Process and typical scenarios

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

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

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

4.4. Typical use cases

4.4.1. Use case 1 - Simple Despatch

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.

Use Case number 1

Use Case Name

Simple Despatch

Use Case 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

The 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

4.4.2. Use case 2 - Simple Despatch with outstanding quantity.

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 outstanding reason There are four parties (legal entities) in this use case.

Use Case number 2

Use Case Name

Simple Despatch with outstanding quantity

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

The 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

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

Use Case number 3

Use Case Name

Despatch Advice with Logistic units using GS1 Keys

Use Case 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

    gtin scss

The 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

XML example file

See Annex A for a sample file illustrating Use Case 3.

The following provides additional details and clarifications about the various keys and identifiers used in this Use Case, as well as the benefits implementers can obtain when using them. Ultimately there are two pictures clarifying the relationship between the GSIN and the GINC identifiers.

Beneath are an overview and an explanation of the keys used in the Use Case.

GLN:

Global location number

Despatch party - Organizational identification.

Despatch party - Endpoint identification

Consignee - Organizational identification.

Consignee - Endpoint identification

Buyer - Organizational identification.

Buyer - Endpoint identification.

Seller - Organizational identification

Seller - Endpoint identification.

SSCC:

Serial Shipping Container Code

Each transport handling unit is assigned an SSCC.

The SSCC is the GS1 Identification Key for an item of any composition established for transport and/or storage which needs to be managed through the supply chain. The SSCC is assigned for the life time of the transport item and is a mandatory element on the GS1 Logistic Label

GSIN:

Global Shipment Identification Number

Shipment identification. One shipment number for the despatch advice.

A document level id that specifies the number of the Shipment along the entire shipment, which, may consist of several consignments.

  • Number assigned by the seller to identify a logical grouping of logistic or transport units that are typically assembled by the seller for a transport shipment.

  • It meets the World Customs Organisation (WCO) requirement for a Unique Consignment Reference (URC).

It is endorsed by ISO/IEC 15459 (ISO License Plate)

GINC:

Global Identification Number of Consignment

One consignment number for the Despatch Advice

  • Used to identify a logical grouping of logistic or transport units that are assembled to be transported under one transport document.

  • It is used to identify a logical grouping of logistic units during a specific journey of which there may be multiple consignment stages.

GTIN:

Global trade Item Number

Each ordered item as a GTIN.

Product identification.
Beneath are an overview of the benefits implementers can get when using the keys and identifiers.

GTIN:

Global trade Item Number

  • Correct goods and associated data have been sourced through upfront data alignment

GLN

Global Location Number

  • Precise and trustworthy location data has been achieved through GS1 master data alignment location registers.

SSCC:

Serial Shipping Container Code

  • Logistic units are individually identified with the SSCC (Serial Shipping Container Code)

  • The item (goods) details accessed by scanning (bar code) or reading (EPC/RFID) the SSCC on the logistic unit and accessing the relevant information.

  • The usage of the SSCC on a logistic unit is subject to rules, namely that multiple visible SSCCs on one logistics unit can only be used for transit purposes.

    • If two or more SSCCs are applied on a logistics unit then the units associated to a given SSCC have to be individually wrapped or bound together to form individual logistics units.

    • Multiple SSCCs can be applied to individual units on one logistic unit for subsequent cross docking but they HAVE to be wrapped so that they are not visible.

  • Additionally, a master logistics label needs to be applied to the whole logistics unit for the consignment to the distribution center.

GSIN:

Global Shipment Identification Number

  • A globally recognised shipping number used to uniquely identify the shipment as a whole as specified by the seller

GINC:

Global Identification Number of Consignment

  • A globally recognised consignment number used to uniquely identify the consignment as specified by the shipper.

Supplementary clarification on the usage of the GSIN and the GINC.

Assembling of the keys:

image::../images/image8.png

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

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.

Use Case number 4

Use Case Name

Despatch with weight, length and/or volume based items (ie vegetables, meat)

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

image9

The 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

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

This use case is a relatively more complex use of the Despatch Advice which will demonstrate the use of most of the business terms available in the electronic Despatch Advice message.

Use Case number 5

Use Case Name

Advanced Despatch Advice demonstrating most of the business terms

Use Case 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

image10

The 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

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

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

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

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

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

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

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

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

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

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

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

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

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

5.2.11. Binary objects

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

Component Use Primitive Type Example

Content

Mandatory

Binary

QmFzZTY0IGNvbnRlbnQgZXhhbXBsZQ==

Mime Code

Mandatory

String

image/jpeg

Filename

Mandatory

String

drawing5.jpg

5.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.3. Use of concatenated information in structured fields

The use of concatenated information in structured fields is permitted, where possible; this means XML elements that contain tuples of values, divided among themselves by the symbol "#" and without using spaces, as shown in the following example:

<Tag>Value#Value#Value</Tag>

Structured fields allowed are solely and strictly the ones listed in the table below:

Structured fields

OrderReference/ID

DespatchLine/OrderLineReference/OrderReference/ID

6. Code lists

6.1. Code lists for coded elements

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

6.2. Code list for identifiers

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

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

6.2.2. Electronic address identifier scheme identifier

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

Valid values are found in the Codelist EAS

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

7. Description of selected parts of the despatch advice message

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

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

In particular, name and identifier are mandatory as per Article 21, comma 4 of DPR n. 633/1972.

The same information are required and verified by the Access Point of destination in order for the purpose of the reconciliation with the Order.

Example:

<cac:DespatchSupplierParty>
        <cac:Party>
                <cbc:EndpointID schemeID="0211">IT01234567890</cbc:EndpointID>
                <cac:PartyIdentification>
                        <cbc:ID schemeID="0211">IT01234567890</cbc:ID>(1)
                </cac:PartyIdentification>
                <cac:PartyLegalEntity>
                        <cbc:RegistrationName>Speditore/Fornitore</cbc:RegistrationName>
                </cac:PartyLegalEntity>
                <cac:Contact>
                        <cbc:Name>Giovanni</cbc:Name>
                        <cbc:Telephone>123456789</cbc:Telephone>
                        <cbc:ElectronicMail>giovanni@speditore.it</cbc:ElectronicMail>
                </cac:Contact>
        </cac:Party>
</cac:DespatchSupplierParty>
1 the VAT number must be specified with the attribute @schemeID filled with the code "0211"

7.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 as per Article 21, comma 4 of DPR n. 633/1972.

Example:

<cac:DeliveryCustomerParty>
        <cac:Party>
                <cbc:EndpointID schemeID="0201">ABCDEF</cbc:EndpointID>
                <cac:PartyIdentification>
                        <cbc:ID  schemeID="0210">02483810392</cbc:ID>(1)
                </cac:PartyIdentification>
                <cac:PostalAddress>
                        <cbc:StreetName>Via Europa 100</cbc:StreetName>
                        <cbc:AdditionalStreetName>Palazzo A, Interno 409</cbc:AdditionalStreetName>
                        <cbc:CityName>Bologna</cbc:CityName>
                        <cbc:PostalZone>40121</cbc:PostalZone>
                        <cbc:CountrySubentity>Bologna</cbc:CountrySubentity>
                        <cac:Country>
                                <cbc:IdentificationCode>IT</cbc:IdentificationCode>
                        </cac:Country>
                </cac:PostalAddress>
                <cac:PartyLegalEntity>
                        <cbc:RegistrationName>Consegnatario/Cliente</cbc:RegistrationName>
                </cac:PartyLegalEntity>
        </cac:Party>
        <cac:DeliveryContact>
                <cbc:Name>Gianfranco Verdi</cbc:Name>
                <cbc:Telephone>987654321</cbc:Telephone>
                <cbc:ElectronicMail>g.verdi@consegnatario.it</cbc:ElectronicMail>
        </cac:DeliveryContact>>
</cac:DeliveryCustomerParty>
1 the Fiscal Code must be specified with with the attribute @schemeID filled with the code "0210"

7.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="0210">02483810392</cbc:ID>
                </cac:PartyIdentification>
                <cac:PartyName>
                        <cbc:Name>Acquirente S.p.A.</cbc:Name>
                </cac:PartyName>
                <cac:PostalAddress>
                        <cbc:StreetName>Via Napoli 1</cbc:StreetName>
                        <cbc:CityName>Milano</cbc:CityName>
                        <cbc:PostalZone>20100</cbc:PostalZone>
                        <cbc:CountrySubentity>MI</cbc:CountrySubentity>
                        <cac:Country>
                                <cbc:IdentificationCode>IT</cbc:IdentificationCode>
                        </cac:Country>
                </cac:PostalAddress>
        </cac:Party>
</cac:BuyerCustomerParty>

7.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="0211">IT01234567890</cbc:ID>
                </cac:PartyIdentification>
                <cac:PartyName>
                        <cbc:Name>Venditore p/c Fornitore</cbc:Name>
                </cac:PartyName>
                       <cac:PostalAddress>
                        <cbc:StreetName>Via Ferrara 300</cbc:StreetName>
                        <cbc:CityName>Milano</cbc:CityName>
                        <cbc:PostalZone>20100</cbc:PostalZone>
                        <cbc:CountrySubentity>MI</cbc:CountrySubentity>
                        <cac:Country>
                                <cbc:IdentificationCode>IT</cbc:IdentificationCode>
                        </cac:Country>
                </cac:PostalAddress>
        </cac:Party>
</cac:SellerSupplierParty>

7.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="0211">02483810392</cbc:ID>
                </cac:PartyIdentification>
                <cac:PartyName>
                        <cbc:Name>Committente</cbc:Name>
                </cac:PartyName>
                <cac:PostalAddress>
                        <cbc:StreetName>Via Monte Napoleone 1</cbc:StreetName>
                        <cbc:CityName>Milano</cbc:CityName>
                        <cbc:PostalZone>20100</cbc:PostalZone>
                        <cbc:CountrySubentity>MI</cbc:CountrySubentity>
                        <cac:Country>
                                <cbc:IdentificationCode>IT</cbc:IdentificationCode>
                        </cac:Country>
                </cac:PostalAddress>
        </cac:Party>
</cac:OriginatorCustomerParty>

7.1.6. Carrier Party

The Carrier manages the delivery/physical transport of the shimpent. Utilized if the delivery is carried out by a third party.

Example:

<cac:CarrierParty>
        <cac:PartyIdentification>
                <!-- Identificativo Fiscale Vettore -->
                <cbc:ID schemeID="0211">IT01245267890</cbc:ID>
        </cac:PartyIdentification>
        <!-- Obbligatorio: Art. 21, comma 4 del DPR n. 633/1972 -->
        <cac:PartyName>
                <cbc:Name>Trasportatore S.r.l.</cbc:Name>
        </cac:PartyName>
        <cac:PostalAddress>
                <!-- Obbligatorio: Art. 21, comma 4 del DPR n. 633/1972 -->
                <cbc:StreetName>Via Europa 100</cbc:StreetName>
                <cbc:AdditionalStreetName>Palazzo A</cbc:AdditionalStreetName>
                <!-- Obbligatorio: Art. 21, comma 4 del DPR n. 633/1972 -->
                <cbc:CityName>Bologna</cbc:CityName>
                <!-- Obbligatorio: Art. 21, comma 4 del DPR n. 633/1972 -->
                <cbc:PostalZone>40121</cbc:PostalZone>
                <!-- Obbligatorio: Art. 21, comma 4 del DPR n. 633/1972 -->
                <cbc:CountrySubentity>Bologna</cbc:CountrySubentity>
                <cac:Country>
                        <cbc:IdentificationCode>IT</cbc:IdentificationCode>
                </cac:Country>
        </cac:PostalAddress>
</cac:CarrierParty>

7.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 (element "cbc:LineID") 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.

Reference to the related order must be done indicating the "identification triplet" (so-called Tripletta di identificazione) of the Order through the concatenation of the following values:

  • Order ID;

  • IssueDate valorized with the date of the order;

  • EndpointID of the element BuyerCustomerParty in the order;

Example on header level
<cac:OrderReference>
        <cbc:ID>4321#2013-01-30#ABCDEF</cbc:ID>
</cac:OrderReference>
Example 1 on line level
<cac:OrderLineReference>
        <cbc:LineID>1</cbc:LineID>
        <cac:OrderReference>
                <cbc:ID>879865#2013-01-30#ABCDEF</cbc:ID>
        </cac:OrderReference>
</cac:OrderLineReference>
Example 2 on line level
<cac:OrderLineReference>
        <cbc:LineID>NA</cbc:LineID>
        <cac:OrderReference>
                <cbc:ID>9898654#2013-01-30#ABCDEF</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.

In order to refer to more orders it is possible to indicate one or more Order numbers on each despatch line.

Example 1 on line level with reference to many orders
<cac:OrderLineReference>
        <cbc:LineID>5</cbc:LineID>
        <cac:OrderReference>
                <cbc:ID>123#2013-01-30#ABCDEF</cbc:ID>
        </cac:OrderReference>
</cac:OrderLineReference>
<cac:OrderLineReference>
        <cbc:LineID>5</cbc:LineID>
        <cac:OrderReference>
                <cbc:ID>456#2013-01-30#ABCDEF</cbc:ID>
        </cac:OrderReference>
</cac:OrderLineReference>

7.2.1. Additional reference to the Order

When the Documento di trasporto refers to a single Order on the header level, with the element cbc:CustomerReference is possible to provide a further reference of the Client.

This information is utilized as reference issued by the Client to identify the object of the shimpent, such as the final receiver of pharmaceutical products (Patient ID) in the case of home delivery (see §. 6.3.1)

Example of reference to a client in the case of home delivery:
<cac:OrderReference>
    <cbc:ID>4321#2013-01-30#ABCDEF</cbc:ID>
    <!-- ID Paziente -->
    <cbc:CustomerReference>123</cbc:CustomerReference>
</cac:OrderReference>

7.3. Shipment

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

7.3.1. Shipment ID, Carrier party, shimpment information, delivery and despatch

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.

As part of the shipping information (Shipment), the following are provided: weight, volume, packages (transport handling units), Carrier Party, estimated delivery period and actual despatch.

Measures such as weight and volume are mandatory sono obbligatoriamente espresse secondo la codifica UN/ECE Recommendation 20, Revision 11 (2015) e non è richiesto qualificarle con ulteriori attributi.
Example:
<cac:Shipment>
        <cbc:ID>NA</cbc:ID>
        <cbc:Information>Informazioni testuali libere relative alla Spedizione</cbc:Information>
        <!-- Peso lordo, obbligatorio in base all'Art. 21, comma 4 del DPR n. 633/1972 -->
        <cbc:GrossWeightMeasure unitCode="KGM">23</cbc:GrossWeightMeasure>(1)
        <!-- Volume lordo -->
        <cbc:GrossVolumeMeasure unitCode="MTQ">27</cbc:GrossVolumeMeasure>(2)
        <!-- Nr. Colli, obbligatorio in base all'Art. 21, comma 4 del DPR n. 633/1972 -->
        <cbc:TotalTransportHandlingUnitQuantity>3</cbc:TotalTransportHandlingUnitQuantity>(3)
        <!--TRASPORTO, VETTORE-->
        <cac:Consignment>
                <cbc:ID>12345</cbc:ID>(4)
                <cac:CarrierParty>
                        <cac:PartyIdentification>
                                <!-- Identificativo Fiscale Vettore -->
                                <cbc:ID>PIVA:IT01245267890</cbc:ID>(5)
                        </cac:PartyIdentification>
                        <!-- Obbligatorio: Art. 21, comma 4 del DPR n. 633/1972 -->
                        <cac:PartyName>
                                <cbc:Name>Trasportatore S.r.l.</cbc:Name>(6)
                        </cac:PartyName>
                        <cac:PostalAddress>(7)
                                <!-- Obbligatorio: Art. 21, comma 4 del DPR n. 633/1972 -->
                                <cbc:StreetName>Via Europa 100</cbc:StreetName>
                                <cbc:AdditionalStreetName>Palazzo A</cbc:AdditionalStreetName>
                                <!-- Obbligatorio: Art. 21, comma 4 del DPR n. 633/1972 -->
                                <cbc:CityName>Bologna</cbc:CityName>
                                <!-- Obbligatorio: Art. 21, comma 4 del DPR n. 633/1972 -->
                                <cbc:PostalZone>40121</cbc:PostalZone>
                                <!-- Obbligatorio: Art. 21, comma 4 del DPR n. 633/1972 -->
                                <cbc:CountrySubentity>Bologna</cbc:CountrySubentity>
                                <cac:Country>
                                        <cbc:IdentificationCode>IT</cbc:IdentificationCode>
                                </cac:Country>
                        </cac:PostalAddress>
                </cac:CarrierParty>
        </cac:Consignment>
                        <!-- INFORMAZIONI SULLO STATO DELLA SPEDIZIONE -->
        <cac:ShipmentStage>
                <cbc:TransportModeCode>2</cbc:TransportModeCode>
        </cac:ShipmentStage>
                        <!-- TEMPI DI CONSEGNA PROMESSI/STIMATI -->
        <cac:Delivery>(8)
                <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>
                <!-- DATA/ORA EVASIONE EFFETTIVA -->
                <cac:Despatch>(9)
                        <cbc:ActualDespatchDate>2013-03-13</cbc:ActualDespatchDate>
                        <cbc:ActualDespatchTime>08:00:00</cbc:ActualDespatchTime>
                </cac:Despatch>
        </cac:Delivery>
</cac:Shipment>
1 Gross weight
2 Gross volume
3 Nr. Transport handling unit, expressed as whole number (see rule IT-T16-R005)
4 Identifier assigned to this delivery
5 Tax ID Carrier
6 Company name or Carrier’s name
7 Address
8 Estimated/promised delivery period
9 Date/time actual despatch

In the case of home delivery (for example, delivery to the address of a patient) this circumstance needs to be specified valorizing the field “ID” with the text “Consegna domiciliare” and indicating accurately in the element “AddressLine/Line” the exact delivery address (for instance, including the flat number), as shown by the following example:

Example
<cac:Delivery>
    <cac:DeliveryLocation>
        <cac:ID>Consegna domiciliare</cac:ID>
        <Name>Entrata lato portineria</Name>
        <cac:Address>
            <cbc:StreetName>Via Attanasio Soldati 80</cbc:StreetName>
            <cbc:AdditionalStreetName>Località La Rustica</cbc:AdditionalStreetName>
            <cbc:CityName>Roma</cbc:CityName>
            <cbc:PostalZone>00155</cbc:PostalZone>
            <cbc:CountrySubentity>Lazio</cbc:CountrySubentity>
            <cac:AddressLine>
                <cbc:Line>Edificio C, Quarto piano, Stanza 01</cbc:Line>
            </cac:AddressLine>
            <cac:Country>
                <cbc:IdentificationCode>IT</cbc:IdentificationCode>
            </cac:Country>
        </cac:Address>
    </cac:DeliveryLocation>
</cac:Delivery>

7.4. Attachments

Non-XML documents can be sent as attachments to the Peppol BIS Despatch Advise. This could be drawings or time sheets or other documents relevant for the order. The attachment can either be sent as a binary object encoded in Base64 embedded in the message or as a URI to an external address as a link.

It is recommended to send attachments as embedded, binary objects and not as external references.
Example of attachment as an embedded, binary object
Unresolved directive in description/_attachments.adoc - include::../../../../rules/snippets/despatch/snippet-01.xml[tags=attachment]
1 It is recommended to use element cac:AdditionalDocumentReference/cbc:DocumentType to send a short description of the content of the attachment.
2 File name and extension should be sent in the filename attribute to the cbc:EmbeddedDocumentBinaryObject element.  
Attachments should be used for additional information and not as order copies.

8. Despatch line

Description of items that are being despatched.

8.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>
        <!-- Obbligatorio: Art. 21, comma 4 del DPR n. 633/1972 -->
        <cbc:Name>Item123</cbc:Name>
        <!-- Obbligatorio: Art. 21, comma 4 del DPR n. 633/1972 -->
        <cac:SellersItemIdentification>
                <cbc:ID>010120401</cbc:ID>
        </cac:SellersItemIdentification>
        <cac:StandardItemIdentification>
                <!-- GS1 GTIN -->
                <cbc:ID schemeID="0160">7611104117056</cbc:ID>
        </cac:StandardItemIdentification>
</cac:Item>

8.1.1. Details on pharmaceutical products and their identification - AIC code

For pharmaceutical products provided with the code "Autorizzazione all’Immissione in Commercio" (AIC), released by the Agency "Agenzia Italiana del Farmaco" (AIFA), the element cac:SellersItemIdentification/cbc:ID needs to be valued with the AIC code, prefixed by the string "AICFARMACO:".

Example of an order with the indication of the AIC code
<cac:DespatchLine>
    ...
        <cac:Item>
            <cbc:Name>NORVASC</cbc:Name>
            <cac:SellersItemIdentification>
                <cbc:ID>AICFARMACO:027428010</cbc:ID>
            </cac:SellersItemIdentification>
        </cac:Item>
</cac:DespatchLine>

In particular circumstances, some foreign pharmaceutical products are commercialized in Italy without the authorization released by the AIFA. This products do not fall within the application of the Decree of the Italian Ministry of the Economy 20 December 2017, bearing “Modalità tecniche di indicazione dell’AIC sulla fattura elettronica, nonché modalità di accesso da parte dell’AIFA ai dati ivi contenuti”, and the alphanumeric code associated to them it is not an AIC code exactly, therefore needs to be indicated without the prefix “AICFARMACO:”.

8.1.2. Details on medical devices products and their identification - UDI code

For medical devices products provided with the code UDI (Unique Device Identification) released by the Agency "GS1 Italy", the element cac:SellersItemIdentification/cbc:ID needs to be valued with the UDI code, prefixed by the string "UDI:".

Example of an order with the indication of the UDI code
<cac:DespatchLine>
    ...
        <cac:Item>
            <cbc:Name>Item's name</cbc:Name>
            <cac:SellersItemIdentification>
              <cbc:ID>UDI:(01)47964367965424(11)173434(17)226565(10)A379B3(21)1237</cbc:ID>
            </cac:SellersItemIdentification>
        </cac:Item>
</cac:DespatchLine>

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

<!-- Obbligatorio: Art. 21, comma 4 del DPR n. 633/1972 -->
<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

<!-- Obbligatorio: Art. 21, comma 4 del DPR n. 633/1972 -->
<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

<!-- Obbligatorio: Art. 21, comma 4 del DPR n. 633/1972 -->
<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.

8.3. Hazardous item

The Peppol Despatch Advice also contains the possibility to inform the Consignee about Hazardous Items (also referred to as HAZMAT, Hazard Material o Dangerous Goods).

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>
        <!-- UNCL8273 -->
        <cbc:UNDGCode>ADR</cbc:UNDGCode>
        <!-- Classe di pericolosità -->
        <cbc:HazardClassID>2.3</cbc:HazardClassID>
</cac:HazardousItem>

In certain sectors may be necessary to identify the hazardous items in a more precise way, by providing the following information:

Table 4. Extended information about the hazardous items

Extended information

Description

UBL syntax

Hazardous item identifier

Assigned UN identifier (UN Number)

cbc:ID

Hazardous item technical name

UN technical name

cbc:TechnicalName

Hazardous item category

Name of the type of hazard for a material or substance

cbc:CategoryName

In the next paragraph provides an advanced example that utilizes all the extended information described above.

8.3.1. Advances example in the Health sector: anablastics drugs

In case it is necessary to identify in a more precise way the hazardous items, it is possibile to provide further information, such as:

  • Hazardous item identifier, according to the NDGCode convention;

  • Hazardous item technical name;

  • Hazardous item category.

In the case of hazardous item road transport (e.g. anablastics) the convention ADR is used, which defines the Hazard classes and identifies each substance with an UN Number.

In the table below, the most used identifiers and the related hazard classes for anablastics transportation are provided:

Table 5. Hazard classes

UN number

UN denomination

Hazard class

UN 1851

Medicine, liquid, toxic, n.o.s

6.1

UN 3248

Medicine, liquid, flammable, toxic, n.o.s

3

UN 3249

Medicine, solid, toxic, n.o.s

6.1

For further clarifications, see the example below.

Example of anablastics drugs
<cac:DespatchLine>
        <cac:Item>
                <cac:HazardousItem>
                        <cbc:ID>3249</cbc:ID>(1)
                        <cbc:UNDGCode>ADR</cbc:UNDGCode>(2)
                        <cbc:TechnicalName>Medicine, solid, toxic, n.o.s</cbc:TechnicalName>(3)
                        <cbc:CategoryName>ANTIBLASTICI</cbc:CategoryName>(4)
                        <cbc:HazardClassID>6.1</cbc:HazardClassID>(5)
                </cac:HazardousItem>
        </cac:Item>
        <cac:Shipment>
                <cbc:ID>123456</cbc:ID>
                <cac:TransportHandlingUnit>
                        <cbc:HazardousRiskIndicator>true</cbc:HazardousRiskIndicator>
                </cac:TransportHandlingUnit>
        </cac:Shipment>
</cac:DespatchLine>

The example above denotes the use of:

1 UN identifier (UN Number) assigned to the substance: 3249
2 The convention: ADR (European agreement on the international carriage of dangerous goods on road) according to the codelist UNCL8273 (Dangerous goods regulations code)
3 Technical name of the medicinal: Medicine, solid, toxic, n.o.s
4 Category of the medicinal: ANTIBLASTICI
5 Hazard class

UN Numbers are available in the following tool:

http://www.hazmattool.com/info.php

8.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 of the element cac:AdditionalItemProperty.

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

8.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 specifying one specific instance for each serial number.

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

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

8.6.1. AIFA Note (Italian Medicine Agency)

When the expiry date of a medical drug is indicated with month and year, the validity is meant to be until the last day of the month.

This is stated in the "Quality review of documents human product information annotated template", document that the European Medicines Agency makes available on its portal and that indicates which information neeeds to be reported on medical drugs' prints (Summary of Product Characteristics, Package Leaflet and Label).

In particular, point 8 of Annex III clarifies: “The expiry date printed on medicinal product stating only month and year should be taken to mean the last day of that month”.

The document is available at the following link:

http://www.ema.europa.eu/ema/index.jsp?curl=pages/regulation/document_listing/document_listing_000134.jsp&mid=WC0b01ac0580022c59

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

The code "TransportHandlingUnitTypeCode" allow to specify precisely the type of transport handling unit using the codelist UN/ECE Rec 21, of which some examples are reported below:

Table 6. Type of transport handling unit

Code

Transport handling unit

CT

Carton

CS

Case

BX

Box

PX

Pallet

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.

In Italy the logistic label placed over the logistic unit, such as one pallet with the related SSCC identifier, is usually called “segnacollo”.

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>

8.8. Additional information (free items or discounts)

It is possibile to utilize the element cbc:AdditionalInformation to provide additional information about free items or discounts on the line level, as shown in the example below:

Example of a free article
<cbc:DespatchLine>
        <cbc:ID>3</cbc:ID>
        <!-- Obbligatorio: Art. 21, comma 4 del DPR n. 633/1972 -->
        <cbc:DeliveredQuantity unitCode="SR">20</cbc:DeliveredQuantity>
        …
        <cac:Item>
                <!-- Obbligatorio: Art. 21, comma 4 del DPR n. 633/1972 -->
                <cbc:Name>Striscie per glucosio</cbc:Name>
                <cbc:AdditionalInformation>OMAGGIO</cbc: AdditionalInformation>
        </cac:Item>
</cbc:DespatchLine>
Example of a discounted article
<cbc:DespatchLine>
        <cbc:ID>3</cbc:ID>
        <!-- Obbligatorio: Art. 21, comma 4 del DPR n. 633/1972 -->
        <cbc:DeliveredQuantity unitCode="SR">20</cbc:DeliveredQuantity>
        …
        <cac:Item>
                <!-- Obbligatorio: Art. 21, comma 4 del DPR n. 633/1972 -->
                <cbc:Name>Striscie per glucosio</cbc:Name>
                <cbc:AdditionalInformation>SCONTO MERCE</cbc: AdditionalInformation>
        </cac:Item>
</cbc:DespatchLine>

8.9. Packaging

In order to provide information about the packaging, it is possibile to use two differents ways depending on how the order is carried out, meaning if the item corresponds with the unit quantity "C62" or the packaging unit "XPK".

If the ordered article is a package, it is important to indicate the correct unit of measure.

The following table provides clarification on how to add information about single units within the package and viceversa, meaning when the article coincides with the unit base, to provide information about the packaging.

Type of information Descriprion

PackSizeNumeric

It indicates the number of articles contained in a primary packaging (for example, how many pills or unit “C62” in a package “XPK”)

PackQuantity

It indicates the number of sub-units contained in a secondary packaging (for example, how many boxes or packages “XPK” there are in a box “XBX”)

Two meaningful examples are below.

8.9.1. Case 1: Ordered item by single unit

This is an example of an item ordered as single unit and not as package, and so the indication of number of pieces into the primary package:

<cac:DespatchLine>
    <!-- 5000 guanti -->
    <cbc:Quantity unitCode="C62">5000</cbc:Quantity>
    <cac:Item>
        <cbc:Name>Guanti</cbc:Name>
        <cac:SellersItemIdentification>
            <!-- O altro identificativo (es. Standard) -->
            <cbc:ID>XYZ</cbc:ID>
        </cac:SellersItemIdentification>
        <cac:AdditionalItemProperty>
            <!-- Una confezione contiene 500 pezzi -->
            <cbc:Name>PackSizeNumeric</cbc:Name>
            <cbc:Value>500</cbc:Value>
        <cac:AdditionalItemProperty>
        <cac:AdditionalItemProperty>
            <cbc:Name>PackIdentification</cbc:Name>
            <!-- Codice confezione -->
            <cbc:Value>XYZ500</cbc:Value>
        </cac:AdditionalItemProperty>
    </cac:Item>
</cac:DespatchLine>

8.9.2. Case 2: Ordered item by package

This is an example in which the item is ordered by package:

<cac:DespatchLine>
    <!--10 confezioni di guanti -->
    <cbc:Quantity unitCode="XPK">10</cbc:Quantity>
    <cac:Item>
        <cbc:Name>CONFEZIONE GUANTI</cbc:Name>
        <cac:SellersItemIdentification>
            <!-- O altro identificativo (es. Standard) -->
            <cbc:ID>XYZ500</cbc:ID>
        </cac:SellersItemIdentification>
        <cac:AdditionalItemProperty>
            <!-- Una articolo (confezione) contiene 500 pezzi -->
            <cbc:Name>PackQuantity</cbc:Name>
            <cbc:Value>500</cbc:Value>
        <cac:AdditionalItemProperty>
        <cac:AdditionalItemProperty>
            <cbc:Name>UnitIdentification</cbc:Name>
            <!-- Codice unità base -->
            <cbc:Value>XYZ</cbc:Value>
        </cac:AdditionalItemProperty>
    </cac:Item>
</cac:DespatchLine>

8.10. Special treatment (line level)

In some cases, a part of the shipping may need a special treatment, such as the refrigeration of the goods.

The element cbc:HandlingCode on the line level, in Shipment segment, can be used as the example below:

Example
<cac:DespatchLine>
        <cac:Shipment>
                <cbc:HandlingCode>11</cbc:HandlingCode>
        </cac:Shipment>
</cac:DespatchLine>

Use the codelist “HandlingInstructionDescriptionCode” (UN/CEFACT code list 4079, D.17A) available in the codelists section.

8.11. Specifications on the shipment

To provide further details about a consignment it is possible to utilize the segment cac:Shipment/cac:GoodsItem on the line level, as part of information about the shipment.

In particular, it is possible to specify information about the temperature recommended and allowable as described below.

8.11.1. Temperature

To indicate the recommended and allowable temperature for some goods or the minimum/maximum tolerated temperature, it is possible to specify it always in the detail of the shipment as shown in the following example:

Example of temperature settingsmperatura:
<cac:DespatchLine>
        <cac:Shipment>
                <cac:GoodsItem>
                        <cac:Temperature>
                                <cbc:AttributeID>Recommended</cbc:AttributeID>
                                <cbc:Measure unitCode="CEL">-20</cbc:Measure>
                        </cac:Temperature>
                        <cac:MinimumTemperature>
                                <cbc:AttributeID>Allowable</cbc:AttributeID>
                                <cbc:Measure unitCode="FAH">-20</cbc:Measure>
                        </cac:MinimumTemperature>
                        <cac:MaximumTemperature>
                                <cbc:AttributeID>Allowable</cbc:AttributeID>
                                <cbc:Measure unitCode="FAH">15</cbc:Measure>
                        </cac:MaximumTemperature>
                </cac:GoodsItem>
        </cac:Shipment>
</cac:DespatchLine>

The example denotes the use of unit of measures Celsius (CEL) and Fahrenheit (FAH). The element cbc:AttributeID is mandatory but can be ignored valorizing it as NA. However in some cases can improve the understanding of the temperature provided (es. Recommended, Allowable, Alert).

Measures are necesseraly expressed according to the codelist UN/ECE Recommendation 20 and it is not required to qualify them with further attributes.

8.12. Product classification

For each product, inside the related despatch line it is possible to specify one or more classification codes, valorizing the element “ItemClassificationCode/ID” of the segment “CommodityClassification”.

It is advisable, however, to use at least one of the classification systems for goods and services shown in the table below, where applicable.

Code Description of the classification standard Use

STI

CPV – Common Procurement Vocabulary

Products and services subject to public procurement

STL

ATC - Anatomical Therapeutic Chemical classification system

Medical drugs

STO

Medical Devices National Classification (CND - Classificazione Nazionale dei Dispositivi Medici)

Medical devices

STH

GPC – Global Product Classification

Consumer goods

IB

ISBN - International Standard Book Number

Books (also in electronic format and other products created to be used as books)

ZZZ

System defined mutually between the parties

For medical devices it allows to specify the values “DM1”, “DM2” or “DM0” (when the first two are not applicable)

It is advisable to indicate in detail product with different products' code on separeted order lines.
Example of a product classification indication
<cac:CommodityClassification>
        <cbc:ItemClassificationCode listID="STL">N05BA01</cbc:ItemClassificationCode>
</cac:CommodityClassification>

8.12.1. Indications for medical devices

The example below shows that the in the element cac:CommodityClassification/cbc:ItemClassificationCode is provided the registration number attributed to the medical devices in the Italian "Banca dati dei dispositivi medici" from Ministry of Health.

Please note that as indicated in the Circular of the Ministry of Health DGSISS-0002051-P-08/02/2019, the attribute schemeID must be valorized with:

  • DM1 for “Dispositivo medico o Dispositivo diagnostico in vitro”

  • DM2 for “Sistema o kit Assemblato”

  • DM0 for "Nessun numero di repertorio"

Example of a double indication of product classification
<cac:Item>
    <cbc:Name>Nome del Dispositivo</cbc:Name>
    <cac:SellersItemIdentification>
        <cbc:ID>Codice attribuito dal Fornitore</cbc:ID>
    </cac:SellersItemIdentification>
    <cac:CommodityClassification>
        <cbc:ItemClassificationCode listID="STO">P09070302</cbc:ItemClassificationCode>
    </cac:CommodityClassification>
    <cac:CommodityClassification>
        <cbc:ItemClassificationCode listID="ZZZ">DM1:229026</cbc:ItemClassificationCode>
    </cac:CommodityClassification>
</cac:Item>

Notice that, in the example, the element “CommodityClassificationCode” is used twice (due to its multiple cardinality), because it’s been indicated also the corresponding code STO, related to the product classificaton into the system of "Classificazione Nazionale italiana dei Dispositivi medici".

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

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

9.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 (Trdm16)

urn:fdc:peppol.eu:poacc:trns:despatch_advice:3 :extended:urn:www.agid.gov.it:trns:ddt:3.1

urn:fdc:peppol.eu:poacc:bis:despatch_advice:3

9.3. Namespace

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

9.4. Endpoint ID

The Endpoint ID is specified in the document to maintain information about the electronic address of the sender or the receiver and it is used for channeling the documents (delivery) on the Peppol network.

The types of identifier used in Italy and recognized by Peppol are:

  • 0211 for the VAT number;

  • 0210 for the Fiscal code, of legal person or entity;

  • 0201 for the Codice Univoco Ufficio (so-called "iPA code", from Indice delle Pubbliche Amministrazioni).

In Italy IPA code is suggested to register register public administrations over the Peppol delivery network, however it is not compulsory and if not available it is recommended the use of the fiscal code.

Example for an Endpoint of a Public Administration registered on Peppol with the Codice Univoco Ufficio:
<cbc:EndpointID schemeID="0201">ABCDEF</cbc:EndpointID>
Example for an Endpoint of a Public Administration registered on Peppol with the fiscal code:
<cbc:EndpointID schemeID="0210">07643520567</cbc:EndpointID>
Example for an Endpoint of a Public Administration registered on Peppol with the VAT number:
<cbc:EndpointID schemeID="0211">IT07643520567</cbc:EndpointID>
Example for an Endpoint of a Public Administration registered on Peppol with the GLN (Global Location Number), according to GS1 standard:
​<cbc:EndpointID schemeID="0088">5790000435968</cbc:EndpointID