Registreren overdracht van Belang

Casusbeschrijving

Er wordt een Belang overgedragen van persoon 1 (partijId = 39d50c05-311d-45cc-a931-ed03c5ffae93) naar persoon 2 (partijId = 00e976f3-310e-455d-8d23-dd08774e2c15). De registratie van de betrokken partijen heeft reeds plaatsgevonden en is beschreven in casus Initiële registratie van Partijen. De registratie van het betrokken wozobject heeft ook plaatsgevondenb en is beschreven in Initiële registratie van WOZ-objecten. De registratie van het belang van persoon 1 heeft plaatsgevonden en is beschreven in Registreren van belangen

In deze beschrijvingen worden alleen de claim-rollen en de daarbij behorende waarden beschreven. De claimtype expressies zijn te vinden in de beschrijvingen van Objecttype Belang

Het uitvoeren van deze casus is onderdeel van de test_woz (alle casussen die in combinatie worden uitgevoerd). Vanwege de samenhang met het registreren van personen, woz-objecten en belangen als pre-conditie is het niet mogelijk deze casus alleen uit te voeren. Zie Uitleg uitvoeren WOZ-cases

In deze casus wordt een bestaand belang van Persoon 1 in WozObject met WozObjectnummer “d6b33e05-a6ea-43d7-b9d0-7380c74e3c39” beëindigd en er wordt middels een nieuw Belang geregistreerd tussen datzelfde WozObject en persoon 2.

Bevinding

Tijdens het uitwerken van deze casus is een discussie gevoerd over de wijze waarop d overdracht van het belang geregistreerd moest worden. Naast de hierboven beschreven optie, die in deze casus geïmplementeerd is, zou er voor kunnen worden gekozen om het Partij-id in het bestaande belang te wijzigen. Dat zou dus effectief leiden tot het beëeindigen van alleen de Belang_Partijid claim (dien verwijst naar persoon 1) en het opvoeren van een nieuwe Belang_Partijid claim (die verwijst naar persoon 2) binnen hetzelfde belang.

De reden om deze variant niet toe te passen is dat het Belang een samengestelde sleutel heeft. Functioneel gezien ligt de uniciteit over de Belang_PartijId claim en het Belang_WozObjectnummer-claim. Het vervangen van alleen de Belang_PartijId _claim zou dus neerkomen op het wijziging van de unieke identificatie van het betreffende Belang en dat is ongewenst.

Transacties

De beëindiging van het belang van persoon 1 en het nieuwe belang van persoon 2 worden één transactie geregistreerd. Dat betekent dat de beindigings-annotatie (ValidUntil) van het belang van persoon 1 en alle claims en annotaties van het nieuwe belang van persoon 2 dezelfde waarde kennen voor het registratiemoment (registeredAt). Als er een error optreedt dan worden alle claims die in de lopende transactie zijn geregistreerd in een rollback weer verwijderd.

Notificatie

In deze casus komen wijzigingen tot stand op basis van een binnenkomend bericht. De veronderstelling is dat dit bericht binnen het domein is opgesteld en direct als commando verwerkt wordt. Een andere mogelijke inrichting is dat dit proces in gang gezet wordt door een bericht dat is opgesteld buiten het domein en als (informatierijke) notificatie ontvangen en verwerkt wordt.

In de praktijk zullen overdrachten van belangen worden doorgevoerd naar aanleiding van (informatierijke) notificaties van het kadaster uit de BRK.

Indien het een notificatie zou betreffen is in onderstaand overzicht te zien hoe een notificatie tot commando’s, effecten (verwerkingsstappen? , gevolgen?) en claims wordt verwerkt.

Notificatieverwerking

Van notificatiebericht naar commando

Van het binnenkomende notificatiebericht moet worden vastgesteld dat het een valide notificatiebericht zou kunnen zijn en geen onderdeel is van een DDOS-aanval of input bevat die onmogelijk verwerkbaar zou kunnen zijn.

Als het bericht ontvangen is vinden de volgende bewerkingstappen plaats.

Notificatieverwerker ontvangt notificatiebericht voert de volgende stappen uit:

Noot: De Notificatieverwerker is niet geïmplementeerd in het prototype. Het omzetten van XML naar Json is niet nieuw en er is voor gekozen om deze stap over te slaan. De werkende casus begint dus vanaf het commando.

Command

    command_str = """
        {
            "command": {
                "commandId": "fc463d6c-23ef-47e4-98f3-e49bdf90cb00",
                "commandType": "registreer_belangen"
            },
            "data": [
              {
                "beeindig_belang": {
                    "wozObjectnummer": "d6b33e05-a6ea-43d7-b9d0-7380c74e3c39",
                    "aandeel": "50",
                    "partijId": "39d50c05-311d-45cc-a931-ed03c5ffae93",
                    "soortBelang" : "eigenaar",  
                    "aardZakelijkRecht": "606", 
                    "geldigTot": "2025-03-06T11:10:00.000+00:00"       
                }
              },
              {
               "registreer_belang": {
                    "wozObjectnummer": "d6b33e05-a6ea-43d7-b9d0-7380c74e3c39",
                    "aandeel": "50",
                    "partijId": "00e976f3-310e-455d-8d23-dd08774e2c15",
                    "soortBelang" : "eigenaar",  
                    "aardZakelijkRecht": "606", 
                    "geldigVanaf": "2025-03-06T11:10:00.000+00:00"   
                }
              }   
            ]
        }
    """

Verwerking

Het commando wordt aangeboden aan het systeem en de eerste stap in de verwerking is het vastleggen van de inhoud van het commando en de registratietijd en, waar mogelijk de context van het commando.

Vervolgens wordt het commando door de commandoverwerker “draag_belang_over” verwerkt tot effecten (gevolgen). In dit geval onstaan er 2 effecten. Het ene effect is de beëindiging van het belang van persoon 1 en het andere effect is het registreren van het belang van persoon 2. De effecten worden na ontstaan zelf geregistreerd en vervolgens worden de effecten verwerkt door de effect-verwerkers “beeindig_belang” en “registreer_belang”. Bij deze verwerking worden de claims en annotaties vastgelegd in de Atomic Claim Engine (ACE).

Nadat de command voor het overdragen van het belang is uitgevoerd is de “ValidUntil” annotatie voor het belang van persoon 1 geregistreerd met als datum de geldigTot uit het commando en er alle claims en annotaties voor het nieuwe belang van persoon 2 zijn geregistreerd.

Lineage

De lineage geeft de context weer tussen command, gevolgen en claims per objecttype. Om de lineage te kunnen weergeven is iedere claim (ook annotaties) voorzien van een context-annotatie die verwijst naar het commando of het gevolg dat geleid heeft tot het vastleggen van deze claim. De context wordt in dit overzicht gerepresenteerd door de lijnen tussen de blokjes. Alle individuele context_annotaties van een gegroepeerd object zijn dus geconsolideerd in 1 verbindings-lijn.

De lineage wordt aangemaakt door na het verwerken van het command tweemaal de call_lineage-module aan te roepen. Deze aanroep is verwerkt in “test_woz_output”. Dit resulteert in de volgende twee weergaven van de lineage:

Lineage-roles

In deze weergave worden alleen de claimroles met hun waarden getoond. (Klik op de afbeelding voor grotere weergave op mermaid.live. Daar wordt ook de mogelijkheid geboden om full-screen weer te geven en in te zoomen. )

Lineage-state

In deze weergave worden de volledige claim-expressies in de “state”- variant getoond. (Klik op de afbeelding voor grotere weergave op mermaid.live. Daar wordt ook de mogelijkheid geboden om full-screen weer te geven en in te zoomen. )

Objectweergave

Het laatste inzicht dat geboden wordt naar aanleiding van deze casus is een weergave waarbij de claims zijn gegroepeerd op object-niveau content_claims. Daarbij worden ook alle annotaties die zijn geregistreerd getoond. Ook voor deze weergave geldt dat het image ter illustratie is en dat via de link een weergave op mermaid.live getoond kan worden waarbij ingezoomd kan worden. Deze weergave wordt gegenereerd door de content_claims-module aan te roepen. Deze aanroep is verwerkt in “test_woz_output”.