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 T015 - Publish Notice 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. |
2. Transaction business and information requirements
The following tables describe the transaction business and information requirements of "T015 - Publish Notice 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.
2.1. Identification and description of the requirements
| ID | Requirement |
|---|---|
PEPPOL-tbr015-001 |
The publication request shall be identified. |
PEPPOL-tbr015-002 |
The electronic address of the sender of the publication request shall be identified. |
PEPPOL-tbr015-003 |
The electronic address of the receiver of the publication request shall be identified. |
PEPPOL-tbr015-004 |
The creation date and time of the publication request shall be specified. |
PEPPOL-tbr015-005 |
The publication request shall indicate if a publication or a validation of the notice object is requested. |
PEPPOL-tbr015-006 |
The object of the notice publication request shall be identified. |
PEPPOL-tbr015-007 |
The object of the notice publication request shall be included and must be formatted according to the eForms standard. |
PEPPOL-tbr015-008 |
The publication request shall contain the following notice metadata:
|
PEPPOL-tbr015-009 |
The publication request shall contain the following buyer information:
|
PEPPOL-tbr015-010 |
The publication request shall provide the possibility to include other attachments associated to a notice. |
2.2. Formatting of notice object
PEPPOL transaction T015 - Publish Notice 1.2 describes a process that supports electronic messaging for the publication of notice. The profile is executed between a contracting authority or its representative and a publication entity to announce business opportunities and contract awards in public procurement procedures.
The PEPPOL transaction T015 - Publish Notice 1.2 only provides a container in which a notice object can be transported. The notice object attached to a publication request must be formatted according the rules described for eForms. The corresponding eForms Specifications are maintained by the Publication Office and are not a specific subject to this BIS. As proposed by eForms, the associated notice must follow the syntax provided by the UBL document schemas:
• 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)]
eForms were established under Commission Implementing Regulation (EU) 2019/1780. The standard forms to be used for the publication of procurement notices and a clear representation of all information requirements that need to be taken into account when preparing a notice object can also be found at: 2019/1780 - Extended Annex to the eForms Regulation.
3. Data model: Syntax mapping and XML example
3.1. Data model and syntax mapping
The data model and syntax mapping for Publish Notice can be found at Syntax mapping for T015 - Publish Notice 1.2. The data model and syntax mapping explains how to use the UBL (or an underlying syntax) to support the Publish Notice information transaction requirements. It provides the syntax mappings from each UBL (or syntax) element to the Publish Notice information elements of this transaction.
3.2. Data model diagram
The following transaction data model illustrates the classes and information elements of T015 - Publish Notice 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 Publish Notice: Syntax mapping for T015 - Publish Notice 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. UBL Document Schema
The UBL Document Schema (rim:Slot name="ublDocumentSchema") has to have the non optional type attribute (type=ublDocumentSchema). It has to be chosen from the code list ublDocumentSchema
<rim:Slot name="UBLDocumentSchema" type="ublDocumentSchema"> (1)
<rim:SlotValue xsi:type="rim:StringValueType">
<rim:Value>CN</rim:Value>
</rim:SlotValue>
</rim:Slot>| 1 | The code "CN" for status information has to be put into the value tag. The listID as the SlotType is always "ublDocumentSchema". |
Identifier (type) |
|
|---|---|
Document location |
|
Issuer |
4.2. Code list for identifier schemes
4.2.1. Electronic Address Identifier scheme of Sender and Receiver
All electronic address identifiers are based upon the Electronic Address Scheme code list (EAS), maintained by CEF (CEF Code lists).
Electronic address identifiers have a non optional scheme identifier attribute (@type) which must be 'ICD'. Valid scheme values are found here: EAS codes.
rim:Value<rim:Value>9946:500820007</rim:Value>| 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 |
|
4.2.2. Schemes for Buyer Party Identification and Buyer Electronic Address.
Buyer Party Identification (rim:Slot name="BuyerPartyIdentification") has an non optional scheme identifier attribute (@type) which must be 'ICD'. The scheme value shall be chosen from the code list ICD codes.
rim:Value<rim:Value>0088:7300010000001</rim:Value>Buyer Electronic Address (rim:Slot name="BuyerElectronicAddress") has an non optional scheme identifier attribute (@type) which must be 'EAS'. The scheme value shall be chosen from the code list EAS codes.
rim:Value<rim:Value>9930:DE122268496</rim:Value>| Business Term | Allowed Scheme | Document location |
|---|---|---|
Buyer Electronic Address Identifier [Buyer Information (BG-3)] |
schemeID attribute is mandatory and must use values from EAS codes |
|
Buyer Party Identification [Buyer Information (BG-3)] |
schemeID attribute is mandatory and must use values from ICD codes |
|
5. PEPPOL Identifiers
PEPPOL has defined a Policy for Using 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 ebXML RegRep documents
The @type attribute must be populated in all instances of the ID element when used within a rim:Slot container for Sender Identification and Receiver Identification.
Example of usage in Sender Electronic Address Identifier and Receiver Electronic Address Identifier:
rim:Slot<rim:Slot name="SenderElectronicAddress" type="EAS">
<rim:SlotValue xsi:type="rim:StringValueType">
<rim:Value>9930:DE122268496</rim:Value>
</rim:SlotValue>
</rim:Slot>rim:Slot<rim:Slot name="ReceiverElectronicAddress" type="EAS">
<rim:SlotValue xsi:type="rim:StringValueType">
<rim:Value>9946:500820007</rim:Value>
</rim:SlotValue>
</rim:Slot>rim:Slot<rim:Slot name="BuyerElectronicAddress" type="EAS">
<rim:SlotValue xsi:type="rim:StringValueType">
<rim:Value>9946:500820007</rim:Value>
</rim:SlotValue>
</rim:Slot>rim:Slot<rim:Slot name="BuyerPartyIdentification" type="ICD">
<rim:SlotValue xsi:type="rim:StringValueType">
<rim:Value>0204:991-1234512345-06</rim:Value>
</rim:SlotValue>
</rim:Slot>5.2. Document Identifiers used in ebXML RegRep documents
5.2.1. Profile ID
The PEPPOL Profile ID identifies what business process a given message is part of, and are connected to one business process, and may contain multiple document types. The Profile ID must be put in the element rim:Slot name="BusinessProcessTypeIdentifier"
Valid profile identifiers are described in the profile BIS documents. See Main documentation site. The following example illustrates the usage of Business Process Type Identifiers in OASIS ebXML RegRep Version 4.0 documents:
rim:Slot<rim:Slot name="BusinessProcessTypeIdentifier">
<rim:SlotValue xsi:type="rim:StringValueType">
<rim:Value>urn:fdc:peppol.eu:prac:bis:p008:1.1</rim:Value>
</rim:SlotValue>
</rim:Slot>5.2.2. Customization ID
The PEPPOL Customization ID identifies the specification of content and rules that apply to the transaction. This transaction requires several changes to the CEN BII transaction. Following the CEN BII methodology any extension must be communicated by adding an extension ID onto the Customization ID. The Customization ID must be put in the element rim:Slot name="SpecificationIdentification"
The following example illustrates the usage of Specification Identification in OASIS ebXML RegRep Version 4.0 documents:
rim:Slot<rim:Slot name="SpecificationIdentification">
<rim:SlotValue xsi:type="rim:StringValueType">
<rim:Value>urn:fdc:peppol.eu:prac:trns:t015:1.1</rim:Value>
</rim:SlotValue>
</rim:Slot>Which customization identification should be used, is based on which transaction is sent, and the extension identification for BIS documents.
| 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 |
|---|---|---|---|
T015 |
Publish Notice |
The provider sends the publish notice request to the responder. |
urn:fdc:peppol.eu:prac:trns:t015: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 "Trdm078 Contract Notice transaction",
"Trdm079 Prior Information Notice transaction" and
"Trdm080 Contract Award Notice 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. Submit Objects Request
-
id indicates the id of the transmission in the form of an UUID
-
mode has to be "CreateOrVersion" as it should be possible to both transfer a new submission or an updated version
<lcm:SubmitObjectsRequest
id="4e3517fd-724d-44fc-b90b-5743c33ff68e"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:4.0"
xmlns:lcm="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:4.0"
xmlns:xlink="http://www.w3.org/1999/xlink"
xsi:schemaLocation="
urn:oasis:names:tc:ebxml-regrep:xsd:rim:4.0
http://docs.oasis-open.org/regrep/regrep-core/v4.0/csd01/xsd/rim.xsd
urn:oasis:names:tc:ebxml-regrep:xsd:lcm:4.0
http://docs.oasis-open.org/regrep/regrep-core/v4.0/os/xsd/lcm.xsd"
mode="CreateOrVersion"
>
</lcm:SubmitObjectsRequest>6.2. Issue Date and time (and preferred publication date)
Issue date/time, and the registered date/time must be sent.
Issue date and received date are both xs:date data type, and the date is specified as "YYYY-MM-DD" where:
-
YYYY - four digit year
-
MM - two digit month (01 to 12)
-
DD - two digit day (0)
Issue time and received time are both xs:time data type, and the time 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 issue date and time refer to the actual issuance of the notice.
| The issue date, and the preferred publication date must specify the time zone. |
<rim:Slot name="IssueDateTime"> (1)
<rim:SlotValue xsi:type="rim:DateTimeValueType"> (2)
<rim:Value>2020-02-14T19:20:30+01:00</rim:Value> (3)
</rim:SlotValue>
</rim:Slot>| 1 | Slot for date and time of issuing of the published notice |
| 2 | SlotValue type has to be DateTimeValue |
| 3 | Value tag were the issue date time has to be put, including the time zone |
6.3. Sender electronic address
<rim:Slot name="SenderElectronicAddress" type="EAS"> (1)
<rim:SlotValue xsi:type="rim:StringValueType"> (2)
<rim:Value>9930:DE122268496</rim:Value> (3)
</rim:SlotValue>
</rim:Slot>| 1 | The scheme of the endpoint id is clarified in the type attribute of the slot. |
| 2 | Fill the scheme id and electronic sender address into this slot. |
6.4. Receiver electronic address
<rim:Slot name="ReceiverElectronicAddress" type="EAS"> (1)
<rim:SlotValue xsi:type="rim:StringValueType"> (2)
<rim:Value>9946:500820007</rim:Value> (3)
</rim:SlotValue>
</rim:Slot>| 1 | The scheme of the endpoint id is clarified in the type attribute of the slot. |
| 2 | Fill the scheme id and electronic receiver address into this slot. |
6.5. Publication Requested Indicator
This indicator shows if the attached notice needs to be published or if it only needs to be validated by the publication body. The check by the publication body can help the contracting party to determine the validity of the notice with regard to a possible publication.
<rim:Slot name="PublicationRequested"> (1)
<rim:SlotValue xsi:type="rim:BooleanValueType"> (2)
<rim:Value>true</rim:Value>
</rim:SlotValue>
</rim:Slot>| 1 | Slot for the indication of the publication of the attached notices |
| 2 | SlotValue type has to be BooleanValueType |
6.6. Registry Object List and Registry Objects (Notice Metadata)
This list contains all the notices, which will be published at once during this transaction. Each notice is represented as one registry object. The Registry Object contains the RepositoryItemRef, which is the reference to the notice itself.
<rim:RegistryObjectList> (1)
<rim:RegistryObject
lid="2C621D47-112D-42D4-B6F8-57392464C3E7"
id="53EB9F20-EE12-474F-9424-78FC604E8FAE"
xsi:type="rim:ExtrinsicObjectType"> (2)
<rim:RepositoryItemRef xlink:href="./53EB9F20-EE12-474F-9424-78FC604E8FAE.eform.xml"/> (3)
</rim:RegistryObject>
</rim:RegistryObjectList>| 1 | Beginning of the registry object list |
| 2 | Here you can find the uuids required to identify the Notice and its associated procurement procedures
|
| 3 | Reference to the eform.xml file which must be included to the ASiC-E Container (Associated Signature Container Extended) repository (see BIS eDocuments guide for pre-award). |
6.6.1. UBL Document Schema
Used to identify the UBL document schema of the referenced notice which are associated to the corresponding UBL namespaces. Use code according to code list document type issued by PEPPOL. For a complete list of all the document types, see tbd.
<rim:Slot name="UBLDocumentSchema" type="ublDocumentSchema"> (1)
<rim:SlotValue xsi:type="rim:StringValueType">
<rim:Value>CN</rim:Value>
</rim:SlotValue>
</rim:Slot>| 1 | The code "CN" for status information has to be put into the value tag. The listID as the SlotType is always "ublDocumentSchema". |
6.6.2. Notice Publication Date Preferred (BT-738)
The "Notice Publication Date Preferred" is the date on which the buyer wishes the notice to be published. It can be used to help the buyer respect the requirements that exist between publications at national and European levels. In case the publication of the attached notices should not be the immediate date when sending of this transaction, use the field to enter a preferred publication date. Otherwise, this field should not be included as well as when no publication is preferred.
<rim:Slot name="NoticePublicationDatePreferred"> (1)
<rim:SlotValue xsi:type="rim:DateTimeValueType">
<rim:Value>2020-02-14T19:20:30+01:00</rim:Value> (2)
</rim:SlotValue>
</rim:Slot>| 1 | Slot for the preferred publication date of the attached notices |
| 2 | SlotValue type has to be DateTimeValueType (please refer to the general hints about using a dateTime Slot above) |
6.6.3. Notice Version (BT-757)
Version of the notice which shall be published. If this is not the first iteration of the notice choose a higher number than one, ideally counting up from the last version which was published.
<rim:Slot name="NoticeVersion"> (1)
<rim:SlotValue xsi:type="rim:IntegerValueType"> (2)
<rim:Value>1</rim:Value>
</rim:SlotValue>
</rim:Slot>| 1 | Slot for the notice version |
| 2 | SlotValue type has to be IntegerValueType, in this case 1 as it is the first version of the notice |
6.6.4. eForms Version
Version of the used eForms specification for the notice. The format is according to the specification always "eforms-sdk-x.y".
-
“eforms-sdk-”: fixed prefix,
-
“x”: major version number (increased everytime backward compatibility is affected),
-
“y”: minor version number
<rim:Slot name="eFormsVersion"> (1)
<rim:SlotValue xsi:type="rim:StringValueType"> (2)
<rim:Value>eforms-sdk-1.2</rim:Value>
</rim:SlotValue>
</rim:Slot>| 1 | Slot for the eForms version |
| 2 | SlotValue type has to be StringValueType, as the format for the version will be always eforms-x.y |
6.6.5. Additional Document Reference
The Additional Document Reference specifies a reference to an additional file that is included to the local ASiC-E container (Associated Signature Container Extended) repository (see BIS eDocuments guide for pre-award). For optional use.
| The notice stored in a eForms based format must contain all the information of the notice, regardless of the place of publication. Therefore, the attached additional file shall only contain additional information to the notice (like statistical data) that is not part of the notice itself. |
<rim:Slot name="AdditionalDocumentReference" type="SomeStatistics"> (1)
<rim:SlotValue xsi:type="rim:StringValueType">
<rim:Value>./12f5017b-e5fa-404b-bfa1-849c721b2c83.eform.xml</rim:Value> (2)
</rim:SlotValue>
</rim:Slot>
<rim:Slot name="AdditionalDocumentReference" type="EvenMoreStats"> (3)
<rim:SlotValue xsi:type="rim:StringValueType">
<rim:Value>./d2c79a1a-af4c-409f-b4c5-f2460e32cfb8.eform.xml</rim:Value>
</rim:SlotValue>
</rim:Slot>| 1 | Example of an attachment. The type is used for the classification of the attachment (here: "SomeStatistics") |
| 2 | Path to the file |
| 3 | If needed, additional attachments can be included as an additional slot (here: "EvenMoreStats") |