-
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
OCDS control activities : add requests no objection opinion to tender #1724
Comments
Hi @pdiadia, thank you for reporting this issue. In #403, we discussed 'no objection' certificates. For OCDS 1.2, we will add a 'noObjectionCertificate' code to the documentType codelist. This code is defined as "A document that certifies that the issuer has no objections to the tender or award." Can you share a real (or realistic) example of the information you intend to model? For example, "The Bureau of Public Procurement issued a no-objection certificate about the contracting process on May 1, 2024 … (all other relevant details you want to model)". I think there can be some simplifications to the model you propose. |
Thank you for your reply. For example, at the planning stage, the tender documents are submitted to the supervisory body if the supervisory body's control threshold is reached, in order to give a no-objection opinion on the documents. Similarly, once the contract has been awarded and signed, the inspection body must give its opinion as to whether the procedure should be continued. In addition to these key stages, the element I'd like to propose goes beyond the attribute to model the exchanges between the contracting authority and the inspection body. |
I come back again. What do you think about adding field (hash and digital signature to document) ? |
The question of hashes and digital signatures is somewhat independent, so I created a new issue: #1725 |
In order to model this correctly, we will need some specific examples to work with. Right now, we have an abstract description of the process. It would greatly contribute to the discussion if you could share a specific example with all the relevant details that you intend to model (it can be somewhat fictional example, but it should be realistic and representative). |
By way of example A contracting authority can refer a specific request to the control body. To do so, it submits a letter with a reference and a referral date. The letter is a document describing the request. On receipt, the control body examines the request and issues an opinion, which may be favorable, favorable with reservations or unfavorable. The opinion is issued by means of a document with a date and a reference. For a given type of request, it is possible to go back and forth several times before obtaining a favorable opinion. Here are some examples of request types
|
Context
In Senegal, as part of a public procurement procedure, there is an important activity which consists in controlling the procedures. This activity enables the control body to give a no-objection opinion on the key stages of the procedure (examination of the tender documents, opinion on the bid evaluation report, opinion on the draft contract).
Thus, we propose an extension fields to support the control process (RequestNooTender, RequestNooTenderItem). This extension will to facilitate tracking of information relating to procedure control activities.
List of codes for request types
ETD: examination of tender documents ;
RERPA: review of evaluation report and provisional award proposals;
LTRDC: legal and technical review of draft contract.
Model
When a contracting authority refers a matter to the inspection body for an opinion, the inspection body responds by attaching a document, a description, the response and information on the dates of referral and response.
For a given contract, it is possible to have several referrals to the inspection body (RequestNooTender) Each referral is materialized by RequestNooTenderItem.
• ocid (string, integer)
• id (string, integer)
• description (string)
• typerequest (string) (codelist)
• opinion {object}
o $ref : #/definitions/Document
o datesubmit (Format: date-time) (string)
o daterend (Format: date-time) (string)
For the document, we propose to add two additional fields: the value of the document's hash key and its signature for use in Blockchain.
The text was updated successfully, but these errors were encountered: