EHF Document Folder

This document describes EHF Document Folder ("EHF Dokumentmappe" in Norwegian) and EHF Document Folder Reception Confirmation ("EHF Dokumentmappe Kvitteringsmelding" in Norwegian). The document is part of Norwegian Agency for Public and Financial Management (DFØ) standardization work related to electronic commerce.

1. Introduction

The Dynamic purchasing system (DPS) is an electronic procurement procedure (system) that can be established by, for example, a Central Purchasing body to purchase works, goods and services from Contracting Authorities. DPS is full electronic process, and compared to other framework agreements in DPS new suppliers can join at any time.

A sub-process of the whole DPS-process is called EHF Document folder, where the main idea is that Central Purchasing body can send a document folder with several tender documents to the Contracting Authorities connected to Central Purchasing body.

The purpose of this document is to describe EHF Document Folder process with a process diagram and use cases, then describe roles and parties together with role diagram, and finally give detailed description of important parts of EHF Supplier list. Appendices with supporting information is provided at the end of the document.

2. Background

The Dynamic Purchasing System (DPS) is a full electronic procurement procedure for procurement of goods, works and services, where a new supplier can join at any time.

DPS is a two stage process:

Step 1: Initial setup- all suppliers who meet the selection criteria will be admitted to the DPS, and
Step 2: Individual contracts are awarded.

3. Process and Typical Use Cases

3.1. Process Diagram

The following diagram illustrates the EHF Document Folder and EHF Document Folder Reception Confirmation processes.

Figure 1. EHF Document Folder and EHF Document Folder Reception Confirmation process.

The main idea of document folder, the Central Purchasing Body sends a EHF Document folder with structured and non-structured documents to all qualified suppliers in the DPS. Contracting Authorities receives the Document folder with procurement documents, and sends a confirmation to the Central Purchasing Body. The Central Purchasing Body receives and stores the confirmation.

In general, the Central Purchasing body sends EHF Document Folder to Contracting Authorities when:

creating DPS, or
updating tender documents inside the EHF Document Folder.

The Central Purchasing Body can also send EHF Document Folder to new suppliers that qualifies to DPS.

3.2. Use Cases

3.2.1. Use Case 1

Description

This use case illustrates the use of document folders in DPS between Central Purchasing Body and the Contracting Authrities connected to Central Purcahsing Body.

Parties involved

Contracting Authority
Central Purchasing body

Assumptions

Central Purchasing Boy has created an DPS for hotel services.

Flow

Central Purchasing system sends a document folder with a catalogue template to the Contracting Authorities.
The Contracting Authorities receives a Document Folder with a catalogue template, and saves the tender document in the tender system.
The Contracting Authorities Tender system sends a confirmation to the Central Purchasing system.
The Central Purchasing system receives the message and store the information.

Result

The Contracting Authorities receives a document folder with a catalogue template from the Central Purchasing system.
The Central Purchasing body sends EHF Document Folder to Contracting Authorities when:
1. creating DPS,
2. updating tender documents inside the EHF Document Folder.
The Central Purchasing Body can also send EHF Document Folder to new suppliers that qualifies to DPS.

4. Detailed Descriptions

This chapter describes selected parts of the information contents of the EHF Document Folder and EHF Document folder reception confirmation.

4.1. Parties and Roles

The important parties and roles in EHF Document Folder and EHF Document Folder Reception Confirmation is described below.

Contracting authority (CA): The contracting authority or contracting entity who is buying supplies, services or tendering works.
Central Purchasing body: Central Purchasing body is a contracting authority which provides centralised procurement of works, goods and services.

The following diagram illustrates the parties and roles involved in document folder transaction.

Figure 2. EHF Supplier list rolediagram.

4.2. Sending Tendering Documents

Central purchasing body can send structured or non-structured tender documents by using EHF Document Folder which is based on OASIS Exchange Header Envelope 1.0 CS02.

4.2.1. Exchange Header Envelope (XHE)

The Exchange header envelope (XHE) describes either a header to or an envelope of a set of payloads that contains information about the content. In EHF Document Folder, the main idea with using XHE is to pack all structured and non-structured tender documents in payloads. For example, the central purchasing body can send catalogue templates (a pdf file) to the contracting authorities in a DPS.

Read more about Exchange Header Envelope here.

To send a EHF Document Folder following metadata information about the Exchange Header Envelope (XHE) need to be provided (see Figure (3)):

XHE version identifier,
Specification identifier (CustomizationID),
Business process type identifier (ProfileID),
General header information, and
Payload information.

Figure 3. Illustration of Exchange Header Envelope.

Example of how to implement the general (head) information in XHE.

<XHE xmlns="oasis-cefact-xhe-1.0-ExchangeHeaderEnvelope"
     xmlns:xhb="oasis-cefact-xhe-1.0-BasicComponents"
     xmlns:xha="oasis-cefact-xhe-1.0-AggregateComponents"
     xmlns:ext="oasis-cefact-xhe-1.0-ExtensionComponents">

    <xhb:XHEVersionID>1.0</xhb:XHEVersionID> (1)
    <xhb:CustomizationID>...</xhb:CustomizationID> (2)
    <xhb:ProfileID>...</xhb:ProfileID> (3)

    <xha:Header> (4)
        <!-- Header Information -->
    </xha:Header>

    <xha:Payloads>  (5)
        <xha:Payload>
            <!-- Payload Information -->
        </xha:Payload>
    </xha:Payloads>

1	XHE version number
2	XHE specification identifier (`CustomizationID`)
3	XHE business process type identifier (`ProfileID`)
4	Header information
5	Payloads - information about each relevant payload

Header Information

Information relevant to the header envelope need to be provided in element xha:Header, and will be used to handle the envelope. The header envelope contains information about the business scope, where contracting authority can specify the criterion of the scope of business. There is also important to state the senders and receivers organization number.

Example of how to implement the header-information in XHE.

<xha:Header>
    <xhb:ID>158</xhb:ID> (1)
    <xhb:UUID>356a67cf-1fac-4c30-94b0-a29fee1a015b</xhb:UUID> (2)
    <xhb:CreationDateTime>2019-10-09T10:00:00Z</xhb:CreationDateTime> (3)
    <xha:BusinessScope> (4)
        <xha:BusinessScopeCriterion>
            <xhb:BusinessScopeCriterionTypeCode>DPS</xhb:BusinessScopeCriterionTypeCode>(5)
            <xhb:BusinessScopeCriterionValue>Developing DPS pilot.</xhb:BusinessScopeCriterionValue> (6)
        </xha:BusinessScopeCriterion>
    </xha:BusinessScope>

    <xha:FromParty>
        <xha:PartyIdentification>
            <xhb:ID schemeID="0192">987654325</xhb:ID> (7)
        </xha:PartyIdentification>
    </xha:FromParty>

    <xha:ToParty>
        <xha:PartyIdentification>
            <xhb:ID schemeID="0192">123456785</xhb:ID> (8)
        </xha:PartyIdentification>
    </xha:ToParty>
</xha:Header>

1	Identifier
2	Unique universal identifier (UUID), recommend version 4.
3	Date and time for when this header envelope was created.
4	Business scope
5	The property of the business scope
6	The value of the property
7	Senders organization number
8	Receivers organization number

Payload Information

Information about the set of payloads within the envelope need to be provided in element xha:Payloads, and information about the specific payload need to be provided in element xha:Payload. For example, the payload instance can be catalogue template, or other tender documents.

Example of how to implement the payloads in XHE.

  <xha:Payloads>
    <xha:Payload>(1)
      <xhb:ID>1</xhb:ID> (2)
      <xhb:Description>Catalogue templates</xhb:Description> (3)
      <xhb:DocumentTypeCode>9</xhb:DocumentTypeCode> (4)
      <xhb:ContentTypeCode>application/pdf</ContentTypeCode> (5)
      <xhb:InstanceEncryptionIndicator>False</xhb:InstanceEncryptionIndicator> (6)
      <xha:PayloadContent filename="catalogue-templates.pdf">Q2F0YWxvZ3VlIHRlbXBsYXRlcyBuZWVkIHRvIGJlIHVzZWQgaW4gRFBTIDEyMjM0IGNvbXBldGl0aW9u</xha:PayloadContent> (7)
  </xha:Payload>
</xha:Payloads>

1	Information about the specific payload instance
2	Identification of the specific payload instance
3	Description of the specific payload instance
4	Type of document expressed as a code from UNCL1001 code list
5	The Payload instance’s file format. Use Mime code code list.
6	Payload instance is not encrypted- always use `False`.
7	The Payload instance embedded as binary object with `filename`. Use Base64.

4.3. Response

In EHF Document Folder Reception Confirmation the Contracting Authority need to send a response message to the Central Purchasing Body, by using element cac:DocumentResponse. The response message confirms that the receiver of EHF Document Folder has received the Document folder, and refers to the specific EHF Document Folder.

Example of how to send a response in EHF Document Folder Reception Confirmation

<cac:DocumentResponse>
    <cac:Response>
        <cbc:ResponseCode>RECEIVED</cbc:ResponseCode>(1)
    </cac:Response>
    <cac:DocumentReference>
        <cbc:ID>845</cbc:ID>(2)
    </cac:DocumentReference>
</cac:DocumentResponse>

1	Response code- always `RECEIVED`
2	Identifier referenced to EHF Document Folder

Appendix A: 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.

A.1. Primitive types

Semantic data type content may be of the following primitive types. These primitive types were taken from ISO15000, 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 ISO8601.
Decimal	A subset of the real numbers, which can be represented by decimal numerals.
String	A finite sequence of characters.

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

Decimal

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

String

A finite sequence of characters.

A.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 ISO15000.

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.

A.2.1. 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

Component

Use

Primitive Type

Example

Content

Mandatory

String

Abc123

A.2.2. 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

A.2.3. Date

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

Dates shall not include timezone information.

Table 1. EN 16931_ Date. Type
Component	Use	Primitive Type	Example
Content	Mandatory	Date	2017-12-01

A.2.4. Time

Time shall be in accordance to the “Extended time format” as specified by ISO8601, 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 2. EN 16931_ Date. Type
Component	Use	Primitive Type	Example
Content	Mandatory	Date	09:30:12

A.2.5. Document Reference

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

Table 3. Document Reference. Type
Component	Use	Primitive Type	Example
Content	Mandatory	String	abc:123-DEF

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

Component

Use

Primitive Type

Example

Content

Mandatory

String

5% allowance when paid within 30 days

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

Component

Use

Primitive Type

Example

Content

Mandatory

Binary

QmFzZTY0IGNvbnRlbnQgZXhhbXBsZQ==

Mime Code

Mandatory

String

image/jpeg

Filename

Mandatory

String

drawing5.jpg

A.2.8. 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

Component

Use

Primitive Type

Example

Content

Mandatory

String

true

Appendix B: 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.

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

Type	Element `cbc:CustomizationID`	Element `cbc:ProfileID`
EHF Document Folder	…	…
EHF Document Folder Reception Confirmation	…	…

EHF Document Folder

…

EHF Document Folder Reception Confirmation

…

Appendix C: UBL 2.2

This implementation guide builds on UBL 2.2 Schemas, available from OASIS.

These schemas are used when performing syntax validation.

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