EHF Despatch Advice

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 is both accounting and IT professionals in organizations aiming at performing the fulfillment process completely or partially electronic. That means issuing a dispatch advice. This document may also benefit system suppliers, ERP suppliers and message brokers.

This document consists of the following chapters and contents:

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

Version 1.0.12 is a revision of EHF Despatch Advice 1.0, and this version is backwards compatible to EHF Despatch Advice 1.0. This means that any instance documents valid towards EHF Despatch Advice 1.0 is also valid in version 1.0.12. Please note that valid here reflects the validity against the implementation guide of EHF Despatch Advice 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 electronic transaction described in this implementation guide is the despatch advice message. The Despatch Advice message is used in the fulfillment process by the supplier to notify the receiver about the despatch and delivery period for the goods being sent, as well as details about the goods for cross checking with the order and ultimately the despatch advice is used for declaring how the despatched goods are packed.

The diagram below shows the roles involved in the fulfillment process.

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.

This version of EHF Despatch Advice is based on UBL XML schema version 2.1.

The fulfillment process includes issuing and sending the despatch advice message from a supplier to a customer and receiving of the goods at the customer’s site.

The main activities supported by this message are:

The diagram below shows the fulfillment process by using the EHF despatch advice message. This process is based on profile 30 in CENBII2 (BII30 – Dispatch only).

The following roles may be specified in the format. The same actor may play more than one role depending on the handling routine.

Used to provide a reference to the purchase order on which the Despatch Advice is based. There may be multiple Despatch Advices to cover one purchase order. Each Despatch Advice relates to one purchase order. The reference to Order Line-ID is required in the UBL syntax. To cater for scenarios where no order line reference exist a dummy value must be applied. The dummy value must consist of the characters NA (Not Applicable).

Description of the actual shipment that contains the goods that are being despatched.

Description of items that are being despatched.

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.