EHF Catalogue 3.0

This Peppol EHF supports a process for suppliers to send a catalogue and for buyers to return a catalogue response. It is intended to support transmission of electronic catalogue-messages for processing in semi-automated processes by the receiver. The EHF mandates no procurement related data but supports different ways of referring to products and services. By selective use of such references it can be used as basis for automated processing of ordering and invoicing.

The intended scope for this EHF is:

This Peppol EHF supports a set of “common use cases / process”. These are processes that are used widely or understood as being relevant for most companies.

The main activities supported by this EHF are:

This Peppol EHF supports requirements by providing elements for information needed to meet the requirement. This EHF also provides a set of business rules to clarify content and implementers can use them as basis for validation where it provides business value.

Catalogues are used as basis for maintenance of information about products and services that are part of a contract, like a framework agreement.

This Peppol EHF is based on the CEN/ISSS WS/BII Profile BII01 specification, see [BII_Catalogue].

This Peppol EHF structure is based on the European Interoperability Framework 2.0 EIF. This Peppol EHF applies the Framework as follows:

Any time limits for the catalogue response must be agreed between the parties as a part of the collaboration agreement. Any further processing is outside scope of this EHF, and is in most cases done in the customers catalogue tool.

This use case includes a simple catalogue containing mandatory information and information required to get a high performance from the buyers search engine. The catalogue contains both products and services. This is the first catalogue to the receiver.

This is an Update of the catalogue based on Use case 1.

This is a Replace of the catalogue based on Use case 1 and 2.

This is a Deletion of the catalogue based on Use case 3.

This is an Update of a previous sent catalogue and not based on any of the other uses cases. The catalogue includes all possible information in a EHF catalogue. Some information may not be relevant, but is in the catalogue for giving an example.

The following parties/roles may be specified in the message:

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. Please be aware that the below mentioned are codes, and hence the correct use of upper and lower case must be used. Example: Replace is valid, REPLACE is not valid.

Legal codes on Catalogue header level:

Legal codes on Catalogue Line level:

It is important to note that when updating or deleting on line level, the key identifier is the item ID (sellers item identification or standard item identification, see chapter 10.2.2.), not the line ID. If CatalogueLineReference is used in the corresponding order message (outside scope of this EHF), the numbering of Line ID must be consistent in all versions of the catalogue.

Item identification must be sent using the identifiers described below.

Either Sellers item identification or Standard item identification must be sent. Manufacturer’s item identification shall be sent if available. Buyers item identification can be used if known. Which identifier to use depends on what is known at the time of catalogue exchange or what is commonly used in the relevant business sector.

If an item 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).

The Item name shall be sent in tag cac:Item/cbc:Name on line level. It is the short description of an item commonly used in ERP-systems. An item name should make it possible for the user to distinguish between similar items. The Item name is often sent in the order from buyer to seller. The field length could be an agreement between parties, to make sure the supporting systems can handle the length.

cac:Item/cbc:Description is used to provide additional relevant description of the item, in free text.

An item may be classified according to UNSPSC being the mandatory public classification schemes in some countries/sectors. The code "TST" (The UNSPSC commodity classification system) from codelist UNCL7143 is used. Products can also be classified according to regulatory schemes or classification schemes used in certain business sectors.

Keywords are sent to let the Buyer search for an item without knowing the item identification or name. Keywords tag can be repeated (0..n), but the number should be limited to ensure correct handling in the receiving system.

It is also possible to send several keywords in the same tag, by using a separator between the different keywords. Which separator that should be used, must be agreed between the parties. Example of a separator can be the %-sign, as this is not used anywhere else.

The table below lists quantities and units in the catalogue transaction. All quantities must be based on a Unit Of Measure (UOM) according UNECE Recommendation 20 and Recommendation 21 for UOM. For xml-examples for quantities and units, we refer to Example files (ZIP).

Following are two examples showing the use of different elements.

Example 1: Bottles that contain 250m of shampoo are packed in cases, 6 bottles in each case. The cases are stacked 18 on each pallet. The minimum order quantity is always one unit.

Example 2: Printing paper is sold in packs of 500 sheets. 6 packs of paper are packed in cases and 18 cases are stacked on a pallet. Minimum order quantity is one unit.

Following table shows the definition of the business terms shown in the example as well as their syntax binding.

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

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.

Items can be related to each other for ordering or logistic purposes. All related items must also be sent as separate Catalogue lines. Sellers article number is the only permitted type of article number and there for it is important that the Sellers article numbers is provided in catalogue line with the related item.
Types of relations:

The Logistics elements can be used to specify different pack levels for the same item:

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

For some items it is important to inform about storage regulations. The following values can be stated:

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

Replaced item is used to identify an existing item being replaced by an item in this Catalogue.

TAX information on line level is provided in the class cac:ClassifiedTaxCategory.

Each line may have the item TAX information including category code and percentage.

Semantic data type content may be of the following primitive types. These primitive types were taken from ISO 15000-5:2014, Annex A.

The different semantic data types are described in the tables below, where various features such as attributes, format, and decimals as well as the basic type are defined for each semantic data type. They are based on ISO 15000-5:2014.

When used in an instance document, each data element will contain data. In the below tables this is identified as the “content”. Whenever a business term is used this term shall always have content and therefore the content is always mandatory.