Skip to content
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

'No Objection' certificates (and/or approvals or milestones) #403

Closed
agm3dc opened this issue Nov 11, 2016 · 15 comments · Fixed by #1647
Closed

'No Objection' certificates (and/or approvals or milestones) #403

agm3dc opened this issue Nov 11, 2016 · 15 comments · Fixed by #1647
Assignees
Labels
Codelist: Codes Relating to adding or deprecating codes in codelists Codelist: Open Relating to an open codelist
Milestone

Comments

@agm3dc
Copy link

agm3dc commented Nov 11, 2016

In West Africa, and likely elsewhere, procurement authorities issue "no objection" certificates as part of the procurement process.

In Nigeria, these certificates are sought:
A. When a procuring entity requests if it wants to use a restricted procurement method (in practice, for anything that is not national competitive procurement).
B. When a procuring entity requests to award a contract above a certain price threshold;

In Liberia, the procuring authority issues a no objection certificate:

C. when a procuring entity requests to award a contract above a certain price threshold (this threshold varies depending on the nature of the procurement). It is during the approval of procurement plan that the authority would usually approve the use of restricted procurement methods.

I would propose including no objection as a binary field in tender phase to meet use case A, in the award phase to meet use case B, and in the planning phase in case C. I recognize this is a number of new fields, but thought it worth raising.

@timgdavies
Copy link
Contributor

Thanks @agm3dc. This is an interesting use case.

We've been thinking about a possible approvals block which would consist of:

  • approvalType
  • agent
  • date
  • outcome
  • confirmation documents

This has come up from the PPP extension work, where it is useful to know that an organisation has been cleared through a competition check, or some other process.

The idea was that approvals could then belong to a process, or to an organisation, and that it would be possible to provide the supporting documentation.

This would be captured as an extension to OCDS, rather than in core.

Would there be value for your use-cases in this more detailed extension? Or would the simple flag be all you are aiming for?

@chrisalexsmith
Copy link

For donor funded procurement e.g. World Bank, African Development Bank etc etc the 'no objection' process is also applicable and will normally be a date field in the procurement plan agreed with the recipient government.
On an unrelated point, is there any possibility that the above (and other) development institutions will also sign up to the OCDS?

@agm3dc
Copy link
Author

agm3dc commented Nov 11, 2016

Thanks @timgdavies. The use case I have in mind is a simple 1,0 to signify whether no objection certificate has been provided. This way, an authority can detect easily, for example, if a restrictive procuring method has been used when a no objection certificate has not been sought.

The "approval type" category you have defined should work as far as i'm aware.

@timgdavies
Copy link
Contributor

I've been doing some work on the milestones extension to capture arbitrary events. This is documented here

This introduces milestones to the planning section, and adds both milestone type (with a value for 'approvals') and milestone code which can be used by particular implementations to track particular kinds of approvals.

That would mean that the no-objection certificate could be modelled as:

"planning": {
    "milestones":[
       { 
          "id":"1",
          "type":"approval",
          "code":"noObjection",
          "status":"met",
          "dateMet":"2016-12-02T00:00:00Z"
       }
    ]
}

I know this is not as simple as a single flag, but I think it gives us a more flexible model - as it allows:

  • The use of status for the simple flag
  • The inclusion of a date if required
  • The use of wider milestone features if wanted, such as associated documents for each milestone (e.g. the evidence in the certificate)
  • The idea of scheduling approvals (with a status of 'scheduled' and dueDate) to indicate when approval would be expected.

Thoughts?

@timgdavies
Copy link
Contributor

@chriscrownagents Good question on other development institutions signing up to OCDS. That's one I might have to ping over to the Open Contracting Partnership policy team.

@agm3dc
Copy link
Author

agm3dc commented Dec 12, 2016

@timgdavies Your approach sounds reasonable; probably better than that which I had in mind previously as it's more flexible.

FYI, I've also come across the case of Guinea, where as many as 10 or 12 no objection certificates can be required (essentially all documents produced by the PE need a certificate from the proc authority). This would likely change in the event that they adopt electronic tools, but it goes to show that the use of no objection is varied.

@mpostelnicu please weigh in if you have any concerns.

@mireille-raad
Copy link

mireille-raad commented Sep 1, 2017

Approval just came up in a CoST-PPP technical discussion. Here are some "conceptual" reasons that could potentially justify a new building block for approvals:

  • The importance of the approval data in the corruption use case (which is a main one in the OCDS). It would make this building block more permanent instead of it being a codelist. You can add much more details to it.

  • When you get into big projects (PPP/CoST), the approval process might become more elaborate. A new building block can be easily modified... while modifying the milestone building block has its limitation. So that is something to think about for 'the long run'

As for the suggested data model, it is great that it takes into consideration that there might be multiple approvals.

"planning": {
    "milestones":[
       { 
          "id":"1",
          "type":"approval",
          "code":"noObjection",
          "status":"met",
          "dateMet":"2016-12-02T00:00:00Z"
       }
    ]
}

I have some questions about:

  • Linking it to the parties: who approved? there could be one or many organizations included in the approval (ministry of finance, proc entity) - there could also be committees with member names. Sometimes there are social witness who are part of the approval an it might be good to capture all those details. I don't see how it is done within this milestone. (there is no parties array included)

  • How to model if a procurement process received objections? ... I know your codelist says "noObjection" , but is there a proposed model for objections? their numbers at least?

  • Can the start of the approval process and actual date be modeled? needless to say it would be good to have data on how long things are taking to approve. Great use case for the private sector and NGOs who could study the approval date and correlate them with who is in power etc.

  • How to include a document for the specific approval milestone?

  • Does the document type have a codelist for "approval document" ?

@mireille-raad
Copy link

mireille-raad commented Sep 1, 2017

hmm... now i am re-reading my other issue about "certificate" and your suggestion for it to be an extension. (I missed to see the reference earlier). do you still think certificate is the good answer for this issue?

@jpmckinney jpmckinney changed the title Including No Objection fields 'No Objection' certificates (approvals and/or milestones) Sep 18, 2018
@jpmckinney jpmckinney changed the title 'No Objection' certificates (approvals and/or milestones) 'No Objection' certificates (and/or approvals or milestones) Sep 18, 2018
@jpmckinney jpmckinney added the Focus - Extensions Relating to new or proposed extensions, or the governance and maintenance of extensions label Sep 18, 2018
@jpmckinney
Copy link
Member

jpmckinney commented Jul 18, 2020

The milestones proposal seems to have satisfied the early use cases. There are outstanding questions, but no proposed solution. With no new participants since 2017, I am closing this issue.

@yolile
Copy link
Member

yolile commented Sep 15, 2022

I'm reopening the issue as per CRM-8367. In Nigeria, they also have the document of no objection itself. I think no documentType describes this document, so for at least for B. When a procuring entity requests to award a contract above a certain price threshold; I think we could add an "awardApproval" or "awardApprovalCertificate" document type.

@yolile yolile reopened this Sep 15, 2022
@jpmckinney
Copy link
Member

I think no objection is different from approval, legally. It could be that the issuer does not have the power to approve, but does have the power to object. For example, your neighbor can't approve a renovation to your house, but they can object to it if it affects their own property, etc. I figure there are similar scenarios in procurement.

So, we can just call it 'noObjectionCertificate'

@yolile
Copy link
Member

yolile commented Sep 16, 2022

So, we can just call it 'noObjectionCertificate'

And if it is in the tender level will mean that it is a non-objection to the tender and if it is at the award level no objection to the award, right?

@jpmckinney
Copy link
Member

Yes

@jpmckinney
Copy link
Member

@yolile Based on the work in Nigeria, should this code be a candidate for OCDS 1.2?

@yolile
Copy link
Member

yolile commented Jun 7, 2023

Yes, I think it should.

@jpmckinney jpmckinney added Codelist: Open Relating to an open codelist Codelist: Codes Relating to adding or deprecating codes in codelists and removed Focus - Extensions Relating to new or proposed extensions, or the governance and maintenance of extensions labels Jun 7, 2023
@jpmckinney jpmckinney added this to the 1.2.0 milestone Jun 7, 2023
@odscjen odscjen self-assigned this Oct 10, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Codelist: Codes Relating to adding or deprecating codes in codelists Codelist: Open Relating to an open codelist
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

7 participants