BIS Order Agreement 3.0.0.9
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.
1. Introduction to openPeppol and BIS
This BIS is a result of work within OpenPeppol and is published as part of the 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/BII Profile “BII Profile 42 Order Agreement CWA 17029-124” CEN WS/BII 3.
In this document, italian usage rules and paragraphs deriving from the italian e-procurement model are highlighted in yellow.
The purpose of this document is to describe a common format for the order agreement in the European market, and to facilitate an efficient implementation and increased use of electronic collaboration regarding the ordering process based on this format.
1.1. 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 Peppol Order Agreement. It is based on the CEN WS/BII 42 Order Agreement.
This profile identifies, explains and justifies the business requirements for the Order agreement process. It provides syntax bindings to UBL 2.1 (Universal Business Language). It also includes a syntax implementation guide.
The order agreement profile describes processes where the buyer, after purchasing items/services, receives a message with information documenting the purchase.
2.1. Prerequisites
The following are prerequisites for this BIS:
-
A buyer has purchased goods or services from the seller by any means.
-
The seller has to be registered in the buyer system with information as contact information and identifiers used for other BIS transaction e.g. BIS order and invoice (GLN, Organization number…)
2.2. Scope
The intended scope for this BIS includes business-to-government (B2G) and business-to-business (B2B) relationships. Although the BIS is a basis for an EDI agreement between two parties, it does not address all business level details of such an agreement/contract.
The order agreement represents the combined information of an order and an order confirmation, i.e. it represents an agreement entered upon by seller and buyer. The transaction, specified in this BIS is intended to be exchanged between the seller’s order management system and the of buyer’s purchasing system so that their respective systems get syncronised with regard to the information on the purchase.
The different uses of this BIS are described in Process and typical use cases.
This is an auxiliary BIS intended to complement the primary ordering BISs, such as Peppol BIS 28A. It allows the buyer to have information from less formalized purchase processes conveniently fed into the procurement system, thereby giving control over corresponding payments and better statistics. By opening for order agreement transactions, it is very important that the buyer’s system can verify that the seller is allowed to send an order agreement and that the process is described in the contract between seller and buyer to prevent fraud and to secure good quality in the transaction.
2.3. Goals and Objectives
The following main business goals to be gained by implementing a BII Order agreement profile are the following and apply to this BIS.
| ID | Description |
|---|---|
G-42-001 |
The profile enables buyers to receive real time information on the contracted products/services, resulting in correct and up to date information, such as price and availability based on a contract. |
G-42-002 |
The effort to distribute catalogue information can be substantially reduced for sellers with large catalogues. It does not even presume standardized catalogues. |
G-42-003 |
The profile enables the buyer to create an order in the seller’s web shop. |
G-42-004 |
The profile enables the buyer to buy services such as flight tickets on-line and receive the order information back in the purchasing system of the buyer. |
G-42-005 |
The profile enables buyers to configure their own products (i.e. pc’s or furniture) on the seller’s website, and receive order information back to the purchasing system of the buyer., |
G-42-006 |
Increased order accuracy by ensuring high data quality in the purchasing system of the buyer. |
G-42-007 |
Personalized shopping experience - the seller’s product/services can be presented with photos, customized promotions and recommended accessories |
G-42-008 |
The profile enables the buyer to receive the order information back in the purchasing system of the buyer also in the cases where the order is sent via e-mail, made in a telephone call or on a visit to the seller’s store. |
G-42-009 |
The profile enables the buyer to instruct the seller to send a reference chosen by the buyer in the Order Agreement transaction. |
G-42-010 |
The buyer wants precise order to invoice matching. |
G-42-011 |
The seller wants an efficient way to report services rendered when buyer cannot order through the purchasing system. |
G-42-012 |
The seller wants to match order and invoice automatically |
G-42-013 |
The buyer wants to document the services rendered based on contract when the order was executed by other channels or based on a service agreement |
G-42-014 |
The buyer wants to receive order agreement in a structured way in a general and interoperable file-format with no need for custom mappings or conversions. |
G-42-015 |
The seller wants order agreement using generally accepted standard formats/specifications. |
G-42-016 |
A buyer wants to collect certificate and label information in his orders for analytical purposes. |
2.4. Parties and roles
The table below gives the definitions of the parties and roles of the ordering process.
Business partners |
Description |
Customer |
The customer is the legal person or organization who is in demand of a product or service. Examples of customer roles: buyer, consignee/delivery part, debtor, contracting body. |
Supplier |
The supplier is the legal person or organization who provides a product or service. Examples of supplier roles: seller, consignor, creditor, economic operator. |
Role/actor |
Description |
Buyer (BuyerCustomerParty) |
The buyer is the legal person or organization acting on behalf of the customer and who buys or purchases the goods or services. |
Seller (SellerSupplierParty) |
The seller is the legal person or organization acting on behalf of the supplier and who sells goods or services to the customer. |
The following diagram links the business processes to the roles performed by the Business Partners.
2.5. Benefits
-
The ability to use existing order-invoice-matching processes even if order is not issued from a procurement system.
-
Capture ordering actions that happen in other processes such as web shops, phone or by requisition at warehouse/store and so forth.
-
Visibility of whole spending analysis in the ordering module by importing orders that are not sent directly from the ordering module.
-
Support for ordering processes where products/services are not necessarily described as standardized catalogue items.
2.6. Interoperability
This Peppol BIS structure is based on the European Interoperability Framework 2.0. Peppol BIS applies the Framework as follows:
-
Legal Interoperability
-
Legal:
-
In implementations supporting public sector buyers, the use of the Punch out BIS has to be monitored in order to secure that the buyers act in line with EU procurement directives.
-
-
-
Organizational interoperability
-
Organization (Organization/Business):
-
This Peppol BIS supports B2B and B2G.
-
This Peppol BIS supports cross border, regional and domestic ordering in EU and EEA.
-
This Peppol BIS can function as a component in an EDI agreement within a trading community.
-
This Peppol BIS supports linking of business processes within the sending and receiving organization. The process of order transmission in electronic form can be linked into internal processes of both sender and receiver, which may differ for various reasons.
-
-
Organization (Process):
-
This Peppol BIS supports a set of “common business processes” that is assumed to be supported by most enterprises whether public or private. These are processes that are used widely or understood as being relevant for most companies.
-
-
-
Semantic interoperability
-
Semantic: The set of information elements is assumed to be sufficient to support organizational business and processing requirements stated above.
-
A CORE Order Agreement cart message:
-
Data model, a set of elements that the receiver MUST be able to process.
-
Business rules, a set of business rules that ensure a common way of processing the information elements. The rules are stated in a way that allows for automated validation of document instances. Issuers and receivers can verify that the exchanged document conformes to the rules of this BIS.
Peppol adds business rules on top of the data model to clarify certain design choices left open by the {cenbii}. These choices are intended to lower the implementation threshold by limiting options for implementers and thereby increase interoperability of Peppol punch out transactions.
-
-
-
-
Technical interoperability
-
Technical Interaction (Process and semantic implementation):
-
Binding to OASIS UBL 2.1, see UBL 2.1
-
ISO/IEC 19757-3 Schematron, for automation of document validation, see Schematron
-
XSLT Stylesheet for presentation of content, see [XSLT]
-
-
Technical Interaction (eSignature Validation):
-
Not mandatory in this Peppol BIS. Not supported.
-
-
3. Process and typical use cases
The order agreement BIS includes the sending of information on agreed products/services from a Seller to a Buyer.
3.1. Process flow
The order agreement process flow can be described as follows:
-
A Buyer makes a purchase of goods or services from the Seller.
-
A Seller reports one or more accumulated purchases made under a framework agreement to the Buyer.
-
A purchase has been recorded in the Buyer´s purchasing system. The seller proceeds to invoice accordingly.
An Order Agreement may refer to a framework agreement for its terms and conditions; otherwise the Buyer’s terms and conditions apply.
3.2. Business processes requirements
This process involves the use of two Documents:
-
an Order agreement, issued by the Seller;
-
a Confirmation Order, eventually issued by the Client.
The process starts with the sending of an Order Agreement from the Seller, who issues it because he is pre-authorized by the Client.
Following the reception of the Order Agreement, the Client can:
-
conclude the process without issuing a Confirmation Order;
-
transmit a Confirmation Order, that needs to contain the indication of the Order Agreement to which it is related to, for communicating to the Seller that he intends to:
-
confirm the Order Agreement received (Confirmation Order to approve);
-
reject the Order Agreement received (Confirmation Order to reject);
-
replace the Order Agreement received (Confirmation Order to substitute).
-
3.3. Business process Diagram
3.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 diagram shows the choreography of the business process implemented by the BIS.
Categories |
Description and Values |
Description |
The buyer doesn’t use the purchasing system to create an order. It’s done outside of this system. The seller creates an order in his ordering system based on requirements from the buyer and, after agreeing/committing to it, sends a copy of the order as an Order agreement to the buyer. |
Pre-conditions |
The seller’s ordering system must be able to send Order agreement transactions. The buyer’s purchasing system must be able to receive Order agreement transactions. The content of the order is agreed through use of web shop, phone, email, physical visit to shop or other means. |
Post-conditions |
The buyer has received an order agreement that is recorded in the purchasing system. |
Legal Implications |
By providing an Order agreement transaction the Seller commits himself the, quantities, prices and terms stated in the Order agreement transaction. |
3.4. Use case 1 – Web store used for booking tickets
This use case describes the process where a customer/buyer orders tickets.
Use Case number |
1 |
|---|---|
Use Case Name |
Web store used for booking tickets |
Use Case Description |
The buyer uses a website to buy tickets, such as for airfare or events. |
Parties involved |
|
Assumptions |
The seller has a website that allows the buyer to select and order tickets. |
The flow |
The buyer uses the website to book tickets. The buyer receives the tickets in the way as selected in the web shop (e.g. mobile ticket or pdf). The buyer then ends the web shop session. The purchase is recorded in the seller’s system. An order agreement transaction with all necessary information is sent from the seller’s system to the buyer’s purchasing system. The order agreement is recorded in the buyer’s purchasing system. An invoice is sent to the buyer, but this is outside of this BIS. If the buyer wishes to change a ticket in accordance with the its rules then he reenters the web store, changes the ticket and receives a new order agreement. The change procedure is a repetition of the initial one. |
Result |
The buyer and the seller have reached an agreement. An order has been placed for tickets and the buyer has received a structured message with its details. If the invoice has an order reference, the invoice can be matched automatically. |
3.5. Use case 2 – Web shop used for ordering items
This use case describes the process where a customer/buyer orders products in a web shop.
Use Case number |
2 |
|---|---|
Use Case Name |
Web shop used for ordering items |
Use Case Description |
The buyer uses a website to buy items. |
Parties involved |
|
Assumptions |
The seller has a website that allows the buyer to select and order items. |
The flow |
The buyer is working in the in-house purchasing system, selects a seller that has a web shop, and clicks to see that seller’s products. The buyer searches the website for items needed, and choose to add some to the order agreement. It is clearly visible which items are contracted. After selecting all required items, the buyer then chooses to buy the selected items. When the ordering is finalized in the web shop, the buyer ends the web shop session. The purchse is recorded in the seller’s system. An order agreement transaction with item information of the purchased items is sent from the seller to the. The order agreement is recorded in the buyer’s purchasing system. After the delivery of the goods the seller sends an invoice which matches the order and the delivery, but this is outside of this BIS. |
Result |
The buyer and the seller have reached an agreement. An order has been placed and the buyer has received a structured message with the order details. If the invoice has an order reference, the invoice can be matched automatically. |
3.6. Use case 3 – Telephone and e-mail is used to order items
Use Case number |
3 |
|---|---|
Use Case Name |
Telephone or e-mail order |
Use Case Description |
Buyer makes a purchase by calling the seller by telephone or by sending an email. |
Parties involved |
|
Assumptions |
The buyer has an account with the seller with necessary details to send him an order agreement. |
The flow |
The buyer is working in his purchasing system, and need to by printers and selects a seller of printers. The seller’s items are not in the purchasing system and the seller doesn’t offer a web shop. The buyer calls the seller on the telephone. The buyer orders the printer directly during the phone call, and also informs the seller what reference to use. An order agreement transaction with item information and price of the selected items is sent from the seller to the buyer’s purchasing system. The order agreement is recorded in the buyer’s purchasing system After the delivery of the goods, the seller sends an invoice which matches the order and the delivery, but this is outside of this BIS. |
Result |
The buyer and the seller have reached an agreement. An order has been placed and the buyer has received a structured message with the order details. If the invoice has an order reference, the invoice can be matched automatically. |
3.7. Use case 4 – Buyer visits the seller’s physical store.
This use case describes a process where the buyer physically enters the sellers store to buy and possibly take delivery of goods.
Use Case number |
4 |
|---|---|
Use Case Name |
User configures product/services |
Use Case Description |
A buyer physically makes a purchase and takes delivery. |
Parties involved |
|
Assumptions |
The buyer has an account with the seller with necessary details to send him an order agreement. |
The flow |
The buyer urgently need some items and may wish to discuss this with the seller before buying the items. After selecting the items he needs the buyer gets a receipt for the selected items. He may bring with him all the items when leaving the store or schedule a later delivery. The seller registers the order in the ordering system including a reference such as requisition number, person id, project id etc. An order agreement transaction with item information and price of the selected items is sent from the seller to the buyer’s purchasing system. The order agreement is recorded in the buyer’s purchasing system The buyer then follows the normal procedure to, if needed, complete the order. The seller sends an invoice which matches the order and delivery, but this is outside of this BIS. |
Result |
The buyer and the seller has reached an agreement. An order has been placed and the buyer has taken delivery of the products. The buyer has received a structured message with the order details. The invoice has a reference, to match the order. |
3.8. Use case 5 – Framework contract
The buyer has made a framework agreement with the seller for services such as maintenance or consulting. The framework agreement sets limits and terms within which the seller may provide services without individual orders from the buyer.
Use Case number |
5 |
|---|---|
Use Case Name |
Maintenance based on framework contract |
Use Case Description |
A seller who has a framework agreement that contracts him for certain services, items or consulting may react to events as contracted and at the end of a period send an order agreement listing the services that were carried out.
In each of these examples the buyer has made a framework contract with the seller allowing the seller to react to defined but not previously known events without receiving an order or request from the buyer for each event. |
Parties involved |
|
Assumptions |
The seller and buyer has a framework contract that define the service to be provided and its limits. |
The flow |
The seller of the services or items reacts to events as defined in the contract and carries out the service or delivers the items as contracted. Periodically, for example monthly, the seller lists all services and items that have been provided during the period. This is listed with order agreement lines and the total of the order agreement represents the total value of the services and items provided during the period which will be invoice by the seller. The seller sends the order agreement to the buyer who records it in his system. The seller proceeds to invoice immediately unless otherwise directed by the framework agreement. The buyer may have internal processes that verify these kind of order agreements differently than those initiated by himself. |
Result |
The buyer has registered a purchase order in his systems that allow him to order to invoice matching when the invoice is received. |
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, 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. |
4.2. Semantic data types
The different semantic data types are described in the tables below, where various features such as attributes, format, and decimals as well as the basic type are defined for each semantic data type. They are based on ISO 15000-5:2014.
When used in an instance document, each data element will contain data. In the below tables this is identified as the “content”. Whenever a business term is used this term shall always have content and therefore the content is always mandatory.
4.2.1. Amount
An amount states a numerical monetary value. The currency of the amount is defined as a separate business term.
| Amount is floating up to two fraction digits. |
| Component | Use | Primitive Type | Example |
|---|---|---|---|
Content |
Mandatory |
Decimal |
10000.25 |
4.2.2. Price Amount
A price amount states a numerical monetary amount value for data elements that contain item prices that may be multiplied by item quantities. The currency of the amount is defined as a separate business term.
| Unit price amount does not set restrictions on number of decimals, as contrast to the Amount type |
| Component | Use | Primitive Type | Example |
|---|---|---|---|
Content |
Mandatory |
Decimal |
10000.1234 |
4.2.3. Percentage
Percentages are given as fractions of a hundred (per cent) e.g. the value 34.78 % in percentage terms is given as 34.78.
| No restriction on number of decimals for percentages. |
| Component | Use | Primitive Type | Example |
|---|---|---|---|
Content |
Mandatory |
Decimal |
34.7812 |
4.2.4. Quantity
Quantities are used to state a number of units such as for items. The code for the Unit of Measure is defined as a separate business term.
| No restriction on number of decimals for quantities. |
| Component | Use | Primitive Type | Example |
|---|---|---|---|
Content |
Mandatory |
Decimal |
10000.1234 |
4.2.5. Code
Codes are used to specify allowed values in elements as well as for lists of options. Code is different from Identifier in that allowed values have standardized meanings that can be known by the recipient.
| Codes shall be entered exactly as shown in the selected code list |
| Component | Use | Primitive Type | Example |
|---|---|---|---|
Content |
Mandatory |
String |
Abc123 |
4.2.6. Identifier
Identifiers (IDs) are keys that are issued by the sender or recipient of a document or by a third party.
| The use of the attributes is specified for each information element. |
| Component | Use | Primitive Type | Example |
|---|---|---|---|
Content |
Mandatory |
String |
abc:123-DEF |
Scheme identifier |
Conditional |
String |
0088 |
Scheme version identifier |
Conditional |
String |
1.0 |
4.2.7. Date
Dates shall be in accordance to the “Calendar date complete representation” as specified by ISO 8601:2004, format YYYY-MM-DD.
| Dates shall not include timezone information. |
| Component | Use | Primitive Type | Example |
|---|---|---|---|
Content |
Mandatory |
Date |
2017-12-01 |
4.2.8. Time
Time shall be in accordance to the “Extended time format” as specified by ISO 8601:2004, format [hh]:[mm]:[ss].
| Time shall not include timezone information. Decimal fraction on seconds SHALL not be used. |
| Component | Use | Primitive Type | Example |
|---|---|---|---|
Content |
Mandatory |
Date |
09:30:12 |
4.2.9. Document Reference
Document Reference Types are identifiers that were assigned to a document or document line.
| Component | Use | Primitive Type | Example |
|---|---|---|---|
Content |
Mandatory |
String |
abc:123-DEF |
4.2.10. Text
Text is the actual wording of anything written or printed. Line breaks in the text may be present, and any line breaks should be preserved and respected by the receiver’s system
| Component | Use | Primitive Type | Example |
|---|---|---|---|
Content |
Mandatory |
String |
5% allowance when paid within 30 days |
4.2.11. Binary objects
Binary objects can be used to describe files which are transmitted together with the business document. Attachments shall be transmitted together with the business document. The binary object has two supplementary components: a Mime Code, which specifies the Mime type of the attachment and a Filename that is provided by (or on behalf of) the sender of the business document.
| Component | Use | Primitive Type | Example |
|---|---|---|---|
Content |
Mandatory |
Binary |
QmFzZTY0IGNvbnRlbnQgZXhhbXBsZQ== |
Mime Code |
Mandatory |
String |
image/jpeg |
Filename |
Mandatory |
String |
drawing5.jpg |
4.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>Valore#Valore#Valore</Tag>Structured fields allowed are solely and strictly the ones listed in the table below:
| Structured fields | Peppol Document |
|---|---|
OrderDocumentReference/ID |
Order Only |
OrderReference/ID |
Order Agreement |
DeliveryTerms/SpecialTerms |
Order Only |
AccountingCost |
Order Only |
AdditionalDocumentReference/ID |
Order Only |
ItemSpecificationDocumentReference/ID |
Order Only |
4.4. Type of Document
The Documents, which constitute the body of the message, contain the instructions that Buyers and Sellers exchange to settle the provision of goods and services.
The following table lists documents documents sub-types and variants of the Order and described in the paragraphs that follows.
See paragraph 7.3.1 for compilation rules.
| Type of Document | Sub-types | Variants |
|---|---|---|
Ordine (Order) |
Ordine di riscontro (Confirmation Order) |
Confirmation Order to approve |
Confirmation Order to reject |
||
Confirmation Order to substitute |
||
Ordine Pre-concordato (Order Agreement) |
Ordine Pre-concordato inziale (Initial Order Agreement) |
- |
Ordine Pre-concordato di revoca (Revocation Order Agreement) |
- |
|
Ordine Pre-concordato sostitutivo (Replacement Order Agreement) |
- |
|
Ordine Pre-concordato collegato (Connected Order Agreement) |
- |
|
Ordine Pre-concordato di convalida (Validation Order Agreement) |
- |
Confirmation Order
The Confirmation Order is a particular Order Document sub-type with which the Buyer (sender) approve, reject or susbtitute a Response sent by the Seller (receiver).
The Confirmation Order takes on the following variants:
-
The Confirmation Order to approve is an Order containing the indication that it is a confirmation (“Accepted”) and the reference to the Response that is intended to be confirmed. This Order contains only one empty order line.
-
The Confirmation Order to reject is an Order containing the indication that it is a refusal (“Cancelled”) and the reference to the Response that is intended to be rejected. This Order contains only one empty order line.
-
The Confirmation Order to substitute is a new Order, complete of all the order lines and contains the indication that it’s a substitution (“Revised”) and the reference to the Response that is intended to be replaced.
| Confirmation Order to substitute and Confirmation Order to reject, respectively, replaces and cancels the Response specified therein and all the other Replacement Order/s and Revocation Order/s already transmitted, related to the Initial Order. |
<cbc:CustomizationID>urn:fdc:peppol.eu:poacc:trns:order:3 :restrictive:urn:www.agid.gov.it:trns:ordine:3.1<cbc:CustomizationID>
<cbc:ProfileID>urn:fdc:peppol.eu:poacc:bis:order_only:3</cbc:ProfileID>
<cbc:ID>460</cbc:ID>
<cbc:IssueDate>2018-03-15<cbc:IssueDate>
…
<cac:OrderDocumentReference>
<cbc:ID>380#2018-02-16#ITccccccccccc#Cancelled</cbc:ID>
</cac:OrderDocumentReference>
…
<cac:BuyerCustomerParty>
<cac:Party>
<cbc:EndpointID schemeID="0201”>ABCDEF</cbc:EndpointID>
</cac:Party>
</cac:BuyerCustomerParty>
…
<cac:SellerSupplierParty>
<cac:Party>
<cbc:EndpointID schemeID="0211">ITddddddddddd</cbc:EndpointID>
</cac:Party>
</cac:SellerSupplierParty>
…
<cac:OrderLine>
<cac:LineItem>
<cbc:ID>NA</cbc:ID>
<cbcQuantity unitCode="C62">0</cbc:Quantity>
<cac:Item>
<cbc:Name>NA</cbc:Name>
</cbc:Item>
</cac:LineItem>
</cac:OrderLine>Revocation Order Agreement
For some circumstances, the revocation of a previosly issued Order may be useful.
The Revocation Order Agreement is an Order Agreement that contains the reference another Order Agreement that is intended to revoke and the indication that convey this information (“Cancelled”), also it has only one order line empty.
See paragraph 6.12 for compilation rules.
Replacement Order Agreement
Where appropriate, the instructions contain into an Order Agreement can be modified through the issuance of a Replacement Order Agreement. However, unless otherwise prescribed by regulations, commercial use or agreement between the parties, the Seller is required to consider as effective only the replacement of Orders received before the execution of the supply.
The Replacement Order Agreement is a new Order, complete with all the order lines and contains the reference to the Order Agreement that is intended to be replaced with the indication that it’s a "substitution" (“Revised”).
In some cases, however, it may be necessary to modify the information contained in a previous Order Agreement, even after the conclusion of the supply process, or even after the issuance of the related Invoice (when the Document is only issued in order to regulate some details of a process already closed)
| In this cases the Replacement Order Agreement must report the indication of the Order sub-type “OR”, (so-called “Regulating Replacement Order Agreement", see paragraph 4.4). |
See paragraph 6.12 for compilation rules.
Connected Order Agreement
For some circumstances, it may be useful to highlight that an Order Agreement, even though is indipendent, it is generically related to another Document.
In this cases the Connected Order Agreement is used, where it is present a reference to the linked Order and the indication “Connected”.
| The Connected Order Agreement can be used exclusively to keep memory that the new process that is intended to begin it’s connected to another one. This Order must never be used in place of the others (i.e. Revocation Order Agreement, Replacement Order Agreement, Confirmation Order Agreement) specifically designed to revoke, substitute (or integrate), confirm or refuse another Document. |
See paragraph 6.12 for compilation rules.
Validation Order Agreement
The Validation Order Agreement is an Order Agreementin which there is a reference to an Invoice to be regularised and the indication that it’s a validation (“Invoice”).
This Order Agreement can be exclusively used:
-
to validate an Invoice issued in absence of the relative provision order through NSO;
-
if necessary, to validate an Invoice referred to an Order when the Invoicee is different from the initial Buyer (e.g. sent by a Contracting authority or in case the initial Buyer has been bought, sold or divided).
| The Validation Order Agreement must never be used in place of the others (i.e. Revocation Order Agreement, Replacement Order Agreement, Confirmation Order Agreement) specifically designed to revoke, substitute (or integrate), confirm or refuse another Document. |
In the case of Validation Order Agreement it is necessary to report the details of the Invoice to be validated in the element OrderReference/ID, filling it with the values and by respecting the order of priority that follows:
-
the number of the Invoice that is intended to be validated;
-
the issuing date of the Invoice that is intended to be validated;
-
the VAT number of the subject who issued the Invoice that is intended to be validated;
-
the text “Invoice” to indicate that it’s an Order for validating an Invoice (or an equivalent request for payment).
<cac:OrderReference>
<cbc:ID>57#2018-01-30#ITccccccccccc#Invoice</cbc:ID>
</cac:OrderReference>4.5. Order type
The Order Type and Order Sub-Type codes must me indicated in the field cbc:SpecialTerms of the element cac:DeliveryTerms, which is a structured fields, as shown in the following examples:
<cac:DeliveryTerms>
<cbc:SpecialTerms>220#OF</cbc:SpecialTerms>
</cac:DeliveryTerms>A subset of the UNCL 1001 codelist is used to identify the typology of the order: "OrderTypeCode IT" (section "Codelist" of the Homepage), defined by Peppol and extended by the italian procurement model (consistent with NSO).
Order type is an essential element of the process. The code 220 is assumed by default if not present.
Order Type |
Order Sub-Type |
||
Code |
Description |
Code |
Description |
220 |
Ordine di Acquisto (Purchase Order) |
- |
Ordine di acquisto in senso stretto (Purchase Order in the strict sense) |
OF |
Ordine di fatturazione (Order for Billing products already consumed) |
||
OFR |
Ordine di fatturazione e reintegro (Order for Billing products already consumed and Restoration) |
||
ON |
Ordine di noleggio (Order for Rental) |
||
OR |
Ordine di regolazione (Order for Regulation) |
||
OB |
Ordine a budget (Order for Budgeting) |
||
227 |
Ordine di consegna (Delivery Order) |
- |
Ordinazione generica di consegna (Generic Delivery Order) |
CD |
Ordine in conto deposito (Order on Consignment) |
||
CV |
Ordine in conto visione (Order for Evaluation) |
||
CG |
Ordine in comodato gratuito (Order for Free Rental) |
||
CN |
Ordine in conto noleggio (Order for Rental Account) |
||
Purchase Order (220)
The typology 220 corresponds to a generic Purchase Order that can be used both for goods and services, with or without the issuance of the related Despatch Advice. In this typology Orders for goods to supply are included, also Orders for goods in transit or goods never stoked, Orders for sending products under repair and Orders for rental with fees.
In particular, the code “220” (Purchase Order) indicates that the order relates to a transaction that involves usually the following effects:
-
the transfer from the Seller to the Buyer both the ownership (or others real rights) and the possession of goods;
-
the provision of services against payment. Note that, even if some provisions involve the transfer of possession (e.g. rental), the main object of the provision it is not the transfer of the items but the performance of a service.
and, in particular circumstances:
-
the transfer from the Seller to the Buyer of the ownership (or others real rights) but not the transfer of the possessions. In this instance, the possession transfer may not be necessary or may be regulated with a separated Delivery Order, which may precede (for example goods in the deposit account) or follows the Purchase Order.
As a general rule, what characterizes Purchase Orders in the stict sense is that the transactions are onerous (at least nominally), with the effect of the issuance of an Invoice or an equivalent document.
Can be provided a further detail of the Purchase Order by using the following sub-types:
-
OF (Order for Billing products already consumed): with the "Order for Billing products already consumed" (OF) the Buyer is not asking to the Seller for shipping a goods or providing a service, but just the issuance of the Invoice (or equivalent document) in the face of a product already in possession by the client or a service already perfomed (for example some products in the deposit account then used or items on evaluations then decided to buy).
In the case of goods purchased through the method "Order on Evaluation" (for example, implantable medical devices managed directly by an operating room) the Order for Billing is used to authorize the invoicing of the only goods held and consumed.
Furthermore, in the case of a Order on Consignement) the Order for Billing) is used to authorize the invoicing of the goods in the deposit account for which is not required the "contextual restoration".
To the code 220#OF can be led back all the Orders that regards the Invoicing of products already consumed, for which the Sellere does not need a new delivery. The Order type 220#OF reports the reference (in specific fields) of Lot, Serial Number, ID and Date of the Despatch Advice related to the goods delivered.;
-
OFR (Order for Billing products already consumed and Restoration): the "Order for Billing and Restoration" (OFR) is used to ask to a Seller for the Invoice in the case of goods already owned in a Deposit Account and already consumed and at the same time the restoration of the same product in the Deposit Account (please note that the Invoice and the restoration must refer to the same items in terms of name, quantity, lot, delivery reason in the Despatch Advice, etc.).
The stock management in a deposit account normally involves a certain product quantity already determined to maintain the stock of each product to the minimum necessary. The stock is maintained to the agreed minimum quantity not periodically but after each use.
The Order type 220#OFR is used also for all the goods bought with Invoicing at report, kit, test or validation. The Order type 220#OFR reports the reference (in specific fields) to the Lot, Serial Number, ID and date of the Despatch Advice related to the goods delivered.
<cac:DeliveryTerms>
<cbc:SpecialTerms>220#OFR</SpecialTerms>
</cac:DeliveryTerms>-
ON (Order for Rental): in some cases, as abovementioned in letter b), the performance of the services is realized through the transfer of the possession of one or more items.
Therefore, the "Order for Rental" (ON) differs from a sale beacuse the transfer of the possession is limited in time and is accomplished through a lease.
For these reasons the rent is handled alternatively:
-
as an Order with a service as object (the rental of goods);
-
as an Order with one ore more items with a limited time period transfer as object (the rented goods).
-
In the first case, given that the Order’s object is the rental service (which incorporates but not coincide with the trasnfer of individual goods) the unit price to be indicated in the Document must refer to the entire duration of the event and to all the goods that make up each unit of the service, as foreseen in the rental agreement.
See below two example of Orders (both examples not include allowances and charges).
For detailed instructions and further examples about rental Orders, please see paragraph n° 3.3.3.17 of Regole Techniche NSO.
<cbc:Note>Pagamento in rate mensili</cbc:Note >
…
<cac:DeliveryTerms>
<cbc:SpecialTerms>220#ON</SpecialTerms>
</cac:DeliveryTerms>
…
<cac:OrderLine>
<cac:LineItem>
<cbc:ID>Numero della linea d’ordine</ cbc:ID>
<cbc:Quantity unitCode="C62">10</cbc:Quantity>
<cbc:LineExtensionAmount currencyID="EUR">15000</cbc:LineExtensionAmount>
…
<cac:Price>
<cbc:PriceAmount currencyID="EUR">1500</cbc:PriceAmount>
</cac:Price>
<cac:Item>
<cbc:Description>Modello della stampante</cbc:Description>
<cbc:Name>Modello della stampante</cbc:Name>
</cac:Item>
</cac:LineItem>
</cac:OrderLine>Given the Order, 12 Invoices of € 1.250 will be issued at the end of each montlhy installements (this information is reported in the element “PaymentTerms/Note”).
…
<cbc:Note>Pagamento in rate trimestrali</cbc:Note>
…
<cac:DeliveryTerms>
<cbc:SpecialTerms>220#ON</SpecialTerms>
</cac:DeliveryTerms>
…
<cac:OrderLine>
<cac:LineItem>
<cbc:ID>Numero della linea d’ordine</ cbc:ID>
<cbc:Quantity unitCode="C62">12</cbc:Quantity>
<cbc:LineExtensionAmount currencyID="EUR">43200</cbc:LineExtensionAmount>
…
<cac:Price>
<cbc:PriceAmount currencyID="EUR">3600</cbc:PriceAmount>
</cac:Price>
<cac:Item>
<cbc:Description>Postazione di lavoro composta da pc, 2 monitor, stampante</cbc:Description>
<cbc:Name>Postazione di lavoro standard</cbc:Name>
</cac:Item>
</cac:LineItem>
</cac:OrderLine>Given the Order, 8 Invoices of € 5.400 will be issued (four per year) at the end of each quarterly installements (this information is reported in the element “PaymentTerms/Note”).
-
OR (Order for Regulation): in certain circumstances, can be necessary to modify or specify in more detail the information of an Order previously sent and referred to a provision already carried out.
In these cases, it is necessary issuing an Order that refers to the previous Order, specifying that it is a "Order for Regulation" (OR).
An Order for Regulation, so, is an Order:
-
used to specify in a more detailed way or to modify the information contained in a previous Order;
-
that never constitutes a new request of Order and Services, instead it integrates the information of an already closed processed.
An Order for Regulation is realized alternatively:
-
via a Connected Order (Connected Order for Regulation), when it is necessary to specify information about the provision, the quantity and/or prices (or part of them) contained in a previous Order.
-
via a Replacement Order (Replacement Order for Regulation), when it is necesssary to modify information about the provision, the quantity and/or prices (or part of them) contained in a previous Order.
For detailed instructions and further examples about rental Orders, please see paragraph n° 3.3.3.17 of Regole Techniche NSO.
-
OB (Order for Budgeting): it may happen that the price, the quantity and even the details about goods and services to order are not known precisely at the moment of the issuance of the Order.
In these cases the type “220” can be associated with sub-type “OB” (Order for Budgeting), with which the Buyer indicates that the information about quantity and/or prices cointained in the Order need to be considered ad maximum expected values and that the same goods and services object of the provision may be described in a summary way.
An Order for Budgeting, so, it is an Order in which:
-
quantity and/or price indicated are to be intended by the Seller as maximum values and not be exceeded;
-
the object of the provision may be described in a summary way.
An Order for Budgeting can be:
-
an Initial Order for Budgeting, meaning that it is an Initial Order for Budgeting, an Initial Order with estimated quantity and/or prices.
-
an Order Replacement for Budgeting, meaning that it is an Order Replacement issued while the provision is still to be completed, and that changes the estimated quantity and/or prices of an Initial Order for BudgetingInitial Order for Budgeting.
For detailed instructions and further examples about rental Orders, please see paragraph n° 3.3.3.18 of Regole Techniche NSO.
Delivery Order (227)
The typology 227 corresponds to orders for materials that do not involve an invoicing except after the use of the materials and after an Order type 220.
Can be provided a further detail of the Delivery Order by using the following sub-types:
-
CD (Conto deposito - Order on Consignement), for consitution or integration of a stock of goods on consignement;
-
CV (Conto visione - Order for Evaluation), for consitution or integration of a stock of goods on evaluation;
-
CG (Comodato d’uso gratuito - Order for Free Rental), for consitution or integration of a stock on loan;
-
CN (Conto noleggio - Order for Rental Account), for consitution or integration of a stock with the aim of a subsequnt rental.
Note that the Order on Consignement (CD) needs to be certainly issued at the constitution of a deposit account and everytime it is intended to change the quantity of the goods in the deposit. In case of reintegration of the consumed goods, contrary, the Order for Billing and Reintegration (OFR) can be used.
The code “227”, on the other hand, must be utilized solely to regulate the transfer of the goods possession from the Seller to the Buyer, but not the ownership or the service free of charge, or in the case of free of cahrge performances.This happens in the cases of Order on Consignement, Order for Evaluation and Order Free Rental that do not entail, per se, issuing of an invoice.
Note that, however, in many cases the transfer of the possession is accessory of a service provision (see the abovementioned letter b) or precedes a transfer of ownership (see the abovementioned letter c), therefore the Delivery Order can be linked to one or more Purchase Order.
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 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.
5.2. Code list for identifiers
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 Codelist ICD
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. |
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 (CEF Code lists).
Valid values are found in the Codelist EAS
cbc:EndpointID<cbc:EndpointID schemeID="0211">IT01234567890</cbc:EndpointID> (1)| 1 | schemeID attribute is mandatory |
6. Calculations
6.1. Calculation of TAX amounts
6.1.1. Total TAX amount
The total TAX amount can be provided without providing the TAX breakdown, but if the TAX breakdown is present, the total TAX amount is the sum of all TAX Category TAX amounts.
\$"Total TAX amount" = sum("TAX category tax amount")\$
6.1.2. TAX Breakdown
One TAX Breakdown shall be provided for each distinct combination of TAX category code and TAX rate found in either the line TAX information or the Document level allowance or charges.
For each distinct combination of TAX category code and TAX rate the calculations are:
\$"TAX category taxable amount" = sum("Line net amounts")\$
\$+ "Document level charge amount" - "Document level allowance amount"\$
\$"TAX category tax amount" = "TAX category taxable amount" times ("TAX rate" div 100)\$
| For TAX Breakdown where the TAX Category indicates the invoice is not subject to TAX (e.g. (O) in EU), then the TAX category tax amount shall be zero. |
Please note that for the TAX rate, only significant decimals should be considered, i.e any difference in trailing zeros should not result in different TAX breakdowns.
Line 1 has category code = S and VAT rate = 25
Line 2 has category code = S and VAT rate = 25.00
This should result in only one VAT Breakdown.
<cac:TaxTotal>
<cbc:TaxAmount currencyID="EUR">283.2</cbc:TaxAmount>
<cac:TaxSubtotal>
<cbc:TaxableAmount currencyID="EUR">1200</cbc:TaxableAmount>(1)
<cbc:TaxAmount currencyID="EUR">283.20</cbc:TaxAmount>(2)
<cac:TaxCategory>
<cbc:ID>S</cbc:ID>
<cbc:Percent>23.6</cbc:Percent> (3)
<cac:TaxScheme>
<cbc:ID>VAT</cbc:ID>
</cac:TaxScheme>
</cac:TaxCategory>
</cac:TaxSubtotal>
</cac:TaxTotal>| 1 | The class cac:TaxCategory is used for tax category information |
| 2 | TAX category according to to codelist UNCL5305 |
| 3 | TAX rate |
6.2. Calculation of totals
The following elements show the legal monetary totals
| Element | Description | Formula |
|---|---|---|
|
Sum of line net amounts |
\$sum("cac:OrderLine/LineItem/cbc:LineExtensionAmount")\$ |
|
Sum of allowances on document level |
\$sum("cac:AllowanceCharge[ChargeIndicator='false']/cbc:Amount")\$ |
|
Sum of charges on document level |
\$sum("cac:AllowanceCharge[ChargeIndicator='true']/cbc:Amount")\$ |
|
Invoice total amount without VAT |
\$\ \ \ \ "cac:LegalMonetaryTotal/cbc:LineExtensionAmount"\$ |
|
Invoice total amount with VAT |
\$\ \ \ \ "cac:LegalMonetaryTotal/cbc:TaxExclusiveAmount"\$ |
|
Amount allready paid |
Not applicable |
|
Amount added for rounding of the payable amount |
Not applicable |
|
Amount due for payment |
\$\ \ \ \ "cac:LegalMonetaryTotal/cbc:TaxInclusiveAmount"\$ |
7. Description of selected parts of the order agreement message
Following clauses describe the use of individual sections of the order agreement transaction.
7.1. Parties
The following parties/roles may be specified in the message:
7.1.1. SellerSupplierParty (Seller)
The seller is the legal person or organization acting on behalf of the supplier and who sells goods or services to the buyer. The seller is mandatory in the Peppol BIS Order Agreement message.
In case you want to indicate the VAT number, this must be indicated in the Seller party identification. + field In case you want to indicate the Tax Code, this must be indicated in the Seller legal registration identifier.
<cac:SellerSupplierParty>
<cac:Party>
<cbc:EndpointID schemeID="0211">IT01234567890</cbc:EndpointID>
<cac:PartyIdentification>
<cbc:ID schemeID="0211"> IT01234567890</cbc:ID>
</cac:PartyIdentification>
<cac:PostalAddress>
<cbc:StreetName>Indirizzo Riga 1</cbc:StreetName>
<cbc:AdditionalStreetName>Indirizzo Riga 2</cbc:AdditionalStreetName>
<cbc:CityName>Bologna</cbc:CityName>
<cbc:PostalZone>40121</cbc:PostalZone>
<cbc:CountrySubentity>BO</cbc:CountrySubentity>
<cac:AddressLine>
<cbc:Line>Zona Savena</cbc:Line>
</cac:AddressLine>
<cac:Country>
<cbc:IdentificationCode>IT</cbc:IdentificationCode>
</cac:Country>
</cac:PostalAddress>
<cac:PartyLegalEntity>
<cbc:RegistrationName>Azienda fornitore</cbc:RegistrationName>
<cbc:CompanyID schemeID="0210">01598570354</cbc:CompanyID>
<cac:RegistrationAddress>
<cbc:CityName>Bologna</cbc:CityName>
<cac:Country>
<cbc:IdentificationCode>IT</cbc:IdentificationCode>
</cac:Country>
</cac:RegistrationAddress>
</cac:PartyLegalEntity>
<cac:Contact>
<cbc:Name>Lucio Grande</cbc:Name>
<cbc:Telephone>051102030</cbc:Telephone>
<cbc:ElectronicMail>lucio.grande@fornitore.it</cbc:ElectronicMail>
</cac:Contact>
</cac:Party>
</cac:SellerSupplierParty>If the Seller is a Public Administration, the code 0201 shall be used in the element EndpointID/@schemeID, followed by the Entity’s CUU code (Codice Univoco Ufficio, so-called "iPA code").
<cac:SellerSupplierParty>
<cac:Party>
<cbc:EndpointID schemeID="0201"> UFY9MH</cbc:EndpointID>
<cac:PartyIdentification>
<cbc:ID schemeID="0211"> IT01234567890</cbc:ID>
</cac:PartyIdentification>
<cac:PostalAddress>
<cbc:StreetName>Via Amendola 2</cbc:StreetName>
<cbc:CityName>Reggio Emilia</cbc:CityName>
<cbc:PostalZone>42122</cbc:PostalZone>
<cbc:CountrySubentity>RE</cbc:CountrySubentity>
<cac:Country>
<cbc:IdentificationCode>IT</cbc:IdentificationCode>
</cac:Country>
</cac:PostalAddress>
<cac:PartyLegalEntity>
<cbc:RegistrationName>Azienda USL di Reggio Emilia</cbc:RegistrationName>
<cbc:CompanyID schemeID="0210">01234567890</cbc:CompanyID>
<cac:RegistrationAddress>
<cbc:CityName>Reggio Emilia</cbc:CityName>
<cac:Country>
<cbc:IdentificationCode>IT</cbc:IdentificationCode>
</cac:Country>
</cac:RegistrationAddress>
</cac:PartyLegalEntity>
<cac:Contact>
<cbc:Name>Giovanni Rossi</cbc:Name>
<cbc:Telephone>0522335111</cbc:Telephone>
<cbc:ElectronicMail>giovanni.rossi@ausl.re.it</cbc:ElectronicMail>
</cac:Contact>
</cac:Party>
</cac:SellerSupplierParty><cac:SellerSupplierParty>
<cac:Party>
<cbc:EndpointID schemeID="9925">0999999999</cbc:EndpointID>
<cac:PostalAddress>
<cbc:StreetName> Rue Emile Claus 28</cbc:StreetName>
<cbc:AdditionalStreetName>Quartiere</cbc:AdditionalStreetName>
<cbc:CityName>Bruxelles</cbc:CityName>
<cbc:PostalZone>1050</cbc:PostalZone>
<cac:AddressLine>
<cbc:Line>Deposito Consegnatario: Fornitore Estero</cbc:Line>
</cac:AddressLine>
<cac:Country>
<cbc:IdentificationCode>BE</cbc:IdentificationCode>
</cac:Country>
</cac:PostalAddress>
<cac:PartyLegalEntity>
<cbc:RegistrationName>Fornitore Estero</cbc:RegistrationName>
</cac:PartyLegalEntity>
<cac:Contact>
<cbc:Name>Lucio Grande</cbc:Name>
<cbc:Telephone>003241102030</cbc:Telephone>
<cbc:ElectronicMail>lucio.grande@belgio.be</cbc:ElectronicMail>
</cac:Contact>
</cac:Party>
</cac:SellerSupplierParty>7.1.2. BuyerCustomerParty (Buyer)
The buyer is the legal person or organization acting on behalf of the customer and who buys or purchases the goods or services. The buyer is mandatory in the Peppol BIS Order Agreement message.
If the Contracting Authority is registered in Peppol with the CUU code (Codice Univoco Ufficio, so-called "iPA code"), this must be indicated in the Endpoint (cac:EndpointID):
<cac:BuyerCustomerParty>
<cac:Party>
<cbc:EndpointID schemeID="0201">ABCDEF</cbc:EndpointID>
…
</cac:Party>
</cac:BuyerCustomerParty>In case you want to indicate the VAT number, this must be indicated in the Buyer party identification. + field In case you want to indicate the Tax Code, this must be indicated in the Buyer legal registration identifier.
<cac:BuyerCustomerParty>
<cac:Party>
<cbc:EndpointID schemeID="0201">UFY9MH</cbc:EndpointID>
<cac:PartyIdentification>
<cbc:ID schemeID="0211">IT01598570354</cbc:ID>
</cac:PartyIdentification>
<cac:PostalAddress>
<cbc:StreetName>Via Amendola 2</cbc:StreetName>
<cbc:CityName>Reggio Emilia</cbc:CityName>
<cbc:PostalZone>42122</cbc:PostalZone>
<cbc:CountrySubentity>RE</cbc:CountrySubentity>
<cac:Country>
<cbc:IdentificationCode>IT</cbc:IdentificationCode>
</cac:Country>
</cac:PostalAddress>
<cac:PartyLegalEntity>
<cbc:RegistrationName>Azienda USL di Reggio Emilia</cbc:RegistrationName>
<cbc:CompanyID schemeID="0210">01598570354</cbc:CompanyID>
</cac:PartyLegalEntity>
</cac:Party>
</cac:BuyerCustomerParty>7.1.3. OriginatorCustomerParty (Originator)
The unit initiating or requesting the ordered items. Most often the end user. The originator information is optional in the Peppol BIS Order Agreement message.
<cac:OriginatorCustomerParty>
<cac:Party>
<cac:PartyIdentification>
<cbc:ID schemeID="0210">01598570354</cbc:ID>
</cac:PartyIdentification>
<cac:PartyName>
<cbc:Name>Information services</cbc:Name>
</cac:PartyName>
</cac:Party>
</cac:OriginatorCustomerParty>7.1.4. AccountingCustomerParty (Invoicee)
The invoicee is the legal person or organization acting on behalf of the customer and who receives the invoice for the order. The invoicee information is optional in the Peppol BIS Order Agreement message.
<cac:AccountingCustomerParty>
<cac:Party>
<cac:PartyIdentification>
<cbc:ID schemeID="0211">IT01234567890</cbc:ID>
</cac:PartyIdentification>
<cac:PartyName>
<cbc:Name>Information services</cbc:Name>
</cac:PartyName>
</cac:Party>
</cac:AccountingCustomerParty>7.2. Delivery
Delivery gives information on when and where the goods and services are delivered.
-
Delivery location (
cac:Delivery/cac:DeliveryTerms/cac:DeliveryLocation) is where the supplier leaves the packages. -
Delivery party (
cac:Delivery/cac:DeliveryParty) is the party who will get the ordered items.
Delivery special terms may be used to inform how the the goods or service is delivered. E.g.
-
A ticket may be delivered as a pdf in mail - “Mail”.
-
Goods may have been collected at the store – “Customer pick up“
The delivery information is optional in the Peppol BIS Order Agreement message.
<cac:Delivery>
<cac:PromisedDeliveryPeriod>
<cbc:StartDate>2016-08-20</cbc:StartDate>
<cbc:StartTime>12:00:00</cbc:StartTime>
<cbc:EndDate>2016-08-30</cbc:EndDate>
<cbc:EndTime>18:00:00</cbc:EndTime>
</cac:PromisedDeliveryPeriod>
<cac:DeliveryParty>
<cac:PartyIdentification>
<cbc:ID schemeID="0211">IT01234567890</cbc:ID>
</cac:PartyIdentification>
<cac:PartyName>
<cbc:Name>Delivery party name</cbc:Name>
</cac:PartyName>
</cac:DeliveryParty>
</cac:Delivery>
<cac:DeliveryTerms>
<cbc:ID>1</cbc:ID>
<cbc:SpecialTerms>Il cliente ritira la merce</cbc:SpecialTerms>
</cac:DeliveryTerms>7.2.1. Delivery Location
Information about the delivery are necessary if the address differ from the one of the Party that send the order and if allows to provide more precise indications about the returns of goods (DeliveryTerms). The warehouse opening time needs to be inserted in the elements "AddressLine/Line" of segment "Address".
The delivery location is the location in which the provision of goods or services needs to happen. It is represented by the elements “Delivery/DeliveryLocation”.
If the delivery address is the Client’s institutional address to which a unique identifier has been associated, made available by the Seller, it is necessary to provide also this identifier, as shown by the followign example:
<cac:Delivery>
<cac:PromisedDeliveryPeriod>
<cbc:StartDate>2018-05-15</cbc:StartDate>
<cbc:EndDate>2018-05-15</cbc:EndDate>
</cac:PromisedDeliveryPeriod>
<cac:DeliveryParty>
<cac:PartyIdentification>
<cbc:IDschemeID="0201">AAFF33</cbc:ID>
</cac:PartyIdentification>
<cac:PartyName>
<cbc:Name>Centro Logistico Beni Sanit-Ecom Area 2</cbc:Name>
</cac:PartyName>
</cac:DeliveryParty>
</cac:Delivery>
<cac:DeliveryTerms>
<cbc:ID>PORTO FRANCO</cbc:ID>
<cac:DeliveryLocation>
<cbc:ID>CF-IdShipTo</cbc:ID>
<cac:Address>
<cbc:StreetName>Viale Ercolani, 4</cbc:StreetName>
<cbc:CityName>Bologna</cbc:CityName>
<cbc:PostalZone>40138</cbc:PostalZone>
<cbc:CountrySubentity>BO</cbc:CountrySubentity>
<cac:AddressLine>
<cbc:Line>Orario:Lunedì-Venerdì 8:00-13:00 - Sabato 8:00-12:00</cbc:Line>
</cac:AddressLine>
<cac:Country>
<cbc:IdentificationCode>IT</cbc:IdentificationCode>
</cac:Country>
</cac:Address>
</cac:DeliveryLocation>
</cac:DeliveryTerms>On the other hand, if the provision of goods and services must take place in a non-institutional location or institutional location not coded (even temporarily), it is necessary to indicate precisely all the elements and sub-information inside de segment “Address”, as shown by the following example:
<cac:DeliveryTerms>
<cac:DeliveryLocation>
<cbc:ID>Entrata magazzino merci</cbc:ID>
<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:CountrySbentity>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:DeliveryTerms>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:
<cac:Delivery>
<cac:DeliveryLocation>
<cbc:ID>Consegna domiciliare</cbc: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:CountrySbentity>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.2.2. Delivery Party
If the delivery party, the party to whom the goods are delivered, is a determined subject, it is necessary to indicate it with precisely by valorizing the fields of the element cac:DeliveryParty.
The indication of the Deliver party is possible only with the reference to the whole Document.
The following example describes a delivery to a particular organizational unit:
<cac:Delivery>
<cac:DeliveryParty>
<cac:PartyIdentification>
<cbc:ID>UO07</cbc:ID>
</cac:PartyIdentification>
<cac:PartyName>
<cbc:Name>Centro logistico</cbc:Name>
</cac:PartyName>
</cac:DeliveryParty>
</cac:Delivery>When the "Beneficiary" needs to be indicated, the identifier (field “ID”) and denomination (field “Name”) of the organizational unit are both mandatory. If the identifier is unknown or does not exist, it is sufficient to fill the element with the text “UO” (abbreviation for organizational unit).
If the Beneficiary is a natural person, it is necessary to balance the need of protecting their confidentiality with the necessity of giving complete and exhaustive information for the delivery. To this end:
-
if it is not strictly necessary to indicate the extended name of the Beneficiary, the field “Name” must be filled with “PF” (abbreviation for physical person).
-
if an identifier was assigned to the Beneficiary, this must be indicated into the field “ID”, otherwise even this must be filled with “PF”.
7.3. References
When sending the order agreement transaction the seller may include a reference that the buyers gave to him during the purchase. This reference can be of different nature and since it originates from the buyer it is understood by him.
<cbc:CustomerReference>Buyer reference id</cbc:CustomerReference>7.3.1. Reference to another Order Agreement
In the case of Connected Order Agreement, Revocation Order Agreement or Replacement Order Agreement, it is necessary to indicate the so-called "Identification triple"(in italian Tripletta di identificazione) of the related Order Agreement in the elemement cac:OrderReference/cbc:ID, which is a structured field, by concatenating the following information in the order that follows:
-
ID, the identifier of the Order Agreement which this Order refers;
-
IssueDate, valorized with the date of the Order Agreement which this Order refers;
-
EndpointID of the element “SellerCustomerParty/Party” of the Order Agreement which this Order refers;
-
the status to be assigned to the Order Agreement, which can be:
-
“Connected”, for connection;
-
“Cancelled”, for the revocation;
-
“Revised”, for the replacement.
-
<cac:OrderReference>
<cbc:ID>110#2018-01-30#aaaaaa#Connected</cbc:ID>
</cac:OrderReference>|
The |
7.3.2. Example of Initial Order Agreement, Replacement Order Agreement and Revocation Order Agreement
Case 1: Initial Order Agreement
The right to issue an Order Agreement may result from a contract or another document (for example, an order sent via fax or e-mail, due to unavailability of the informatic system that issues the electronic orders), with which the Buyer has pre-authorized the Seller to issue the Order Agreement.
On the 30/1/2018, the Company “C” sends to the Entity “A” an Order Agreement with the identifier “110”. The Document refers to a contract with “exclusive right”, therefore is free from the CIG (Codice Identificativo Gara).
<cbc:CustomizationID>urn:fdc:peppol.eu:poacc:trns:order_agreement:3:restrictive:urn:www.agid.gov.it:trns:ordine_preconcordato:3.0<cbc:CustomizationID>
<cbc:ProfileID>urn:fdc:peppol.eu:poacc:bis:order_agreement:3</cbc:ProfileID>
<cbc:ID>110</cbc:ID>
<cbc:IssueDate>2018-01-30<cbc:IssueDate>
…
<cac:OrderReference>
<cbc:ID>0</cbc:ID>
</cac:OrderReference>
…
<cac:OriginatorDocumentReference>
<cbc:ID>ES07</cbc:ID>
</cac:OriginatorDocumentReference>
…
<cac:SellerSupplierParty>
<cac:Party>
<cbc:EndpointID schemeID=”0211”>IT02188520544</cbc:EndpointID>
</cac:Party>
</cac:SellerSupplierParty>
…
<cac:BuyerCustomerParty>
<cac:Party>
<cbc:EndpointID schemeID=”0201”>ABCDEF</cbc:EndpointID>
</cac:Party>
</cac:BuyerCustomerParty>
…Case 2: Replacement Order Agreement
In this example the Seller wants to modify the Order Agreement already transmitted, therefore sends a Replacement Order Agreement.
The Replacement Order AgreementL’Ordine pre-concordato replace both the Order Agreement indicated in the Document and all the other Replacements and Revocations made and already transmitted, related to the same Initial Order Agreement. In addition, it starts a new ordering process.
On the 15/2/2018, Company “C” sends to the Entity “A” the Replacement Order Agreement n. “250”, that replace the Order Agreement n. “110”, because there was quanto era stato erroneamente indicata l’esenzione dal CIG. Il CIG corretto è “1234567889B”.
<cbc:CustomizationID>urn:fdc:peppol.eu:poacc:trns:order_agreement:3:restrictive:urn:www.agid.gov.it:trns:ordine_preconcordato:3.0<cbc:CustomizationID>
<cbc:ProfileID>urn:fdc:peppol.eu:poacc:bis:order_agreement:3</cbc:ProfileID>
<cbc:ID>250</cbc:ID>
<cbc:IssueDate>2018-02-15<cbc:IssueDate>
…
<cac:OrderReference>
<cbc:ID>110#2018-01-30#IT02188520544#Revised</cbc:ID>
</cac:OrderReference>
…
<cac:OriginatorDocumentReference>
<cbc:ID>1234567889B</cbc:ID>
</cac:OriginatorDocumentReference>
…
<cac:SellerSupplierParty>
<cac:Party>
<cbc:EndpointID schemeID=”0211”>IT02188520544</cbc:EndpointID>
</cac:Party>
</cac:SellerSupplierParty>
…
<cac:BuyerCustomerParty>
<cac:Party>
<cbc:EndpointID schemeID=”0201”>ABCDEF</cbc:EndpointID>
</cac:Party>
</cac:BuyerCustomerParty>
…Case 3: Revocation Order Agreement
At a later time, Company “C” needs to revoke the Order Agreement previously issued, thus sends a Revocation Order Agreement.
The Revocation Order Agreement revokes both the Order Agreement indicated in the Document and all the other Replacements and Revocations made and already transmitted, related to the same Initial Order Agreement.
On the 15/3/2018 the Company “C” sends to the Entity “A” the Revocation Order Agreement n. “300”, which nullifies the Order Agreement n. “250”.
<cbc:CustomizationID>urn:fdc:peppol.eu:poacc:trns:order_agreement:3:restrictive:urn:www.agid.gov.it:trns:ordine_preconcordato:3.0<cbc:CustomizationID>
<cbc:ProfileID>urn:fdc:peppol.eu:poacc:bis:order_agreement:3</cbc:ProfileID>
<cbc:ID>300</cbc:ID>
<cbc:IssueDate>2018-03-15<cbc:IssueDate>
…
<cac:OrderReference>
<cbc:ID>250#2018-02-15#IT02188520544#Cancelled</cbc:ID>
</cac:OrderReference>
…
<cac:OriginatorDocumentReference>
<cbc:ID>1234567889B</cbc:ID>
</cac:OriginatorDocumentReference>
…
<cac:SellerSupplierParty>
<cac:Party>
<cbc:EndpointID schemeID=”0211”>IT02188520544</cbc:EndpointID>
</cac:Party>
</cac:SellerSupplierParty>
…
<cac:BuyerCustomerParty>
<cac:Party>
<cbc:EndpointID schemeID=”0201”>ABCDEF</cbc:EndpointID>
</cac:Party>
</cac:BuyerCustomerParty>
…7.3.3. CIG (Originator document reference)
In public procurement there may be different referenced document needed for identifying a provision of good and services; to provide the details at the document or line level it is necessary to specify the identifier of the document.
In "Initial Order Agreement" and "Replacement Order Agreement" is mandatory to indicate the Codice Identificativo Gara (CIG or Smart CIG), registered in the "Banca dati Nazionale dei contratti pubblici" (BDNCP), related to the object of the Document.
| Reference | Description | Use |
|---|---|---|
CIG |
Tender identification code |
At document level At line level |
<cac:OriginatorDocumentReference>
<cbc:ID>1Z1A3EE456</cbc:ID>
</cac:OriginatorDocumentReference>In the exclusion cases, according to the current legislation, in the place of CIG value it needs to be utilised one of the codes present in the coelist "Esclusioni CIG (IT)", available in the section CODELIST. The reason of the exclusion is indicated by inserting the specific code.
<cac:OriginatorDocumentReference>
<cbc:ID>ES12</cbc:ID>
</cac:OriginatorDocumentReference><cac:OrderLine>
<cac:LineItem>
<cac:Item>
...
<cac:ItemSpecificationDocumentReference>
<cbc:Id>CIG:1Z1A3EE456</cbc:Id>
</cac:ItemSpecificationDocumentReference>
...
</cac:Item>
</cac:LineItem>
</cac:OrderLine>|
In the event that the CIG is provided at the line level, no other Document can be indicated int the cac:ItemSpecificationDocumentReference (see next par.). |
7.3.4. Other references
To provide the ID of CUP, Despatch Advice, Expenditure Commitment, Expenditure Deliberation, Contract and Framework Agreement see the table below.
Even though at document level can be provided one or more references to several documents (cardinality 0..n), at line level it is not possible to indicate more than one Document (cardinality 0..1).
| Reference | Description | Use |
|---|---|---|
CUP |
Unique Project Reference (Codice Unico di Progetto) |
At document level At line level |
DDT |
Despatch Advice ID (Documento di Trasporto) |
At document level At line level Use it only to refer to Despatch Advice previously received during a goods deposit account |
IMPEGNO |
Expenditure Commitment ID |
At document level At line level |
DELIBERA |
Expenditure Deliberation ID |
At document level At line level |
CONTRATTO |
Contract ID |
At document level At line level use |
CONVENZIONE |
Framework Agreement ID |
At document level At line level |
<cac:AdditionalDocumentReference>
<cbc:ID>J31E01000010004</cbc:ID>
<cbc:DocumentType>CUP</cbc:DocumentType>
</cac:AdditionalDocumentReference><cac:OrderLine>
<cac:LineItem>
<cac:Item>
...
<cac:ItemSpecificationDocumentReference>
<cbc:Id>IMPEGNO:123/2019 </cbc:Id>
</cac:ItemSpecificationDocumentReference>
...
</cac:Item>
</cac:LineItem>
</cac:OrderLine>| The elements "AdditionalDocumentReference/ID" and "ItemSpecificationDocumentReference/ID" are structured fields. |
7.4. Attachments on header level
Non-XML documents can be sent as attachments to the Peppol BIS Order Agreement. This could be time sheets or other documents relevant for the order agreement. 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.
| Attachments should be used for additional information and not as order copies. |
Valid values (i.e. compatible with con NSO) are listed and highlighted in the codelist Mime code.
<cac:AdditionalDocumentReference>
<cbc:ID>ID documento</cbc:ID>
<cbc:DocumentType>Descrizione documento</cbc:DocumentType>
<cac:Attachment>
<cbc:EmbeddedDocumentBinaryObject mimeCode="application/pdf" filename="file.pdf">UjBsR09EbGhjZ0dTQUxNQUFBUUNBRU1tQ1p0dU1GUXhEUzhi</cbc:EmbeddedDocumentBinaryObject>
</cac:Attachment>
</cac:AdditionalDocumentReference>In the event of goods and services orders that to be processed require necessarily the presence of certain documents (ex. Patient Cars), it is necessary that these documents need to be trasmitted through NSO as an attached PDF to the electronic order.
Where the information contained in the attachments may involve privacy issues, these attachments can be in encrypted form or it is possible to use the element cac:ExternalReference, which access can be limited to appropriate profiling.
7.5. Attachments and document references on line level
Non-XML documents can be sent as attachments to the Peppol BIS Order Agreement on line level. This could comprise item specifications, time sheets or other documents relevant for the particular line in the order agreement. See the above information regarding attachments.
<cac:ItemSpecificationDocumentReference>
<cbc:ID>ID documento</cbc:ID>
<cbc:DocumentType>Descrizione documento</cbc:DocumentType>
<cac:Attachment>
<cbc:EmbeddedDocumentBinaryObject mimeCode="application/pdf" filename="specs.pdf">UjBsR09EbGhjZ0dTQUxNQUFBUUNBRU1tQ1p0dU1GUXhEUzhi</cbc:EmbeddedDocumentBinaryObject>
</cac:Attachment>
</cac:ItemSpecificationDocumentReference><cac:ItemSpecificationDocumentReference>
<cbc:ID>ID documento</cbc:ID>
<cbc:DocumentType>Descrizione documento</cbc:DocumentType>
<cac:Attachment>
<cac:ExternalReference>
<cbc:URI>https://joinup.ec.europa.eu/svn/peppol/PostAward/Ordering28A/20160310%20-%20PEPPOL_BIS_28a-101.pdf</cbc:URI>
</cac:ExternalReference>
</cac:Attachment>
</cac:ItemSpecificationDocumentReference>7.6. Product identification
Product identification may be done using the identifiers described below:
-
the code assigned by the Sellet (
cac:SellersItemIdentification/CBC:ID); -
the code assigned by the Buyer (
cac:BuyersItemIdentification/cbc:ID); -
the standard code, corresponding to the identifier assigned to the prduct by a unique identifier system (
cac:StandardItemIdentification/cbc:ID) selected among them present in the appropriate Peppol codelist "ISO 6523 ICD list".
The order agreement requires that an item has an identifier. This can be either the sellers identifier or a standard identifier. Which identifier to use depends on what is known at the time of the purchase or what is commonly used in the relevant business sector.
<cac:SellersItemIdentification>
<cbc:ID>123</cbc:ID>
</cac:SellersItemIdentification>
<cac:StandardItemIdentification>
<cbc:ID schemeID="0160">73123456001233</cbc:ID>
</cac:StandardItemIdentification>7.6.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:".
<cac:OrderLine>
<cac:LineItem>
...
<cac:Item>
<cbc:Description>NORVASC*5MG 28CPR</cbc:Description>
<cbc:Name>NORVASC</cbc:Name>
<cac:SellersItemIdentification>
<cbc:ID>AICFARMACO:027428010</cbc:ID>
</cac:SellersItemIdentification>
<cac:CommodityClassification>
<cbc:ItemClassificationCode listID="STL" listIVersionID="UNCL7143">C08CA01</cbc:ItemClassificationCode>
</cac:CommodityClassification>
</cac:Item>
</cac:LineItem>
</cac:OrderLine>|
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:”. |
7.6.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:".
<cac:OrderLine>
<cac:LineItem>
...
<cac:Item>
<cbc:Name>Nome articolo</cbc:Name>
<cac:SellersItemIdentification>
<cbc:ID>UDI:(01)47964367965424(11)173434(17)226565(10)A379B3(21)1237</cbc:ID>
</cac:SellersItemIdentification>
</cac:Item>
</cac:OrderLine>7.6.3. Type of fuel
The type of fuel through the use the element cac:SellersItemIdentification/cbc:ID in which is entered the value of the reference table for energetic products TA13, published on the Agenzia delle Dogane’s website, prefixed by the string “CARB:”.
<cac:OrderLine>
<cac:LineItem>
...
<cac:Item>
<cbc:Name>Benzina senza piombo, ottani>=98</cbc:Name>
<cac:SellersItemIdentification>
<cbc:ID>CARB:27101249</cbc:ID>
</cac:SellersItemIdentification>
<cac:ClassifiedTaxCategory>
<cbc:ID>S</cbc:ID>
<cbc:Percent>22</cbc:Percent>
<cac:TaxScheme>
<cbc:ID>VAT</cbc:ID>
</cac:TaxScheme>
</cac:ClassifiedTaxCategory>
</cac:Item>
</cac:LineItem>
</cac:OrderLine>7.7. Product name and description
The Product name must be sent in the element cac:Item/cbc:Name on line level. Description of a product can be sent in cac:Item/cbc:Description.
The Product name is often sent in the order agreement from the buyer to the seller.
<cac:Item>
<cbc:Description>Descrizione</cbc:Description>
<cbc:Name>Salviette per bambini</cbc:Name>
…
</cac:Item>7.8. Item labelling
Information about the items environmental, social, ethical and quality type of labelling can be provided through the segment cac:Certificate. The UBL structure used for item labeling requires certain elements in addition to those used by this BIS. To fulfill the UBL requirements these are included with the dummy value NA.
<cac:Certificate>
<cbc:ID>EU Ecolabel</cbc:ID>
<cbc:CertificateTypeCode>NA</cbc:CertificateTypeCode>
<cbc:CertificateType>Environmental</cbc:CertificateType>
<cbc:Remarks>Item label value</cbc:Remarks>
<cac:IssuerParty>
<cac:PartyName>
<cbc:Name>NA</cbc:Name>
</cac:PartyName>
</cac:IssuerParty>
<cac:DocumentReference>
<cbc:ID>Item label reference</cbc:ID>
</cac:DocumentReference>
</cac:Certificate>7.9. Contracted item
If the purchased item is offered in accordance to an existing contract, this should be indicated in the order agreement message.
<cac:TransactionConditions>
<cbc:ActionCode>CT</cbc:ActionCode>
</cac:TransactionConditions>7.10. Classification
For each product, inside the related order 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' codes on separated order lines. |
<cac:OrderLine>
<cac:LineItem>
<cbc:ID>1</cbc:ID>
...
<cac:Item>
...
<cac:CommodityClassification>
<cbc:ItemClassificationCode listID="STL">N05BA01</cbc:ItemClassificationCode>
</cac:CommodityClassification>
</cac:Item>
</cac:LineItem>
</cac:OrderLine>An item may be classified according to UNSPSC being the mandatory public classification schemes in some countries/sectors. As there is currently no code for UNSPSC in the used code list UNCL 7143, the code "MP" (Product/service identification number) is used. Products can also be classified according to regulatory schemes or classification schemes used in certain business sectors.
<cac:CommodityClassification>
<cbc:ItemClassificationCode listID="MP" listVersionID="20.0601">14111511</cbc:ItemClassificationCode>
</cac:CommodityClassification>7.10.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"
<cac:OrderLine>
<cac:LineItem>
...
<cac:Item>
<cbc:Description>Descrizione del dispositivo</cbc:Description>
<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>
</cac:LineItem>
</cac:OrderLine>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".
7.11. Quantities and units
Various Quantities and Units can be stated in the Peppol BIS Order Agreement. These are both related to the ordering process and the logistics process.
The table below lists quantities and units in the format. To all quantities there must be a valid Unit of measure according to the Code list.
| Element name / (Tag name) | Description |
|---|---|
Price Quantity / (BaseQuantity) |
Quantity related to Price. |
Order Quantity / (Quantity) |
Quantity that is ordered, e.g. number of pieces or volume in litre . |
<cac:OrderLine>
<cac:LineItem>
<cbc:ID>1</cbc:ID>
<cbc:Note>Line note</cbc:Note>
<cbc:Quantity unitCode="C62">120</cbc:Quantity>
<cbc:LineExtensionAmount currencyID="EUR">500</cbc:LineExtensionAmount>
<cac:Price>
<cbc:PriceAmount currencyID="EUR">50</cbc:PriceAmount>
<cbc:BaseQuantity unitCode="C62">12</cbc:BaseQuantity>
</cac:Price>
...
</cac:LineItem>
</cac:OrderLine>7.12. Prices
Prices must be exchanged in the Order Agreement transaction. The price may be 0 (zero)
Price sent is related to the articles or services within this order agreement
Prices includes allowances and/or charges but exclude VAT amounts
<cac:Price>
<cbc:PriceAmount currencyID="EUR">50</cbc:PriceAmount>
<cbc:BaseQuantity unitCode="C62">1</cbc:BaseQuantity>
</cac:Price>7.13. Allowances and Charges
The order agreement transaction has Allowance/charge on header level.
The element cac:AllowanceCharge with sub element cbc:ChargeIndicator indicates whether the instance is a charge (true) or an allowance (false).
Information on allowance and/or charges applies to the whole order agreement and is included in the calculation of the order agreement total amount.
-
Several allowances and charges may be supplied
-
Specification of VAT for allowances and charges,
cac:TaxCategorywith sub elements, shall be supplied -
The sum of all allowances and charges on the header level shall be specified in
cbc:AllowanceTotalAmountandcbc:ChargeTotalAmountrespectively. See Calculation of totals
Calculation of allowance/charge amount
Allowance and charge on document level consists of elements carrying information on the allowance/charge base amount and the allowance/charge percentage. These are, if present in the invoice instance, used for calculating the allowance/charge amount.
If base amount is present, the percentage shall also be present, and if percentage is present, the base amount shall also be present, and the calculation of the amount shall be:
\$"Amount" = "Base amount" times ("Percentage" div 100)\$
<cac:AllowanceCharge>
<cbc:ChargeIndicator>true</cbc:ChargeIndicator>(1)
<cbc:AllowanceChargeReasonCode>FC</cbc:AllowanceChargeReasonCode>
<cbc:AllowanceChargeReason>Servizio di Trasporto</cbc:AllowanceChargeReason>
<cbc:MultiplierFactorNumeric>2</cbc:MultiplierFactorNumeric>(4)
<cbc:Amount currencyID="EUR">20</cbc:Amount> (5)
<cbc:BaseAmount currencyID="EUR">1000</cbc:BaseAmount>(3)
<cac:TaxCategory>
<cbc:ID>S</cbc:ID>
<cbc:Percent>23.6</cbc:Percent>
<cac:TaxScheme>
<cbc:ID>VAT</cbc:ID>
</cac:TaxScheme>
</cac:TaxCategory>
</cac:AllowanceCharge>
<cac:AllowanceCharge>
<cbc:ChargeIndicator>false</cbc:ChargeIndicator>(2)
<cbc:AllowanceChargeReasonCode>65</cbc:AllowanceChargeReasonCode>
<cbc:AllowanceChargeReason>Production error discount</cbc:AllowanceChargeReason>
<cbc:Amount currencyID="EUR">10</cbc:Amount>
<cac:TaxCategory>
<cbc:ID>S</cbc:ID>
<cbc:Percent>23.6</cbc:Percent>
<cac:TaxScheme>
<cbc:ID>VAT</cbc:ID>
</cac:TaxScheme>
</cac:TaxCategory>
</cac:AllowanceCharge>| 1 | ChargeIndicator = true to indicate a charge |
| 2 | ChargeIndicator = false to indicate an allowance |
| 3 | Base amount, to be used with the percentage to calculate the amount |
| 4 | Charge percentage |
| 5 | \$"Amount" = "Base amount" times ("Percentage" div 100)\$ |
<cac:AllowanceCharge>
<cbc:ChargeIndicator>true</cbc:ChargeIndicator>
<cbc:AllowanceChargeReasonCode>ABL</cbc:AllowanceChargeReasonCode>
<cbc:AllowanceChargeReason>Costi diimballaggio</cbc:AllowanceChargeReason>
<cbc:MultiplierFactorNumeric>20</cbc:MultiplierFactorNumeric>
<cbc:Amount currencyID="EUR">10.00</cbc:Amount>
<cbc:BaseAmount currencyID="EUR">50.00</cbc:BaseAmount>
</cac:AllowanceCharge><cac:AllowanceCharge>
<cbc:ChargeIndicator>false</cbc:ChargeIndicator>
<cbc:AllowanceChargeReasonCode>41</cbc:AllowanceChargeReasonCode>
<cbc:AllowanceChargeReason>Sconto</cbc:AllowanceChargeReason>
<cbc:MultiplierFactorNumeric>2</cbc:MultiplierFactorNumeric>
<cbc:Amount currencyID="EUR">2.00</cbc:Amount>
<cbc:BaseAmount currencyID="EUR">100.00</cbc:BaseAmount>
</cac:AllowanceCharge>7.13.1. Allowance and charges on price
The following example shows an allowance of 10 EUR applied to the base amount price:
<cac:OrderLine>
<cac:LineItem>
<cbc:ID>1</cbc:ID>
<cbc:Quantity unitCode="C62" unitCodeListID="UNECERec20">20</cbc:Quantity>
<cbc:LineExtensionAmount currencyID="EUR">1800.00</cbc:LineExtensionAmount>
<cac:Price>
<cbc:PriceAmount currencyID="EUR">90.00</cbc:PriceAmount>
<cac:AllowanceCharge>
<cbc:ChargeIndicator>false</cbc:ChargeIndicator>
<cbc:Amount currencyID="EUR">10.00</cbc:Amount>
<cbc:BaseAmount currencyID="EUR">100.00</cbc:BaseAmount>
</cac:AllowanceCharge>
</cac:Price>
...
</cac:LineItem>
</cac:OrderLine>7.13.2. Free items
To include free items in the order it is necessary to indicate them on a different line than paid items and also to indicate both the line amount and the price equal to 0 (zero).
<cac:Orderline>
<cac:LineItem>
<cbc:ID>1</cbc:ID>
<cbc:Quantity unitCode="C62" unitCodeListID=”UNECERec20”>20</cbc:Quantity>
<cbc:LineExtensionAmount currencyID="EUR">0</cbc:LineExtensionAmount>
<cac:Price>
<cbc:PriceAmount currencyID="EUR">0</cbc:PriceAmount>
<cbc:BaseQuantity unitCode="C62" unitCodeListID=”UNECERec20”>1</cbc:BaseQuantity>
<cac:AllowanceCharge>
<cbc:ChargeIndicator>false</cbc:ChargeIndicator>
<cbc:Amount currencyID="EUR">5.00</cbc:Amount>
<cbc:BaseAmount currencyID="EUR">5.00</cbc:BaseAmount>
</cac:AllowanceCharge>
</cac:Price>
<cac:Item>
<cbc:Description>1x12 pacchi</cbc:Description>
<cbc:Name>Striscie per glucosio</cbc:Name>
<cac:SellersItemIdentification>
<cbc:ID>79847-E</cbc:ID>
</cac:SellersItemIdentification>
<cac:ClassifiedTaxCategory>
<cbc:ID>S</cbc:ID>
<cbc:Percent>22</cbc:Percent></cac:Item>
<cac:TaxScheme>
<cbc:ID>VAT</cbc:ID>
</cac:TaxScheme>
</cac:ClassifiedTaxCategory>
</cac:Item>
</cac:LineItem>
</cac:OrderLine>7.14. Information about taxes
The follwing paragrapghs describe several information about taxes that can be provided with this BIS. "Tax" refers to VAT (IVA in Italy), GST or Sales Tax, according to the field of application.
Please also see UNCL5305 for details on the TAX category code list, and Total TAX amount for detailed explanation and example on how to perform the calculations for TAX Breakdown.
7.14.1. Line TAX Category
TAX information on line level is provided in the class cac:ClassifiedTaxCategory.
Each line may have the item TAX information including category code and percentage.
<cac:ClassifiedTaxCategory>
<cbc:ID>S</cbc:ID> (1)
<cbc:Percent>18</cbc:Percent>(2)
<cac:TaxScheme>
<cbc:ID>VAT</cbc:ID>(3)
</cac:TaxScheme>
</cac:ClassifiedTaxCategory>| 1 | TAX category according to Codelist UNCL5305 |
| 2 | TAX percentage. |
| 3 | Value must identify the correct tax type. For example VAT, GST or sales tax. |
7.14.2. TAX info for allowance or charge
Document level allowance/charge is stated using the UBL element cac:AllowanceCharge. Further details on allowance and charge can be found in Allowances and Charges.
Each document level charge or allowance must have the Document level allowance or charge TAX category code, and for all TAX categories except when tax category indicates that the invoice is not subject to TAX (e.g. (O) in EU), then the TAX rate shall be provided.
<cac:AllowanceCharge>
<cbc:ChargeIndicator>true</cbc:ChargeIndicator>
<cbc:AllowanceChargeReason>Packing cost</cbc:AllowanceChargeReason>
<cbc:Amount currencyID="EUR">200</cbc:Amount>
<cac:TaxCategory>(1)
<cbc:ID>S</cbc:ID>(2)
<cbc:Percent>23.6</cbc:Percent>(3)
<cac:TaxScheme>
<cbc:ID>VAT</cbc:ID>
</cac:TaxScheme>
</cac:TaxCategory>
</cac:AllowanceCharge>| 1 | The class cac:TaxCategory is used for tax category information |
| 2 | TAX category according to codelist UNCL5305 |
| 3 | TAX rate |
7.15. Indications for particular Order Agreement
7.15.1. Order for Evaluation and Order for Billing products already consumed and Restoration
Order Agreements with typology 227 for "Order for Evaluation" (CV) and Order Agreements with typology 220 of "Order for Billing products already consumed and Restoration" (OFR) provide that the issuance of the order takes place after the delivery and the use of the goods provided.+
Therefore, in this orders it is mandatory to specify the references to Lot, Serial number and DDT number of the delivery concerning the item used.
Example:
<cac:OrderLine>
<cac:LineItem>
<cac:Item>
...
<cac:ItemSpecificationDocumentReference>
<cbc:Id>DDT:123</cbc:Id>
</cac:ItemSpecificationDocumentReference>
...
</cac:Item>
</cac:LineItem>
</cac:OrderLine>7.15.2. Orders of Kit with predefined or variables components
The components of a KIT (generally implantable medical devices) can be predefined (defined in the price list by the Seller and always used together) or variables (in the Seller’s price list are indicated those that can be requested). Typically there is an item number for the KIT and one for each component of the KIT.
In orders the Item can be "defined" in the terms of KIT or component.
Example of an Item defined in terms of KIT
Seller’s item number for a "KIT" (e.g. “KITCARTO9”); detail of the compnents of the KIT using one or more "AdditionalItemProperty" (not mandatory, cardinality 0-n) in this way:
-
Name = Component;
-
Value = ID KIT’s component (example: “34A35M”, “34N01M”, …)
It is possibile to use the unit of measure that describes a KIT:
<cac:OrderLine>
<cac:LineItem>
<cbc:ID>1</cbc:ID>
<cbc:Quantity unitCode="KT">10</cbc:Quantity>
<cbc:LineExtensionAmount currencyID="EUR">1000.00</cbc:LineExtensionAmount>
<cac:Price>
<cbc:PriceAmount currencyID="EUR">100.00000</cbc:PriceAmount>
<cbc:BaseQuantity unitCode="C62">1</cbc:BaseQuantity>
</cac:Price>
<cac:Item>
<cbc:Name>KIT</cbc:Name>
<cac:SellersItemIdentification>
<cbc:ID>KITCARTO9</cbc:ID>
<!-- ID KIT -->
</cac:SellersItemIdentification>
<cac:AdditionalItemProperty>
<cbc:Name>Componente</cbc:Name>
<cbc:Value>KITCARTO9</cbc:Value>
</cac:AdditionalItemProperty>
<cac:AdditionalItemProperty>
<cbc:Name>Componente</cbc:Name>
<cbc:Value>34N01M</cbc:Value>
</cac:AdditionalItemProperty>
</cac:Item>
</cac:LineItem>
</cac:OrderLine>Example of an item defined in terms of "Component of a KIT"
Seller’s item number for a "Component" (e.g. NAVI-STAR 34A35M); reference to the KIT to which it belongs using the element "AdditionalItemProperty" (not mandatory, cardinality 0-n) in this way:
-
Name = KIT;
-
Value = ID KIT (example: “KITCARTO9”)
It is possibleto use the unit of measure that describes a component (part): C62
It is possibile to use the unit of measure that describes a KIT:
<cac:OrderLine>
<cac:LineItem>
<cbc:ID>1</cbc:ID>
<cbc:Quantity unitCode="C62">10</cbc:Quantity>
<cbc:LineExtensionAmount currencyID="EUR">100.00</cbc:LineExtensionAmount>
<cac:Price>
<cbc:PriceAmount currencyID="EUR">10.00000</cbc:PriceAmount>
<cbc:BaseQuantity unitCode="C62">1</cbc:BaseQuantity>
</cac:Price>
<cac:Item>
<cbc:Name>Articolo Componente</cbc:Name>
<cac:SellersItemIdentification>
<cbc:ID>NAVI-STAR 34A35M</cbc:ID>
<!-- ID Componente -->
</cac:SellersItemIdentification>
<cac:AdditionalItemProperty>
<cbc:Name>KIT</cbc:Name>
<cbc:Value>34A35M</cbc:Value>
</cac:AdditionalItemProperty>
</cac:Item>
</cac:LineItem>
</cac:OrderLine>7.16. Additional Item Property
It is possible to indicate further information about products on the order lines, by using the element cac:AdditionalItemProperty, compiled as follows:
-
in the “Name” field needs to be reported the "type of information”, by selecting it among those present in the tables of the paragraphs below;
-
in the “Value” field needs to be reported the value of the information.
7.16.1. 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.
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:OrderLine>
<cac:LineItem>
<!-- 5000 guanti -->
<cbc:ID>1<cbc:ID>
<cbc:Quantity unitCode="C62">5000</cbc:Quantity>
<cbc:LineExtensionAmount currencyID="EUR">500.00</cbc:LineExtensionAmount>
<cac:Price>
<!-- Prezzo singolo guanto -->
<cbc:PriceAmount currencyID="EUR">0.10000</cbc:PriceAmount>
<cbc:BaseQuantity unitCode="C62">1</cbc:BaseQuantity>
</cac:Price>
<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:Item>
</cac:LineItem>
</cac:OrderLine>Case 2: Ordered item by package
This is an example in which the item is ordered by package:
<cac:OrderLine>
<cac:LineItem>
<!-- 10 confezioni di guanti -->
<cbc:ID>1<cbc:ID>
<cbc:Quantity unitCode="XPK"">10</cbc:Quantity>
<cbc:LineExtensionAmount currencyID="EUR">500.00</cbc:LineExtensionAmount>
<cac:Price>
<!-- Prezzo confezione -->
<cbc:PriceAmount currencyID="EUR">50.00000</cbc:PriceAmount>
<cbc:BaseQuantity unitCode="XPK">1</cbc:BaseQuantity>
</cac:Price>
<cac:Item>
<cbc:Name>CONFEZIONE GUANTI</cbc:Name>
<cac:SellersItemIdentification>
<!-- O altro identificativo (es. Standard) -->
<cbc:ID>XYZ500</cbc:ID>
</cac:SellersItemIdentification>
<cac:AdditionalItemProperty>
<!-- Un articolo (confezione) contiene 500 pezzi-->
<cbc:Name>PackQuantity</cbc:Name>
<cbc:Value>500</cbc:Value>
<cac:AdditionalItemProperty>
</cac:Item>
</cac:LineItem>
</cac:OrderLine>7.16.2. Calibration
The element cac:AdditionalItemProperty it is also used to provide the following information:
| Type of information | Description |
|---|---|
CalibrationDate |
It indicates the calibration date for Nuclear Medicine products |
<cac:OrderLine>
<cac:LineItem>
...
<cac:Item>
<cac:AdditionalItemProperty>
<cbc:Name>CalibrationDate</cbc:Name>
<cbc:Value>2025-05-15</cbc:Value>
</cac:AdditionalItemProperty >
</cac:Item>
</cac:LineItem>
</cac:OrderLine>7.17. Use of the elements "Note"
When there is the necessity to provide particular information, it is possible to valorize with free-form text the elementes “Note” present at various points of the Documents data’s schemes.
| As a general rule, it is recommended using the textual notes only if absolutely necessary and in absence of other elements that may contain the same information. |
8. Peppol Identifiers
Peppol has defined a Peppol Policy for identifiers, policy 8 that specifies how to use identifiers in both its transport infrastructure and within the documents exchanged across that infrastructure. It also introduces principles for any identifiers used in the Peppol environment. The policies that apply to this BIS are the following:
8.1. Profiles and messages
All messages contains ProfileID and CustomizationID. ProfileID identifies what business process a given message is part of, and CustomizationID identifies the kind of message and the rules applied.
Profiles are connected to one business process, and may contain multiple document types. Valid document instances shall contain corresponding ProfileID and CustomizationID.
| CustomizationID is a string without spaces. The list below contains spaces in CustomizationID to make them easier to read. Make sure to remove any spaces before use. |
8.2. Customization and Profile identifiers
In the table below you will find the values to be used as the specification identifier and the business process type for this profile
| Type | Element cbc:CustomizationID |
Element cbc:ProfileID |
|---|---|---|
Order Agreement (Trdm110) |
urn:fdc:peppol.eu:poacc:trns:order_agreement:3 :restrictive:urn:www.agid.gov.it:trns:ordine_preconcordato:3.0 |
urn:fdc:peppol.eu:poacc:bis:order_agreement:3 |
8.3. Namespaces
The order agreement data model is in this Peppol BIS bound to the UBL 2.1 of the order response document type UBL Order Response 2.1. The target namespace for the UBL-OrderResponse-2.1 is:
urn:oasis:names:specification:ubl:schema:xsd:OrderResponse-2
8.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.
<cbc:EndpointID schemeID="0201">ABCDEF</cbc:EndpointID><cbc:EndpointID schemeID="0210">07643520567</cbc:EndpointID><cbc:EndpointID schemeID="0211">IT07643520567</cbc:EndpointID><cbc:EndpointID schemeID="0088">5790000435968</cbc:EndpointID