This document describes the new version of Pre-Award Catalogue (called "EHF Tilbudskatalog" in Norwegian) and Pre-Award Catalogue Request (called "EHF Forespørselskatalog" in Norwegian). The document is part of Norwegian "Agency of Public Management and eGovernment" (Difi) standardization work related to electronic commerce.

Introduction

The purpose of this document is to describe a common format for the pre award catalogue messages in the European market, and to facilitate an efficient implementation and increased use of electronic collaboration, both in the tendering process as well as in the bridging between pre- and post award catalogues.

1. Definitions

Catalogue

A catalogue is a structured document of items (e.g., goods and services) description that is available in a format so that it can be processed electronically.

Pre-Award catalogue request

A pre-award catalogue request is a catalogue of requirements on products (goods or services) intended to be bought by a Contracting Authority.
SOURCE: CWA 17028-402:2016, definition 3.3

Pre-Award catalogue

A pre-award catalogue is a catalogue used by an economic operator to provide the information on the offered products as an answer to a call for tenders and the corresponding pre-award catalogue request.
SOURCE: CWA 17028-402:2016, definition 3.2

Post-Award catalogue

A post-award catalogue is a catalogue used by an economic operator to provide the information in the post-award phase, i.e., to provide the information necessary for a placing an order for requested items with an economic operator.
A post-award catalogue might be based on a pre-award catalogue as well as based on a framework agreement or an agreement from a tender.

Catalogue provider

The party that sends the catalogue.

Catalogue receiver

The party that receives the catalogue.

Contracting authority (CA)

The contracting authority or contracting entity who is buying supplies, services or tendering works.

Economic operator (EO)

Party participating with a tender in a procurement process to sell goods, services or works.

Supplier

The supplier is the legal person or organization who provides a product, service or works. Examples of supplier roles are seller, consignor, creditor and economic operator.

Customer

The customer is the legal person or organization who is in demand of a product, service or works. Examples of customer roles are buyer, consignee, debtor and contracting body.

Buyer

The buyer is the legal person or organization acting on behalf of the customer and who buys or purchases the goods or services.

Seller

The seller is the legal person or organization acting on behalf of the supplier and who sells goods or services to the customer.

2. Background

The Pre-award catalogue request is a tool for Contracting authorities (CA) to describe requirements and required characteristics for respectively of goods, services and works in a structured manner. A Pre-award catalogue request contains a generic description of the CA’s needs. Based on the generic descriptions and requirements the economic operator (EO) creates a Pre-award catalogue based on their own assortment of goods, services or works to fulfil the requirements of the CA. Means of proof can be included and the evidence must be provided by EO in the pre-award catalogue.

Means for providing generic descriptions of requirements can be classifications systems such as UNSPSC, CPV or eCl@ss. These classification systems provide codes that codify classes of goods, services or works in a vendor-neutral manner. Furthermore, some of these classification systems codify properties of goods, services or works by providing property codes, for instances, codes for length, width or height of a goods.

But also required skills or non-functional requirements may specified in a Pre-award catalogue requests, for instance, to specify that environmental aspects shall be considered by the offered goods, services, or works, or to specify that certain professional skills, for instance, to able to work as a nurse, are required. To prove that these requirements or skills are fulfilled respectively are available labels or information on other means of proof can then be provided in the Pre-award catalogue by the EO.

Summarized, using electronic catalogues in the tendering procedures will save processing time both for EO’s and CA’s and will enhance transparency and traceability of goods, services and works. To achieve efficient and effective processes, the EO should have their own e-submission systems based on a 4-corner model to be able to communicate with different tendering platforms based on standard formats and PEPPOL eDelivery network.

This diagram illustrates the catalogue process:

processdiagram
Figure 1. Diagram for the catalogue processes.

3. Process and Typical Use Cases


3.1. Pre-Award Catalogue Request


3.1.1. Process Diagram

The following diagram illustrates the basic EHF Pre-Award Catalogue Request process.

catalogueRequestDiagram1
Figure 2. EHF Pre-Award Catalogue Request process.


3.1.2. Use Cases

Use case 1

Certification/conformity assessment of certain skills as surgical nurse, midwife, different kinds of engineers or other specialty of occupation can also be used. CA has stored the generic description and requirements via a Pre-award catalogue request in the tendering system, and based on that Pre-award catalogue request an automated evaluation of the different offers (in shape of Pre-award catalogues) from different economic operators can be performed. In this cases, the required skills are described in the Pre-award catalogue and the economic operator provides the means of proof in the Pre-award catalogue to proof that the required skills are provided.

In the evaluation process the pre-award catalogues will be stored. After signing the contract with EO, the Pre-award catalogue can be transferred to the eProcurement system (catalogue tool) to be used as baseline to compare the catalogue to the contract, if the catalogue is updated by the economic operator.

Use case 2

Pre-award catalogue requests can be used in a Dynamic Purchasing System (DPS) as a carrier of contracting authorities needs towards suppliers qualified for the DPS supplier group. Automatically evaluation of incoming, tenders in the form of Pre-award catalogue, will save contracting authority handling cost, as these Pre-award catalogues can be used to cross-check them with stored Pre-award catalogue request. DPS will also stimulate small and medium-sized enterprises (SME) to get involved in tenders because the needs are specified in a structured manner, easier to handle and can be used to create an offer in shape of a Pre-award catalogue automatically based on a Pre-award catalogue request.

Use case 3

A CA wants to buy goods, services or works that can be described easily. "Described easily" means that it is possible to specify the requirements on the products or services to be bought by the CA. Examples for such products are products for maintenance, repair and operations like office supplies. Standardized services can be different kind of substitute services for different kinds of professions. To describe the requirements contracting authority fill in pre-award catalogue request. The pre-award catalogue request specifies the requirements, e.g., the size and the thickness of the printer paper on the products in a structured and vendor-neutral manner.

After subscribing to a tender, an economic operator from Norway uses its tendering platform 123-Nor to receive the structured documents and store it in his system. The system fills the information on goods and services into the Pre-award catalogue using information from the economic operator’s ERP system as well as procurement documents. Finally, the system prepares all theses documents for submission as a tender and submits it.

The contracting authorities tendering platform ABC-Germania receives the procurement documents and imports the Pre-award catalogue into the evaluation system and compare all received Pre-award catalogues with each other and the Pre-award catalogue requests to find the best tender of goods or services automatically.

Use case 4

An economic operator finds an interesting business opportunity after a search on a tendering platform. The tender informs the economic operator that this is a Dynamic Purchasing System (DPS) process. After passing the qualification to the DPS, the economic operator is able to receive requests for goods, services or work from contracting authority.

When contracting authority has a need for goods or services, it provides the generic descriptions for the different requirements by creating a Pre-award catalogue request together with other structured tender documents containing more high-level requirements. These documents are made available in the DPS.

The economic operator uses the Pre-award catalogue request to match the requirements with the product specification in its own system for product information (or catalogue) management. As a result, the economic operator retrieves a list of goods/service information that fulfil the requirements and the system creates a Pre-award catalogue.

The contracting authority receives the Pre-award catalogue and automatically evaluate the tenders from the various economic operator. The contracting authority choses the winner and inform all participating economic operator and then sends the contract for signing to the winning economic operator.

The winning Pre-award catalogue will be then the basis for placing orders, receiving reception of goods and services and atomically checking of sent invoices.

3.2. Pre-Award Catalogue


3.2.1. Process Diagram

The following diagram illustrates the basic EHF Pre-Award Catalogue process.

catalogueDiagram1
Figure 3. EHF Pre-Award Catalogue process.


3.2.2. Use Case

On behalf of many municipalities or governmental entities a central unit has been given the task to accomplish a tender for the group on office supplies.

The call for tender includes a structured pre-award catalogue request with the needs for the group. The economic operator (tenderer) that prepares the tender downloads or receive the catalogue request as part of the procurement documents. The pre-award catalogue request is containing descriptions of product and services the group needs in a generic way, e.g. blue pen.

Economic operators choose their own products or services that fulfills the requirement and make use of a supplier eSubmission system to fill out the requested information as product number, product description, UoM (unit of measure) code, price, link to pictures and labels for environmental and social labels if required and so on. If the contracting authority provided structured information on the required goods, services or works base on codified property systems, for instance, provided by classification systems like GPC or eCl@ss, the economic operator can use this information to retrieve the necessary data on the offered goods, services or works from their product information systems. Futhermore, by using the aforementioned classification systems they can provide these product information in a structured way as well, so that it facilitates the automatic procession and evaluation of the tender.

After finalizing the pre-award catalogue they include the catalogue together with other structured documents or non-structured documents as PDF into the system. The system prepares for submission towards the tender systems by sending the bid package to the access point connected.

When contracting authority receive, through their access point, the pre-award catalogues from different tenderers, as part of the bid packages they lock down the offers. When time for open the bids, tendering system import the pre-award catalogue xml files in to their valuation service and find the best offer of products and/or services.

The central unit import the catalogue into their catalogue tool and check the quality. According to the contract the supplier is sending a post-award catalogue that’s compared towards the pre-award catalogue from the tender. When the catalogue is ok the central unit sends it out of their access point, based on a distribution list in the catalogue tool. The different municipalities or governmental entities is receiving the approved pre-award catalogue in their catalogue tool connected to their eProcurement system. When the catalogue already is approved, the system can automatically display the catalogue content in the eProcurement search engine used by the different entities buyers.

4. Requirements

Table 1. Requirements for pre award catalogue request
Requirement id Description

General

tir-001

A pre-award catalogue request shall be uniquely identifiable.

tir-002

A reference to the corresponding call for tender by its identifying property document this pre-award catalogue request is a part of shall be always specified.

tir-003

It shall be possible to check that the pre-award catalogue request is authentic.

tir-004

It shall be possible to audit the integrity and authentication of the information content.

tir-005

It shall be possible to check the integrity and authentication of the information content.

tir-006

The transaction shall contain all information necessary for its application.

tir-007

It shall be possible to specify information requirements on the pre-award catalogue.

tir-008

A pre award catalogue request shall contain the issue date.

tir-009

The contracting body shall be identified with a name, in addition the postal address, the country of registration, an endpoint and an identifier might be used.

tir-010

It shall be possible to state the issue time.

tir-011

A pre award catalogue request shall contain information on the contracting authority.

tir-012

A pre award catalogue request shall contain information on the receiver, often an economic operator.

tir-013

The receiver shall be identified with a name, in addition the postal address, the country of registration, an endpoint and an identifier might be used.

tir-014

The pre award catalogue request may include information about contacts to obtain additional information.

Item

tir-020

An item in a pre-award catalogue request shall be uniquely identifiable by a name and an identifier.

tir-021

An item may have a description.

tir-022

It shall be possible to refer an item to the corresponding classes from one or more classification systems.

tir-023

It shall be possible to specify information requirement on the items.

tir-024

It shall be possible to specify the required physical location for an requested item.

  • In case of goods, it is the location the goods should be delivered to

  • In case of services, it is the location where the service should be provided

  • In case of works, it is the location where the works should be provided

tir-025

It shall be possible to state requirements on how the item can be ordered.

tir-026

It shall be possible to state requirements on how the item should be delivered.

tir-027

It shall be possible to specify the quantity of an requested item intended to be tendered by the contracting authority. The quantity might be a range of quantities with a minimum and maximum value.

tir-028

The CPV code for an item may be specified.

tir-029

It shall be possible to specify the "non-functional" requirements on requested items referring to environmental, social or other "non-functional" characteristics of the item requirements that might be proven by a means of proof according to 2014/24/EU, Art. 43.

tir-030

It shall be possible to provide additional specification for an requested item as an additional document, e.g., technical specifications or blueprints.

tir-031

It shall be possible to specify an upper price limit on a requested item.

Item property

tir-050

An item property has to be uniquely identifiable.

tir-051

It shall be possible to define an item property in free text.

tir-052

It shall be possible to specify the maximum and/or minimum values of an item property.

tir-053

It shall be possible to specify a range of allowed values for an item property.

tir-054

It shall be possible to refer from an item property to any product groups that are specific, using standardized and predefined properties from accepted standards.

tir-055

It shall be possible to refer from an item property to any property from a product/service classification system, using standardized and predefined properties from accepted standards.

tir-056

It shall be possible to state that an item property in the catalogue is mandatory, optional, not allowed or for information.

Table 2. Requirements for pre award catalogue
Requirement id Description

General requirements

tir-001

The specification on the requested kind of goods and/or services shall be provided in a structured description.

tir-002

A pre-award catalogue shall contain the procurement reference number of the call for tenders.

tir-003

The transaction shall contain all information necessary for its application i.e. it shall not rely on the availability of external references such as a centralised repository of item information. No external data sources should be needed in order to ease the processing of a pre-award catalogue request.

tir-004

It shall be reusable in post-award processes, i.e., a pre-award catalogue shall have information that makes it possible to use as a post-award catalogue, even if some information might be added later in the process. There is a potential difference between the pre-award and the post-award catalogue when it comes to the extent of required information. A "principle of proportionality" means that the information that can be required in relation to a tender and a pre-award catalogue must be in proportion to the offered contract. In a post-award catalogue, after the parties have signed an agreement, more information can be requested by the buyer to describe the products in more details.

Metadata requirements

tir-100

The transaction shall be uniquely identifiable.

tir-101

The transaction shall contain a reference to the Tender transaction the pre-award catalogue belongs to.

tir-102

The transaction shall contain the issue date and time.

tir-103

The transaction shall contain a version number indicating updated versions of the pre-award catalogue.

tir-104

The issuing catalogue provider shall be identified in the transaction with a name, an address, the country of registration, an endpoint and should include an identifier.

tir-105

The corresponding economic operator offering the listed items in the catalogue shall be identified in the transaction with a name, an address, the country of registration, an endpoint and should include an identifier. This might be the same party as the catalogue provider.

tir-106

The party receiving the pre-award catalogue (catalogue receiver) shall be identified in the transaction with a name, an address, the country of registration, an endpoint and should include an identifier.

tir-107

The contracting authority the pre-award catalogue is offered to shall be identified in the transaction with a name, an address, the country of registration, an endpoint and should include an identifier. This might be the same party as the catalogue receiver.

tir-108

The transaction may include contact information to the supplier and customer. E-Mail or internet address at which the procurement documents shall be available for unrestricted and full direct access, free of charge.

tir-109

It shall be possible to check the integrity and authentication of the information content and to audit these aspects of the content. It shall be possible to check that the pre-award catalogue is authentic.

tir-110

The transaction shall specify in which period of time the pre-award catalogue is valid.

tir-111

It shall be possible to reference a contract in the pre-award catalogue, for instance, to be used in re-opening of Tenders or DPS.

Catalogue line requirements

tir-201

A catalogue line is a set of items that can be ordered as such.

tir-202

A catalogue line in a pre-award catalogue shall be uniquely identifiable by an identifier, to ensure that the catalogue line can be referenced, e.g., by an id.

tir-203

To align with post award catalogue, a pre award catalogue line shall specify how the corresponding items can be ordered.

tir-204

To align with post award catalogue, a pre award catalogue shall specify the requirements on the order transaction.

tir-205

A catalogue line may specify the warranty conditions on the items

tir-206

A catalogue line may specify in which period of time the catalogue line is valid.

tir-207

To align with post award catalogue, a pre award catalogue line should provide for an indicator that clearly states whether the line item can be ordered according to the information given in the line.

Item requirements

tir-301

An item is a specification within a catalogue line of an offered goods, services or works by the economic operator

tir-302

An item in a pre-award catalogue shall be uniquely identifiable by a name and an identifier, to ensure that the item can be referenced, e.g., by an id.

tir-303

An item may have a description.

tir-304

To align with post award catalogue, it shall be possible to specify how an item can be ordered. This includes amongst others allowed units of measure, order sizes, minimal and maximal order sizes. There might exist restrictions from the production process or a need to simplify or limit the costs of the ordering and logistics process, so that the order size is restricted. Thus, the buyer needs information to place a correct order that is not denied by the supplier.

tir-305

It shall be possible to specify how the items will be packaged.

tir-306

It shall be possible to specify logistic conditions and other needed service information on how the item will be delivered. This includes information on maximum and minimum storage temperature, information needed for cross-border logistics processes. To define the products to be done for each package unit along the supply chain.

tir-307

It shall be possible to specify how the item is priced. This includes factors that have influence on the price as well as relationships to other parts of the catalogue that may have impact on the price. The price can be dependent on many factors, e.g., delivery region (down to the city level), allowance, charges, currency, etc.

tir-308

It should be possible to specify the period of time an item price is valid. If no validity period is specified, the price is valid until cancelled.

tir-309

Prices shall not be negative.

tir-310

It shall be possible to provide information that helps to search for the item, e.g., keywords or item description used in a full text search.

tir-311

It shall be possible to refer an item to the corresponding classes from one or more classification systems.

tir-312

An item might be illustrated by attached images.

tir-313

An item might include further specifications as attachments.

tir-314

It might be specified how the item will be delivered. This includes information on the packaging and the conditions for certain delivery locations.

tir-315

An item shall include information that allow to compare the item with other items.

tir-316

It shall be possible to provide information on means of proof according to 2014/24/EU, Art. 43 as well as other kind of information on labels, test reports etc. for an offered item to proof that related requirements specified in the corresponding Pre-award catalogue request are fulfilled by the offered item.

tir-317

It should be possible to specify the manufacturer of the item. In particular, for the case where the supplier is different from the manufacturer of the item.

tir-318

It should be possible to specify hazard indicators for an item by any indicator system. If an item can be a danger to people or the environment, so called hazardous goods, often legal requirements demand that such items have indicators to indicate the danger that come from this item. Furthermore, such items require special handling in the logistics process

tir-319

It shall be possible to specify the semantic relationships with cardinalities between different items in the pre-award catalogue request. In particular, it shall be possible to specify part-of relationships, to specify that not only an item is tendered, but also additional items belonging to it. E.g., items that are accessories for other items or are replacements for defect components of an item. This helps to specify for instance that not only printers are tendered, but also print cartridges.

tir-320

It should be possible to specify a delivery location with address, city, post code, etc., so that all details on each line are dependent on this location, including price, tax and other specifications. Needed to support the buying decision, to see how much has to be paid in the end.

tir-321

It should be possible to specify a manufacturing date, a best before date and an expiry date (last date when product may be used or consumed) for an item.

tir-322

It should be possible to state the country of origin for an item.

Item property requirements

tir-401

An item property specifies one characteristic of an item, e.g., the colour of an offered pen.

tir-402

An item property has to be uniquely identifiable, to ensure that the item property can be referenced.

tir-403

An item property may be related to one or more corresponding properties of one or more classification systems. Any kind of classification system having properties might be used.

tir-404

If an item property is specified, a specific value may to be specified for this item property. The specified value has to hold true for the corresponding item.

tir-405

It shall be possible to specify a range of allowed values for an item property. In order to allow the supplier to offer only values in the range the contracting body needs (e.g. for a RAM memory the contracting body needs values of 1, 2 or 3 GB and no other values, for a maintenance service the action is request within 1 day). The values information allows also a validation check with respect to the offer of the economic operator.

tir-406

An item property might be described using free text.

5. Information models

5.1. Information model Pre-award catalogue request

catalogue request class diagram
Figure 4. Class diagram PreAward catalogue request

5.2. Information model Pre-award catalogue

Pre-award catalogue class diagram
Figure 5. Class diagram PreAward catalogue

6. Detailed Descriptions

This chapter describes selected parts of the information contents of the EHF Pre-Award Catalogue and EHF Pre-Award Catalogue Request.

6.1. Information found in both transactions

6.1.1. Parties and Roles

The important parties and roles in pre-award catalogue and request is described below.

Contracting authority (CA)

The contracting authority or contracting entity who is buying supplies, services or tendering works.

Economic operator (EO)

Party participating with a tender in a procurement process to sell goods, services or works.

Customer

The customer is the legal person or organization who is in demand of a product, service or works. Examples of customer roles are buyer, consignee, debtor and contracting body.

Supplier

The supplier is the legal person or organization who provides a product, service or works. Examples of supplier roles are seller, consignor, creditor and economic operator.

The following diagram illustrates the parties and roles involved in the Pre-Award Catalogue and Catalogue Request.



rolediagram
Figure 6. EHF Catalogue and request rolediagram.

6.1.2. Classification

An item may be classified according to UNSPSC being the mandatory public classification schemes in some countries/sectors. As there is currently no code for UNSPSC in the used code list UNCL 7143, the code "MP" (Product/service identification number) is used. Products can also be classified according to regulatory schemes or classification schemes used in certain business sectors.

Example of UNSPSC code as classification
<cac:CommodityClassification>
    <cbc:ItemClassificationCode listID="MP" listName="UNSPSC">14111511</cbc:ItemClassificationCode>
</cac:CommodityClassification>
Example of CPV code as classification
<cac:CommodityClassification>
    <cbc:ItemClassificationCode listID="STI" listName="CPV">230498234</cbc:ItemClassificationCode> (1)
</cac:CommodityClassification>
1 listID = STI states that the code is a CPV code

6.1.3. Validity Period

In the catalogue request the contracting authority can state the requested delivery period for an item by using the element 'cac:LineValidityPeriod'. If several options exist for the requested delivery period of a particular item/service, the contracting authority can state which is the preferred period (only one instance allowed), and what is the alternative period(s).

Example of the requested delivery period in the pre-award catalogue request
<cac:CatalogueRequestLine>

    <cbc:ID>1</cbc:ID>
    <cac:LineValidityPeriod>
        <cbc:StartDate>2018-10-11</cbc:StartDate>
        <cbc:EndDate>2018-10-13</cbc:EndDate>
        <cbc:DescriptionCode>69</cbc:DescriptionCode>
        (1)
    </cac:LineValidityPeriod>

    <!-- Code omitted for clarity -->

<cac:CatalogueRequestLine>
    <cbc:ID>2</cbc:ID>
    <cac:LineValidityPeriod>
        <cbc:StartDate>2018-10-25</cbc:StartDate>
        <cbc:EndDate>2018-10-27</cbc:EndDate>
        <cbc:DescriptionCode>120</cbc:DescriptionCode>
        (2)
    </cac:LineValidityPeriod>
1 Code 69 indicating the preferred delivery period
2 Code 120 indicating an alternative delivery period
Only one instance of Line validity period with Validity description code = '69' is allowed for the same item/service

In the Pre-Award Catalogue the following validity periods can be stated:

  • Validity period on document level (mandatory), used to state the validity period for the entire Pre-Award Catalogue.

  • Validity period for a catalogue line

  • Validity period for price (See also section 4.7)

All validity periods shall have both start date and end date, and the start date shall be earlier than the end date

Example of validity periods in a Pre-Award Catalogue:

Document level (mandatory)
<cac:ValidityPeriod>
    <cbc:StartDate>2018-11-20</cbc:StartDate>
    <cbc:EndDate>2018-12-30</cbc:EndDate>
</cac:ValidityPeriod>
Catalogue line
<cac:LineValidityPeriod>
    <cbc:StartDate>2018-11-20</cbc:StartDate>
    <cbc:EndDate>2018-12-15</cbc:EndDate>
</cac:LineValidityPeriod>
Two different validity period for a given price
<cac:RequiredItemLocationQuantity>
    <cac:Price>
        <cbc:PriceAmount currencyID="NOK">75.00</cbc:PriceAmount>
        <cbc:PriceTypeCode>NE</cbc:PriceTypeCode>
        <cac:ValidityPeriod>
            <cbc:StartDate>2018-11-20</cbc:StartDate>
            <cbc:EndDate>2018-11-30</cbc:EndDate>
        </cac:ValidityPeriod>

        <cac:ValidityPeriod>
            <cbc:StartDate>2018-12-01</cbc:StartDate>
            <cbc:EndDate>2018-12-10</cbc:EndDate>
        </cac:ValidityPeriod>
    </cac:Price>
</cac:RequiredItemLocationQuantity>

6.1.4. Attachments

Attachments can be sent on line level in the pre award catalogue request, to add further item specifications. In the request no binary attachments are allowed, only providing external uri to the document, and also the possibility to add information on hash-value.

In the pre-award catalogue additional specifications or product images can be sent. In both the request and the catalogue, the element used is cac:ItemSpecificationDocumentReference

It is strongly recommended to use external references in the form of URI’s for attachments.
Example of using external reference in the pre-award catalogue
<cac:Item>
  ...
  <cac:ItemSpecificationDocumentReference>
    <cbc:ID>LK8788</cbc:ID>
    <cbc:DocumentDescription>Product image</cbc:DocumentDescription>
    <cac:Attachment>
      <cac:ExternalReference>
        <cbc:URI>http://img.trioving.net/Låskasser/LK8788_PRD_FPM_000.JPG</cbc:URI>
      </cac:ExternalReference>
    </cac:Attachment>
  </cac:ItemSpecificationDocumentReference>
  ...
</cac:Item>

If binary objects are attached to the Pre-Award Catalogue, the valid values for mimetype can be found in codelist.

Example of using attached binary objects
<cac:ItemSpecificationDocumentReference>
    <cbc:ID>2384-34232-342-34-2333</cbc:ID>
    <cac:Attachment>
        <cbc:EmbeddedDocumentBinaryObject mimeCode="application/pdf" filename="specification.pdf"
        >ZGVmYXVsdA==</cbc:EmbeddedDocumentBinaryObject>
    </cac:Attachment>
</cac:ItemSpecificationDocumentReference>

6.1.5. Prices

In the pre-award catalogue request the contracting authority can specify the minimum and maximum price, using the element cac:RequiredItemLocationQuantity/cac:Price. The prices can be specific for a location, meaning different locations can have different minimum and maximum prices.

UBL example requesting both a minimum and a maximum price
<cac:RequiredItemLocationQuantity>
    <cac:Price>
        <cbc:PriceAmount currencyID="NOK">5000</cbc:PriceAmount>
        <cbc:PriceTypeCode>NE</cbc:PriceTypeCode> (1)
    </cac:Price>
</cac:RequiredItemLocationQuantity>
<cac:RequiredItemLocationQuantity>
    <cac:Price>
        <cbc:PriceAmount currencyID="NOK">2500</cbc:PriceAmount>
        <cbc:PriceTypeCode>ABG</cbc:PriceTypeCode> (2)
    </cac:Price>
</cac:RequiredItemLocationQuantity>
1 Code NE to indicate maximum prices
2 Code ABG to indicate minimum prices

In the corresponding pre-award catalogue the following prices can be stated:

  • Item price is net price including all discounts and charges but excluded Vat.

  • Item comparison unit price defining price for a certain quantity. Used for comparing prices for different articles with various quantities.

  • Conditional price related to a specific location or a certain quantity.

  • Campaign price.

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

Example of prices in Pre-Award Catalogue:

Item Price
<cac:RequiredItemLocationQuantity>
    <cac:Price>
        <cbc:PriceAmount currencyID="NOK">3000.00</cbc:PriceAmount>
    </cac:Price>
</cac:RequiredItemLocationQuantity>
Comparison Price
<cac:ItemComparison>
    <cbc:PriceAmount currencyID="NOK">270.00</cbc:PriceAmount>
    <cbc:Quantity unitCode="EA">10</cbc:Quantity>
</cac:ItemComparison>
Conditional Price
<cac:RequiredItemLocationQuantity>
    <cac:Price>
        <cbc:PriceAmount currencyID="NOK">29.00</cbc:PriceAmount>
    </cac:Price>
</cac:RequiredItemLocationQuantity>

6.1.6. Requested Item Properties

Requested item properties are used in the pre-award catalogue request transaction to request specific properties of an item, like a specific colour of an item, and is sent in the UBL element cac:AdditionalItemProperty. This element can contain information on requested property name, quantity, range, classification and request relevance, i.e if the property request is optional, forbidden or used for evaluation purposes. If the relevance code is not set this means that information on that property shall be included in the corresponding pre-award catalogue, i.e it is mandatory. If the code is F (forbidden) this cannot be a property of the item, and hence its value shall not be sent in the catalogue.

The requested item property identifier must be unique within one request, and this identifier must also be used in the corresponding pre-award catalogue, if the element sent.

See further details and examples of the response in a pre-award catalogue in chapter Additional Item Properties

Example to request a specific proportion of fat in milk
<cac:AdditionalItemProperty>
    <cbc:ID>1</cbc:ID>(1)
    <cbc:Name>Fat</cbc:Name>(2)
    <cbc:ValueQuantity unitCode="P1">3</cbc:ValueQuantity>(3)
    <cbc:ValueQualifier>Proportion of fat</cbc:ValueQualifier>
</cac:AdditionalItemProperty>
(4)
1 Unique (in this request) identifier
2 the name of the requested property as free text
3 The quantity and unit code requested, here 3%
4 No relevance code is sent, hence it is mandatory to send this information in the corresponding pre-award catalogue
Example to request a specific range of item net quantity
<cac:AdditionalItemProperty>
    <cbc:ID>2</cbc:ID>
    <cbc:Name>Item net quantity</cbc:Name>(1)
    <cac:ItemPropertyRange>
        <cbc:MinimumValue>1 liter</cbc:MinimumValue>(2)
        <cbc:MaximumValue>1,75 liters</cbc:MaximumValue>(3)
    </cac:ItemPropertyRange>
    <cbc:ImportanceCode>O</cbc:ImportanceCode>(4)
</cac:AdditionalItemProperty>
1 the name of the requested property as free text
2 Minimum requested item net quantity
3 Maximum requested item net quantity
4 The relevance code, according to Property relevance codes
Example to request a specific element
<cac:AdditionalItemProperty>
    <cbc:ID>3</cbc:ID>(1)
    <cbc:Name>Item net quantity</cbc:Name>(3)
    <cbc:NameCode>BT-056</cbc:NameCode>(2)
</cac:AdditionalItemProperty>
1 Unique (in this request) identifier
2 Business term identifier of the requested element
3 the name of the requested element as found in the code list

6.1.7. Environment, Social and Innovative requirements

Public actors may have special green, social or innovative requirements to the works, supplies or services they intend to purchase, and they might ask for labels, test reports, certificates or other means of proof for these requirements.

Contracting authorities requiring a specific label shall accept all labels that confirm that the works, supplies or services meet equivalent label requirements.

These requirements are sent in the element 'cac:Certificate' in the pre award catalogue request, and the economic operator sends their answer and attachments (if any), in the cac:Certificate-element in the pre-award catalogue.

The 'cac:Certificate' contains detailed information on the requirement(s), if the requirement is an absolute criteria (must be fulfilled) or an award criteria. In addition, the type of evidence (means of proof) that can be used is stated as well.

Example showing a requirement to fulfill the EU GPP energy criteria for computers, and stating that a Type 1 (or equivalent) certificate can be used as means of proof.
<cac:Certificate>
    <cbc:ID>1</cbc:ID>
    <cbc:CertificateTypeCode>Energy consumption</cbc:CertificateTypeCode>(1)
    <cbc:CertificateType>EU GPP Criteria - Minimum energy performance of the
        computer.</cbc:CertificateType>(2)
    <cbc:Remarks>Absolute</cbc:Remarks>(3)
    <cac:IssuerParty>
        <cac:PartyName>
            <cbc:Name>NA</cbc:Name>
        </cac:PartyName>
    </cac:IssuerParty>
    <cac:DocumentReference>
        <cbc:ID>1</cbc:ID>
        <cbc:DocumentTypeCode>Type1</cbc:DocumentTypeCode>(4)
        <cbc:DocumentType>Green</cbc:DocumentType>(5)
        <cac:Attachment>
            <cac:ExternalReference>
                <cbc:URI>http://www.eu-energystar.org/specifications.htm</cbc:URI>(6)
            </cac:ExternalReference>
        </cac:Attachment>
    </cac:DocumentReference>
</cac:Certificate>
1 Main level requirement
2 Specific requirement
3 The requirement is absolute, use codes from Absolute or award criteria codes
4 A Type 1 certificate is asked for as the means of proof level
5 Green requirement
6 Reference to the specification of the suggested means of proof.
Example showing a response to this requirement in the pre-award catalogue, providing another type of proof then what is mentioned in the request.
<cac:Certificate>
    <cbc:ID>1</cbc:ID> (1)
    <cbc:CertificateTypeCode>Energy consumption</cbc:CertificateTypeCode> (2)
    <cbc:CertificateType>EU GPP Criteria - Minimum energy performance of the computer.</cbc:CertificateType> (3)
    <cac:IssuerParty>
        <cac:PartyName>
            <cbc:Name>NA</cbc:Name>
        </cac:PartyName>
    </cac:IssuerParty>
    <cac:DocumentReference>
        <cbc:ID>1</cbc:ID>
        <cbc:DocumentTypeCode>TestReport</cbc:DocumentTypeCode> (4)
        <cbc:DocumentType>EU Energy Star</cbc:DocumentType> (5)
        <cbc:DocumentDescription>Registered in Energy Star database</cbc:DocumentDescription> (6)
        <cac:Attachment>
            <cac:ExternalReference>
                <cbc:URI>http://www.eu-energystar.org/database-register.htm</cbc:URI> (7)
            </cac:ExternalReference>
        </cac:Attachment>
    </cac:DocumentReference>
</cac:Certificate>
1 The identifier must be the same as what was sent in the request.
2 References to the general requirement as sent in the request
3 Reference to the specific requirement as sent in the request
4 Means of proof level provided
5 Specific means of proof details
6 Description of the means of proof
7 Link to the database for registration.
Life cycle analysis (LCA)

Below you can find two examples on how to state requirements on LCA

<cac:Certificate>
    <cbc:ID>1</cbc:ID>
    <cbc:CertificateTypeCode>Climate change (GWP)</cbc:CertificateTypeCode>
    <cbc:CertificateType>Max 4 (kg C02-e)/liter</cbc:CertificateType>
    <cbc:Remarks>Absolute</cbc:Remarks>
    <cac:IssuerParty>
        <cac:PartyName>
            <cbc:Name>X</cbc:Name>
        </cac:PartyName>
    </cac:IssuerParty>
    <cac:DocumentReference>
        <cbc:ID>1</cbc:ID>
        <cbc:DocumentTypeCode>Type3</cbc:DocumentTypeCode>
        <cbc:DocumentType>Green</cbc:DocumentType>
    </cac:DocumentReference>
</cac:Certificate>

<cac:Certificate>
    <cbc:ID>2</cbc:ID>
    <cbc:CertificateTypeCode>Land system change</cbc:CertificateTypeCode>
    <cbc:CertificateType>(m2-years agr)/liter</cbc:CertificateType>
    <cbc:Remarks>Award</cbc:Remarks>
    <cac:IssuerParty>
        <cac:PartyName>
            <cbc:Name>X</cbc:Name>
        </cac:PartyName>
    </cac:IssuerParty>
    <cac:DocumentReference>
        <cbc:ID>1</cbc:ID>
        <cbc:DocumentTypeCode>Other</cbc:DocumentTypeCode>
        <cbc:DocumentType>Green</cbc:DocumentType>
    </cac:DocumentReference>
</cac:Certificate>

6.1.8. VAT

VAT information on line level is provided in the class cac:ClassifiedTaxCategory in both the pre-award catalogue request and the pre-award catalogue.

VAT information is optional in both transactions, but if the contracting authority has sent VAT info in the pre-award catalogue request, the economic operator should provide this information in the corresponding pre-award catalogue.

Example of using VAT.
<cac:ClassifiedTaxCategory>
    <cbc:ID>S</cbc:ID>
    <cbc:Percent>25</cbc:Percent>
    <cac:TaxScheme>
        <cbc:ID>VAT</cbc:ID>
    </cac:TaxScheme>
</cac:ClassifiedTaxCategory>

6.1.9. Delivery location coordinate

In the pre-award catalogue request, the contracting authority can specify the location coordinate for delivery, as well as a description/comment on the location coordinate. This is done by using the UBL extension element.

Example of a particular location stated, and a comment that 1 hour drive from the given location is allowed
<ext:UBLExtensions>
    <ext:UBLExtension>
        <cbc:ID>urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2</cbc:ID>
        <cbc:Name>Delivery location</cbc:Name>
        <ext:ExtensionContent>
            <cac:DeliveryLocation>
                <cbc:Description>Maximum 1 hour drive from stated location coordinates</cbc:Description>
                <cac:LocationCoordinate>
                    <cbc:LatitudeDegreesMeasure unitCode="DD">40</cbc:LatitudeDegreesMeasure>
                    <cbc:LatitudeMinutesMeasure unitCode="D61">26.767</cbc:LatitudeMinutesMeasure>
                    <cbc:LatitudeDirectionCode>N</cbc:LatitudeDirectionCode>
                    <cbc:LongitudeDegreesMeasure unitCode="DD">79</cbc:LongitudeDegreesMeasure>
                    <cbc:LongitudeMinutesMeasure unitCode="D61">58.933</cbc:LongitudeMinutesMeasure>
                    <cbc:LongitudeDirectionCode>W</cbc:LongitudeDirectionCode>
                </cac:LocationCoordinate>
            </cac:DeliveryLocation>
        </ext:ExtensionContent>
    </ext:UBLExtension>
</ext:UBLExtensions>

In the corresponding pre-award catalogue the economic operator can provide coordinates for the exact delivery, as well as a description/comment.

6.2. Information specific to the pre-award catalogue

6.2.1. Additional Item Properties

Additional properties are used to send information on item properties

All properties that is corresponding to a requested item property from the pre-award catalogue request, shall use the identifier and name as sent in the request.

Additional item properties are sent in pre-award catalogue in the UBL element cac:AdditionalItemProperty.

Example of a pre-award catalogue property as a response to the requested property of 3% fat in milk (as in the above chapter)
<cac:AdditionalItemProperty>
    <cbc:ID>1</cbc:ID>
    <cbc:Name>Fat</cbc:Name>
    <cbc:Value>Proportion of fat</cbc:Value>
    <cbc:ValueQuantity unitCode="P1">3</cbc:ValueQuantity>
</cac:AdditionalItemProperty>
Example of a pre-award catalogue property as a response to the requested minimum and maximum range of the net quantity (as in the above chapter)
<cac:CatalogueLine>
    <cbc:ID>1</cbc:ID>
    <cbc:OrderableIndicator>true</cbc:OrderableIndicator>
    <cbc:OrderableUnit>XCT</cbc:OrderableUnit>
    <cbc:ContentUnitQuantity unitCode="LTR">1.50</cbc:ContentUnitQuantity> (1)
     <!-- ... -->
1 The item net quantity is sent in the ContentUnitQuantity in the pre-award catalogue
Other examples of additional properties in a pre-award catalogue
Nutrition
<cac:AdditionalItemProperty>
    <cbc:ID>1</cbc:ID>
    <cbc:Name>NutritionProtein</cbc:Name>
    <cbc:Value>Nutrition</cbc:Value>
    <cbc:ValueQuantity unitCode="GRM">2.5</cbc:ValueQuantity>
    <cbc:ValueQualifier>Nutrition</cbc:ValueQualifier>
</cac:AdditionalItemProperty>
Allergens
<cac:AdditionalItemProperty>
    <cbc:Name>Allergens</cbc:Name>
    <cbc:Value>Item contains 5% hazelnuts by volume.</cbc:Value>
    <cbc:ValueQuantity unitCode="60">5</cbc:ValueQuantity>
    <cbc:ValueQualifier>HAZELNUTS</cbc:ValueQualifier>
</cac:AdditionalItemProperty>
Genetically modified
<cac:AdditionalItemProperty>
    <cbc:Name>GeneticallyModified</cbc:Name>
    <cbc:Value>True</cbc:Value>
</cac:AdditionalItemProperty>

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

Types of relations:

  • Required related items are products that are bundled and ordered/invoiced together, e.g. bottles and deposits.

  • Component related items are products that are connected in a product line or a logistics structure, e.g. consumer units and trading units of the same article.

  • Complementary related item is used for items that might be sold together with a product, e.g. disk station to a laptop.

Examples of related products in a Pre-Award Catalogue message

Bundled products
<cac:RequiredRelatedItem>
    <cbc:ID>987654</cbc:ID>
    <cbc:Quantity unitCode="EA">1</cbc:Quantity>
</cac:RequiredRelatedItem>
Logistics structure
<cac:ComponentRelatedItem>
    <cbc:ID>89388789930</cbc:ID>
    <cbc:Quantity unitCode="EA">12</cbc:Quantity>
</cac:ComponentRelatedItem>
Accessories
<cac:ComplementaryRelatedItem>
    <cbc:ID>123456</cbc:ID>
    <cbc:Quantity unitCode="EA">1</cbc:Quantity>
</cac:ComplementaryRelatedItem>

6.2.3. Quantities and Units

There are various quantities and units that can be used in the Pre-award catalogue. Here is a detailed list of relevant quantities and units:

Orderable unit (OrderableUnit)

The unit in which the item described in this catalogue line can be ordered.

Item net quantity (ContentUnitQuantity)

The net quantity of the item that is contained in each consumable unit (excluding packaging material), e.g. ml in bottles of shampoo.

Order quantity increment (OrderQuantityIncrementNumeric)

Possible limitation to the number of articles that can be ordered. If the Quantity increment is 6 the article shall be ordered in a quantity of 6, 12, 18 etc.

Minimum order quantity (MinimumOrderQuantity)

The smallest number of items that can be ordered (most often 1).

Maximum order quantity (MaximumOrderQuantity)

The largest number of items that can be ordered (most often unlimited).

Packed quantity (Item/PackQuantity)

Number of items on next lower level, e.g. number of Consumer units in a Trading unit.

Consumable unit quantity (Item/PackSizeNumeric)

Number of Consumer items in the orderable unit. E.g. number of bottles on a pallet.

Item quantity for component related item(ComponentRelatedItem/Quantity)

Quantity of the related component.

Handling unit height or length or width or gross weight (Dimension/Measure)

The dimensions of the handling unit.

Handling unit minimum storage temperature (Dimension/MinimumMeasure)

The lower margin of the recommended storage temperature range for the item.

Handling unit maximum storage temperature (Dimension/MaximumMeasure)

The upper margin of the recommended storage temperature range for the item.

Handling unit minimum storage humidity (Dimension/MinimumMeasure)

The lower margin of the recommended storage humidity range for the item.

Handling unit maximum storage humidity (Dimension/MaximumMeasure)

The upper margin of the recommended storage humidity range for the item.

Item property value quantity (AdditionalItemProperty/ValueQuantity)

The quantity of the requested item property.

Table 3. Example of quantites and units.
Description Element (from CatalogueLine level) 1 bottle Case of 6 bottles Pallet of 18 cases

Line identifier

ID

1

2

3

Sellers item identifier

SellersItemIdentification/ID

2222

222

22

Item name

Item/Name

Milk 1L

6 x 1L Milk

Milk

Orderable Unit

OrderableUnit

XBO

CS

PF

Packaging level

PackLevelCode

CU

TU

DU

Packed quantity

Item/PackQuantity

6

18

Packed quantity unit

Item/PackQuantity/@unitCode

XBO

CS

Consumable unit quantity

Item/PackSizeNumeric

1

6

108

Item net quantity

ContentUnitQuantity

1000

6000

108000

Item net quantity unit

ContentUnitQuantity/@unitCode

MLT

MLT

MLT

Minimum order quantity

MinimumOrderQuantity

1

1

1

Minimum order quantity unit

MinimumOrderQuantity/@unitCode

XBO

CS

PF

Component related item identifier

ComponentRelatedItem/ID

2222

222

Item quantity for component related item

ComponentRelatedItem/Quantity

6

18

Example of catalogue line with line identifier = 1 from the above table.
<cac:CatalogueLine>
    <cbc:ID>1</cbc:ID>
    <cbc:OrderableIndicator>true</cbc:OrderableIndicator>
    <cbc:OrderableUnit>XBO</cbc:OrderableUnit>
    <cbc:ContentUnitQuantity unitCode="MLT">1000</cbc:ContentUnitQuantity>
    <cbc:OrderQuantityIncrementNumeric>1</cbc:OrderQuantityIncrementNumeric>
    <cbc:MinimumOrderQuantity unitCode="XBO">1</cbc:MinimumOrderQuantity>
    <cbc:PackLevelCode>CU</cbc:PackLevelCode>
    <!-- ... -->
    <cac:Item>
        <cbc:Name languageID="en">Milk 1 Liter</cbc:Name>
        <cac:SellersItemIdentification>
            <cbc:ID>2222</cbc:ID>
        </cac:SellersItemIdentification>
        <!-- ... -->
    </cac:Item>
    <!-- ... -->
</cac:CatalogueLine>

6.2.4. Logistics Information

The Pre-Award Catalogue includes elements to support the need for logistics information which is a requirement in many industries. 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 shall be done as follows:

  • Each pack level is regarded as a unique product and shall be sent as a separate Catalogue line and identified with a unique ID such as GTIN.

  • Information about pack level is done in the element PackLevelCode on line level. The Pack level codes are based on the Edifact/Eancom-standard and the following codes are available (codes in brackets are used in some business sectors in Norway):

    • DU = Dispatch Unit (T-Pak)

    • HN = Handling Unit (level between TU and DU). Not commonly used.

    • TU = Traded Unit (D-Pak or L-Pak)

    • CU = Consumer Unit (F-Pak)

  • It shall be stated if the pack level is orderable.

  • The relation between pack levels shall be specified, e.g. that a Dispatch unit contains Traded units.

When component related items are used, all the items in the Pre-Award Catalogue shall specify the Sellers item identifier

Below is an example of Logistics information in a Pre-Award Catalogue message.

Catalogue line for Dispatch unit, highest pack level.
<cac:CatalogueLine>
    <cbc:ID>1</cbc:ID>
    <cbc:OrderableIndicator>false</cbc:OrderableIndicator>
    <cbc:PackLevelCode>DU</cbc:PackLevelCode>
    <cac:ComponentRelatedItem>
        <cbc:ID>222222</cbc:ID> (1)
        <cbc:Quantity unitCode="XBO">12</cbc:Quantity> (2)
    </cac:ComponentRelatedItem>
    <cac:Item>
        <cbc:Description>Soft drink, pallet</cbc:Description>
        <cbc:PackQuantity unitCode="EA">1</cbc:PackQuantity>
        <cbc:Name languageID="en">Soft drink</cbc:Name>
        <cac:SellersItemIdentification>
            <cbc:ID>111111</cbc:ID>
        </cac:SellersItemIdentification>
    </cac:Item>
</cac:CatalogueLine>
1 References the sellers item identification for the component line
2 Quantity of that component (each dispatch unit contains 12 traded units)
Catalogue line for Traded unit.
<cac:CatalogueLine>
    <cbc:ID>2</cbc:ID>
    <cbc:OrderableIndicator>true</cbc:OrderableIndicator>
    <cbc:OrderableUnit>XCS</cbc:OrderableUnit>
    <cbc:PackLevelCode>TU</cbc:PackLevelCode>
    <cac:ComponentRelatedItem>
        <cbc:ID>333333</cbc:ID> (1)
        <cbc:Quantity unitCode="XBO">6</cbc:Quantity> (2)
    </cac:ComponentRelatedItem>
    <cac:Item>
        <cbc:Description>Soft drink, trading unit</cbc:Description>
        <cbc:PackQuantity unitCode="EA">1</cbc:PackQuantity>
        <cbc:Name languageID="en">Soft drink</cbc:Name>
        <cac:SellersItemIdentification>
            <cbc:ID>222222</cbc:ID>
        </cac:SellersItemIdentification>
    </cac:Item>
</cac:CatalogueLine>
1 References the sellers item identification for the component line
2 Quantity of that component (each traded unit contains 6 consumer units)
Catalogue line for Consumer unit, lowest pack level.
<cac:CatalogueLine>
    <cbc:ID>3</cbc:ID>
    <cbc:OrderableIndicator>false</cbc:OrderableIndicator>
    <cbc:PackLevelCode>CU</cbc:PackLevelCode>
    <cac:Item>
        <cbc:Description>Soft drink 4-pack</cbc:Description>
        <cbc:PackQuantity unitCode="EA">1</cbc:PackQuantity>
        <cbc:Name languageID="en">Soft drink</cbc:Name>
        <cac:SellersItemIdentification>
            <cbc:ID>333333</cbc:ID>
        </cac:SellersItemIdentification>
    </cac:Item>
</cac:CatalogueLine>

6.2.5. Hazardous Item

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

Example of UNDG code
<cac:HazardousItem>
    <cbc:ID>0024</cbc:ID>
    <cbc:UNDGCode>ADR</cbc:UNDGCode>
</cac:HazardousItem>
Example of attachement with further specification
<cac:ItemSpecificationDocumentReference>
    <cbc:ID>1</cbc:ID>
    <cbc:DocumentDescription>HMS Safety sheet</cbc:DocumentDescription>
    <cac:Attachment>
        <cac:ExternalReference>
            <cbc:URI>http://www.klif.no/no/Tema/Kjemikalier/Klassifisering-og-merking-av-kjemikalier-CLP/Klassifisering-CLP-avsnitt-I-II-og-V/</cbc:URI>
        </cac:ExternalReference>
    </cac:Attachment>
</cac:ItemSpecificationDocumentReference>

6.2.6. Keyword

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

Example of several Keywords in the same tag.
<cac:Item>
    <cbc:Description> Pallet of water </cbc:Description>
    <cbc:Name languageID="en">Water</cbc:Name>
    <cbc:Keyword>sparkling%natural%water</cbc:Keyword>
    <cac:SellersItemIdentification>
        <cbc:ID>111111</cbc:ID>
    </cac:SellersItemIdentification>
</cac:Item>

7. Code lists

7.1. Code lists for coded elements

Any element with the semantic data type = code, can mandate the use of a specific code list (or a fixed value). The applicable code lists can be found in the Code list section. In this section, you can find the valid codes, their names and description, and also links to where the same code list is used elsewhere in the transaction, or in other PEPPOL BIS v3. documents.

7.2. Code list for identifiers

All party identifiers (cac:PartyIdentification/cbc:ID) and party legal registration identifier (cac:PartyLegalEntity/cbc:CompanyID) has an optional scheme identifier attribute (@schemeID). If used, the value shall be chosen from the code list ICD list

Examples of usage in cac:PartyIdentification
<cac:PartyIdentification>
        <cbc:ID schemeID="0088">5790000435968</cbc:ID> (1)
</cac:PartyIdentification>
1 schemeID attribute is optional, but when used, the codes must be from ICD list

7.2.2. Electronic address identifier scheme identifier

All electronic address identifiers (cbc:EndpointID/@schemeID) use of a code list to be maintained by CEF.

Business Term Applicable XPath Code list (link or subset values)

Electronic address identifiers (Endpoint)

cbc:EndpointID/@schemeID

8. Semantic datatypes

Semantic data types are used to bridge the gap between the semantic concepts expressed by the information elements and the technical implementation. The semantic data types define the allowed value domain for the content, and any additional information components (attributes) needed in order to ensure its precise interpretation.

8.1. Primitive types

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

Primitive type Definition

Binary

A set of finite-length sequences of binary digits.

Date

Time point representing a calendar day on a time scale consisting of an origin and a succession of calendar ISO 8601:2004.

Decimal

A subset of the real numbers, which can be represented by decimal numerals.

String

A finite sequence of characters.

8.2. Semantic data types

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.

8.2.1. Amount

An amount states a numerical monetary value. The currency of the amount is defined as a separate business term.

Amount is floating up to two fraction digits.
Component Use Primitive Type Example

Content

Mandatory

Decimal

10000.25

8.2.2. Price Amount

A price amount states a numerical monetary amount value for data elements that contain item prices that may be multiplied by item quantities. The currency of the amount is defined as a separate business term.

Unit price amount does not set restrictions on number of decimals, as contrast to the Amount type
Component Use Primitive Type Example

Content

Mandatory

Decimal

10000.1234

8.2.3. Percentage

Percentages are given as fractions of a hundred (per cent) e.g. the value 34,78 % in percentage terms is given as 34,78.

No restriction on number of decimals for percentages.
Component Use Primitive Type Example

Content

Mandatory

Decimal

34.7812

8.2.4. Quantity

Quantities are used to state a number of units such as for items. The code for the Unit of Measure is defined as a separate business term.

No restriction on number of decimals for quantities.
Component Use Primitive Type Example

Content

Mandatory

Decimal

10000.1234

8.2.5. Code

Codes are used to specify allowed values in elements as well as for lists of options. Code is different from Identifier in that allowed values have standardized meanings that can be known by the recipient.

Codes shall be entered exactly as shown in the selected code list
Component Use Primitive Type Example

Content

Mandatory

String

Abc123

8.2.6. Identifier

Identifiers (IDs) are keys that are issued by the sender or recipient of a document or by a third party.

The use of the attributes is specified for each information element.
Component Use Primitive Type Example

Content

Mandatory

String

abc:123-DEF

Scheme identifier

Conditional

String

GLN

Scheme version identifier

Conditional

String

1.0

8.2.7. Date

Dates shall be in accordance to the “Calendar date complete representation” as specified by ISO 8601:2004, format YYYY-MM-DD.

Dates shall not include timezone information.
Table 4. EN 16931_ Date. Type
Component Use Primitive Type Example

Content

Mandatory

Date

2017-12-01

8.2.8. Time

Time shall be in accordance to the “Extended time format” as specified by ISO 8601:2004, format [hh]:[mm]:[ss]. The precision of decimal fraction is zero, i.e it shall not be used.

Time shall not include timezone information.
Table 5. EN 16931_ Date. Type
Component Use Primitive Type Example

Content

Mandatory

Date

09:30:12

8.2.9. Document Reference

Document Reference Types are identifiers that were assigned to a document or document line.

Table 6. Document Reference. Type
Component Use Primitive Type Example

Content

Mandatory

String

abc:123-DEF

8.2.10. Text

Text is the actual wording of anything written or printed. Line breaks in the text may be present, and any line breaks should be preserved and respected by the receiver’s system

Component Use Primitive Type Example

Content

Mandatory

String

5% allowance when paid within 30 days

8.2.11. Binary objects

Binary objects can be used to describe files which are transmitted together with the business document. Attachments shall be transmitted together with the business document. The binary object has two supplementary components: a Mime Code, which specifies the Mime type of the attachment and a Filename that is provided by (or on behalf of) the sender of the business document.

Component Use Primitive Type Example

Content

Mandatory

Binary

QmFzZTY0IGNvbnRlbnQgZXhhbXBsZQ==

Mime Code

Mandatory

String

image/jpeg

Filename

Mandatory

String

drawing5.jpg

8.2.12. Boolean

Boolean indicators are used to specify the two allowed values, true or false. All elements of datatype Boolean, must have either true or false as their value.

Component Use Primitive Type Example

Content

Mandatory

String

true

Appendix A: 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 shall contain corresponding ProfileID and CustomizationID.

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.

A.1. Customization and Profile identifiers

In the table below you will find the values to be used as the specification identifier and the business process type for this profile

Type Element cbc:CustomizationID Element cbc:ProfileID

Pre-award Catalogue request

urn:fdc:difi.no:2017:ehf:pacr:1.0

urn:fdc:difi.no:2017:ehf:profile:03:1.0

Pre-award Catalogue

urn:fdc:difi.no:2017:ehf:pac:1.0

Appendix B: UBL 2.2

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

These schemas are used when performing syntax validation.

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