The Peppol Business Interoperability Specification, “BIS” from here on after, has been developed by the OpenPeppol AISBL Post Award Coordinating Community and is published as part of the Peppol specifications.
Link to main site of documentation
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 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 BIS is based on the CEN WS/BII Profile CEN BII2 Profile 28, Ordering and is extended to include order change and order cancellation. This business processes in this BIS are specified in collaboration with CEN TC-440/WG6.
The purpose of this document is to describe formats for the Order, Order Change, Order Cancellation and Order Response Advanced message, and to facilitate an efficient implementation and increased use of electronic collaboration regarding the advanced 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 Advanced Ordering.
2.1. Scope
This BIS describes a process comprising a buyer to issue an electronic order, whereby the seller may accept or reject the order. 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. After acceptance the buyer may send an order change to the original order and the seller can either accept or reject the change. The seller may also change the order by sending a response which can be accepted or rejected by the buyer. Both buyer and seller may also cancel the order.
The order that is agreed upon by final acceptance has the commercial and legal status of a contract and is ready for delivery.
The main activities supported by this profile are
- Initial order from buyer
-
The initial 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.
- Change of order from buyer
-
The buyer may change the order based on new requirements or other reasons. Changes must be done before the order is prepared for delivery. The seller can either accept or reject the changes.
- Change of order from seller
-
The seller may change the previously accepted order due to e.g. changes in delivery dates or replacements. The buyer can either accept or reject the changes.
- Cancellation of order from buyer
-
The buyer may cancel the order if this is done before the order is prepared for delivery. The buyer and seller may have agreed upon deadlines for cancellation. The seller can either accept or reject the cancellation.
- Cancellation of order from seller
-
The seller may cancel the order because of lack of delivery capacity or other reasons. As stated above the buyer and seller may have agreed upon deadlines for cancellation. The buyer must confirm the reception of the cancellation.
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 person or unit 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 BIS structure is based on the European Interoperability Framework 2.0 EIF. This 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 BIS supports B2B and B2G.
-
This BIS supports cross border, regional and domestic ordering.
-
This BIS can function as a component in an EDI agreement within a trading community.
-
This 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 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 (for Order transaction)
-
Binding to OASIS UBL 2.3, see UBL 2.3 (for other transactions)
-
ISO/IEC 19757-3 Schematron, for automation of document validation, see Schematron
-
-
Technical Interaction (eSignature Validation):
-
Not supported in this BIS.
-
-
3. Business process and scenarios
The Advanced ordering process includes the sending of an intial order from buyer and subsequent changes to the order from both buyer and seller. The process also allows for cancellation of the order.
3.1. Process flow
The Ordering process flow is shown in the below figure. Each task comprise a scenario that is described in detail in the following chapters.
-
A buyer submits an initial order to the seller requesting for delivery of goods or services.
-
The order may refer to a framework agreement for its terms and conditions; otherwise the buyer’s terms and conditions apply.
-
The order may contain items (goods or services) with item identifiers or items with free text description.
-
-
The initial order may be confirmed for delivery without any more changes or it may be cancelled by buyer or seller
-
The order may be changed by the buyer sending one or more order changes until a contract is concluded and the order is confirmed for delivery.
-
The seller may also change the order by sending a response with proposed changes.
-
The buyer may cancel the order by sending an order cancellation which may be accepted or rejected by the seller.
-
The seller may cancel the order by sending a negative response with rejection of all lines.
3.2. Scenario 1 – Initial order from buyer
The following diagram shows the business process and choreography for Scenario 1.
| Scenario number | 1 |
|---|---|
Name |
Initial order from buyer |
Description |
|
Parties involved |
Buyer |
Assumptions |
Buyer and seller have a commercial agreement with general conditions for ordering of goods or services. |
The flow |
The buyer creates an Order with one or more lines.
If the seller accepts the order partially or with changes the buyer may either
|
Alternative results |
|
XML example file |
See Appendix A for example files for scenario 1 |
3.3. Scenario 2 – Change of order from buyer
The following diagram shows the business process and choreography for Scenario 2.
| Scenario number | 2 |
|---|---|
Name |
Change of order from buyer |
Description |
|
Parties involved |
Buyer |
Assumptions |
Buyer has sent an initial order which is accepted by seller and the order is confirmed. |
The flow |
The buyer creates an Order Change with changes to one or more order lines.
|
Alternative results |
|
XML example file |
See Appendix A for example files for scenario 2 |
3.4. Scenario 3 – Change of order from seller
The following diagram shows the business process and choreography for Scenario 3.
| Scenario number | 3 |
|---|---|
Name |
Change of order from seller |
Description |
|
Parties involved |
Buyer |
Assumptions |
Buyer has sent an initial order which is accepted by seller and the order is confirmed. |
The flow |
The seller creates an Order Response Advanced with changes to one or more order lines.
|
Alternative results |
|
XML example file |
See Appendix A for example files for scenario 3 |
3.5. Scenario 4 – Cancellation of order from buyer
The following diagram shows the business process and choreography for Scenario 4.
| Scenario number | 4 |
|---|---|
Name |
Cancellation of order from buyer |
Description |
|
Parties involved |
Buyer |
Assumptions |
Buyer has sent an initial order which is accepted by seller and the order is confirmed. |
The flow |
The buyer creates an Order Cancellation to cancel the order.
|
Alternative results |
|
XML example file |
See Appendix A for example files for scenario 4 |
3.6. Scenario 5 – Cancellation of order from seller
The following diagram shows the business process and choreography for Scenario 5.
| Scenario number | 5 |
|---|---|
Name |
Cancellation of order from seller |
Description |
|
Parties involved |
Buyer |
Assumptions |
Buyer has sent an initial order which is accepted by seller and the order is confirmed. |
The flow |
The seller creates an Order Response Advanced with rejection of all lines in an order. |
Result |
The order will be cancelled. |
XML example file |
See Appendix A for example files for scenario 5 |
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 without time zone [hh]:[mm]:[ss]
- format with UTC timezone [hh]:[mm]:[ss]Z
- format for other zones [hh]:[mm]:[ss]±[hh:mm] with zone is given as difference from UTC.
|
Time may 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 |
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 Code list section. 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 code list ICD codes
cac:PartyIdentification<cac:PartyIdentification>
<cbc:ID schemeID="0088">5790000435968</cbc:ID> (1)
</cac:PartyIdentification>| 1 | schemeID attribute is optional, but when used, the codes must be from ICD codes |
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 here: EAS codes.
cbc:EndpointID<cbc:EndpointID schemeID="0184">DK87654321</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.
<cac:SellerSupplierParty>
<cac:Party>
<cbc:EndpointID schemeID="0192">987654325</cbc:EndpointID>
<cac:PartyIdentification>
<cbc:ID schemeID="0192">987654325</cbc:ID>
</cac:PartyIdentification>
<cac:PostalAddress>
<cbc:StreetName>Harbour street</cbc:StreetName>
<cbc:AdditionalStreetName>Dock 45</cbc:AdditionalStreetName>
<cbc:CityName>Bergen</cbc:CityName>
<cbc:PostalZone>5005</cbc:PostalZone>
<cbc:CountrySubentity>Region West</cbc:CountrySubentity>
<cac:AddressLine>
<cbc:Line>Gate 34</cbc:Line>
</cac:AddressLine>
<cac:Country>
<cbc:IdentificationCode>NO</cbc:IdentificationCode>
</cac:Country>
</cac:PostalAddress>
<cac:PartyLegalEntity>
<cbc:RegistrationName>Cod Liver Oil Limited</cbc:RegistrationName>
</cac:PartyLegalEntity>
<cac:Contact>
<cbc:Name>Öystein</cbc:Name>
<cbc:Telephone>+47555444333</cbc:Telephone>
<cbc:ElectronicMail>oystein@codliveroil.no</cbc:ElectronicMail>
</cac:Contact>
</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.
<cac:BuyerCustomerParty>
<cac:Party>
<cbc:EndpointID schemeID="0007">5541277710</cbc:EndpointID>
<cac:PartyIdentification>
<cbc:ID schemeID="0007">5541277710</cbc:ID>
</cac:PartyIdentification>
<cac:PartyName>
<cbc:Name>City Hospital</cbc:Name>
</cac:PartyName>
<cac:PartyLegalEntity>
<cbc:RegistrationName>City Hospital 345433</cbc:RegistrationName>
<cbc:CompanyID schemeID="0007">5541277710</cbc:CompanyID>
<cac:RegistrationAddress>
<cbc:CityName>Eurocity</cbc:CityName>
<cac:Country>
<cbc:IdentificationCode>SE</cbc:IdentificationCode>
</cac:Country>
</cac:RegistrationAddress>
</cac:PartyLegalEntity>
<cac:Contact>
<cbc:Name>Martin Foggerty</cbc:Name>
<cbc:Telephone>+46555785488</cbc:Telephone>
<cbc:ElectronicMail>martin.foggerty@cityhospital.se</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="0088">7300010000001</cbc:ID>
</cac:PartyIdentification>
<cac:PartyName>
<cbc:Name>Surgery Department</cbc:Name>
</cac:PartyName>
<cac:Contact>
<cbc:Name>Dr Bengt</cbc:Name>
<cbc:Telephone>+46555444777</cbc:Telephone>
<cbc:ElectronicMail>bengt@cityhospital.no</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.
<cac:AccountingCustomerParty>
<cac:Party>
<cbc:EndpointID schemeID="0007">5544332215</cbc:EndpointID>
<cac:PartyIdentification>
<cbc:ID schemeID="0007">5544332215</cbc:ID>
</cac:PartyIdentification>
<cac:PartyName>
<cbc:Name>Swedish Hospitals</cbc:Name>
</cac:PartyName>
<cac:PostalAddress>
<cbc:StreetName>High Street 23</cbc:StreetName>
<cbc:AdditionalStreetName>First floor</cbc:AdditionalStreetName>
<cbc:CityName>Trondheim</cbc:CityName>
<cbc:PostalZone>7005</cbc:PostalZone>
<cbc:CountrySubentity>Region M</cbc:CountrySubentity>
<cac:AddressLine>
<cbc:Line>Room 18</cbc:Line>
</cac:AddressLine>
<cac:Country>
<cbc:IdentificationCode>NO</cbc:IdentificationCode>
</cac:Country>
</cac:PostalAddress>
<cac:PartyLegalEntity>
<cbc:RegistrationName>Swedish Hospitals AB</cbc:RegistrationName>
<cbc:CompanyID>5544332215</cbc:CompanyID>
<cac:RegistrationAddress>
<cbc:CityName>Stockholm</cbc:CityName>
<cac:Country>
<cbc:IdentificationCode>SE</cbc:IdentificationCode>
</cac:Country>
</cac:RegistrationAddress>
</cac:PartyLegalEntity>
</cac:Party>
</cac:AccountingCustomerParty>| In order to facilitate the invoicee information to be used in the invoice it is recommended to include as much information as possible, ie.PostalAddress, PartyTaxScheme and PartyLegalEntity in addition to PartyName and PartyIdentification. |
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 codes can be found in Code list section.
<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. |
6.3. Originator document reference
The element `cac:OriginatorDocumentReference/cbc:ID`is used to give a reference to a document that has originated the order, example being the internal requisition on the buyer site on which the order is based.
<cac:OriginatorDocumentReference>
<cbc:ID>2139239</cbc:ID>
</cac:OriginatorDocumentReference>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.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>1x12 pack sauce bags</cbc:Description>
<cbc:Name>White sauce</cbc:Name>
<!-- Code omitted for clarity -->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.
| 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 . |
<cbc:Quantity unitCode="LTR">120</cbc:Quantity>
<cac:Price>
<cbc:PriceAmount currencyID="EUR">6</cbc:PriceAmount>
<cbc:BaseQuantity unitCode="LTR">1</cbc:BaseQuantity>
</cac:Price>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">30</cbc:PriceAmount>
<cbc:BaseQuantity unitCode="NAR">2</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.
-
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</cbc:BaseAmount>(3)
<cac:TaxCategory>
<cbc:ID>S</cbc:ID>
<cbc:Percent>25</cbc:Percent>
<cac:TaxScheme>
<cbc:ID>VAT</cbc:ID>
</cac:TaxScheme>
</cac:TaxCategory>
</cac:AllowanceCharge>
<cac:AllowanceCharge>
<cbc:ChargeIndicator>false</cbc:ChargeIndicator>(2)
<cbc:AllowanceChargeReasonCode>65</cbc:AllowanceChargeReasonCode>
<cbc:AllowanceChargeReason>Production error discount</cbc:AllowanceChargeReason>
<cbc:Amount currencyID="EUR">10</cbc:Amount>
<cac:TaxCategory>
<cbc:ID>S</cbc:ID>
<cbc:Percent>25</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:Price>
<cbc:PriceAmount currencyID="EUR">40</cbc:PriceAmount>
<cac:AllowanceCharge>
<cbc:ChargeIndicator>false</cbc:ChargeIndicator>
<cbc:Amount currencyID="EUR">10</cbc:Amount>
<cbc:BaseAmount currencyID="EUR">50</cbc:BaseAmount>
</cac:AllowanceCharge>
</cac:Price>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:TaxTotal>
<cbc:TaxAmount currencyID="EUR">85.63</cbc:TaxAmount>
</cac:TaxTotal>
<cac:AnticipatedMonetaryTotal>
<cbc:LineExtensionAmount currencyID="EUR">700</cbc:LineExtensionAmount>
<cbc:TaxExclusiveAmount currencyID="EUR">800</cbc:TaxExclusiveAmount>
<cbc:TaxInclusiveAmount currencyID="EUR">885.63</cbc:TaxInclusiveAmount>
<cbc:AllowanceTotalAmount currencyID="EUR">100</cbc:AllowanceTotalAmount>
<cbc:ChargeTotalAmount currencyID="EUR">200</cbc:ChargeTotalAmount>
<cbc:PrepaidAmount currencyID="EUR">135</cbc:PrepaidAmount>
<cbc:PayableRoundingAmount currencyID="EUR">0.37</cbc:PayableRoundingAmount>
<cbc:PayableAmount currencyID="EUR">751.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 Code list UNCL5305 |
| 2 | The TAX percentage rate that applies to the item unless specific trade reasons apply such as exemptions. |
| 3 | Value must identify the correct tax type. For example VAT, GST or sales tax. |
6.12. Order Type Code
Following values may be uses as order type code but shall be treated as synonyms with 220 and process in the same way, unless bi-laterally agreed differently.
Document location |
|
|---|---|
Source codelist |
| Code | Name | Description | Synonym with | UBL Message type |
|---|---|---|---|---|
220 |
Order |
Document/message by means of which a buyer initiates a transaction with a seller involving the supply of goods or services as specified, according to conditions set out in an offer, or otherwise known to the buyer. |
|
|
105 |
Purchase Order |
Document/message issued within an enterprise to initiate the purchase of articles, materials or services required for the production or manufacture of goods to be offered for sale or otherwise supplied to customers. |
220 |
|
221 |
Blanket order |
Usage of document/message for general order purposes with later split into quantities and delivery dates and maybe delivery locations. |
220 |
|
226 |
Call off order |
Document/message to provide split quantities and delivery dates referring to a previous blanket order. |
220 |
|
227 |
Consignment order |
Order to deliver goods into stock with agreement on payment when goods are sold out of this stock. |
220 |
|
402 |
Intermediate handling cross docking order |
An order requesting the supply of products which will be moved across a dock, de-consolidated and re-consolidated according to the final delivery location requirements. |
220 |
|
7. Description of selected parts of the Order Response Advanced message
Order Response Advanced is used in this profile because the order change reference is not present in Order Response. The rest of the message is unchanged. The Order Response Advanced message is sent from the seller to the buyer stating the sellers ability to fulfill the order. The following rules applies to the Order Response Advanced:
-
The Order Response Advanced must refer to an Order.
-
The Order Response Advanced may refer to an Order Change.
-
Seller may accept or reject the entire Order.
-
If the order or any order line is rejected the Order Response Advanced 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 Advanced. This applies even for order lines that has been delivered completely or partially.
-
The following information may be changed in the Order Response Advanced:
-
Quantity
-
Delivery period
-
Replacement item
-
Price
-
-
If the Order is rejected or changed, the Order Response Advanced may contain contact information to seller.
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><OrderResponse
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>101</cbc:ID>
<cbc:IssueDate>2013-07-01</cbc:IssueDate>
<cbc:IssueTime>06:10:10</cbc:IssueTime>
<cbc:OrderResponseCode>AB</cbc:OrderResponseCode> (1)
<cbc:Note>Response message with amendments in the details</cbc:Note>
<cbc:DocumentCurrencyCode>EUR</cbc:DocumentCurrencyCode>
<cbc:CustomerReference>YourRef</cbc:CustomerReference>
<cac:OrderReference>
<cbc:ID>1</cbc:ID>
</cac:OrderReference>
<cac:SellerSupplierParty>
<cac:Party>
<cbc:EndpointID schemeID="0007">5546577791</cbc:EndpointID>
<cac:PartyIdentification>
<cbc:ID schemeID="0007">5546577791</cbc:ID>
</cac:PartyIdentification>
<cac:PartyLegalEntity>
<cbc:RegistrationName>The Supplier AB</cbc:RegistrationName>
</cac:PartyLegalEntity>
</cac:Party>
</cac:SellerSupplierParty>
<cac:BuyerCustomerParty>
<cac:Party>
<cbc:EndpointID schemeID="0007">5541277710</cbc:EndpointID>
<cac:PartyIdentification>
<cbc:ID schemeID="0007">5541277710</cbc:ID>
</cac:PartyIdentification>
<cac:PartyLegalEntity>
<cbc:RegistrationName>City Hospital</cbc:RegistrationName>
</cac:PartyLegalEntity>
</cac:Party>
</cac:BuyerCustomerParty>
<cac:Delivery>
<cac:PromisedDeliveryPeriod>
<cbc:StartDate>2013-07-15</cbc:StartDate>
<cbc:EndDate>2013-07-16</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
| 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. |
<cbc:LineStatusCode>3</cbc:LineStatusCode>7.2. Order reference
Reference to the related order must be done on Header level.
<cac:OrderReference>
<cbc:ID>1</cbc:ID>
</cac:OrderReference>If lines are sent in the Order Response Advanced, reference to the related order line must be sent.
<cac:OrderLineReference>
<cbc:LineID>1</cbc:LineID>
</cac:OrderLineReference>7.3. Order change reference
Reference to an order change must be done on Header level.
<cac:OrderChangeDocumentReference>
<cbc:ID>c-1</cbc:ID>
</cac:OrderChangeDocumentReference>7.4. Order Response Advanced 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
-
-
<cac:OrderLine>
<cac:LineItem>
<cbc:ID>3</cbc:ID>
<cbc:LineStatusCode>3</cbc:LineStatusCode>
<cbc:Quantity unitCode="NAR">23</cbc:Quantity>
<cac:Item>
<cbc:Name>Pepper sauce</cbc:Name>
<cac:SellersItemIdentification>
<cbc:ID>SN-35</cbc:ID>
</cac:SellersItemIdentification>
</cac:Item>
</cac:LineItem>
<cac:OrderLineReference>
<cbc:LineID>3</cbc:LineID>
</cac:OrderLineReference>
</cac:OrderLine><cac:OrderLine>
<cac:LineItem>
<cbc:ID>4</cbc:ID>
<cbc:LineStatusCode>3</cbc:LineStatusCode>
<cbc:Quantity unitCode="EA">18</cbc:Quantity>
<cac:Delivery>
<cac:PromisedDeliveryPeriod>
<cbc:StartDate>2013-07-15</cbc:StartDate>
<cbc:EndDate>2013-07-15</cbc:EndDate>
</cac:PromisedDeliveryPeriod>
</cac:Delivery>
<cac:Item>
<cbc:Name>Wet tissues</cbc:Name>
</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 Advanced line per Order line. |
<cac:OrderLine>
<cac:LineItem>
<cbc:ID>5</cbc:ID>
<cbc:LineStatusCode>1</cbc:LineStatusCode>
<cbc:Quantity unitCode="EA">12</cbc:Quantity>
<cac:Delivery>
<cac:PromisedDeliveryPeriod>
<cbc:StartDate>2013-08-15</cbc:StartDate>
<cbc:EndDate>2013-08-15</cbc:EndDate>
</cac:PromisedDeliveryPeriod>
</cac:Delivery>
<cac:Item>
<cbc:Name>Wet tissues</cbc:Name>
</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.
-
<cac:OrderLine>
<cac:LineItem>
<cbc:ID>6</cbc:ID>
<cbc:LineStatusCode>3</cbc:LineStatusCode>
<cac:Item>
<cbc:Name>Wet tissues</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>Wet tissues</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="MP" listVersionID="20.0601">14111511</cbc:ItemClassificationCode>(2)
</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 |
| 2 | Attribute listID="MP" indicates UNSPSC, and the attribute listVersionID is used to indicate the version of UNSPSC that is used. |
7.5. Order Response Advanced replacing items and delivering over time.
An Order Response Advanced may replace items in two ways. If the full quantity of an item is replaced that information can be provided by using the Seller substituted line item element as shown in the following example.
<cac:OrderLine>
<cac:LineItem>
<cbc:ID>6</cbc:ID>
<cbc:LineStatusCode>3</cbc:LineStatusCode>
<cac:Item>
<cbc:Name>Wet tissues</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>Wet tissues</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="MP" listVersionID="20.0601">14111511</cbc:ItemClassificationCode>(2)
</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 part of the quantity or delivers the order quantity at different dates he may need to add lines and/or mark ordered lines as being delivered as demonstrated in the following example.
In the example a seller confirms the first line of an order, provides two delivery dates for second order line of 3 pieces of Product B by adding a new line and then confirms that order line 3 has already been delivered.
<cac:OrderLine>
<cac:LineItem>
<cbc:ID>11</cbc:ID>
<cbc:LineStatusCode>5</cbc:LineStatusCode>
<cac:Item>
<cbc:Name>Product 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>10</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>Product 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>7</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>Product 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>8</cbc:ID>
<cbc:LineStatusCode>42</cbc:LineStatusCode>
<cac:Item>
<cbc:Name>Product 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.6. Order Response Advanced with backorder.
An Order Response Advanced 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, maximum backorder quantity should be set to 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-07-05</cbc:StartDate>
</cac:PromisedDeliveryPeriod>
</cac:Delivery>
<cac:Item>
<cbc:Name>Product 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.7. 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 Code list UNCL5305 |
| 2 | The TAX percentage rate that applies to the item unless specific trade reasons apply such as exemptions. |
| 3 | Value must identify the correct tax type. For example VAT, GST or sales tax. |
10. 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:
10.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. |
10.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 |
urn:fdc:peppol.eu:poacc:bis:advanced_ordering:3 |
Order response advanced (Trdm116) |
urn:fdc:peppol.eu:poacc:trns:order_response_advanced:3 |
|
Order change (Trdm114) |
urn:fdc:peppol.eu:poacc:trns:order_change:3 |
|
Order cancellation (Trdm115) |
urn:fdc:peppol.eu:poacc:trns:order_cancellation:3 |