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.
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:
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.
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.
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
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.
|
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. |
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. |
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.
The following diagram illustrates the parties and roles involved in the Pre-Award Catalogue and Catalogue Request.
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.
<cac:CommodityClassification>
<cbc:ItemClassificationCode listID="MP" listName="UNSPSC">14111511</cbc:ItemClassificationCode>
</cac:CommodityClassification>
<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).
<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:
<cac:ValidityPeriod>
<cbc:StartDate>2018-11-20</cbc:StartDate>
<cbc:EndDate>2018-12-30</cbc:EndDate>
</cac:ValidityPeriod>
<cac:LineValidityPeriod>
<cbc:StartDate>2018-11-20</cbc:StartDate>
<cbc:EndDate>2018-12-15</cbc:EndDate>
</cac:LineValidityPeriod>
<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. |
<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.
<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.
<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:
<cac:RequiredItemLocationQuantity>
<cac:Price>
<cbc:PriceAmount currencyID="NOK">3000.00</cbc:PriceAmount>
</cac:Price>
</cac:RequiredItemLocationQuantity>
<cac:ItemComparison>
<cbc:PriceAmount currencyID="NOK">270.00</cbc:PriceAmount>
<cbc:Quantity unitCode="EA">10</cbc:Quantity>
</cac:ItemComparison>
<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
<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 |
<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 |
<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.
<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. |
<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.
<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.
<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
.
<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>
<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
<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>
<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>
<cac:AdditionalItemProperty>
<cbc:Name>GeneticallyModified</cbc:Name>
<cbc:Value>True</cbc:Value>
</cac:AdditionalItemProperty>
6.2.2. Related Products and Accessories
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
<cac:RequiredRelatedItem>
<cbc:ID>987654</cbc:ID>
<cbc:Quantity unitCode="EA">1</cbc:Quantity>
</cac:RequiredRelatedItem>
<cac:ComponentRelatedItem>
<cbc:ID>89388789930</cbc:ID>
<cbc:Quantity unitCode="EA">12</cbc:Quantity>
</cac:ComponentRelatedItem>
<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:
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 |
<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.
<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) |
<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) |
<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).
<cac:HazardousItem>
<cbc:ID>0024</cbc:ID>
<cbc:UNDGCode>ADR</cbc:UNDGCode>
</cac:HazardousItem>
<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).
<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
7.2.1. Party identifiers and party legal registration identifier scheme
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
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 |
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. |
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. |
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.
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 |
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.