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 T008 - Tendering Answers 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
Party | Description | Example of roles |
---|---|---|
Customer |
The customer is the legal person or organization who is in demand of a product, service or works. |
Buyer, consignee, debtor, contracting body |
Supplier |
The supplier is the legal person or organization who provides a product, service or works. |
Seller, consignor, creditor, economic operator |
Role | Description |
---|---|
Contracting body |
The contracting authority or contracting entity who is buying supplies, services or tendering 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 tables describe the transaction business and information requirements of "T008 - Tendering Answers 1.1", it inherits from CEN WS/BII 3 "Trdm085 Tendering Answers transaction".
ID | Requirement |
---|---|
tbr85-001 |
The contracting body shall be identified. |
tbr85-002 |
The economic operator shall be identified. |
tbr85-003 |
The creation date and time of the message shall be specified. |
tbr85-004 |
Each message shall have a message ID. |
tbr85-005 |
The CEN/BII profile and transaction names and versions shall be identified. |
tbr85-006 |
The message shall contain the Procurement Reference number. |
tbr85-007 |
The message may contain the Lot ID’s. |
tbr85-008 |
The message shall contain the answer text. |
tbr85-009 |
The message may contain a reference to the related call for tender questions. |
3. Data model: Syntax mapping and XML example
3.1. Data model and syntax mapping
The data model and syntax mapping for Tendering Answers can be found at Syntax mapping for T008 - Tendering Answers 1.1. The data model and syntax mapping explains how to use the UBL (or an underlying syntax) to support the Tendering Answers information transaction requirements. It provides the syntax mappings from each UBL (or syntax) element to the Tendering Answers information elements of this transaction.
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 Answers: Syntax mapping for T008 - Tendering Answers 1.1 |
The following code lists for coded elements and identifier schemes are used by the transaction.
4.1. 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:RequestorParty/cbc:EndpointID/@schemeID |
Contracting body electronic address identifier |
schemeID attribute is mandatory and must use values from EAS codes |
cac:ResponderParty/cbc:EndpointID/@schemeID |
Economic operator identifier |
schemeID attribute is mandatory and must use values from ICD codes |
cac:RequestorParty/cac:PartyIdentification/cbc:ID/@schemeID |
Contracting body identifier |
schemeID attribute is mandatory and must use values from ICD codes |
cac:ResponderParty/cac:PartyIdentification/cbc:ID/@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.
<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 Tendering Answers - Syntax mapping for T008 - Tendering Answers 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. |
TransactionID | Transaction name | Short Description | cbc:CustomizationID |
---|---|---|---|
T008 |
TenderingAnswers |
The CA sends answers to all subscribed EOs. |
urn:fdc:peppol.eu:prac:trns:t008:1.1 |
6. Description of selected parts of the transaction
The transaction including business terms, business rules and code lists are based upon the definitions of "Trdm085 Tendering Answers transaction" described in "Profile 48 — Call for Tenders Questions and Answers" (CWA 17027-113:2016).
6.1. AdditionalDocumentReferences and Attachments
The EnquiryResponse
element should be build as follows to answering questions:
-
The ParentDocumentReference must have an
cbc:ID
having the attributeschemeName
set toContractFolderID
and the value has to be the contract folder id. -
An
EnquiryResponse
element can have multiplecac:AdditionalDocumentReference
refer to the procurement procedure, a LotsGroup, a lot or a part. -
Answers have to be put in an
cac:Attachment
element. The question to be answered has to be placed at the beginning of the answer. The attachment can have one or morecbc:Description
elements or refer to a file in the ASiC-e by using thecbc:FileName
element. -
Each
cbc:Description
element contains only a question with its answer. -
The relation between
cac:AdditionalDocumentReference
andcac:Attachment
is done by acbc:XPath
element in thecac:AdditionalDocumentReference
-
The
cbc:XPath
can only contain references to ancac:Attachment
and has to match the following expression:/EnquiryResponse/cac:Attachment[number]
where number represents a 1-base index in the list of the attachments.
The following are examples of combining question and its answer in a transaction with different parts of the procurement procedure.
6.1.1. Answering a common question about a procurement procedure
If you have to answer questions only about the procurement procedure, a reference to the question in the attachments can be placed in the cac:AdditionalDocumentReference
with the cbc:ID
having the schemeName
set to ContractFolderID
.
<cac:ParentDocumentReference>
<cbc:ID schemeName="ContractFolderId">6ebc4e19-eba6-4b0a-9155-b59471f20ea0</cbc:ID> (1)
</cac:ParentDocumentReference>
<cac:AdditionalDocumentReference>
<cbc:ID schemeName="ContractFolderId">6ebc4e19-eba6-4b0a-9155-b59471f20ea0</cbc:ID> (2)
<cbc:XPath>/EnquiryResponse/cac:Attachment[1]</cbc:XPath> (3)
</cac:AdditionalDocumentReference>
<cac:Attachment>
<cac:ExternalReference>
<cbc:Description> (4)
Place the Tendering Questions here?
Place your answer according to the Tendering Question here.
</cbc:Description>
</cac:ExternalReference>
</cac:Attachment>
1 | The Contract Folder ID of the procurement procedure. |
2 | The Contract Folder ID of the procurement procedure to indicate a common questions regarding the procedure. |
3 | A reference to an element where a question with its answer is located. The number in square brackets is the position in the list of attachments. The position starts with 1 (1-based indexing). |
4 | The questions and answers are placed in an attachment element. Each question and its associated answer must be put in a description element. |
6.1.2. Answering a question about a group of lots of a procurement procedure
If you have to answer questions about a group of lots, you have to add an cac:AdditionalDocumentReference
with an cbc:ID
having an attribute schemeName
set to LotsGroup
and the value represents the Group of Lots ID.
Add as many questions as needed and refer the cac:Attachment
with the cbc:XPath
element.
<cac:ParentDocumentReference>
<cbc:ID schemeName="ContractFolderId">6ebc4e19-eba6-4b0a-9155-b59471f20ea0</cbc:ID> (1)
</cac:ParentDocumentReference>
<cac:AdditionalDocumentReference>
<cbc:ID schemeName="LotsGroup">GLO-0001</cbc:ID> (2)
<cbc:XPath>/EnquiryResponse/cac:Attachment[2]</cbc:XPath> (3)
</cac:AdditionalDocumentReference>
<cac:Attachment>
<cac:ExternalReference>
<cbc:MimeCode>application/vnd.oasis.opendocument.text</cbc:MimeCode>
<cbc:FileName>TextDocument.odt</cbc:FileName>
<cbc:Description>
Place the Tendering Question regarding GLO-0001 here?
Place your Tendering Answer regarding GLO-0001 here.
</cbc:Description>
</cac:ExternalReference>
</cac:Attachment>
1 | The Contract Folder ID of the procurement procedure. |
2 | Referencing a group of lots. |
3 | A reference to a question and answer. |
6.1.3. Answering a question about several lots in a procurement procedure
If you have to answer one question regarding several lots, you have to add an cac:AdditionalDocumentReference
for each lot containing an cbc:ID
with an attribute schemeName
set to Lot
and a value representing the Lot ID.
Add an cac:Attachment
with the question and its associated answer. Reference this attachment with a cbc:XPath
element in each cac:AdditionalDocumentReference
element.
<cac:ParentDocumentReference>
<cbc:ID schemeName="ContractFolderId">6ebc4e19-eba6-4b0a-9155-b59471f20ea0</cbc:ID> (1)
</cac:ParentDocumentReference>
<cac:AdditionalDocumentReference>
<cbc:ID schemeName="Lot">LOT-0001</cbc:ID> (2)
<cbc:XPath>/EnquiryResponse/cac:Attachment[3]</cbc:XPath> (4)
</cac:AdditionalDocumentReference>
<cac:AdditionalDocumentReference>
<cbc:ID schemeName="Lot">LOT-0007</cbc:ID> (3)
<cbc:XPath>/EnquiryResponse/cac:Attachment[3]</cbc:XPath> (4)
</cac:AdditionalDocumentReference>
<cac:Attachment>
<cac:ExternalReference>
<cbc:Description>
Place the Tendering Question regarding LOT-0001/LOT-0007 here?
Place your Tendering Answer regarding LOT-0001/LOT-0007 here.
</cbc:Description>
</cac:ExternalReference>
</cac:Attachment>
1 | The Contract Folder ID of the procurement procedure. |
2 | Referencing a lot. |
3 | Referencing another lot. |
4 | Referencing the same question and answer (note the same index in square bracket). |
6.2. Reference to multiple attachments
It’s possible to reference multiple cac:Attachment
elements from an cac:AdditionalDocumentReference
.
<cac:AdditionalDocumentReference>
<cbc:ID schemeName="Lot">LOT-0006</cbc:ID> (1)
<cbc:XPath>/EnquiryResponse/cac:Attachment[4]</cbc:XPath> (2)
<cbc:XPath>/EnquiryResponse/cac:Attachment[5]</cbc:XPath>
</cac:AdditionalDocumentReference>
<cac:Attachment>
<cac:ExternalReference>
<cbc:Description>
Place the first Tendering Question about lot LOT-0006 here?
Place your answer according to the question about lot LOT-0006 here.
</cbc:Description>
</cac:ExternalReference>
</cac:Attachment>
<cac:Attachment>
<cac:ExternalReference>
<cbc:Description>
Place the second Tendering Question about lot LOT-0006 here?
Place your answer according to the question about lot LOT-0006 here.
</cbc:Description>
</cac:ExternalReference>
</cac:Attachment>
1 | Indicating an question and answer to lot LOT-0006. |
2 | Two XPath elements to reference the questions and answers or a files. |