Add a class for natural persons #883
Comments
jpmckinney
added
Schema
|
Hey! As you can see we are indicating business function for each disclosed person. The structure description is following:
More details here |
|
Very useful, thank you! I will review that extension when I have a chance. For now, I think |
|
In the context of design contests, we should be able to add jury members to the |
|
We're drafting a new extension for transactions and the inclusion of |
|
Example of award committee member data from Taiwan, which includes the following fields for each member:
|
|
I agree with the proposal. The list of information for disclosure upon request from the CoST IDS includes "Project officials and roles" which CoST describes as "Name and position of the highest authority in the procuring entity where the budget for this project is allocated (project owner)" OC4IDS reuses the parties/organization model from OCDS and includes the following related guidance, which was authored before the proposal in this issue:
In open-contracting/infrastructure#220 we're working on improving this guidance and adding new fields, so it would be good to decide on a model and property names (for at least name and position/job title) for consistency between the standards. |
|
This issue is presently scheduled for 1.3/2.0, as it's a fairly fundamental question (though not in high demand) that I estimate is too large for the 1.2 release (which is already trying to close 80 less contentious / less complicated issues). With respect to OC4IDS, Schema.org just puts |
|
Just noting that the development of the TransactionDetails Extension (CRM: #5917) potentially demonstrates a demand for this, as it wishes to model natural persons as an |
|
For context, some info on how the EU deals with this: The eForms act defines that "'Organisation’ refers to a legal or natural person or a public entity." Furthermore, organisation BT-633 (Organisation Natural Person) allows marking organisations that are natural persons. The idea is that the organisation block can be used to inform about people, even if some of the fields will not be used. We expect to see two main type of natural persons in the data: sole proprietors and beneficial owners (additionally, some organisations requesting review could also plausibly be natural persons). Beyond policy, an additional added value of knowing that an organisation is a natural person might be linked to GDPR (e.g. organisation names that are also names of natural persons might have different policies for removal). In eInvoicing, the definition of organisation is based on ISO 6523. The organisation under this standard also covers sole proprietors. |
|
@JachymHercher Sole proprietors make sense, and is an exception we carve out in OCDS ("sole traders" above). In eForms, I only see the following in BG-4 Winner, which wouldn't result in BG-703 Organisation being used for a beneficial owner.
|
|
BT-706 and BT-746 are used for minimalistic reporting (just the nationality). Publishers that want to publish more can do so by publishing BG-703 and choosing the 'ben-own' code in https://op.europa.eu/en/web/eu-vocabularies/at-concept-scheme/-/resource/authority/organisation-role. |
|
In our recent work on bringing invoice data into OCDS, there were a couple
of potential uses for naturalised persons that came up and so I also
support the proposal.
In line with the CoST data, there's a need for data on authorisation, but
also for the officer executing the payment.
This is particularly valuable for combatting invoice fraud and for
monitoring separation of duties within finance teams. There may be a need
to anonymise records at the point of publication, but the roles of both
approver and executor should be able to be recorded at different times in
the procurement process.
Best,
Ian
…On Sun, Jan 10, 2021 at 14:48:48, JachymHercher ***@***.***> wrote:
BT-706 and BT-746 are used for minimalistic reporting (just the
nationality). Publishers that want to publish more can do so by publishing
BG-703 and choosing the 'ben-own' code in https://op.europa.eu/en/web/
eu-vocabularies/at-concept-scheme/-/resource/authority/organisation-role.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#883 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB6SOOD457P2LI5NUN4KCALSZG45BANCNFSM4HZ4JJEA>
.
|
|
Very practically, eForms BT-633 (mentioned by @JachymHercher) is indeed a boolean field that tags an organization that is part of a procedure as a person instead of an organization. A common use case is, I believe, when a tenderer is a self-employed individual (like me!). Until OCDS distinguishes people-parties from organizations-parties, I recommend implementers to discard this boolean when mapping eForms to OCDS. |
|
A use case for natural persons in the parties array (besides sole traders): For some Indian public sector companies' procurement processes, Independent External Monitors (IEM) are appointed for transparency and dispute resolution. IEMs will have access to all the documents/records pertaining to the contract for which a complaint or issue is raised before them, except the documents having national security implications. The IEMs will examine all complaints received by them and give their recommendations to the chief executive of the organisation. In case of suspicion of serious irregularities requiring legal or administrative action, they are supposed to send a report to the Chief Vigilance Officers (CVOs) CivicDataLab (India) want to capture the name and designation of the IEM. Example: However, the role of the IEM lasts till the contracting process is concluded. This leaves the parties array as the logical home for the Independent natural person to be mentioned. |
|
Paraguay DNCP now wants to publish information about the legal representatives of each company. The legal representatives are natural persons. They have, for each organization, a list of legal representatives, including:
The legal representative is a different concept from the organization's contact point. The parties/people approach and the fields used by the Moldova extension could be reused for this use case (although the proposed model is more complicated than what the DNCP needs) |
|
There's no consensus on the model other than putting a |
|
Sounds good. I'm wondering if we should change the beneficial ownership extension as part of this, or maybe that concept won't fall under the "people" definition? In any case, I think that the model should include at least: {
"parties": [
{
"id": "PY-RUC-1223",
"name": "Company A",
"people": [
{
"id": "1",
"name": "",
"identifier": {
"scheme": "",
"id": ""
},
"roles": [
"legalRepresentative"
],
"jobTitle": ""
}
]
}
]
}Where other possible roles are: Owners, authorized agents, signing officers, contact points (maybe not contact points as we already have As mentioned in #883 (comment), I think this information should be enough for the current demand. |
|
Having |
|
Another real use case for this is in Argentina at the national level where they have the information about who signed the contract (name and job title) |
Problem
Presently, entries in the
partiesarray are onlyOrganizationobjects:Organizationhas adescriptionof "A party (organization)". In other words, all parties must be organizations, at present, according to the schema. Many of the extensions to this object add organization-specific fields that don't make sense for people.If any natural persons belong in the
partiesarray, we will need to change the schema.Sidebar: Exceptional case: Sole traders: When governments award contracts to natural persons, they are often treated administratively as if they were corporations. For example, in Canada, natural persons with significant commercial activities must register a GST (VAT) ID the same as a corporation. This being the case, it's fine to use the
Organizationobject for sole traders in OCDS.Background
#368 anticipated allowing natural persons as parties, but it's not clear that this was realized, beyond the special case of sole traders.
Discussion
In terms of what belongs in the
partiesarray, the field is described as "Information on the parties … who are involved in the contracting process and their roles." Going over the types of individuals that have come up:it would not make sense to present such people alongside other parties; this would likely confuse users, especially given that an unaware tool won't be able to draw the link between the many people and their related organizations.
#621 discusses a local extension that would use the
partiesarray for attendees of clarification meetings, including potential bidders (organizations) and public servants (natural persons). My interpretation is that the public servants are not parties, but are instead there on behalf of the buyer.Other examples of natural persons are members of approval or award committees, etc. This is a more ambiguous scenario. However, I think it can still be said that, even in the temporary role of a juror in a design contest, that person is working on behalf of the buyer to determine the winner.
Proposal
For the above natural persons, we can consider a new field (
people) on the Organization object to collect all the relevant people and their respective roles within/with respect to that organization. In that case, unaware tools would display people within the appropriate context of their related organization.As of writing, we don't have a use case for natural persons in the
partiesarray (besides sole traders). If we do, however, we'll need to change the schema.This issue has at least raised the need to better document the use of the
partiesarray, and the treatment of natural persons in OCDS.The text was updated successfully, but these errors were encountered: