codeGebouwdOngebouwd word nooit van "O" gehaald. Moeten de nieuwe WOZ-objecten die bij de splitsing ontstaan ook codeGebouwdOngebouwd "O" zijn?
Stap 5: Vestigingsnummer 983412342 is geen 12 cijfers
Bij stap 10 word niet duidelijk gemaakt welk van de nieuwe BAG-objecten de aanduiding word voor het WOZ-object met nummer 051300193111. Dus wat word WOZNUM?
In het voorbeeldbericht voor WASWO word in de oude waarde de toegekendeOppervlakte en meegetaxeerdeOppervlakte elementen opgenomen. Deze mogen weg.
De datum van Stap 10 en 11 is omgekeerd (of is dat expres?)
ma, 19-11-2012 - 15.58u
#1
Opmerkingen Scenario 3
Bij de scenario's worden niet exact alle attributen die in een bericht geleverd moeten worden opgenomen benoemd. Er wordt ook enige WOZ-kennis verwacht van de uitvoerder/van de applicatie waarmee de berichten worden gemaakt. In stap 3 is sprake van "start bouw". Start bouw betekent dat er vanaf dat moment sprake is van een gebouwd object. Dus in het MKEN bericht wordt ook codeGebouwdOngebouwd op "G" gezet. In applicaties/werkprocessen zal vaak bij een dergelijke wijziging van gebruikscode ook de gebruiker worden gewezen op de wijziging van de codeGebouwdOngebouwd.
Vestigingsnummer was inderdaad "te kort". In de voorbeeldberichten was dit opgelost met voorloopnullen. Deze voorloopnullen zijn nu ook toegevoegd in de scenariobeschrijving.
In voorbeeldberichten was "819a" als NUM genomen. Dat is nu ook expliciet opgenomen in de scenariobeschrijving.
Wat betreft het WASWO bericht denk ik dat je gelijk hebt. Inderdaad wordt de ene relatie beëindigd en de andere opgevoerd en het is geen "wijziging" van de relatie. Wanneer het een wijziging van de relatie betreft, is in ieder geval toegekendeOppervlakte wel verplicht, want die wijzigt. We zullen het nog eens voorleggen aan een echte StUF-expert.
De "omdraaiing" van de data bij stap 10 en 11 is inderdaad expres, want overeenkomstig de realisteit. Kadastermutaties komen immers altijd met meer vertraging bij de gemeente aan dan de BAG-mutaties.
toegekendeOppervlakte en meegetaxeerdeOppervlakte kunnen inderdaad verwijderd worden in de 'oude' SWOKOZ-relatie (alleen de kerngegevens c.q. de in het schema verplichte gegevens zijn nodig). De eis is dat in tijdvakGeldigheid in oud, beginGeldigheid gelijk is aan eindRelatie en eindGeldigheid geenWaarde heeft.