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 T018 - Tendering Message Response 1.1. 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 "T018 - Tendering Message Response 1.1", it inherits from the profile

  • BII Architecture 107 - Message Level Response guideline (CWA 17025-107:2016)

created by CEN WS/BII 3.

Table 3. Transaction business requirements of T018 - Tendering Message Response 1.1
ID Requirement

tbr71-001

It must be possible to give the response message a unique identifier. The identifier is issued by the sender and can be used to uniquely identify a message instance.

tbr71-002

It must be possible to state the date and time when the response message is issued. The date should always be given but the time (hours, minutes and seconds) should be optional to use.

tbr71-003

It must be possible to state a free text note. Used to inform the receiver about information that is not explicitly given in any dedicated structure. The information is meant to be manually read/assessed by the receiver.

tbr71-004

It must be possible to specify the Party sending the response.

tbr71-005

It must be possible to specify the Party receiving the response.

tbr71-006

It must be possible to specify the Response to at previously received message referring to the document including the document type and document identifier and version.

tbr71-007

It must be possible to give the response as a code. A response code list is required in order to facilitate automated process of message responses.

tbr71-008

It must be possible to give an optional description possibly in several languages.

tbr71-009

It must be possible to give response for one or more lines in the previously received document. This includes response code and response description.

tbr71-010

A response document must be able to clearly indicate whether the received document was accepted or not.

tbr71-011

It must be possible to sign the response document in order to provide for non-repudiation.

tbr71-012

It must be possible to specify the type of acceptation and/or rejection of the document. The allowed types are "accepted", "conditionally accepted" and "rejected".

tbr71-013

The message should allow the identification of more than one error.

tbr71-014

The message should allow for XPath statements to indicate the location of the errors in the received instance.

3. Data model: Syntax mapping and XML example

3.1. Data model and syntax mapping

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

3.2. Data model diagram

The following transaction data model illustrates the classes and information elements of T018 - Tendering Message Response 1.1.

TenderingMessageResponse

3.3. XML example

The following XML example illustrates the structure of an instance of T018 - Tendering Message Response 1.1.

Link to AP example file

Example file for AP
<?xml version="1.0" encoding="UTF-8"?>

<ApplicationResponse xmlns="urn:oasis:names:specification:ubl:schema:xsd:ApplicationResponse-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>
    <cbc:CustomizationID>urn:fdc:peppol.eu:prac:trns:t018:1.1</cbc:CustomizationID>
    <cbc:ProfileID>urn:fdc:peppol.eu:prac:bis:p010:1.1</cbc:ProfileID>
    <cbc:ID>123e4567-e89b-12d3-a456-426614174000</cbc:ID>
    <cbc:IssueDate>2021-07-18</cbc:IssueDate>
    <cbc:IssueTime>14:44:33+01:00</cbc:IssueTime>
    <cac:SenderParty>
        <cbc:EndpointID schemeID="9930">DE122268496</cbc:EndpointID>
    </cac:SenderParty>
    <cac:ReceiverParty>
        <cbc:EndpointID schemeID="9946">500820007</cbc:EndpointID>
    </cac:ReceiverParty>
    <cac:DocumentResponse>
        <cac:Response>
            <cbc:ResponseCode>AP</cbc:ResponseCode>
            <cbc:Description>Accepted</cbc:Description>
        </cac:Response>
        <cac:DocumentReference>
            <cbc:ID>4e3517fd-724d-44fc-b90b-5743c33ff68e</cbc:ID>
            <cbc:DocumentTypeCode>urn:fdc:peppol.eu:prac:trns:t013:1.1</cbc:DocumentTypeCode>
        </cac:DocumentReference>
    </cac:DocumentResponse>
</ApplicationResponse>

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 Tendering Message Response: Syntax mapping for T018 - Tendering Message Response 1.1

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

4.1. Code list for elements

The following policies apply to the use of codes for returning the processing status of a transaction via Message Response Codes and Status Reason Codes:

  • There are three Message Response Codes which define the final processing result.

  • There are eleven pre-defined Status Reason Codes which define the reason why a received and reference document could not be processed correctly.

  • Lists of Message Response Codes and Status Reason Codes are fixed and can not be changed bilaterally.

  • Message Response Codes and Status Reason Codes are returned from the receiver of a document to the sender of a document to inform the sender of the document about the final processing results and reasons in case of failure or processing problems.

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 final processing result of the referenced and received document, e.g. AP for Accepted.
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 why a received and reference document could not be processed correctly e.g. BW for Business rule violation, warning.
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 Tendering Message Response - Syntax mapping for T018 - Tendering Message Response 1.1 - 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

T018

Tendering Message Response

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

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

6. Description of selected parts of the transaction

The transaction including business terms, business rules and code lists are derived from the definitions of the Message Level Response described in:

BII Architecture 107 - Message Level Response guideline (CWA 17025-107:2016).

6.1. Identifier

6.1.1. UBL Version Identifier

Requires UBL version 2.2.

Example of UBL Version Identifier
<cbc:UBLVersionID>2.2</cbc:UBLVersionID> (1)
1 Has to be 2.2, to correspondent to the used UBL version

6.1.2. 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 response identifier
<cbc:ID>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 digit year

  • MM - two digit month (01 to 12)

  • DD - two digit 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>2021-07-18</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 an Notice Publication Response message back to the sending party that initiated the request to publish a notice.

Example of sender party
<cac:SenderParty>
    <cbc:EndpointID schemeID="9930">DE122268496</cbc:EndpointID> (1)
</cac:SenderParty>
1 Identifies the senders party’s electronic address and the scheme identifier for the electronic address

6.3.2. Receiver Party

The party who is supposed to process the Notice Publication Response. This is the same party that initiated the request to publish a notice.

Example of receiver party
<cac:ReceiverParty>
    <cbc:EndpointID schemeID="9946">500820007</cbc:EndpointID> (1)
</cac:ReceiverParty>
1 Identifies the receivers party’s electronic address and the scheme identifier for the electronic address

6.4. Document response

The notice response is used to indicate the result of business document validation. The element 'cac:DocumentResponse/cac:Response/cbc:ResponseCode' MUST contain the overall result code.

6.4.1. Response

A "rejection" (RE) states that the notice was not processed because of identified issues. "Conditionally accepted" (CA) indicates that the publication of the notice is done with warnings indicated in the message. "Accepted" (AP) indicates that the notice will be published at a certain time.

Example of response
<cac:Response>
    <cbc:ResponseCode>RE</cbc:ResponseCode> (1)
    <cbc:Description>Rejected</cbc:Description> (2)
</cac:Response>
1 A code stating whether the referenced message was cleared through validation and advanced to the next step in the process. Refer to codelist notice response.
2 Used to make any comments or instructions relevant to the response. The use of this element requires manual assessment by the receiver.

6.4.2. Document reference

The document reference is used to provide references to notice request transaction and the notice payload. Thus, the transaction uses two levels of validation. The first one is the notice transaction itself, referenced with the cbc:ID tag. The second level is the notice which is included as payload and referenced with the cbc:UUID.

Example of document reference
<cac:DocumentReference>
    <cbc:ID>4e3517fd-724d-44fc-b90b-5743c33ff68e</cbc:ID> (1)
    <cbc:DocumentTypeCode>urn:fdc:peppol.eu:prac:trns:t013:1.1</cbc:DocumentTypeCode> (2)
</cac:DocumentReference>
1 Specifies the unique identifier of the container that describes the request to publish a notice on which the Notice Publication Response is based, expressed in uuid syntax.
2 An identification of the version of the underlying message.

6.4.3. Line response

A response to a particular line in the notice transaction or notice payload. If the document response is negative (code='RE'), the line response element is used to specify the errors in the notice.

The line response contains the line reference and the line response information

Line reference

Identifies the line in the notice transaction or notice payload to which the reported issue applies.

The LineID element must be used to indicate where in the notice the error occurred by using XPath to reference the element causing the error. To cater for scenarios where it is not possible to provide XPath, a dummy value must be applied. The dummy value must consist of the characters NA. This is due to that the LineID element is mandatory in the ApplicationResponse message in UBL 2.1 on which the notice response transaction is based.

Line responses may be given for the container that describes the request to publish a notice or they can be related to the referenced notice within the container.

Example of line reference
<cac:LineReference>
    <cbc:LineID>/TenderWithdrawal/cac:TenderDocumentReference/cbc:ID</cbc:LineID> (1)
</cac:LineReference>
1 Identifies the section of the notice to which the reported issue applies. Please use the XPath of the transaction header if a concrete XPath to the line cannot be given
Line response information

Line response information provides details about a given validation error.

Example of line response
<cac:Response>
    <cbc:ResponseCode>RE</cbc:ResponseCode> (1)
    <cbc:Description>A Tender Document Reference Identifier MUST have a schemeURI attribute.</cbc:Description> (2)
    <cac:Status>
        <cbc:StatusReasonCode>BV</cbc:StatusReasonCode> (3)
    </cac:Status>
</cac:Response>
1 A code stating whether the referenced line was (conditionally) accepted or rejected.
2 The description of the issue identified in the transaction document, if possible a error message from a schematron or xml should be used to give a more detailed insight
3 A codified version of the issue description that describes the nature of the issue e.g. Syntax violation, Business rule violation, etc. Refer to the code list status reason code.

Appendix A: Key examples/use cases

Link to AP example file

Link to DL example file

Link to BV example file

Link to BV example file

Link to BWBV example file

Link to BWNF example file

Link to SV example file

Link to WT example file

Example file for AP
<?xml version="1.0" encoding="UTF-8"?>

<ApplicationResponse xmlns="urn:oasis:names:specification:ubl:schema:xsd:ApplicationResponse-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>
    <cbc:CustomizationID>urn:fdc:peppol.eu:prac:trns:t018:1.1</cbc:CustomizationID>
    <cbc:ProfileID>urn:fdc:peppol.eu:prac:bis:p010:1.1</cbc:ProfileID>
    <cbc:ID>123e4567-e89b-12d3-a456-426614174000</cbc:ID>
    <cbc:IssueDate>2021-07-18</cbc:IssueDate>
    <cbc:IssueTime>14:44:33+01:00</cbc:IssueTime>
    <cac:SenderParty>
        <cbc:EndpointID schemeID="9930">DE122268496</cbc:EndpointID>
    </cac:SenderParty>
    <cac:ReceiverParty>
        <cbc:EndpointID schemeID="9946">500820007</cbc:EndpointID>
    </cac:ReceiverParty>
    <cac:DocumentResponse>
        <cac:Response>
            <cbc:ResponseCode>AP</cbc:ResponseCode>
            <cbc:Description>Accepted</cbc:Description>
        </cac:Response>
        <cac:DocumentReference>
            <cbc:ID>4e3517fd-724d-44fc-b90b-5743c33ff68e</cbc:ID>
            <cbc:DocumentTypeCode>urn:fdc:peppol.eu:prac:trns:t013:1.1</cbc:DocumentTypeCode>
        </cac:DocumentReference>
    </cac:DocumentResponse>
</ApplicationResponse>
Example file for DL (Tender Submission)
<?xml version="1.0" encoding="UTF-8"?>

<ApplicationResponse xmlns="urn:oasis:names:specification:ubl:schema:xsd:ApplicationResponse-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>
    <cbc:CustomizationID>urn:fdc:peppol.eu:prac:trns:t018:1.1</cbc:CustomizationID>
    <cbc:ProfileID>urn:fdc:peppol.eu:prac:bis:p010:1.1</cbc:ProfileID>
    <cbc:ID>123e4567-e89b-12d3-a456-426614174000</cbc:ID>
    <cbc:IssueDate>2021-07-18</cbc:IssueDate>
    <cbc:IssueTime>14:44:33+01:00</cbc:IssueTime>
    <cac:SenderParty>
        <cbc:EndpointID schemeID="9930">DE122268496</cbc:EndpointID>
    </cac:SenderParty>
    <cac:ReceiverParty>
        <cbc:EndpointID schemeID="9946">500820007</cbc:EndpointID>
    </cac:ReceiverParty>
    <cac:DocumentResponse>
        <cac:Response>
            <cbc:ResponseCode>CA</cbc:ResponseCode>
            <cbc:Description>Conditionally accepted</cbc:Description>
        </cac:Response>
        <cac:DocumentReference>
            <cbc:ID>4e3517fd-724d-44fc-b90b-5743c33ff68e</cbc:ID>
            <cbc:DocumentTypeCode>urn:fdc:peppol.eu:prac:trns:t005:1.1</cbc:DocumentTypeCode>
        </cac:DocumentReference>
        <cac:LineResponse>
            <cac:LineReference>
                <cbc:LineID>/Tender/cbc:IssueDate</cbc:LineID>
            </cac:LineReference>
            <cac:Response>
                <cbc:ResponseCode>CA</cbc:ResponseCode>
                <cbc:Description>Deadline expired</cbc:Description>
                <cac:Status>
                    <cbc:StatusReasonCode>DL</cbc:StatusReasonCode>
                </cac:Status>
            </cac:Response>
        </cac:LineResponse>
    </cac:DocumentResponse>
</ApplicationResponse>
Example file for BV
<?xml version="1.0" encoding="UTF-8"?>

<ApplicationResponse xmlns="urn:oasis:names:specification:ubl:schema:xsd:ApplicationResponse-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:t018:1.1</cbc:CustomizationID> (2)
    <cbc:ProfileID>urn:fdc:peppol.eu:prac:bis:p010:1.1</cbc:ProfileID> (3)
    <cbc:ID>123e4567-e89b-12d3-a456-426614174000</cbc:ID> (4)
    <cbc:IssueDate>2021-07-18</cbc:IssueDate> (5)
    <cbc:IssueTime>14:44:33+01:00</cbc:IssueTime> (6)
    <cac:SenderParty>
        <cbc:EndpointID schemeID="9930">DE122268496</cbc:EndpointID> (7)
    </cac:SenderParty>
    <cac:ReceiverParty>
        <cbc:EndpointID schemeID="9946">500820007</cbc:EndpointID> (8)
    </cac:ReceiverParty>
    <cac:DocumentResponse>
        <cac:Response>
            <cbc:ResponseCode>RE</cbc:ResponseCode> (9)
            <cbc:Description>Rejected</cbc:Description> (10)
        </cac:Response>
        <cac:DocumentReference>
            <cbc:ID>4e3517fd-724d-44fc-b90b-5743c33ff68e</cbc:ID> (11)
            <cbc:DocumentTypeCode>urn:fdc:peppol.eu:prac:trns:t013:1.1</cbc:DocumentTypeCode> (12)
        </cac:DocumentReference>
        <cac:LineResponse>
            <cac:LineReference>
                <cbc:LineID>/TenderWithdrawal/cac:TenderDocumentReference/cbc:ID</cbc:LineID> (13)
            </cac:LineReference>
            <cac:Response>
                <cbc:ResponseCode>RE</cbc:ResponseCode> (14)
                <cbc:Description>A Tender Document Reference Identifier MUST have a schemeURI attribute.</cbc:Description> (15)
                <cac:Status>
                    <cbc:StatusReasonCode>BV</cbc:StatusReasonCode> (16)
                </cac:Status>
            </cac:Response>
        </cac:LineResponse>
    </cac:DocumentResponse>
</ApplicationResponse>
Example file for BW and BV
<?xml version="1.0" encoding="UTF-8"?>

<ApplicationResponse xmlns="urn:oasis:names:specification:ubl:schema:xsd:ApplicationResponse-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>
    <cbc:CustomizationID>urn:fdc:peppol.eu:prac:trns:t018:1.1</cbc:CustomizationID>
    <cbc:ProfileID>urn:fdc:peppol.eu:prac:bis:p010:1.1</cbc:ProfileID>
    <cbc:ID>123e4567-e89b-12d3-a456-426614174000</cbc:ID>
    <cbc:IssueDate>2021-07-18</cbc:IssueDate>
    <cbc:IssueTime>14:44:33+01:00</cbc:IssueTime>
    <cac:SenderParty>
        <cbc:EndpointID schemeID="9930">DE122268496</cbc:EndpointID>
    </cac:SenderParty>
    <cac:ReceiverParty>
        <cbc:EndpointID schemeID="9946">500820007</cbc:EndpointID>
    </cac:ReceiverParty>
    <cac:DocumentResponse>
        <cac:Response>
            <cbc:ResponseCode>RE</cbc:ResponseCode>
            <cbc:Description>Rejected</cbc:Description>
        </cac:Response>
        <cac:DocumentReference>
            <cbc:ID>4e3517fd-724d-44fc-b90b-5743c33ff68e</cbc:ID>
            <cbc:DocumentTypeCode>urn:fdc:peppol.eu:prac:trns:t010:1.1</cbc:DocumentTypeCode>
        </cac:DocumentReference>
        <cac:LineResponse>
            <cac:LineReference>
                <cbc:LineID>/TenderWithdrawal/cac:TenderDocumentReference/cbc:ID/@schemeURI</cbc:LineID>
            </cac:LineReference>
            <cac:Response>
                <cbc:ResponseCode>RE</cbc:ResponseCode>
                <cbc:Description>A Tender Withdrawal Identifier MUST have a schemeURI attribute.</cbc:Description>
                <cac:Status>
                    <cbc:StatusReasonCode>BV</cbc:StatusReasonCode>
                </cac:Status>
            </cac:Response>
        </cac:LineResponse>
        <cac:LineResponse>
            <cac:LineReference>
                <cbc:LineID>/TenderWithdrawal/cbc:WithdrawOfferIndicator</cbc:LineID>
            </cac:LineReference>
            <cac:Response>
                <cbc:ResponseCode>CA</cbc:ResponseCode>
                <cbc:Description>WithdrawOfferIndicator SHOULD NOT contain any attributes.</cbc:Description>
                <cac:Status>
                    <cbc:StatusReasonCode>BW</cbc:StatusReasonCode>
                </cac:Status>
            </cac:Response>
        </cac:LineResponse>
    </cac:DocumentResponse>
</ApplicationResponse>
Example file for BW and NF
<?xml version="1.0" encoding="UTF-8"?>

<ApplicationResponse xmlns="urn:oasis:names:specification:ubl:schema:xsd:ApplicationResponse-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>
    <cbc:CustomizationID>urn:fdc:peppol.eu:prac:trns:t018:1.1</cbc:CustomizationID>
    <cbc:ProfileID>urn:fdc:peppol.eu:prac:bis:p010:1.1</cbc:ProfileID>
    <cbc:ID>123e4567-e89b-12d3-a456-426614174000</cbc:ID>
    <cbc:IssueDate>2021-07-18</cbc:IssueDate>
    <cbc:IssueTime>14:44:33+01:00</cbc:IssueTime>
    <cac:SenderParty>
        <cbc:EndpointID schemeID="9930">DE122268496</cbc:EndpointID>
    </cac:SenderParty>
    <cac:ReceiverParty>
        <cbc:EndpointID schemeID="9946">500820007</cbc:EndpointID>
    </cac:ReceiverParty>
    <cac:DocumentResponse>
        <cac:Response>
            <cbc:ResponseCode>RE</cbc:ResponseCode>
            <cbc:Description>Rejected</cbc:Description>
        </cac:Response>
        <cac:DocumentReference>
            <cbc:ID>4e3517fd-724d-44fc-b90b-5743c33ff68e</cbc:ID>
            <cbc:DocumentTypeCode>urn:fdc:peppol.eu:prac:trns:t010:1.1</cbc:DocumentTypeCode>
        </cac:DocumentReference>
        <cac:LineResponse>
            <cac:LineReference>
                <cbc:LineID>/TenderWithdrawal/cac:TenderDocumentReference/cbc:ID/text()</cbc:LineID>
            </cac:LineReference>
            <cac:Response>
                <cbc:ResponseCode>RE</cbc:ResponseCode>
                <cbc:Description>Error caused by a document reference given in the received message that could not be
                    found. Leads to the rejection of the received message.</cbc:Description>
                <cac:Status>
                    <cbc:StatusReasonCode>NF</cbc:StatusReasonCode>
                </cac:Status>
            </cac:Response>
        </cac:LineResponse>
        <cac:LineResponse>
            <cac:LineReference>
                <cbc:LineID>/TenderWithdrawal/cbc:WithdrawOfferIndicator</cbc:LineID>
            </cac:LineReference>
            <cac:Response>
                <cbc:ResponseCode>CA</cbc:ResponseCode>
                <cbc:Description>WithdrawOfferIndicator SHOULD NOT contain any attributes.</cbc:Description>
                <cac:Status>
                    <cbc:StatusReasonCode>BW</cbc:StatusReasonCode>
                </cac:Status>
            </cac:Response>
        </cac:LineResponse>
    </cac:DocumentResponse>
</ApplicationResponse>
Example file for SV
<?xml version="1.0" encoding="UTF-8"?>

<ApplicationResponse xmlns="urn:oasis:names:specification:ubl:schema:xsd:ApplicationResponse-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>
    <cbc:CustomizationID>urn:fdc:peppol.eu:prac:trns:t018:1.1</cbc:CustomizationID>
    <cbc:ProfileID>urn:fdc:peppol.eu:prac:bis:p010:1.1</cbc:ProfileID>
    <cbc:ID>123e4567-e89b-12d3-a456-426614174000</cbc:ID>
    <cbc:IssueDate>2021-07-18</cbc:IssueDate>
    <cbc:IssueTime>14:44:33+01:00</cbc:IssueTime>
    <cac:SenderParty>
        <cbc:EndpointID schemeID="9930">DE122268496</cbc:EndpointID>
    </cac:SenderParty>
    <cac:ReceiverParty>
        <cbc:EndpointID schemeID="9946">500820007</cbc:EndpointID>
    </cac:ReceiverParty>
    <cac:DocumentResponse>
        <cac:Response>
            <cbc:ResponseCode>RE</cbc:ResponseCode>
            <cbc:Description>Rejected</cbc:Description>
        </cac:Response>
        <cac:DocumentReference>
            <cbc:ID>4e3517fd-724d-44fc-b90b-5743c33ff68e</cbc:ID>
            <cbc:DocumentTypeCode>urn:fdc:peppol.eu:prac:trns:t010:1.1</cbc:DocumentTypeCode>
        </cac:DocumentReference>
        <cac:LineResponse>
            <cac:LineReference>
                <cbc:LineID>/TenderWithdrawal/cbc:CustomizationID</cbc:LineID>
            </cac:LineReference>
            <cac:Response>
                <cbc:ResponseCode>RE</cbc:ResponseCode>
                <cbc:Description>Error associated with a syntax violation that indicates a problem that leads to the
                    rejection of the referenced message.</cbc:Description>
                <cac:Status>
                    <cbc:StatusReasonCode>SV</cbc:StatusReasonCode>
                </cac:Status>
            </cac:Response>
        </cac:LineResponse>
    </cac:DocumentResponse>
</ApplicationResponse>
Example file for WT
<?xml version="1.0" encoding="UTF-8"?>

<ApplicationResponse xmlns="urn:oasis:names:specification:ubl:schema:xsd:ApplicationResponse-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>
    <cbc:CustomizationID>urn:fdc:peppol.eu:prac:trns:t018:1.1</cbc:CustomizationID>
    <cbc:ProfileID>urn:fdc:peppol.eu:prac:bis:p010:1.1</cbc:ProfileID>
    <cbc:ID>123e4567-e89b-12d3-a456-426614174000</cbc:ID>
    <cbc:IssueDate>2021-07-18</cbc:IssueDate>
    <cbc:IssueTime>14:44:33+01:00</cbc:IssueTime>
    <cac:SenderParty>
        <cbc:EndpointID schemeID="9930">DE122268496</cbc:EndpointID>
    </cac:SenderParty>
    <cac:ReceiverParty>
        <cbc:EndpointID schemeID="9946">500820007</cbc:EndpointID>
    </cac:ReceiverParty>
    <cac:DocumentResponse>
        <cac:Response>
            <cbc:ResponseCode>RE</cbc:ResponseCode>
            <cbc:Description>Rejected</cbc:Description>
        </cac:Response>
        <cac:DocumentReference>
            <cbc:ID>432a35d2-756a-4670-a07f-46d4ca0433e6</cbc:ID>
            <cbc:DocumentTypeCode>urn:fdc:peppol.eu:prac:trns:t010:1.1</cbc:DocumentTypeCode>
        </cac:DocumentReference>
        <cac:LineResponse>
            <cac:LineReference>
                <cbc:LineID>/EnquiryResponse</cbc:LineID>
            </cac:LineReference>
            <cac:Response>
                <cbc:ResponseCode>RE</cbc:ResponseCode>
                <cbc:Description>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.</cbc:Description>
                <cac:Status>
                    <cbc:StatusReasonCode>WT</cbc:StatusReasonCode>
                </cac:Status>
            </cac:Response>
        </cac:LineResponse>
    </cac:DocumentResponse>
</ApplicationResponse>