PEPPOL T012 - Search Notice Response 1.2

The PEPPOL Business Interoperability Specification, “BIS” from here on after, has been developed by the OpenPEPPOL AISBL Pre Award Coordinating Community and is published as part of the PEPPOL specifications.

Statement of copyright

This PEPPOL Business Interoperability Specification (BIS) document is based on the CEN CWA prepared by the BII workshop specified in the introduction below. The original CEN CWA document contains the following copyright notice which still applies:

The CEN CWA documents and profiles prepared by the BII workshop are not specific to a business area. Subject to agreement with CEN, customizations have been made by PEPPOL to establish the PEPPOL BIS, detailing and adding further guidance on the use of BII profiles.

OpenPEPPOL AISBL holds the copyright in the customizations made to the original document. The customizations appear from the corresponding conformance statement which is attached to this document. For the purpose of national implementations, customizations covered by the conformance statement may be further refined and detailed by PEPPOL Authorities and/or other entities authorized by OpenPEPPOL AISBL, provided that interoperability with PEPPOL BIS is ensured. This PEPPOL BIS document may not be modified, re-distributed, sold or repackaged in any other way without the prior consent of CEN and/or OpenPEPPOL AISBL.

1. Principle and prerequisites

1.1. Scope

This guide aims to provide insight into transaction details for the transaction model T012 - Search Notice Response 1.2. The transaction description is meant to be a standalone description to be used as a part of one or more procurement profiles. It describes syntax mappings, requirements, rules and example.

The transactions, specified in this document are intended to be exchanged between the tendering systems of economic operators and contracting bodies. This means that it is expected that the parties have connected their systems to the internet, and that they have middleware in place to enable them to send and receive the transactions in a secure way, using an agreed syntax.

The content model of the transactions can also be used in procurement platforms or notification platforms, so that these platforms as well as procurement systems of economic operators and contracting bodies are based on the same information and process models, which makes them more interoperable. Even if platforms are not technically interoperable, the content model facilitates understanding the tendering documents and to participate in the tendering process.

1.2. Parties and roles

The following parties participate as business partners in this transaction, acting in the roles as defined below

Table 1. parties
Business Partner	Description
Governmental or private organization	Any organisation.

Table 2. roles
Role	Description
Requester	A service or economic operator in search of opportunities.
Provider	A data service that discloses information on notices (whether governmental or a private organisation).

Also other bodies than economic operators may need to search for notices, such as a statistics office or scholars. This profile particularly focuses on the tendering process, involving involving tendering platforms that are operated for economic operators. However, the search process and the transactions described in this profile may not necessarily be used by economic operators alone.

2. Transaction business and information requirements

The following tables describe the transaction business and information requirements of "T012 - Search Notice Response 1.2", it inherits from the profile BII Profile 45 - Search Notices (CWA 17026-104:2016) created by CEN WS/BII 3.

Table 3. Transaction business requirements of T012 - Search Notice Response 1.2
ID	Requirement
tbr100-001	The message shall contain the notice with the following information: Notice ID Notice type Publication date Publication URI/URL
tbr100-002-003	The message shall contain the notice with the following information about the business opportunity: Contracting body name Contracting body type Contracting body main activity Procurement project title Procurement project short description CPV code(s) NUTS code(s) Public Procurement Directive Reference number Procurement project type(s) (works, supplies and/or services) Indicator that the contract is restricted to sheltered workshops or employment programsNotice ID Keywords
tbr100-004	The message shall contain the notice with the following information about the procurement process: Procedure type Deadline to submit offer (type Open procedures) Deadline to request participation (type Restricted procedures) Address to access more information about procurement project Address to submit tenders or requests to participate Winner economic operator name (in case of contract award notice) Award criteria type(s)
tbr100-005	If one or more notices were found, the message envelope shall contain the full text of the notices in XML and their metadata. The business transactions and information requirements for XML notices apply as laid down eForms.
tbr100-006	The information about the requester and the identification of the search message shall be known.
tbr100-007	The number of results found shall be specified, even if the result is 0.
tbr100-008	The identification of the sender and the sending date may be included.
tbr100-009	General information about the message may be included.

3. Data model: Syntax mapping and XML example

3.1. Data model and syntax mapping

The data model and syntax mapping for Search Notice Response can be found at Syntax mapping for T012 - Search Notice Response 1.2. The data model and syntax mapping explains how to use the UBL (or an underlying syntax) to support the Search Notice Response information transaction requirements. It provides the syntax mappings from each UBL (or syntax) element to the Search Notice Response information elements of this transaction.

3.2. Data model diagram

The following transaction data model illustrates the classes and information elements of T012 - Search Notice Response 1.2.

3.3. XML example

The following XML example illustrates the structure of an instance of T012 - Search Notice Response 1.2.

Link to example file

Example file for T012 - Search Notice Response 1.2

<?xml version="1.0" encoding="UTF-8"?>
<query:QueryResponse
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:4.0"
        xmlns:query="urn:oasis:names:tc:ebxml-regrep:xsd:query:4.0"
        xmlns:xlink="http://www.w3.org/1999/xlink"
        totalResultCount="-1"
        requestId="48ac7379-731d-40be-bc48-599934182d45"
        startIndex="0"
        status=""
        xsi:schemaLocation="
        urn:oasis:names:tc:ebxml-regrep:xsd:rim:4.0
        http://docs.oasis-open.org/regrep/regrep-core/v4.0/csd01/xsd/rim.xsd
        urn:oasis:names:tc:ebxml-regrep:xsd:query:4.0
        http://docs.oasis-open.org/regrep/regrep-core/v4.0/csd01/xsd/query.xsd"
>
    <rim:Slot name="SpecificationIdentification"> (1)
        <rim:SlotValue xsi:type="rim:StringValueType">
            <rim:Value>
                urn:fdc:peppol.eu:prac:trns:t012:1.2
            </rim:Value> (2)
        </rim:SlotValue>
    </rim:Slot>
    <rim:Slot name="BusinessProcessTypeIdentifier"> (3)
        <rim:SlotValue xsi:type="rim:StringValueType">
            <rim:Value>urn:fdc:peppol.eu:prac:bis:p006:1.2</rim:Value> (4)
        </rim:SlotValue>
    </rim:Slot>
    <rim:Slot name="IssueDateTime"> (5)
        <rim:SlotValue xsi:type="rim:DateTimeValueType"> (6)
            <rim:Value>2020-02-14T19:20:30+01:00</rim:Value>
        </rim:SlotValue>
    </rim:Slot>
    <rim:Slot name="SenderElectronicAddress" type="EAS"> (7)
        <rim:SlotValue xsi:type="rim:StringValueType">
            <rim:Value>9930:DE122268496</rim:Value> (8)
        </rim:SlotValue>
    </rim:Slot>
    <rim:Slot name="ReceiverElectronicAddress" type="EAS"> (9)
        <rim:SlotValue xsi:type="rim:StringValueType">
            <rim:Value>9946:500820007</rim:Value> (10)
        </rim:SlotValue>
    </rim:Slot>
    <rim:RegistryObjectList> (11)
        <rim:RegistryObject
                lid="2C621D47-112D-42D4-B6F8-57392464C3E7"
                id="53EB9F20-EE12-474F-9424-78FC604E8FAE"
                xsi:type="rim:ExtrinsicObjectType"> (12)
            <rim:Slot name="BuyerInformation">
                <rim:Slot name="BuyerPartyIdentification" type="ICD">
                    <rim:SlotValue xsi:type="rim:StringValueType">  (13)
                        <rim:Value>0204:991-1234512345-06</rim:Value>
                    </rim:SlotValue>
                </rim:Slot>
                <rim:Slot name="BuyerElectronicAddress" type="EAS"> (14)
                    <rim:SlotValue xsi:type="rim:StringValueType">
                        <rim:Value>9930:DE122268496</rim:Value>
                    </rim:SlotValue>
                </rim:Slot>
            </rim:Slot>
            <rim:Slot name="ublDocumentSchema" type="ublDocumentSchema"> (15)
                <rim:SlotValue xsi:type="rim:StringValueType">
                    <rim:Value>CN</rim:Value>
                </rim:SlotValue>
            </rim:Slot>
            <rim:Slot name="eFormsVersion"> (16)
                <rim:SlotValue xsi:type="rim:StringValueType">
                    <rim:Value>eforms-sdk-1.2</rim:Value>
                </rim:SlotValue>
            </rim:Slot>
            <rim:RepositoryItemRef xlink:href="./53EB9F20-EE12-474F-9424-78FC604E8FAE.eform.xml"/> (17)
        </rim:RegistryObject>
    </rim:RegistryObjectList>
</query:QueryResponse>

4. Code lists

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

Information elements that are ruled by codelists in this transaction are also described in the Syntax mapping for Search Notice Response: Syntax mapping for T012 - Search Notice Response 1.2

The following code lists for coded elements and identifier schemes are used by the transaction.

4.1. Code list for elements

4.1.1. UBL Document Schema

The UBL Document Schema (rim:Slot name="ublDocumentSchema") has to have the non optional type attribute (type=ublDocumentSchema). It has to be chosen from the code list ublDocumentSchema

Example of usage of UBL Document Schema

<rim:Slot name="ublDocumentSchema" type="ublDocumentSchema"> (1)
    <rim:SlotValue xsi:type="rim:StringValueType">
        <rim:Value>CN</rim:Value>
    </rim:SlotValue>
</rim:Slot>

1	The code "CN" for status information has to be put into the value tag. The listID as the SlotType is always "ublDocumentSchema".

Identifier (type)	ublDocumentSchema
Document location	`rim:Slot name="ublDocumentSchema"`
Issuer	Peppol

Identifier (type)

ublDocumentSchema

Document location

rim:Slot name="ublDocumentSchema"

Issuer

Peppol

4.2. Code list for identifier schemes

4.2.1. Electronic Address Identifier scheme of Sender and Receiver

All electronic address identifiers are based upon the Electronic Address Scheme code list (EAS), maintained by CEF (CEF Code lists).

Electronic address identifiers have a non optional scheme identifier attribute (@type) which must be 'EAS'. Valid scheme values are found here: EAS codes.

Example of usage of Sender and Receiver Electronic Address Identifier Scheme values (here 9946) in rim:Value

<rim:Value>9946:500820007</rim:Value>

Table 4. Code list for identifier schemes used by Sender and Receiver
Business Term	Allowed Scheme	Document location
Sender Electronic Address Identifier	schemeID attribute is mandatory and must use values from EAS codes	`rim:Slot name="SenderElectronicAddress" @type`
Receiver Electronic Address Identifier	schemeID attribute is mandatory and must use values from EAS codes	`rim:Slot name="ReceiverElectronicAddress" @type`

4.2.2. Schemes for Buyer Party Identification and Buyer Electronic Address

Buyer Party Identification (rim:Slot name="BuyerPartyIdentification") has an non optional scheme identifier attribute (@type) which must be 'ICD'. The scheme value shall be chosen from the code list ICD codes.

Example of usage of ICD scheme value (here 0080) in Buyer Party Identification in rim:Value

<rim:Value>0088:7300010000001</rim:Value>

Buyer Electronic Address (rim:Slot name="BuyerElectronicAddress") has an non optional scheme identifier attribute (@type) which must be 'EAS'. The scheme value shall be chosen from the code list EAS codes.

Example of usage of EAS scheme value (here 9930) in Buyer Electronic Address in rim:Value

<rim:Value>9930:DE122268496</rim:Value>

Table 5. Code list for identifier schemes used by the Buyer
Business Term	Allowed Scheme	Document location
Buyer Electronic Address Identifier	schemeID attribute is mandatory and must use values from EAS codes	`rim:Slot name="BuyerElectronicAddress" @type`
Buyer Party Identification	schemeID attribute is mandatory and must use values from ICD codes	`rim:Slot name="BuyerPartyIdentfication" @type`

5. PEPPOL Identifiers

PEPPOL has defined a Policy for Using Identifiers that specifies how to use identifiers in both its transport infrastructure and within the documents exchanged across that infrastructure. It also introduces principles for any identifiers used in the PEPPOL environment. The e-Tendering pilot adopts and extends the PEPPOL Policy in the following ways:

5.1. Party Identifiers used in ebXML RegRep documents

The @type attribute must be populated in all instances of the ID element when used within a rim:Slot container for Sender Identification and Receiver Identification.

Example of usage in Sender Electronic Address Identifier and Receiver Electronic Address Identifier:

Example of usage of Sender Electronic Address Identifier in rim:Slot

<rim:Slot name="SenderElectronicAddress" type="EAS">
    <rim:SlotValue xsi:type="rim:StringValueType">
        <rim:Value>9930:DE122268496</rim:Value>
    </rim:SlotValue>
</rim:Slot>

Example of usage of Receiver Electronic Address Identifier in rim:Slot

<rim:Slot name="ReceiverElectronicAddress" type="EAS">
    <rim:SlotValue xsi:type="rim:StringValueType">
        <rim:Value>9946:500820007</rim:Value>
    </rim:SlotValue>
</rim:Slot>

Example of usage of the Buyer Electronic Address Identifier in rim:Slot

<rim:Slot name="BuyerElectronicAddress" type="EAS">
    <rim:SlotValue xsi:type="rim:StringValueType">
        <rim:Value>9946:500820007</rim:Value>
    </rim:SlotValue>
</rim:Slot>

Example of usage of Buyer Party Identification in rim:Slot

<rim:Slot name="BuyerPartyIdentification" type="ICD">
    <rim:SlotValue xsi:type="rim:StringValueType">
        <rim:Value>0204:991-1234512345-06</rim:Value>
    </rim:SlotValue>
</rim:Slot>

5.2. Document Identifiers used in ebXML RegRep documents

5.2.1. Profile ID

The PEPPOL Profile ID identifies what business process a given message is part of, and are connected to one business process, and may contain multiple document types. The Profile ID must be put in the element rim:Slot name="BusinessProcessTypeIdentifier"

Valid profile identifiers are described in the profile BIS documents. See Main documentation site. The following example illustrates the usage of Business Process Type Identifiers in OASIS ebXML RegRep Version 4.0 documents:

Example of usage of Business Process Type Identifiers in rim:Slot

<rim:Slot name="BusinessProcessTypeIdentifier">
    <rim:SlotValue xsi:type="rim:StringValueType">
        <rim:Value>urn:fdc:peppol.eu:prac:bis:p006:1.2</rim:Value>
        </rim:SlotValue>
</rim:Slot>

5.2.2. Customization ID

The PEPPOL Customization ID identifies the specification of content and rules that apply to the transaction. This transaction requires several changes to the CEN BII transaction. Following the CEN BII methodology any extension must be communicated by adding an extension ID onto the Customization ID. The Customization ID must be put in the element rim:Slot name="SpecificationIdentification"

The following example illustrates the usage of Specification Identification in OASIS ebXML RegRep Version 4.0 documents:

Example of usage of Specification Identification in rim:Slot

<rim:Slot name="SpecificationIdentification">
    <rim:SlotValue xsi:type="rim:StringValueType">
        <rim:Value>urn:fdc:peppol.eu:prac:trns:t012:1.2</rim:Value>
    </rim:SlotValue>
</rim:Slot>

Which customization identification should be used, is based on which transaction is sent, and the extension identification for BIS documents.

For implementers, please note that the process identifiers in the document instance MUST correspond to the SMP process identifier.

Table 6. Customization ID to be used for this transaction.
TransactionID	Transaction name	Short Description	`cbc:CustomizationID`
T012	Search Notice Response	The provider sends the search notice response to the requester.	urn:fdc:peppol.eu:prac:trns:t012:1.1

6. Description of selected parts of the transaction

The transaction including business terms, business rules and code lists are based upon the definitions of "Trdm100 Notices metadata transaction" described in BII Profile 45 - Search Notices (CWA 17026-104:2016).

6.1. Query Response: Parameter totalResultCount and startIndex

<query:QueryResponse
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:4.0"
        xmlns:query="urn:oasis:names:tc:ebxml-regrep:xsd:query:4.0"
        xmlns:xlink="http://www.w3.org/1999/xlink"
        totalResultCount="-1"
        requestId="48ac7379-731d-40be-bc48-599934182d45"
        startIndex="0"
        status=""
        xsi:schemaLocation="
        urn:oasis:names:tc:ebxml-regrep:xsd:rim:4.0
        http://docs.oasis-open.org/regrep/regrep-core/v4.0/csd01/xsd/rim.xsd
        urn:oasis:names:tc:ebxml-regrep:xsd:query:4.0
        http://docs.oasis-open.org/regrep/regrep-core/v4.0/csd01/xsd/query.xsd"
>

name	description
totalResultCount	This parameter specifies the size of the complete result set matching the query within the server. When this value is unspecified, the client should assume it is the size of the result set contained within the result. When this value is -1, the client should assume that the number of total results is unknown. In this case the client should keep iterating through the remaining result set for the query until no more results are returned.
startIndex	This integer value is used to indicate the index for the first result in the result set returned by the query, within the complete result set matching the query. By default, this value is 0.

name

description

totalResultCount

This parameter specifies the size of the complete result set matching the query within the server. When this value is unspecified, the client should assume it is the size of the result set contained within the result. When this value is -1, the client should assume that the number of total results is unknown. In this case the client should keep iterating through the remaining result set for the query until no more results are returned.

startIndex

This integer value is used to indicate the index for the first result in the result set returned by the query, within the complete result set matching the query. By default, this value is 0.

Figure 1. Example of a request with maxResults set to 100.

6.2. Specification Identification

<rim:Slot name="SpecificationIdentification"> (1)
    <rim:SlotValue xsi:type="rim:StringValueType">
        <rim:Value>
            urn:fdc:peppol.eu:prac:trns:t012:1.2
        </rim:Value> (2)
    </rim:SlotValue>
</rim:Slot>

1	Identifier for the set of rules and transactions for a search notice response.
2	The value for the specification identification is always "urn:fdc:peppol.eu:prac:trns:t012:1.0", just like in the given example.

6.3. Business Process Type Identifier

<rim:Slot name="BusinessProcessTypeIdentifier"> (1)
    <rim:SlotValue xsi:type="rim:StringValueType">
        <rim:Value>urn:fdc:peppol.eu:prac:bis:p006:1.2</rim:Value> (2)
    </rim:SlotValue>
</rim:Slot>

1	Identifier for the business process context of the search notice response.
2	The value for the business process type identifier is always "urn:fdc:peppol.eu:prac:bis:p006:1.0", just like in the given example.

6.4. Issue Date Time

<rim:Slot name="IssueDateTime"> (1)
    <rim:SlotValue xsi:type="rim:DateTimeValueType"> (2)
        <rim:Value>2020-02-14T19:20:30+01:00</rim:Value>
    </rim:SlotValue>
</rim:Slot>

1	Date and time when the request was being issued.
2	The SlotValue type has to be DateTimeValueType. Stick to the format "yyyy-mm-ddThh:mm:ss" and add the timezone in the end (i.e. Z or +01:00). Values for seconds, and the timezone must be given.

6.5. Sender electronic address

<rim:Slot name="SenderElectronicAddress" type="EAS"> (1)
    <rim:SlotValue xsi:type="rim:StringValueType">
        <rim:Value>9930:DE122268496</rim:Value> (2)
    </rim:SlotValue>
</rim:Slot>

1	The scheme of the endpoint id is clarified in the type attribute of the slot.
2	Fill the scheme id and electronic sender address into this slot.

6.6. Receiver electronic address

<rim:Slot name="ReceiverElectronicAddress" type="EAS"> (1)
    <rim:SlotValue xsi:type="rim:StringValueType">
        <rim:Value>9946:500820007</rim:Value> (2)
    </rim:SlotValue>
</rim:Slot>

1	The scheme of the endpoint id is clarified in the type attribute of the slot.
2	Fill the scheme id and electronic receiver address into this slot.

6.7. Registry Object List and Registry Objects (Notice Metadata)

<rim:RegistryObjectList> (1)
    <rim:RegistryObject
            lid="2C621D47-112D-42D4-B6F8-57392464C3E7"
            id="53EB9F20-EE12-474F-9424-78FC604E8FAE"
            xsi:type="rim:ExtrinsicObjectType"> (2)
        <rim:Slot name="BuyerInformation">
            <rim:Slot name="BuyerPartyIdentification" type="ICD">
                <rim:SlotValue xsi:type="rim:StringValueType">  (3)
                    <rim:Value>0204:991-1234512345-06</rim:Value>
                </rim:SlotValue>
            </rim:Slot>
            <rim:Slot name="BuyerElectronicAddress" type="EAS"> (4)
                <rim:SlotValue xsi:type="rim:StringValueType">
                    <rim:Value>9930:DE122268496</rim:Value>
                </rim:SlotValue>
            </rim:Slot>
        </rim:Slot>
        <rim:Slot name="ublDocumentSchema" type="ublDocumentSchema"> (5)
            <rim:SlotValue xsi:type="rim:StringValueType">
                <rim:Value>CN</rim:Value>
            </rim:SlotValue>
        </rim:Slot>
        <rim:Slot name="eFormsVersion"> (6)
            <rim:SlotValue xsi:type="rim:StringValueType">
                <rim:Value>eforms-sdk-1.2</rim:Value>
            </rim:SlotValue>
        </rim:Slot>
        <rim:RepositoryItemRef xlink:href="./53EB9F20-EE12-474F-9424-78FC604E8FAE.eform.xml"/> (7)
    </rim:RegistryObject>
</rim:RegistryObjectList>

1	The Registry object list contains the registry object, which contains the requested form.
2	Here you can find the uuids required to identify the Notice and its associated procurement procedures lid: The Procedure Identifier which allows distinguishing procurement procedures globally unique. It identifies the procurement procedure the notice belongs to. In PEPPOL the Procedure Identifier is also named "Reference Number" or "ContractFolderID". id: Specifies the Notice Identifier (BT-701) allowing to uniquely distinguishing the notice amongst all other existing ones contained within the query.
3	An identification for the buyer party according to ICD codes.
4	Electronic address according to EAS codes used by the buyer, just like the ones from the receiver or sender.
5	This is the UBL code of the type of document you searched for. Possible values can be taken from the list ublDocumentSchema, which has to be identified in the type-attribute of the slot.
6	Used eForms-Version according to specification in the format eforms-sdk-x.y
7	Reference to the eform.xml file which must be included to the ASiC-E Container (Associated Signature Container Extended) repository (see BIS eDocuments guide for pre-award).