search

open-contracting / standard

Documentation of the Open Contracting Data Standard (OCDS)
http://standard.open-contracting.org/
Other
139 stars 46 forks source link

Planning for parts of a contracting process #910

Open jpmckinney opened 5 years ago

jpmckinney commented 5 years ago

Background

The planning section is structured to describe the planning for a contracting process as a whole, not for any component parts like:

As described in comments in https://github.com/open-contracting/standard/issues/906#issuecomment-519628640, in Paraguay, there might be planning processes, after which a multi-use list is set up, and then there are tender processes (following from the planning processes) that use the multi-use list.

Besides the modelling challenge of how to disclose planning information for parts of a contracting process, there might also be an implementation challenge around how to mint OCIDs or which identifiers to use as OCIDs, depending on the sequence of planning and other stages.

Proposal

None yet.

jpmckinney commented 5 years ago

Update: I misunderstood the comment about Paraguay, and there aren't multiple plannings (one for each of qualification and tender stages) in that case.

jpmckinney commented 5 years ago

From an 2019-10-07 Skype chat: In Paraguay, there might be multiple planning processes at the same time about (for example) buying trucks. Since they know they will buy trucks this year, they do a prequalification process to get a list of suppliers. These suppliers don't know much about the specific needs (how many trucks, what size, etc.). When the government is ready to tender, the prequalified suppliers are invited to submit a tender.

If that is the case, then I think it makes more sense to have one OCID to get on the list, and then one OCID for each tender that uses the list. The contracting process to get on the list can use regular OCDS fields. However, I'm not sure what value the procurementMethod should have for the tenders, and I'm not sure what relationship code should be used in relatedProcesses.

Otherwise, if we tried to model this all as one process, we'd have multiple relatedProcesses for all the different planning processes, which suggests that model is wrong.

This scenario assumes the government doesn't know in advance whether the PQ list will be used only once; if it did, it could make it part of one process (e.g. like a restricted procedure in the EU), as there is only one planning and one tender.

In short, this issue isn't encountered in the above scenario (assuming its description is accurate).

The discussion of how to model a multi-use list in that scenario can be continued in #909.

jpmckinney commented 5 years ago

Another scenario is around joint procurement: In Paraguay, the procedure will be that each buyer does their own planning independently, and then might decide to do a joint contracting process to fulfill their common needs.