Tender: Suspended tender (e.g. blocked by court order)

[timgdavies]

Discussion of a possible extension to OCDS

From OpenProcurement Ukraine:

We have an intention of adding a new informational field for blocking all the processes related to a given auction. Our proposed name for the field is "blocked", and, in our point of view, it would be simplest for it to have two values - "true" or "false". The rationale behind such a new field is a necessity of blocking the auction in case of a court order prohibiting any further action with the auction and/or contract until further notice.

I believe the underlying issue here is:

• How to indicate when a tender process has been temporarily suspended as a result of a court order (or for some other reason).

There are two main options we could pursue:

(1) Adding an entry to the tenderStatus codelist for use in tender.status

A tender status of 'suspended' could be paired with an extended field tender.statusDetails to describe the nature of the suspension;

This would mean that:

• When the tender became blocked, it would cease to show up in lists of 'active' tenders;
• Applications would need to be aware of the 'suspended' tender status;

tenderStatus is a closed codelist, which means any changes have to be part of an upgrade of the standard, and should not be made by extensions.

(2) Adding a new field via an extension

The suggested field from Open Procurement Ukraine is blocked.

I would suggest suspended as a more general terminology, which can be paired with 'suspendedDetails``` to provide a description of the reason for suspension.

On this approach:

• Applications that are not aware of the suspended field would continue to display the tender in a list of active tenders;
• Applications that are aware of the suspended field could use this to filter views, or display extra information about a contracting process

Questions

Assuming we pursue option (2):

(1) Are there other uses for this kind of field, other than that raised by Open Procurement Ukraine?

(2) Do you have any preference on terminology between 'blocked' or 'suspended' (or another option)?

(3) Should an extension also introduce any 'documentType' codelist entries to link to related reasons for suspension or documentation of the suspension/blocking of the process?

(4) Should guidance include any information on including milestones or other free-text descriptions about suspensions/blocking?

Please also comment if you have a preference for option (1).

[myroslav]

2nd option is more preferable. The only question I'd have is to have suspension reasons codified somehow. Either via suspended field itself or via extra suspendedCode to accompany suspendDetails. Since in informational systems it is normal to have suspendCode and suspendDetails in OCDS exports derive either pogrammatically from Codelists or from dedicated description field filled by human.

suspended is ok, no need to keep blocked around.

Extra documentTypes are yet to be explored, we are in the early days of procedure suspension, we'll see what accompanying documentation there will be, and if there will be need to register it into the system. If court system will gain their own entry to the system with suspension and withdrawal of suspensions, then there are high chances that extra documentation will follow.

[timgdavies]

I would suggest then we work up the extension to add the following to tender:

suspended - a true/false field to indicate that a process has been suspended.
suspendedReason - a array of one or more codes from the open 'suspendedReasons' to indicate the nature of the suspension;
suspendDetails - a free text field to describe the reason for suspension

For this we just need to work out the initial contents of the 'suspendedReason' codelist, which I understand for Ukraine would be:

• courtOrder - A court order has been issued to block progression of this contracting process until further notice.

[ivanka-jakimchuk]

We suggest to add suspendPeriod to tender.
It has been also explored that extra documentation is going to be registered into the ProZorro.Sale system (previously it was mentioned by Myroslav). Hence, we need to add some documentTypes. Now it is for sure that documents with an explanation why system delays occur should be provided. One of our suggestions is x_suspensionProtocol. Is this one correct? Or, perhaps, you will give another variant.

[duncandewhurst]

We suggest to add suspendPeriod to tender.

This sounds appropriate, using the period building block. Using suspendedPeriod would be preferable as it is in-line with the naming convention of the other new properties.

It has been also explored that extra documentation is going to be registered into the ProZorro.Sale system (previously it was mentioned by Myroslav). Hence, we need to add some documentTypes. Now it is for sure that documents with an explanation why system delays occur should be provided. One of our suggestions is x_suspensionProtocol. Is this one correct? Or, perhaps, you will give another variant.

x_suspensionProtocol suggests that the document will describe the process or procedure for suspension, rather the reason for the suspension.

Using suspendedReason instead would be clearer and would be in-line with the name of the associated property.

[sofiiashnyr]

The thing is that we need to have both suspendedReason - with such values as courtOrder (when a procedure is blocked by a court resolution) and dgfComissionOrder (when it is blocked by the decision of Deposit Guarantee Fund commission) allowed - and a new document type, x_suspensionProtocol, as we need to have an official document with the text of the very resolution issued either by the Court or Deposit Guarantee Fund commission in the system allowing us to block the procedure.

[duncandewhurst]

@sofiiashnyr my suggestion was to keep both the property and the documentType but to align the names, so that it is clear that the document provides more information about the values given in the property.

So, bringing together the proposals so far in this thread, the extension would:

1. Add the following properties to the tender section:

• suspended - a true/false field to indicate that a process has been suspended.
• suspendedReasons - a array of one or more codes from the open 'suspendedReasons' codelist to indicate the nature of the suspension;
• suspendedDetails - a free text field to describe the reason for suspension

2. Introduce a suspendedReasons codelist with the following values: courtOrder, dgfCommissionOrder

3. Add x_suspendedReason to the documentType codelist, with the description "An official document with the text of the resolution issued to suspend the process"

If you still feel x_suspendedProtocol is a more appropriate code than x_suspendedProtocol that's OK, since documentType is an open codelist.

Are there any other possible codes for the suspendedReasons codelist?

[sofiiashnyr]

@duncandewhurst,

thank you for the suggestion.

• It does make more sense to have x_suspendedReason as a new document type, so we'll stick to that.

• No, currently a procedure can be blocked only by a courtOrder or dgfCommissionOrder.

[jpmckinney]

Relevant to review procedures in EU forms, UNCITRAL, WTO GPA.

Also, we typically use Rationale not Reason elsewhere in the schema.

[jpmckinney]

Removing 'Use case - Trade' tag, as the EU forms, UNCITRAL, WTO GPA don't go as far as this.

[jpmckinney]

This issue has worked up some requirements around suspensions:

• that there is a suspension
• the period of the suspension
• the reason/rationale for the suspension, as both a code and free-text
• that a document is about a suspension

However, consensus was not reached when the conversation ended in 2017. In #764, we propose adding a statusDetails field to Tender, Award and Contract, which can be used to satisfy these in an unstructured way. If there is renewed engagement, we can re-open the issue and seek consensus on a structured model.