This document describes the data formats used when trading partners exchange order agreement electronically (Norwegian: Elektronisk Handelsformat; EHF). It is prepared as part of the initiative taken by the Norwegian “Agency of Public Management and eGovernment” (Difi) within the standardization of electronic trade processes.
|
Reporting bugs
Please use Github Issues to report bugs and lack of content when discovered.
Users currently not registered on Github may create an account for free.
|
1. Introduction
1.1. Background and Objective
The government white paper labeled “St.Meld. nr. 36 (2008-2009) Det gode innkjøp” (The good procurement), states among other things:
It’s the Government’s opinion that increased use of electronic solutions is important to improve and increase the efficiency of public procurement. The use of electronic solutions may reduce time spent on public procurement, increase the competition and arrange for purchases to be more transparent and easier to re-examine. By spending less time and money on procurement, resources will be available for both modernizing the public sector and more welfare. The goal for introducing electronic solutions is to contribute to a better, simpler and more secure procurement.
The previous «Ministry of Government Administration, Reform and Church Affairs» (FAD) considered use of open standards as a vital means to build a well-functioning public administration, with good internal collaboration and a high level of service for both inhabitants and businesses.
An open standard is characterized by its reputation and will be maintained by a non-commercial organization, and the continuing development is based on decision processes open to every interested party. The standard is published and the documentation is available, either free of charge or for a small, insignificant fee. Anyone must be allowed to copy, distribute and use the standard free of charge or for a small, insignificant fee. The intellectual rights related to the standard (e.g. patents) are irrevocably available, without any royalties. There is no reservation regarding re-use of the standard.
The purpose of this document is to describe a common format for invoice messages in the Norwegian market, and to facilitate an efficient implementation and increased use of electronic collaboration regarding the invoicing process based on this format.
1.2. Audience
The audience for this document is organizations wishing to be EHF enabled for exchanging electronic orders, 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
1.3. Scope
The intended scope for this EHF includes business-to-government (B2G) and business-to-business (B2B) relationships. Although the EHF is a basis for an EDI agreement between two parties, it does not address all business level details of such an agreement/contract.
The order agreement represents the combined information of an order and an order confirmation, i.e. it represents an agreement entered upon by seller and buyer. The transaction, specified in this EHF is intended to be exchanged between the seller’s order management system and the of buyer’s purchasing system so that their respective systems get syncronised with regard to the information on the purchase.
This is an auxiliary EHF intended to complement the primary ordering EHF, such as EHF Ordering. It allows the buyer to have information from less formalized purchase processes conveniently fed into the procurement system, thereby giving control over corresponding payments and better statistics. By opening for order agreement transactions, it is very important that the buyer’s system can verify that the seller is allowed to send an order agreement and that the process is described in the contract between seller and buyer to prevent fraud and to secure good quality in the transaction.
2. Changelog
2.1. Consequences of Implementing this version
Version 1.0.4 is a revision of EHF Order Agreement 1.0, and this version is backwards compatible to EHF Order Agreement 1.0. This means that any instance documents valid towards EHF Order Agreement 1.0 is also valid in version 1.0.4. Please note that valid here reflects the validity against the implementation guide of EHF Order Agreement 1.0, as this is the normative reference.
2.2. Version 1.x
Version 1.0.3 (2019-02-27)
| Issue | Description | Type |
|---|---|---|
- |
Fixing syntax, resulting in updated basic validation rules. |
Syntax |
| Validation rules expected to be updated to trigger error in next release: All basic validation rules (EHF-TXX-BXXXXXX). |
Version 1.0.2 (2018-11-15)
| Issue | Description | Type |
|---|---|---|
- |
Moving example files into a example file archive. Appendix is updated with the new link. |
Guide |
- |
Replacing listing of validation rules with links to all relevant validation rules. |
Guide |
- |
Adding "basic" validation rules automatically created from syntax. Rules are identified as 'EHF-T77-BXXXXX' where 'XXXXX' is a running number. |
Validator |
| Validation rules expected to be updated to trigger error in next release: All basic validation rules (EHF-TXX-BXXXXXX). |
3. Electronic Commerce Format (EHF)
3.1. About EHF
EHF is an anagram of the Norwegian expression «Elektronisk handelsformat» (Electronic Commerce Format).
EHF is based on the work performed by CEN BII. This is further adjusted to comply with the Norwegian accounting regulations and current practices for the different business processes in the Norwegian market. Difi pursues the goal to cover the full trading process using EHF documents, both before and after awarding (signing of a contract).
Documents, from the tender catalogue to the credit note will be gathered under the EHF umbrella. During 2013 Difi will prepare for the use of EHF formats in what is known as the post award process, i.e. the part of the business process that starts when a supplier and a customer have signed a contract.
By using the EHF documents the collaboration between the supplier and the customer will be predictable. Elements from the tender Catalogue will be re-used in the Order, and elements from the Order will be re-used in the Invoice. This leads to a holistic use of all the documents under the EHF umbrella.
Difi has chosen to use CEN BII as a base for the EHF formats and the Universal Business Language (UBL) as a foundation for the implemented syntax. Both EHF and UBL are open standards and as such not liable to any licensing fees or royalties.
EHF is managed and maintained by Difi.
3.2. Information Consistency
The different EHF formats mentioned above contain a number of common information elements (supplier, customer, item etc.). It is important to preserve consistency in those common information elements, and that means that elements with identical content are declared in the same way and as far as possible given the same element tag name.
EHF invoicing formats will for instance re-use elements from the Catalogue and Order to ensure consistency between the messages and to make sure that the information from the business transactions are reflected in the invoicing documents. This makes it possible to implement an efficient and automated control of the invoice and the originating transactions.
3.3. Empty Elements
The use of empty elements is prohibited in UBL, which is the base for EHF. The reason for this, is that empty elements may be interpreted to have a certain meaning, it could mean that the information was not available at the time of sending as an example. In addition, numeric- and date elements have requirements that would generate validation errors if they were empty.
| The use of empty elements is, for the above mentioned reasons, not allowed in EHF. |
3.4. Use of Collaboration Agreements
The combination of the ELMA registration and the implementation guides referred to in that context eliminates the need for any formal collaboration agreement between the sender and the receiver. The ELMA registration verifies that an actor has declared the ability and the commitment to receive business documents composed according to the specific implementation guide, and any party is free to send the business document to this actor.
Exchanging Catalogue and Order requires no registration in ELMA, and actors are advised to include the use of electronic messages in the purchase contract or to supply an collaboration agreement as an attachment, in order to link the electronic collaboration with the mercantile regulations and thus achieve a regularly revision of the electronic process.
3.5. Versioning
Difi claims the right to exchange the current format with a new one as and when needed. If so, Difi will inform the public via the web site and their registered users via e-mail.
Difi manages the formats in this way:
- Main Version
-
A new main version will be announced at least 5 months prior to release. When a main version is released, there will be at least a 12 months implementation period before the new version is made mandatory.
Difi intends to relate every main version to the regulations concerning IT standards in the public sector.
- Sub Version
-
A new sub version will be announced at least 3 months prior to release and is made mandatory 5 months after release.
All sub versions must be backwards compatible. 2 months after the new sub version has become mandatory, the support (validation service and implementation guide) is ceased for preceding versions.
- Revision
-
A revision is in principle a result of bug fixing the latest sub version, and will be announced at release time and should be implemented without further delay.
4. Principles and prerequisites
This chapter describes the principles and assumptions that underlie the use of EHF Order Agreement. It is based on the CENBII 42 Order Agreement.
This profile identifies, explains and justifies the business requirements for the Order agreement process. It provides syntax bindings to OASIS UBL 2.1. It also includes a syntax implementation guide.
Use of EHF Order agreement differs from an EHF Order/confirmation process. In EHF order agreement process there is no EHF Order in advance. Typically corresponding orders are made by ex. phone, mail etc.
The EHF order agreement profile describes processes where the buyer, after purchasing items/services, receives a message with information documenting the purchase.
4.1. Prerequisites
The following are prerequisites for this EHF:
-
A buyer has purchased goods or services from the seller by any means.
-
The seller has to be registered in the buyer system with information as contact information and identifiers used for other EHF transaction e.g. EHF order and invoice (Organization number…)
4.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 part, debtor, contracting body. |
Supplier |
The supplier is the legal person or organization who provides a product or service. Examples of supplier roles: seller, consignor, creditor, economic operator. |
| Role/actor | Description |
|---|---|
Buyer |
(BuyerCustomerParty) The buyer is the legal person or organization acting on behalf of the customer and who buys or purchases the goods or services. |
Seller |
(SellerSupplierParty) The seller is the legal person or organization acting on behalf of the supplier and who sells goods or services to the customer. |
The following diagram links the business processes to the roles performed by the Business Partners.
4.3. Benefits
-
The ability to use existing order-invoice-matching processes even if order is not issued from a procurement system.
-
Capture ordering actions that happen in other processes such as web shops, phone or by requisition at warehouse/store and so forth.
-
Visibility of whole spending analysis in the ordering module by importing orders that are not sent directly from the ordering module.
-
Support for ordering processes where products/services are not necessarily described as standardized catalogue items.
4.4. Process flow
The order agreement process flow can be described as follows:
Start position.
-
A Buyer makes a purchase of goods or services from the Seller.
-
A Seller reports one or more accumulated purchases made under a framework agreement to the Buyer.
End positions.
-
A purchase has been recorded in the Buyer´s purchasing system. The seller proceeds to invoice accordingly.
An Order Agreement may refer to a framework agreement for its terms and conditions; otherwise the Buyer’s terms and conditions apply.
4.4.1. Process diagram
The following diagram shows the choreography of the business process implemented by the EHF.
| Categories | Description and Values |
|---|---|
Description |
The buyer doesn’t use the purchasing system to create an order. It’s done outside of this system. The seller creates an order in his ordering system based on requirements from the buyer and, after agreeing/committing to it, sends a copy of the order as an Order agreement to the buyer. |
Pre-conditions |
The seller’s ordering system must be able to send Order agreement transactions. The buyer’s purchasing system must be able to receive Order agreement transactions. The content of the order is agreed through use of web shop, phone, email, physical visit to shop or other means. |
Post-conditions |
The buyer has received an order agreement that is recorded in the purchasing system. |
Legal Implications |
By providing an Order agreement transaction the Seller commits himself the, quantities, prices and terms stated in the Order agreement transaction. |
5. Use cases
Use case files are provided to help implementers. This implementation guide contains these files:
The order agreement EHF includes the sending of information on agreed products/services from a Seller to a Buyer.
6. Description of selected parts of the order agreement message
Following clauses describe the use of individual sections of the order agreement transaction.
6.1. Parties/roles
The following parties/roles may be specified in the message:
6.1.1. SellerSupplierParty
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 EHF Order Agreement message.
<cac:SellerSupplierParty>
<cac:Party>
<cbc:EndpointID schemeID="NO:ORGNR">987654321</cbc:EndpointID>
<cac:PartyIdentification>
<cbc:ID schemeID="NO:ORGNR">987654321</cbc:ID>
</cac:PartyIdentification>
<cac:PartyName>
<cbc:Name>Information services</cbc:Name>
</cac:PartyName>
<cac:PostalAddress>
<cbc:StreetName>Storgata 34</cbc:StreetName>
<cbc:AdditionalStreetName>rom 123</cbc:AdditionalStreetName>
<cbc:CityName>Storevik</cbc:CityName>
<cbc:PostalZone>1234</cbc:PostalZone>
<cbc:CountrySubentity>Region A</cbc:CountrySubentity>
<cac:Country>
<cbc:IdentificationCode listID="ISO3166-1:Alpha2">NO</cbc:IdentificationCode>
</cac:Country>
</cac:PostalAddress>
<cac:Contact>
<cbc:Name>Ola Nordmann</cbc:Name>
<cbc:Telephone>123456</cbc:Telephone>
<cbc:Telefax>123456</cbc:Telefax>
<cbc:ElectronicMail>mail@jobb.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 EHF Order Agreement message.
<cac:BuyerCustomerParty>
<cac:Party>
<cbc:EndpointID schemeID="NO:ORGNR">987654325</cbc:EndpointID>
<cac:PartyIdentification>
<cbc:ID schemeID="NO:ORGNR">987654325</cbc:ID>
</cac:PartyIdentification>
<cac:PartyName>
<cbc:Name>AS Innkjøper</cbc:Name>
</cac:PartyName>
<cac:PostalAddress>
<cbc:StreetName>Hovedgata 23</cbc:StreetName>
<cbc:AdditionalStreetName>Bakdøra</cbc:AdditionalStreetName>
<cbc:CityName>Lillevik</cbc:CityName>
<cbc:PostalZone>8523</cbc:PostalZone>
<cbc:CountrySubentity>Region B</cbc:CountrySubentity>
<cac:Country>
<cbc:IdentificationCode listID="ISO3166-1:Alpha2">NO</cbc:IdentificationCode>
</cac:Country>
</cac:PostalAddress>
</cac:Party>
<cac:DeliveryContact>
<cbc:Name>Kari Navnesen</cbc:Name>
<cbc:Telephone>123456</cbc:Telephone>
<cbc:Telefax>123456</cbc:Telefax>
<cbc:ElectronicMail>kari@innkjoper.no</cbc:ElectronicMail>
</cac:DeliveryContact>
</cac:BuyerCustomerParty>6.1.3. OriginatorCustomerParty (Originator)
The unit initiating the order. Most often the end user. The originator information is optional in the EHF Order Agreement message.
<cac:OriginatorCustomerParty>
<cac:Party>
<cac:PartyIdentification>
<cbc:ID schemeID="NO:ORGNR">987654321</cbc:ID>
</cac:PartyIdentification>
<cac:PartyName>
<cbc:Name>Information services</cbc:Name>
</cac:PartyName>
</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 EHF Order Agreement message.
<cac:AccountingCustomerParty>
<cac:Party>
<cac:PartyIdentification>
<cbc:ID schemeID="NO:ORGNR">987654325</cbc:ID>
</cac:PartyIdentification>
<cac:PartyName>
<cbc:Name>Information services</cbc:Name>
</cac:PartyName>
</cac:Party>
</cac:AccountingCustomerParty>6.2. Delivery
Delivery gives information on when and where the goods and services are delivered.
Delivery special terms may be used to inform how the goods or service is delivered. E.g.
-
A ticket may be delivered as a pdf in mail - “Mail”.
-
Goods may have been collected at the store – “Customer pick up“
The delivery information is optional in the EHF Order Agreement message.
<cac:Delivery>
<cac:PromisedDeliveryPeriod>
<cbc:StartDate>2017-10-15</cbc:StartDate>
<cbc:StartTime>12:00:00</cbc:StartTime>
<cbc:EndDate>2017-11-15</cbc:EndDate>
<cbc:EndTime>18:00:00</cbc:EndTime>
</cac:PromisedDeliveryPeriod>
<cac:DeliveryParty>
<cac:PartyIdentification>
<cbc:ID schemeID="NO:ORGNR">98765432</cbc:ID>
</cac:PartyIdentification>
<cac:PartyName>
<cbc:Name>Delivery party name</cbc:Name>
</cac:PartyName>
</cac:DeliveryParty>
<cac:DeliveryTerms>
<cbc:ID>id</cbc:ID>
<cbc:SpecialTerms>special terms</cbc:SpecialTerms>
<cac:DeliveryLocation>
<cbc:ID>id</cbc:ID>
<cac:Address>
<cbc:StreetName>Hovedgata 23</cbc:StreetName>
<cbc:AdditionalStreetName>Bakdøra</cbc:AdditionalStreetName>
<cbc:CityName>Lillevik</cbc:CityName>
<cbc:PostalZone>8523</cbc:PostalZone>
<cbc:CountrySubentity>Region B</cbc:CountrySubentity>
<cac:Country>
<cbc:IdentificationCode listID="ISO3166-1:Alpha2">NO</cbc:IdentificationCode>
</cac:Country>
</cac:Address>
</cac:DeliveryLocation>
</cac:DeliveryTerms>
</cac:Delivery>6.3. References
When sending the order agreement transaction the seller may include a reference that the buyers gave to him during the purchase. This reference can be of different nature and since it originates from the buyer it is understood by him.
<cbc:CustomerReference>Buyer reference id tir110-044</cbc:CustomerReference>The order agreement may refrence a previous order agreement. This may be relevant, as example, when the buyer has changed a previous order.
<cac:OrderReference>
<cbc:ID>Order id tir110-042</cbc:ID>
</cac:OrderReference>The order agreement may reference a contract that applies to the purchase.
<cac:Contract>
<cbc:ID>contract id tir110-049</cbc:ID>
<cbc:ContractType>Framwork agreement tir110-050</cbc:ContractType>
</cac:Contract>6.4. Attachments on header level
Non-XML documents can be sent as attachments to the EHF Order Agreement. This could be timesheets or other documents relevant for the order agreement. The attachment can either be sent as a binary object encoded in Base64 embedded in the message or as a URI to an external address as a link.
It is recommended to send attachments as embedded, binary objects and not as external references. See code list for more details about attachment types.
<cac:AdditionalDocumentReference>
<cbc:ID>Document idtir110-045</cbc:ID>
<cbc:DocumentType>Document description</cbc:DocumentType>
<cac:Attachment>
<cbc:EmbeddedDocumentBinaryObject filename="file.pdf" mimeCode="application/pdf">UjBsR09EbGhjZ0dTQUxNQUFBUUNBRU1tQ1p0dU1GUXhEUzhi</cbc:EmbeddedDocumentBinaryObject>
<cac:ExternalReference>
<cbc:URI>https://joinup.ec.europa.eu/svn/peppol/PostAward/Ordering28A/20160310%20-%20PEPPOL_BIS_28a-101.pdf</cbc:URI>
</cac:ExternalReference>
</cac:Attachment>
</cac:AdditionalDocumentReference>6.5. Attachments and document references on line level
Non-XML documents can be sent as attachments to the EHF Order Agreement on line level. This could comprise item specifications, timesheets or other documents relevant for the particluar line in the order agreement. See the above information regarding attachments.
<cac:ItemSpecificationDocumentReference>
<cbc:ID>doc id</cbc:ID>
<cbc:DocumentType>Item specs</cbc:DocumentType>
<cac:Attachment>
<cbc:EmbeddedDocumentBinaryObject mimeCode="application/pdf" filename="specs.pdf">UjBsR09EbGhjZ0dTQUxNQUFBUUNBRU1tQ1p0dU1GUXhEUzhi</cbc:EmbeddedDocumentBinaryObject>
<cac:ExternalReference>
<cbc:URI>https://joinup.ec.europa.eu/svn/peppol/PostAward/Ordering28A/20160310%20-%20PEPPOL_BIS_28a-101.pdf</cbc:URI>
</cac:ExternalReference>
</cac:Attachment>
</cac:ItemSpecificationDocumentReference><cac:ItemSpecificationDocumentReference>
<cbc:ID>Ticket id</cbc:ID>
<cbc:DocumentType>A ticket for ...</cbc:DocumentType>
<cac:Attachment>
<cac:ExternalReference>
<cbc:URI>https://ticketseller.eu/ticket.pdf</cbc:URI>
</cac:ExternalReference>
</cac:Attachment>
</cac:ItemSpecificationDocumentReference>6.6. Product identification
Product identification may be done using the identifiers described below:
-
Sellers ID
-
Standard ID, e.g. the GS1 Global Trade Item Number (GTIN) GS1
The order agreement requires that an item has an identifier. This can be either the sellers idenfier or a standard identifier. Which identifier to use depends on what is known at the time of the purchase or what is commonly used in the relevant business sector.
<cac:Item>
<cac:SellersItemIdentification>
<cbc:ID>123</cbc:ID>
</cac:SellersItemIdentification>
<cac:StandardItemIdentification>
<cbc:ID schemeID="GTIN">1234567890124</cbc:ID>
</cac:StandardItemIdentification>
</cac:Item>6.7. Product name and description
The Product name must be sent in tag Item/Name on line level. Description of a product can be sent in Item/Description.
The Product name is often sent in the order agreement from the buyer to the seller.
<cac:Item>
<cbc:Description>Description of the item</cbc:Description>
<cbc:Name>Item name</cbc:Name>
</cac:Item>6.8. Item labelling
Information about the items environmental, social, ethical and quality type of labelling. The UBL structure used for item labeling requires certain elements in addition to those used by this EHF. To fulfill the UBL requirements these are included with the dummy value NA.
<cac:Certificate>
<cbc:ID>EU Ecolabel</cbc:ID>
<cbc:CertificateTypeCode>NA</cbc:CertificateTypeCode>
<cbc:CertificateType>Environmental</cbc:CertificateType>
<cbc:Remarks>Item label value</cbc:Remarks>
<cac:IssuerParty>
<cac:PartyName>
<cbc:Name>NA</cbc:Name>
</cac:PartyName>
</cac:IssuerParty>
<cac:DocumentReference>
<cbc:ID>Item label reference</cbc:ID>
</cac:DocumentReference>
</cac:Certificate>6.9. Contracted item
If the purchased item is offered in accordance to an existing contract, this should be indicated in the order agreement message.
<cac:TransactionConditions>
<cbc:ActionCode>CT</cbc:ActionCode>
</cac:TransactionConditions>6.10. Quantities and units
Various Quantities and Units can be stated in the EHF Order Agreement. These are both related to the ordering process and the logistics process.
The table below lists quantities and units in the format. To all quantities there must be a valid Unit of measure according to the Code list.
| Element name / (Tag name) | Description |
|---|---|
Price Quantity /(BaseQuantity) |
Quantity related to Price. |
Order Quantity /(Quantity) |
Quantity that is ordered, e.g. number of pieces or volume in litre. |
<cbc:ID>1</cbc:ID>
<cbc:Note>Line note</cbc:Note>
<cbc:Quantity unitCode="C62" unitCodeListID="UNECERec20">10</cbc:Quantity>
<cac:Price>
<cbc:PriceAmount currencyID="NOK">10</cbc:PriceAmount>
<cbc:BaseQuantity unitCode="C62" unitCodeListID="UNECERec20">10</cbc:BaseQuantity>
</cac:Price>6.11. Prices
Prices must be exchanged in the Order Agreement transaction. The price may be 0 (zero) Price sent is related to the articles or services within this order agreement Prices includes allowances and/or charges but exclude VAT amounts
<cac:Price>
<cbc:PriceAmount currencyID="NOK">10</cbc:PriceAmount>
<cbc:BaseQuantity unitCode="C62" unitCodeListID="UNECERec20">10</cbc:BaseQuantity>
</cac:Price>6.12. Allowances and charges
<cac:AllowanceCharge>
<cbc:ChargeIndicator>true</cbc:ChargeIndicator>
<cbc:AllowanceChargeReason>Packing cost</cbc:AllowanceChargeReason>
<cbc:Amount currencyID="NOK">199.95</cbc:Amount>
</cac:AllowanceCharge><cac:AllowanceCharge>
<cbc:ChargeIndicator>false</cbc:ChargeIndicator>
<cbc:AllowanceChargeReason>Discount</cbc:AllowanceChargeReason>
<cbc:Amount currencyID="NOK">100.00</cbc:Amount>
</cac:AllowanceCharge>6.13. Calculation of totals (LegalMonetaryTotal)
The following elements show the anticipated monetary totals for an order agreement:
| Element: | Description: |
|---|---|
<cbc:LineExtensionAmount> |
Sum of line amounts |
<cbc:AllowanceTotalAmount> |
Allowances on document level |
<cbc:ChargeTotalAmount> |
Charges on document level |
<cbc:TaxExclusiveAmount> |
Order total amount without VAT |
<cbc:TaxInclusiveAmount> |
Order total amount included VAT |
<cbc:PrepaidAmount> |
Any amounts that have been paid a-priory |
<cbc:PayableRoundingAmount> |
Rounding of Order total |
<cbc:PayableAmount> |
The amount that is expected to be paid |
Amounts MUST be given to a precision of maximum 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 LegalMonetaryTotals class is optional. The legal monetary total class in the order agreement is equal to the anticipated monetary total in the order transaction. If the class is included in the message, the only mandatory elements are the LineExtensionAmount and the PayableAmount elements. All other elements are optional. When optional elements are used, the content MUST be according to the rules below.
Formulas for the calculations of totals are as follows:
| Element: | Formula: |
|---|---|
<cbc:LineExtensionAmount> |
∑ (cac:OrderLine/cac:LineItem/cbc:LineExtensionAmount) |
<cbc:ChargeTotalAmount> |
∑ (cac:AllowanceCharge[ChargeIndicator='true']/cbc:Amount ) |
<cbc:AllowanceTotalAmount> |
∑ (cac:AllowanceCharge[ChargeIndicator='false']/cbc:Amount ) |
<cbc:TaxExclusiveAmount> |
cac:LegalMonetaryTotal/cbc:LineExtensionAmount – cac:LegalMonetaryTotal/cbc:AllowanceTotalAmount + cac:LegalMonetaryTotal/cbc:ChargeTotalAmount |
<cbc:TaxInclusiveAmount> |
cac:LegalMonetaryTotal/cbc:TaxExclusiveAmount + cac:TaxTotal/cbc:TaxAmount + cac:LegalMonetaryTotal/cbc:PayableRoundingAmount |
<cbc:PayableAmount> |
cac:LegalMonetaryTotal/cbc:TaxInclusiveAmount – cac:LegalMonetaryTotal/cbc:PrepaidAmount |
6.13.1. Example of calculations:
| Business term | Sample | Amounts | Elements |
|---|---|---|---|
Sum of line amounts |
+ |
1000.00 |
|
Allowance on document level |
- |
100.00 |
|
Charges on document level |
+ |
199.95 |
|
Total amount without VAT |
= |
1099.95 |
|
VAT total amount |
+ |
250.00 |
|
Rounding of Order total |
+ |
0.05 |
|
Total with VAT (value of purchase) |
= |
1350.00 |
|
Paid amounts |
- |
100.00 |
|
Amount expected to be paid |
= |
1250.00 |
|
<cac:LegalMonetaryTotal>
<cbc:LineExtensionAmount currencyID="NOK">1000.00</cbc:LineExtensionAmount>
<cbc:TaxExclusiveAmount currencyID="NOK">1099.95</cbc:TaxExclusiveAmount>
<cbc:TaxInclusiveAmount currencyID="NOK">1350</cbc:TaxInclusiveAmount>
<cbc:AllowanceTotalAmount currencyID="NOK">100</cbc:AllowanceTotalAmount>
<cbc:ChargeTotalAmount currencyID="NOK">199.95</cbc:ChargeTotalAmount>
<cbc:PrepaidAmount currencyID="NOK">100</cbc:PrepaidAmount>
<cbc:PayableRoundingAmount currencyID="NOK">0.05</cbc:PayableRoundingAmount>
<cbc:PayableAmount currencyID="NOK">1250.00</cbc:PayableAmount>
</cac:LegalMonetaryTotal>6.13.2. 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, i.e. greater than or equal to 0.5 is rounded up, all other values are rounded down.
The element LegalMonetaryTotal/PayableRoundingAmount is used for this purpose and is specified on the header level. This value must be added to the value in LegalMonetaryTotal/TaxInclusiveAmount.
Example: Amount 999.81 rounded to 1000. PayableRounding Amount = 0.19
6.14. Tax amounts
It is possible to state the tax total of the order agreement, on the header level and also on line level.
<cac:TaxTotal>
<cbc:TaxAmount currencyID="NOK">250.00</cbc:TaxAmount>
<cac:TaxSubtotal>
<cbc:TaxableAmount currencyID="NOK">1000.00</cbc:TaxableAmount>
<cbc:TaxAmount currencyID="NOK">250.00</cbc:TaxAmount>
<cac:TaxCategory>
<cbc:ID schemeID="UNCL5305">S</cbc:ID>
<cbc:Percent>25</cbc:Percent>
<cac:TaxScheme>
<cbc:ID>VAT</cbc:ID>
</cac:TaxScheme>
</cac:TaxCategory>
</cac:TaxSubtotal>
</cac:TaxTotal><cac:LineItem>
<cbc:ID>1</cbc:ID>
<cbc:Note>Line note</cbc:Note>
<cbc:Quantity unitCode="C62" unitCodeListID="UNECERec20">10</cbc:Quantity>
<cbc:LineExtensionAmount currencyID="NOK">1000.00</cbc:LineExtensionAmount>
<cbc:TotalTaxAmount currencyID="NOK">250.00</cbc:TotalTaxAmount>
<cac:ClassifiedTaxCategory>
<cbc:ID schemeID="UNCL5305">S</cbc:ID>
<cbc:Percent>25</cbc:Percent>
<cac:TaxScheme>
<cbc:ID>VAT</cbc:ID>
</cac:TaxScheme>
</cac:ClassifiedTaxCategory>7. Code lists
7.1. Code lists for coded elements
7.1.2. Mime code of attached document
Qualifier |
None |
|---|---|
Document location |
|
Source codelist |
Subset of IANA and AutoCAD file type. |
Structured content |
application/xml |
|---|---|
Documents |
application/pdf |
Images |
image/png |
image/jpeg |
|
image/tiff |
|
image/gif |
|
Drawings |
application/acad |
application/autocad_dwg |
|
application/dwg |
|
drawing/dwg |
7.1.3. Country code
Qualifier |
|
|---|---|
Document location |
|
Source codelist |
7.1.5. Item VAT category code
Qualifier |
|
|---|---|
Document location |
|
Source codelist |
Subset of UN/CEFACT code list 5305 |
| Code | Description |
|---|---|
AE |
Vat Reverse Charge |
E |
Exempt from Tax |
S |
Standard rate |
Z |
Zero rated goods |
H |
Higher rate |
AA |
Lower rate |
7.1.6. Commodity code
| Qualifier | None |
|---|---|
Document location |
|
Source codelist |
COMMODITY SCHEME ID – CENBII |
| Code | Description |
|---|---|
CV |
Customs Article Number |
GN |
National Product Group Code |
HS |
Harmonised System |
CPV |
Common Procurement Vocabulary |
UNSPSC |
|
eCLASS |
eCLASS |
GPC |
GS1 Global Product Classification |
7.2. Codelists for identifier schemes
Table of the code lists used to constrain the values of schemeID for identifiers in the order agreement transaction:
| Business Term | Allowed SchemeID | Applicable Xpath | Note |
|---|---|---|---|
Party Identifier |
cbc:EndpointID/@schemeID |
Mandatory |
|
Business process type identifier |
See Profile ID |
cbc:ProfileID |
Mandatory |
Specification identification |
See Customization ID |
cbc:CustomizationID |
Mandatory |
8. Message transport and identifiers
EHF has defined a “Policy for Using Identifiers” 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 EHF environment. The policies that apply to this EHF are the following:
8.1. Party Identifiers
The “schemeID” attribute must be populated in all instances of the “ID” element when used within a “PartyIdentification”-container and in all instances of the “EndpointID” element when used within a “Party”-container.
<cac:PartyIdentification>
<cbc:ID schemeID="NO:ORGNR">987654321</cbc:ID>
</cac:PartyIdentification>8.2. Version ID
This EHF is using the UBL 2.1 syntax UBL_OrderResponse. The namespace of the XML-message does only communicate the major version number. Since it is important for the receiver to also know what minor version of the syntax that is used, the element UBLVersionID must be stated with the value 2.1:
<cbc:UBLVersionID>2.1</cbc:UBLVersionID>8.3. Profile ID
The ProfileID identifies the process that the business document is part of. EHF uses the identification system according to BII:
The following process identifier is used for Order Agreement:
ProfileID: urn:www.cenbii.eu:profile:bii42:ver1.0
<cbc:ProfileID>urn:www.cenbii.eu:profile:bii42:ver1.0</cbc:ProfileID>8.4. Customization ID
The EHF CustomizationID identifies the specification of content and rules that apply to the transaction. This EHF has required some minor additions and changes to the PEPPOL transaction. Following the CENBII methodology any extension must be communicated by adding an extension ID onto the Customization ID CENBII. The full syntax is:
<transactionId>:(restrictive|extended|partly):<extensionId>[(restrictive|extended|partly):<extensionId>]Where:
-
CENBII Transaction ID is:
urn:www.cenbii.eu:transaction:biitrns110:ver1.0 -
Peppol extension ID is:
urn:www.peppol.eu:bis:peppol42a:ver1.0 -
EHF extension ID is:
urn:fdc:difi.no:2017:ehf:spec:1.0
By combining these according to the identifier syntax the CustomizationID to use in EHF is (without spaces):
urn:www.cenbii.eu:transaction:biitrns110:ver1.0
:extended:urn:www.peppol.eu:bis:peppol42a:ver1.0
:extended:urn:fdc:difi.no:2017:ehf:spec:1.0<cbc:CustomizationID>urn:www.cenbii.eu:transaction:biitrns110:ver1.0:extended:urn:www.peppol.eu:bis:peppol42a:ver1.0:extended:urn:fdc:difi.no:2017:ehf:spec:1.0</cbc:CustomizationID>For implementers: Please note that CustomizationID element in the document instance MUST correspond to the Customization ID of the SMP Document Identifier.
8.5. Namespaces
The target namespace for the mapping of Order Agreement onto UBL is UBL 2.1 OrderResponse is:
urn:oasis:names:specification:ubl:schema:xsd:OrderResponse-28.6. Message transport
The transactions defined in this EHF need to be transferred from the sending party to the receiving party through an agreed transport network and protocol. The EHF is specified independent of a transport network but it is designed with the requirement of the PEPPOL network in mind and does not specifically support other transport network that may be used.
8.6.1. The PEPPOL network
This EHF is based on PEPPOL transport network that is a four corner transport network that allows senders end receivers to exchange message from one service provider to another by using a single identifier for the parties.
Details about the PEPPOL network can be found at PEPPOL
The combination of the ELMA registration and the implementation guides referred to in that context eliminates the need for any formal collaboration agreement between the sender and the receiver. The ELMA registration verifies that an actor has declared the ability and the commitment to receive business documents composed according to the specific implementation guide, and any party is free to send the business document to this actor.
9. Validation
To optimize the flexibility in the validation process, each EHF document is validated in different stages with shifting focus in every stage. The pyramid below illustrates the different stages.
9.1. Validation Principles
Stages in the validation process:
-
Validation of syntax against UBL 2.1 Schema, for example:
-
Tag names and attributes must be correctly written and follow the UBL 2.1 sequence
-
All UBL 2.1 mandatory tag names must be present.
-
The element’s contents must be according to the element’s type definition.
-
-
Validation against CEN BII Core to verify that the message is according to international requirements, like:
-
Valid codes for currencies, countries, tax etc.
-
Mandatory tag names according to CEN BII Core.
-
Logical correlations between information element, i.e. that start date is at least lower than end date, sub totals must be totaled, multiplications give the correct result etc.
-
-
Validation against PEPPOL (EU) rules and regulations
-
Validation against EHF Common rules containing rules common to all EHF document types.
-
Validation against EHF rules and Norwegian legislation, like:
-
Organisation number must be specified for the seller/supplier.
-
«Your ref» must be specified.
-
Addresses, postal zone number and post office/city must be specified for the buyer/customer.
-
9.2. Dynamic Validation
The combination of ProfileID and CustomizationID in an XML document defines the validation rules applied to the document.
CustomizationID may be extended with more elements for specific trade or business validation rules.
9.5. Validation Service
Difi’s Validator is an application program used to validate EHF XML-files.
Further information can be found here: https://vefa.difi.no/ehf/knowledge-base/validation/
10. Appendix
Appendix A: Structure Table
Attached is structure tables providing a structured overview of the document types.
Appendix C: Example files
Example files are provided to help implementers. Example files for this implementation guideline is included in the example file archive.