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.

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. This document is based on work done by the e-SENS pilot project as well as work done by CEN WS/BII 3 and it closely relates to the corresponding PEPPOL BIS Message Level Response used in PEPPOL Post-Award.

BII relationship
Figure 1. Relationship between BII profiles and PEPPOL BIS

The purpose of the "PEPPOL BIS Profile P010 - Tendering Message Response" 1.1 is to describe a common format for a response message that can be used in eTendering procedures. The Tendering Message Response (TMR) shall facilitate an efficient implementation and increased use of electronic collaboration between eTendering platforms. It will improve reliability by allowing a receiver of a business document to inform the sender about the results of receivers validations and processing success, and in case of negative results, to inform the sender about the nature of the errors as well as their details.The TMR than may allow the sender of the document to take appropriate action.

In a nutshell, the "PEPPOL BIS Profile P010 - Tendering Message Response" 1.1 is a PEPPOL BIS Message Level Response that adds processing exceptions that may occur on the business level of eTendering in an PEPPOL eTendering BIS.

Audience

The audience for this document is organizations wishing to be PEPPOL enabled for exchanging electronic pre-award tendering messages, 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 Peppol

1. Principles and prerequisites

This chapter describes the principles and assumptions that underlie the use of Peppol Pre-Award. The specification herein is based on the CEN WS/BII 3 and the BII Architecture 107 - Message Level Response guideline and it is named:

• "PEPPOL BIS Profile P010 - Tendering Message Response" 1.1

The eTendering Message Response closely relates to the corresponding PEPPOL BIS Message Level Response used in PEPPOL Post-Award.

The BII Architecture 107 - Message Level Response guideline profile document is available from your national standardization body.

The intended scope for this profile includes public procurement, but the profile may also be used in Business to Business (B2B) relations.

This profile is intended to support transmission of electronic documents for processing in (semi-)automated processes. The legal requirements that were taken into account are requirements from European legislation, in particular the Directive 2014/23/EU, Directive 2014/24/EU and Directive 2014/25/EU

1.1. Tendering Message Response introduction

Through the start to end flow of a message exchange; from the creation of an electronic message, down the transport line that goes through one or more transport networks to the designated receiver and all way through the eventual processing of the message content, there may be need to give responses to the relevant parties up-line about the status or results of the actions that the message goes through. These responses are of different nature but for the purpose of this document they can be divided according to the views.

scopeResponseMessages
Figure 2. Flow of different response messages

The figure above illustrates the different views where Tendering Message Responses (TMR) are used. Whereas the technical view is addressed by transport acknowledgements, the TMR is applied to the semantic view (including syntactical apsects) as well as the organizational view of the eTendering process.

Technical View

These are messages that are exchanged within the transport network(s) to inform about the process of carrying a message down the transport line. These responses may inform someone up-line that the delivery to a given point was successful or not and may contain details about issues that are relevant such as why a delivery was not successful. The key nature of these responses is that they do not in any way act on result of validation or processing of the content of the payload that is being transported. These response messages are commonly called “acks” or transport acknowledgements.

Semantic View

When a message has reached a given point in the transport line its content may be validated according to agreed specifications that may be both syntactical and semantic. The outcome of these validations may be reported to a relevant party up-line, informing him whether the validation was successful or not as well as giving some details. An example could be that a tender message that is received is rejected because it is missing a closing tag (syntax error) or because the Economic Operator is not identified by its party and endpoint identifiers. A key nature of these messages is that they report on the message content on the basis of the technical specifications that apply.

Organisational View

A message that has been received and accepted for processing may call for an action on the receiver’s behalf. That receiver’s action may need to be reported back up-line to a relevant party. An example is that a technically correct tender may be received but the receiver decides to reject the tender for any business reason such as expired tender submission deadline, a missing authorization to submit a tender etc. The key nature of these responses is that they report a business decision that is made on the message instance received.

1.2. Benefits of the Tendering Message Response

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.

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.

  • 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.3. Errors in scope of the Tendering Message 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 exceptions

  • 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.4. Errors out of scope of the Tendering Message 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)

1.5. Associated notification and tendering procedures

This section provides a brief overview about the notification and tendering procedures and their associated Peppol BIS and transactions. The illustration thereby points to the relevant Peppol BISs that depict a particular business process. Additionally, the guideline references the underlying CEN WS/BII 3 Workshop Agreement. The CEN BII3 workshop is a standardisation initiative within CEN (European Committee for Standardisation). It provides a framework for interoperability in pan-European electronic transactions expressed as a set of technical specifications ("Profiles") .

The profiles provided by CEN BII3 and Peppol are designed to facilitate effective public e-procurement based on a modular approach for implementation, with a focus on global interoperability. Thereby, BII profiles can be seen as “agreements” on message contents and business processes and are the baseline for many Peppol BISs which add specific technical implementation perspectives that are further illustrated in section 6. Thus, the CEN profile descriptions rather focus on the core information elements that typically cater to the majority of user requirements applicable across Europe and lower the need for detailed bilateral agreements between the trading partners whereas Peppol provides a framework for their implementation and adaption.

1.5.1. Notification procedures

Official notification through publishing bodies is part of many procurement procedures. Many pre-award opportunities first become visible to the economic operators in the form of notices describing upcoming or current procurement procedures (prior information notices or contract notices). At the end of a procedure, a contract award notice about the result of the procedure is published.

eNotification covers the transfer of electronic procurement notices for publication and dissemination with the ultimate aim of opening business opportunities. eNotification profiles are addressed to all those who exchange procurement notices for publication and further information processing. eNotification is therefore generally addressed to eTendering Plattform Providers, Contracting Bodies, publishers, print shops, information brokers or monitoring or statistical services. eNotification can be carried out at various levels and between different levels (regional, state, European etc). The legal obligation of publishing notices at the correct level is the responsibility of the contracting bodies.

The content model of procurement notices in Europe is based on Commission Implementing Regulation (EU) 2019/1780 and upon Directive 2014/23/EU, Directive 2014/24/EU and Directive 2014/25/EU and their annexes, particularly the annex describing the standard forms to be used for the publication of procurement notices. eForms are at the core of the digital transformation of public procurement in the EU. Through the use of a common standard and terminology, they can significantly improve the quality and analysis of data. Well-implemented eForms increase the ability of businesses and other organisations to find opportunities. They will also reduce the administrative burden for buyers, increase the ability of governments to make data-driven decisions about public spending, and make public procurement more transparent.

eNotification covers the electronic transfer of electronic notices for publication and dissemination services. The publication of notices is executed between a contracting body or his representative and a publisher. CEN WS/BII 3 profiles BII14 Prior Information Notice (CWA 17026-102), BII10 Contract Notice (CWA 17026-101) and BII43 Contract Award Notice (CWA 17026-103) describe the exchange of notices between a contracting body or his representative and a publisher. In Peppol, these profiles are covered by the Peppol BIS P008 Publish Notice which provides electronic messaging support to publish a prior information notice, a contract notice or a contract award notice. Thus, Peppol BIS P008 Publish Notice helps contracting bodies to announce business opportunities and contract awards in public procurement procedures.

In the EU, eForms are used to publish notices above threshold on Tenders Electronic Daily (TED)—an online portal for public procurement notices from across the EU. On the national level public procurement decision makers can benefit from eForms through tailoring and defining a national approach to the various aspects of eForms, e.g. using them for contracts below thresholds, considering different policies and requirements.

The Peppol BIS P006 Search Notice supports a process by which a notification platform can be queried along a set of parameters to find relevant notices and related metadata required by other PEPPOL BISs. The profile is based on CEN WS/BII 3 Profile BII45 Search Notice (CWA 17026-104:2016). The transactions, specified in BIS P006 Search Notice are intended to be exchanged between eTendering systems and Publication Bodies but they can be adopted by many other actors. Since the P006 Search Notice provides access to Open Data, it also provides possibilities for the establishment of new business models that allow monitoring, the provision of statistical information or easy access for economic operators to business opportunities in different countries across different eTendering and eNotification platforms.

In order to execute the Peppol BIS P008 Publish Notice and Peppol BIS P006 Search Notice, it is necessary that the parties have Peppol eDelivery in place to enable them to send and receive the transactions in a secure way. Implementers must also support eForms content model because the transactions are based on the EU-wide eForms standard.

1.5.2. Tendering procedures

For the purpose of initiating electronic tendering via Peppol, the Peppol BIS P006 Search Notice plays a significant role. When the contracting body has published a notice, the interested economic operators who finds it may want to subscribe to this procedure by using PEPPOL P001 Procurement procedure subscription based on BII46 Subscribe to Procedure. Thereby, the Profile P006 Search Notice delivers necessary organisational and technical information to identify the procedure and contracting authority. This information is required because the request for procurement procedure subscription must be directed to the entity responsible for the procurement procedure.

eTendering can be put in place using different procedures, depending on the value and the type of the contract to be awarded, on the legal nature of the contracting body and on specific member state national legislation (Directive 2014/24/EU art. 26). Article 26 to 32 from Directive 2014/24/EU and article 43 to 50 from Directive 2014/25/EU describe the different tendering procedures that can be used by contracting bodies. For the purpose of electronic tendering, some of these procedures have been described in CEN WS/BII 3 BII37 Open Procedure (CWA 17027-106) and CEN WS/BII 3 BII39 Restricted Procedure (CWA 17027-108).

In open procedures, any economic operator can access the tender documents (including the call for tenders) and submit a tender before the time expires, without any previous assessment of their capabilities. In restricted and negotiated procedures and in a competitive dialogue the interested economic operators must submit a request to participate in order to be invited in the tendering process by the contracting body. When the contracting body has published a notice, the interested economic operators may subscribe (unscubsribe) to obtain (not obtain) tendering information using profile CEN WS/BII 3 BII46 Subscribe to Procedure (CWA 17027-111) covered by Peppol BIS P001 Procurement procedure subscription. Restricted and negotiated procedures require sending the invitation to tender (profile CEN WS/BII 3 BII52 Invitation to Tender (CWA 17027-117) to the identified candidates.

Once the interested economic operator has subscribed to an open procedure, the contracting authority provides the procurement documents by using Peppol BIS P002 Procurement document access. The BIS P002 is based on CEN WS/BII 3 BII60 Tender Status Inquiry (CWA 17027-123) and CEN WS/BII 3 BII47 Call for Tenders (CWA 17027-112) and provides the call for tender documents. It can be repeated at any time until the tender submission deadline to receive the latest version of the procurement documents. Additionally, contracting authorities must push updates to the economic operators that subscribed to a procedure.

Within the call for tenders, contracting authorities must inform economic operators how to qualify for the procedure. This may be done by an European Single Procurement Document (ESPD) defined by the Commission Implementing Regulation (EU) 2016/7 for which Peppol develops the BIS ESPD 3.0 based on the ESPD Exchange Data Model version 3.0. Additionally, call for tenders may include pre-award catalogue information to describe products and services in a common format allowing economic operators to send offers in a structured way and contracting authorities to evaluate products and services automatically through their tendering tools. The Peppol BIS pre-award catalogue can be used for this purpose and was defined according to the CEN WS/BII 3 Profile BII35 Advanced Tendering with Pre-award Catalogue.

Restricted and negotiated procedures require a previous qualification using profile CEN WS/BII 3 BII 49 Qualification (CWA 17027-114) covered by PEPPOL BIS P011 Qualification before submitting a tender. In restricted and negotiated procedures the contracting authority will send an invitation to tender using profile CEN WS/BII 3 BII52 Invitation to Tender (CWA 17027-117) to the identified candidates which have been selected to submit a tender. In contrast, those economic operators whose qualifications are being rejected are informed using profile CEN WS/BII 3 BII 51 Qualification Rejection (CWA 17027-116).

Once the economic operator has received the call for tenders or invitation to tender, it can use the Peppol BIS P004 Call for Tenders Questions and Answers for the business process of answering questions about a call for tenders. The BIS P004 is based upon CEN WS/BII3 profile BII48 Call for Tenders Questions and Answers (CWA 17027-113) and supports economic operators asking questions about call for tenders. Answers of the contracting authority then have to be sent to all economic operators that subscribed to the procedure and additionally the call for tenders should be updated and pushed to the subscribers of the procedure.

In case the economic operator decides to submit a tender, he can use the Peppol BIS P003 Tender Submission. After the submission of a tender, the contracting body notifies the economic operator of having received the tender. The BIS P003 is based upon CEN WS/BII3 profile BII54 Tendering (CWA 17027-119). On the contrary, economic operators can decide to withdraw a tender that was previously submitted by using the Peppol BIS P007 Tender Withdrawal. The BIS P007 was derived from CEN WS/BII3 profile BII53 Tender Withdrawal (CWA 17027-118) and provides electronic messaging support for the economic operator to withdraw a tender. The contracting body notifies the economic operator of having received the tender withdrawal. After the tender withdrawal, an economic operator may submit a new offer at any time before the tender submission deadline.

On the opening date, the contracting authority gathers and opens all received tenders. The opening board members can now evaluate the received tenders. If questions about specific offers arise during the course of the evaluation, they can be answered through the Peppol BIS P005 Tender Clarification. The BIS P005 supports the contracting authority to clarify questions on a tender which has been submitted. The BIS P005 was defined according to the requirements gathered by the CEN WS/BII3 profile BII50 Tender Clarification (CWA 17027-115).

At the end of the evaluation process, the contracting authority needs to inform the participating economic operators upon the results of the tender evaluation. For this purpose, contracting authorities can use the Peppol BIS P009 Notify Awarding which provides electronic messaging support to inform the bidders that a contract has been awarded to a particular economic operator. The BIS P009 is based upon the CEN WS/BII3 profile BII58 Notify Awarding (CWA 17027-121). The contracting authority can use BIS P009 to inform the winner(s) at the same time as they inform the unsuccessful tenderers and they must individually declare the reasons why they failed. The notification of the awarding decision imitated by BIS P009 shall also start the standstill period clock. After the stand still period, the contracting authority can finalize the contract with the winning supplier and also send a contract award notice using BIS Peppol BIS P008 Publish Notice.

1.6. 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.
usecaseTMR
Figure 3. Flow of Tendering Response Message

1.7. Business requirements

For the Peppol BIS all Peppol business requirements are applicable as documented in BII Architecture 107 - Message Level Response guideline. When adopting "PEPPOL BIS Profile P010 - Tendering Message Response" 1.1 implementers must comply to these requirements.

Req. ID Requirement statement

br107-001

At most one Tendering Message Response can be sent per received message.

br107-002

If supported by both sender and receiver, the receiver MUST send a Tendering Message Response whenever he detects errors in the business document that prevents him from processing it.

br107-003

If supported by both sender and receiver, the receiver SHOULD (as a good practice) send a Tendering Message Response whenever he detects warnings in the business document that do not prevents him from processing it, but that may violate agreed business rules.

br107-004

If supported by both sender and receiver, the receiver MAY (as a good practice) send a Tendering Message Response when the business document received was processed successfully.

br107-005

If supported by both sender and receiver, the business partners SHOULD agree to exchange Tendering Message Responses for all Tendering transactions.

br107-006

The Tendering Message Response SHOULD convey either an “accept” or a “reject” or a "conditionally accept" of the instance received. If accepted, no errors should be reported. If rejected or "conditionally accepted" the reason may be stated.

br107-007

A rejection implies that the instance will not be further processed by the receiver.

br107-008

The Tendering Message Response can be used by its sender to report a business level rejection (e.g. a processing exception due to an expired deadline) of a previously received business document (e.g. tender) that is conformant to PEPPOL BIS.

br107-009

The specification assumes that any service provider or tendering platform acts on behalf of either the sender or the receiver.

br107-010

The Tendering Message Response should provide for coded responses in order to facilitate the automated processing of the Tendering Message Response.

br107-011

The Tendering Message Response should provide for coded status reasons in order to facilitate the understanding of the reasons why the processing of a document has failed and created an exception.

1.8. Interoperability

The PEPPOL eTendering BIS structure is based on the European Interoperability Framework.

It applies the Framework as follows:

  1. Legal Interoperability

  2. Organizational interoperability

    • Organization (Organization/Business):

    • Organization (Process):

      • PEPPOL eTendering BIS support a set of “common business processes” that are assumed to be supported by most enterprises whether public or private. These are processes that are used widely or understood as being relevant for most companies.

      • The current scope of the PEPPOL eTendering BIS and guidelines include processes that support the main flow of open procedures such publication of notices, search of notices, calls for tenders, tenders and awarding notifications. During these processes additional support processes may be executed between contracting bodies and economic operators, such as procurement procedure subscription, call for tenders’ questions and answers, tender withdrawal or tender clarifications.

      • The BIS Pre-Award Guide for Notification and Open Procedure describes the choreography to execute open procedures using Peppol. Thus, the Notification & Open Procedure Guideline is a procedural specification. The guideline does not define individual transactions but it refers to Peppol several BISs and underlying standards, in which the transactions and the transaction information requirements are listed and defined. Even though the guideline is based on a set of PEPPOL BISs, its contents are derived from the agreement BII37 Open Procedure of the CEN Workshop on Business Interoperability Interfaces for Public Procurement in Europe .

  3. Technical interoperability

2. Business process and use cases

The following process flows and use cases describe how the "PEPPOL BIS Profile P010 - Tendering Message Response" 1.1 can be used. The BPMN diagram shows the choreography of the business process implemented by the "PEPPOL BIS Profile P010 - Tendering Message Response" 1.1. The choreography of business collaborations defines the sequence of interactions when the profile is run within its context. The use cases detail example types of responses that can be returned by the Message Level Response (MLR).

2.1. Business process description

The process starts when a BusinessDocumentSender is preparing an electronic business document and then sends it. The BusinessDocumentReceiver receives the business document, potentially validates syntax and business rules and starts to process the business document.

  • In case the BusinessDocumentSender has the capability to receive a TMR, the BusinessDocumentReceiver either:

    • Validates the business document and based on the result returns either an accept (no fatal errors and no processing exceptions found), a conditional accept (warnings found) or a reject (fatal errors or processing exception found)

    • Doesn’t validate the business document and does not find any processing exceptions and just sends an accept to the sender of the business document.

  • If a TMR is returned to the BusinessDocumentSender, it may take appropriate action.

    • If the response is positive the BusinessDocumentSender may update the status of the business document or simply ignore the TMR.

    • If the response is negative the BusinessDocumentSender may be able to fix the issue and sent an updated version of electronic business document.

    • If the response is accepted conditionally the BusinessDocumentSender may be able to analyse and fix the issue for future applications.

bpmnTMR
Figure 4. Business Process Tendering Message Response

The BPMN diagram above shows the choreography of the business process implemented by the TMR. The choreography of business collaborations defines the sequence of interactions when the "PEPPOL BIS Profile P010 - Tendering Message Response" 1.1 is excecuted.

Table 3. Business process
Category Description

Description

A receiver of a business document sends a TMR if the sender of the business document supports the TMR.

Pre-conditions

(1) A faulty business document was received by the Receiver

(2) A correct business document was received by the Receiver

Post-conditions

(1) A negative TMR was sent to the sender of the business document and the sender takes appropriate actions

(2) A positive TMR was sent to the sender of the business document and the business process continues

2.2. Use Case 1 – Positive response

This use case is a message response containing no errors, i.e. a positive response.

Use Case number 1

Use Case Name

Positive response

Use Case Description

This use case is a response based on a business document with no errors, i.e. a positive response.

Parties involved

BusinessDocumentSender, TMR Receiver
BusinessDocumentReceiver, TMR Sender

Status Code

AP

Possible Status Reason Codes

none

Assumptions

  1. The BusinessDocumentReceiver has received an electronic business document from the BusinessDocumentSender.

  2. The BusinessDocumentReceiver has validated the business document from the BusinessDocumentSender.

  3. The result of the validation is OK, no fatal errors or business concerns.

The flow

  1. The BusinessDocumentSender has prepared and sent an electronic business document to the BusinessDocumentReceiver.

  2. The BusinessDocumentReceiver has received the business document.

  3. The BusinessDocumentReceiver has validated the business document.

  4. The TMR Sender has sent a TMR back to the BusinessDocumentSender.

  5. The TMR Receiver has received and processed the TMR.

Result

  1. The TMR helped the BusinessDocumentSender to confirm that the business document was received and validated with no errors by the BusinessDocumentReceiver.

XML example file

See Appendix A for a sample file illustrating Use Case 1.

2.3. Use Case 2 – Negative response – violation of business rules

This use case is a message level response containing errors due to violation of business rules.

Use Case number 2

Use Case Name

Negative response – violation of business rules

Use Case Description

This use case is a TMR based on a business document containing errors due to violation of business rules.

Parties involved

BusinessDocumentSender, TMR Receiver
BusinessDocumentReceiver, TMR Sender

Status Code

RE

Possible Status Reason Codes

BV

Assumptions

  1. The BusinessDocumentReceiver has received an electronic business document from the BusinessDocumentSender.

  2. The BusinessDocumentReceiver has validated the business document from the BusinessDocumentSender.

  3. The result of the validation is not OK due to violation of business rules.

The flow

  1. The BusinessDocumentSender has prepared and sent an electronic business document to the BusinessDocumentReceiver.

  2. The BusinessDocumentReceiver has received the business document.

  3. The BusinessDocumentReceiver has validated and rejected the business document.

  4. The TMR Sender has sent a TMR back to the BusinessDocumentSender.

  5. The TMR Receiver has received and processed the TMR and performed appropriate action due to the rejection.

Result

  1. The TMR helped the BusinessDocumentSender to confirm that the business document was received and rejected by the BusinessDocumentReceiver. The BusinessDocumentSender must take appropriate action to correct and resend the business document.

XML example file

See Appendix A for a sample file illustrating Use Case 2.

2.4. Use Case 3 – Positive response – violation of business rules warnings

This use case is a message level response containing warnings due to violation business rules.

Use Case number 3

Use Case Name

Positive response – violation of business rules warnings

Use Case Description

This use case is a TMR based on a business document containing warnings due to violation of non-fatal business rules.

Parties involved

BusinessDocumentSender, TMR Receiver
BusinessDocumentReceiver, TMR Sender

Status Code

CA

Possible Status Reason Codes

BW

Assumptions

  1. The BusinessDocumentReceiver has received an electronic business document from the BusinessDocumentSender.

  2. The BusinessDocumentReceiver has validated the business document from the BusinessDocumentSender.

  3. The result of the validation is not OK due to violation of non-fatal business rules.

The flow

  1. The BusinessDocumentSender has prepared and sent an electronic business document to the BusinessDocumentReceiver.

  2. The BusinessDocumentReceiver has received the business document.

  3. The BusinessDocumentReceiver has validated and found possible errors the business document.

  4. The TMR Sender has sent a TMR back to the TMR Receiver.

  5. The TMR Receiver has received and processed the TMR and performed appropriate action to anticipate any future rejection of a similar incident.

Result

  1. The TMR helped the BusinessDocumentSender to confirm that the business document was received and could be rejected by the BusinessDocumentReceiver.

  2. The BusinessDocumentSender may take appropriate action to correct and resend the business document.

XML example file

See Appendix A for a sample file illustrating Use Case 3.

2.5. Use Case 4 – Negative response – Process termination

This use case is a message level response which can be used to terminate a search request to not receive further results.

Use Case number 4

Use Case Name

Process termination

Use Case Description

This use case is a TMR based on a search notice, whose results are no longer requested.

Parties involved

SearchNoticeSender, TMR Sender
SearchNoticeReceiver, TMR Receiver

Status Code

RE

Possible Status Reason Codes

PT

Assumptions

  1. The SearchNoticeReceiver has received an electronic search notice from the SearchNoticeSender.

  2. The SearchNoticeReceiver has validated the search notice from the SearchNoticeSender.

  3. The SearchNoticeReceiver has sent results matching the search from the SearchNoticeSender.

  4. The SearchNoticeSender received sufficient results from the SearchNoticeReceiver.

The flow

  1. The SearchNoticeSender has prepared and sent an electronic search notice to the SearchNoticeReceiver.

  2. The SearchNoticeReceiver has received the search notice.

  3. The SearchNoticeReceiver has validated the search notice.

  4. The SearchNoticeReceiver sent page wise search results to the SearchNoticeSender.

  5. The TMR Sender has sent a TMR back to the SearchNoticeReceiver with the request to terminate the page wise search results.

  6. The TMR Receiver has received and processed the TMR and performed appropriate action to terminate the process.

Result

  1. The TMR helped the SearchNoticeSender to confirm that the search was concluded, and it does not need more results. The SearchNoticeReceiver must take appropriate action to stop the sending of search results.

XML example file

See Appendix A for a sample file illustrating Use Case 4.

3. Implementation guidelines

"PEPPOL BIS Profile P010 - Tendering Message Response" 1.1 is based on work done by CEN WS/BII BII107 Message Level Response guideline. The business terms, business rules and code lists defined in this BIS are applied to the following UBL 2.2 documents:

urn:oasis:names:specification:ubl:schema:xsd:ApplicationResponse-2

The Tendering Message Response data model in this PEPPOL BIS is bound to the UBL Application Response Schema 2.2.

Peppol "PEPPOL BIS Profile P010 - Tendering Message Response" 1.1 business process includes 1 transactions:

4. 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.

4.1. Profile identification

All transactions within this profile uses the following profile identifier

The value of the Element cbc:ProfileID for all transactions of this profile must be urn:fdc:peppol.eu:prac:bis:p010:1.1

4.2. Specification identification

In the table below you will find the values to be used as the specification identifier (Element cbc:CustomizationID) for the different transactions of this profile.

Table 4. Specification identifiers for the transactions
TransactionID Transaction name Short Description Element cbc:CustomizationID

T018

Tendering Message Response

The receiver of a business document sends a Tendering Message Response to the sender of the business document.

urn:fdc:peppol.eu:prac:trns:t018:1.1
For implementers, please note that the process identifiers in the document instance MUST correspond to the SMP process identifier.

5. Revision history

Version Date Author Organization Description

0.1

2022-03-07

Felicia Tsakonas

adesso SE

First draft: Description of Use Cases

0.2

2022-03-30

Ansgar Mondorf

University of Koblenz

Description of Introduction, Principles and Prerequisites

0.3

2022-04-01

Ansgar Mondorf

University of Koblenz

Description of Business Process, Implementation Guidelines and PEPPOL Identifiers

0.4

2022-04-02

Ansgar Mondorf

University of Koblenz

Review and Final Draft

0.5

01-03-2023

Ansgar Mondorf

Mondorf IT

Final editorial review for March Release 2023: Update Version information, links & examples, editorial improvements, change of transaction structure

6. Contributors

Country Name Organization

DE

Ansgar Mondorf

Mondorf IT / University of Koblenz-Landau

DE

Rolf Kewitz

Beschaffungsamt des BMI

DE

Felicia Tsakonas

adesso SE