Enforce uniqueness of Partij

[mariusvandam]

Thema / Theme

Klantinteracties API

Omschrijving / Description

It is currently possible to create multiple identical Partij Identificator records for the same 'Partij'

As a replacement story for #241 we should create a more intelligent enforcement of uniqueness for partij. Depending on the used identificatoren for a Partij, different logic should be applied to make sure a single Partij is only created once.

1. Any bsn can only be occur once (natural persons)
2. A kvkNummer without a vestigingsnummer can only occur once (representing the "niet natuurlijk persoon" in general, separate from any concrete vestiging)
3. A combination of kvkNummer AND vestigingsnummer can only occur once (vestigingen, disambiguated according to their associated parent entity)
4. A Partij can never have a vestigingsnummer assigned without a kvkNummer being assigned at the same time

This will almost certainly require some kind of bulk creation/deletion of identificatoren, to avoid to avoid intermediate states which would violate these invariants (e.g. if there's already a Partij with 1 kvkNummer, you would have to provide both kvkNummer and vestigingsnummer together for a second Partij you might want to create to represent a vestiging separately from the generic niet-natuurlijk persoon).

It would also require being able to filter the Partij resource on an array of identificator values (to filter a list down to a specific kvk/vestigingsnummer pairing (ideally using the identificator register/objecttype/id values directly, to avoid having to first fetch the partij identificatoren and filter on the identificator UUIDs).

Toegevoegde waarde / Added value

The value of an identificator should be that it actually functions as a unique identifier, both for developer experience (no difficult-to-resolve edge-cases to handle), but it would also improve the data quality (less chance of spurious duplicates). This would be complementary to #233 . Specifically it is important that there is no ambiguity when referring to vestigingen, where two vestigingen may have the same number but different parent kvkNummer entities.

Aanvullende opmerkingen / Additional context

No response

[joeribekker]

A vestigingsnummer is globally unique, so let's just do that instead of a combination of kvk number AND vestigingsnummer.

[sytskevanhasselt]

See also my comment on issue #233

[swrichards]

Because #233 had veered into discussions of uniqueness which strictly belong here, I just wanted to add a proposal based on Hugo's comment in the 26/11 meeting that we can enforce the (vestiging, kvk) at the application level.

The simplest solution would be to keep the vestigingsnummer identificator (that is, not a compound), but enforce that:

• A vestigingsnummer identificator can only ever be added to a Partij if it already has a kvkNummer identificator
• A kvkNummer identificator cannot be removed from a Partij as long as a vestigingsnummer has been assigned.

These together would enforce that every Partij with a vestigingsnummer would also have a kvkNummer.

This does not solve all problems. In particular, it you query the Partij resources by vestigingsnummer, you could get more than one result, and there's nothing forcing application users to narrow down their query to a single row by adding a kvkNummer. It this possibly to blindly take a "grab the first partij we find for this vestigingsnummer", meaning developers may end up writing to the history of the "wrong" partij (e.g. as a child of the previous kvk parent). But as discussed in our meeting, we're comfortable letting different applications handle this in an appropriate manner.

[swrichards]

@mariusvandam proposal for an amended ticket description, feel free to copy it into the main description if we're all in agreement:

---

Thema / Theme

Klantinteracties API

Omschrijving / Description

It is currently possible to create multiple identical Partij Identificator records for the same 'Partij'

As a replacement story for #241 we should create a more intelligent enforcement of uniqueness for partij. Depending on the used identificatoren for a Partij, different logic should be applied to make sure a single Partij is only created once.

1. Any bsn can only be occur once (natural persons)
2. A kvkNummer without a vestigingsnummer can only occur once (representing the "niet natuurlijk persoon" in general, separate from any concrete vestiging)
3. A combination of kvkNummer AND vestigingsnummer can only occur once (vestigingen, dismabiguated according to their associated parent entity)
4. A Partij can never have a vestigingsnummer assigned without a kvkNummer being assigned at the same time

This will almost certainly require some kind of bulk creation/deletion of identificatoren, to avoid to avoid intermediate states which would violate these invariants (e.g. if there's already a Partij with 1 kvkNummer, you would have to provide both kvkNummer and vestigingsnummer together for a second Partij you might want to create to represent a vestiging separately from the generic niet-natuurlijk persoon).

It would also require being able to filter the Partij resource on an array of identificator values (to filter a list down to a specific kvk/vestigingsnummer pairing (ideally using the identificator register/objecttype/id values directly, to avoid having to first fetch the partij identificatoren and filter on the identificator UUIDs).

Toegevoegde waarde / Added value

The value of an identificator should be that it actually functions as a unique identifier, both for developer experience (no difficult-to-resolve edge-cases to handle), but it would also improve the data quality (less chance of spurious duplicates). This would be complementary to #233 . Specifically it is important that there is no ambiguity when referring to vestigingen, where two vestigingen may have the same number but different parent kvkNummer entities.

Aanvullende opmerkingen / Additional context

No response