This document describes the new version of EHF Ordering (called "EHF Ordre" in Norwegian). The document is part of Norwegian Agency for Public and Financial Management (DFØ) standardization work related to electronic commerce.

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

1.1. Scope

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

1.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
cac:BuyerCustomerParty

The buyer is the legal person or organization acting on behalf of the customer and who buys or purchases the goods or services.

Seller
cac:SellerSupplierParty

The seller is the legal person or organization acting on behalf of the supplier and who sells goods or services to the customer.

Originator
cac:OriginatorCustomerParty

A person or unit that initiates an order.

Invoicee
cac:AccountingCustomerParty

A person or unit that receives the invoice (invoicee) on behalf of the customer.

Consignee
cac:Delivery/cac:DeliveryLocation

A person or unit to where the seller, or a despatching party on behalf of the seller, delivers the goods.

Delivery party
cac:Delivery/cac:DeliveryParty

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.

Roles in ordering

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

1.3. Interoperability

This Peppol EHF structure is based on the European Interoperability Framework 2.0 EIF. This Peppol EHF applies the Framework as follows:

Legal Interoperability
  • Legal:

    • In implementations supporting public sector buyers, the use of this EHF 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 EHF supports B2B and B2G.

    • This Peppol EHF supports cross border, regional and domestic ordering in EU and EEA.

    • This Peppol EHF can function as a component in an EDI agreement within a trading community.

    • This Peppol EHF 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 EHF 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 EHF.
        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.2, see UBL 2.2

    • ISO/IEC 19757-3 Schematron, for automation of document validation, see Schematron

  • Technical Interaction (eSignature Validation):

    • Not mandatory in this Peppol EHF. Not supported.

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

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

2.2. Process Business requirements

A seller may either:

  • Accept the Order in full

  • Reject the entire Order

  • Accept the Order partially.

  • Accept the Order with changes, if there is an agreement in place with the buyer on how to establish buyers agreement on the change.

  • There may be several Order Responses for one Order

  • One Order Response may only refer to one Order

2.3. Business process Diagram

2.3.1. Legend for BPMN diagrams

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

bpmn legend
Figure 1. BPMN legend

The following diagram shows the choreography of the business process implemented by the EHF.

bpmn ordering

2.4. Use case 1 – Ordering of numbered items/articles

This use case contains an order of numbered items/articles.

Description
  • An order of numbered articles.

  • The order instructs the seller of the delivery address. The seller can deliver some of the items but not all.

  • One item needs to be replaced.

Parties involved

Buyer
Seller

Assumptions

The buyer has a catalogue or list of products to order.
The catalogue contains the item numbers, names and type of unit of measure.

Flow

The buyer creates the order with 3 different lines and items.
The seller receives the order.

  • Accepts to deliver one item.

  • Rejects one item.

  • Replaces one item.

Result

The buyer and the seller has reached an agreement.
The buyer has updated the order information based on the response.
If the invoice has an order reference, the invoice can be matched automatically.

2.5. Use case 2 – Ordering of free text articles

This use case contains an order of free text articles.

Description

An order with item/articles described in free text and attribute/value pairs.
The seller responds with the proper item names.
All lines are accepted.

Parties involved

Buyer
Seller
Originator

Assumptions

The buyer does not have structured item information.

The buyer must specify the items in a way that ensures that the seller can properly identify the requested items.

Flow

The buyer creates the order with 2 different lines and items.
The seller:

  • Accepts to deliver all items

  • Full item information is returned in the response.

Result

The buyer and the seller has reached an agreement.
The buyer has updated the order information based on the response.+ If the invoice has an order reference, the invoice can be matched automatically.

2.6. Use case 3 – Ordering of services

This use case contains an order of services.

Description

An order of translation services.
Delivery location and period is specified.
The seller rejects the order.

Parties involved

Buyer
Seller

Assumptions

The buyer is using a form with pre-defined and agreed properties for this service.

Flow

The buyer creates the order with one line requesting translation between Swedish and Spanish.

The seller rejects the order.

Result

The buyer and the seller has not reached any agreement.

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

Description

An order for numbered items with allowance and charges both on order level, line level and price.

Parties involved

Buyer
Seller
Originator

Assumptions

The buyer has a catalogue or list of products to order.
The catalogue contains the item numbers, names and type of unit of measure.
The buyer has reached a special agreement with the seller regarding discounts on the order, order lines and price.

Flow

The buyer creates the order with 4 different lines and items.

The seller accepts to deliver all 4 items.

Result

The buyer and the seller has reached an agreement.
The buyer has updated the order information based on the response.
If the invoice has an order reference, the invoice can be matched automatically.

3. Description of selected parts of the order message

3.1. Parties

The following parties/roles may be specified in the message:

3.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 EHF Order message.

Example of seller information
<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>

3.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 EHF Order message.

Example of buyer information
<cac:BuyerCustomerParty>
  <cac:Party>
    <cbc:EndpointID schemeID="0007">5541277711</cbc:EndpointID>
    <cac:PartyIdentification>
      <cbc:ID schemeID="0007">5541277711</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">5541277711</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>

3.1.3. OriginatorCustomerParty (Originator)

The unit initiating the order. Most often the end user. The originator information is optional in the Peppol EHF Order message.

Example of originator information
<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>

3.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 EHF Order message.

Example of invoicee information
<cac:AccountingCustomerParty>
  <cac:Party>
    <cbc:EndpointID schemeID="0007">5544332211</cbc:EndpointID>
    <cac:PartyIdentification>
      <cbc:ID schemeID="0007">5544332211</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>5544332211</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.

3.2. Attachments

Non-XML documents can be sent as attachments to the Peppol EHF 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.

Example of attachment as an embedded, binary object
<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.

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

UBL example of originator reference
<cac:OriginatorDocumentReference>
  <cbc:ID>2139239</cbc:ID>
</cac:OriginatorDocumentReference>

3.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
Example of an Peppol EHF Order item using both Sellers ID and Standard ID (GTIN):
<cac:SellersItemIdentification>
  <cbc:ID>SN-33</cbc:ID>
</cac:SellersItemIdentification>

<cac:StandardItemIdentification>
  <cbc:ID schemeID="0160">05704066204093</cbc:ID>
</cac:StandardItemIdentification>

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

Example in an Peppol EHF Order message:
<cac:Item>
 <cbc:Description>1x12 pack sauce bags</cbc:Description>
 <cbc:Name>White sauce</cbc:Name>

  <!-- Code omitted for clarity -->

3.6. Quantities and units

Various quantities and units can be stated in the Peppol EHF 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
(cbc:BaseQuantity)

Quantity related to Price.

Order Quantity
(cbc:Quantity)

Quantity that is ordered, e.g. number of pieces or volume in litre .

Example of an order line with a quantity of 120 litre (cbc:Quantity) and price is given per 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>

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

Example of price information in an Order message:
<cac:Price>
  <cbc:PriceAmount currencyID="EUR">30</cbc:PriceAmount>
  <cbc:BaseQuantity unitCode="NAR">2</cbc:BaseQuantity>
</cac:Price>

3.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:TaxCategory with sub elements, shall be supplied

  • The sum of all allowances and charges on the header level shall be specified in cbc:AllowanceTotalAmount and cbc:ChargeTotalAmount respectively. 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)\$

UBL example of Allowances and Charges on the document level where TAX = VAT.
<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)\$
UBL example showing a discount on price of EUR 10:
<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>

3.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"\$
\$– \ "cac:AnticipatedMonetaryTotal/cbc:AllowanceTotalAmount"\$
\$+ \ "cac:AnticipatedMonetaryTotal/cbc:ChargeTotalAmount"\$

<cbc:TaxInclusiveAmount>

Order total amount included TAX

\$\ \ \ \ "cac:AnticipatedMonetaryTotal/cbc:TaxExclusiveAmount"\$
\$+ \ "cac:TaxTotal/cbc:TaxAmount"\$

<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"\$
\$- \ "cac:AnticipatedMonetaryTotal/cbc:PrepaidAmount"\$
\$+ \ "cac:AnticipatedMonetaryTotal/cbc:PayableRoundingAmount"\$

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

Note that the AnticipatedMonetaryTotals class is optional. If the class is included in the message, the only mandatory elements are the cbc:LineExtensionAmount and the cbc:PayableAmount elements. All other elements are optional. When optional elements are used, the content MUST be according to the formulas in the table above.*

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

3.9.2. Example of calculations:

Description Element Sample amounts

Sum of line amounts

cbc:LineExtensionAmount

700

Allowance on document level

cbc:AllowanceTotalAmount

100.00

Charges on document level

cbc:ChargeTotalAmount

200.00

Order total amount without TAX

cbc:TaxExclusiveAmount

800

TAX total amount

cac:TaxTotal/cbc:TaxAmount

85.63

Rounding of Order total

cbc:PayableRoundingAmount

0.37

Order total with TAX (value of purchase)

cbc:TaxInclusiveAmount

885.63

Paid amounts

cbc:PrepaidAmount

135.00

Amount expected to be paid

cbc:PayableAmount

751.00

The above example is presented in the order in the following way:
<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>

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

Example of tax total (header level)
<cac:TaxTotal>
  <cbc:TaxAmount currencyID="EUR">268.75</cbc:TaxAmount>
</cac:TaxTotal>

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

UBL example of line TAX category, when TAX is VAT
<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 Value must identify the correct tax type. For example VAT, GST or sales tax.

4. 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 EHF 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. This applies even for order lines that has been delivered completely or partially.

  • The following information may be changed in the Order response:

    • Quantity

    • Delivery period

    • Replacement item

    • Price

  • If the Order is rejected or changed, the Order response may contain contact information to Seller.

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

  • Response code must be sent on header level.

  • Line response code must be sent on line level if lines are sent.

  • Response code may have 4 values: AB, RE, AP and CA (subset of UNCL 4343 code list)

  • Line response code may have 5 values: 1, 3, 5, 7 and 42.

4.1.1. Response code on Header level

Response code Action

AB

  • The Order has been received.

  • The Order has not yet been processed.

  • No lines should be sent.

  • An additional order response should be sent after processing, to accept, reject or accept with changes

RE

  • The Order is rejected.

  • No lines should be sent.

AP

  • The Order is accepted without amendment.

  • No lines should be sent.

CA

  • The Order is accepted with amendment on line level.

  • All lines must be sent.

UBL example of Response code on Header level in an Order Response message
<cbc:OrderResponseCode>CA</cbc:OrderResponseCode>
UBL example of an order response using response code "AB" (order is received
<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>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">5546577799</cbc:EndpointID>
      <cac:PartyIdentification>
  <cbc:ID schemeID="0007">5546577799</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">5541277711</cbc:EndpointID>
      <cac:PartyIdentification>
  <cbc:ID schemeID="0007">5541277711</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.

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

Example of Response code on Line level in an Order Response message:
<cbc:LineStatusCode>3</cbc:LineStatusCode>

4.2. Order reference

Reference to the related order must be done on Header level.

Example of order reference on header level in a Peppol EHF Order Response
<cac:OrderReference>
  <cbc:ID>1</cbc:ID>
</cac:OrderReference>

If lines are sent in the Order Response, reference to the related order line must be sent.

Example of order line reference on line level:
<cac:OrderLineReference>
  <cbc:LineID>1</cbc:LineID>
</cac:OrderLineReference>

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

Example of change of quantity in an Order Response message:
<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>
Example of change of quantity and delivery period in an Order Response message:
<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 line per Order line.
Example of change of quantity and delivery period for the same Order line as in the example above.
<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.

Example of Replacement item in an Order Response message:
<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.

4.4. Order response replacing items and delivering over time.

An order response 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 in the invoice response as shown in the following example.

Example of Replacement item in an Order Response message:
<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.

Example of adding lines and delivering over time:
<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>

4.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.
Example showing a response to an order of 6 items of which 2 get confirmed delivery dates and 3 are placed on backorder to be delivered later, for a total delivery of up to 5 items
<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>

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

UBL example of line TAX category, when TAX is VAT
<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 Value must identify the correct tax type. For example VAT, GST or sales tax.

Appendix A: UBL 2.2

This implementation guide builds on UBL 2.2 Schemas, available from OASIS.

These schemas are used when performing syntax validation.

Please see the homepage for information about the standard or further resources available.

Appendix B: 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.

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

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

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

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

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

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

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

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

B.2.7. Date

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

Dates shall not include timezone information.
Table 1. EN 16931_ Date. Type
Component Use Primitive Type Example

Content

Mandatory

Date

2017-12-01

B.2.8. Time

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

Time shall not include timezone information. Decimal fraction on seconds SHALL not be used.
Table 2. EN 16931_ Date. Type
Component Use Primitive Type Example

Content

Mandatory

Date

09:30:12

B.2.9. Document Reference

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

Table 3. Document Reference. Type
Component Use Primitive Type Example

Content

Mandatory

String

abc:123-DEF

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

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

B.2.12. Boolean

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

Component Use Primitive Type Example

Content

Mandatory

String

true