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

Statement of copyright

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

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

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

Link to main site of documentation

Main documentation site

1. Introduction to openPEPPOL and BIS

This BIS (Business Interoperability Specification) is a result of work within BEAst Supply 4.0 Project and Peppol Logistics Incubation Project. After the incubation project it will be part of the specifications in new Logistics domain in OpenPeppol.

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.

Figure 1. Relationship between BII profiles and PEPPOL BIS

1.1. Background and objective

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

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

1.2. Audience

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

These organizations may be:

Service providers
Contracting Authorities
Economic Operators
Software Developers

More specifically it is addressed towards the following roles:

ICT Architects
ICT Developers
Business Experts

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

2. Principles and prerequisites

This chapter describes the principles and assumptions that underlie the use of the Logistics Advanced Despatch Advice with Receipt Advice.

2.1. Business process in scope

This Peppol BIS supports a process for suppliers to send an Advanced Despatch Advice and for buyers to return a Receipt Advice. It is intended to support transmission of electronic messages for processing in automated processes by the receiver.

The main activities supported by this BIS are:

Transport Full description of how the goods is packed and delivered, or how and when the services are delivered. A delivery is taken to be a number of items that are despatched as a single consignment to a single delivery address.
Despatch Line States what is shipped or delivered; the quantity of the delivery and what is outstanding.
Validation Buyer can accept or reject the Advanced Despatch Advice by sending the Receipt Advice as a reply to the Advanced Despatch Advice.
Receiving Full support of the process of receiving goods into a warehouse, inventory, in stores or simply at a reception counter or receiving services at agreed location
Responding Response from the buyer after receiving the goods/service by sending the Receipt Advice with three alternative usages:
- a) Reject the whole Consignment
- b) Accept the whole Consignment without any claim.
- c) Accept the Consignment with claims:
  - 1) Report damages at Transport Handling Units.
  - 2) Report shortage or other issues with the received products/services.

2.2. Parties and roles

The table below gives the definitions of the parties and roles of the Receipt Advice. For the parties in the Advanced Despatch Advice, please read the BIS Advanvced Despatch Advice Only.

Parties	Definition
Customer	The customer is the legal person or organization who has received a product or service. Examples of customer roles: buyer, consignee, debtor, contracting authority.
Supplier	The supplier is the legal person or organization who has provided a product or service to the customer. Examples of supplier roles: seller, despatch party, creditor, economic operator.
Carrier	The carrier handles the physical delivery/transportation of the shipment that arrived to the Consignee. Used if a third party is handling the physical transport.

Parties

Definition

Customer

The customer is the legal person or organization who has received a product or service.

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

Supplier

The supplier is the legal person or organization who has provided a product or service to the customer.

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

Carrier

The carrier handles the physical delivery/transportation of the shipment that arrived to the Consignee. Used if a third party is handling the physical transport.

Roles	Definition
Delivery party/Consignee (UBL:DeliveryCustomerParty)	Defines the role that has received the goods or the service. It also defines the sender of the Receipt Advice.
Despatch Party/Consignor (UBL:DespatchSupplierParty)	Defines the role that provided the goods or the service to the Consignee. It also defines the receiver of the Receipt Advice.
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.

Roles

Definition

Delivery party/Consignee

(UBL:DeliveryCustomerParty)

Defines the role that has received the goods or the service. It also defines the sender of the Receipt Advice.

Despatch Party/Consignor

(UBL:DespatchSupplierParty)

Defines the role that provided the goods or the service to the Consignee. It also defines the receiver of the Receipt Advice.

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.

The diagram below shows the roles in the fulfillment process.

2.3. Other important concepts

The table below gives the definitions of key concepts of the Receipt Advice. For the concepts in the Advanced Despatch Advice, please read the BIS Advanvced Despatch Advice Only.

Term	Definition
Shipment	A contractual arrangement whereby an identifiable collection of goods items is to be transported from one party (usually a Supplier) to another party (usually a Customer).
Consignment	The transportation of an identifiable collection of goods items from one party (the Despatch Party) to another party (the Consignee) via one or more modes of transport.
Transport Handling Unit	A description of individual handling units in which the line items are packed.
Master Data	Master data is data which is generally static. Data such as locations or product item can be considered master data. The process of data alignment is the exchange, “up-front”, between trading partners of location and/or item data. In a GS1 context, master data is referenced by GS1 identification keys; the GLN – the global location number for locations, and the GTIN – global trade item number for item products.
Logistics Label	A logistics’ label has been applied to each of the pallets where the SSCCs are used and rendered as clear text numbers, address details and GS1 128 barcode. NB where multiple SSCCs are applied to logistics’ units on one pallet, there needs to be a GS1 logistics label applied and exterior of the pallet. The subordinate SSCCs on the individual logistics units should be packaged in such a way that they are not visible to the naked eye (in this scenario). For a full description of how to apply SSCCs and the GS1 Logistic label see link; http://www.gs1.eu/?page=&tudasbazis=60&lister=26
Delivery	Delivery of goods or services as per agreement and conditions described in the Despatch Advice.

Term

Definition

Shipment

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

Consignment

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

Transport Handling Unit

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

Master Data

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

Logistics Label

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

Delivery

Delivery of goods or services as per agreement and conditions described in the Despatch Advice.

3. Process and use cases

3.1. Legend for BPMN diagrams

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

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

3.2. Scenario 1 - Process with sending Advanced Despatch Advice before the delivery of the goods

This process implies the sending of an Advanced Despatch Advice before the actual delivery has taken place. This enables the parties to correct any errors in the transactions and/or the delivery before the goods is transported from the Despatch party.

An Advanced Despatch Advice sent before the delivey may have a defined DespatchAdviceTypeCode, but if omitted, this is the default.

The following controls should be done by the consignee after reception of the Advanced Despatch Advice:

Check that the message validates OK against all business rules
Check that all parties are the correct ones.
Check that the order reference is correct
Check that any other references are correct

Based on these controls a Receipt Advice can be sent as the confirmation that the Advanced Despatch Advice is correct, contains errors or just is received but not yet controlled.

When goods arrives and is received a new Recipt Advice can be created to report to the supplier quantities were ok or if there are issues to manage.

3.3. Scenario 2 - Process with sending the Advanced Despatch Advice after the delivery of the goods.

This process implies the sending of an Advanced Despatch Advice after the actual delivery has taken place. This enables the Consignee also to approve or reject the actual delivery of the goods.

3.4. How the Receipt Advice is used when sending it multiple times.

The Receipt Advice can be sent multiple times as a response first to the Advanced Despatch Advice, then as a response to the received shipment. Which type of Receipt Advice it is, is shown by the Receipt Advice Type Code.

New updates can after that be sent if issues are found when unpacking the received goods.

Here a summary of this:

Confirmation of having received an Advanced Despatch Advice, but not yet validated the content (ReceiptAdviceTypeCode = "D" and DespatchDocumentReference/DocumentStatusCode = "AB").
Confirmation of having received an Advanced Despatch Advice and validated the codes and identities which were found to be ok or not ok. (ReceiptAdviceTypeCode = "D" and DespatchDocumentReference/DocumentStatusCode = "AP" or "RE").
Confirmation of having received the goods/service in the referred Advanced Despatch Advice. Missing or damaged Transport Handling Units can be reported, and any other issue on Consignment or Transport Handling Unit can be reported. (ReceiptAdviceTypeCode = "S" and Shipment/Consignment/Status/ConditionCode = "AP", "CA" or "RE").
Confirmation of having received the goods/service in the referred Advanced Despatch Advice. After unpacking the Transport Handling Units new issues, like shortages or quality issues on the parts, can be found causing a new version of the Receipt Advice to be sent. (ReceiptAdviceTypeCode = "S" and ReceiptLine/ShortQuantity and/or RejectedQuantity).

The last update of the Receipt Advice is only sent if new issues are found.

3.5. Use-cases

The different use-cases described here are focusing only on the different options to use the Receipt Advice. They are not related directly to any of the use-cases for the Advanced Despatch Advice - The resposes here can be used for any Advanced Despatch Advice use-case. Example files for Receipt Advice are included in Appendix A.

3.5.1. Typical use cases

The table below lists the nine use cases.

Use Case Number	Definition	Link
1	Confirm the reception of a Advanced Despatch Advice before content is validated.	Link to use case 1
2	Confirm the reception and the validation of an Advanced Despatch Advice.	Link to use case 2
3	Reject the reived Advanced Despatch Advice due to application errors (Party identities, References etc.).	Link to use case 3
4	Goods/service has been received with no claims.	Link to use case 4
5	Goods/service has arrived outside requested time window and is rejected.	Link to use case 5
6	Goods/service has arrived too late, but been received.	Link to use case 6
7	Goods has been received with damages on Transport Handling Unit.	Link to use case 7
8	Goods has been received with a missing Transport Handling Unit.	Link to use case 8
9	Goods has been received ok but when opening the Transport Handling Unit there is a shortage found.	Link to use case 9

Use Case Number

Definition

Link

Confirm the reception of a Advanced Despatch Advice before content is validated.

Link to use case 1

Confirm the reception and the validation of an Advanced Despatch Advice.

Link to use case 2

Reject the reived Advanced Despatch Advice due to application errors (Party identities, References etc.).

Link to use case 3

Goods/service has been received with no claims.

Link to use case 4

Goods/service has arrived outside requested time window and is rejected.

Link to use case 5

Goods/service has arrived too late, but been received.

Link to use case 6

Goods has been received with damages on Transport Handling Unit.

Link to use case 7

Goods has been received with a missing Transport Handling Unit.

Link to use case 8

Goods has been received ok but when opening the Transport Handling Unit there is a shortage found.

Link to use case 9

Use case 1 – Confirm the reception of a Advanced Despatch Advice before content is validated.

This use case is based on the recommendation that an Advanced Despatch Advice should be confirmed as received before any validation starts.

Use Case number	1
Use Case Name	Confirm the reception of a Advanced Despatch Advice before content is validated.
Use Case Description	This is only a simple confirmation that the Advanced Despatch Advice has been technically received. No data checks have yet been made. The Receipt Advice enables the goods receiver to give a confirmation that the Adva nced Despatch Advice has been received. This enables the Supplier check this step and wait for the next.
Parties involved	Buyer (In UBL: BuyerCustomerParty) Seller (In UBL: SellerSupplierParty) Despatch party (In UBL: DespatchSupplierParty) (Same legal entity as the Seller in this use case) Consignee party (In UBL: DeliveryCustomerParty) (Same legal entity as the Buyer in this use case).
Pre conditions	Advanced Despatch Advice is sent from Consignor to Consignee. Receipt Advice is sent from Consignee to Consignor.
Post conditions	Receipt advice is received by the sender of the goods.
Assumptions	The Consignor and Consignee has agreed to use the Receipt Advice message as a confirmation of that the Advance Despatch Advice has been received. Later new Receipt Advices can be exchanged depending on what other agreements have been made.
The flow	The Advanced Despatch Advice is received by the Consignee. If the formal validation (Peppol business rules) passes and the Advanced Despath Advice is received, a Receipt Advice message is sent by the Consignee’s application. The Consignor party receives the Receipt advice message The Consignor party uses the content in the Despatch advice message confirm that the Advanced Despatch Advice now has been received by the Conignee. The Consignee now can continue to the next steps of validating data and receive the goods/service.
Result	The Receipt advice message helped the Consignee party to inform the supplier that the Advanced Despatch ADvice has arrived. With no formal errors That the process now continues with next steps The Receipt advice message helped the Consignor party in the process to be sure that the Advanced Despatch Advice is received and in the process.
XML example file	See Examples files Appendix A for a sample file illustrating Use Case 1.

Use Case number

Use Case Name

Confirm the reception of a Advanced Despatch Advice before content is validated.

Use Case Description

This is only a simple confirmation that the Advanced Despatch Advice has been technically received. No data checks have yet been made.

The Receipt Advice enables the goods receiver to give a confirmation that the Adva nced Despatch Advice has been received. This enables the Supplier check this step and wait for the next.

Parties involved

Buyer (In UBL: BuyerCustomerParty)

Seller (In UBL: SellerSupplierParty)

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

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

Pre conditions

Advanced Despatch Advice is sent from Consignor to Consignee. Receipt Advice is sent from Consignee to Consignor.

Post conditions

Receipt advice is received by the sender of the goods.

Assumptions

The Consignor and Consignee has agreed to use the Receipt Advice message as a confirmation of that the Advance Despatch Advice has been received.
Later new Receipt Advices can be exchanged depending on what other agreements have been made.

The flow

The Advanced Despatch Advice is received by the Consignee.
If the formal validation (Peppol business rules) passes and the Advanced Despath Advice is received, a Receipt Advice message is sent by the Consignee’s application.
The Consignor party receives the Receipt advice message
The Consignor party uses the content in the Despatch advice message confirm that the Advanced Despatch Advice now has been received by the Conignee.
The Consignee now can continue to the next steps of validating data and receive the goods/service.

Result

The Receipt advice message helped the Consignee party to inform the supplier that the Advanced Despatch ADvice has arrived.
1. With no formal errors
2. That the process now continues with next steps
The Receipt advice message helped the Consignor party in the process to be sure that the Advanced Despatch Advice is received and in the process.

XML example file

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

Use case 2 – Confirm the reception and the validation of an Advanced Despatch Advice.

This use case is based on the recommendation that an Advanced Despatch Advice should be confirmed as received and validated before the goods reception is made.

Use Case number	2
Use Case Name	Confirm the reception and validation of an Advanced Despatch Advice.
Use Case Description	This is the confirmation that the Advanced Despatch Advice has been received. Data checks have been made and all checked data is found to be correct. The Receipt Advice enables the goods receiver to give a confirmation that the Advanced Despatch Advice has been received and controlled OK. This enables the Supplier check this step and wait for the next.
Parties involved	Buyer (In UBL: BuyerCustomerParty) Seller (In UBL: SellerSupplierParty) Despatch party (In UBL: DespatchSupplierParty) (Same legal entity as the Seller in this use case) Consignee party (In UBL: DeliveryCustomerParty) (Same legal entity as the Buyer in this use case).
Pre conditions	Advanced Despatch Advice is sent from Consignor to Consignee. Receipt Advice is sent from Consignee to Consignor.
Post conditions	Receipt advice is received by the sender of the goods.
Assumptions	The Consignor and Consignee has agreed to use the Receipt Advice message as a confirmation of that the Advance Despatch Advice has been received and controlled. Earlier a Receipt Advice may have been exchanged before any data checks were made. Later new Receipt Advices can be exchanged depending on what other agreements have been made.
The flow	The Advanced Despatch Advice is received by the Consignee. If the formal validation (Peppol business rules) and the application validation (Party identities, References etc.) of the Advanced Despatch Advice pass, a Receipt Advice message is sent by the Consignee’s application. The Consignor party receives the Receipt advice message The Consignor party uses the content in the Despatch advice message confirm that the Advanced Despatch Advice now has been received by the Conignee. The Consignee now can continue to the next step to receive the goods/service.
Result	The Receipt advice message helped the Consignee party to inform the supplier that the Advanced Despatch ADvice has arrived. With no formal errors, no application errors That the process now continues with next steps The Receipt advice message helped the Consignor party in the process to be sure that the Advanced Despatch Advice is received and in the process.
XML example file	See Examples files Appendix A for a sample file illustrating Use Case 2.

Use Case number

Use Case Name

Confirm the reception and validation of an Advanced Despatch Advice.

Use Case Description

This is the confirmation that the Advanced Despatch Advice has been received. Data checks have been made and all checked data is found to be correct.

The Receipt Advice enables the goods receiver to give a confirmation that the Advanced Despatch Advice has been received and controlled OK. This enables the Supplier check this step and wait for the next.

Parties involved

Buyer (In UBL: BuyerCustomerParty)

Seller (In UBL: SellerSupplierParty)

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

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

Pre conditions

Advanced Despatch Advice is sent from Consignor to Consignee. Receipt Advice is sent from Consignee to Consignor.

Post conditions

Receipt advice is received by the sender of the goods.

Assumptions

The Consignor and Consignee has agreed to use the Receipt Advice message as a confirmation of that the Advance Despatch Advice has been received and controlled.
Earlier a Receipt Advice may have been exchanged before any data checks were made.
Later new Receipt Advices can be exchanged depending on what other agreements have been made.

The flow

The Advanced Despatch Advice is received by the Consignee.
If the formal validation (Peppol business rules) and the application validation (Party identities, References etc.) of the Advanced Despatch Advice pass, a Receipt Advice message is sent by the Consignee’s application.
The Consignor party receives the Receipt advice message
The Consignor party uses the content in the Despatch advice message confirm that the Advanced Despatch Advice now has been received by the Conignee.
The Consignee now can continue to the next step to receive the goods/service.

Result

The Receipt advice message helped the Consignee party to inform the supplier that the Advanced Despatch ADvice has arrived.
1. With no formal errors, no application errors
2. That the process now continues with next steps
The Receipt advice message helped the Consignor party in the process to be sure that the Advanced Despatch Advice is received and in the process.

XML example file

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

Use case 3 – Reject the reived Advanced Despatch Advice due to application errors (Party identities, References etc.).

This use case is based on the recommendation that an Advanced Despatch Advice should be confirmed as received and validated before the goods reception is made.

Use Case number	3
Use Case Name	Reject the reived Advanced Despatch Advice due to application errors (Party identities, References etc.).
Use Case Description	This is the confirmation that the Advanced Despatch Advice has been received. Data checks have been made and errors have been found. The received Advanced Despatch Advice is now deleted and the supplier should correct it and send it again. The Receipt Advice enables the goods receiver to request a correction of the errors found and that the supplier must send a new version. This enables the Supplier to correct the errors so that a new correct Advanced Despatch Advice can be sent.
Parties involved	Buyer (In UBL: BuyerCustomerParty) Seller (In UBL: SellerSupplierParty) Despatch party (In UBL: DespatchSupplierParty) (Same legal entity as the Seller in this use case) Consignee party (In UBL: DeliveryCustomerParty) (Same legal entity as the Buyer in this use case).
Pre conditions	Advanced Despatch Advice is sent from Consignor to Consignee. Receipt Advice is sent from Consignee to Consignor.
Post conditions	Receipt advice is received by the sender of the goods.
Assumptions	The Consignor and Consignee has agreed to use the Receipt Advice message as a confirmation of that the Advance Despatch Advice has been received and controlled. Earlier a Receipt Advice may have been exchanged before any data checks were made. Later new Receipt Advices can be exchanged depending on what other agreements have been made.
The flow	The Advanced Despatch Advice is received by the Consignee. If the formal validation (Peppol business rules) and the application validation (Party identities, References etc.) of the Advanced Despatch Advice fail, a Receipt Advice message is sent by the Consignee’s application. The Consignor party receives the Receipt advice message The Consignor party uses the content in the Despatch advice message to correct and resend the Advanced Despatch Advice. The Consignee will wait for a new version of the Advanced Despatch Advice to be received.
Result	The Receipt advice message helped the Consignee party to inform the supplier that the Advanced Despatch Advice has been rejected due to errors. The supplier now must correct the errors and send a new Advanced Despatch Advice. The Receipt advice message helped the Consignor party to find the errors so that a new correct Advanced Despatch Advice can be sent.
XML example file	See Examples files Appendix A for a sample file illustrating Use Case 3.

Use Case number

Use Case Name

Reject the reived Advanced Despatch Advice due to application errors (Party identities, References etc.).

Use Case Description

This is the confirmation that the Advanced Despatch Advice has been received. Data checks have been made and errors have been found. The received Advanced Despatch Advice is now deleted and the supplier should correct it and send it again.

The Receipt Advice enables the goods receiver to request a correction of the errors found and that the supplier must send a new version. This enables the Supplier to correct the errors so that a new correct Advanced Despatch Advice can be sent.

Parties involved

Buyer (In UBL: BuyerCustomerParty)

Seller (In UBL: SellerSupplierParty)

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

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

Pre conditions

Advanced Despatch Advice is sent from Consignor to Consignee. Receipt Advice is sent from Consignee to Consignor.

Post conditions

Receipt advice is received by the sender of the goods.

Assumptions

The Consignor and Consignee has agreed to use the Receipt Advice message as a confirmation of that the Advance Despatch Advice has been received and controlled.
Earlier a Receipt Advice may have been exchanged before any data checks were made.
Later new Receipt Advices can be exchanged depending on what other agreements have been made.

The flow

The Advanced Despatch Advice is received by the Consignee.
If the formal validation (Peppol business rules) and the application validation (Party identities, References etc.) of the Advanced Despatch Advice fail, a Receipt Advice message is sent by the Consignee’s application.
The Consignor party receives the Receipt advice message
The Consignor party uses the content in the Despatch advice message to correct and resend the Advanced Despatch Advice.
The Consignee will wait for a new version of the Advanced Despatch Advice to be received.

Result

The Receipt advice message helped the Consignee party to inform the supplier that the Advanced Despatch Advice has been rejected due to errors. The supplier now must correct the errors and send a new Advanced Despatch Advice.
The Receipt advice message helped the Consignor party to find the errors so that a new correct Advanced Despatch Advice can be sent.

XML example file

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

Use case 4 – Goods/service has been received with no claims.

This use case is based on the recommendation that a receipt of goods or service should be confirmed by a Receipt Advice.

Use Case number	4
Use Case Name	Goods/service has been received with no claims.
Use Case Description	This is the confirmation that the goods/service has been received with no claims found. The Receipt Advice enables the goods receiver to inform the supplier that the goods/service was received without any problems. (At a later stage, when the Transport Handling Units are opened and the content is checked, an updated Receipt Advice may be sent.) This enables the Supplier to issue the corresponding invoice.
Parties involved	Buyer (In UBL: BuyerCustomerParty) Seller (In UBL: SellerSupplierParty) Despatch party (In UBL: DespatchSupplierParty) (Same legal entity as the Seller in this use case) Consignee party (In UBL: DeliveryCustomerParty) (Same legal entity as the Buyer in this use case).
Pre conditions	Advanced Despatch Advice is sent from Consignor to Consignee. Receipt Advice is sent from Consignee to Consignor.
Post conditions	Receipt advice is received by the sender of the goods.
Assumptions	The Consignor and Consignee has agreed to use the Receipt Advice to confirm that the goods/service has been received. Earlier a Receipt Advice may have been exchanged to confirm the reception of the Advanced Despatch Advice. Later new Receipt Advices can be exchanged if shortages or other problems are found at a later stage.
The flow	The Advanced Despatch Advice is received by the Consignee. A Receipt Advice may be sent by the Consignee to confirm/reject the Advanced Despatch Advice. The goods/service is received. A Receipt Advice is created and sent by the Consignee party. The Consignor party receives the Receipt advice message. The Consignor party uses the content in the Advanced Despatch Advice and Receipt Advice messages to start the invoicing process. The Consignee will wait for a the invoice to arrive.
Result	The Receipt advice message helped the Consignee party to inform the supplier that the goods/service was received ok and that it now is ok to send the invoice. The Receipt advice message helped the Consignor party know when to start the invoicing process.
XML example file	See Examples files Appendix A for a sample file illustrating Use Case 4.

Use Case number

Use Case Name

Goods/service has been received with no claims.

Use Case Description

This is the confirmation that the goods/service has been received with no claims found.

The Receipt Advice enables the goods receiver to inform the supplier that the goods/service was received without any problems. (At a later stage, when the Transport Handling Units are opened and the content is checked, an updated Receipt Advice may be sent.) This enables the Supplier to issue the corresponding invoice.

Parties involved

Buyer (In UBL: BuyerCustomerParty)

Seller (In UBL: SellerSupplierParty)

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

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

Pre conditions

Advanced Despatch Advice is sent from Consignor to Consignee. Receipt Advice is sent from Consignee to Consignor.

Post conditions

Receipt advice is received by the sender of the goods.

Assumptions

The Consignor and Consignee has agreed to use the Receipt Advice to confirm that the goods/service has been received.
Earlier a Receipt Advice may have been exchanged to confirm the reception of the Advanced Despatch Advice.
Later new Receipt Advices can be exchanged if shortages or other problems are found at a later stage.

The flow

The Advanced Despatch Advice is received by the Consignee.
A Receipt Advice may be sent by the Consignee to confirm/reject the Advanced Despatch Advice.
The goods/service is received.
A Receipt Advice is created and sent by the Consignee party.
The Consignor party receives the Receipt advice message.
The Consignor party uses the content in the Advanced Despatch Advice and Receipt Advice messages to start the invoicing process.
The Consignee will wait for a the invoice to arrive.

Result

The Receipt advice message helped the Consignee party to inform the supplier that the goods/service was received ok and that it now is ok to send the invoice.
The Receipt advice message helped the Consignor party know when to start the invoicing process.

XML example file

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

Use case 5 – Goods/service has arrived outside requested time window and is rejected.

This use case is based on the recommendation that a receipt of goods or service should be confirmed by a Receipt Advice.

Use Case number	5
Use Case Name	Goods/service has arrived outside requested time-window and is rejected.
Use Case Description	This is the confirmation that the goods/service has been rejected because it arrived outside time window. The Receipt Advice enables the goods receiver to inform the supplier that the goods/service was rejected. This enables the Supplier to start the process of shipping the goods/service again at a new time slot.
Parties involved	Buyer (In UBL: BuyerCustomerParty) Seller (In UBL: SellerSupplierParty) Despatch party (In UBL: DespatchSupplierParty) (Same legal entity as the Seller in this use case) Consignee party (In UBL: DeliveryCustomerParty) (Same legal entity as the Buyer in this use case).
Pre conditions	Advanced Despatch Advice is sent from Consignor to Consignee. Receipt Advice is sent from Consignee to Consignor.
Post conditions	Receipt advice is received by the sender of the goods.
Assumptions	The Consignor and Consignee has agreed to use the Receipt Advice to confirm that the goods/service has been received or rejected. Earlier a Receipt Advice may have been exchanged to confirm the reception of the Advanced Despatch Advice. A new Advanced Despatch Advice, starting a new process, must be issued when the goods/service is sent the next time.
The flow	The Advanced Despatch Advice is received by the Consignee. A Receipt Advice may be sent by the Consignee to confirm/reject the Advanced Despatch Advice. The goods/service is rejected due to late arrival. A Receipt Advice is created and sent by the Consignee party. The Consignor party receives the Receipt advice message. The Consignor party plan for a new delivery of the goods/service. A new Advanced Despatch Advice followed by Receipt Advice must be issued. The Consignee will wait for a the goods/service to arrive.
Result	The Receipt advice message helped the Consignee party to inform the supplier that the goods/service arrived too late and could not be received. The Receipt advice message helped the Consignor party know that they need to plan for a new time to deliver the goods/service.
XML example file	See Examples files Appendix A for a sample file illustrating Use Case 5.

Use Case number

Use Case Name

Goods/service has arrived outside requested time-window and is rejected.

Use Case Description

This is the confirmation that the goods/service has been rejected because it arrived outside time window.

The Receipt Advice enables the goods receiver to inform the supplier that the goods/service was rejected. This enables the Supplier to start the process of shipping the goods/service again at a new time slot.

Parties involved

Buyer (In UBL: BuyerCustomerParty)

Seller (In UBL: SellerSupplierParty)

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

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

Pre conditions

Advanced Despatch Advice is sent from Consignor to Consignee. Receipt Advice is sent from Consignee to Consignor.

Post conditions

Receipt advice is received by the sender of the goods.

Assumptions

The Consignor and Consignee has agreed to use the Receipt Advice to confirm that the goods/service has been received or rejected.
Earlier a Receipt Advice may have been exchanged to confirm the reception of the Advanced Despatch Advice.
A new Advanced Despatch Advice, starting a new process, must be issued when the goods/service is sent the next time.

The flow

The Advanced Despatch Advice is received by the Consignee.
A Receipt Advice may be sent by the Consignee to confirm/reject the Advanced Despatch Advice.
The goods/service is rejected due to late arrival.
A Receipt Advice is created and sent by the Consignee party.
The Consignor party receives the Receipt advice message.
The Consignor party plan for a new delivery of the goods/service. A new Advanced Despatch Advice followed by Receipt Advice must be issued.
The Consignee will wait for a the goods/service to arrive.

Result

The Receipt advice message helped the Consignee party to inform the supplier that the goods/service arrived too late and could not be received.
The Receipt advice message helped the Consignor party know that they need to plan for a new time to deliver the goods/service.

XML example file

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

Use case 6 – Goods/service has arrived too late, but been received.

This use case is based on the recommendation that a receipt of goods or service should be confirmed by a Receipt Advice.

Use Case number	6
Use Case Name	Goods/service has been received too late.
Use Case Description	This is the confirmation that the goods/service has arrived too late, but been received at a higher cost for the Consignee. The Receipt Advice enables the goods receiver to inform the supplier that the goods/service arrived late, but was received by the Consignee anyway by asking personel to work overtime, creating a higher cost for the Consignee. A claim process for this will be started. (At a later stage, when the Transport Handling Units are opened and the content is checked, an updated Receipt Advice may be sent.) This enables the Supplier to issue the corresponding invoice and be ready for the claim process to start.
Parties involved	Buyer (In UBL: BuyerCustomerParty) Seller (In UBL: SellerSupplierParty) Despatch party (In UBL: DespatchSupplierParty) (Same legal entity as the Seller in this use case) Consignee party (In UBL: DeliveryCustomerParty) (Same legal entity as the Buyer in this use case).
Pre conditions	Advanced Despatch Advice is sent from Consignor to Consignee. Receipt Advice is sent from Consignee to Consignor.
Post conditions	Receipt advice is received by the sender of the goods.
Assumptions	The Consignor and Consignee has agreed to use the Receipt Advice to confirm that the goods/service has been received. Earlier a Receipt Advice may have been exchanged to confirm the reception of the Advanced Despatch Advice. Later new Receipt Advices can be exchanged if shortages or other problems are found at a later stage.
The flow	The Advanced Despatch Advice is received by the Consignee. A Receipt Advice may be sent by the Consignee to confirm/reject the Advanced Despatch Advice. The goods/service is received. A Receipt Advice is created and sent by the Consignee party. The Consignor party receives the Receipt advice message. The Consignor party uses the content in the Advanced Despatch Advice and Receipt Advice messages to start the invoicing process. The Consignor party will also be ready for the start of the claim process. The Consignee will wait for a the invoice to arrive and besides that also start the claim process.
Result	The Receipt advice message helped the Consignee party to inform the supplier that the goods/service was received late at a higher cost and that there will be a claim process for that. The Receipt advice message helped the Consignor party know when to start the invoicing process, and to expect a claim from the Consignee party.
XML example file	See Examples files Appendix A for a sample file illustrating Use Case 6.

Use Case number

Use Case Name

Goods/service has been received too late.

Use Case Description

This is the confirmation that the goods/service has arrived too late, but been received at a higher cost for the Consignee.

The Receipt Advice enables the goods receiver to inform the supplier that the goods/service arrived late, but was received by the Consignee anyway by asking personel to work overtime, creating a higher cost for the Consignee. A claim process for this will be started. (At a later stage, when the Transport Handling Units are opened and the content is checked, an updated Receipt Advice may be sent.) This enables the Supplier to issue the corresponding invoice and be ready for the claim process to start.

Parties involved

Buyer (In UBL: BuyerCustomerParty)

Seller (In UBL: SellerSupplierParty)

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

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

Pre conditions

Advanced Despatch Advice is sent from Consignor to Consignee. Receipt Advice is sent from Consignee to Consignor.

Post conditions

Receipt advice is received by the sender of the goods.

Assumptions

The Consignor and Consignee has agreed to use the Receipt Advice to confirm that the goods/service has been received.
Earlier a Receipt Advice may have been exchanged to confirm the reception of the Advanced Despatch Advice.
Later new Receipt Advices can be exchanged if shortages or other problems are found at a later stage.

The flow

The Advanced Despatch Advice is received by the Consignee.
A Receipt Advice may be sent by the Consignee to confirm/reject the Advanced Despatch Advice.
The goods/service is received.
A Receipt Advice is created and sent by the Consignee party.
The Consignor party receives the Receipt advice message.
The Consignor party uses the content in the Advanced Despatch Advice and Receipt Advice messages to start the invoicing process.
The Consignor party will also be ready for the start of the claim process.
The Consignee will wait for a the invoice to arrive and besides that also start the claim process.

Result

The Receipt advice message helped the Consignee party to inform the supplier that the goods/service was received late at a higher cost and that there will be a claim process for that.
The Receipt advice message helped the Consignor party know when to start the invoicing process, and to expect a claim from the Consignee party.

XML example file

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

Use case 7 – Goods has been received with damages on Transport Handling Unit.

This use case is based on the recommendation that a receipt of goods or service should be confirmed by a Receipt Advice.

Use Case number	7
Use Case Name	Goods has been received with damages on a Transport Handling Unit.
Use Case Description	This is the confirmation that the goods has arrived with a damage on a Transport Handling Unit, but received anyway. The Receipt Advice enables the goods receiver to inform the supplier that the goods/service arrived with damages on a Transport Handling Unit. A claim process for this will be started with the Supplier or Carrier depending on who is responsible for transportation. (At a later stage, when the Transport Handling Units are opened and the content is checked, an updated Receipt Advice may be sent.) This enables the Supplier to issue the corresponding invoice and be ready for the claim process to start.
Parties involved	Buyer (In UBL: BuyerCustomerParty) Seller (In UBL: SellerSupplierParty) Despatch party (In UBL: DespatchSupplierParty) (Same legal entity as the Seller in this use case) Consignee party (In UBL: DeliveryCustomerParty) (Same legal entity as the Buyer in this use case).
Pre conditions	Advanced Despatch Advice is sent from Consignor to Consignee. Receipt Advice is sent from Consignee to Consignor.
Post conditions	Receipt advice is received by the sender of the goods.
Assumptions	The Consignor and Consignee has agreed to use the Receipt Advice to confirm that the goods/service has been received. Earlier a Receipt Advice may have been exchanged to confirm the reception of the Advanced Despatch Advice. Later new Receipt Advices can be exchanged if shortages or other problems are found at a later stage.
The flow	The Advanced Despatch Advice is received by the Consignee. A Receipt Advice may be sent by the Consignee to confirm/reject the Advanced Despatch Advice. The goods/service is received and a damage found. A Receipt Advice is created and sent by the Consignee party. The Consignor party receives the Receipt advice message. The Consignor party uses the content in the Advanced Despatch Advice and Receipt Advice messages to start the invoicing process. The Consignor party will also be ready for the start of the claim process if the Supplier is responsible. The Consignee will wait for a the invoice to arrive and besides that also start the claim process with the Supplier or the Carrier.
Result	The Receipt advice message helped the Consignee party to inform the supplier that the goods/service was received with damages and that there will be a claim process for that if the supplier is responsible for transportation. The Receipt advice message helped the Consignor party know when to start the invoicing process, and to expect a claim from the Consignee party.
XML example file	See Examples files Appendix A for a sample file illustrating Use Case 7.

Use Case number

Use Case Name

Goods has been received with damages on a Transport Handling Unit.

Use Case Description

This is the confirmation that the goods has arrived with a damage on a Transport Handling Unit, but received anyway.

The Receipt Advice enables the goods receiver to inform the supplier that the goods/service arrived with damages on a Transport Handling Unit. A claim process for this will be started with the Supplier or Carrier depending on who is responsible for transportation. (At a later stage, when the Transport Handling Units are opened and the content is checked, an updated Receipt Advice may be sent.) This enables the Supplier to issue the corresponding invoice and be ready for the claim process to start.

Parties involved

Buyer (In UBL: BuyerCustomerParty)

Seller (In UBL: SellerSupplierParty)

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

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

Pre conditions

Advanced Despatch Advice is sent from Consignor to Consignee. Receipt Advice is sent from Consignee to Consignor.

Post conditions

Receipt advice is received by the sender of the goods.

Assumptions

The Consignor and Consignee has agreed to use the Receipt Advice to confirm that the goods/service has been received.
Earlier a Receipt Advice may have been exchanged to confirm the reception of the Advanced Despatch Advice.
Later new Receipt Advices can be exchanged if shortages or other problems are found at a later stage.

The flow

The Advanced Despatch Advice is received by the Consignee.
A Receipt Advice may be sent by the Consignee to confirm/reject the Advanced Despatch Advice.
The goods/service is received and a damage found.
A Receipt Advice is created and sent by the Consignee party.
The Consignor party receives the Receipt advice message.
The Consignor party uses the content in the Advanced Despatch Advice and Receipt Advice messages to start the invoicing process.
The Consignor party will also be ready for the start of the claim process if the Supplier is responsible.
The Consignee will wait for a the invoice to arrive and besides that also start the claim process with the Supplier or the Carrier.

Result

The Receipt advice message helped the Consignee party to inform the supplier that the goods/service was received with damages and that there will be a claim process for that if the supplier is responsible for transportation.
The Receipt advice message helped the Consignor party know when to start the invoicing process, and to expect a claim from the Consignee party.

XML example file

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

Use case 8 – Goods has been received with a missing Transport Handling Unit.

This use case is based on the recommendation that a receipt of goods or service should be confirmed by a Receipt Advice.

Use Case number	8
Use Case Name	Goods has been received with a missing Transport Handling Unit.
Use Case Description	This is the confirmation that the goods has arrived with a Transport Handling Unit missing. The Receipt Advice enables the goods receiver to inform the supplier that the goods/service arrived with a Transport Handling Unit missing. A claim process for this will be started with the Supplier or Carrier depending on who is responsible for transportation. (At a later stage, when the Transport Handling Units are opened and the content is checked, an updated Receipt Advice may be sent.) This enables the Supplier to issue the corresponding invoice and be ready for the claim process to start.
Parties involved	Buyer (In UBL: BuyerCustomerParty) Seller (In UBL: SellerSupplierParty) Despatch party (In UBL: DespatchSupplierParty) (Same legal entity as the Seller in this use case) Consignee party (In UBL: DeliveryCustomerParty) (Same legal entity as the Buyer in this use case).
Pre conditions	Advanced Despatch Advice is sent from Consignor to Consignee. Receipt Advice is sent from Consignee to Consignor.
Post conditions	Receipt advice is received by the sender of the goods.
Assumptions	The Consignor and Consignee has agreed to use the Receipt Advice to confirm that the goods/service has been received. Earlier a Receipt Advice may have been exchanged to confirm the reception of the Advanced Despatch Advice. Later new Receipt Advices can be exchanged if shortages or other problems are found at a later stage.
The flow	The Advanced Despatch Advice is received by the Consignee. A Receipt Advice may be sent by the Consignee to confirm/reject the Advanced Despatch Advice. The goods/service is received and a damage found. A Receipt Advice is created and sent by the Consignee party. The Consignor party receives the Receipt advice message. The Consignor party uses the content in the Advanced Despatch Advice and Receipt Advice messages to start the invoicing process. The Consignor party will also be ready for the start of the claim process if the Supplier is responsible. The Consignee will wait for a the invoice to arrive and besides that also start the claim process with the Supplier or the Carrier.
Result	The Receipt advice message helped the Consignee party to inform the supplier that the goods/service was received with a missing Transport Handling Unit and that there will be a claim process for that if the supplier is responsible for transportation. The Receipt advice message helped the Consignor party know when to start the invoicing process, and to expect a claim from the Consignee party.
XML example file	See Examples files Appendix A for a sample file illustrating Use Case 8.

Use Case number

Use Case Name

Goods has been received with a missing Transport Handling Unit.

Use Case Description

This is the confirmation that the goods has arrived with a Transport Handling Unit missing.

The Receipt Advice enables the goods receiver to inform the supplier that the goods/service arrived with a Transport Handling Unit missing. A claim process for this will be started with the Supplier or Carrier depending on who is responsible for transportation. (At a later stage, when the Transport Handling Units are opened and the content is checked, an updated Receipt Advice may be sent.) This enables the Supplier to issue the corresponding invoice and be ready for the claim process to start.

Parties involved

Buyer (In UBL: BuyerCustomerParty)

Seller (In UBL: SellerSupplierParty)

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

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

Pre conditions

Advanced Despatch Advice is sent from Consignor to Consignee. Receipt Advice is sent from Consignee to Consignor.

Post conditions

Receipt advice is received by the sender of the goods.

Assumptions

The Consignor and Consignee has agreed to use the Receipt Advice to confirm that the goods/service has been received.
Earlier a Receipt Advice may have been exchanged to confirm the reception of the Advanced Despatch Advice.
Later new Receipt Advices can be exchanged if shortages or other problems are found at a later stage.

The flow

The Advanced Despatch Advice is received by the Consignee.
A Receipt Advice may be sent by the Consignee to confirm/reject the Advanced Despatch Advice.
The goods/service is received and a damage found.
A Receipt Advice is created and sent by the Consignee party.
The Consignor party receives the Receipt advice message.
The Consignor party uses the content in the Advanced Despatch Advice and Receipt Advice messages to start the invoicing process.
The Consignor party will also be ready for the start of the claim process if the Supplier is responsible.
The Consignee will wait for a the invoice to arrive and besides that also start the claim process with the Supplier or the Carrier.

Result

The Receipt advice message helped the Consignee party to inform the supplier that the goods/service was received with a missing Transport Handling Unit and that there will be a claim process for that if the supplier is responsible for transportation.
The Receipt advice message helped the Consignor party know when to start the invoicing process, and to expect a claim from the Consignee party.

XML example file

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

Use case 9 – Goods has been received ok but when opening the Transport Handling Unit there is a shortage found.

This use case is based on the recommendation that a receipt of goods or service should be confirmed by a Receipt Advice.

Use Case number	9
Use Case Name	Goods has been received ok but when opening the Transport Handling Unit there is a shortage found.
Use Case Description	This Receipt Advice is sent as an update at a later stage when the Transport Handling Units are opened and the content checked and a shortage found. The Receipt Advice enables the goods receiver to inform the supplier that the consignment had a shortage. A claim process for this will be started. The supplier is requested to replace the missing parts or to create a credit note.
Parties involved	Buyer (In UBL: BuyerCustomerParty) Seller (In UBL: SellerSupplierParty) Despatch party (In UBL: DespatchSupplierParty) (Same legal entity as the Seller in this use case) Consignee party (In UBL: DeliveryCustomerParty) (Same legal entity as the Buyer in this use case).
Pre conditions	Advanced Despatch Advice is sent from Consignor to Consignee. Receipt Advice is sent from Consignee to Consignor.
Post conditions	Receipt advice is received by the sender of the goods.
Assumptions	The Consignor and Consignee has agreed to use the Receipt Advice to confirm that the goods/service has been received. Earlier a Receipt Advice may have been exchanged to confirm the reception of the Advanced Despatch Advice. Earlier, at arrival of the goods, a Receipt Advice was sent to inform the Consignor about that. This new Receipt Advice is sent only if shortages or other problems are found at a later stage.
The flow	The Advanced Despatch Advice is received by the Consignee. A Receipt Advice may be sent by the Consignee to confirm/reject the Advanced Despatch Advice. The goods/service is received and confirmed. A Receipt Advice is created and sent by the Consignee party. The Consignor party receives the Receipt advice message. The Consignee later opens the Transport Handling Units and finds a shortage. A new Receipt Advice is sent by the Consignee to the Consignor informing abot the shortage. The Consignor party uses the content in the Receipt Advice to compensate the Consignee for the missing parts. The Consignee will wait for the compensation for the shortage.
Result	The Receipt advice message helped the Consignee to report about the shortage and to receive a compensation from the Consignor. The Receipt advice message helped the Consignor compensate for the missing parts.
XML example file	See Examples files Appendix A for a sample file illustrating Use Case 9.

Use Case number

Use Case Name

Goods has been received ok but when opening the Transport Handling Unit there is a shortage found.

Use Case Description

This Receipt Advice is sent as an update at a later stage when the Transport Handling Units are opened and the content checked and a shortage found.

The Receipt Advice enables the goods receiver to inform the supplier that the consignment had a shortage. A claim process for this will be started. The supplier is requested to replace the missing parts or to create a credit note.

Parties involved

Buyer (In UBL: BuyerCustomerParty)

Seller (In UBL: SellerSupplierParty)

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

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

Pre conditions

Advanced Despatch Advice is sent from Consignor to Consignee. Receipt Advice is sent from Consignee to Consignor.

Post conditions

Receipt advice is received by the sender of the goods.

Assumptions

The Consignor and Consignee has agreed to use the Receipt Advice to confirm that the goods/service has been received.
Earlier a Receipt Advice may have been exchanged to confirm the reception of the Advanced Despatch Advice.
Earlier, at arrival of the goods, a Receipt Advice was sent to inform the Consignor about that.
This new Receipt Advice is sent only if shortages or other problems are found at a later stage.

The flow

The Advanced Despatch Advice is received by the Consignee.
A Receipt Advice may be sent by the Consignee to confirm/reject the Advanced Despatch Advice.
The goods/service is received and confirmed.
A Receipt Advice is created and sent by the Consignee party.
The Consignor party receives the Receipt advice message.
The Consignee later opens the Transport Handling Units and finds a shortage.
A new Receipt Advice is sent by the Consignee to the Consignor informing abot the shortage.
The Consignor party uses the content in the Receipt Advice to compensate the Consignee for the missing parts.
The Consignee will wait for the compensation for the shortage.

Result

The Receipt advice message helped the Consignee to report about the shortage and to receive a compensation from the Consignor.
The Receipt advice message helped the Consignor compensate for the missing parts.

XML example file

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

4. Semantic datatypes

Semantic data types are used to bridge the gap between the semantic concepts expressed by the information elements and the technical implementation. The semantic data types define the allowed value domain for the content, and any additional information components (attributes) needed in order to ensure its precise interpretation.

4.1. Primitive types

Semantic data type content may be of the following primitive types. These primitive types were taken from ISO 15000-5:2014, Appendix A.

Primitive type	Definition
Binary	A set of finite-length sequences of binary digits.
Date	Time point representing a calendar day on a time scale consisting of an origin and a succession of calendar ISO 8601:2004.
Decimal	A subset of the real numbers, which can be represented by decimal numerals.
String	A finite sequence of characters.

Primitive type

Definition

Binary

A set of finite-length sequences of binary digits.

Date

Time point representing a calendar day on a time scale consisting of an origin and a succession of calendar ISO 8601:2004.

Decimal

A subset of the real numbers, which can be represented by decimal numerals.

String

A finite sequence of characters.

4.2. Semantic data types

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

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

4.2.1. Amount

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

Amount is floating up to two fraction digits.

Component	Use	Primitive Type	Example
Content	Mandatory	Decimal	10000.25

Component

Use

Primitive Type

Example

Content

Mandatory

Decimal

10000.25

4.2.2. Price Amount

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

Unit price amount does not set restrictions on number of decimals, as contrast to the Amount type

Component	Use	Primitive Type	Example
Content	Mandatory	Decimal	10000.1234

Component

Use

Primitive Type

Example

Content

Mandatory

Decimal

10000.1234

4.2.3. Percentage

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

No restriction on number of decimals for percentages.

Component	Use	Primitive Type	Example
Content	Mandatory	Decimal	34.7812

Component

Use

Primitive Type

Example

Content

Mandatory

Decimal

34.7812

4.2.4. Quantity

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

No restriction on number of decimals for quantities.

Component	Use	Primitive Type	Example
Content	Mandatory	Decimal	10000.1234

Component

Use

Primitive Type

Example

Content

Mandatory

Decimal

10000.1234

4.2.5. Code

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

Codes shall be entered exactly as shown in the selected code list

Component	Use	Primitive Type	Example
Content	Mandatory	String	Abc123

Component

Use

Primitive Type

Example

Content

Mandatory

String

Abc123

4.2.6. Identifier

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

The use of the attributes is specified for each information element.

Component

Use

Primitive Type

Example

Content

Mandatory

String

abc:123-DEF

Scheme identifier

Conditional

String

0088

Scheme version identifier

Conditional

String

1.0

4.2.7. Date

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

Dates shall not include timezone information.

Table 1. EN 16931_ Date. Type
Component	Use	Primitive Type	Example
Content	Mandatory	Date	2017-12-01

4.2.8. Time

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

Time shall not include timezone information. Decimal fraction on seconds SHALL not be used.

Table 2. EN 16931_ Date. Type
Component	Use	Primitive Type	Example
Content	Mandatory	Date	09:30:12

4.2.9. Document Reference

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

Table 3. Document Reference. Type
Component	Use	Primitive Type	Example
Content	Mandatory	String	abc:123-DEF

4.2.10. Text

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

Component	Use	Primitive Type	Example
Content	Mandatory	String	5% allowance when paid within 30 days

Component

Use

Primitive Type

Example

Content

Mandatory

String

5% allowance when paid within 30 days

4.2.11. Binary objects

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

Component	Use	Primitive Type	Example
Content	Mandatory	Binary	QmFzZTY0IGNvbnRlbnQgZXhhbXBsZQ==
Mime Code	Mandatory	String	image/jpeg
Filename	Mandatory	String	drawing5.jpg

Component

Use

Primitive Type

Example

Content

Mandatory

Binary

QmFzZTY0IGNvbnRlbnQgZXhhbXBsZQ==

Mime Code

Mandatory

String

image/jpeg

Filename

Mandatory

String

drawing5.jpg

4.2.12. Boolean

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

Component	Use	Primitive Type	Example
Content	Mandatory	String	true

Component

Use

Primitive Type

Example

Content

Mandatory

String

true

5. Code lists

5.1. Code lists for coded elements

Any element with the semantic data type = code, can mandate the use of a specific code list (or a fixed value). The applicable code lists can be found under Code lists in the top-menu bar. There you can find the valid codes, their names and description, and also links to where the same code list is used elsewhere in the transaction, or in other Logistics documents. Below are examples on usage of code lists for identifiers being used in all formats.

5.2. Code list for identifiers - Examples of usage

5.2.1. Party identifiers and party legal registration identifier scheme

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

Examples of usage in cac:PartyIdentification

<cac:PartyIdentification>
        <cbc:ID schemeID="0088">5790000435968</cbc:ID> (1)
</cac:PartyIdentification>

1	schemeID attribute is optional, but when used, the codes must be from the ICD code list.

5.2.2. Electronic address identifier scheme identifier

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

Valid values are found in the EAS code list.

Examples of usage in cbc:EndpointID

<cbc:EndpointID schemeID="0184">DK87654321</cbc:EndpointID> (1)

1	schemeID attribute is mandatory

6. Description of selected parts of the Receipt Advice

Description of selected parts of Advanced Despatch Advice can be found in the BIS for Advanced Despatch Advice Only.

6.1. Parties

The following parties/roles are mandatory in the message.

6.1.1. Delivery Customer Party (DeliveryCustomerParty)

The party that received the Advanced Despatch Advice, receied or will receive the goods/service, and now creates/sends the Receipt Advice.

Example:

<cac:DeliveryCustomerParty>
   <cac:Party>
      <cbc:EndpointID schemeID="0088">5798000000124</cbc:EndpointID>
      <cac:PartyIdentification>
         <cbc:ID schemeID="0088"> 5790000435951</cbc:ID>
      </cac:PartyIdentification>
      <cac:PartyName>
         <cbc:Name> Sender inc. </cbc:Name>
      </cac:PartyName>
      <cac:PostalAddress>
         <cbc:StreetName>Avon Way</cbc:StreetName>
         <cbc:AdditionalStreetName>Big projects</cbc:AdditionalStreetName>
         <cbc:CityName>Bridgtown</cbc:CityName>
         <cbc:PostalZone>ZZ99 1ZZ</cbc:PostalZone>
         <cbc:CountrySubentity>Avon</cbc:CountrySubentity>
         <cac:AddressLine>
            <cbc:Line>3rd Floor, Room 5</cbc:Line>
         </cac:AddressLine>
         <cac:Country>
            <cbc:IdentificationCode>GB</cbc:IdentificationCode>
         </cac:Country>
      </cac:PostalAddress>
      <cac:PartyTaxScheme>
         <cbc:CompanyID> GB523859989 </cbc:CompanyID>
         <cac:TaxScheme>
            <cbc:ID> VAT </cbc:ID>
         </cac:TaxScheme>
      </cac:PartyTaxScheme>
      <cac:PartyLegalEntity>
         <cbc:RegistrationName> Sender inc.</cbc:RegistrationName>
         <cbc:CompanyID schemeID="0089"> GB523859989</cbc:CompanyID>
         <cac:RegistrationAddress>
            <cbc:CityName> Bridgtown </cbc:CityName>
            <cac:Country>
               <cbc:IdentificationCode> UK</cbc:IdentificationCode>
            </cac:Country>
         </cac:RegistrationAddress>
      </cac:PartyLegalEntity>
 <cac:Contact>
  <cbc:Name>Mr Fred Churchill</cbc:Name>
  <cbc:Telephone>0127 2653214</cbc:Telephone>
  <cbc:ElectronicMail>fred@iytcorporation.gov.uk</cbc:ElectronicMail>
 </cac:Contact>
   </cac:Party>
</cac:DeliveryCustomerParty>

6.1.2. Despatch Supplier Party (DespatchSupplierParty)

The party that sent the Advanced Despatch Advice, delivered the goods or service, and will receive the Receipt Advice.

Example:

<cac:DespatchSupplierParty>
   <cac:Party>
      <cbc:EndpointID schemeID="0088"> 7300010000001</cbc:EndpointID>
      <cac:PartyIdentification>
         <cbc:ID schemeID="0088"> 7300010000001</cbc:ID>
      </cac:PartyIdentification>
      <cac:PartyName>
         <cbc:Name> Sender inc. </cbc:Name>
      </cac:PartyName>
      <cac:PostalAddress>
         <cbc:StreetName>Busy Street</cbc:StreetName>
         <cbc:AdditionalStreetName>way 1</cbc:AdditionalStreetName>
         <cbc:CityName>Farthing</cbc:CityName>
         <cbc:PostalZone>AA99 1BB</cbc:PostalZone>
         <cbc:CountrySubentity>Heremouthshire</cbc:CountrySubentity>
         <cac:AddressLine>
            <cbc:Line>The Roundabout</cbc:Line>
         </cac:AddressLine>
         <cac:Country>
            <cbc:IdentificationCode>GB</cbc:IdentificationCode>
         </cac:Country>
      </cac:PostalAddress>
      <cac:PartyTaxScheme>
         <cbc:CompanyID> GB325456788</cbc:CompanyID>
         <cac:TaxScheme>
            <cbc:ID> VAT </cbc:ID>
         </cac:TaxScheme>
      </cac:PartyTaxScheme>
      <cac:PartyLegalEntity>
         <cbc:RegistrationName> Consortial</cbc:RegistrationName>
         <cbc:CompanyID schemeID="0089"> SC234567 </cbc:CompanyID>
         <cac:RegistrationAddress>
            <cbc:CityName> Farthing </cbc:CityName>
            <cac:Country>
               <cbc:IdentificationCode> UK </cbc:IdentificationCode>
            </cac:Country>
         </cac:RegistrationAddress>
      </cac:PartyLegalEntity>
      <cac:Contact>
         <cbc:Name> Mrs Bouquet</cbc:Name>
         <cbc:Telephone> 0158 1233714 </cbc:Telephone>
         <cbc:ElectronicMail> bouquet@fpconsortial.co.uk </cbc:ElectronicMail>
      </cac:Contact>
   </cac:Party>
</cac:DespatchSupplierParty>

6.2. Despatch Document Reference

This is the reference to the received Advanced Despatch Advice, and here the status of it can be reported. The reference must always be provided, but the Status must only be included when the Receipt Advice is used as a response to the Advanced Despatch Advice. When used as a response to a received shipment, this Status must be omitted. With the Status code the sender reports the status for when the Advanced Despatch Advice was received and processed. Following values can be used:

AB = Received, not yet validated. This status confirms that the Advanced Despatch Advice has been received ok, but the content is not yet validated.
AP = Accepted after validation. With this code the receiver confirms that the Advanced Despatch Advice contains valid information.
RE = Rejected after validation. With this code the receiver informs the supplier that there are formal errors in the Advanced Despatch Advice that need to be corrected and a new Advanced Despatch Advice sent.

At line level there is also a reference to the Despatch Advice Line number.

Example:

<cac:DespatchDocumentReference>
     <cbc:ID>565899</cbc:ID>
     <cbc:IssueDate>2021-09-10</cbc:IssueDate>
     <cbc:IssueTime>12:00:00+01:00</cbc:IssueTime>
     <cbc:DocumentStatusCode>RE</cbc:DocumentStatusCode>
     <cbc:DocumentDescription>Incorrect Identity of the buyer.</cbc:DocumentDescription>
  </cac:DespatchDocumentReference>

6.3. Additional Document Reference

Here any document that is relevant for the Receipt Advice can be referred to, included or linked to. Typically photos to document damages on received Transport Handling Units can be attached.

Example:

<cac:AdditionalDocumentReference>
   <cbc:ID> 7648779</cbc:ID>
   <cbc:DocumentType> DamageReportPhoto </cbc:DocumentType>
   <cac:Attachment>
      <cbc:EmbeddedDocumentBinaryObject mimeCode="application/pdf" filename="Damage-Report-01.pdf">
        aHR0cHM6Ly90ZXN0LXZlZmEuZGlmaS5uby9wZXBwb2xiaXMvcG9hY2MvYmlsbGluZy8zLjAvYmlzLw== </cbc:EmbeddedDocumentBinaryObject>
      <cac:ExternalReference>
         <cbc:URI> www.beast.se </cbc:URI>
      </cac:ExternalReference>
   </cac:Attachment>
</cac:AdditionalDocumentReference>

6.4. Consignment

The Consignment describes how and when the goods/service has been delivered. The Reciver can accept or reject everything in the Consignment with a Condition code, a Reason Code and a text describing why it is rejected when rejected. Valid Condition codes are:

AP = Accepted, no problems found.
CA = Accepted with claims. Description of found issues are provided.
RE = Rejected, the whole Consignment was rejected and the goods/service not received.

Example:

<cac:Consignment>
   <cbc:ID> NA</cbc:ID>
   <cac:Status>
      <cbc:ConditionCode>CA</cbc:ConditionCode>
      <cbc:StatusReasonCode>4</cbc:StatusReasonCode>
      <cbc:StatusReason>Delivery outside requested time window.</cbc:StatusReason>
   </cac:Status>
   <cac:CarrierParty>
      <cac:PartyIdentification>
         <cbc:ID schemeID="0088"> 5790000435951</cbc:ID>
      </cac:PartyIdentification>
      <cac:PartyName>
         <cbc:Name>Name</cbc:Name>
      </cac:PartyName>
      <cac:Person>
         <cac:IdentityDocumentReference>
            <cbc:ID>45642323</cbc:ID>
            <cbc:DocumentType>DriverLicence</cbc:DocumentType>
         </cac:IdentityDocumentReference>
      </cac:Person>
   </cac:CarrierParty>
</cac:Consignment>

6.5. Delivery

The actual delivery time is showed here, together with the Terms of Delivery.

Example:

<cac:Delivery>
   <cbc:ActualDeliveryDate>2021-09-27</cbc:ActualDeliveryDate>
   <cbc:ActualDeliveryTime>16:00:00+01:00</cbc:ActualDeliveryTime>
   <cac:DeliveryTerms>
      <cbc:ID> EXW </cbc:ID>
      <cbc:SpecialTerms> EQN-06</cbc:SpecialTerms>
      <cac:DeliveryLocation>
         <cbc:ID> Kalmar </cbc:ID>
      </cac:DeliveryLocation>
   </cac:DeliveryTerms>
</cac:Delivery>

6.6. Transport Handling Unit

A list of Transport Handling Units can be provided in the Receipt Advice. If one is included, all must be. It is not allowed to show only some of the Transport Handling Units.

If any damage is found on the Transport Handling Unit at arrival, it can be reported here. If a photo (or other document) is required for documentation, they can be sent at header level in AdditionalDocumentReference.

The Condition code describes if the Transport Handling Unit was ok or not. A text can also be provided in the Damage Remark.

Example:

   <cac:TransportHandlingUnit>
      <cbc:ID>11111222222222</cbc:ID>
      <cbc:TransportHandlingUnitTypeCode> AG </cbc:TransportHandlingUnitTypeCode>
      <cac:Status>
         <cbc:ConditionCode>CA</cbc:ConditionCode>
<cbc:StatusReasonCode>4</cbc:StatusReasonCode>
<cbc:StatusReason>Pallet cover broken, see attached photo.</cbc:StatusReason>
      </cac:Status>
   </cac:TransportHandlingUnit>

6.7. Receipt Line

Since the ReceiptLine is mandatory in UBL, we need to always include lines in the Receipt Advice. To avoid misunderstandings, all lines in the Advanced Despatch Advice must be included in the Receipt Advice, not only the ones with a problem. Each line contains several element and some of them are described here:

6.7.1. Received Quantity (ReceivedQuantity)

This quantity is the whole received quantity, including also what has been rejected.

6.7.2. Shortage Quantity (ShortQuantity)

Here is reported what is missing - how much less quantity that was received than ordered.

6.7.3. Rejected Quantity (RejectedQuantity)

This quantity is a part of the Received Quantity, but for some reason it can not be used/accepted.

6.7.4. Oversupply Quantity (OversupplyQuantity)

The Oversupply Quantity is a part of the Received Quantity. If a higher quantity is received than ordered, it is reported here.

6.7.5. Action Code (ActionCode)

For Shortage and Rejected Quantities there is an Action Code to inform how the customer wants the supplier to compensate.

6.7.6. Reason Code (ReasonCode)

For Rejected Quantities there is a Reason Code and a textual equivalent to inform about the reason of the rejection.

Example:

<cac:ReceiptLine>
   <cbc:ID>1</cbc:ID>
   <cbc:Note>SAMPLE</cbc:Note>
   <cbc:ReceivedQuantity unitCode="KGM">90</cbc:ReceivedQuantity>
   <cbc:ShortQuantity unitCode="KGM">10</cbc:ShortQuantity>
   <cbc:ShortageActionCode>1</cbc:ShortageActionCode>
   <cbc:RejectedQuantity unitCode="KGM">1</cbc:RejectedQuantity>
   <cbc:RejectReasonCode>3</cbc:RejectReasonCode>
   <cbc:RejectReason>Wrong item delivered.</cbc:RejectReason>
   <cbc:RejectActionCode>2</cbc:RejectActionCode>
   <cbc:OversupplyQuantity unitCode="KGM">5</cbc:OversupplyQuantity>

6.7.7. Order line reference

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

Example line level

<cac:OrderLineReference>
   <cbc:LineID>1</cbc:LineID>
   <cbc:SalesOrderLineID>10</cbc:SalesOrderLineID>
   <cac:OrderReference>
      <cbc:ID>AEG012345</cbc:ID>
      <cbc:SalesOrderID>5678985 </cbc:SalesOrderID>
   </cac:OrderReference>
</cac:OrderLineReference>

Example header level

<cac:OrderReference>
   <cbc:ID>AEG0123456</cbc:ID>
</cac:OrderReference>

6.7.8. Item

This part provides the Name and Identity of the Item that is received in this line.

Example:

<cac:Item>
   <cbc:Name>Beeswax</cbc:Name>
   <cac:BuyersItemIdentification>
      <cbc:ID>6578489</cbc:ID>
   </cac:BuyersItemIdentification>
   <cac:SellersItemIdentification>
      <cbc:ID>17589683</cbc:ID>
   </cac:SellersItemIdentification>
   <cac:ManufacturersItemIdentification>
      <cbc:ID> 17589683</cbc:ID>
   </cac:ManufacturersItemIdentification>
   <cac:StandardItemIdentification>
      <cbc:ID schemeID="0160"> 1234567891234</cbc:ID>
      <cbc:ExtendedID>22114455</cbc:ExtendedID>
   </cac:StandardItemIdentification>
</cac:Item>

7. Peppol Identifiers

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

7.1. Profiles and messages

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

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

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

7.2. Customization and Profile identifiers

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

Type Element cbc:CustomizationID Element cbc:ProfileID

Type	Element `cbc:CustomizationID`	Element `cbc:ProfileID`
Advanced Despatch Advice (Trdm120)	urn:fdc:peppol.eu:logistics:trns:advanced_despatch_advice:1	urn:fdc:peppol.eu:logistics:bis:despatch_advice_w_receipt_advice:1
Receipt Advice (Trdm128)	urn:fdc:peppol.eu:logistics:trns:receipt_advice:1

Advanced Despatch Advice (Trdm120)

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

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

Receipt Advice (Trdm128)

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

7.3. Namespaces

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

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

The receipt advice data model is bound to UBL 2.3 of the document type {ubl-receipt-advice}. The target namespace for the UBL 2.3 Receipt Advice is:

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