techniques: Add fields about electronic workflows following the structure of BT-92, BT-743, BT-93

[ColinMaudry]

See also https://github.com/open-contracting-extensions/european-union/issues/5#issuecomment-517271339

[ColinMaudry]

The electronicInvoicing field would use the shared permissions code list (allowed, required, notAllowed).

[ColinMaudry]

These fields should go to a Contract terms extension: https://github.com/eForms/eForms/issues/322#issuecomment-517403313

[ColinMaudry]

Reopened until work starts on the Contract terms extension, as a reminder.

[ColinMaudry]

Here is the permission code list. We may need to make the subject more generic than "tenderers", since in some cases the field may apply to the buyer.

Code,Title,Description
required,Required,The tenderers are required to perform the activity.
allowed,Allowed,The tenderers are allowed to perform the activity.
notAllowed,Not allowed,The tenderers are not allowed to perform the activity.

[ColinMaudry]

Here is the schema part:

"hasElectronicPayment": {
          "title": "Electronic payment used",
          "description": "Whether electronic payment is used.",
          "type": [
            "boolean",
            "null"
          ]
      },
      "hasElectronicOrdering": {
          "title": "Electronic ordering used",
          "description": "Whether electronic ordering is used.",
          "type": [
            "boolean",
            "null"
          ]
      },
      "electronicInvoicing": {
          "title": "Electronic invoicing",
          "description": "Whether the buyer will require, allow or not allow electronic invoices.",
          "type": ["string", "null"],
          "openCodelist": false,
          "codelist": "permission.csv",
          "enum": [
            "required",
            "allowed",
            "notAllowed",
            null
          ]
      }

[jpmckinney]

A has* field implies a boolean value, but these are permission levels. I suggest removing the prefix has. Nevermind, I see the fields are indeed boolean!

We can change the code descriptions to "The activity is [required, allowed, not allowed]."

[jpmckinney]

So, first, I misread which fields used permission levels and which were boolean :) (I updated my earlier comment).

However, so far, we have used has* when there is another object that describes the attribute in more detail. Here, we just have a boolean attribute, which elsewhere we don't prefix with has, e.g. successiveReduction. Do you think it's likely that there will be e.g. an electronicPayment object in future? If not, should we remove the has prefix?

[ColinMaudry]

I think

• we shouldn't burn bridges to an electronicPayment or electronicOrdering object, as I can perfectly imagine data about these things. They are not leaf concepts by nature
• the presence or absence of a detailed object shouldn't determine the spelling of the label of the boolean field. Apparently, hasEnquiries is the only boolean field in core OCDS, and it follows this pattern. I think we should stick to it.

[ColinMaudry]

OK to update the code descriptions to "The activity is [code]".

[jpmckinney]

Sounds good, re: has and OK to update code descriptions.

[ColinMaudry]

We have implemented these fields in the contractTerms extension.