search

VNG-Realisatie / StUF-Standaarden

Repository met de issues uit en in de oude Drupal community omgeving en de nieuwe issues
https://vng-realisatie.github.io/StUF-Standaarden/
6 stars 3 forks source link

Titels/predicaten in LO GBA 3.14 #17

Closed sbrouwer71 closed 2 years ago

sbrouwer71 commented 3 years ago

Op 3 oktober aanstaande treedt een nieuwe versie van het LO GBAin werking. In deze versie, 3.14, zijn twee wijzigingen opgenomen rond titels/predicaten:

  1. Het gegeven wordt voortaan benoemd volgens de (sinds 2006) actuele spelling: predikaat wordt predicaat.
  2. Alle titels worden met kleine letters gespeld, waar die nu nog beginnen met een kleine letter.

Wijziging 1 hoeft geen effect te hebben op StUF, aangezien de interne benaming van het veld niet erg relevant is voor de functionele werking. Het heeft in ieder geval geen enkele prioriteit om dit te wijzigen.

Wijziging 2 is wat dat betreft meer discutabel. In StUF BG3.10 wordt voor dit gegeven namelijk een enumeratie gebruikt, waarbij alle elementen, overeenkomstig de titelomschrijvingen in de BRP, worden gespeld met een hoofdletter. Zouden we StUF hier niet op aanpassen, dan moeten alle zenders en ontvangers er rekening mee houden dat in de communicatie met StUF de titels met hoofdletters moeten worden geschreven, terwijl in de communicatie met gebruikers (gegenereerde correspondentie etc. inbegrepen) er alleen kleine letters moeten worden gebruikt.

Ik vermoed dat veel afnemers (buiten het GBA/BRP-domein) dit niet eens zullen weten. Daar zullen dus waarschijnlijk de hoofdletters gebruikt blijven worden bij het weergeven/afdrukken van de titels.

Ik zou hier graag de discussie starten over twee vragen:

  1. Is het noodzakelijk om de enumeratie in StUF aan te passen, dan wel te vervangen door een 'vrij' tekstelement? Bij aanpassen van de enumeratie moeten wellicht beide vormen nog worden opgenomen (zie volgend issue). Bij aanpassen naar een vrij tekstelement kan het probleem ontstaan dat ongeldige titels worden doorgegeven. Voor sommige systemen kan dit een probleem zijn, aangezien titel/predicaat mogelijk als een code/omschrijving-paar kan zijn opgeslagen, zoals dat in de BRP gebeurt. In de communicatie (en interoperabiliteit) zou de impact het kleinst zijn als we niets veranderen in StUF en de enumeratie als 'codes' behandelen die door zender/ontvangen moeten worden omgezet naar de juiste omschrijvingen (in dit geval de codes zonder hoofdletters). In mijn ogen niet bepaald de meest fraaie oplossing, maar wel bedrijfszeker als het gaat om de gegevensuitwisseling.
  2. Wat zouden afnemers moeten verwachten van de bronhouder bij deze wijziging (indien we StUF hierop aanpassen)? Voor de GBA is dit geen wijziging op de persoonslijsten. Op de PL wordt een code opgeslagen en wat wijzigt zijn de omschrijvingen bij die codes (landelijke tabel 38). Er zijn geen berichten (noch in de GBA, noch in StUF) om deze wijzigingen door te geven. Vanuit oogpunt van de BRP hoeven er dus geen wijzigingen te worden doorgegeven. Als we in StUF de enumeratie wijzigen, dan zou dat kunnen betekenen dat voor iedere persoon met een titel toch een wijzigingsbericht zou moeten worden gestuurd. Dat zou voor punt 1 betekenen dat zowel oude als nieuwe schrijfwijzen moeten kunnen worden opgenomen. Dit zou in de ontvangende applicaties ook kunnen worden opgelost door een (eenmalige) conversie zonder dat er StUF-berichten zouden hoeven worden verzonden.
mvdbro commented 3 years ago

Ad 1: ik zou de enumeratie vervangen door een vrij tekstveld. Enumeratie lijkt me niet nodig, omdat de bron over algemeen een GBA applicatie of een GBA API zal zijn.

Ad 2: In distributiesystemen en gegevensmagazijnen zal de omschrijving sowieso aangepast moeten worden. Het lijkt mij dan vanuit het distributiesysteem geen hele grote moeite om dit te doen via een kennisgeving en deze kennisgeving ook te distribueren naar afnemers. Zo hoeft maar één applicatie in de gemeente iets te doen en volgt de rest automatisch.

melsk-r commented 3 years ago

Dit onderhoudsverzoek is opgevoerd in de onderhoudsverzoeken als ONV0523. De lijst met onderhoudsverzoeken vind je hier.

melsk-r commented 2 years ago

In het prepatch bestand bg0310_20210901_pre-patch31.zip is in het schema 'bg0310_simpleTypes.xsd' het door Sid geschetste probleem opgelost zoals door Maarten voorgesteld. Het simpleType 'AdellijkeTitelPredikaat' is dus ontdaan van de enumeratie. De waarde wordt daardoor niet meer gelimiteerd door de enumeratie maar door de gerelateerde in het LO GBA gedefinieerde lijst.

De vraag is nu of iedereen zich kan vinden in deze oplossingsrichting.

mvdbro commented 2 years ago

Prima

sbrouwer71 commented 2 years ago

Mee eens.

timmerto commented 2 years ago

Ook mee eens, weer een enumeratie minder! Het is zinvol om alle nog bestaande enumeraties binnen entiteiten uit BAG en GBA ook te verwijderen of in ieder geval hierop na te lopen. Dan hebben we kraan dicht gedraaid ipv alleen maar te moppen zoals nu bij BAG 2.0, GBA 3.13 en3.14. De authentieke bron is immers verantwoordelijk voor het doorgeven van de juiste waarde! Voor het handelsregister zie ik zo vlug geen enumeraties meer. Het toevoegen van een nieuwe rechtsvorm (kans daarop?) zou daarom geen probleem moeten zijn, behalve dan bij de omzetting bg0310 -> BG0204

melsk-r commented 2 years ago

Hoi Ton,

StUF onderhoud staat op een laag pitje en we beperken ons bij patches daarom tot zaken die noodzakelijk zijn om het StUF berichtenverkeer in stand te houden. We ga dus geen aanpassingen doorvoeren om het mooier of handiger te maken. Voor de wijziging die ik n.a.v. deze discussie heb voorgesteld is dat het geval. Er verandert iets in de LO GBA en de aanpassing is noodzakelijk om het berichtenverkeer werkende te houden.

timmerto commented 2 years ago

Ik snap dat je het onderhoud tot een minimum wilt beperken. Maar ik geloof dat je dat met het verwijderen van de enumeraties dat nog beter bereikt. Dan hoeven we een volgende LO of BAG wijziging dit soort aanpassingen niet meer te bepreken en door te voeren. Scheelt een boel tijd en een benodigde implementatie van een patch voor alle leveranciers en afnemers. Denk nog eens terug aan die BGA 2.0 oplossing waar de bestaande enumeratie werd uitgebreid en binnen StUF BG de nieuwe waardes via extra elementen moeten worden doorgegeven.

timmerto commented 2 years ago

Ik snap dat je het onderhoud tot een minimum wilt beperken. Maar ik geloof dat je dat met het verwijderen van de enumeraties dat nog beter bereikt. Dan hoeven we een volgende LO of BAG wijziging dit soort aanpassingen niet meer te bepreken en door te voeren. Scheelt een boel tijd en een benodigde implementatie van een patch voor alle leveranciers en afnemers. Denk nog eens terug aan die BGA 2.0 oplossing waar de bestaande enumeratie werd uitgebreid en binnen StUF BG de nieuwe waardes via extra elementen moeten worden doorgegeven.

Ook staat er weer iets te gebeuren voor GBA: Het wetsvoorstel ‘Pensioenverdeling bij scheiding’ (kst 35287) ligt ter behandeling in de Tweede Kamer. Voor de tweede maal is de beoogde datum inwerkingtreding opgeschoven, deze keer naar 1 juli 2022. Als gevolg van dit wetsvoorstel, moet er een wijziging in tabel 41 Reden ontbinding/nietigverklaring huwelijk/geregistreerd partnerschap worden doorgevoerd. Het idee is dat met de in werking treding van de nieuwe wet: • de code S een einddatum geldigheid krijgt • er een nieuwe code E komt voor een scheiding die niet is voorafgegaan door een scheiding van tafel en bed en • er een nieuwe code T komt voor een scheiding die wel is voorafgegaan door een scheiding van tafel en bed.

melsk-r commented 2 years ago

Voor nu houden we het bij de voorgestelde wijziging zodat de publicatie van patch 31 z.s.m. plaats kan vinden. Bij een eventuele volgende gelegenheid waarin een enumeratie moet worden verwijderd zullen we opnieuw overwegen alle enumeraties te verwijderen.

@timmerto Kan jij je post m.b.t. het wetsvoorstel ‘Pensioenverdeling bij scheiding’ in een apart issue plaatsen.

melsk-r commented 2 years ago

Dit issue is inmiddels opgelost met patch 31 en kan gesloten worden.