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:

© 2012 CEN All rights of exploitation in any form and by any means reserved worldwide for CEN national Members.

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

Contracting Body

The State, regional or local authorities, bodies governed by public law, associations formed by one or several of such authorities or one or more such bodies governed by public law, contracting Economic Operators for supply of goods, services or works.

Economic Operator

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

Publication Body

A Pan-European, national or regional organisation that publishes procurement notices of a contracting body. While the basic role of the publisher may apply to any newspaper, other roles and functions are often restricted to official gazettes. These gazettes are also often responsible to ensure a formal verification of the notices in respect of legislative or other requirements in vigour. Official gazettes may also have the role to receive information exempted from publication (e.g. due to confidential content) used for notification to a supervising authority. I.e. eNotification also covers notification of authorities in the context of public procurement notices, e.g. for transparency and control reasons.
Table 2. Roles
Roles Description

Sender

The party sending a Tendering Message Response message back to the sending party of the business document.

Receiver

The party receiving the Tendering Message Response, and who is supposed to process it. This is the same party as the sender of the business document.

1.3. Tendering Message Response Principles

The Tendering Message Response (TMR) is intended to inform the issuer of the following situations:

  • The received message (or business document) contained fatal errors according to the relevant conformance and processing rules.

    • Result: The received message (or business document) will not be processed any further.

  • The received message (or business document) passed the validation of conformance and processing rules without any fatal errors but warnings.

    • Result: The received message (or business document) will be processed further. Eventual warnings are included to the Tendering Message Response.

  • The received message (or business document) passed the validation of conformance and processing rules without any errors.

    • Result: The received message (or business document) will be processed further.

  • The received message (or business document) has been correctly processed by the receiver even though it has not been validated for conformance. The receiver acknowledges that it has been received and identified as a valid business document.

    • Result: The received message (or business document) will be processed further.

1.4. Errors in scope for a negative/rejecting Message Level Response:

Syntax and business rule violation

  • XML schema validation error

  • Standard Compliance violations (e.g. empty elements not being allowed by UBL 2.1)

  • Validation error of type fatal error

  • Validation error of type warning. Warnings alone must NOT cause rejection of the business document (but they may be reported in addition to fatal errors)

  • Wrong version of business document (Will be handled like validation error of type fatal error)

Processing expections

  • Wrong values and references (after database look-up) (e.g. wrong receiver, reference to procedure not found, …​)

  • Wrong transaction flow (e.g. Tender Status Inquiry transaction is sent before the Subscribe to Procedure transaction)

  • Expired deadlines (e.g. The tender submission deadline has expired before the retrieval of a Tender.)

  • Missing authorizations and authentications (e.g. A Tender is submitted for an economic operator that is not subscribed for the procedure.)

  • Process terminations (e.g. A Search Notice Response sent in several replies is aborted by the recipient because searched information has already been found.)

1.5. Errors outside the scope of the message level response:

  • Unknown sender (in scope of transport acknowledgement)

  • Unknown receiver (in scope of transport acknowledgement)

  • Wrong version of envelope (in scope of transport acknowledgement)

  • XML schema validation error – envelope (in scope of transport acknowledgement)

  • XML not well formed (in scope of transport acknowledgement)

  • Non supported encoding (in scope of transport acknowledgement)

2. Transaction business and information requirements

The following tables describe the transaction business and information requirements of "T023 - Qualification Rejection", it inherits from the profile

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

created by CEN WS/BII 3.

2.1. Identification and description of the requirements

Table 3. Transaction business requirements of T023 - Qualification Rejection
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 CEN/BII 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.

3. Data model: Syntax mapping and XML example

3.1. Data model and syntax mapping

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

Appendix A: Data Model

Appendix B: Key examples/use cases

Link to example file

Example file for AP
<?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 languageID="en">limited turnover</cbc:Resolution> (16)
        <cbc:Resolution languageID="en">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>false</cbc:AdmissionCode>
        <cbc:Resolution>limited turnover</cbc:Resolution>
        <cbc:Resolution>criminal conviction - money laundering</cbc:Resolution>
        <cbc:ResolutionDate>2023-01-07</cbc:ResolutionDate>
        <cac:ProcurementProjectLot>
            <cbc:ID>765a9937-16d5-4513-92b4-cc9800925951::3</cbc:ID>
        </cac:ProcurementProjectLot>
    </cac:QualificationResolution>
</TendererQualificationResponse>

4. Code lists

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

4.1. Code list for elements

The following policies apply to the use of status codes:

  • Lists of Status codes are fixed and can not be changed bilaterally.

  • There are eleven pre-agreed status codes (elven reason status and three result status).

  • Status codes are sent from one party to the other to inform it about further processing of the request the other side.

  • Maximum time for first response 3 days – The Seller should receive the first Invoice Response within 3 working days.

4.1.1. Message Response Code

Qualifier (listID)

Message Response Code

Document location

cac:DocumentResponse/cac:Response/cbc:ResponseCode cac:DocumentResponse/cac:LineResponse/cac:Response/cbc:ResponseCode

Issuer

Peppol
The columns in the below table shall be understood as follows:
Message Response Code

The code that defines the status of the reference document, e.g. AP.
Name of the Message Response Code

The name of the code.
Usage of the Message Response Code

The usage of the code.
Example

Example of a use case for the code.
Possible Status Reason Code

Status Reason code which could be used to lead to the Message Response Code.
Due to legal framework conditions, there is a constraint to tolerate errors to a certain extent when receiving a tender, even if from a technical point of view, the message might have to be rejected. Especially tender rejections have to be kept to a minimum and must be based on valid reasons. These have to withstand judicial review.
Table 4. The Message Response Codes used in a Tendering Message Response message are defined in the table below.
Message Response Code Name of the Message Response Code Usage of the Message Response Code Example Possible Status Reason Code

RE

Rejected

Response code is used when the receiver will not process the referenced message any further. The reason for rejecting the message shall be stated in ´Status Reason´.

The received Tender has been rejected due to a fatal business rule violation (BV)

BV, SV, NF, DL, RF, WT, IR, MA, AE, PT

AP

Accepted

Response code is uses when the referenced message has been accepted by the receiver.

The received Tender has been accepted.

none

CA

Conditionally accepted

Response code is used when the receiver is accepting the message under conditions stated in ‘Status Reason’ and proceed to continue the process unless disputed by the sender.

The received Tender has only been conditionally accepted due to an expired tender submission deadline. The Contracting Authority is investigating the incident in a separate process.

BW, DL, IR

4.1.2. Status Reason Code

Qualifier (listID)

Status Reason Code

Document location

cac:DocumentResponse/cac:LineResponse/cac:Response/cac:Status/cbc:StatusReasonCode

Issuer

Peppol
The columns in the below table shall be understood as follows:
Status Reason Code

The code that defines the reason for the status of the reference document, e.g. BW.
Name of the Status Reason Code

The name of the code.
Usage of the Status Reason Code

The usage of the code.
Example

Example of a use case for the code.
Possible resulting Message Response Code

Message Response Codes which could be the results of the usage of the status reason code.
Table 5. The Status Reason Codes used in a Tendering Message Response message are defined in the table below.
Status Reason Code Name of the Status Reason Code Usage of the Status Reason Code Example Possible resulting Message Response Code

BV

Business rule violation, fatal

Error associated with a business rule that indicates a problem that leads to the rejection of the referenced message.

A Tenderings Questions transaction does not contain a question.

RE

BW

Business rule violation, warning

Warning related to a business rule that indicates a problem but that does not hinder further processing at this point in time.

A Tendering Answers transaction includes a cbc:CopyIndicator that is not required according to the specifications.

CA

SV

Syntax violation

Error associated with a syntax violation that indicates a problem that leads to the rejection of the referenced message.

The retrieved Tendering Questions transaction does not adhere to the UBL syntax for Enquiry.

RE

NF

Reference not found

Error caused by a document reference given in the received message that could not be found. Leads to the rejection of the received message.

The Tender or procedure to which Tender Withdrawal is referencing was not found.

RE

DL

Deadline expired

Error caused by a received message that was not submitted on time. Depending on the procedure availability and elapsed time period, the message may be rejected or conditionally accepted as a result.

The tender submission deadline has expired before the retrieval of a Tender.

RE/CA

RF

Request failed

Error caused by a received message that cannot be processed further for technical reasons. Leads to rejection of the received message.

An undefined technical error occurred so that a Call for Tender update could not be processed by the receiver.

RE

WT

Wrong transaction flow

Error caused to a received message that was not sent in the expected sequence of the business process. Leads to the rejection of the received message.

A Tender Status Inquiry transaction is sent before the Subscribe to Procedure transaction.

RE

IR

Invalid request

Error caused by a received message that cannot be processed further for semantic or business reasons. The message may be rejected or conditionally accepted as a result.

A Tender that was submitted contains false Contracting Authority information that cannot be processed by the receiver.

RE/CA

MA

Missing authorisation

Error caused by a received message that could not be processed further due to a missing authorization or approval for the procedure. Leads to the rejection of the received message.

A Subscribe to Procedure cannot be confirmed because the subscriber has not been approved for the restricted procedure.

RE

AE

Authentication exception

Error caused by a received message that could not be processed further due missing authentication or registration for the procedure. Leads to the rejection of the received message.

A Tender is submitted for an economic operator that is not subscribed for the procedure.

RE

PT

Process termination

A query response of a Search Notice Request is cancelled or terminated.

A Search Notice Response sent in several replies is aborted by the recipient because searched information has already been found.

RE

4.2. Code list for identifier schemes

Table 6. Code list for identifier schemes
Business Term Allowed Scheme Document location

Sender Electronic Address Identifier

schemeID attribute is mandatory and must use values from EAS codes

cac:SenderParty/cbc:EndpointID/@schemeID

Receiver Electronic Address Identifier

schemeID attribute is mandatory and must use values from EAS codes

cac:ReceiverParty/cbc:EndpointID/@schemeID

5. 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:

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

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

5.3. Document Identifiers used in business (UBL) documents

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

5.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 Rejection - Syntax mapping for T023 - Qualification Rejection - and the corresponding BIS document, see Main documentation site.

5.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 7. Customization ID to be used for this transaction.
TransactionID Transaction name Short Description cbc:CustomizationID

T023

Qualification Rejection

The publication body sends a notice publication response to the contracting authority.

urn:fdc:peppol.eu:prac:trns:t018:1.0

6. 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 Rejection transaction" described in:

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

6.1. Identifier

6.1.1. Qualification Rejection 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 rejection 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

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

6.3. Party identification

6.3.1. Sender Party

The party sending a Qualification Rejection Response message back 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.

6.3.2. Receiver Party

The party who is supposed to process the Qualification Rejection 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 Qualification, this Qualification Rejection 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.

6.4. ResolutionDocumentReference

The ResolutionDocumentReference contains a reference to the Qualification Document handed in by the Economic Operator (receiver party of this document) to qualify for the procurement.

Example of ResolutionDocumentReference
<cac:ResolutionDocumentReference>
    <cbc:ID schemeURI="urn:uuid">6bc5f7fe-cb0f-4640-bda6-f1ee7f02576a</cbc:ID> (1)
</cac:ResolutionDocumentReference>
1 The ResolutionDocumentReference must contain an identifier, being expressed in uuid syntax.

6.5. QualificationResolution

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

The QualificationResolution returned with this transaction will always be false. If more than one lot have been aimed to qualify for and need to be rejected, one QualificationResolution for each lot is expected.

Example of QualificationResolution
<cac:QualificationResolution>
    <cbc:AdmissionCode>false</cbc:AdmissionCode> (1)
    <cbc:Resolution languageID="en">limited turnover</cbc:Resolution> (2)
    <cbc:Resolution languageID="en">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 States that the Tenderer is not allowed to attend the further Procurement Process, only "false" is the allowed value here.
2 The decision leading to this Qualification Resolution can be explained in one or more Resolution elements. The resolution is expected be te described in plain text. At least one Resolution element should be provided.
3 The Date at which the decision expressed in this Qualification Resolution was made.
4 The ProcurementProjectLot referenced in this Qualification Resolution
5 The ProcurementProjectLot’s ID