This document describes the EHF Order and Order Response formats to be used for the exchange of order information between trading partners. It is prepared as part of the initiative taken by the Norwegian "The Norwegian Agency for Public and Financial Management" (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.

Introduction

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.

Definition of open standards:
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.

Target Audience

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

Document Structure

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.

Mandatory Use

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

1. Changelog

1.1. Consequences of Implementing this version

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.

1.1.1. Registration in ELMA

Invoice and creditnote receivers capable of receiving EHF Ordering 1.0 instance documents is also capable of receiving EHF Ordering 1.0.13, so no change is needed in the registration in ELMA.

1.2. Version 1.x

Version 1.0.13 (2019-12-10)

Issue Description Type

-

Updated links to Github.

Guide

Version 1.0.12 (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.11 (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-T01-BXXXXX' for Order and 'EHF-T76-BXXXXX' for Order Response 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).

Version 1.0.10 (2018-09-12)

Issue Description Type

#267

Adding a missing word in "Profiler og meldinger" section (Norwegian edition only).

Guide

Version 1.0.9 (2017-11-15)

Issue Description Type

#230

Updating rule EHF-COMMON-R011 (F) from warning to error.

Validator

#229

For easier maintenance and better transparency use PEPPOL BIS Schematron source in favour of copying generated XSLTs into this project.

Validator

#233

Updated chapter on validation to reflect use of EHF Common.

Guide

#245

Adding information related to new tax categories valid as of next release.

Guide

Version 1.0.8 (2017-09-14)

Issue Description Type

#215

Fixing context for a lot of rules for higher quality.

Validator

#222

Replacing rules with rules in EHF Common.

Validator

#222

Adding rule NOGOV-T01-R023 (W) and NOGOV-T01-R024 (W) to support implisit functionality.

Validator

Validation rules expected to be updated to trigger error in next release: EHF-COMMON-R011
Mapping of rules in EHF Common for EHF Order
New rule Description Old rule

Document in general

EHF-COMMON-R001 (F)

Document MUST not contain empty elements.

NOGOV-T01-R006 (F)

EHF-COMMON-R002 (F)

Document MUST not contain empty elements.

NOGOV-T01-R006 (F)

EHF-COMMON-R003 (W)

Document SHOULD not contain schema location.

New rule

EHF-COMMON-R004 (F)

Document MUST have a syntax identifier.

NOGOV-T01-R012 (F)

Validation of Norwegian organization numbers

EHF-COMMON-R010 (F)

MUST be a valid Norwegian organization number. Only numerical value allowed

NOGOV-T01-R009 (F)

EHF-COMMON-R011 (F)

When scheme is NO:ORGNR, a valid Norwegian organization number must be used. Only numerical value allowed

New rule

EHF-COMMON-R012 (F)

A VAT number MUST be valid Norwegian organization number (nine numbers) followed by the letters MVA.

NOGOV-T01-R011 F

EHF-COMMON-R013 (F)

When scheme is NO:ORGNR, a valid Norwegian organization number must be used. Only numerical value allowed

NOGOV-T01-R010 F

EHF-COMMON-R014 (F)

An endpoint identifier scheme MUST have the value 'NO:ORGNR'.

NOGOV-T01-R008 (F)

Validation of tax

EHF-COMMON-R020 (F)

Tax categories MUST be one of the follwoing codes: AA E H K R S Z

NOGOV-T01-R022 (F)

Formating validation

EHF-COMMON-R030 (F)

A date must be formatted YYYY-MM-DD.

NOGOV-T01-R007 (F)

Validation of other identifiers

EHF-COMMON-R040 (W)

Invalid GLN number provided.

New rule

Code lists

EHF-COMMON-R100 (W)

Attachment is not a recommended MIMEType.

NOGOV-T01-R021 (W)

Mapping of rules in EHF Common for EHF Order Response
New rule Description Old rule

Document in general

EHF-COMMON-R001 (F)

Document MUST not contain empty elements.

NOGOV-T76-R010 (F)

EHF-COMMON-R002 (F)

Document MUST not contain empty elements.

NOGOV-T76-R010 (F)

EHF-COMMON-R003 (W)

Document SHOULD not contain schema location.

New rule

EHF-COMMON-R004 (F)

Document MUST have a syntax identifier.

NOGOV-T76-R007 (F)

Validation of Norwegian organization numbers

EHF-COMMON-R010 (F)

MUST be a valid Norwegian organization number. Only numerical value allowed

NOGOV-T76-R003 (F)

EHF-COMMON-R011 (F)

When scheme is NO:ORGNR, a valid Norwegian organization number must be used. Only numerical value allowed

New rule

EHF-COMMON-R012 (F)

A VAT number MUST be valid Norwegian organization number (nine numbers) followed by the letters MVA.

Ignored

EHF-COMMON-R013 (F)

When scheme is NO:ORGNR, a valid Norwegian organization number must be used. Only numerical value allowed

Ignored

EHF-COMMON-R014 (F)

An endpoint identifier scheme MUST have the value 'NO:ORGNR'.

NOGOV-T76-R002 (F)

Validation of tax

EHF-COMMON-R020 (F)

Tax categories MUST be one of the follwoing codes: AA E H K R S Z

NOGOV-T76-R011 (F)

Formating validation

EHF-COMMON-R030 (F)

A date must be formatted YYYY-MM-DD.

NOGOV-T76-R001 (F)

Validation of other identifiers

EHF-COMMON-R040 (W)

Invalid GLN number provided.

New rule

Code lists

EHF-COMMON-R100 (W)

Attachment is not a recommended MIMEType.

Ignored

Version 1.0.7 (2017-05-15)

Issue Description Type

#207

Updated validation artifacts for PEPPOL BIS from OpenPEPPOL.

Validator

#196

Supressing OP-T01-R008 in favour of NOGOV-T01-R022 (F). Supressing OP-T76-R008 in favour of NOGOV-T76-R011 (F).

Validator

#203

Description of package level codes.

Guide

#206

Updating links in 3.6 and code lists.

Guide

Version 1.0.6 Hotfix (2016-12-13)

Issue Description Type

#192

Removing EHF Core for Order and Order Response.

Validator

Version 1.0.6 (2016-11-15)

Issue Description Type

#166

Aligning chapter 5.3 with EHF Invoice and Credit Note.

Guide

#169

Fix minor bug in Order and Order Response example files.

Attachment

#167

Fix rule NOGOV-T01-R021 (W) so it triggers as intended.

Validator

#169

Updating NOGOV-T01-R009 (F), NOGOV-T01-R010 (F) and NOGOV-T01-R011 (F) to also verify checksum of organization number.

Validator

#169

Updating NOGOV-T76-R003 (F) to also verify checksum of organization number.

Validator

#179

Updated validation artifacts for PEPPOL BIS from OpenPEPPOL.

Validator

#66

Adding EHF Core for Order and Order Response.

Validator

#167

Change authoritative source of validation artifacts from XSLT to Schematron for NOGOV-T01.

Validator

#177

Change authoritative source of validation artifacts from XSLT to Schematron for NOGOV-T76.

Validator

Version 1.0.5 (2016-09-15)

Issue Description Type

#149

Converting guide to Asciidoctor format.

  • Aligning chapter 1 to other guides.

  • Aligning chapter 3 to other guides.

  • Moving 6.1.1-8 to 6.1-8, moving 6.2 to 6.9.

  • Removing chapter 7 in favor of GEFEG presentation found on VEFA.

  • Moving chapter 8 to chapter 7.

  • Moving chapter 9 to chapter 8.

  • Presentations and illustrations are changed due to new format.

Guide

Version 1.0.4 (2016-05-23)

Changes in validator:
  • Correction of rule BII2-T01-R011 and R017

Author:
  • Siw Meckelborg, Edisys Consulting AS

Version 1.0.3 (2015-09-01)

Changes in validator:
  • Update of PEPPOL and BII validation artefacts

  • Empty elements will generate error, not warning (rule NOGOV-T01-R006 and NOGOV-T76-R010)

Author:
  • Siw Meckelborg, Edisys Consulting AS

Version 1.0.2 (2015-03-03)

Validation changes:
  • Validation of all mandatory and recommended elements.

  • Validation of datatypes (VAT number, date etc.)

  • Only organisational numbers are valid in EndpointID.

Editorial changes:
  • Added ruleID to message table

  • Adding Dependant to description of elements.

  • Clarification added to chapter 2.1

Author:
  • Siw Meckelborg, Edisys Consulting AS

Version 1.0.1 (2014-09-02)

  • Changed error message and error type for DocumentCurrencyCode in chapter 8

  • Described use of code ZZZ for PartyID in chapter 6.1.1

  • Added chapter 3.3

  • Added rules for currencyID, mimeCode, Endpoint Identifier scheme and Party identifier scheme.

  • Added rule for correct use of Profile ID

Author:
  • Edisys Consulting AS

Version 1.0.0 (2013-09-25)

Approved

Author:
  • Edisys Consulting AS

2. Electronic Commerce Format (EHF)

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

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

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

2.4. Message Transport

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.

2.5. Profiles and Messages

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:

Profile Document types

Invoice only (bii04)

Invoice

Credit note only (biixx)

Credit note

Invoice and credit note (bii05)

Invoice, Credit note

Invoice, credit note and reminder (biixy)

Invoice, Credit note, Reminder

Order and invoice (bii06)

Order, Order response, Invoice, Credit note

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

<cbc:CustomizationID>urn:www.cenbii.eu:transaction:biitrns10:ver2.0:extended:urn:www.peppol.eu:bis:peppol5a:ver2.0:extended:urn:www.difi.no:ehf:faktura:ver2.0</cbc:CustomizationID>

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

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

3. Definitions

EHF (Elektronisk Handelsformat)

The formats to be used for the exchange of electronic documents towards the Norwegian public sector (catalogue, order, and invoice). EHF is based on BII2 and UBL 2.1.

Catalogue

A document describing the properties of products and services.

Invoice

The financial confirmation of a purchase. The Invoice is sent from Seller to Buyer with amount to be paid and payment instructions.

Order

The Order is used by the Buyer to purchase goods and services.

Order Response

An Order Response is used to accept or reject an Order on header or line level.

Supplier

A Company delivering products or services.

Seller

A person or unit within the Suppliers organisation being responsible for selling a product or a service to a Customer.

Customer

A Company taking over the ownership of a product or service based on an agreement with Supplier.

Buyer

A person or unit within the Customers organisation buying a product or service at a set price.

Originator

A person or unit within the Customers organisation that initiates an order.

UBL

UBL (Universal Business Language) is a collection of XML-formats (XML Schema) for the exchange of electronic documents such as Catalogue, Order and Invoice.

BII2

BII (Business Interoperability Interfaces) is a subset of UBL containing documents and content that is required for electronic collaboration in the European public sector.
Does not include separate XML Schemas

Schematron validation

Validation of a message towards business requirements. Additional to the syntax check against XML Schema.

4. Principles and Prerequisites

This chapter describes the ordering process and functional requirements covered by EHF Order and Order Response. The description is based on the business rules described in profile CEN BII2 28 Ordering.

4.1. About the Order Messages

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.

4.2. Functionality and Roles

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.

Functionality and roles

4.3. Profiles and 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.

CustomizationID is a string without spaces. The list below contains spaces in CustomizationID to make them easier to read. Make sure to remove any spaces before use.

4.3.1. Profile 28 - Ordering

ProfileID

urn:www.cenbii.eu:profile:bii28:ver2.0

Type CustomizationID Role

Order

urn:www.cenbii.eu:transaction:biitrns001:ver2.0 :extended:urn:www.peppol.eu:bis:peppol28a:ver1.0 :extended:urn:www.difi.no:ehf:ordre:ver1.0

Economic Operator

Order Response

urn:www.cenbii.eu:transaction:biitrns076:ver2.0 :extended:urn:www.peppol.eu:bis:peppol28a:ver1.0 :extended:urn:www.difi.no:ehf:ordrebekreftelse:ver1.0

Contracting Authority

4.4. Ordering process

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:

  1. A Buyer sends an order to a Seller specifying goods or services to be delivered. The goods or services can either be identified through article numbers or descibed as free text.

  2. The order may refer to a Commercial agreement stating terms and regulations for the purchase. If not these terms can be specified in the order.

  3. The Seller receives and vaildates the order message. If the message is not according to agreed format the Seller must inform the Buyer that it will not be processed.

  4. If validation is OK the Seller processes the order and sends an order response to the Buyer with the result of the processing.

    1. The order is accepted completely with a positive order reponse and delivery will be fulfilled according to agreed terms.

    2. The order is accepted with changes on one or more order lines. Further processing should be described in the Collaboration agreement but could potentially lead to some manual handling.

    3. The order is rejected completely with a negativ order response and no delivery can be expected.

  5. When receiving a negative order response rejecting the whole order, the Buyer may initiate a new purchase taking into account the reason for the rejection.

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.

Ordering process

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.

5. Description of Selected Parts

There are no formal requirements to order content according to Norwegian regulations. The content requirements are therefore based on the following:

  • Information content in the existing Procurement Platform (EPP)

  • UBL 2.1

  • CEN BII2

The format will also be verified against requirements in certain areas of the Norwegian private sector.

Chapter 6.1 and 6.2 describe selected areas of the format and specifically information elements being important for use in the Norwegian market. Part of the content of chapter 6.1 is relevant for both messages while chapter 6.2 contains information relevant only for Order Response.

Complete Information content is defined in chapter 7.

5.1. Roles and Actors

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:

Scheme ID Scheme Agency

GLN

GS1

NO:ORGNR

Enhetsregisteret ved Brønnøysundregisterne

NO:VAT

Enhetsregisteret ved Brønnøysundregisterne

ZZZ

Unknown issuer agency

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

Role Description

Buyer (BuyerCustomerParty)

The party buying products or services. Mandatory.

Originator (OriginatorCustomerParty)

The unit initiating the order. Most often the end user.

Invoicee (AccountingCustomerParty)

The invoice receiver can be stated in the order.

Seller (SellerSupplierParty)

The party receiving an order from Buyer. Mandatory.

Example of supplier information on header level in a EHF Order message
<cac:SellerSupplierParty>
  <cac:Party>
    <cbc:EndpointID schemeID="NO:ORGNR">976502132</cbc:EndpointID>
    <cac:PartyIdentification>
      <cbc:ID schemeID="ZZZ">12345</cbc:ID>
    </cac:PartyIdentification>
    <cac:PartyName>
      <cbc:Name>WENAAS AS</cbc:Name>
    </cac:PartyName>
    <cac:PartyLegalEntity>
      <cbc:RegistrationName/>
      <cbc:CompanyID schemeID="NO:ORGNR">976502132</cbc:CompanyID>
    </cac:PartyLegalEntity>
    <cac:Contact>
      <cbc:ID>Unknown</cbc:ID>
      <cbc:Name/>
      <cbc:Telephone/>
      <cbc:ElectronicMail/>
    </cac:Contact>
  </cac:Party>
</cac:SellerSupplierParty>
Example of buyer information on header level in a EHF Order message.
<cac:BuyerCustomerParty>
  <cac:Party>
    <cbc:EndpointID schemeID="NO:ORGNR">984661185</cbc:EndpointID>
    <cac:PartyIdentification>
      <cbc:ID schemeID="GLN">7080000555134</cbc:ID>
    </cac:PartyIdentification>
    <cac:PartyName>
      <cbc:Name>Posten Norge As</cbc:Name>
    </cac:PartyName>
    <cac:PostalAddress>
      <cbc:StreetName>BISKOP GUNNERUS' GATE 14</cbc:StreetName>
      <cbc:CityName>OSLO</cbc:CityName>
      <cbc:PostalZone>0185</cbc:PostalZone>
      <cac:Country>
        <cbc:IdentificationCode listID="ISO3166-1:Alpha2">NO</cbc:IdentificationCode>
      </cac:Country>
    </cac:PostalAddress>
    <cac:PartyLegalEntity>
      <cbc:CompanyID schemeID="NO:ORGNR">984661185</cbc:CompanyID>
    </cac:PartyLegalEntity>
    <cac:Contact>
      <cbc:ID>3150bdn</cbc:ID> (1)
      <cbc:Name>Johansen, Pat</cbc:Name>
      <cbc:Telephone>91508465</cbc:Telephone>
      <cbc:ElectronicMail>pat.johansen@posten.no</cbc:ElectronicMail>
    </cac:Contact>
  </cac:Party>
</cac:BuyerCustomerParty>
1 Contact/ID is recommended to use. This is an extension to BII Core.

5.2. Product Identification

Product identification must be done using the identifiers described below.

  • Sellers ID

  • Standard ID, e.g. GTIN

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.

Example of an EHF Order message using both Sellers ID and Standard ID (GTIN)
<cac:Item
  ...
  <cac:SellersItemIdentification>
    <cbc:ID>541706</cbc:ID>
  </cac:SellersItemIdentification>
  <cac:StandardItemIdentification>
    <cbc:ID schemeID ="GTIN">05449000035882</cbc:ID>
  </cac:StandardItemIdentification>
  ...
</cac:Item>

5.3. Product Name and Description

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.

Example in an EHF Order message
<cac:Item>
  <cbc:Name>TUNFISK I VANN 6 BX Á 1880 MILLIGRAM</cbc:Name>
  ...
</cac:Item>

5.4. Quantities and Units

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.

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.

Example of an EHF Order line with a quantity of 120 litre (cbc:Quantity) and price is given per litre. (BaseQuantity):
<cbc:ID>1</cbc:ID>
<cbc:Quantity unitCode="LTR" unitCodeListID="UNECERec20”>120</cbc:Quantity>
<cbc:LineExtensionAmount currencyID="NOK">6000</cbc:LineExtensionAmount>
<cbc:TotalTaxAmount currencyID="NOK">1500</cbc:TotalTaxAmount>
<cbc:PartialDeliveryIndicator>false</cbc:PartialDeliveryIndicator>
<cbc:AccountingCostCode>ProjectID123</cbc:AccountingCostCode>
<cac:Price>
  <cbc:PriceAmount currencyID="NOK">50</cbc:PriceAmount>
  <cbc:BaseQuantity unitCode="LTR" unitCodeListID="UNECERec20”>1</cbc:BaseQuantity>
</cac:Price>

5.5. Prices

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:

  • Net price including all allowances and charges but excluded Vat

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.

Example of price information in an EHF Order message
<cac:Price>
  <cbc:PriceAmount currencyID="NOK">50</cbc:PriceAmount>
  <cbc:BaseQuantity unitCode="LTR" unitCodeListID="UNECERec20”>1</cbc:BaseQuantity>
</cac:Price>

5.6. Attachments

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:

Coding

Base64

Document format

MIME types:

  • Pdf – application / pdf

  • TXT – text / txt

  • GIF – image / gif

  • TIFF – image / tiff

  • JPEG, JPG – image / jpeg

  • PNG – image / png

Size

5MB

Description of attachment

It is advised to supply a good description of each attachment and the element to use is: ubl:Order/`cac:AdditionalDocumentReference/cac:DocumentReference/cbc:DocumentType.
Should only be used for description of the document content.

Example of attachment as an embedded, binary object in an EHF Order message.
<cac:AdditionalDocumentReference>
  <cbc:ID>Orderdetails.pdf</cbc:ID>
  <cbc:DocumentType>Order details</cbc:DocumentType>
  <cac:Attachment>
    <cbc:EmbeddedDocumentBinaryObject mimeCode="application/pdf">PD94bWwgdm… +PC9PcmRlcj4=</cbc:EmbeddedDocumentBinaryObject>
  </cac:Attachment>
</cac:AdditionalDocumentReference>

5.7. Environment, Social Responsibility and Ecological

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.

Example of Encironmental lables in an EHF Order message:
<cac:Attachment>
  <cac:ExternalReference>
    <cbc:URI>http://www.ecolabelindex.com/ecolabel/forest-stewardship-council-fsc-chain-of-custody-certification</cbc:URI>
  </cac:ExternalReference>
</cac:Attachment>
...
<cac:AdditionalItemProperty>
  <cbc:Name>EnvironmentMarking</cbc:Name>
  <cbc:Value>FSC</cbc:Value>
</cac:AdditionalItemProperty>

5.8. Additional Item Properties

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:

  • Color

  • Weight

Example of Additional item properties in an EHF Order message
<cac:Item>
  <cbc:Description>God pensel for panel</cbc:Description>
  <cbc:Name>Pensel 20 mm</cbc:Name>
  <cac:SellersItemIdentification>
    <cbc:ID>SItemNo011</cbc:ID>
  </cac:SellersItemIdentification>
  ...
  <cac:AdditionalItemProperty>
    <cbc:Name>Hair color</cbc:Name>
    <cbc:Value>Black</cbc:Value>
  </cac:AdditionalItemProperty>
  <cac:AdditionalItemProperty>
    <cbc:Name>Width</cbc:Name>
    <cbc:Value>20mm</cbc:Value>
  </cac:AdditionalItemProperty>
</cac:Item>

5.9. Package level code

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

Eksempel på angivelse av anbrekkskode
  <cac:AdditionalItemProperty>
    <cbc:Name>DU</cbc:Name>
    <cbc:Value>Anbrekk</cbc:Value>
  </cac:AdditionalItemProperty>
</cac:Item>

5.10. Order Response

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:

  • The Order response must refer to the preceding Order.

  • Seller may accept or reject the entire Order.

  • The Order response should contain an explanation to a 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.

  • Lines in the Order response must refer to corresponding lines in the Order 1 to 1.

  • The following informaiton may be changes in the Order response:

    • Quantity

    • Delivery period

    • Replacement item

    • Price

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

5.10.1. Response Code

The Response code states the Sellers ability to fulfill the order and must be sent on both header level and line level if lines are sent.

Rules for use
  • Response code must be sent on both Header and Line level.

  • If Response code is missing the Order response will be rejected .

  • Response code may have 3 values: 27=Rejected, 29=Accepted, and 30=Accepted with change/Amendment.

Table 1. Response code on Header level:
Response code Action

27

The Order is rejected. No lines should be sent.

29

The Order is accepted. No lines should be sent.

30

The Order is accepted with changes. All lines must be sent.

Example of Response code on Header level in an EHF Order Response message
<cbc:ID>34</cbc:ID>
<cbc:IssueDate>2012-10-01</cbc:IssueDate>
<cbc:IssueTime>12:30:00</cbc:IssueTime>
<cbc:OrderResponseCode listID="UNCL1225">30</cbc:OrderResponseCode>
<cbc:Note>Changes in 2 orderlines</cbc:Note>
Table 2. Response code on Line level

Response code

Action

27

The Order line is rejected.

29

The Order line is accepted without changes.

30

The Order line is accepted with changes.

Example of Response code on Line level in an EHF Order Response message
<cac:OrderLine>
  <cac:LineItem>
    <cbc:ID>1</cbc:ID>
    <cbc:LineStatusCode listID=" UNCL1225">27</cbc:LineStatusCode>
    <cbc:Quantity unitCode="EA" unitCodeListID="UNECERec20”>0</cbc:Quantity>
    <cac:Item/>
  </cac:LineItem>
</cac:OrderLine>

5.10.2. Order Reference

Reference to the preceding order must be done on Header level and on Line level if lines are sent.

Example of Order reference on Header level in an EHF Order Response message
<cbc:ID>12</cbc:ID>
<cbc:IssueDate>2012-10-01</cbc:IssueDate>
<cbc:IssueTime>12:30:00</cbc:IssueTime>
<cbc:OrderResponseCode listID=" UNCL1225">30</cbc:OrderResponseCode>
<cbc:Note>Changes in 1 orderline</cbc:Note>
<cac:OrderReference>
  <cbc:ID>34</cbc:ID>
</cac:OrderReference>
Example of Order reference on Line level in an EHF Order Response message
<cac:OrderLine>
  <cac:LineItem>
    <cbc:ID>2</cbc:ID>
    <cbc:LineStatusCode listID=" UNCL1225">29</cbc:LineStatusCode>
  </cac:LineItem>
  <cac:OrderLineReference>
    <cbc:LineID>2</cbc:LineID>
  </cac:OrderLineReference>
</cac:OrderLine>

5.10.3. Order Response with Changes

When Seller accepts an order with changes, the Response code «Accepted with change» must be sent on both Header and Line level.

In addition 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 changes in an EHF Order Response message
<cac:OrderLine>
        <cac:LineItem>
                <cbc:ID>1</cbc:ID>
                <cbc:LineStatusCode listID=" UNCL1225">30</cbc:LineStatusCode>
                <cbc:Quantity unitCode="EA" unitCodeListID="UNECERec20”>18</cbc:Quantity>
                <cac:Item/>
        </cac:LineItem>
</cac:OrderLine>
Example of Replacement item in an EHF Order Response message
<cac:OrderLine>
        <cac:LineItem>
                <cbc:ID>2</cbc:ID>
                <cbc:LineStatusCode listID="UNCL1225">30</cbc:LineStatusCode>
                <cbc:PartialDeliveryIndicator>false</cbc:PartialDeliveryIndicator>
                <cac:Item>
                        <cbc:Description>Wet tissues for children</cbc:Description>
                        <cbc:Name>Wet tissues</cbc:Name>
                        <cac:SellersItemIdentification>
                                <cbc:ID>SItemNo011</cbc:ID>
                        </cac:SellersItemIdentification>
                </cac:Item>
        </cac:LineItem>
        <cac:SellerSubstitutedLineItem>
                <cbc:ID>2</cbc:ID>
                <cac:Item>
                        <cbc:Description>Wet tissues for adults</cbc:Description>
                        <cbc:Name>Wet tissues</cbc:Name>
                        <cac:SellersItemIdentification>
                                <cbc:ID>SItemNo012</cbc:ID>
                        </cac:SellersItemIdentification>
                        <cac:StandardItemIdentification>
                                <cbc:ID schemeID="GTIN">05449000035882</cbc:ID>
                        </cac:StandardItemIdentification>
                        <cac:CommodityClassification>
        <cbc:ItemClassificationCode listID="UNSPSC">675634</cbc:ItemClassificationCode>
                </cac:Item>
        </cac:SellerSubstitutedLineItem>
</cac:OrderLine>

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

Pyramid of Validation

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

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

6.3. Validation Rules per ProfileID and CustomizationID

6.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/

7. Appendix

Appendix A: Structure Table

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

Appendix B: Message table

Attached is complete message table for the document types.

Appendix C: Code Lists

Current code lists for EHF:

Appendix D: UBL 2.1

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.

Appendix E: Schematron

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.

Appendix F: Example files

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