Example: Joint purchases

[Ravf95]

In Mexico, different entities can tender the same goods and services, so they can be tender in a single contracting process. This is called a consolidated purchase.

Proposal

I talked about this with @yolile and she suggests we can add a new field to techniques extension to represent this method of purchase.

cc @yolile @jpmckinney

[Ravf95]

{
    "definitions": {
        "Tender": {
            "properties": {
                "techniques": {
                    "hasConsolidatedPurchase": {
                        "title": "Consolidated Purchase.",
                        "description": "Identifies if the tender is a consolidated purchase.",
                        "type": [
                            "boolean",
                            "null"
                        ]
                    }
                }
            }
        }
    }
}

[jpmckinney]

This seems fine for a local extension. However, I'm not clear on what a consolidated purchase is. Isn't this implied whenever there are multiple parties with a 'buyer' role?

[yolile]

I'm not clear on what a consolidated purchase is.

This is the definition in Mexico: https://www.gob.mx/insabi/prensa/que-es-una-compra-consolidada In Chile: https://www.chilecompra.cl/comprascoordinadas/ Perú: https://www.gob.pe/10566-participar-en-las-compras-corporativas Paraguay will introduce this technique soon with their new public procurement law (from https://www.contrataciones.gov.py/noticias/319.html, page 4 of the document https://www.contrataciones.gov.py/t/download/BannerAdjunto/37 "Compras conjuntas obligatorias"

A consolidated purchase is similar to a framework agreement. Actually, framework agreements are a specific instance of a consolidated purchase (in the sense of multiple buyers buying the same and coordinating their purchases). To save time and get better prices, different entities coordinate what they want to buy, and instead of having multiple tenders, they have a big one. As the result, they will have multiple contracts. For completely modeling this I think they will also need to use the contracts buyer extension.

Isn't this implied whenever there are multiple parties with a 'buyer' role?

Yes, but this can also happen in framework agreements, so it seems fine to have a specific field to indicate the technique used, especially for users that want to filter them.

This seems fine for a local extension.

This could be a local extension, but with the potential to be a community one, as the consolidated purchases is a technique used in other Latam countries as well (and by different states/entities in Mexico)

[Ravf95]

We have the same case with another publisher, México QuiénEsQuién, they are using the CompraNet extension, and it has consolidatedProcessMxCnet field for consolidated purchased

[jpmckinney]

In the EU and some English-speaking jurisdictions like the US, this sort of procedure is referred to as a "joint procurement". In the EU profile, this is simply indicated by having multiple buyers (and the absence of a framework agreement – at any rate, a data analyst must always account for framework agreements, since they mess up most analyses). eForms also takes this "implicit" approach https://github.com/eForms/eForms/issues/251#issuecomment-471165788.

Related to joint procurement, the EU profile adds a 'centralPurchasingBody' role. This is relevant to https://www.gob.mx/insabi/prensa/que-es-una-compra-consolidada

La responsabilidad de instrumentar el procedimiento de compra consolidada recae en una sola institución a la que se conoce como consolidadora.

(Machine translation) The responsibility for implementing the consolidated purchase procedure lies with a single institution known as a consolidator.

and to https://www.chilecompra.cl/comprascoordinadas/

Dependiendo de quién ejecute esta agregación de demanda en el proceso de compra, se distinguen dos maneras de implementación: Compras Coordinadas por mandato, ejecutadas por la Dirección ChileCompra ...

(Machine translation) Depending on who executes this demand aggregation in the purchase process, there are two ways of implementation: Coordinated Procurement by mandate, executed by the ChileCompra Management ...

I don't see any semantic difference between having multiple buyers and having a boolean field. The boolean field would be a calculated field, which we generally do not add, because they duplicate information (and thus are an added opportunity for inconsistency). We only add calculated fields when the basis for the calculation is not disclosed (e.g. OCDS has numberOfTenderers because bidders are typically not disclosed). In this case, I don't see much possibility of the fact of using joint procurement being disclosed, but the specific buyers not being disclosed...

If we do add any field, I would not qualify joint procurement as a technique. The existing techniques – framework agreement (of which dynamic purchasing system is a specific type) and electronic auction – involve very different actions on behalf of the buyers and suppliers, namely call-offs and auctions; there is a clear, technical difference in how the procurement operates. In the case of joint procurement, it is mainly about planning the procurement (i.e. whose needs are aggregated into a single purchase); once the tender notice is published, the procedure behaves the same as non-joint procurement.

[yolile]

Related to joint procurement, the EU profile adds a 'centralPurchasingBody' role.

Yes, this role can also be used in the Latam context and maybe the data users could check for this role to know if the process is a consolidated purchase or not. (However, why 'procuringEntity' is not used in this case? (as it is used in framework agreements))

If we do add any field, I would not qualify joint procurement as a technique

What should it be then?

the procedure behaves the same as non-joint procurement.

Well, the differences are:

• Multiple buyers
• One central purchasing body
• Multiple budgets
• Multiple entities deciding what they need to buy and who will be awarded
• Multiple contracts, at least one for each buyer

How are the contracts for joint procurements disclosed in the EU profile?

And as joint procurements are also related to introducing sustainable procurement I anticipate identifying them will be a clear user need.

[jpmckinney]

maybe the data users could check for this role to know if the process is a consolidated purchase or not

I wouldn't do that because not all joint procurements use a central purchasing body, as described on Chile's page.

why 'procuringEntity' is not used in this case?

There is some discussion about what code to use for the concept of a central purchasing body. It started at https://github.com/open-contracting/standard/pull/1225/files/c9468df62cb8c934b4c53b99e8aba0bf33a1d2a9#diff-0eefb1dd5b82e2659b640cfd9901f9964640b7e17489d8da1afeb334f034e43a, which became https://github.com/open-contracting/standard/issues/1180. We can continue the discussion there.

To find some common ground, not every difference is a difference of technique :) So what makes something a technique?

If we made a workflow chart for the contracting process of a joint procurement (not the planning process), it would look the same as a regular procurement. Award decisions are made (the composition of the award committee and the assignment of decisions to committee members is almost never disclosed, and it doesn't seem to me like these details would imply a fundamental change in technique in any case) and there can be one or more contracts (which is also the case when there are lots, etc.). If the workflow is the same, it is not a different technique.

The differences are mainly in the planning process (number of buyers and budgets, and use of central purchasing body).

What should it be then?

It is a fact of the planning process. The buyers (and CPB) involved carry over to the contracting process, making it possible to identify a joint procurement without looking up the planning process.

How are the contracts for joint procurements disclosed in the EU profile?

The same as any contract. The EU doesn't link a contract to an individual buyer.

I anticipate identifying them will be a clear user need

Sure, but this need is already satisfied by checking whether there are multiple buyers.

[yolile]

Sure, but this need is already satisfied by checking whether there are multiple buyers.

And that tender.techniques.hasFrameworkAgreement is not present or is false. And of course, checking this is harder than checking a boolean field (for both data users and maybe data publishers who may want to have a filter in their APIs, etc), but ok.

If the workflow is the same, it is not a different technique.

The slight change in the workflow could be that after the award, each contract refers to a different buyer (e.g., this will add a line between the buyer, the supplier and the contract, whereas in a regular process, there is no need for that line). The item quantities will also be different from the award to the contracts. It could also be argued that the workflow change is having just one tender instead of many, and that's the technique itself. But I see your point. And might be worth clarifying that in the technique extension definition.

To sum up, for modeling joint purchases in OCDS, the steps are:

• If there is a central purchase body, include it in the parties array using the 'centralPurchasingBody' role
• Include the different buyers as parties using the 'buyer' role as usual
• Use an award to disclose the awarded suppliers and items as usual
• If the data is available, use the contracts buyers extension to disclose the relationship between each contract and the buyer, including the items
• And for planning, I guess the budget breakdown extension could be used to disclose each buyer's budget.

[jpmckinney]

checking this is harder than checking a boolean field

Indeed. A data standard needs to balance consistency and ease of use. Consistency means having a single way to model a fact, (1) so that it can be answered the same way for all publishers and (2) so that you don't get different answers by asking the question in different ways (e.g. checking a boolean vs checking buyer roles). If a use case is sufficiently popular, we might favor ease of use.

Right now, I don't see a convincing case for sacrificing consistency. We can always add a boolean field later once there is some real evidence.

The slight change in the workflow could be that after the award, each contract refers to a different buyer (e.g., this will add a line between the buyer, the supplier and the contract, whereas in a regular process, there is no need for that line)

That relationship doesn't change the workflow (and in any case, that relationship does exist for regular procurement – it's just implicit). A change in workflow requires a new/substituted action/event.

To avoid any future confusion, a simplified workflow is:

publish opportunity -> answer questions -> receive bids -> qualify bids -> decide awards -> sign contracts

• An auction fundamentally changes the "decide awards" step, because it creates new steps like "submit bid" (possibly over multiple rounds). (It's also the auction that decides the award, rather than an award committee (the default).)
• A framework agreement fundamentally changes the "decide awards" step. "decide awards" instead creates a supplier list, and then specific contracts are awarded through call-offs (which might use a formula or a competition).

A joint procurement doesn't do anything fundamental to the above workflow.

It could also be argued that the workflow change is having just one tender instead of many, and that's the technique itself.

Governments have many ways of aggregating demand. Not every way involves a difference in technique. Examples:

• Set up a central government agency to satisfy common needs, like Shared Services Canada (SSC) for IT services. Instead of multiple buyers procuring data storage, all the buyers can instead use SSC (and they don't procure at all).
• Have a central government agency procure common needs with its own budget, and then distribute them internally through a separate mechanism. The procurement itself looks the same as a regular procurement.
• Framework agreement. Aggregation occurs when multiple buyers participate (which is not always the case). It happens to also involve a change in technique, as above.
• Joint procurement.
• No aggregation (multiple tenders).

Notably, auctions are not about aggregating demand; they are just a technique. Aggregation of demand and use of technique are separate concepts, and ought to be modelled differently.

If there is a central purchase body, include it in the parties array using the 'centralPurchasingBody' role

This depends on #1180. It's what the EU profile currently does, though.

[yolile]

Aggregation of demand and use of technique are separate concepts, and ought to be modelled differently.

With something like tender.aggregatingDemandTechnique? 😄 Anyway, I think we need to clarify what a technique means for OCDS in the extension, as right now that is not clear there. I will open an issue. And we could change this issue to be about documenting the modeling of joint purchases in OCDS as a worked example. Sounds good?

[jpmckinney]

I think this discussion is more something for the handbook, since the technique extension doesn’t require exposition of what a technique is - users of the extension are not expected to change the extension itself.

[jpmckinney]

Noting that Directive 2014/24/EU uses "technique" and "instrument" in its preamble for several different concepts including:

Technique

• Framework agreement
• Dynamic purchasing system
• Electronic catalogue
• Centralised purchasing

Instrument

• Framework agreement
• Dynamic purchasing system
• Design contest
• Non-jargon usage (e.g. public procurement as an instrument for sustainable growth)

However, as discussed in https://github.com/eForms/eForms/issues/251, there is no consistent, unifying theme across all of these, and, indeed, eForms rearranges them into distinct conceptual groups – a.ka. business groups (BGs). For example:

• Framework agreement and dynamic purchasing system replace the "decide awards" step of the usual workflow, and so they are treated as one conceptual group, which retains the term "technique".
• A design contest is a different type of procedure entirely (involving publicly named juries whose decision might not be binding, and prizes without the option of a contract in only some cases), and so it is modelled within the conceptual group of "notice" (the highest level in eForms – the procedure itself is represented by a series of notices).
• Electronic catalogues are more about the format of the bid, and so are modelled within the conceptual group of "submission terms".
• Centralised purchasing is just the fact of there being a single procedure to meet the needs of multiple buyers (whether directly or indirectly), and so is modelled via party roles (multiple buyers, central purchasing body, etc.).

OCDS follows the same conceptual grouping (and I informed this grouping in eForms - it didn't start out this way).

[yolile]

Note that this will also be modeled as a local extension for the Mexico Ministry of Hacienda. They use a "Consolidation strategy" field with three possible values: Framework agreement, Joint purchases, and "Sectorizated purchase." (I'm not sure what the last means). In any case, FAs are in the same box as Joint purchases but under the "consolidation strategy" concept.

[yolile]

Confirming that Mexico will create a local extension for this in a field called "Procurement Strategy". They have a clear use case for it, as the government has a commitment that all the national purchases will be joint procurements, and they need an easy way to measure that commitment.

[jpmckinney]

Noting that the eForms profile adds a 'leadBuyer' code for: "The lead buyer in a group of buyers."