Example: Simultaneous supply / Cascade framework agreement

[yolile]

In Paraguay, the lots have their own information, like:

• If the lots allows simultaneous Supply of the items
• the delivery address of the lot
• the minimum value of the lot
• if the lot is part of an open contract and what type of open contract (open amounts or open quantites )

So, it is proposed to add a "details" field, as the one that exist for parties, to add all these details about the lots in Paraguay.

                "lots": [
                    {
                        "id": "1",
                        "title": "Lote Total",
                        "status": "active",
                        "value": {
                            "currency": "PYG"
                        },
                        "details": {
                            "simultaneousSupply": False,
                            "isOpenContract": True,
                            "openContractType": "Por Monto"
                            "minValue": {
                                "currency": "PYG",
                                "amount": 500000
                            },
                            "deliveryAddress": {
                                "streetAddress": "Escriba un lugar de entrega"
                            }
                          }
                    }
                ]

Lot example: https://contrataciones.gov.py/licitaciones/convocatoria/359472-servicio-transmision-vivo-redes-sociales-eventos-organizados-rectorado-una-1.html#itemSolicitados

cc @duncandewhurst

[jpmckinney]

I recommend putting the fields directly on the Lot object.

• What does "simultaneous supply of the items" mean?
• "the delivery address of the lot": Is it not possible to put this on the item using the location extension, and to then relate the item to the lot with relatedLot?
• "the minimum value of the lot": Instead, copy the tender.minValue field onto the Lot object, but replace "procurement" with "lot" in the field description. This change should be made to the core extension.
• "if the lot is part of an open contract and what type of open contract": Could the logic be that if openContractType is set, then it is an open contract, and otherwise it is not? That avoids having an extra field for isOpenContract. This is all I can find from a quick search for "open contract". I'm not sure if perhaps "Contrato Abierto" refers to a different concept than "open contract" in English, e.g. indefinite quantity (or "open quantity" in the PDF) is a narrower kind of "open contract".

details objects are somewhat of an anti-pattern.

[yolile]

"the delivery address of the lot": Is it not possible to put this on the item using the location extension, and to then relate the item to the lot with relatedLot?

Yes, but the information will be the same/duplicate for all the items in the lot.

"if the lot is part of an open contract and what type of open contract": Could the logic be that if openContractType is set, then it is an open contract, and otherwise it is not?

Yes, sure

The definitions of the simultaneous supply and open contract can be found here: https://www.contrataciones.gov.py/documentos/download/marco-legal/12760
at the article 35 and 36 of the Decree Nº 21.909/2003 of the Public procurement law (page 21 and 22)

Simultaneous Supply: is one that contemplates the supply of goods and / or services by more than one supplier or contractor as a result of the same tender.
This system will be applicable when it is convenient for reasons of economy and efficiency or when it is foreseen, for reasons of capacity, that no bidder will be able to provide all the goods.

Open Contract: it is characterized by specifying approximately the quantities and amplitude of goods
and / or services, as they are not capable of exact definition for the duration of the contract.

[jpmckinney]

Yes, but the information will be the same/duplicate for all the items in the lot.

Hmm, in other jurisdictions it's possible for a lot to have multiple items, each of which are delivered to different places (or some to one location and others to a second location). I understand that this duplication is not efficient, but it avoids having to look in two places for the same information, or to have to implement logic like "if an item has a location, use it, otherwise use the lot's location". This gets more complicated if, for example, an item is not deliverable (now you'll need to somehow flag that the lot's location should not be used). Perhaps in Paraguay, all items in one lot always go to one location, but that's not the case in the EU, for example.

Simultaneous Supply: is one that contemplates the supply of goods and / or services by more than one supplier or contractor as a result of the same tender. This system will be applicable when it is convenient for reasons of economy and efficiency or when it is foreseen, for reasons of capacity, that no bidder will be able to provide all the goods.

In a non-Paraguay case, wouldn't 'simultaneous supply' be true anytime the suppliers array has more than one supplier?

Open Contract: it is characterized by specifying approximately the quantities and amplitude of goods and / or services, as they are not capable of exact definition for the duration of the contract.

Okay, so it is similar to indefinite quantity. There's a proposal for estimated quantity, which might be relevant: #689 Let me know what you think – it might not be the best approach.

[jpmckinney]

Regarding the repetition, I created a broader issue: #893

[yolile]

Hmm, in other jurisdictions it's possible for a lot to have multiple items, each of which are delivered to different places (or some to one location and others to a second location). I understand that this duplication is not efficient, but it avoids having to look in two places for the same information, or to have to implement logic like "if an item has a location, use it, otherwise use the lot's location". This gets more complicated if, for example, an item is not deliverable (now you'll need to somehow flag that the lot's location should not be used). Perhaps in Paraguay, all items in one lot always go to one location, but that's not the case in the EU, for example.

Ok, I will duplicate the values.

In a non-Paraguay case, wouldn't 'simultaneous supply' be true anytime the suppliers array has more than one supplier?

Not necessarily, because, even in Paraguay, if the award is by item or lots then you could have a supplier for each awarded item/lot

Okay, so it is similar to indefinite quantity. There's a proposal for estimated quantity, which might be relevant: #689 Let me know what you think – it might not be the best approach.

I commented on that issue about that. But, is ok to add the minValue as an extension to lot?

[jpmckinney]

Not necessarily, because, even in Paraguay, if the award is by item or lots then you could have a supplier for each awarded item/lot

If there is a supplier for each awarded item/lot, then in a non-Paraguay case, there would be a different award for each lot, with one supplier per award. Did I misunderstand your example?

But, is ok to add the minValue as an extension to lot?

Yes, that's fine as described in #888 (comment) I was instead discussing open contract, and only linking to #689 in case it was relevant (e.g. in case the item quantities are specified on open contracts, but need to be expressed as estimates or ranges).

[yolile]

If there is a supplier for each awarded item/lot, then in a non-Paraguay case, there would be a different award for each lot, with one supplier per award. Did I misunderstand your example?

No, you understood it well. But, there are some cases, for example, when the tender was a simultaneous supply but only one supplier was awarded, This can happen because the simultaneous supply type has some rules, for example, that the second awarded supplier must supply the items with the same price as the first awarded supplier and the second awarded supplier could not agree with that. Or, as the example, it could happen that the tender has only one tenderer. So, if we have multiples awarded suppliers for the same item we can be sure that it is a simultaneous supply, but if we only have one awarded supplier we cannot say if the tender was or not a simultaneous supply.
This type of tender is just a way to try to increase the competition, and I think that it is important to have a field to indicate it to the possible bidders.

Yes, that's fine as described in #888 (comment) I was instead discussing open contract, and only linking to #689 in case it was relevant (e.g. in case the item quantities are specified on open contracts, but need to be expressed as estimates or ranges).

Yes, it is relevant because the open contract process could be of amount or quantities, so the items quantities (and amounts) need to be expressed as ranges. What I'm saying is, we already have the concept of ranges in the tender/value and tender/minValue field, and that we can use the same logic for quantities (quantity and minQuantity).
Also, I will need to put/create the minValue field at item level too, for when the tender is by items

[jpmckinney]

Ah, okay, understood: so it is information about the procedure, rather than about the result. It makes sense to indicate it then. To better understand the procedure, in order to determine how best to indicate this:

• Procedurally, how is it determined which supplier will supply the items? Is it similar to a direct call-off in a framework agreement (e.g. where the set-up contract has some rules about deciding which supplier to use)?
• Is a procedure with simultaneous supply considered a distinct procedure? Can 'simultaneous supply' be applied to only one type of procedure, or can it be used in a whole variety of types of procedures?

From what I understand, I would consider 'simultaneous supply' to be a type of two-stage procedure. The first stage determines which suppliers participate, and in a second-stage (I'm assuming) they are awarded contracts based on some criteria.

As part of the work on EU forms, this extension adds a secondStage field on the Lot object to describe procedural details about the second stage. So far, it just indicates any limits on the number of candidates to be invited for the second stage.

If 'simultaneous supply' is an attribute that can describe many different types of procedures, then we might want to add it to this secondStage object. If, instead, it is a distinct procedure, then perhaps it is better to map it to procurementMethodDetails or similar.

[jpmckinney]

Re: quantities, understood, I will discuss in that issue, then.

[yolile]

Procedurally, how is it determined which supplier will supply the items? Is it similar to a direct call-off in a framework agreement (e.g. where the set-up contract has some rules about deciding which supplier to use)?

The supplier with the lowest price is the first awarded, and he has to provide a percentage of the number of item (this percentage is determined already in the tender specifications and conditions document), then the second should provide the rest and so on. This decision is made in the award and there is not a second stage, all is part of the award stage. so I think that in this case is not necessary to have a secondStage or similar, we dont have extra information or stages.

Is a procedure with simultaneous supply considered a distinct procedure? Can 'simultaneous supply' be applied to only one type of procedure, or can it be used in a whole variety of types of procedures?

It is the second, it can be used in a variety of types of procedures

[jpmckinney]

Thanks for clarifying! Okay, so it is used in single-stage procedures and is a 'modifier' to or an attribute of a procedure rather than a distinct procedure.

So, I think the proposed Lot.simultaneousSupply boolean is reasonable. I don't know similar examples from other jurisdictions to inform the choice of term.

[yolile]

Yes, and just noticing that if the tender is by items the boolean simultaneousSupply should be at the item level. So the extension should add the field in lot and item

[jpmckinney]

Also, I will need to put/create the minValue field at item level too, for when the tender is by items

just noticing that if the tender is by items the boolean simultaneousSupply should be at the item level

Can you explain what is meant by 'tender by items'? If the procedure is to award different items to different suppliers, then I believe, conceptually, that the items are in different lots. It might be the case that in the concrete system you are working on, a shortcut is taken to avoid the overhead of tracking/storing lots if each item is known to be awarded separately, but even in that case I think there are 'conceptual' or 'virtual' lots.

I think it is very confusing if items start inheriting fields that originate from the tender/lot.

[yolile]

So, in Paraguay, we have three different awards methods:

• By Lots: each supplier can win one or more lots. If you win a lot you have to supply all of the items of that lot, example
• By total: you can only win all of the items, and the items are aggruped in one big lot, example
• by items: each item can be awarded to different suppliers, there is not lots in the tender, example

I think it is very confusing if items start inheriting fields that originate from the tender/lot.

So maybe, we can just put the simultaneousSupply field at the item level, to be consistent, as we will do with the deliveryAddress

[jpmckinney]

I'm not sure that addresses the broader modelling issue.

First, I want to be clear in distinguishing what I mean by 'conceptual' and 'concrete'. 'Concrete' means what you can directly observe from a real system in the real world. 'Conceptual' means an abstraction or inference or implication from the concrete, which is necessary for there to be any standardization across concrete systems. OCDS operates at the conceptual level, and all implementations of OCDS need to make some leaps from the concrete to the conceptual; otherwise, they are not using OCDS as a standard, but instead as a set of common 'building blocks' that have different semantics in different jurisdictions.

At a conceptual level, 'Lot' is the concept for organizing items that are to be supplied together. If there are no lots, the interpretation is the same as if there were one big lot, i.e. all items are to be supplied together.

Now, I understand that the implementation of public contracting into a concrete system in Paraguay has produced a method whereby there are no concrete lots. However, the items are nonetheless organized such that each item is to be supplied separately. This would mean that there are 'conceptual' lots, but, in this case, they have no representation in the concrete system.

If we were to model items as you suggest, then OCDS data users will need to apply special logic to correctly interpret Paraguay's data. They will need to know that if some flag is set indicating that the method is 'by items', then they must treat each item as if it is in a separate lot. If Ukraine were to pursue yet another model, then OCDS data users will need to apply more special logic, and so on. This leads to a situation where the data can hardly be described as 'standardized', and OCDS becomes a bag of words that countries re-use, rather than a standard with consistent semantics.

[jpmckinney]

Here's another way of thinking about it. Let's pretend that instead of 'Lot', the definition is called 'ItemContainer', and it is described as "A group of one or more items, where each group is bid on, awarded, and supplied separately. If a contracting process has no groups, it is interpreted as having a single group for all items." I think we would agree that, in Paraguay, in the 'by items' case, that it needs 'item containers' to model its procedure correctly – otherwise, 'by items' isn't distinguished from the 'by total' case.

In OCDS, 'Lot' is the word used for that concept. 'Lot' is not defined as "lot according to Paraguay law + lot according to Ukraine law + lot according to UK law," etc., because that would be an incoherent concept, because not all countries use the same words to mean the same things, and many countries use concepts implicitly in cases where it isn't relevant to be explicit. In OCDS, we unfortunately need to be very explicit to achieve standardization.

[yolile]

Ok so,
Paraguay -> OCDS
by item -> an item container (lot) per item - here the information about the simultaneousSupply goes to the lot
by lot -> an item container (lot) per lot - here the information about the simultaneousSupply goes to the lot
by total -> no item container at all - here the information about the simultaneousSupply goes to the item?

[jpmckinney]

For by total, I recommend having one (big) lot in lots, and putting simultaneousSupply on the lot.

(In #891 I propose that all OCDS contracting processes should specify an explicit lot, as otherwise there are two ways of modelling the same thing (either use tender as an implicit lot, or use lots with a single lot), which means that data users need to look in two places, and also need to reconcile potentially conflicting information between the tender and lots. In retrospect, it might have been a good idea to use a generic term instead of 'lot'.)

I'm not sure if people will agree with #891 (i.e. forcing the use of lots by all publishers), but for this case, it is not incorrect to use lots even if there is only one lot.

[yolile]

Ok, after discussing this with the dncp team, we agreed on having lots for all the cases

[jpmckinney]

Thanks for reporting back and working through the different options and questions :)

[jpmckinney]

This issue has become a bit wide-ranging, so I'm creating some follow-up issues:

• lots: Add Lot.minValue field ocds-extensions#152 lots: Add Lot.minValue field
• Example: Division into lots #1105 Worked example: Division into lots

Already created:

• Discussion: Move other blocks to top-level, similar to parties #893, to avoid the repetition of location objects across multiple items

This issue will remain a discussion of simultaneous supply.

[jpmckinney]

@yolile Does @JachymHercher's description of the process match how it works in Paraguay?

If so, we might look for a common model for expressing simultaneous supply and FAs with cascades.

[yolile]

@yolile Does @JachymHercher's description of the process match how it works in Paraguay?

Kind of, the definition of simultaneous supply in Paraguay (
https://www.contrataciones.gov.py/documentos/download/marco-legal/12760
at the article 35 and 36 of the Decree Nº 21.909/2003 of the Public procurement law (page 21 and 22) ) says that:

"The highest possible quantity will be awarded to the tenderer who presents the lowest value, and the remaining quantities to the following bidders in evaluation order, provided that these bidders agree to adjust their prices to those of the lowest evaluated bid"

So let says that an entity wants to buy a maximum of 2000 cubic meters of fuel, for example, https://contrataciones.gov.py/licitaciones/adjudicacion/381473-adquisicion-gasoil-1/resumen-adjudicacion.html#proveedores but there are no suppliers that can provide the total liters needed. So tenderer A offered to provide fuel to 2$ the liter, and tenderer B 1$ the liter. As tenderer B offered a lower price the entity asks tenderer B to provide the maximum quantity of fuel that he can, and the remaining goes to tenderer A, but at the same price tendered by tenderer B.

So, for the same procurement process, we have two awards, for different suppliers but with the same items with the same unit prices but different quantities.

When the capacity of the first supplier is surpassed, I would go to the second supplier.

So this is true, I think the "simultaneous" word doesn't mean exactly simultaneity

If so, we might look for a common model for expressing simultaneous supply and FAs with cascades.

In Paraguayan law, this is expressed as an "award method" as: "a system that contemplates the supply of goods and/or services by more than one supplier or contractor as a result of the same tender". So maybe this could be a new tender/awardCriteria or a new technique but as in Paraguay this information is at the lot level, Paraguay will still need the extension that is been using. (lot.simultaneousSupply)

[JachymHercher]

Looking at the definition,

"The highest possible quantity will be awarded to the tenderer who presents the lowest value, and the remaining quantities to the following bidders in evaluation order,

corresponds perfectly to a "cascade framework agreement", which could probably also be called a "framework agreement with multiple participants without the reopening of competition". (I'm not aware of another way to deal with multiple participants in a framework besides a competition or cascade.) I think this can be expressed in OCDS already (or should be possible once the eForms mapping is complete). This means the difference is

provided that these bidders agree to adjust their prices to those of the lowest evaluated bid

which I think might be worth a separate field. I wouldn't tie it tightly with the framework agreement, as I would think it could, in principle, exist just as well in a standalone contract (in the EU you'd probably need to split it into lots). ("Dear tenderers, we are aware that we are buying more than any of you can supply on your own. Please submit your bid price and the maximum number you are able to supply, we will then conclude a contract with several of you, on the condition that you are willing to supply the goods at the lowest bidder's price, which we will inform you of".)

The definition of the field could be "To be awarded a contract, any supplier must agree to supply at the prices offered by the lowest bidder, regardless of his own bid price."

Taken this way, I think it is a general condition of the process/contract - relevant at the call for competition stage - so I would put it in Tender (or Lot). (In theory, we should then see the results during the award stage, when award.value will be different than bids.statistics.value from the bid statistic extension.)

[jpmckinney]

Regarding the semantics:

To be awarded a contract, any supplier must agree to supply at the prices offered by the lowest bidder, regardless of his own bid price.

If the need for such a field is shared across jurisdictions, we can consider a narrow boolean field. Otherwise, we can have a free-text field in which such conditions can be expressed.

@JachymHercher Would this fall into the concept of Contract Terms, Other Requirements or something else?

(In theory, we should then see the results during the award stage, when award.value will be different than bids.statistics.value from the bid statistic extension.)

For which statistic? There's 'lowestValidBidValue', but that is expressed as the value for an entire bid (quantity x unit price). That said, a statistic can be added for 'lowestUnitValue' or similar.

[JachymHercher]

If the need for such a field is shared across jurisdictions, we can consider a narrow boolean field. Otherwise, we can have a free-text field in which such conditions can be expressed.

The use in the EU is purely theoretical, I'm not aware of anyone actually doing it. Still, it seems fairly concrete, so I'd have a tendency to have it structured. (Why I mentioned the similarity between simultaneous supply and FA was just to point out that a concept which seemed different is actually close to a concept we already have.)

@JachymHercher Would this fall into the concept of Contract Terms, Other Requirements or something else?

Out of the two, I'd put it in Contract Terms, but if these two are only in the EU extension, I'm not sure I'd put it in there. As mentioned above, the goal wasn't to have it for the EU, but rather to point out that simultaneous supply could perhaps be more broadly standardized.

For which statistic? There's 'lowestValidBidValue', but that is expressed as the value for an entire bid (quantity x unit price). That said, a statistic can be added for 'lowestUnitValue' or similar.

I think that FA could quite commonly have a unit price as an award criterion, in which case I would assume that both 'lowestValidBidValue' from bidStatistics and value from Bid could contain unit prices. However, having codes for distinguishing unit prices and tender values may still be useful.

[jpmckinney]

I'm moving this to 1.1 (iterative improvements), since it can build on #1123 as a further example of a (cascade) framework agreement - assuming @yolile agrees that simultaneous supply can be modelled as such.

The additional field with the semantics of "To be awarded a contract, any supplier must agree to supply at the prices offered by the lowest bidder, regardless of his own bid price." could be added in a local extension for Paraguay, until we have evidence that other jurisdictions need the same semantics. The implementer can decide whether to model it as Contract Terms or not (which is based on EU requirements but isn't restricted to use by EU members).