Supporting documentation for a contracting process as a whole

[portaledcahn]

Hi community,

Currently the data of the purchases made to attend the COVID-19 emergency are published monthly with all the contracting processes in an Excel file and the supporting documentation is included as a link to a pdf file that could have all the supporting documents for these processes (For example: Quotes, Contracts, Purchase Orders, Bidders and quotes).

Initially we are including this field as a document in "tender" using documentType: supportingDocumentation. Could this code be considered to be included in the document type code list?

Additionally, the file has a field that contains a "Link to the contract" that we are including as a document in "contract" using documentType: contractLink. Is it okay to use this code or should we use contractSigned directly?

[aguilerapy]

Hello! Thanks for opening an issue to comment on this case.

The 'supportingDocumentation' code refers to the fact that it is a document that can change its content as the contracting process progresses. So instead of using documentType in the document section of each specific stage, we can add a top-level field, similar to relatedProcesses, named links. The relationship field would have a different codelist. The 'alternate' code means that the linked resource is an alternative representation of this contracting process. Here is a related issue.

And regarding the value 'contractLink', it is possible to use 'contractSigned' instead.

[portaledcahn]

Hi @aguilerapy,

Ok, using links sounds good to include supporting documentation, we will start working on the extension mentioned in related issue

Greetings.

[jpmckinney]

As I understand, this PDF file contains information that spans multiple stages, e.g. bidders from the tender stage, contracts and purchase orders from the contracts stage, etc.

In OCDS, all the documents arrays are in specific stages, so this PDF file doesn't fit in any of them. If there were a top-level documents array, it would fit there.

In #928, the idea would be that the linked document is an alternative representation of the entire procedure.

If that is not the correct semantics, then there should instead be a new top-level documents array.

[duncandewhurst]

It seems clear to me that the original question is about supporting documents (e.g. Quotes, Contracts, Purchase Orders etc.) rather than an alternative representation of the contracting process.

Is any further discussion or input required before preparing a PR to add a top-level documents array?

[jpmckinney]

The main risk with a top-level documents array is that publishers start using it for documents anytime they can't figure out which section to put a document in. I think it is fairly rare for a document to cover multiple stages (from tender to contract). In those rare cases, we might advise on the use of an extension to add that top-level documents array – so that its use is more deliberate. So far this has only come up from one partner, so I think we can close until we see more evidence.

[duncandewhurst]

Closing per the previous comment.