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.
1. Principle and prerequisites
1.1. Scope
This guide aims to provide insight into transaction details for the transaction model T016 - Notice Publication 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
| Business Partner | Description |
|---|---|
Governmental or private organization |
Any organisation. |
Governmental organization |
A body governed by public law, meaning bodies: (a) established for the specific purpose of meeting needs in the general interest, not having an industrial or commercial character; (b) having legal personality; and (c) financed, for the most part, by the State, regional or local authorities, or other bodies governed by public law; or subject to management supervision by those bodies; or having an administrative, managerial or supervisory board, more than half of whose members are appointed by the State, regional or local authorities, or by other bodies governed by public law. |
| Role | 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. This term has a narrower scope than the term “Customer” and is in BII treated as a customer role. |
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. |
1.3. Notice Publication Response Principles
The Message Level Response is intended to inform the issuer of the following situations
-
The received notice transaction or the notice payload contained errors according to the relevant conformance rules.
-
The notice will not be processed any further.
-
-
The received notice transaction and the notice payload passed the validation of conformance rules without any fatal errors.
-
The notice will be processed further.
-
-
The received notice transaction or the notice payload are not validated for conformance but the receiver acknowledges that it has been received and identified as a business message.
-
The notice will be processed further.
-
Furthermore, 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.
<cac:DocumentReference>
<cbc:ID>4e3517fd-724d-44fc-b90b-5743c33ff68e</cbc:ID>
<cbc:UUID>53EB9F20-EE12-474F-9424-78FC604E8FAE</cbc:UUID>
<cbc:DocumentTypeCode>CN</cbc:DocumentTypeCode>
<cbc:VersionID>1</cbc:VersionID>
</cac:DocumentReference>Errors can occur and can be documented in detail at both levels, the notice transaction and the notice payload.
1.3.1. The following errors are within the scope for a negative/rejecting Message Level Response:
-
XML schema validation error
-
Standard Compliance violations (e.g. empty elements not being allowed by UBL)
-
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)
1.3.2. The following errors are 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 "T016 - Notice Publication Response 1.2", it inherits from the profiles
• BII Profile 14 - Prior Information Notice (CWA 17026-102:2016)
• BII Profile 10 - Contract Notice (CWA 17026-202:2016)
• BII Profile 43 - Contract Award Notice (CWA 17026-103:2016)]
created by CEN WS/BII 3.
| ID | Requirement |
|---|---|
tbr65-001 |
The identification about the sender and the receiver of the transaction must be specified |
tbr65-002 |
The date and time of the response must be specified |
tbr65-003 |
The response must be identified |
tbr65-004 |
The reference to the document initiated the response, or to publish, must be included |
tbr65-005 |
The code and/or the description of the response must be included, it is a description about the result of the transaction, in the case of the Publication request, the description can be "in progress", "publish", "rejected" or "received" or some other reason. |
tbr65-006 |
The date and time of the reception of the document to publish, may be included |
tbr65-007 |
Some additional information may be included, as question or clarification about the document e.g. in case of validation errors. For detailed information see the scope and the line response sections. |
tbr65-008 |
The type of the document to publish 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 Notice Publication Response can be found at Syntax mapping for T016 - Notice Publication Response 1.2. The data model and syntax mapping explains how to use the UBL (or an underlying syntax) to support the Notice Publication Response information transaction requirements. It provides the syntax mappings from each UBL (or syntax) element to the Notice Publication Response information elements of this transaction.
3.2. Data model diagram
The following transaction data model illustrates the classes and information elements of T016 - Notice Publication Response 1.2.
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 Notice Publication Response: Syntax mapping for T016 - Notice Publication 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. Notice Response Code
Qualifier (listID) |
Notice Response Code |
|---|---|
Document location |
|
Issuer |
4.1.2. Publication Condition Code
Qualifier (listID) |
Publication Condition Code |
|---|---|
Document location |
|
Issuer |
4.1.3. UBL Document Schema
Qualifier (listID) |
UBL Document Schema |
|---|---|
Document location |
|
Issuer |
4.2. 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 |
|
Receiver Electronic Address Identifier |
schemeID attribute is mandatory and must use values from EAS codes |
|
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.
<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.
<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:
<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 Notice Publication Response - Syntax mapping for T016 - Notice Publication Response 1.2 - 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. |
| TransactionID | Transaction name | Short Description | cbc:CustomizationID |
|---|---|---|---|
T016 |
Notice Publication Reponse |
The publication body sends a notice publication response to the contracting authority. |
urn:fdc:peppol.eu:prac:trns:t016:1.2 |
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 14 - Prior Information Notice (CWA 17026-102:2016)
• BII Profile 10 - Contract Notice (CWA 17026-202:2016)
• BII Profile 43 - Contract Award Notice (CWA 17026-103:2016)].
6.1. Identifier
6.1.1. UBL Version Identifier
Requires UBL version 2.2.
<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.
<cbc:ID>123e4567-e89b-12d3-a456-426614174000</cbc:ID> (1)| 1 | A transaction instance must contain an identifier, being a number |
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. |
<cbc:IssueDate>2021-07-18</cbc:IssueDate> (1)| 1 | Format for the date has to be yyyy-mm-dd |
<cbc:IssueTime>14:44:33+01:00</cbc:IssueTime> (1)| 1 | 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.
<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.
<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. The element 'cac:DocumentResponse/cac:Response/cac:Status/cbc:ConditionCode' MUST contain a condition related to the publication of the notice.
6.4.1. Response
A "rejection" states that the notice was not processed because of identified issues. "Conditionally accepted" indicates that the publication of the notice is done with warnings indicated in the message. "Accepted" indicates that the notice will be published at a certain time. "Published" indicates that the notice has been published at a certain time.
The value "test" is used to indicate that the notice has be only used for the purpose to check its validity and not its publication. The value "test" is also used in case of negative validation responses. The value "forecast" is used to indicate a planned publication date in the future. The value "effective" is used to indicate an actual publication date.
<cac:Response>
<cbc:ResponseCode>RE</cbc:ResponseCode> (1)
<cbc:Description>Rejected due to validation error</cbc:Description> (2)
<cbc:EffectiveDate>2021-07-20</cbc:EffectiveDate> (3)
<cbc:EffectiveTime>09:00:00+01:00</cbc:EffectiveTime> (4)
<cac:Status>
<cbc:ConditionCode>FCST</cbc:ConditionCode> (5)
</cac:Status>
</cac:Response>| 1 | An indicator 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. |
| 3 | The date upon which this notice is published. |
| 4 | The time upon which this notice is published. |
| 5 | Specifies the condition related to the publication of the notice. |
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.
<cac:DocumentReference>
<cbc:ID>4e3517fd-724d-44fc-b90b-5743c33ff68e</cbc:ID> (1)
<cbc:UUID>53EB9F20-EE12-474F-9424-78FC604E8FAE</cbc:UUID> (2)
<cbc:DocumentTypeCode>CN</cbc:DocumentTypeCode> (3)
<cbc:VersionID>1</cbc:VersionID> (4)
</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 | Specifies the notice identifier (BT-701) allowing to uniquely distinguishing the notice, expressed in uuid syntax. |
| 3 | An identification of the UBL document schema of the notice being referred to, expressed as a code. Refer to the code list UBLDocumentSchema. |
| 4 | An identification of the version of the underlying notice (BT-757). |
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.
<cac:LineReference>
<cbc:LineID>
/ContractNotice/cac:ContractingParty[1]/cac:Party[1]/cac:PostalAddress[1]/cbc:CountrySubentityCode[1]
</cbc:LineID> (1)
<cac:DocumentReference> (2)
<cbc:ID>53EB9F20-EE12-474F-9424-78FC604E8FAE</cbc:ID> (3)
</cac:DocumentReference>
</cac:LineReference>| 1 | Identifies the section of the notice to which the reported issue applies. |
| 2 | A reference to the document containing the referenced line. |
| 3 | Specifies the unique document identifier to which the line response is related, expressed in uuid syntax.
|
Must either use the See in comparsion the uuid in the response, which is represents the same documente hence uses the same ID seen at number 2
Line response information
Line response information provides details about a given validation error.
<cac:Response>
<cbc:ResponseCode>RE</cbc:ResponseCode> (1)
<cbc:Description>Validation gives error [Rule ID] - Organisation country subdivision (BT-500) MUST be
coded using http://publications.europa.eu/resource/authority/nuts code list
- Link to eForms schematrons https://github.com/OP-TED/eForms-SDK/tree/main/schematrons
</cbc:Description> (2)
<cac:Status>
<cbc:StatusReasonCode>BV</cbc:StatusReasonCode> (3)
</cac:Status>
</cac:Response>| 1 | A code stating whether the referenced line was accepted or rejected. |
| 2 | The description of the issue identified in the transaction document. |
| 3 | A codified verison 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. |