-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Procurement plans #794
Comments
Thanks @jpmckinney, I prefer proposal 1, some thoughts on the options below:
This could also be linked via
We have seen demand to provide structured data on procurement plans (at least from Belarus and NSW Australia and probably elsewhere if we were to review past engagements with other publishers), which this option doesn't really address.
Since the items on a procurement plan may have different estimated approach to market dates, they can't be represented using the Sharing examples where procurement plans have been expressed as machine readable data in OCDS: |
I've scheduled for 1.2, so that it is at least discussed as part of that release. Given that this would be a fairly significant change, we might end up having to re-schedule its ultimate deployment. |
The UK government requires departments to publish commercial pipelines (which seem analogous to a procurement plans) and defines a set of fields that should be disclosed, in this document. Most of the fields in the commercial pipeline can be represented using objects and fields which already exist in OCDS. We should consider this in any work on structuring procurement plan data |
Adding some more detail on the examples noted above: Belarus represents each procurement plan using a single contracting process in OCDS, adding an 'items' array to the planning section in OCDS to represent the items due to be procured under the plan. There doesn't appear to be a link between the procurement plan and the tenders which result from it. NSW Australia represents each procurement plan using multiple contracting processes in OCDS, with each item on the plan represented as a separate contracting process. Additional fields are added to the |
Chile is going to publish their procurement plan using items in the planning section as Belarus, too. They have the relation with the tender but after the tender is made not before. |
Paraguay will also publish their data using planning/items. A drafted extension for that is available here: https://gitlab.com/dncp-opendata/ocds_planning_items_extension |
From @pindec's call with Ethiopia:
|
Noting from a call with Lagos:
|
Quick note to add details from CRM-5594. |
Development Gateway authored a similar planning items extension for Makueni County. cc @mpostelnicu |
This issue hasn't been updated in a while. As part of 1.2, a distinction has been made between planning processes and contracting processes. With that, it should be easier to model procurement plans as planning processes (assuming they don't represent some third option). |
Motivation
Discussion
The facts so far:
planning/documents
with adocumentType
ofprocurementPlan
(motivation 2). These documents are presently often PDFs or HTML (1).relatedProcesses
, whoserelationship
can be set toplanning
, defined as "This contracting process follows on from the related planning process." However, this code is meant to relate processes, not to to relate a process to a plan (2).We might need to refine, and we might disagree on, the facts. This issue is partly to figure that out.
Proposals
Based on the facts, these seem to be the possibilities:
planning/documents
field (or a new field).planning/documents
field, but provide no prescribed machine-readable format.relatedProcesses
.Relevant prior discussion: #72 (comment)
Related: #371, #440, CRM-3698
cc @duncandewhurst
The text was updated successfully, but these errors were encountered: