-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Field request: supplier size / type #260
Comments
(Corrected title - as I had mixed up buyer type and supplier size issues) |
I like the idea of the global codelist. For comparison reasons, I think it would be best to use the local classification and not convert it to some kind of OCDS classification based on turnover and amount of employees. Small, Medium, and Large seem to be the categories that are consistently used, often times Micro is used as well. The latter is the case in Mexico. |
Just checked in EU TED forms, and I can't find any fields for size of supplier. Will dig around further. |
This will be useful from an "Open contracting" perspective to identify subset of companies to drill into their contracts. |
See also #181 for a related discussion |
This issue is taken forward in #369 |
Treated as duplicate of #181 |
Via @olafveerman from the Procurement Analytics project:
Some analysis of contracting data relies upon knowing the 'type' of a company selected as supplier (or bidding): e.g. Small, Medium, Large enterprise.
In procurement analytics, a
award/supplier/sizeSupplier
field has been added.Whilst in theory, buyer type could be inferred from looking up information in company registries (e.g. based on declared turnover where this is available), many governments collect self-declarations of this information in their procurement systems, so it would be useful to be able to publish this in the standard.
Questions
There are a number of options for constructing a field like this:
1. Global codelist
Setting out a single unified codelist for company type or size - and asking publishers to map to this codelist.
This has the advantage of supporting analysis to be developed based on a fairly simple taxonomy (e.g. tools can be built that only need to recognise a few features of companies) - but the disadvantages (a) of not capturing the full range of features countries might have; (b) of risking poor quality mappings when countries do no hold adequate data to bucket in the globally agreed categories.
2. Local codelists
Provide a field, but allow countries to set their own codes for types of company
This places the burden of working out how to interpret codes on tools, but allows the standard to express country-relevant categories.
This may need a mechanism for countries to better declare and document their codes.
3. Detailed feature descriptions
Providing space to declare key features such as company turnover, employees etc. from which a definition of company type can be applied.
This would allow the greatest flexibility - but countries may not currently collect this data.
The text was updated successfully, but these errors were encountered: