PEPPOL T023 - Qualification Response

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 T023 - Qualification Response. 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 examples.

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
Example of roles	Customer
The Customer is the legal person or organization who is in demand of a product or service.	Examples of customer roles are Buyer, Consignee, Debtor and contracting body.
Supplier	The Supplier is the legal person or organization who provides a product or service.

Table 2. Roles
Role	Description
Contracting body	The Contracting Authority or Contracting Entity who is buying supplies, services or tendering public works.
Economic operator	Party participating with a bid in a procurement process to sell goods, services or works.

2. Transaction business and information requirements

The following table describes the transaction business and information requirements of "T023 - Qualification Response", it inherits from BII46 Subscribe to Procedure and "Trdm087 Qualification Response transaction".

3. Identification and description of the requirements

Table 3. Transaction business requirements of T023 - Qualification Response
ID	Requirement
tbr87-001	The contracting body shall be identified.
tbr87-002	The economic operator shall be identified.
tbr87-003	The creation date and time of the message shall be specified.
tbr87-004	Each message shall have a message ID and may refer to the ID of the qualification.
tbr87-005	The Peppol profile and transaction names and versions shall be identified.
tbr87-006	The message shall contain the Procurement Reference number.
tbr87-007	The message may contain the Lot ID’s.
tbr87-008	The message may contain the reason for the rejection.

4. Data model: Syntax mapping and XML example

4.1. Data model and syntax mapping

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

4.2. Data model diagram

The following transaction data model illustrates the classes and information elements of T023 - Qualification Response.

4.3. XML example

The following XML example illustrates the structure of an instance of T023 - Qualification Response.

Link to example file

<?xml version="1.0" encoding="UTF-8"?>

<TendererQualificationResponse
        xmlns="urn:oasis:names:specification:ubl:schema:xsd:TendererQualificationResponse-2"
        xmlns:cac="urn:oasis:names:specification:ubl:schema:xsd:CommonAggregateComponents-2"
        xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2">
    <cbc:UBLVersionID>2.2</cbc:UBLVersionID>(1)
    <cbc:CustomizationID>urn:fdc:peppol.eu:prac:trns:t023:1.0</cbc:CustomizationID>(2)
    <cbc:ProfileID>urn:fdc:peppol.eu:prac:bis:p012:1.0</cbc:ProfileID>(3)
    <cbc:ID schemeURI="urn:uuid">123e4567-e89b-12d3-a456-426614174000</cbc:ID>(4)
    <!-- ReferenceNumber - Procurement project identifier-->
    <cbc:ContractFolderID>765a9937-16d5-4513-92b4-cc9800925951</cbc:ContractFolderID>(5)
    <cbc:IssueDate>2022-12-07</cbc:IssueDate>(6)
    <cbc:IssueTime>14:44:33+01:00</cbc:IssueTime>(7)
    <cac:SenderParty>
        <cbc:EndpointID schemeID="9930">DE122268496</cbc:EndpointID>(8)
        <cac:PartyIdentification>
            <cbc:ID schemeID="0088">7300010000001</cbc:ID>(9)
        </cac:PartyIdentification>
        <cac:PartyName>
            <cbc:Name>Beschaffungsamt des BMI</cbc:Name> (10)
        </cac:PartyName>
    </cac:SenderParty>
    <cac:ReceiverParty>
        <cbc:EndpointID schemeID="9946">500820007</cbc:EndpointID>(11)
        <cac:PartyIdentification>
            <cbc:ID schemeID="0088">7300010000001</cbc:ID>(12)
        </cac:PartyIdentification>
        <cac:PartyName>
            <cbc:Name>Dutch Tulips Ltd</cbc:Name> (13)
        </cac:PartyName>
    </cac:ReceiverParty>
    <cac:ResolutionDocumentReference>
        <cbc:ID schemeURI="urn:uuid">6bc5f7fe-cb0f-4640-bda6-f1ee7f02576a</cbc:ID> (14)
    </cac:ResolutionDocumentReference>
    <cac:QualificationResolution>
        <cbc:AdmissionCode>false</cbc:AdmissionCode> (15)
        <cbc:Resolution>limited turnover</cbc:Resolution> (16)
        <cbc:Resolution>criminal conviction - money laundering</cbc:Resolution>
        <cbc:ResolutionDate>2023-01-07</cbc:ResolutionDate> (17)
       <cac:ProcurementProjectLot>(18)
            <cbc:ID>765a9937-16d5-4513-92b4-cc9800925951::1</cbc:ID>(19)
        </cac:ProcurementProjectLot>
    </cac:QualificationResolution>
    <cac:QualificationResolution>
        <cbc:AdmissionCode>true</cbc:AdmissionCode>
        <cbc:ResolutionDate>2023-01-07</cbc:ResolutionDate>
        <cac:ProcurementProjectLot>
            <cbc:ID>765a9937-16d5-4513-92b4-cc9800925951::3</cbc:ID>
        </cac:ProcurementProjectLot>
    </cac:QualificationResolution>
</TendererQualificationResponse>

5. Code lists

The following code lists for coded elements and identifier schemes are used in this transaction.

5.1. Code list for elements

5.1.1. AdmissionCode

Qualifier	cbc:AdmissionCode
Document location	cac:QualificationResolution/cbc:AdmissionCode

Qualifier

cbc:AdmissionCode

Document location

cac:QualificationResolution/cbc:AdmissionCode

5.2. Code list for identifier schemes

Table 4. Code list for identifier schemes
Business Term	Allowed Scheme	Applicable Xpath:
Economic operator electronic address identifier	schemeID attribute is mandatory and must use values from EAS codes	cac:ReceiverParty/cbc:EndpointID/@schemeID
Contracting body electronic address identifier	schemeID attribute is mandatory and must use values from EAS codes	cac:SenderParty/cbc:EndpointID/@schemeID
Economic operator identifier	schemeID attribute is mandatory and must use values from ICD codes	cac:ReceiverParty/cac:PartyIdentification/cbc:ID/@schemeID
Contracting body identifier	schemeID attribute is mandatory and must use values from ICD codes	cac:SenderParty/cac:PartyIdentification/cbc:ID/@schemeID

6. PEPPOL Identifiers

PEPPOL has defined a Policy for use of 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:

6.1. Party Identifiers used in business (UBL) documents

All party identifiers (cac:PartyIdentification/cbc:ID) have an optional scheme identifier attribute '@schemeID'. If used, the value shall be chosen from the code list ICD codes.

Examples of usage in cac:PartyIdentification

<cac:PartyIdentification>
        <cbc:ID schemeID="0088">5790000435968</cbc:ID> (1)
</cac:PartyIdentification>

1	schemeID attribute is optional, but when used, the codes must be from ICD codes

6.2. Electronic address identifier used in business (UBL) documents

All electronic address identifiers (cbc:EndpointID/@schemeID) use the Electronic Address Scheme code list (EAS), maintained by CEF (CEF Code lists).

Valid values are found here: EAS codes.

Examples of usage in cbc:EndpointID

<cbc:EndpointID schemeID="0184">DK87654321</cbc:EndpointID> (1)

1	schemeID attribute is mandatory and must use values from EAS codes

6.3. Document Identifiers used in business (UBL) documents

6.3.1. UBL Version ID

This transaction model is using the UBL 2.2 syntax. The namespace of the XML-message does only communicate the major version number. Since it is important for the receiver to also know what minor version of the syntax that is used, the element UBLVersionID must be stated with the value 2.2:

Examples of usage in PartyIdentification and EndpointID

<cbc:UBLVersionID>2.2</cbc:UBLVersionID>

6.3.2. Profile ID

ProfileID identifies what business process a given message is part of, and are connected to one business process, and may contain multiple document types.

Valid profile identifiers are described in the Syntax mapping for Qualification Response - Syntax mapping for T023 - Qualification Response - and the corresponding BIS document, see Main documentation site.

6.3.3. Customization ID

The PEPPOL Customization ID identifies the specification of content and rules that apply to the transaction. Profiles are connected to one business process (ProfileID), and may contain multiple transactions. Valid document instances shall contain corresponding ProfileID and CustomizationID.

CustomizationID is a string without spaces. Which customization identification should be used, is based on which transaction is sent.

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

Table 5. Customization ID to be used for this transaction.
TransactionID	Transaction name	Short Description	`cbc:CustomizationID`
T023	Qualification Response	The contracting body sends the Qualification Response to the economic operator that has tendered.	urn:fdc:peppol.eu:prac:trns:t023:1.0

7. Description of selected parts of the transaction

The transaction including business terms, business rules and code lists are based upon the definitions of "Trdm087 Qualification Response transaction" described in:

"Profile BII51 Qualification Rejection" (CWA 17027-116:2016).

7.1. Identifier

7.1.1. Qualification Response Identifier

The identifier enables positive referencing the transaction instance for various purposes including referencing between transactions that are part of the same process. Must be expressed as a UUID.

Example of qualification response document identifier

<cbc:ID schemeURI="urn:uuid">123e4567-e89b-12d3-a456-426614174000</cbc:ID>(1)

1	A transaction instance must contain an identifier, being expressed in uuid syntax

7.2. Response issue date and time

Response issue date/time must be sent.

Response issue date is a xsi:date data type and is specified as "YYYY-MM-DD" where:

YYYY - four digits year
MM - two digits month (01 to 12)
DD - two digits day (0)

Response issue time is a xsi:time data type and is specified as "hh:mm:ss" where:

hh - two digits of hour (00 to 23) (am/pm NOT allowed).
mm - two digits of minute (00 to 59)
ss - two digits of second (00 to 59)
TZD - time zone designator (Z or +hh:mm or -hh:mm)

The response issue date and time refer to the date when of the issuance of the response.

The response issue time must specify the time zone.

Example of response issue date and time

<cbc:IssueDate>2022-12-07</cbc:IssueDate>(1)
<cbc:IssueTime>14:44:33+01:00</cbc:IssueTime>(2)

1	Format for the date has to be yyyy-mm-dd
2	Format for the time has to be hh:mm:ssTZD, granularity down to seconds and timezone

7.3. Party identification

7.3.1. Sender Party

The party sending a Qualification Response to the party that initiated the request to qualify for a Procurement. The sender party in this case corresponds to the contracting body.

Example of sender party

<cac:SenderParty>
    <cbc:EndpointID schemeID="9930">DE122268496</cbc:EndpointID>(1)
    <cac:PartyIdentification>
        <cbc:ID schemeID="0088">7300010000001</cbc:ID>(2)
    </cac:PartyIdentification>
    <cac:PartyName>
        <cbc:Name>Beschaffungsamt des BMI</cbc:Name> (3)
    </cac:PartyName>
</cac:SenderParty>

1	Identifies the sender party’s electronic address and the scheme identifier for the electronic address
2	Identifies the sender party itself and the scheme identifier to resolve sender party’s identifier
3	Contains the sender party’s official name.

7.3.2. Receiver Party

The party who is supposed to receive the Qualification Response. This is the same party that initiated the request to qualify for a Procurement. The receiver party in this case corresponds to the Economic Operator who handed in the Qualification to which this Qualification Response refers to.

Example of receiver party

<cac:ReceiverParty>
    <cbc:EndpointID schemeID="9946">500820007</cbc:EndpointID>(1)
    <cac:PartyIdentification>
        <cbc:ID schemeID="0088">7300010000001</cbc:ID>(2)
    </cac:PartyIdentification>
    <cac:PartyName>
        <cbc:Name>Dutch Tulips Ltd</cbc:Name> (3)
    </cac:PartyName>
</cac:ReceiverParty>

1	Identifies the receiver party’s electronic address and the scheme identifier for the electronic address
2	Identifies the receiver party and the scheme identifier to resolve the receiver party’s identifier
3	Contains the receiver party’s official name including the organization’s legal form.

7.4. Response Document Reference

The Response Document Reference contains a reference to the original Qualification Document that had been handed in by the Economic Operator (receiver party of this document) to qualify for the procurement.

Example of Response Document Reference

<cac:ResolutionDocumentReference>
    <cbc:ID schemeURI="urn:uuid">6bc5f7fe-cb0f-4640-bda6-f1ee7f02576a</cbc:ID> (1)
</cac:ResolutionDocumentReference>

1	The Response Document Reference must contain an identifier, being expressed in uuid syntax.

7.5. Qualification Response Resolution

The Qualification Response Resolution is the central part of any Qualification Response. It contains all information required to inform about the Qualification Rejection.

The Qualification Response Resolution returned with this transaction may be positive or negative. It is expected to respond every rejection but it is also possible to respond any acceptance. If more than one lot have been aimed to qualify for and need to be responded, one Qualification Response Resolution for each lot is expected.

Example of Qualification Response Resolution

<cac:QualificationResolution>
    <cbc:AdmissionCode>false</cbc:AdmissionCode> (1)
    <cbc:Resolution>limited turnover</cbc:Resolution> (2)
    <cbc:Resolution>criminal conviction - money laundering</cbc:Resolution>
    <cbc:ResolutionDate>2023-01-07</cbc:ResolutionDate> (3)
   <cac:ProcurementProjectLot>(4)
        <cbc:ID>765a9937-16d5-4513-92b4-cc9800925951::1</cbc:ID>(5)
    </cac:ProcurementProjectLot>
</cac:QualificationResolution>

1	Gives the qualification result. If the result ist false, it states that the Tenderer is not allowed to attend the further Procurement Process and the (generally neutral) qualification response can alo be seen as qualification rejection. Any qualification rejection is required to be answered. A positive answer resulting in true may also be given, but is not necessarily requested.
2	If the decision leading to a Qualification Rejection, the Reason for Rejection can be explained in one or more resolution elements. The Qualification Rejection Resolution is expected be te described in plain text. At least one Reason for Rejection element should be provided. A positive answer may be sent without a specific resolution element.
3	The Date at which the decision expressed in this Qualification Rejection Resolution was made.
4	The ProcurementProjectLot referenced in this Qualification Response
5	The ProcurementProjectLot’s ID