EHF Ordering

The government white paper labeled “St.Meld. nr. 36 (2008-2009) Det gode innkjøp” (The good procurement), states among other things:

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.

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.

The target audience for this implementation guide (hereafter called IG) is both technical and non-technical personnel involved in the exchange of Order messages. The IG may also be used by system providers and message brokers. * Chapters 1 to 6 are directed to non-technical personnel * Chapters 7 to 8 (appendices) are directed to technical personnel

The document consists of the following parts: * Chapter 1 outlines the background and objective for the document. * Chapter 2 contains document history. * Chapter 3 describes the principles and conditions for EHF. * Chapter 4 contains definitions. * Chapter 5 describes the ordering process. * Chapter 6 describes selected parts of the formats. * Chapter 7 describes the validation of the messages. * Chapter 8 contains the references to separate documents.

This version is valid from 10. December 2019, and is mandatory from the same date.

Version 1.0.13 is a revision of EHF Ordering 1.0, and this version is backwards compatible to EHF Ordering 1.0. This means that any instance documents valid towards EHF Ordering 1.0 is also valid in version 1.0.13. Please note that valid here reflects the validity against the implementation guide of EHF Ordering 1.0, as this is the normative reference.

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.

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.

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.

Open PEPPOL Transport Infrastructure will provide an efficient use and transport of the EHF formats. The objective is to make it easy for parties in different countries to do cross-border trade. Experience shows that it is easy to implement electronic messaging in Norway, because most of the service providers use standard processes.

It must be noted that every document scheduled for this infrastructure must be validated with no fatal errors by Difi’s own validation service. This is likely to be done by the document issuer or by the service provider on behalf of the document issuer.

According to circular P-10/2012 FAD recommends all central government agencies to use this transport infrastructure.

In line with the underlying methodology for the EHF formats (cf. CEN BII) the electronic messages included in a specific format will be exchanged between the parties as a part of an electronic collaboration process – a profile.

CEN BII has defined a profile as “A specification of how one or more Business Processes are executed by specifying the business rules governing its business collaborations and the information content (data model) of the electronic business transactions exchanged.”

If possible, the EHF is using profiles prepared by BII or PEPPOL. Examples of relevant profiles are:

The messages being exchanged within a profile are customized to comply with the requirements given for that particular business document.

A CustomizationID is used to identify the business rules that apply to the document in question, i.e. the whole set of business rules the document issuer founded the document on.

The example CustomizationID below indicates that the contents of the current message is based on business rules determined by BII (urn:www.cenbii.eu:transaction:biitrns010:ver2.0), extended, customized and clarified by PEPPOL (urn:www.peppol.eu:bis:peppol5a:ver2.0) and further extended, customized and clarified in this implementation guide regarding the Norwegian businesses (urn:www.difi.no:ehf:faktura:ver2.0).

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.

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:

The messages covered by this Implementation guide are EHF Order and EHF Order Response. Buyer and Seller must exchange both messages electronically to be in compliance with this guide.

The Order message is used to send an order from Buyer to Seller. Via the Order Response message the Seller can respond to the order as a whole or partially with suggested changes to the order. This enables the Seller and Buyer to perform the ordering process wihout unnecessary delays. Which changes to be allowed and when to send messages should be agreed in the Commercial agreement or the Collaboration agreement. See also chapter 3.6.

The Ordering process is a post-award process being performed after the Commercial agreement is signed between Supplier and Buyer.

The figure below shows the business functions and roles covered by EHF Order messages. In addition to these roles the Delivery location must be stated in the 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 must contain corresponding ProfileID and CustomizationID.

The listing below are related document types connected to the role of receiver in the conversation. Registration in ELMA describes the receivers capabilities.

The Ordering process descibed in this guide is a common process in most trading businesses. We expect companies to understand this process even if they may have organised it differently.

The Ordering process is as follows:

The figure below describes the ordering process using EHF Order messages. The process is based on Profile CENBII 28 - Ordering. This profile assumes that both the Order and the Order Response is sent electronically.

Feedback on reception of the EHF Order and EHF Order Response can be done via e-mail, Telephone or as an electronic message. The use of an electronic message is descibed in chapter 3.4 in this document.

The use of Message Level Response must be agreed between Buyer and Seller.

The following roles are defined in EHF Order. These roles can either be hold by the same physical actor of by different actors depending on how the order processing is organized.

The type of Party ID that is used shall be defined in the schemeID according to code list in defined in the «Peppol Policy for use of identifiers». The following codes are relevant for use in Norway:

ZZZ is to be used for internal customerid’s or supplierid’s.

Product identification must be done using the identifiers described below.

Either Sellers ID or Standard ID must be sent.

Which identifier to use depends on what is known at the time of order exchange or what is commonly used in the relevant business sector.

The Product name shall be sent in tag <Item/Name> on line level. Description of a product can be sent in <Item/Description>, but is normally not used in the order.

The Product name is often sent in the order from buyer to seller. The field length should not exceed 160 characters being the maximum length sent from most existing public purchasing systems. This element is also included in the shopping basket when OCI punch-out (round trip) is used.

Various Quantities and Units can be stated in the 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 legal Unit according to the Code list.

Prices may be exchanged in the Ordering process both for Catalogue-orders and free text orders. This also allows for the Supplier to change the price in the Order response.

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 in EHF Order is related to the articles or services within this order. The following price can be stated:

Be aware that Gross prices cannot be sent in the format (price before discount and charges).

Price must have Currency as an attribute. Currency shall be according to Code list.

Non-XML documents can be sent as attachments to the EHF Order. This could be drawings or timesheets or other documents relevant for the order. The attachment can either be sent as a binary objetc 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.

Additional recommendations:

Public actors will have requirements related to the environment, ecologically produced food and fair trade. They will also demand that basic human rights are respected in the product production and trade.

Environmental lables defined in the Catalogue can also be sent in the Order to motivate the purchasers to follow up these requirements in their daily work.

Item properties that cannot be stated in any of the defined elements can be sent as Additional item properties. The Name of the property must be declared together with the actual Value.

Example of additional properties:

Package level codes (D-pak, F-pak etc.) can be described in the element cac:AdditionalItemProperty.

The package level code is placed in the element cbc:Name, and its values shall be from the code list Packagelevel and is the same as used in EHF Catalogue. The element cbc:Value must have the value "Anbrekk".

Order response is a message sent from seller to buyer stating the sellers ability to fulfill the order. The following rules applies to the EHF Order Response:

Stages in the validation process:

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.

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/

Attached is structure tables providing a structured overview of the document types.

Attached is complete message table for the document types.

Current code lists for EHF:

This implementation guide builds upon UBL 2.1 Schemas available from OASIS.

These schemas are used when performing syntax validation.

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

Validation files based on Schematron may be found in our Github repoistory. Release "2021-02-15" is used for the current version of resources and branch "master" is for development and review.

Difi provides validation artifacts as Schematron and not as XSLT as of release 2016-11-15.

Example files are provided to help implementers. Example files for this implementation guideline is included in the example file archive.