communication: Access to the procurement documents is restricted

[jpmckinney]

In the EU profile, we modelled this as:

Add a ParticipationFee object to the tender.participationFees array, set its .type to ‘document’, and set its .id to ‘1’.

In other words, as a participation fee without further details.

However, the restriction might not involved a fee; it might require a login (viz. atypicalToolUrl in the extension), or the buyer or procuring entity might only send the documents to qualified suppliers (see open-contracting/standard#1469).

So, we should consider a different model, which likely requires a new field in the communication extension.

[jpmckinney]

See CRM-6000 and open-contracting-extensions/european-union#86

[duncandewhurst]

Context

There are three eForms business terms relevant to this issue.

Business term	Title	Description	XPath*	Notes
BT-14	Documents Restricted	The access to certain procurement documents is restricted.	/cbc:DocumentType	Effectively a boolean flag
BT-707	Documents Restricted Justification	The justification for restricting access to certain procurement documents.	/cbc:DocumentTypeCode	Value from communication justification codelist
BT-615	Documents Restricted URL	The internet address with information on accessing the restricted (part of the) procurement documents.	/cac:Attachment/cac:ExternalReference/cbc:URI

*Context: /*/cac:ProcurementProjectLot[cbc:ID/@schemeName='Lot']/cac:TenderingTerms/cac:CallForTendersDocumentReference

Example

<cac:CallForTendersDocumentReference>
    <cbc:ID>20210521/CTFD/ENG/7654-02</cbc:ID>
    <cbc:DocumentTypeCode listName="communication-justification">ipr-iss</cbc:DocumentTypeCode>
    <cbc:DocumentType>restricted-document</cbc:DocumentType>
    <cbc:LanguageID>ENG</cbc:LanguageID>
    <cbc:DocumentStatusCode listName="linguistic-status">official</cbc:DocumentStatusCode>
    <cac:Attachment>
        <cac:ExternalReference>
            <cbc:URI>https://mywebsite.com/proc/2019024/accessinfo</cbc:URI>
        </cac:ExternalReference>
    </cac:Attachment>
</cac:CallForTendersDocumentReference>

Modelling

In keeping with the mapping of BT-15 (Documents URL), BT-708 (Documents Official Language) and BT-737 Documents Unofficial Language, which all map to tender.documents, I think that it would make sense to map this as follows:

• Model as a document in tender.documents of type 'biddingDocuments'
• Map BT-14 and BT-707 to .accessDetails from the document details extension
• Map BT-615 to .accessDetailsURL (new field in document details extension)
• Use Document.relatedLots to relate documents to lots.

Example

{
  "tender": {
    "documents": [
      {
        "id": "20210521/CTFD/ENG/7654-02",
        "documentType": "biddingDocuments",
        "accessDetails": "Restricted. Intellectual property right issues",
        "accessDetailsURL": "https://mywebsite.com/proc/2019024/accessinfo",
        "relatedLots": ["LOT-0001"]
      }
    ]
  }
}

The semantics of Document.url are fairly loose ("A web address for accessing the document.") so an alternative to adding .accessDetailsURL could be to map BT-615 to .url. However, based on the description of BT-615, I think it might be possible in eForms to have separate URLs for the unrestricted and restricted parts of the procurement documents (I'm unsure whether the /<cac:Attachment> element is repeatable).

@jpmckinney it sounds like you were thinking of a different approach (adding fields to the communications extension) - happy to hear your suggestions.

[jpmckinney]

I think the communications extension idea was for the old TED schema - which didn't describe individual documents. But we don't need to solve that here, as no one is implementing that anymore.

Mapping looks good. I think we don't re-use url, since perhaps there could be a registration link in accessDetailsURL and then a direct link in url (which only works for authenticated users).

If we were to design from scratch, we might have done accessDetails.description and accessDetails.url, but I think it's fine as proposed.

[odscjen]

These mappings have now been updated in guidance.yaml. @duncandewhurst I've added the new field to the eforms additional fields mapping spreadsheet but I'm not sure how to get it to show up in the "Summary by extension" sheet?

[duncandewhurst]

Thanks! The range of the pivot table needed updating. That's done now and done in such a way that any future additions will appear automatically.

[odscjen]

closing this now as all that's left is the extension update tracked elsewhere