The PEPPOL Business Interoperablity 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.
Introduction to openPEPPOL and BIS
This {peppol} BIS provides a set of specifications for implementing a {peppol} business process. The document is concerned with clarifying requirements for ensuring interoperability of pan-European Public eProcurement and provides guidelines for the support and implementation of these requirements. The {bii3} Profile “BII Profile 35 Advanced Tendering” is the basis for this work.
The purpose of this document is to describe a common format for the pre award catalogue messages in the European market, and to facilitate an efficient implementation and increased use of electronic collaboration regarding the tendering process based on these formats.
Audience
The audience for this document is organizations wishing to be PEPPOL enabled for exchanging electronic pre-award catalogues, and/or their ICT-suppliers. These organizations may be:
-
Service providers
-
Contracting Authorities (CA)
-
Economic Operators (EO)
-
Software Developers
More specifically, roles addressed are the following:
-
ICT Architects
-
ICT Developers
-
Business Experts
For further information on PEPPOL/OpenPEPPOL, please see {common}
1. Principles and prerequisites
This chapter describes the principles and assumptions that underlie the use of PEPPOL Pre-Award Catalogue. It is based on P003 - Tender Submission.
This BIS will identify, explain and justify the business requirements for the Pre-award Catalogue. It provides syntax bindings to OASIS UBL 2.1. It also includes a syntax implementation guide.
1.1. Scope
The intended scope for this {peppol} BIS includes business-to-government (B2G) and business-to-business (B2B) relationships. Although the BIS is a basis for an EDI agreement between two parties, it does not address all business level details of such an agreement/contract.
The Pre-award Catalogue is intended to be used in different tendering processes, such as:
-
Tendering (P003 - Tender Submission)
-
DPS solutions, qualifications etc
-
These processes are not described in detail in this document, but the transaction can be used in these processes if bilaterally agreed.
-
1.2. Parties and roles
1.2.1. Parties
- Customer
-
The customer is the legal person or organization who is in demand of a product, service or works. Examples of customer roles are buyer, consignee, debtor and contracting body.
- Supplier
-
The supplier is the legal person or organization who provides a product, service or works. Examples of supplier roles are seller, consignor, creditor and economic operator.
1.3. Benefits
PEPPOL BIS pre-award catalogue will stimulate the service provider marked to develop services that covers tendering processes both for Contracting Authorities and Economic Operators. Pre-award catalogue together with tendering metadata transaction (trdm090) and confirmation message (trdm045) will:
-
make it possible for the CA to evaluate products and services automatically through their tendering tools
-
make it easier for the economic operators to participate in different tendering processes
-
save time for the EO to offer their products and services to a CA when the list of products and services are standardized
-
save time for the CA to have a standardized list of products and services
-
make it possible for economic operators to use tools to pre-fill their information before the specific tender and send the offer in a structured way through CEF eDelivery (PEPPOL) infrastructure. The benefit is that an EO uses one tool in different tenders instead of dealing with different interfaces depending on which tool the CA uses.
-
make it possible for the CA to use the pre-award catalogue in mini-competitions and re-opening of competitions
-
make it possible for an EO to use the PEPPOL BIS pre-award catalogue xml when up-loading the tender in a 3-corner model on condition that tendering systems are compatible.
2. Business processes and typical use cases
2.1. Business processes
The PEPPOL BIS Pre-Award Catalogue is most normally used in P003 - Tender Submission.
The pre-award catalogue transaction can also be used in other choreographies as qualification, DPS, mini competition and re-opening of competition (post-award phase).
The use of the pre-award catalogue in these other choreographies are not explained in detail in this document.
2.2. Use case 1
On behalf of many municipalities or governmental entities a central unit has been given the task to accomplish a tender for the group on office supplies.
The call for tender includes a structured pre-award catalogue request with the needs for the group. The economic operator (supplier) that prepares the tender downloads or receives the catalogue request as part of the tendering documents. The pre-award catalogue request is containing descriptions of product and services the group needs in a generic way, e.g. blue pen.
Supplier choose their own products or services that fulfill the requirement and make use of a supplier eSubmission system to fill out the requested information as product number, product description, UoM (unit of measure) code, price, link to pictures and labels for environmental and social labels if required and so on. They can reuse generic information the central unit has included in the pre-award catalogue request as classification codes as UNSPSC, CPV or eCl@ss.
After finalizing the pre-award catalogue they include the catalogue together with other structured documents as ESPD or non-structured documents as PDF in to the system. The system prepares for submission towards the tender systems by sending the bid package to the access point connected.
When the contracting authority receives the pre-award catalogues through their access point, from different suppliers, they lock down the offers as part of the bid packages . When time for open the bids, tendering system import the pre-award catalogue xml files in to their valuation service and find the best offer of products and/or services.
The central unit import the catalogue into their catalogue tool and checks the quality. According to the contract, the supplier is sending a post-award catalogue that’s compared towards the pre-award catalogue from the tender. When the catalogue is ok the central unit sends it out of their access point, based on a distribution list in the catalogue tool. The different municipalities or governmental entities are receiving the approved pre-award catalogue in their catalogue tool connected to their eProcurement system. When the catalogue is already approved, the system can automatically display the catalogue content in the eProcurement search engine used by the different entities buyers.
2.3. Relation between different catalogues in the tendering process
The pre-award catalogue will be created based on requirements from the tendering documents or from the notification. Pre-award catalogues can be used in all procedures. In this description the input to the pre-award catalogue is based on a pre-award catalogue request. The pre-award catalogue request is the tool for the contracting authority (CA) to structure requirements for goods, services and works. The pre-award catalogue request contains a generic description of the needs to the CA. Based on the generic descriptions and requirements the economic operator (EO) creates a pre-award catalogue based on their own assortment of goods, services or works to fulfill the requirement of the CA.
Example of generic descriptions can be classifications systems such as UNSPSC, CPV or eCl@ss. Examples of generic requirements are code lists for environment, social and ecological labels or labels that is equivalent. It can be a certification/attestation of certain skills as surgical nurse, midwife, different kinds of engineers or other speciality of occupation. The CA has stored the generic description and requirements from the pre-award catalogue request in the tendering system, and can undertake an automated evaluation of the different offers from different EO´s with the pre-award catalogue as a structured and standardized input.
After the evaluation process, the pre-award catalogue will be stored and after signing the contract with the EO it will be transferred to the eProcurement system (catalogue tool) to be used as baseline. The purpose is to check the electronic product catalogue toward the contract in order to know when or if the EOs can update the catalogue.
Using catalogues in the tendering process will save processing time both for the EO and CA and will enhance transparency and traceability of goods, services and works. To achieve good and effective processes the EO should have their own eSubmission systems based on a 4-corner model to be able to communicate with different tendering platforms based on standard formats and PEPPOL branches of CEF eDelivery.
3. Peppol Identifiers
PEPPOL has defined a {policy8} 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 policies that apply to this BIS are the following:
3.1. Party Identifiers
The “schemeID” attribute shall be populated in all instances of the “ID” element when used within a “PartyIdentification”-container and in all instances of the “EndpointID” element when used within a “Party”- container.
<cac:PartyIdentification>
<cbc:ID schemeID="GLN">5790000435968</cbc:ID>
</cac:PartyIdentification>The following examples denote that the Issuing Agency is DK:CVR in the PEPPOL set of Issuing Agency Codes. This means that the party has the Danish CVR identifier DK87654321.
<cbc:EndpointID schemeID="DK:CVR">DK87654321</cbc:EndpointID>
<cac:PartyIdentification>
<cbc:ID schemeID="DK:CVR">DK87654321</cbc:ID>
</cac:PartyIdentification>3.2. Profiles and messages
All messages contains ProfileID and CustomizationID. ProfileID identifies what business process a given message is part of, and CustomizationID identifies the kind of message and the rules applied.
Profiles are connected to one business process, and may contain multiple document types. Valid document instances must contain corresponding ProfileID and CustomizationID.
The listing below are related document types connected to the role of receiver in the conversation. Registration in ELMA describes the receivers capabilities.
| CustomizationID is a string without spaces. The list below contains spaces in CustomizationID to make them easier to read. Make sure to remove any spaces before use. |
4. Revision history
| Version | Date | Author | Organization | Description |
|---|---|---|---|---|
0.1 |
2023-03-10 |
Andreas Schmitz |
University Koblenz |
First complete Draft based on Peppol and EHF |
0.2 |
2023-06-13 |
Andreas Schmitz |
University Koblenz |
Refinement of the Documentation, Update of all Examples |
0.3 |
2023-09-12 |
Andreas Schmitz |
University Koblenz |
Updating IDs, Removing Transaction-related content; Adding a Revision History; Adding the Implementation guideline |