Contracting Authority/extend roles

[eprocurementontology]

Patrizia Cannuli proposed the following issue on behalf of Consip: "We suggest to extend the Use Cases, adding new class, properties and relationship, to detail the different roles of Contracting Authority. In fact, a CA can publish and award tenders for its own purchases of goods and services or for the execution of works but it can also act as Central Purchasing Body, awarding contracts that can be used by other public administrations (CA)."

How should we integrate Central Purchasing Body and are there other roles that should be taken into account?

[JachymHercher]

OCDS models this as a procuringEntity and a buyer, if I'm not mistaken. I think it's a very useful distinction.

The definitions are available at http://standard.open-contracting.org/latest/en/schema/release/.

procuringEntity The entity managing the procurement, which may be different from the buyer who is paying / using the items being procured.

buyer The buyer is the entity whose budget will be used to purchase the goods. This may be different from the procuring agency who may be specified in the tender data.

[makxdekkers]

The latest version of the conceptual model (to be provided ahead of the WG meeting of 24 May 2017) makes a distinction between the Buyer and the 'Procuring Entity', the entity that publishes the Call For Tender.

[JachymHercher]

@makxdekkers the definition of the procuringEntity is not in line with the OCDS definition - managing is not publishing. Personally, I would go for the OCDS definition.

Also, note that a "buyer"/"contractingEntity" ""sends"" a "notice", a "publisher" (e.g. TED) ""receives"" a "notice", and then a "publisher" ""publishes"" a "notice". I think the current CM has this differently.

[muricna]

This needs to be clearly discussed within the working group who announces/sends/publishes and what is necessary for the ontology.

I would say a buy announces something in a notice

[JachymHercher]

I agree, this should be clarified. I would assume that the decision of what is necessary for the ontology should be based on how the ontology is intended to be used. For me, the distinction of the actual publisher (e.g. TED) is useful for understanding where notices get published (to know whether companies see them) and ensuring that legal restrictions on content and time of publication can be followed up (publication at national level not sooner than 48 hours unless published on TED etc.).

If this is out of scope, it should be explained in the scope section of the ontology document...

[makxdekkers]

Yes, @JachymHercher, "the decision of what is necessary for the ontology should be based on how the ontology is intended to be used". This is what should follow from the use cases. In the case you outline, it seems to me that TED is 'where the notice is published' (the publication channel) rather than 'who publishes the notice' (the organisation reponsible for the content of the notice). So it could be proposed to add such a relationship to the notice, e.g. 'is published at'.

[JachymHercher]

For me, both ways work.

[JachymHercher]

Just to have a concrete example, please find below the type of data that could be modeled better by distinguishing "procuringEntity" and "buyer". (Note that neither case includes nor CPBs nor joint procurement. However, these examples may still be useful for the ongoing discussion in #27)

http://ted.europa.eu/udl?uri=TED:NOTICE:135585-2016:TEXT:EN:HTML "Municipality of Swinoujscie represented by the Mayor acting as the manager of a public road, proceedings conducted by: General Directorate of National Roads and Motorways Branch in Szczecin"

My interpretation: Buyer = Municipality of Swinoujscie procuringEntity = General Directorate of National Roads and Motorways Branch in Szczecin

http://ted.europa.eu/udl?uri=TED:NOTICE:136889-2016:TEXT:EN:HTML "The Capital City of Warsaw represented by the Municipal Transportation in Warsaw, and on behalf of whom and for whom acts Warsaw Metro."

My interpretation: Buyer = The Capital City of Warsaw procuringEntity = Warsaw Metro

[paulakeen]

We consider that this issue is currently solved. This comment is intended to summarise how the current Conceptual Model represents the solution. Let's see how:

1. First of all, the ePO models "roles" differently to eForms and OCDS. Instead of having one single class Organisation that uses a code list specifying its different possible roles, in ePO we define one particular class that represents and defines the role. Thus in ePO we have the classes "Buyer", "Central Purchasing Body" and "Procurement Service Provider". See definition in the ePO [Glossary](https://github.com/eprocurementontology/eprocurementontology/wiki/eProcurement-Glossary-v2.0.1). There's a strong justification for having designed the roles in this way, but this is not the right place and moment to discuss it (please create an issue if you need that justification).

2. The concept of 'procuringEntity', as defined in OCDS and mentioned by Jachym, is implemented in ePO as the class 'Procurement Service Provider'. To understand how a Procurement Service Provider is a procuringEntity you need to pay attention to the property of Buyer (or CPB) termed 'delegates ancillary activities on'. Read the definition of 'ancillary activities' in Directive 2014/24/EU, Article 2 (15) c.

3. In ePO a Buyer (or a CPB) can be of one (and only one) type of Contracting Authority, Contracting Entity or another type of Buyer. This is solved by the use of three code lists associated to "Buyer" and CPB:contracting-entity-legal-type, contracting-authority-legal-type, and contracting-organisation-legal-type. This solves the problem of how to specify any type of buyer defined in all the Directives.

4. Contracting Authorities have activities that are different to the ones of the Contracting Entities. This is solved using two differentiated code lists: entity-activity and authority-activity.

[JachymHercher]

1- Sounds good - as far as I'm aware, this different approach between eForms and ePO can be easily and perfectly mapped. Please double check https://github.com/eForms/eForms/issues/85#issuecomment-475609662 to see whether all the eForms role are covered - and also to decide how to model eForms' subroles.

3- Doesn't this ignore the unfortunate (for modelling) legal truth that some contracting entities are also contracting authorities, as well as the corollary, that a single buyer may have both a contracting entity and contracting authority legal type?

Also, just on the graphical side, the "disjoint" arrows in the diagram of https://github.com/eprocurementontology/eprocurementontology/issues/6#issuecomment-502022228, are somewhat ambiguous, in the sense that they could be understood as calling all three lines disjoint or only the first and the last. Isn't there a way to make this clearer?

[andreea-pasare]

In the latest release, ePO 3.0.1, the roles on the buyer side are modeled as depicted in the diagram below: