EHF Catalogue

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 catalogue messages. The IG may also be used by system providers and message brokers. * Chapter 1 to 5 are directed to non-technical personnel * Chapter 6 to 8 (attachments) 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.15 is a revision of EHF Catalogue 1.0, and this version is backwards compatible to EHF Catalogue 1.0. This means that any instance documents valid towards EHF Catalogue 1.0 is also valid in version 1.0.15. Please note that valid here reflects the validity against the implementation guide of EHF Catalogue 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 Catalogue and EHF Catalogue Response. Buyer and Seller must exchange both messages electronically to be in compliance with this guide.

An Electronic Catalogue is a listing of products and services to be used in a purchasing process. The EHF Catalogue can serve different purposes during the lifecycle of Catalogue information:

When doing changes to catalogue lines, it is recommended to replace the whole catalogue and not update separate lines.

A Catalogue containing sufficient information about articles and services will prevent faulty deliveries causing lost income for both suppliers and buyers.

Most often an Electronic Catalogue will be integrated with a Catalogue tool and a Search engine. The Search engines are set up differently providing possibility to search for different catalogue elements. The number of elements available will decide the preciseness of the search, and a well set up Search engine will in the end improve the quality of the purchase.

This Implementation Guide covers exchange of catalogues in a post-award process, i.e. after the contract is signed between supplier and buyer. The content may also be used in a pre-award process (tendering), but with less mandatory elements.

The figure below shows the business functions and roles covered by EHF Catalogue.

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 Catalogue exchange is the first part of the post-award process and can be described as follows:

Figure 2 shows the Catalogue process including the exchange of the EHF Catalogue messages.

The Catalogue Response message is part of the Catalogue process described in chapter 5.4. The Catalogue Response is sent from the Catalogue Receiver/Buyer to the Catalogue Provider/Supplier as a business receipt stating that the Catalogue is accepted or rejected.

In other words, this is not a technical receipt only stating that the catalogue message is received.

The Catalogue itself will not be returned from buyer to supplier. If a Catalogue message is rejected, a new corrected Catalogue must be sent.

If the exchange involves the use of a Catalogue tool, this may include a more advanced dialogue between buyer and supplier than described here.

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

The Action code holds instructions about the treatment of the Catalogue by the recipients system. The Action code can be stated either on header or line level.

It is strongly recommended only to use Action code on header level.

Use of Action codes on line level must be explicitly agreed between sender and receiver.

Message response from receiver to sender shall be done according to description in chapter 3.3.

Product identification must be done using the identifiers described below.

Either Sellers item identifier or Items standard identifier must be sent. Manufacturers item identifier shall be sent if available.

The Product name shall be sent in tag <Item/Name> on line level. Long Description of a product shall be sent in <Item/Description> on line level.

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.

Description should not exceed 2000 characters since this is stated as maximum field length from most existing public purchasing systems. This element is not included in the shopping basket when OCI punch-out (round trip) and is not sent in the order. The Description is only shown to the Buyer when searching for the product in the Catalogue.

Keywords are sent to let the Buyer search for a product without knowing the Product ID or name. Keywords can be repeated, but the number should be limited to ensure correct handling in the receiving system. If more than one Keyword is sent, they should be put in the same tag separated by the %-sign since this is already being used by several actors (but a different sign can be agreed by the trading partners).

Keywords may also be put in separate tags.

Various quantities and units can be stated in the EHF Catalogue. 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.

To inform that an item is catch weight (ex. Orderable quantity is pcs, but invoiced quantity is kilo, and where one pcs can be of variable weight), set unit code for content unit to 31 (catch weight) according to UN Recommondations 20.

All prices in the format are related to the article or service within this Catalogue. The following prices can be stated:

Be aware that no Gross prices can be sent in the format (price before discount and charges). All prices must have Currency as an attribute. Currency shall be according to Code list.

Example of Prices in EHF Catalogue:

Products can be related to each other for ordering or logistic purposes. All related products must also be sent as separate Catalogue lines.

Types of relations:

Example of related products in an EHF Catalogue message:

A product must be classified according to UNSPSC being the mandatory public classification schemes. Products can also be classified according to regulatory schemes or classification schemes used in certain business sectors. The type of classification shall be stated in the attribute listID.

Classification must be according to a relevant product classification scheme. UNSPSC is mandatory for all public purchases and must be stated for all products.

If a product is classified as Hazardous item, a reference to the relevant UNDG-code must be stated and further specification must be provided in an attached document or on a web-site (URI).

VAT-information is optional in EHF Catalogue and should be sent as a Category defining the VAT-percent. Catalogue receivers may require VAT-information in the Catalogues based on user or system requirements. If so this must be stated in the Purchasing contract or the Collaboration agreement.

The following VAT-codes are available:

Attachments can be sent on line level in the Catalogue. This can be images or additional descriptions of a product. It is strongly recommended to use external references in the form of URI’s for attachments.

EHF Catalogue includes elements to support the need for logistics information which is a requirement in many industries in the Norwegian market. These elements are not mandatory, but trading partners can agree upon the use in the commercial agreements.

The Logistics elements can be used to specify different pack levels for the same article. This must be done as follows:

Below is an example of Logistics information in an EHF Catalogue message.

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. To be able to highlight products that meet some of these criteria, the EHF Catalogue contains elements to document Environmental labeling and Social certificates. The labels are connected to the relevant product or service on line level enabling the Search engines to make them visible for the buyer during the purchasing process. Detailed information about the different labels can be found on the issuing party’s web-site which is referred to via an URI.

Several labels can be connected to each product.

The following are used: http://www.anskaffelser.no/verktoy/codes-use-ehf-catalogue-labels-environmental-and-social-responsibility

Introducing these classification codes in the electronic messages will support the aim for correct purchases. The Procurement systems must collect the order lines with environmental and social labels and report them to the statistics tools available for the buyers. This will make it possible to measure the purchasing behavior and monitor that the requirements from the tendering process are fulfilled.

CertificateTypeCode is not in use today, but can be used by the Purchasing systems to group the different labels.

Physical properties are important for logistics. The following values can be stated:

Replacement product is used to identify a product replacing an existing product in the Catalogue. The existing product is stated as replaced on the Catalogue line for the new product.

Recommended article is stated in AdditionalItemProperties with Name=ABF.

Smartform ID is stated in AdditionalItemProperties with Name=SmartFormID.

Additional properties are meant for product properties that cannot be sent in any of the defined elements in EHF Catalogue. Additional properties consist of the Name of the property and the actual Value.

To indicate if a product is sterile, we recommend the use of the code list SterilisationTypeCode: http://apps.gs1.org/GDD/Pages/clDetails.aspx?semanticURN=urn:gs1:gdd:cl:SterilisationTypeCode&release=2

This is indicated in cac:AdditionalItemProperty in the EHF Catalogue, with value "STERILE" in element cbc:Name, and the correct code in cbc:Value To indicate that a product is not sterile, use the code "NO", see example below.

If cbc:ValueQualifier contains the value gs1:SterilisationTypeCode, the code will be validated against the legal values in the codelist, and return an error if an invalid code is used. If element cbc:Name= STERILE but ´cbc:ValueQualifier` is not present, or does not contain the value gs1:SterilisationTypeCode, a warning will be raised if code is invalid according to the codelist.

Correct indication of allergens is a matter about life and health, it is therefore important that all participants read allergen information equally.

To ensure common understanding of the indication of allergens, it is recommended to use code list "Allergen Type Code" provided by GS1.

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 format structure providing a structured overview of 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.