-
Notifications
You must be signed in to change notification settings - Fork 3
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
Fixed set of values for 'partij-identificatoren' (ENUM) #233
Comments
Dimpact backlog: https://dimpact.atlassian.net/browse/POD-246 |
Ik heb gekeken naar de identificaties voor personen en bedrijven in de Zaken API's bij een Rol.
|
I'd like to limit the choices now to registers that are official, to make things less vague for client side implementations. Technical implications: partijIdentificatorCodeRegister (becomes an ENUM)There are 10 registers of which 2 are relevant for Open Klant:
We'll add partijIdentificatorCodeObjecttype (adds VALIDATION)
NOTE: I left partijIdentificatorCodeSoortObjectId (adds VALIDATION)
partijIdentificatorObjectId (adds VALIDATION)
|
It also seems useful to pick up #267 at the same time. |
@joeribekker , one question about "CodeObjecttypes choices are limited based on CodeRegister:" |
@andyverberne has confirmed, from Eviden internally and also Gemeente Roermond, that the combinatin Vestigingsnummer + KvKnrA is a different 'client' than the combination Vestigingsnummer + KvKnrB. Which means that the proper uniqueness of a vestiging lies in the combination of KvK-nr AND Vestigingsnummer. |
@sytskevanhasselt if the conclusion is that we need 2 attributes, the structure might not be sufficient since we only have one "ObjectId". A structure change can not be realized just like that. So, we could look at alternatives that fit within the structure:
2a. We could try to make a unique that spans 2 identificatoren (kvk and vestigingsnummer), which might or might not be there at all times. 2b. We can not make the unique and make it a pattern that can be used (so nothing formal, just a suggestion in the API spec) to always store 2 identificatoren in case of vestigings. |
I think the conclusion from @andyverberne and @sytskevanhasselt examples might be even stronger: it is not only that As for how to model this, I would prefer something like @joeribekker 's first option, so we would get:
This means that you can still refer to the |
@sytskevanhasselt agree as well with option 1? |
[#233] Fix tests [#233] Install django-digid-eherkenning [#233] Fix tests [#233] Improve Validator [#233] Fix tests [#233] Isort and Flake8 [#233] Improvements [#233] Remove django-digid-eherkenning [#233] Fix requirements [#233] Fix requirements 2 [#233] Fix tests [#233] Flake8 [#233] Fix validation errors [#233] Update class [#233] Remove unused import
Thema / Theme
Klantinteracties API
Omschrijving / Description
Omschrijving
We willen dat de waardes voor de identificatoren van een Partij enums worden, zodat er nooit verschillen kunnen ontstaan in de waarden van de verschillende onderdelen van de Identificator
Specific details
Voor de volgende properties moeten enums komen.
partijIdentificator.codeRegister
-> toegestane waarden:brp
hr
overig
partijIdentificator.codeObjecttype
-> toegestane waarden:natuurlijkPersoon
vestiging
nietNatuurlijkPersoon
overig
partijIdentificator. codeSoortObjectId
-> toegestane waarden:bsn
kvkNummer
rsin
vestigingsnummer
overig
Aanvullende opmerkingen / Additional context
No response
The text was updated successfully, but these errors were encountered: