BIS Ordering 3.3.0.8
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 28 Ordering” CEN BII2 Profile 28, Ordering.
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 and order response message in the European market, and to facilitate an efficient implementation and increased use of electronic collaboration regarding the ordering process based on these formats.
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 Ordering. It is based on the CEN BII2 Profile 28, Ordering
2.1. Scope
This BIS describes a process comprising a Buyer to issue an electronic order, whereby the Seller may accept the order, accept with changes or reject. In his rejection the Seller may indicate reasons, so the Buyer may issue a new order that may be acceptable. The Seller may accept the order with changes, only if in a previously concluded contract the scope of such changes was agreed. The order that is agreed upon by acceptance has the commercial and legal status of a contract.
The main activities supported by this profile are:
- Structured Ordering
-
The Order transaction should support the structured ordering of goods or services, using free text or use of identifiers. The information source of the ordered products may be a (paper or electronic) catalogue.
- Accounting
-
The ordering process must support the allocation of budgets, so the value amounts of the ordered products may be stated. The buyer may provide some information that the seller is required to place on the invoice for aiding and automation of invoice processing.
- Invoice Verification
-
The buyer may provide some information that the seller is required to place on the invoice for aiding and automation of invoice approval.
- TAX reporting
-
TAX reporting is not a general requirement on orders. In this context the term TAX is used as a generalization of taxes such as VAT, GST or Sales Tax. The level of support in orders is to
-
Enable TAX reporting in invoices by providing TAX number of buyer. As an example in case of reverse charges in EU.
-
TAX can be stated as an estimate to enable buyers to state expected value of order.
This can be helpful in automated matching of orders and invoices.
TAX information is informative and does not affect the terms of trade.
-
- Transport and delivery
-
Only limited support is in scope for transport related information, but it is recognized that the buyer needs to be able to provide some information about requested delivery location, some basic term, time and contact persons for a delivery of an order.
- Inventory
-
Supporting inventory management is not in scope, but structured orders based on catalogues can be used to automate picking at supplier warehouses.
2.2. 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 party, debtor, contracting authority, originator. |
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 |
The buyer is the legal person or organization acting on behalf of the customer and who buys or purchases the goods or services. |
Seller |
The seller is the legal person or organization acting on behalf of the supplier and who sells goods or services to the customer. |
Originator |
A person or unit that initiates an order. |
Invoicee |
A person or unit that receives the invoice (invoicee) on behalf of the customer. |
Consignee |
A location to where the seller, or a despatching party on behalf of the seller, delivers the goods. |
Delivery party |
A unit to where the consignee forwards the goods. A final delivery point. |
The following diagram links the business processes to the roles performed by the Business Partners.
2.2.1. Benefit
Based on success with automation of invoicing, there is a growing interest in automation of ordering also. This approach has two dimensions: Support further automation of invoicing and using structured catalogues as basis for ordering. Implementing this BIS is an important step for many companies and government agencies towards full procurement automation.
For the sellers, the approval, picking and invoicing can be automated significantly.
For the procuring agency, approval and accounting of invoices can be automated and ordering can be structured by use of catalogues.
Other potential benefits of using this BIS are, among others:
-
Can be used by procuring agencies as step towards automation of procurement. The flexibility of the specifications allows the buyers to gradually automate and structure ordering, based on a cost/benefit approach.
-
SME can offer their trading partners the option of exchanging standardized documents in a uniform way and thereby move all orders into electronic form.
-
Large companies can implement this BIS as standardized documents for general operations and implement custom designed bi-lateral connections for large trading partners.
-
Can be used as basis for restructuring of in-house processes of orders and invoices.
-
Significant saving can be realized by the procuring agency by automating and streamlining in-house processing.
-
Significant saving can be realized by the sellers by automating and streamlining in-house processing. Linking to picking and invoicing can be improved significantly based on increased order quality, restructuring of invoice dispute resolution and shorter payment cycles.
-
For the procuring agency, invoice automation and ordering can be structured.
2.3. Interoperability
This Peppol BIS structure is based on the European Interoperability Framework 2.0 EIF. This Peppol BIS applies the Framework as follows:
- Legal Interoperability
-
-
Legal:
-
In implementations supporting public sector buyers, the use of this BIS has to be monitored in order to secure that the parties 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 business 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 conforms 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 CEN WS/BII. These choices are intended to lower the implementation threshold by limiting options for implementers and thereby increase interoperability of Peppol 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
-
-
Technical Interaction (eSignature Validation):
-
Not mandatory in this Peppol BIS. Not supported.
-
-
3. Process and typical use cases
The Ordering process includes the sending of Orders from a Buyer to a Seller and the response of the Seller.
3.1. Process flow
The Ordering process flow can be described as follows:
-
A Buyer submits an Order to the Seller requesting for delivery of goods or services
-
An Order may refer to a framework agreement for its terms and conditions; otherwise the Buyer’s terms and conditions apply.
-
An Order may contain items (goods or services) with item identifiers or items with free text description.
-
The Seller may acknowledge that the order is received.
-
The Seller may accept the Order, committing himself to the conditions stated therein by means of an Order Response transaction.
-
Alternatively, the Seller may reject the Order by means of the Order Response transaction.
-
An order rejection may contain reasons for rejection.
-
If contractually agreed, the Seller also may respond to the order, changing details that are acceptable by the Buyer.
-
If an order is accepted with change, the buyer and seller need to have an agreement between them regarding the processing of the changed order, i.e when is a contract concluded and when can the items be shipped.
-
-
If the order was accepted a contract is concluded. If the order was rejected, no contract and no residual obligations exist.
-
After the receipt of an Order Response that rejects the order, the Buyer may start a new ordering process, taking into account the reasons for the rejection by the Seller.
3.2. Business processes requirements
As a result of the reception of an order, the Seller that must contain the indication of the Order previously sent, by which intends to communicate, alternatively, the following:
-
the Order has been received (Response of receipt);
-
the Order is accepted without amendment (Response of acceptance);
-
the Order is rejected (Response of denial);
-
the Order is accepted with amendment (Response with changes).
The Response with changes must contain all the Order lines, both those that are to be modified and maintained, since it is intended to supplement the related Order previously sent.
The Response to a revoked Order has no effect for the Buyer.
3.4. Use case 1 – Ordering of numbered items/articles
This use case contains an order of numbered items/articles.
| Use Case number | 1 |
|---|---|
Use Case Name |
Ordering of numbered items/articles |
Use Case Description |
|
Parties involved |
Buyer |
Assumptions |
The buyer has a catalogue or list of products to order. |
The flow |
The buyer creates the order with 3 different lines and items.
|
Result |
The buyer and the seller has reached an agreement. |
XML example file |
See section "Downloads" on Homepage. |
3.5. Use case 2 – Ordering of free text articles
This use case contains an order of free text articles.
| Use Case number | 2 |
|---|---|
Use Case Name |
Ordering of free text articles |
Use Case Description |
An order with item/articles described in free text and attribute/value pairs. |
Parties involved |
Buyer |
Assumptions |
The buyer does not have structured item information. |
The flow |
The buyer creates the order with 2 different lines and items.
|
Result |
The buyer and the seller has reached an agreement. |
XML example file |
See section "Downloads" on Homepage. |
3.6. Use case 3 – Ordering of services
This use case contains an order of services.
| Use Case number | 3 |
|---|---|
Use Case Name |
Ordering of services |
Use Case Description |
An order of translation services. |
Parties involved |
Buyer |
Assumptions |
The buyer is using a form with pre-defined and agreed properties for this service. |
The flow |
The buyer creates the order with one line requesting translation between Swedish and Spanish. |
Result |
The buyer and the seller has not reached any agreement. |
XML example file |
See section "Downloads" on Homepage. |
3.7. Use case 4 – Complex ordering
This use case contains an order with almost all elements in the order message used. The order is fully accepted by the seller.
| Use Case number | 4 |
|---|---|
Use Case Name |
Complex ordering |
Use Case Description |
An order for numbered items with allowance and charges both on order level, line level and price. |
Parties involved |
Buyer |
Assumptions |
The buyer has a catalogue or list of products to order. |
The flow |
The buyer creates the order with 4 different lines and items. |
Result |
The buyer and the seller has reached an agreement. |
XML example file |
See section "Downloads" on Homepage. |
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 transaction |
OrderReference/ID |
Order Response |
DeliveryTerms/SpecialTerms |
Order transaction |
AccountingCost |
Order transaction |
AdditionalDocumentReference/ID |
Order transaction |
ItemSpecificationDocumentReference/ID |
Order transaction |
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 6.12 and 7.1 for compilation rules.
| Type of Document | Sub-types | Variants |
|---|---|---|
Ordine (Order) |
Ordine inziale (Initial Order) |
- |
Ordine di revoca (Revocation Order) |
- |
|
Ordine sostitutivo (Replacement Order) |
- |
|
Ordine di riscontro (Confirmation Order) |
Confirmation Order to approve |
|
Confirmation Order to reject |
||
Confirmation Order to substitute |
||
Ordine collegato (Connected Order) |
- |
|
Ordine di convalida (Validation Order) |
- |
|
Risposta (Response) |
Risposta di ricezione (Response of receipt) |
- |
Risposta di accettazione (Response of acceptance) |
- |
|
Risposta di diniego (Response of denial) |
- |
|
Risposta con modifiche (Response with changes) |
- |
Revocation Order
For some circumstances, the revocation of a previosly issued Order may be useful.
The Revocation Order is an Order that contains the reference to the Order 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
Where appropriate, the instructions contain into an Order can be modified through the issuance of a Replacement Order. 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 is a new Order, complete with all the order lines and contains the reference to the Order 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, 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 must report the indication of the Order sub-type “OR”, (so-called “Regulating Order Replacement", see paragraph 4.4). |
See paragraph 6.12 for compilation rules.
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:ordering: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>Connected Order
For some circumstances, it may be useful to highlight that an Order, even though is indipendent, it is generically related to another Document.
In this cases the Connected Order is used, where it is present a reference to the linked Order and the indication “Connected”.
| The Connected Order 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, Replacement Order, Confirmation Order) specifically designed to revoke, substitute (or integrate), confirm or refuse another Document. |
See paragraph 6.12 for compilation rules.
Validation Order
The Validation Order is an Order in which there is a reference to an Invoice to be regularised and the indication that it’s a validation (“Invoice”).
This Order 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 must never be used in place of the others (i.e. Revocation Order, Replacement Order, Confirmation Order) specifically designed to revoke, substitute (or integrate), confirm or refuse another Document. |
In the case of Validation Order it is necessary to report the details of the Invoice to be validated in the element OrderDocumentReference/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:OrderDocumentReference>
<cbc:ID>57#2018-01-30#ITccccccccccc#Invoice</cbc:ID>
</cac:OrderDocumentReference>4.5. Order type
The type of order can be expressed using the following official codelists available in the UBL package.
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) |
||
221 |
Budgeting ordering |
- |
|
226 |
Adjustment ordering |
- |
|
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.
<cbc:OrderTypeCode>220</cbc:OrderTypeCode>
...
<cac:DeliveryTerms>
<cbc:SpecialTerms>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:OrderTypeCode>220</cbc:OrderTypeCode>
…
<cac:DeliveryTerms>
<cbc:SpecialTerms>ON</SpecialTerms>
</cac:DeliveryTerms>
…
<cac:PaymentTerms>
<cbc:Note>Pagamento in rate mensili</cbc:Note >
</cac:PaymentTerms>
…
<cac:OrderLine>
<cac:LineItem>
<cbc:ID>Numero della linea d’ordine</ cbc:ID>
<cbc:Quantity>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:OrderTypeCode>220</cbc:OrderTypeCode>
…
<cac:DeliveryTerms>
<cbc:SpecialTerms>ON</SpecialTerms>
</cac:DeliveryTerms>
…
<cac:PaymentTerms>
<cbc:Note>Pagamento in rate trimestrali</cbc:Note >
</cac:PaymentTerms>
…
<cac:OrderLine>
<cac:LineItem>
<cbc:ID>Numero della linea d’ordine</ cbc:ID>
<cbc:Quantity>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.
Budget ordering (221)
Type 221 corresponds to Budget Ordering, which is used when the purchase of a generic quantity of a good or service is required which will subsequently be distributed with respect to the quantity requested for delivery, date and place of delivery, or otherwise specified.
Type 221 has no order sub-types.
This type of order corresponds to the Budget Order type 220 – sub-type OB; the Entity has the right to alternatively use type 221 or type 220 with sub-type OB.
Adjustment ordering (226)
Type 226 corresponds to the Settlement order, which is used when it is necessary to divide a previous budget order into specific quantities, reporting the delivery date and place information, or to provide further specifications.
Type 226 has no ordering sub-types.
This type of order corresponds to the Regulation order type 220 – sub-type OR; the Entity must use type 226 if it has used type 221 for the related Budget Order, conversely, it must use type 220 with sub-type OR if it has used type 220 with sub-type OB for the related Budget Order .
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. Description of selected parts of the order message
6.1. Parties
The following parties/roles may be specified in the message:
6.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 message since he is the recipient of the order, therefore it is also mandatory to include the EndpointID (ParticipantID) by which he is registered on the Peppol network.
<cac:SellerSupplierParty>
<cac:Party>
<cbc:EndpointID schemeID="0211">IT01234567890</cbc:EndpointID>
<cac:PartyName>
<cbc:Name>Fornitore S.p.A.</cbc:Name>
</cac:PartyName>
<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>
<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").
When the VAT number is not provided in the EndpointID, it shall be indicated in the element Seller party identification.
When the Fiscal Code is to be provided, this shall be indicated in the element Seller legal registration identifier.
<cac:SellerSupplierParty>
<cac:Party>
<cbc:EndpointID schemeID="0201">UFY9MH</cbc:EndpointID>
<cac:PartyIdentification>
<cbc:ID schemeID="0211">IT01598570354</cbc:ID>
</cac:PartyIdentification>
<cac:PartyName>
<cbc:Name>Azienda USL di Reggio Emilia</cbc:Name>
</cac:PartyName>
<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: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:PartyName>
<cbc:Name>Fornitore Estero</cbc:Name>
</cac:PartyName>
<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>
<cbc:CompanyID schemeID="0210">0999999999</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>003241102030</cbc:Telephone>
<cbc:ElectronicMail>lucio.grande@belgio.be</cbc:ElectronicMail>
</cac:Contact>
</cac:Party>
</cac:SellerSupplierParty>The Seller is an essential element for the process but, exceptionally, it can not be known when the Order is issued, but become so at the moment of the provision of goods or services. For example, when the right of choosing the Seller is reserved to the Beneficiary (i.e. the person that takes possesions of the goods or for which the service is performed).
In this case the segment “SellerSupplierParty/Party” must contain only the following elements:
-
“EndpointID”, valorized with “9999999999999999” (16 times the number "9") indicating "0210" for the "Scheme ID";
-
“PostalAddress/Country/IdentificationCode”, valorized with the country code in which the purchase will be carried out (for Italy: “IT”);
-
“PartyLegalEntity/RegistrationName”, valorized with “NDEF”.
<cac:SellerSupplierParty>
<cac:Party>
<cbc:EndpointID schemeID="0210">9999999999999999</cbc:EndpointID>
<cac:PartyName>
<cbc:Name>Fornitore S.p.A.</cbc:Name>
</cac:PartyName>
<cac:PostalAddress>
<cac:Country>
<cbc:IdentificationCode>IT</cbc:IdentificationCode>
</cac:Country>
</cac:PostalAddress>
<cac:PartyLegalEntity>
<cbc:RegistrationName>NDEF</cbc:RegistrationName>
<cac:RegistrationAddress>
<cac:Country>
<cbc:IdentificationCode>IT</cbc:IdentificationCode>
</cac:Country>
</cac:RegistrationAddress>
</cac:PartyLegalEntity>
</cac:Party>
</cac:SellerSupplierParty>6.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 message since he is the sender of the order, therefore it is also mandatory to include the EndpointID (ParticipantID) by which he is registered on the Peppol network.
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>The VAT number must ve indicated in the element cac:Tax Scheme/cbc:CompanyID.
<cac:BuyerCustomerParty>
<cac:Party>
<cbc:EndpointID schemeID="0201">UFY9MH</cbc:EndpointID>
<cac:PartyName>
<cbc:Name>Azienda USL di Reggio Emilia</cbc:Name>
</cac:PartyName>
<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:PartyTaxScheme>
<cbc:CompanyID>IT01598570354</cbc:CompanyID>
<cac:TaxScheme>
<cbc:ID>VAT</cbc:ID>
</cac:TaxScheme>
</cac:PartyTaxScheme>
<cac:PartyLegalEntity>
<cbc:RegistrationName>Azienda USL di Reggio Emilia</cbc:RegistrationName>
<cbc:CompanyID schemeID="0210">01598570354</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 Bianchi</cbc:Name>
<cbc:Telephone>0522335111</cbc:Telephone>
<cbc:ElectronicMail>giovanni.bianchi@ausl.re.it</cbc:ElectronicMail>
</cac:Contact>
</cac:Party>
</cac:BuyerCustomerParty>6.1.3. OriginatorCustomerParty (Originator)
The unit initiating the order. Most often the end user. The originator information is optional in the PEPPOL BIS Order message.
<cac:OriginatorCustomerParty>
<cac:Party>
<cac:PartyIdentification>
<cbc:ID schemeID="0201">ABCDEF</cbc:ID>
</cac:PartyIdentification>
<cac:PartyName>
<cbc:Name>U.O. Farmacia Ospedaliera</cbc:Name>
</cac:PartyName>
<cac:Contact>
<cbc:Name>Roberto Gastone</cbc:Name>
<cbc:Telephone>010150847</cbc:Telephone>
<cbc:ElectronicMail>roberto.gastone@ospedale.it</cbc:ElectronicMail>
</cac:Contact>
</cac:Party>
</cac:OriginatorCustomerParty>If the document is issued with instruements made available by an Intermediary (for instance, an order issued using Central Purchasing Body.'s online platform), it is possible to highlight the Originator valorizing the element “OriginatorCustomerParty”, as shown in the following example.
<cac:OriginatorCustomerParty>
<cac:Party>
<cac:PartyIdentification>
<cbc:ID schemeID="0201">AABBCC</cbc:ID>
</cac:PartyIdentification>
<cac:PartyName>
<cbc:Name>AUSL SALERNO</cbc:Name>
</cac:PartyName>
<cac:Contact>
<cbc:Name>Roberto Gastone</cbc:Name>
<cbc:Telephone>010150847</cbc:Telephone>
<cbc:ElectronicMail>roberto.gastone@ospedale.it</cbc:ElectronicMail>
</cac:Contact>
</cac:Party>
</cac:OriginatorCustomerParty>6.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 message.
|
If the Buyer (BuyerCustomerParty) is a Public Administration, this information shall be provided also when the Invoicee (AccountingCustomerParty) and the Buyer coincide, in this case the "iPA code" needs must be indicated in the element cac:EndpointID. |
<cac:AccountingCustomerParty>
<cac:Party>
<cbc:EndpointID schemeID="0201">ABCDEF</cbc:EndpoinID>
<cac:PartyName>
<cbc:Name>Ospedale Sant’Anna</cbc:Name>
</cac:PartyName>
<cac:PostalAddress>
<cbc:StreetName>Via del pensiero, 1</cbc:StreetName>
<cbc:AdditionalStreetName>Primo Piano</cbc:AdditionalStreetName>
<cbc:CityName>Maranello</cbc:CityName>
<cbc:PostalZone>41053</cbc:PostalZone>
<cbc:CountrySubentity>Modena</cbc:CountrySubentity>
<cac:AddressLine>
<cbc:Line>Stanza 18</cbc:Line>
</cac:AddressLine>
<cac:Country>
<cbc:IdentificationCode>IT</cbc:IdentificationCode>
</cac:Country>
</cac:PostalAddress>
<cac:PartyTaxScheme>
<cbc:CompanyID>IT00234567890</cbc:CompanyID>
<cac:TaxScheme>
<cbc:ID>VAT</cbc:ID>
</cac:TaxScheme>
</cac:PartyTaxScheme>
<cac:PartyLegalEntity>
<cbc:RegistrationName>Ospedale Sant’Anna</cbc:RegistrationName>
<cbc:CompanyID schemeID="0210">00234567890</cbc:CompanyID>
<cac:RegistrationAddress>
<cbc:CityName>Modena</cbc:CityName>
<cac:Country>
<cbc:IdentificationCode>IT</cbc:IdentificationCode>
</cac:Country>
</cac:RegistrationAddress>
</cac:PartyLegalEntity>
<cac:Contact>
<cbc:Name>Responsabile Fatturazione</cbc:Name>
<cbc:ElectronicMail>responsabile.fatturazione@ospedale.it</cbc:ElectronicMail>
</cac:Contact>
</cac:Party>
</cac:AccountingCustomerParty>6.2. Attachments
Non-XML documents can be sent as attachments to the Peppol BIS Order. This could be drawings or time sheets or other documents relevant for the order. The attachment can either be sent as a binary object encoded in Base64 embedded in the message or as a URI to an external address as a link.
| It is recommended to send attachments as embedded, binary objects and not as external references. |
Valid values (i.e. compatible with con NSO) are listed and highlighted in the codelist Mime code.
<cac:AdditionalDocumentReference>
<cbc:ID>100</cbc:ID>
<cbc:DocumentType>Drawing</cbc:DocumentType>(1)
<cac:Attachment>
<cbc:EmbeddedDocumentBinaryObject mimeCode="application/pdf" filename="blueprint.pdf" >Ymx1ZXByaW50</cbc:EmbeddedDocumentBinaryObject>(2)
</cac:Attachment>
</cac:AdditionalDocumentReference>| 1 | It is recommended to use element cac:AdditionalDocumentReference/cbc:DocumentType to send a short description of the content of the attachment. |
| 2 | File name and extension should be sent in the filename attribute to the cbc:EmbeddedDocumentBinaryObject element. |
| Attachments should be used for additional information and not as order copies. |
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.
6.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" and "Replacement Order" the CIG (Codice Identificativo Gara) must be indicated.
| 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>6.4. Product identification
Product identification must be done using the identifiers described below:
-
Sellers ID
-
Standard ID, e.g. the GS1 Global Trade Item Number (GTIN)
Which identifier to use depends on what is known at the time ordering or what is commonly used in the relevant business sector.
| Each order line MUST have an item identifier and/or an item name |
<cac:SellersItemIdentification>
<cbc:ID>SN-33</cbc:ID>
</cac:SellersItemIdentification>
<cac:StandardItemIdentification>
<cbc:ID schemeID="0160">05704066204093</cbc:ID>
</cac:StandardItemIdentification>6.4.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:”. |
6.4.2. Details on medical devices products and their identification - UDI code
The UDI (Unique Device Identification) code, issued by the authorised body (GS1 or other operator) for medical devices, a numeric or alphanumeric character set comprising the device model identification code (UDI-DI) and a set of codes identifying the individual product instance (UDI-PI), including the serial number, the production batch number, software identification and date of manufacture or expiry or both.
The UDI code to be entered in the order corresponds to the model medical device identifier (UDI-DI).
Within the order, the UDI-DI code shall be indicated in the element cac:ManufacturersItemIdentifier/cbc:Structure ID cac:Item, prefixed by the string "UDI-DI:".
<cac:OrderLine>
...
<cac:LineItem>
...
<cac:Item>
...
<cac:ManufacturersItemIdentification>
<cbc:ID>UDI-DI:05414734509589</cbc:ID>
<cac:ManufacturersItemIdentification>
<cac:Item>
<cac:LineItem>
<cac:OrderLine>6.4.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:Item>
<cbc:Name>Benzina senza piombo, ottani>=98</cbc:Name>
<cac:SellersItemIdentification>
<cbc:ID>CARB:27101249</cbc:ID>
</cac:SellersItemIdentification>
<cac:ClassifiedTaxCategory>
<cbc:ID schemeID="UNCL5305">S</cbc:ID>
<cbc:Percent>22</cbc:Percent>
<cac:TaxScheme>
<cbc:ID>VAT</cbc:ID>
</cac:TaxScheme>
</cac:ClassifiedTaxCategory>
</cac:Item>6.5. Product name and description
The Product name shall be sent in tag 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 from buyer to seller.
<cac:Item>
<cbc:Description> Descrizione </cbc:Description>
<cbc:Name>Salviette per bambini</cbc:Name>
…
</cac:Item>6.6. Quantities and units
Various quantities and units can be stated in the Peppol BIS Order. 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 according to the Code list "Recommandation 20".
| Element name / (Tag name) | Description |
|---|---|
Price Quantity |
Quantity related to Price. |
Order Quantity |
Quantity that is ordered, e.g. number of pieces or volume in litre. |
|
As a general rule, please note that when the description related to the product’s codelist (e.g. Seller’s item identification) already contains the minimum sale unit or the packaging unit, it’s advisable to use the unit quantity code “C62” to prevent any misunderstandig between the Parties. |
<cac:OrderLine>
<cac:LineItem>
<cbc:Quantity unitCode=”C62”>3</cbc:Quantity>
</cac:LineItem>
</cac:OrderLine><cac:OrderLine>
<cac:LineItem>
<cbc:ID>1</cbc:ID>
<cbc:Quantity unitCode="LTR">120</cbc:Quantity>
<cbc:LineExtensionAmount currencyID="EUR">6000.00</cbc:LineExtensionAmount>
<cbc:PartialDeliveryIndicator>false</cbc:PartialDeliveryIndicator>
<cbc:AccountingCost>ProjectID123</cbc:AccountingCost>
<cac:Price>
<cbc:PriceAmount currencyID="EUR">50.00000</cbc:PriceAmount>
<cbc:BaseQuantity unitCode="LTR">1</cbc:BaseQuantity>
</cac:Price>
</cac:LineItem>
</cac:OrderLine>6.7. Prices
Prices may be exchanged in the order both for products with or without item identifiers and free text orders.
If prices are not sent in the order the normal process is to do price matching during the billing process comparing prices in the Invoice to prices in the Catalogue.
Price sent is related to the articles or services within this order.
-
Prices should include allowances and/or charges but exclude TAX amounts (e.g. VAT, GST or sales tax)
<cac:Price>
<cbc:PriceAmount currencyID="EUR">50.00000</cbc:PriceAmount>
<cbc:BaseQuantity unitCode="LTR">1</cbc:BaseQuantity>
</cac:Price>6.8. Allowances and Charges
The order transaction has elements for Allowance/charge on 2 levels.
The element cac:AllowanceCharge with sub element cbc:ChargeIndicator indicates whether the instance is a charge (true) or an allowance (false).
- The header level
-
Applies to the whole order and is included in the calculation of the order total amount (if specified).
-
Several allowances and charges may be supplied
-
Specification of TAX 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 (AnticipatedMonetaryTotals)
-
- The line level Price element
-
The price itself shall always be the net price, i.e. the base amount reduced with a discount (allowance).
-
Only one occurrence of allowance (discount) is allowed.
-
Specification of TAX for allowance shall not be specified
-
Allowance related to Price shall not be part of any other calculations.
-
Allowance related to Price may specify amount and the base amount.
-
6.8.1. 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>Freight service</cbc:AllowanceChargeReason>
<cbc:MultiplierFactorNumeric>2</cbc:MultiplierFactorNumeric> (4)
<cbc:Amount currencyID="EUR">20</cbc:Amount> (5)
<cbc:BaseAmount currencyID="EUR">1000.00</cbc:BaseAmount> (3)
<cac:TaxCategory>
<cbc:ID>S</cbc:ID>
<cbc:Percent>22</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.00</cbc:Amount>
<cac:TaxCategory>
<cbc:ID>S</cbc:ID>
<cbc:Percent>22</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>6.8.2. 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">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>6.8.3. Allowance and charges on line level
The following example shows an allowance applied to the whole order line:
<cac:OrderLine>
<cac:LineItem>
<cbc:ID>1</cbc:ID>
<cbc:Quantity unitCode="C62">10</cbc:Quantity>
<cbc:LineExtensionAmount currencyID="EUR">90.00</cbc:LineExtensionAmount>
<cac:AllowanceCharge>
<cbc:ChargeIndicator>false</cbc:ChargeIndicator>
<cbc:AllowanceChargeReason>Sconto sulla riga</cbc:AllowanceChargeReason>
<cbc:MultiplierFactorNumeric>10</cbc:MultiplierFactorNumeric>
<cbc:Amount currencyID="EUR">10.00</cbc:Amount>
<cbc:BaseAmount currencyID="EUR">100.00</cbc:BaseAmount>
</cac:AllowanceCharge>
<cac:Price>
<cbc:PriceAmount currencyID="EUR">10.00000</cbc:PriceAmount>
</cac:Price>
</cac:LineItem>
</cac:OrderLine>6.8.4. Discounts
For sale in the form of discounts, awards or allowance it is necessary to insert a distinct order line, paying attention to indicate the relative VAT exemption code.
In these cases, the discounts are out of scope VAT based on Art. 15 D.P.R. 633/72.
<cac:OrderLine>
<cac:LineItem>
<cbc:ID>1</cbc:ID>
<cbc:Quantity unitCode="C62">10</cbc:Quantity>
<cbc:LineExtensionAmount currencyID="EUR">0.00</cbc:LineExtensionAmount>
<cac:AllowanceCharge>
<cbc:ChargeIndicator>false</cbc:ChargeIndicator>
<cbc:AllowanceChargeReason>Sconto Merce</cbc:AllowanceChargeReason>
<cbc:MultiplierFactorNumeric>100</cbc:MultiplierFactorNumeric>
<cbc:Amount currencyID="EUR">90.00</cbc:Amount>
<cbc:BaseAmount currencyID="EUR">90.00</cbc:Amount>
</cac:AllowanceCharge>
<cac:Price>
<cbc:PriceAmount currencyID="EUR">9.00000</cbc:PriceAmount>
</cac:Price>
<cac:Item>
<cbc:Description>1x12 PACCHI</cbc:Description>
<cbc:Name>ARTICOLO MERCE</cbc:Name>
<cac:ClassifiedTaxCategory>
<cbc:ID>O</cbc:ID>
</cac:ClassifiedTaxCategory>
</cac:Item>
</cac:LineItem>
</cac:OrderLine>6.8.5. 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">20</cbc:Quantity>
<cbc:LineExtensionAmount currencyID="EUR">0</cbc:LineExtensionAmount>
<cac:Price>
<cbc:PriceAmount currencyID="EUR">0</cbc:PriceAmount>
<cbc:BaseQuantity unitCode="C62">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>6.9. Calculation of totals (AnticipatedMonetaryTotals)
The following elements show the anticipated monetary totals for an order:
| Element | Description | Formula |
|---|---|---|
<cbc:LineExtensionAmount> |
Sum of line amounts |
\$sum("cac:OrderLine/cac:LineItem/cbc:LineExtensionAmount")\$ |
<cbc:AllowanceTotalAmount> |
Allowances on document level |
\$sum("cac:AllowanceCharge[ChargeIndicator='false']/cbc:Amount")\$ |
<cbc:ChargeTotalAmount> |
Charges on document level |
\$sum("cac:AllowanceCharge[ChargeIndicator='true']/cbc:Amount")\$ |
<cbc:TaxExclusiveAmount> |
Order total amount without TAX |
\$\ \ \ \ "cac:AnticipatedMonetaryTotal/cbc:LineExtensionAmount"\$ |
<cbc:TaxInclusiveAmount> |
Order total amount included TAX |
\$\ \ \ \ "cac:AnticipatedMonetaryTotal/cbc:TaxExclusiveAmount"\$ |
<cbc:PrepaidAmount> |
Any amounts that have been paid a-priory |
Not applicable |
<cbc:PayableRoundingAmount> |
Rounding of Order total |
Not applicable |
<cbc:PayableAmount> |
The amount that is expected to be paid |
\$\ \ \ \ "cac:AnticipatedMonetaryTotal/cbc:TaxInclusiveAmount"\$ |
-
Amounts MUST be given to a precision of two decimals except for Price where maximum number of decimals are four.
-
Expected total payable amount MUST NOT be negative.
-
Expected total sum of line amounts MUST NOT be negative.
6.9.1. Element for rounding amount, the PayableRoundingAmount
It is possible to round the expected payable amount. The rule for this is according to the standard rule regarding rounding, ie. greater than or equal to 0.5 is rounded up, all other values are rounded down.
The element cac:AnticipatedMonetaryTotal/cbc:PayableRoundingAmount is used for this purpose and is specified on the header level.
Example: Amount 999.81 rounded to 1000. PayableRounding Amount = 0.19.
6.9.2. Example of calculations:
| Description | Element | Sample amounts |
|---|---|---|
Sum of line amounts |
|
700 |
Allowance on document level |
|
100.00 |
Charges on document level |
|
200.00 |
Order total amount without TAX |
|
800 |
TAX total amount |
|
85.63 |
Rounding of Order total |
|
0.37 |
Order total with TAX (value of purchase) |
|
885.63 |
Paid amounts |
|
135.00 |
Amount expected to be paid |
|
751.00 |
<cac:AnticipatedlMonetaryTotal>
<cbc:LineExtensionAmount currencyID="EUR">1436.50</cbc:LineExtensionAmount>
<cbc:TaxExclusiveAmount currencyID="EUR">1536.50</cbc:TaxExclusiveAmount>
<cbc:TaxInclusiveAmount currencyID="EUR">1921.00</cbc:TaxInclusiveAmount>
<cbc:AllowanceTotalAmount currencyID="EUR">100.00</cbc:AllowanceTotalAmount>
<cbc:ChargeTotalAmount currencyID="EUR">200.00</cbc:ChargeTotalAmount>
<cbc:PrepaidAmount currencyID="EUR">1000.00</cbc:PrepaidAmount>
<cbc:PayableRoundingAmount currencyID="EUR">0.37</cbc:PayableRoundingAmount>
<cbc:PayableAmount currencyID="EUR">921.00</cbc:PayableAmount>
</cac:AnticipatedMonetaryTotal>6.10. Tax total
It is possible to state the tax information of the order, on the header level (tax total) and also on line level (taxCategory and rate).
<cac:TaxTotal>
<cbc:TaxAmount currencyID="EUR">268.75</cbc:TaxAmount>
</cac:TaxTotal>6.11. 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. |
6.12. Reference to another order
In the case of Connected Order, Revocation Order or Replacement Order, it is necessary to indicate the so-called "Identification triple"(in italian Tripletta di identificazione) of the related Order in the elemement cac:OrderDocumentReference/cbc:ID, which is a structured field, by concatenating the following information in the order that follows:
-
ID, the identifier of the Order which this Order refers;
-
IssueDate, valorized with the date of the Order which this Order refers;
-
EndpointID, the identifier of the subject that issued the Order which this Order refers (corresponds to the Order’s element BuyerCustomerParty);
-
the status to be assigned to the Order, which can be:
-
“Connected”, for connection;
-
“Cancelled”, for the revocation;
-
“Revised”, for the replacement.
-
<cac:OrderDocumentReference>
<cbc:ID>110#2018-01-30#aaaaaa#Connected</cbc:ID>
</cac:OrderDocumentReference >6.12.1. Example of Connected Order
The Connected Order is used to start a process by connecting the actual process with a previous Order.
For example, after an Inital Order for Budgeting, a Connected Order for Regulation is issued as soon as the Buyer receives the first pro forma parcel of € 7.000 related to the performance of some preparatory activities made following a legal assistance mandate concerning the dispute “xxx”.
…
<cbc:ID>301</cbc:ID>
<cbc:IssueDate>2021-04-30<cbc:IssueDate>
<cbc:OrderTypeCode>220</cbc:OrderTypeCode>
…
<cac:OrderDocumentReference>
<cbc:ID>100#2021-01-30#Cliente_A#Connected</cbc:ID>
</cac:OrderDocumentReference>
…
<cac:BuyerCustomerParty>
<cac:Party>
<cbc:EndpointID schemeID="0201">Cliente_A</cbc:EndpointID>
</cac:Party>
</cac:BuyerCustomerParty>
…
<cac:DeliveryTerms>
<cbc:SpecialTerms>OR</SpecialTerms>
</cac:DeliveryTerms>
…
<cac:OrderLine>
<cac:LineItem>
<cbc:ID>1</cbc:ID>
<cbc:Quantity unitCode="C62">1</cbc:Quantity>
<cbc:LineExtensionAmount currencyID="EUR">7000.00</cbc:LineExtensionAmount>
<cac:price>
<cbc:PriceAmount currencyID="EUR">7000.00</cbc:PriceAmount>
</cac:Price>
<cac:Item>
<cbc:Description>Ordine di regolazione per attività di predisposizione</cbc:Description>
<cbc:Name> Patrocinio legale per la vertenza “xxx”</cbc:Name>
</cac:Item>
</cac:LineItem>
</cac:OrderLine>
…6.12.2. Example of Revocation Order
The previous order is revoked and the actual one has empty lines (NA) and the segments "TaxTotal" and "AnticipatedMonetaryTotal" must not be present.
<cac:OrderDocumentReference>
<cbc:ID>111#2018-01-30#ABCDEF#Cancelled</cbc:ID>
</cac:OrderDocumentReference>
…
<cac:OrderLine>
<cac:LineItem>
<cbc:ID>NA</cbc:ID>
<cbc:Quantity unitCode="C62">0</cbc:Quantity>
<cac:Item>
<cbc:Name>N/A</cbc:Name>
</cac:Item>
</cac:LineItem>
</cac:OrderLine>6.12.3. Example of Replacement Order
The previous order is amended by the present order, wich contains all the needed lines and consequently represents completely the new order.
<cac:OrderDocumentReference>
<cbc:ID>1115#2015-04-30#ABCDEF#Revised</cbc:ID>
</cac:OrderDocumentReference>
…
<cac:OrderLine>
<cac:LineItem>
<cbc:ID>1</cbc:ID>
<cbc:Quantity unitCode="C62">25</cbc:Quantity>
<cbc:LineExtensionAmount currencyID="EUR">118.13</cbc:LineExtensionAmount>
…
<cac:Item>
<cbc:Description>128481</cbc:Description>
<cbc:Name>CISTO - AID 650036(EX79847-E)</cbc:Name>
<cac:SellersItemIdentification>
<cbc:ID>79847-E</cbc:ID>
</cac:SellersItemIdentification>
…
</cac:Item>
</cac:LineItem>
</cac:OrderLine>6.13. Indications for particular orders
6.13.1. Order for Evaluation and Order for Billing products already consumed and Restoration
Orders with typology 227 for "Order for Evaluation" (CV) and orders 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:ItemSpecificationDocumentReference>
<cbc:ID>DDT123</cbc:ID>
</cac:ItemSpecificationDocumentReference>
...
<cac:ItemInstance>
<!--Seriale-->
<cbc:SerialID>23456TY</cbc:SerialID>
<!--Lotto-->
<cac:LotIdentification>
<cbc:LotNumberID>AB123WE</cbc:LotNumberID>
</cac:LotIdentification>
</cac:ItemInstance>6.13.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:BaseAmount currencyID="EUR">5.00</cbc:BaseAmount>
</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: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:BaseAmount currencyID="EUR">5.00</cbc:BaseAmount>
</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>6.14. Other references
To provide the ID of CUP, Despatch Advice, Expenditure Commitment, Expenditure Deliberation, Contract and Framework Agreement see the table below.
| 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:ProjectReference>
<cbc:ID>J31E01000010004</cbc:ID>
</cac:ProjectReference ><cac:OrderLine>
<cac:LineItem>
<cac:Item>
...
<cac:ItemSpecificationDocumentReference>
<cbc:Id>IMPEGNO:123/2019 </cbc:Id>
</cac:ItemSpecificationDocumentReference>
<cac:ItemSpecificationDocumentReference>
<cbc:Id>DDT:00001253/2019</cbc:Id>
</cac:ItemSpecificationDocumentReference>
...
</cac:Item>
</cac:LineItem>
</cac:OrderLine>6.15. Product 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' code on separeted 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>6.15.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>
<cbc:AccountingCost>BA0200</cbc:AccountingCost>
<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".
6.16. Delivery
6.16.1. Delivery Location
Delivery information is required if the address differs from that of the party issuing the order.
The place of delivery shall be the place where the supply of goods and/or services is to take place. It is indicated, at document header level, in the "Delivery/DeliveryLocation" element.
If the place of delivery is an institutional address of the Customer to which a unique identifier made available to the Supplier has been associated, as in the case of the places of delivery for the PA recorded according to the coding published at the following link Punti di consegna NSO, is possible to indicate the identifier in the cbc:ID element.
<cac:Delivery>
<cac:DeliveryLocation>
<cbc:ID>CF-IdShipTo</cbc:ID>
<Name>Magazzino centralizzato</Name>
</cac:DeliveryLocation>
<cac:RequestedDeliveryPeriod> (1)
<cbc:StartDate>2018-05-15</cbc:StartDate>
<cbc:StartTime>08:00:00</cbc:StartTime>
<cbc:EndDate>2018-05-15</cbc:EndDate>
<cbc:EndTime>13:00:00</cbc:EndTime>
</cac:RequestedDeliveryPeriod>
<cac:DeliveryParty>
<cac:PartyIdentification>
<cbc:ID schemeID="0201">AAFF33</cbc:ID>
</cac:PartyIdentification>
<cac:PartyName>
<cbc:Name>Centro Logistico Beni Sanit-Ecom Area 2</cbc:Name>
</cac:PartyName>
<cac:Contact>
<cbc:Name>ResponsabileMagazzino</cbc:Name>
<cbc:Telephone>0516361509</cbc:Telephone>
<cbc:ElectronicMail>responsabile.magazzino@aziendasanitaria.it</cbc:ElectronicMail>
</cac:Contact>
</cac:DeliveryParty>
</cac:Delivery>
<cac:DeliveryTerms>
<cbc:ID>PORTO FRANCO</cbc:ID>
</cac:DeliveryTerms>| 1 | Reuqested delivery period: specify in this structure the information if the day ("StartDate/EndDate" fields) and the time ("StartTime/EndTime" fields) of the delivery execution has been agreed. |
If, on the other hand, the delivery of goods and/or the provision of services is to take place at a non-institutional place or in an institutional place not coded (even temporarily), all parts of the sub-element "Address" must be precisely indicated as shown in the following example:
-
Example of delivery at non-Institutional Address
<cac:Delivery>
<cac:DeliveryLocation>
<Name>Nuovo magazzino di reparto</Name>
<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> (1)
</cac:AddressLine>
<cac:Country>
<cbc:IdentificationCode>IT</cbc:IdentificationCode>
</cac:Country>
</cac:Address>
…
</cac:DeliveryLocation>
</cac:Delivery>
| 1 | Information on the opening time of the warehouse. |
If it is a home delivery (for example, to a patient’s address), this circumstance must be specified by enhancing the "ID" field with the text "Home delivery" and indicating precisely in the structure "Address" the exact delivery address, as shown in the following example:
<cac:Delivery>
<cac:DeliveryLocation>
<cac:ID>Consegna domiciliare</cac:ID>
<Name>Entrata lato portineria</Name>
<cac:Address>
<cbc:StreetName>Via Attanasio Soldati 80</cbc:StreetName>
<cbc:AdditionalStreetName>Località La Rustica</cbc:AdditionalStreetName>
<cbc:CityName>Roma</cbc:CityName>
<cbc:PostalZone>00155</cbc:PostalZone>
<cbc: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>6.16.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:PartyName>
<cbc:Name>Centro logistico</cbc:Name>
</cac:PartyName>
<cac:Contact>
<cbc:Name>James Bond</Name
<cbc:Telephone>0647611</cbc:Telephone>
<cbc:ElectronicMail>james.bond@peo.it</ ElectronicMail>
</cac:Contact>
</cac:PartyIdentification>
</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”.
6.16.3. Shipping Marks
The Buyer can require to the Seller, if needed, to print a text over the shipping label by properly valorizing the field “TransportHandlingUnit/ShippingMarks” of the element “Shipment”, as shown below:
<cac:Delivery>
<cbc:ID>NA</cbc:ID>
<cac:Shipment>
<cac:TransportHandlingUnit>
<cbc:ShippingMarks>aaaaaaaaaa</cbc:ShippingMarks>
</cac:TransportHandlingUnit>
</cac:Shipment>
</cac:Delivery>6.17. 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.
6.17.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>6.17.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>6.18. 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.
In particular, with referecence to the element “Note” in the segment “PaymentTerms”, it is recommended to indicate the number of days since the invoice was issued. The absence of any indications means that valid terms established by current legislation are taken into account.
<cac:PaymentTerms>
<cbc:Note>30 giorni fattura</cbc:Note>
</cac:PaymentTerms>| 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. |
6.19. Accounting Cost
The accounting classification can be indicated at the document level valorizing the element “AccountingCost”.
For instance, given the cost account “BA0040 – Medicinal products with AIC”:
<cbc:AccountingCost>BA0040</cbc:AccountingCost>To indicate the accounting classification at the line level it is necessary to valorize the element "AccountingCost” within the segment “OrderLine/LineItem".
For istance, given the cost account “BA0350 – Informatic support and stationary”:
<cac:OrderLine>
<cac:LineItem>
<cbc:AccountingCost>BA0350</cbc:AccountingCost>
</cac:LineItem>
</cac:OrderLine>With reference to the medical devices, the element “AccountingCost” must be always valorized to provide information about the entry of the Balance Sheet/Income Statement, which needs to be reported later in the Invoice by the Seller into the element of FatturaPA “RiferimentoAmministrazione”, according to the instruction of Ministerial Circular MEF-MDS of 17 March 2020 “Fatture elettroniche riguardanti dispositivi medici - Individuazione delle fatture di interesse per l’applicazione delle disposizioni previste dall’articolo 9-ter del decreto-legge 19 giugno 2015 n. 78, come modificato dalla Legge 30 dicembre 2018, n. 145, art. 1, comma 557”.
In all the remaining cases, the element “AccountingCost” can be valorized as the most appropriate way, for example with a cost account, center account, both, or any other accounting classification.
The information must be separated by the character "#".
Given the provisions of regulation in force, the placelement of information in the fiels "AccountingCost" must comply with the following order of priority:
-
if necessary, the indication “COV-20” (see below);
-
if necessary, the indication about RiferimentoAmministrazione of a medical device;
-
further indications.
6.19.1. Covid-19 epidemiological emergency
The Article 18 of Decree Law of 17 March 2020 prescribes the opening of a dedicated cost-center and marked with the unique code "COV 20", in order to guarantee a distinction of the accounting eventi related to the management of Covid-19 epidemiological emergency.
The appropriate element to be used is the field cbc:AccountingCost (available both on the header and the line level), with the indication of the string "COV20".
Since in the section cac:AdditionalDocumetReference it is also possible to report information about possible measures for reference, such as expenditure deliberation (delibera), expenditure commitment (impegno), etc. (see paragraph 6.14), in order to facilitate the dinstiction of order strictly and uniquely related to COVID-1' emergency management, it is recommended to issue specific order for this purpose.
If this criterion is adopted, alternatively or in addition to what aforementioned, it is possible also to insert the string "COV20” inside the element for Order identification (cbc:ID).
6.20. Financial year shifting
In some circumstances, for puproses of accounting nature, is isual to "close" the totally or partially unfilled Orders at the end of a financial year and re-opening them in the following one.
In these cases, it may be useful that the new order maintain a connection with the previous one. This need can be met by:
-
the issuing, in the financial year now ending, of an Order Cancellation or Order Replacement with the indication of the order sub-type “OR” (see paragraph 4.5) which "closes" the totally or partially unfilled Order;
-
the issuing, in the following financial year, of an Order Cancellation related to the one in the previous financial year (see paragraph 4.4).
7. Description of selected parts of the order response message
The Order response message is sent from the Seller to the Buyer stating the sellers ability to fulfil the order. The following rules applies to the Peppol BIS Order Response:
-
The Order response must refer to an Order.
-
Seller may accept or reject the entire Order.
-
If the order or any order line is rejected the Order response should contain a reason for rejection.
-
Seller may accept or reject the separate order lines.
-
If Seller accepts or rejects order lines, all order lines must be sent in the Order response.
-
The order lines in the order response must be related to the corresponding order line, 1 to 1.
-
The following information may be changed in the Order response:
-
Quantity
-
Delivery period
-
Replacement item
-
Price
-
-
If the order is rejected or modified, the order response must include at the document level the Seller’s contact information in the element cbc:Note.
-
The order response must contain univocally the Buyer’s identifier.
7.1. Response code
The Response code states the Sellers ability to fulfil the order and must be sent on both header level and line level if lines are sent.
|
7.1.1. Response code on Header level
| Response code | Action |
|---|---|
AB |
|
RE |
|
AP |
|
CA |
|
<cbc:OrderResponseCode>CA</cbc:OrderResponseCode><?xml version="1.0" encoding="UTF-8"?>
<OrderResponse
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="urn:oasis:names:specification:ubl:schema:xsd:OrderResponse-2"
xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2">
<cbc:CustomizationID>urn:fdc:peppol.eu:poacc:trns:order_response:3</cbc:CustomizationID>
<cbc:ProfileID>urn:fdc:peppol.eu:poacc:bis:ordering:3</cbc:ProfileID>
<cbc:ID>0005a-2018</cbc:ID>
<cbc:IssueDate>2018-12-01</cbc:IssueDate>
<cbc:IssueTime>14:30:00</cbc:IssueTime>
<!--Ordine ricevuto ma ancora non processato-->
<cbc:OrderResponseCode>AB</cbc:OrderResponseCode> (1)
<cbc:Note>Risposta Ordine Inviato al Cliente</cbc:Note>
<cbc:DocumentCurrencyCode>EUR</cbc:DocumentCurrencyCode>
<cac:OrderReference>
<cbc:ID>5a-2018#2018-11-25#UFY9MH</cbc:ID>
</cac:OrderReference>
<!--Fornitore, Venditore-->
<cac:SellerSupplierParty>
<cac:Party>
<cbc:EndpointID schemeID="0211">IT05501420900</cbc:EndpointID>
<cac:PartyIdentification>
<cbc:ID schemeID="0211">IT05501420900</cbc:ID>
</cac:PartyIdentification>
<cac:PartyLegalEntity>
<cbc:RegistrationName>Fornitore S.p.A.</cbc:RegistrationName>
</cac:PartyLegalEntity >
</cac:Party>
</cac:SellerSupplierParty>
<!--Mittente, Cliente-->
<cac:BuyerCustomerParty>
<cac:Party>
<cbc:EndpointID schemeID="0201">UFY9MH</cbc:EndpointID>
<cac:PartyIdentification>
<cbc:ID schemeID="0201">UFY9MH</cbc:ID>
</cac:PartyIdentification>
<cac:PartyLegalEntity>
<cbc:RegistrationName>Azienda USL di Reggio Emilia </cbc:RegistrationName>
</cac:PartyLegalEntity >
</cac:Party>
</cac:BuyerCustomerParty>
<cac:Delivery>
<cac:PromisedDeliveryPeriod>
<cbc:StartDate>2018-12-10</cbc:StartDate>
<cbc:EndDate>2018-12-20</cbc:EndDate>
</cac:PromisedDeliveryPeriod>
</cac:Delivery> (2)
</OrderResponse>| 1 | Response code AB indicates only that the order has been received, but is not yet processed. |
| 2 | No order lines are sent in this response |
7.1.2. Line response code on Line level
When the order is accepted without amendment (at line level), all the order lines must be sent including the respective code.
| Response line code | Action |
|---|---|
1 |
The Order line is Added. |
3 |
The Order line is Changed. |
5 |
The Order line is Accepted without amendment. |
7 |
The Order line is Not accepted. |
42 |
The Order line is Already delivered. |
<cac:OrderLine>
<cac:LineItem>
<cbc:ID>1</cbc:ID>
<cbc:Note>Merce terminata</cbc:Note>
<cbc:LineStatusCode>7</cbc:LineStatusCode>
...
</cac:LineItem>
</cac:OrderLine>7.2. Order reference
Reference to the related order must be done on Header level, indicating the "identification triplet" (so-called Tripletta di identificazione) of the Order to which it’is intended to respond, in the element “OrderReference/ID”, that is a structured field made of the following values:
-
"ID”, valorized with the identifier of the Order to which is intended to respond;
-
“IssueDate”, valorized with the date of the Order to which is intended to respond;
-
“EndpointID” of the element “BuyerCustomerParty/Party” of the Order to which is intended to respond.
<ubl:OrderResponse>
...
<cbc:ID>12</cbc:ID>
<cbc:IssueDate>2018-10-01</cbc:IssueDate>
<cbc:IssueTime>12:30:00</cbc:IssueTime>
<cbc:OrderResponseCode>CA</cbc:OrderResponseCode>
<cbc:Note>Modifica in una linea ordine</cbc:Note>
<cac:OrderReference>
<cbc:ID>34#2018-09-20#ABCDEF</cbc:ID>
</cac:OrderReference>If lines are sent in the Order Response, reference to the related order line must be sent.
<cac:OrderLine>
<cac:LineItem>
<cbc:ID>2</cbc:ID>
<cbc:LineStatusCode>5</cbc:LineStatusCode>
...
<cac:Item>
<cbc:Name>Salviette umide per bambini</cbc:Name>
</cac:Item>
</cac:LineItem>
...
<cac:OrderLineReference>
<cac:LineID>2</cac:LineID>
</cac:OrderLineReference>
</cac:OrderLine>7.2.1. Order rejected
When the Seller reject the order, the response code «RE» must be sent on Header level. In this case, no order line needs to be provided.
<cbc:ID>34</cbc:ID>
<cbc:IssueDate>2012-10-01</cbc:IssueDate>
<cbc:IssueTime>12:30:00</cbc:IssueTime>
<cbc:OrderResponseCode>RE</cbc:OrderResponseCode7.2.2. Order accepted
When the Seller accepts an order without amendments, the response code «AP» must be sent on Header level. In this case, no order line needs to be provided.
<cbc:ID>34</cbc:ID>
<cbc:IssueDate>2012-10-01</cbc:IssueDate>
<cbc:IssueTime>12:30:00</cbc:IssueTime>
<cbc:OrderResponseCode>AP</cbc:OrderResponseCode>7.3. Order response with changes
-
When Seller accepts an order with changes, the response code «CA» must be sent on header level.
-
On line level there may be a mix of different response codes.
-
Some lines may have been accepted without amendments (line response code 5), some not accepted (line response code 7) and some changed (line response code 3).
-
If line response code = 3, the elements to be changed must be sent with new values.
-
The following elements can be changed:
-
Quantity
-
Delivery period
-
Replacement item
-
Price
-
-
<ubl:Order>
...
<cac:OrderLine>
<cac:LineItem>
<cbc:ID>4</cbc:ID>
<cbc:Quantity unitCode="C62">30</cbc:Quantity>
<cbc:LineExtensionAmount currencyID="EUR">60.00</cbc:LineExtensionAmount>
<cbc:PartialDeliveryIndicator>true</cbc:PartialDeliveryIndicator>
<cbc:AccountingCost>ProjectID123</cbc:AccountingCost>
<cac:Delivery>
<cac:DeliveryLocation>
....
</cac:DeliveryLocation>
<cac:RequestedDeliveryPeriod>
<cbc:StartDate>2018-06-30</cbc:StartDate>
<cbc:StartTime>12:10:33</cbc:StartTime>
<cbc:EndDate>2018-06-30</cbc:EndDate>
<cbc:EndTime>14:20:00</cbc:EndTime>
</cac:RequestedDeliveryPeriod>
<cac:DeliveryParty>
...
</cac:DeliveryParty>
</cac:Delivery>
<cac:Price>
<cbc:PriceAmount currencyID="EUR">2.00</cbc:PriceAmount>
<cbc:BaseQuantity unitCode="C62">1</cbc:BaseQuantity>
</cac:Price>
<cac:Item>
<cbc:Description>Descrizione</cbc:Description>
<cbc:Name>Salviette per bambini</cbc:Name>
<cac:SellersItemIdentification>
<cbc:ID>SItemNo011</cbc:ID>
</cac:SellersItemIdentification>
<cac:StandardItemIdentification>
<cbc:ID schemeID="0160">05704368876486</cbc:ID>
</cac:StandardItemIdentification>
<cac:CommodityClassification>
<cbc:ItemClassificationCode listID="STI">56789</cbc:ItemClassificationCode>
</cac:CommodityClassification>
...
</cac:Item>
</cac:LineItem>
</cac:OrderLine><ubl:OrderResponse>
...
<cac:OrderLine>
<cac:LineItem>
<cbc:ID>4</cbc:ID>
<cbc:LineStatusCode>3</cbc:LineStatusCode>
<cbc:Quantity unitCode="C62">18</cbc:Quantity>
<cac:Item>
<cbc:Name>Salviette umide per bambini</cbc:Name>
<cac:SellersItemIdentification>
<cbc:ID>SN-35</cbc:ID>
</cac:SellersItemIdentification>
</cac:Item>
</cac:LineItem>
<cac:OrderLineReference>
<cbc:LineID>4</cbc:LineID>
</cac:OrderLineReference>
</cac:OrderLine><ubl:OrderResponse>
...
<cac:OrderLine>
<cac:LineItem>
<cbc:ID>4</cbc:ID>
<cbc:LineStatusCode>3</cbc:LineStatusCode>
<cbc:Quantity unitCode="C62">18</cbc:Quantity>
<cac:Delivery>
<cac:PromisedDeliveryPeriod>
<cbc:StartDate>2018-07-15</cbc:StartDate>
<cbc:EndDate>2018-07-15</cbc:EndDate>
</cac:PromisedDeliveryPeriod>
</cac:Delivery>
<cac:Item>
<cbc:Name>Salviette umide per bambini</cbc:Name>
<cac:SellersItemIdentification>
<cbc:ID>SN-35</cbc:ID>
</cac:SellersItemIdentification>
</cac:Item>
</cac:LineItem>
<cac:OrderLineReference>
<cbc:LineID>4</cbc:LineID>
</cac:OrderLineReference>
</cac:OrderLine>| It is possible to send more than one Order Response line per Order line. |
For the same order line therefore we add another change to the quantity and to the delivery period, as shown in the example above.
<ubl:OrderResponse>
...
<cac:OrderLine>
<cac:LineItem>
<cbc:ID>5</cbc:ID>
<cbc:LineStatusCode>1</cbc:LineStatusCode>
<cbc:Quantity unitCode="C62">12</cbc:Quantity>
<cac:Delivery>
<cac:PromisedDeliveryPeriod>
<cbc:StartDate>2018-08-15</cbc:StartDate>
<cbc:EndDate>2018-08-15</cbc:EndDate>
</cac:PromisedDeliveryPeriod>
</cac:Delivery>
<cac:Item>
<cbc:Name>Salviette umide per bambini</cbc:Name>
<cac:SellersItemIdentification>
<cbc:ID>SN-35</cbc:ID>
</cac:SellersItemIdentification>
</cac:Item>
</cac:LineItem>
<cac:OrderLineReference>
<cbc:LineID>4</cbc:LineID>
</cac:OrderLineReference>
</cac:OrderLine>The effect of the two Order response lines above should be interpreted as follows:
-
Order line 4 will be delivered on two dates:
-
18 pieces on 15th of July and
-
12 pieces on the 15th of August.
-
<ubl:OrderResponse>
...
<cac:OrderLine>
<cac:LineItem>
<cbc:ID>4</cbc:ID>
<cbc:LineStatusCode>3</cbc:LineStatusCode>
<cac:Item>
<cbc:Name>Salviette umide per bambini</cbc:Name>
<cac:SellersItemIdentification>
<cbc:ID>SItemNo011</cbc:ID>
</cac:SellersItemIdentification>
<cac:StandardItemIdentification>
<cbc:ID schemeID="0160">05704368876486</cbc:ID>
</cac:StandardItemIdentification>
<cac:CommodityClassification>
<cbc:ItemClassificationCode listID="STI">56789</cbc:ItemClassificationCode>
</cac:CommodityClassification>
</cac:Item>
</cac:LineItem>
<cac:SellerSubstitutedLineItem> (1)
<cbc:ID>4</cbc:ID>
<cac:Item>
<cbc:Name>Salviette umide per adulti</cbc:Name>
<cac:SellersItemIdentification>
<cbc:ID>SItemNo012</cbc:ID>
</cac:SellersItemIdentification>
<cac:StandardItemIdentification>
<cbc:ID schemeID="0160">05704368643453</cbc:ID>
</cac:StandardItemIdentification>
<cac:CommodityClassification>
<cbc:ItemClassificationCode listID="STI">675634</cbc:ItemClassificationCode>
</cac:CommodityClassification>
</cac:Item>
</cac:SellerSubstitutedLineItem>
<cac:OrderLineReference>
<cbc:LineID>4</cbc:LineID>
</cac:OrderLineReference>
</cac:OrderLine>| 1 | Information on the replacement item is sent in cac:SellerSubstitutedLineItem |
<ubl:OrderResponse>
...
<cac:OrderLine>
<cac:LineItem>
<cbc:ID>4</cbc:ID>
<cbc:Note>Merce Modificata nel Prezzo</cbc:Note>
<!--Riga accettata con modifica-->
<cbc:LineStatusCode>3</cbc:LineStatusCode>
<cbc:Quantity unitCode="C62">30</cbc:Quantity>
<cac:Delivery>
<cac:PromisedDeliveryPeriod>
<cbc:StartDate>2018-06-30</cbc:StartDate>
<cbc:EndDate>2018-06-30</cbc:EndDate>
</cac:PromisedDeliveryPeriod>
</cac:Delivery>
<cac:Price>
<cbc:PriceAmount currencyID="EUR">3.00</cbc:PriceAmount>
</cac:Price>
<cac:Item>
<cbc:Name>Salviette umide per bambini</cbc:Name>
<cac:SellersItemIdentification>
<cbc:ID>SItemNo011</cbc:ID>
</cac:SellersItemIdentification>
<cac:StandardItemIdentification>
<cbc:ID schemeID="0160">05704368876486</cbc:ID>
</cac:StandardItemIdentification>
<cac:CommodityClassification>
<cbc:ItemClassificationCode listID="STI">56789</cbc:ItemClassificationCode>
</cac:CommodityClassification>
</cac:Item>
</cac:LineItem>
<cac:OrderLineReference>
<cbc:LineID>4</cbc:LineID>
</cac:OrderLineReference>
</cac:OrderLine>7.4. Order response replacing items and delivering over time.
An order response can replace the items in two ways.
If the total quantity of an order is replaced, this information can be provided by using the element that identifies the new Seller (cac:SellerSubstitutedLineItem) into the invoice response, as shown in the example below.
<cac:OrderLine>
<cac:LineItem>
<cbc:ID>6</cbc:ID>
<cbc:LineStatusCode>3</cbc:LineStatusCode>
<cac:Item>
<cbc:Name>Salviette umide</cbc:Name>
<cac:SellersItemIdentification>
<cbc:ID>SItemNo011</cbc:ID>
</cac:SellersItemIdentification>
<cac:StandardItemIdentification>
<cbc:ID schemeID="0160">05704368876486</cbc:ID>
</cac:StandardItemIdentification>
</cac:Item>
</cac:LineItem>
<cac:SellerSubstitutedLineItem> (1)
<cbc:ID>2</cbc:ID>
<cac:Item>
<cbc:Name>Salviette umide</cbc:Name>
<cac:SellersItemIdentification>
<cbc:ID>SItemNo012</cbc:ID>
</cac:SellersItemIdentification>
<cac:StandardItemIdentification>
<cbc:ID schemeID="0160">05704368643453</cbc:ID>
</cac:StandardItemIdentification>
<cac:CommodityClassification>
<cbc:ItemClassificationCode listID="STI">675634</cbc:ItemClassificationCode>
</cac:CommodityClassification>
</cac:Item>
</cac:SellerSubstitutedLineItem>
<cac:OrderLineReference>
<cbc:LineID>5</cbc:LineID>
</cac:OrderLineReference>
</cac:OrderLine>| 1 | Information on the replacement item is sent in cac:SellerSubstitutedLineItem |
If the seller replaces a part of the order quantity or delivers the quantity at different times, may have to add order lines and/or to mark order lines ad delivered, as shown in the following example.
In the example, the Seller confirms the first order line, provides two dates for the second order’s line of 3 items by adding a new order line (Product B), and so confirming that the order line no. 3 has already been delivered.
<cac:OrderLine>
<cac:LineItem>
<cbc:ID>1</cbc:ID>
<cbc:LineStatusCode>5</cbc:LineStatusCode>
<cac:Item>
<cbc:Name>Prodotto A</cbc:Name>
<cac:SellersItemIdentification>
<cbc:ID>Pr00A</cbc:ID>
</cac:SellersItemIdentification>
</cac:Item>
</cac:LineItem>
<cac:OrderLineReference>
<cbc:LineID>1</cbc:LineID>
</cac:OrderLineReference>
</cac:OrderLine>
<cac:OrderLine>
<cac:LineItem>
<cbc:ID>2</cbc:ID>
<cbc:LineStatusCode>3</cbc:LineStatusCode>
<cbc:Quantity unitCode="C62">2</cbc:Quantity>
<cac:Delivery>
<cac:PromisedDeliveryPeriod>
<cbc:StartDate>2018-07-01</cbc:StartDate>
</cac:PromisedDeliveryPeriod>
</cac:Delivery>
<cac:Item>
<cbc:Name>Prodotto B</cbc:Name>
<cac:SellersItemIdentification>
<cbc:ID>Pr00B</cbc:ID>
</cac:SellersItemIdentification>
</cac:Item>
</cac:LineItem>
<cac:OrderLineReference>
<cbc:LineID>2</cbc:LineID>
</cac:OrderLineReference>
</cac:OrderLine>
<cac:OrderLine>
<cac:LineItem>
<cbc:ID>3</cbc:ID>
<cbc:LineStatusCode>1</cbc:LineStatusCode>
<cbc:Quantity unitCode="C62">1</cbc:Quantity>
<cac:Delivery>
<cac:PromisedDeliveryPeriod>
<cbc:StartDate>2018-07-05</cbc:StartDate>
</cac:PromisedDeliveryPeriod>
</cac:Delivery>
<cac:Item>
<cbc:Name>Prodotto B</cbc:Name>
<cac:SellersItemIdentification>
<cbc:ID>Pr00B</cbc:ID>
</cac:SellersItemIdentification>
</cac:Item>
</cac:LineItem>
<cac:OrderLineReference>
<cbc:LineID>2</cbc:LineID>
</cac:OrderLineReference>
</cac:OrderLine>
<cac:OrderLine>
<cac:LineItem>
<cbc:ID>4</cbc:ID>
<cbc:LineStatusCode>42</cbc:LineStatusCode>
<cac:Item>
<cbc:Name>Prodotto C</cbc:Name>
<cac:SellersItemIdentification>
<cbc:ID>Pr00C</cbc:ID>
</cac:SellersItemIdentification>
</cac:Item>
</cac:LineItem>
<cac:OrderLineReference>
<cbc:LineID>3</cbc:LineID>
</cac:OrderLineReference>
</cac:OrderLine>7.5. Order response with backorder.
An order response may provide information for partial delivery of an order line with additional information about the maximum number of items that will be delivered at a later but not known date.
If the remaining quantity will NOT be delivered use cbc:MaximumBackorderQuantity= 0.
|
<cac:OrderLine>
<cac:LineItem>
<cbc:ID>9</cbc:ID>
<cbc:LineStatusCode>3</cbc:LineStatusCode>
<cbc:Quantity unitCode="C62">2</cbc:Quantity>
<cbc:MaximumBackorderQuantity>3</cbc:MaximumBackorderQuantity>
<cac:Delivery>
<cac:PromisedDeliveryPeriod>
<cbc:StartDate>2018-09-05</cbc:StartDate>
</cac:PromisedDeliveryPeriod>
</cac:Delivery>
<cac:Item>
<cbc:Name>Prodotto D</cbc:Name>
<cac:SellersItemIdentification>
<cbc:ID>Pr00D</cbc:ID>
</cac:SellersItemIdentification>
</cac:Item>
</cac:LineItem>
<cac:OrderLineReference>
<cbc:LineID>1</cbc:LineID>
</cac:OrderLineReference>
</cac:OrderLine>7.6. 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. |
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 (Trdm01) |
urn:fdc:peppol.eu:poacc:trns:order:3 :restrictive:urn:www.agid.gov.it:trns:ordine:3.1 |
urn:fdc:peppol.eu:poacc:bis:ordering:3 |
Order response (Trdm76) |
urn:fdc:peppol.eu:poacc:trns:order_response:3 :restrictive:urn:www.agid.gov.it:trns:risposta_ordine:3.0 |
8.3. Namespaces
-
The target namespace for the UBL 2.1 Order is:
urn:oasis:names:specification:ubl:schema:xsd:Order-2-
The target namespace for the UBL Order Response 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