-
Notifications
You must be signed in to change notification settings - Fork 2
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
Deal with old CPVs #110
Comments
@zufanka The issue with the solution above is that, as you will see in the correspondence table there is no 1-1 mapping between the 2007 and the 2003 cpvs. The 2007 cpvs are more discrete and therefore some 2003 cpvs have 2 or more new cpvs corresponding to them. For example:
From a technical pov the right way would be to make this new Having it as an array would also make things even more complicated and most importantly slow. |
@georgiana-b : I think it's ok to just take the most general one, in this case '09100000'. We have no way of knowing which more specific one to use anyway and as you pointed out, another solution would be awkward. |
@zufanka I like the idea but unfortunately it's not applicable to all the cpvs.
|
@georgiana-b I see! I guess then we put them under the highest level CPV of what they have in common, in this case it's the CPV |
We are starting to get old cpvs (from the 2003 CPV standard) in Opentender data. Currently these are causing an error in Elvis because we don't have any way to deal with them.
The solution we proposed so far was to create a new field for cpvs called
standardCPV
and match on that. For 2008 on tenders thestandardCPV
would be equal to their normal CPV.For earlier tender the standardCPV would be their corresponding new CPV according to the correspondence table.
The text was updated successfully, but these errors were encountered: