Update all status codelists

[jpmckinney]

The 'unsuccessful' code's description is:

This award could not be successfully made. If items or supplier details are included within the award section, then these narrow the scope of the unsuccessful award (i.e. the award of noted items, or an award to the noted supplier, was unsuccessful, but there can be other successful awards for different items listed in the tender, or to different suppliers).

This seems to imply that if the process is unsuccessful, then there would be an award object without suppliers and status set to 'unsuccessful'.

But, https://standard.open-contracting.org/latest/en/guidance/map/unsuccessful_tender/ doesn't mention awards. This seems correct for, e.g., a procedure where all tenderers were excluded because of exclusion grounds or selection criteria.

The OCDS for EU profile uses awards in F03. Since there might be many CANs for the same procedure, and it's unknown whether a later CAN will be successful, this approach makes sense. But, it means all awards could be unsuccessful.

[JachymHercher]

More generally: why isn't there just a single contractingProcess.status field, i.e. what are the use cases for having one in each block? Also, shouldn't there be a planning.status, since there could be an OCDS planning process that would not have Tender (cf #866 (comment)).

eForms have a Not Awarded Reason (BT-144) field that lists various reasons why a process could be unsuccessful. I could imagine classifying the different fields into whether the "unsuccess" happened at the tender, award or contract stage. However, if that is the approach, we should explain it in quite some detail, probably both in the general https://standard.open-contracting.org/latest/en/guidance/map/unsuccessful_tender/ (the name of which shouldn't be just about the tender though) and https://standard.open-contracting.org/latest/en/schema/codelists/#closed-codelists.

[ColinMaudry]

@JachymHercher The idea behind tender.status is have a single field to refer to in order to know how the contracting process went/is going.

The problem is that it doesn't carry enough granularity and one must analyze the data further (awards? contracts? suppliers?) in order to infer accurate insights.

The proposal of Jachym is interesting:

1. renaming tender.status to something like .status (root of Release) or tender.contractingProcessStatus to give a quick summary of the pulse of the contracting process:

• award in progress
• fully awarded
• partially awarded
• ongoing implementation
• delivered, ongoing payment
• cancelled before award
• stalled
• etc.

2. enabling extra granularity by adding status fields to key objects (Planning, Tender, Award, Contract, maybe Lot).

I suggest we first reflect on what questions we would like to ask the data :)

[jpmckinney]

There are multiple status fields, because each object can have a different status. For example, in the same contracting process, one contract might be terminated while another remains active. One award of a lot might be unsuccessful, while another award of another lot is active.

tender.status is just about the pre-award stage(s) - it is not about the procedure as a whole. For example, tender.status can be complete, while there are active contracts.

There is no top-level status because, well, it's not clear what it would express. What do you label a contracting process with a completed pre-award stage, cancelled awards (due to complaints), unsuccessful awards (no qualified bidders), active awards, and a similar mix of contract statuses? We can define use cases, but there is no demand yet. For comparison, OC4IDS has a simple contracting process status codelist, which is just pre-award, active or closed.

There is no planning.status field, because the Planning object is historically under-specified, and we haven't looked toward adding new fields without first clarifying how the object ought to be used. #794 #910

Regarding eForms, in TED R2.0.9, there were just two reasons for non-award, which in OCDS are expressed using the free-text field Award.statusDetails: https://standard.open-contracting.org/profiles/eu/master/en/forms/F03/#V.1

[jpmckinney]

In any case, I agree that non-success ought to be better explained, which is the subject of this issue, viz:

I could imagine classifying the different fields into whether the "unsuccess" happened at the tender, award or contract stage. However, if that is the approach, we should explain it in quite some detail, probably both in the general https://standard.open-contracting.org/latest/en/guidance/map/unsuccessful_tender/ (the name of which shouldn't be just about the tender though) and https://standard.open-contracting.org/latest/en/schema/codelists/#closed-codelists.

[JachymHercher]

Thank you for the clarifications, @jpmckinney and @ColinMaudry, I understand better now, esp. that tender.status, award.status, and contract.status provide information about different phases of the process as well as difference instances of awards and contracts within the process.

Beyond scope for improvement in the documentation and description, I think there might be others problems with 'unsuccessful'
a. it overlaps with 'cancelled' (with the descriptions as they are, I think 'cancelled' implies 'unsuccessful');
b. I'm not sure of a scenario corresponding to award.status = 'unsuccessful';
c. I think there is a scenario for contract.status = 'unsuccessful', but the code does not exist in the codelist;
d. 'unsuccessful' is insufficiently informative, i.e. it combines too many situations in one code (arguably, it might be stranted that the same term describes different situations in tender and contract).

eForms' Not Awarded Reason (BT-144) contains the following codes:

1. No tenders, requests to participate or projects were received
2. Only one admissible tender, request to participate or project was received
3. All tenders, requests to participate or projects were rejected withdrawn or found inadmissible
4. The highest ranked tenderer(s) refused to sign the contract
5. Decision of the buyer, because of insufficient funds
6. Decision of the buyer, because of a change in needs
7. Decision of the buyer, not following a tenderer's request for review, because of technical or procedural errors
8. Decision of the buyer following a tenderer's request for review
9. Decision of a review body or another judicial body
10. Other

Assuming that 'cancelled' is intended to be "unsuccessful because the buyer cancelled it" while unsuccessful is "unsuccessul for any other reason", my impression is that:

• tender.status = 'unsuccessful' corresponds to/has subcodes 1, 2, 3, (10?)
• tender.status = 'cancelled' corresponds to/has subcodes 5, 6, 7, 8, 9 (10?)
• award.status = 'unsuccessful' - I can't think of anything?
• award.status = 'cancelled' corresponds to/has subcodes 5, 6, 7, 8, 9 (10?)
• contract.status = 'unsuccessful' corresponds to/has subcode 4, (10?) - !does not exist!
• contract.status = 'cancelled' corresponds to/has subcode 5, 6 (In other jurisdictions than the EU, where a contract can be cancelled after judicial review even though ti has been signed already, 8 and 9 may perhaps be applicable as well.)

1. What about deprecating 'unsuccessful' and 'cancelled' and replacing them with the more detailed codes above?
2. What about adding them to 'unsuccessful' and 'cancelled' as more detailed codes?
3. Any ideas about what could go into "Other" in the four scenarios?

[ColinMaudry]

a. it overlaps with 'cancelled' (with the descriptions as they are, I think 'cancelled' implies 'unsuccessful');

My understanding is that, in OCDS jargon

• 'cancelled' means that the contract could have been awarded, but some incident made the buyer decide to actively cancel it
• 'unsuccessful' means that none or not enough bids matched the award criteria, or none of the bidding suppliers were eligible (see also b. below)

b. I'm not sure of a scenario corresponding to award.status = 'unsuccessful';

That means that the tendered items (it can be a lot) has not been awarded, e.g. if none of the bids was good enough. In the eForms codes, that would encompass:

1. No tenders, requests to participate or projects were received
2. Only one admissible tender, request to participate or project was received*
3. All tenders, requests to participate or projects were rejected withdrawn or found inadmissible
4. The highest ranked tenderer(s) refused to sign the contract

(maybe more, but these are the ones for which I'm pretty confident)

c. I think there is a scenario for contract.status = 'unsuccessful', but the code does not exist in the codelist;

d. 'unsuccessful' is insufficiently informative, i.e. it combines too many situations in one code (arguably, it might be stranted that the same term describes different situations in tender and contract).

I think I don't have enough experience in procurement to help on these ones :)

[JachymHercher]

b. I'm not sure of a scenario corresponding to award.status = 'unsuccessful';

That means that the tendered items (it can be a lot) has not been awarded, e.g. if none of the bids was good enough. In the eForms codes, that would encompass:

1. No tenders, requests to participate or projects were received
2. Only one admissible tender, request to participate or project was received*
3. All tenders, requests to participate or projects were rejected withdrawn or found inadmissible
4. The highest ranked tenderer(s) refused to sign the contract

I'd put 4. only in contract.status - it is a post-award failure.

We can decide that 1 & 2 & 3 belong in tender.status or award.status, but they shouldn't be in both. So if we say they belong in award.status then my question is what belongs into tender.status.

[jpmckinney]

That means that the tendered items (it can be a lot) has not been awarded

Since we mentioned lots (from the Lots extension): each lot has a status field, which uses the tender.status codelist. So, it is not necessary to create an award related to a lot in order to describe the status of the lot.

---

Taking a step back, I believe contract.status = 'cancelled' exists because contract.status = 'pending' exists, and the latter needs statuses to transition to. To be honest, I'm not sure what information could be on a pending contract object that can't be on an award object. In principle, I see no issue with modelling this information on the award. However, the only way to remove 'cancelled' is to also remove 'pending'. Contract is defined as "Information regarding the signed contract between the buyer and supplier(s).", so it's unexpected that the contract could have a status that means it is unsigned. I'll investigate how publishers are using 'pending' and 'cancelled' on contract objects.

---

I think the reasons provided by eForms are a good way to think through the scenarios. Other governments sometimes have very long lists of possible reasons for cancelling procedures, but I think they all fall within one of the existing codes.

Going over it again:

(1) No tenders, requests to participate or projects were received
(2) Only one admissible tender, request to participate or project was received
(3) All tenders, requests to participate or projects were rejected, withdrawn or found inadmissible

Yes, these would be tender.status = 'unsuccessful' ("The tender process was unsuccessful.")

(4) The highest ranked tenderer(s) refused to sign the contract

I think this can be award.status = 'unsuccessful', but we'd probably want to clean up contract.status as outlined above.

(5) Decision of the buyer, because of insufficient funds
(6) Decision of the buyer, because of a change in needs

@JachymHercher You put these as 'cancelled' under tender.status, award.status, and contract.status. Is that because the buyer can make this decision at the times below?

• before deciding the supplier ("entity with which a buyer or a procuring entity decided to conclude a contract" Supplier - definition ("awarded or contracted") #1149)
• after deciding the supplier, but before contract signature
• after contract signature

(7) Decision of the buyer, not following a tenderer's request for review, because of technical or procedural errors
(8) Decision of the buyer following a tenderer's request for review

@JachymHercher You put these as 'cancelled' under tender.status and award.status. You also put 8 under contract.status if "a contract can be cancelled after judicial review even though ti has been signed already". Is that because the buyer can make this decision at the times above?

(9) Decision of a review body or another judicial body

@JachymHercher You put this as 'cancelled' under tender.status. You also put it under contract.status if "a contract can be cancelled after judicial review even though ti has been signed already". Why at these times, and only at these times? (Why can't this decision come after deciding the supplier, but before contract signature?)

---

This discussion suggests to me that it might be advisable to remove 'pending' and 'unsuccessful' from contractStatus, and for contract objects to only exist if there is a signed contract. That contract can still be 'cancelled' (e.g. after judicial review). If that proposal doesn't achieve consensus, we'll just need to be clear when to use contract.status = 'unsuccessful' versus award.status = 'unsuccessful'.

---

What about deprecating 'unsuccessful' and 'cancelled' and replacing them with the more detailed codes above?
What about adding them to 'unsuccessful' and 'cancelled' as more detailed codes?

We don't currently have the evidence to propose new codes that work across jurisdictions. If we collect that evidence, we can propose new codes – and then decide whether to deprecate old codes. This would be a separate issue.

Any ideas about what could go into "Other" in the four scenarios?

No, and I'm ignoring it for this discussion, since it has no semantics.

[jpmckinney]

Another good next step would be to ask OCDS Helpdesk analysts to describe how implementers have used these codes.

[JachymHercher]

I've started replying to the questions, but I think it ultimately all boils down to where stages/phases start and finish. (If this doesn't help enough, I'll reply to the individual questions.)

My perception:

• Planning: from an idea to publishing a "call for competition" (i.e. a notice with enough information to be followed by a bid)
• Tender: from [end of last phase +1 second] to the bid submission deadline passing
• Award: from [end of last phase +1 second] to the award, i.e. the buyer having made a decision (i.e. the officer with formal power stamps the evaluation report).
• Contract: from [end of last phase +1 second] to the termination of the contract.

1. Looking at your and Colin's comments, it seems we have the end of the award phase at different places (for you it's [signature of contract -1 second]?) and I'm not sure whether we have the start of award at the same place either. For example, the following are within the contract stage for me:

   • informing the tenderers / the public about the award (I'm the least sure about this one, but I have a tendency not to finish the award phase here because I'm not sure how formal/traceable this communication is and whether the two can happen in any order).
   • "drafting and mailing the unsigned contract", because it concerns the contract
   • "failing to get the contract signed", because it concerns the contract

   However, the thresholds do seem somewhat arbitrary and since OCDS does not collect any data on the three examples above, as far as I'm aware, I'm not sure what implications the end of the award stage / beginning of the contract stage has beyond the status fields.

2. I'm not sure whether there is a place in the schema/guidance which clarifies this? I think my perception above is in line with https://standard.open-contracting.org/latest/en/getting_started/contracting_process/, but I think that so is yours, as the definitions are not that precise.

[jpmckinney]

Yes, I think we need to establish those boundaries between stages to resolve this issue: that is, to be able to describe which events cause a given stage to be unsuccessful.

First, a simpler way to resolve the semantic conflict I described earlier is to change the description of the Contract object ("Information regarding the signed contract between the buyer and supplier(s)") to allow for unsigned contracts.

Also, I think the questions for which I tagged you (@JachymHercher) are not too closely tied to specifying the boundaries, but are rather for me to understand in what scenarios a process is cancelled.

Now, the boundaries. To summarize my longer comments below, I suggest:

• The planning stage ends before the first action "aimed at concluding one or more contracts" (Clarify definition of contracting process #866), which might be the publication of a contract notice, the reservation of the necessary budget, or similar.
• The tender stage ends either with the bid submission deadline or after qualification criteria are applied (though it's not clear either of these align with OCDS 1.1).
• The award stage ends with communication of the award decision, addressed to however many parties (tenderers, public, etc.).

The longer version:

Planning/Tender

• In Clarify definition of contracting process #866, it's proposed that the planning stage is only disclosed in a contracting planning process, and the other stages are only disclosed in a contracting process. The boundary, then, is the first action "aimed at concluding one or more contracts" (Clarify definition of contracting process #866). This can be different from the notice's publication. For example, the buyer might first need to reserve the budget (see second diagram here). That activity would fall on the "tender" side of the boundary.

Tender/Award

• This is trickier. If the tender stage ends at the submission deadline, then the tender stage can only be unsuccessful if "(1) No tenders, requests to participate or projects were received" (though I think we could argue that this evaluative action goes on the award side). It had been proposed that the following would also be modelled as unsuccessful at the tender stage: "(2) Only one admissible tender, request to participate or project was received" and "(3) All tenders, requests to participate or projects were rejected, withdrawn or found inadmissible". However, these occur after the submission deadline. @JachymHercher In your opinion, which side should they fall on?
• If they fall on the award side, then the tender stage can never be unsuccessful (it can still be cancelled). In principle, the tender stage can only be unsuccessful if it fails to yield candidates for evaluation, but if that assessment is on the award side, the tender stage always either completes or is cancelled.
• For them to fall on the tender side, then the tender stage would have to end after the qualification criteria are applied. In a two-stage procedure, where tenderers are qualified, invited to bid, and then evaluated, it make sense for events up to the bid deadline to be part of the tender stage. In single-stage procedures, buyers might assess qualification and evaluation criteria at once for administrative efficiency [citation needed], but for the purpose of standardization, reasons (1), (2) and (3) above would still be reported in the tender.status field.
• A wrinkle, as pointed out in tender.status incomplete list of values (during the period where the tenderPeriod end date already passed and the tender is not yet awarded) #919, is that the Tender object is defined as "Data regarding tender process - publicly inviting prospective contractors to submit bids for evaluation and selecting a winner or winners.". This would imply that a tender is only 'complete' after the award stage. This creates a semantic overlap, which is undesirable.
• Note: The tender field is defined as "The activities undertaken in order to enter into a contract.", but I think we can ignore this, because it conflicts with the fact that the awards and contracts fields also describe such activities.

Award/Contract

• Counter what I wrote in my previous comment, I think it is appropriate for the award stage to center on the award decision, and to not get caught up in the mechanics of concluding the contract (signatures, etc.).
• I believe informing the tenderers/public is more coherent within the award stage than in the contract stage, because it is more about communicating the award decision than it is about concluding contracts.
• I agree there seems to be no way for an award to be unsuccessful (though it can be cancelled). If this stage only begins after pre-qualification, then the award decision is entirely within the control of the buyer or procuring entity.
• The description of the 'unsuccessful' code is not helpful, as it doesn't describe the conditions in which an award is unsuccessful, but merely describes how to indicate the items or suppliers involved in that unsuccessful award. Its origin in Tracking unsuccessful tenders #143 adds no relevant detail.

This award could not be successfully made. If items or supplier details are included within the award section, then these narrow the scope of the unsuccessful award (i.e. the award of noted items, or an award to the noted supplier, was unsuccessful, but there can be other successful awards for different items listed in the tender, or to different suppliers).

Given that it mentions suppliers, I assume the idea was that an award could be initiated to a supplier, and then somehow not succeed (e.g. the supplier doesn't sign the contract). There's no code in contractStatus for this scenario, so perhaps this is the use case for 'unsuccessful'. However, contractStatus does have other codes prior to signature ('pending' "This contract has been proposed, but is not yet in force. It might be awaiting signature." and 'cancelled' "This contract has been cancelled prior to being signed."), so this code does belong in the contractStatus codelist instead.

It also seems to suggest that an unsuccessful award could specify items without specifying suppliers. In that case, the interpretation would be that those items were not awarded to any supplier. This is really about lots, but in OCDS 1.0 there were no lots. So, in this interpretation, the 'unsuccessful' code was a workaround that now overlaps with tender.lots.status in the Lots extension. (See also #891 about merging the Lots extension into OCDS.)

[JachymHercher]

First, a simpler way to resolve the semantic conflict I described earlier is to change the description of the Contract object ("Information regarding the signed contract between the buyer and supplier(s)") to allow for unsigned contracts.

I agree, I've noted it in #896 (comment) and will update the definition once we're done here.

The tender stage ends either with the bid submission deadline or after qualification criteria are applied (though it's not clear either of these align with OCDS 1.1).

I think the bid submission deadline is more useful. Mainly because, at least in the EU, in an open procedure, you can choose whether you first evaluate the qualification criteria or the award criteria (a very useful provision, the reasoning being that if you know a bid is too expensive to win, then don't waste time checking the tenderer's credentials), so using it as a threshold would be quite fuzzy; also I think it makes sense to bundle the evaluation of qualification and award criteria together, because they are quite similar; and also the bid submission deadline is a more important, official and public piece of information.

I believe informing the tenderers/public is more coherent within the award stage than in the contract stage, because it is more about communicating the award decision than it is about concluding contracts.

In principle I would like it, but I get worried about the details. If, after an award, the buyer first informs the tenderers (e.g. in their eproc system or by email), waits a week, and then informs the general public, where does the award stage end?

• If it ends with the "first communication of the award outside to the tenderers or the public", then informing the tenderers and the public will be in different stages.
• if it ends with some sort of "last communication", then the award and contract stages will be overlapping (because I might start working on getting the contract signed before I finish communicating). Furthermore, "last communication" might be hard to define (e.g. contract award notices in the EU, which are in fact about signed contracts, should probably be excluded).

Ending with the award decision has the advantage of being very clear and official.

This is trickier. If the tender stage ends at the submission deadline, then the tender stage can only be unsuccessful if "(1) No tenders, requests to participate or projects were received" (though I think we could argue that this evaluative action goes on the award side). It had been proposed that the following would also be modelled as unsuccessful at the tender stage: "(2) Only one admissible tender, request to participate or project was received" and "(3) All tenders, requests to participate or projects were rejected, withdrawn or found inadmissible". However, these occur after the submission deadline. @JachymHercher In your opinion, which side should they fall on?

I originally proposed them as tender.status, but you are right, since they require evaluating admissibility, and since I think evaluation should be in award, then they need to in the award.status. Fine by me.

(I would then put "The highest ranked tenderer(s) refused to sign the contract" in contract.status).

A wrinkle, as pointed out in #919, is that the Tender object is defined as "Data regarding tender process - publicly inviting prospective contractors to submit bids for evaluation and selecting a winner or winners.". This would imply that a tender is only 'complete' after the award stage. This creates a semantic overlap, which is undesirable.

Note: The tender field is defined as "The activities undertaken in order to enter into a contract.", but I think we can ignore this, because it conflicts with the fact that the awards and contracts fields also describe such activities.

Updating the description of tender a bit doesn't sound like a bad idea to me.

---

Also, I think the questions for which I tagged you (@JachymHercher) are not too closely tied to specifying the boundaries, but are rather for me to understand in what scenarios a process is cancelled.

(5) Decision of the buyer, because of insufficient funds
(6) Decision of the buyer, because of a change in needs

@JachymHercher You put these as 'cancelled' under tender.status, award.status, and contract.status. Is that because the buyer can make this decision at the times below?

before deciding the supplier ("entity with which a buyer or a procuring entity decided to conclude a contract" #1149)
after deciding the supplier, but before contract signature
after contract signature

"Yes", or rather before the bid submission deadline; after the bid submission deadline and before contract signature; after contract signature (e.g. I cancel the contract and pay the penalty).

(7) Decision of the buyer, not following a tenderer's request for review, because of technical or procedural errors
(8) Decision of the buyer following a tenderer's request for review

@JachymHercher You put these as 'cancelled' under tender.status and award.status. You also put 8 under contract.status if "a contract can be cancelled after judicial review even though ti has been signed already". Is that because the buyer can make this decision at the times above?

Same as above. On second look though, I guess (7) could apply also to contract.status.

(9) Decision of a review body or another judicial body

@JachymHercher You put this as 'cancelled' under tender.status. You also put it under contract.status if "a contract can be cancelled after judicial review even though ti has been signed already". Why at these times, and only at these times? (Why can't this decision come after deciding the supplier, but before contract signature?)

Sorry, my bad, this should have indeed been also for award.status (that's actually the most pertinent place for it to be). Distinction same as above.

[JachymHercher]

Here is the list of action points based on this issue so far:

1. Contract definition covers also unsigned contracts - done.
2. Decide where the tender and award stages end. I think they should end with bid submission and the award decision, respectively.
3. I would suggest: update the definitions of Planning, Tender, Awards and Contracts as well as the corresponding values in https://standard.open-contracting.org/latest/en/schema/codelists/#release-tag so that they take into account the start and end points of each stage and thus avoid overlaps. We can also standardize the wording.
4. Once we agree the above, double-check that 'unsuccessful', 'cancelled' (and maybe 'pending') exist in (and only in) the status codelists for the stages where they make sense. I would suggest changing the descriptions, possibly by adding the examples used in eForms.
5. Explain all this in the documentation. Where stages start and finish should probably be part of Getting Started, un-successful procedures part of https://standard.open-contracting.org/latest/en/guidance/map/unsuccessful_tender/.
6. In https://standard.open-contracting.org/latest/en/schema/codelists/#document-type, 'evaluationReports' are classified as belonging into tender, but according to our discussion above they should belong to award. We should change it.
7. Update docs/primer/how.md based on this issue

Note: All but 4) is moved to #1385; 5) and 7) concerns both this issue and #1385.

[ColinMaudry]

@JachymHercher Great summary, thanks!

[duncandewhurst]

I believe informing the tenderers/public is more coherent within the award stage than in the contract stage, because it is more about communicating the award decision than it is about concluding contracts.

In principle I would like it, but I get worried about the details. If, after an award, the buyer first informs the tenderers (e.g. in their eproc system or by email), waits a week, and then informs the general public, where does the award stage end?

* If it ends with the "first communication of the award outside to the tenderers or the public", then informing the tenderers and the public will be in different stages.

* if it ends with some sort of "last communication", then the award and contract stages will be overlapping (because I might start working on getting the contract signed before I finish communicating). Furthermore, "last communication" might be hard to define (e.g. contract award notices in the EU, which are in fact about signed contracts, should probably be excluded).

Ending with the award decision has the advantage of being very clear and official.

Currently, the standstill period (see #1142) is part of the award stage. Is the proposal for the standstill period to instead be part of the contract stage, and thus remove the 'pending' code from the award status codelist?

[JachymHercher]

If we decided that tender and award stages end with bid submission and the award decision, respectively, then indeed the standstill period would be part of the contract stage. This would require changing the description of 'pending' in the award status codelist, as that currently in effect only covers the standstill period. I wouldn't remove the code as such though - I think it should be used to inform about any award for which tenders were already submitted, but no decision was issued yet (e.g. under evaluation).

"The end of the standstill period" might be an even better candidate for the end of the award stage though. It avoids my main objections to ending the award stage with "informing the tenderers/public" (proposed in #1160 (comment)) because the end of the standstill period is neither ambiguous nor informal. Furthermore, by definition, it precedes the conclusion of the contract. The only thing I have no clue about is how much remedies apply outside the EU (I gather they are part of UNCITRAL, but I think they are not part of GPA). However, maybe that isn't a problem, as the definition could be ~"end of the standstill period, if there is none, then the award decision". (If we went this way, then the standstill period would be part of the award stage, but we should still broaden the definition of the 'pending' award status.)

[jpmckinney]

@JachymHercher Sounds good!

[JachymHercher]

@jpmckinney moved this to #1385

[jpmckinney]

ACTION ITEM: Update docs/primer/how.md based on this issue (e.g. #1160 (comment)). Added to linked comment

[JachymHercher]

In my comment above, I've clarified that bid submission falls into the tender stage and not the award stage, as discussed above. Furthermore, I've added alternative wordings and clearer identification of which blocks, fields and codes should change. The comment now covers answers to questions 1-3 in #1160 (comment).

[JachymHercher]

The changes proposed to the [block]Status codelists are listed in the table below. I've introduced the changes discussed above (update cancelled/unsuccessful), standardized the wording and added examples from the eForms' codelist. Furthermore, I suggest the following changes not discussed above:

1. Remove 'planning' from tender.status. As far as I can see, this code only duplicates releaseTag code 'planning'. This seems even more glaring once we split planning processes and contracting processes. The code 'planning' in tender.status only makes sense in a planning process, where there is always a releaseTag 'planning'. Essentially, this means that planning processes don't go through any statuses, which I think makes sense.
2. Add 'complete' to awardStatus. I'm assuming that the "basic" lifecycle for each stage should be 'active' --> 'complete', but awardStatus does not have 'complete' nor its equivalent (contractStatus has 'terminated*').
3. 'Withdrawn' should be added to awardStatus and contractStatus, because information can stop flowing at any point in time and also for only individual awards / contracts.
4. I would have a tendency to drop 'pending' from both awardStatus and contractStatus. I'm assuming its main goal is to distinguish releases where an award has already been made or a contract already signed, but this information is clear from dateSigned and awardDate. The same argument could probably also be made against 'planned', 'active', 'complete' though, which would then lead to status changing into "reasons for failure"...?

Code	Description in tenderStatus	Description in awardStatus	Description in contractStatus
planning	A future contracting process is being considered. Early information about the process can be provided in the tender section. A process with this status might provide information on early engagement or consultation opportunities, during which the details of a subsequent tender can be shaped.
planned	A The contracting process is scheduled, but is not yet taking place. Details of the anticipated dates can be provided in the tender block.
active	A tender process is currently taking place. The procurement documents have been published and the bid submission deadline has not yet passed.	This award has been made, and is currently in force. The bid submission deadline has passed, but the award has not yet been made or the standstill period, if any, has not yet ended.	This contract has been signed by all the parties, and is now legally in force. The award has been made and the standstill period, if any, has ended. The contract has not yet terminated.
complete	The tender process is complete. The bid submission deadline has passed.	The award has been made and the standstill period, if any, has ended.
cancelled	The tender process has been cancelled. The contracting process has been cancelled by the buyer or the procuring entity (e.g. because of a change in needs, insufficient funds, or technical or procedural errors) after the procurement documents have been published, but before EDIT: not later than the bid submission deadline.	The award has been cancelled by the buyer or the procuring entity (e.g. because of a change in needs, insufficient funds, or technical or procedural errors) after the bid submission deadline passed, but before the award has been made or before the standstill period, if any, has ended.	This contract has been cancelled prior to being signed. The contracting process has been cancelled by the buyer or the procuring entity (e.g. because of a change in needs, insufficient funds, or technical or procedural errors) after the award has been made and the standstill period, if any, has ended.
unsuccessful	The tender contracting process was unsuccessful failed after the procurement documents have been published, but before EDIT: not later than the bid submission deadline passed (e.g. no bids were received, all bids were withdrawn by the bidders, all bids were rejected by the buyer or the procuring entity).	This award could not be successfully made. If items or supplier details are included within the award section, then these narrow the scope of the unsuccessful award (i.e. the award of noted items, or an award to the noted supplier, was unsuccessful, but there can be other successful awards for different items listed in the tender, or to different suppliers). The award failed (e.g. a review body cancelled the process during the standstill period) after the bid submission deadline passed, but before the award had even been made or before the standstill period ended.	The contract failed (e.g. the winning bidder(s) refused to sign the contract) after the award had been made and the standstill period, if any, had ended, but before the contract was signed and in force.
terminated	--	--	This The contract was signed and in force, and has now come to a close. This might be due to the successful completion of the contract, or might be early termination due to some non-completion.
terminatedEarly	--	--	This The contract was signed and in force, and is terminated early due to some non-completion.
terminatedSuccessfully	--	--	This The contract was signed and in force, and is terminated due to its successful completion.
withdrawn	No further information on this contracting process is available under this ocid.	No further information on this award is available under this ocid.	No further information on this contract is available under this ocid.
pending	--	This award has been proposed, but is not yet in force. This can be due to a cooling off period, or some other process.	This contract has been proposed, but is not yet in force. It might be awaiting signature.

Note: the descriptions repeat the important moments (e.g. bid submission deadline passed) of a contracting process. We could avoid this by saying "the end of the stager stage", "the award stage", etc., but then readers would have to look for what it means. I think in this case, repetition might be better.

Note2: The use of past tenses needs a native / grammar obsessed proofreader :).

The proposal above covers (above and beyond) point 4) from #1160 (comment). Before going further (preparing a PR / drafting the guidance), it would be great to get the views of @jpmckinney (and/or others) - it's a lot of changes.

[yolile]

Sounds good. I'm just double-checking how some use cases will work. Of course, we will need to update some worked examples, red flags and indicators calculation, etc., but we will need to do that for other improvements anyway.

[jpmckinney]

Split to #1582

[duncandewhurst]

@jpmckinney please can you confirm that I've understood what needs to be done from the proposal in #1160 (comment):

1. Update the descriptions of codes in the codelists (keeping semantics consistent with OCDS 1.1)

2. Deprecate the status fields and the codes in status codelists

In #1509:

• Resolve merge conflicts
• Remove the new codes added to tenderStatus.csv, awardStatus.csv and contractStatus.csv
• Request a review of the changes made since the last review and address any feedback.

3. Create a new field for "end state" codes, and add the codes that were added in this PR to those codelists. (We can eliminate the contract 'terminated' code and only keep its sub-codes.)

• Add finalStatus to Tender, Award and Contract and create tenderFinalStatus.csv, awardFinalStatus.csv and contractFinalStatus.csv codelists with the new codes added to tenderStatus.csv, awardStatus.csv and contractStatus.csv in tenderStatus, awardStatus contractStatus: update codes #1509. [done in release-schema: Add finalStatus to tender, award and contract. Clarify tender.datePublished. #1648]

4. Clarify the description of the `tender/datePublished` field

• Decide whether this is the date the contracting documents were published or the date that the tender notice was published and update the description. Based on the use case for the field described in Add tender.datePublished field #892 (to be able to compute some indicators that will say how many days a potential bidder has to prepare an offer) I think that it should be the former since a bidder can't prepare an offer without the tender documents. [done in release-schema: Add finalStatus to tender, award and contract. Clarify tender.datePublished. #1648]

5. Create an issue about `tender/tenderPeriod` (and the need for a second field for submission for bids vs. requests to participate)

• Create an issue based on the following comment:

We might need to review the definition of tender/tenderPeriod. In a two-stage process, I think this is usually the deadline for requests to participate (first stage). However, in terms of 'active', I think the relevant deadline is the one for bids (second stage). This second deadline is not actually published in any field, so maybe it's not possible to determine the tender status without a status code.

[jpmckinney]

I've resolved the merge conflicts.

Remove the new codes added to tenderStatus.csv, awardStatus.csv and contractStatus.csv

I think Jáchym did that in 469e540

The rest sounds good!

[duncandewhurst]

@jpmckinney should I make all the changes in #1160 (comment) as part of #1509 or should I create separate PRs for points 3 and 4?

[jpmckinney]

Let's do it all at once. It'll make it easier to track the closing conditions for this issue.

[jpmckinney]

Oh, wait, I realize we already have #1509 open, and should probably close it as it's already long (otherwise it'll get too confusing). So, yes, keep #1648 separate. It can contain the rest of the changes.

[jpmckinney]

If we're adding a finalStatus field with codes for each end state, then there is no elsewhere, – it's "right here", no?

The additional details would be the more specific reason (insufficient funds, etc.), like finalStatusDetails.

[duncandewhurst]

I didn't mean for #1509 to close this issue. It'll be closed by #1648.

[jpmckinney]

What about statusDetails? Do we want to add a finalStatusDetails too?

We can have a finalStatusDetails. I hadn't thought of what to do with statusDetails. Do you know how that field is currently being used?

statusDetails is new to OCDS 1.2, but it existed as an extension previously: https://gitlab.com/dncp-opendata/ocds_statusdetails_extension

For 1.2, we need to rename it to finalStatusDetails, to avoid having inconsistent semantics with that extension.

[duncandewhurst]

For 1.2, we need to rename it to finalStatusDetails, to avoid having inconsistent semantics with that extension.

Done in #1648