Glossaria - Algemene informatie

Interpreteren van de aanwezigheden van de gegevens

Binnen een glossarium zijn 2 soorten fiches aanwezig om de gegevens van een aangifte voor te stellen :

• Fiches van de zones
• Fiches van de blokken

Voor elk van deze gegevens - zowel blokken als zones - werd een aanwezigheid gedefinieerd. Naast de aanwezigheid van een bepaalde zone, moet bijgevolg steeds de aanwezigheid van het blok, waarin de zone verschijnt, worden beschouwd

Nemen we een voorbeeld :

Het blok 90036 - Commentaar bij de aangifte heeft als aanwezigheid Facultatief.

Dit betekent dat het geheel van zones binnen dit blok kan worden opgegeven indien gewenst. In ons geval bevat het blok slechts één enkele zone, nl. 00126 - Zone vrije tekst.

De zone 00126 - Zone vrije tekst heeft als aanwezigheid Onmisbaar.

Dit betekent dat, indien ervoor gekozen wordt om het omsluitende blok 90036 - Commentaar bij de aangifte op te nemen in de aangifte, deze zone verplicht op te geven is.

Er bestaan m.a.w. bijkomende voorwaarden op het niveau van de zones, die gelden wanneer het blok bestaat.

Bekijken we deze regel op XML-niveau.

De xml-tag van het blok is <CommentDeclaration>.
De xml-tag van de zone in kwestie is <CommentOfDeclaration>.

Indien geen commentaar gewenst, moeten zowel het blok als de zone achterwege blijven.
Dit is dus NIET mogelijk :

<CommentDeclaration></CommentDeclaration>

Indien wel commentaar gewenst is, moeten zowel het blok als de zone aanwezig zijn :

<CommentDeclaration>
<CommentOfDeclaration>TEST</CommentOfDeclaration>
</CommentDeclaration>

Besluit :

De aanwezigheid op het niveau van een zone (zie de fiche die overeenstemt met het gegeven in het glossarium) volstaat niet om te bepalen of dat gegeven al dan niet in de aangifte aanwezig moet zijn.
Gezien de zones worden gegroepeerd in functionele blokken, is de aanwezigheid van een zone ondergeschikt aan de aanwezigheid van het blok waarvan de zone deel uitmaakt. Immers, zelfs indien een zone als onmisbaar wordt aangeduid, blijft het mogelijk dat ze niet in de aangifte voorkomt indien het blok waartoe ze behoort facultatief is.
De fiches met betrekking tot de blokken moeten dus eveneens worden geraadpleegd (nl. de "aanwezigheid") om te beoordelen of een zone met betrekking tot een bepaald gegeven moet voorkomen in de aangifte.

Gebruik van de TAG <Location> (zone 00295 - "Lokalisatie van de fout in de boomstructuur")

Deze tag wil ons in staat stellen om op een eenduidige manier de plaats te lokaliseren waar er zich een fout heeft voorgedaan in een hiërarchische structuur en dus in een XML-document. Daarom zullen wij zodanig te werk gaan dat elk element van een XML-document gelokaliseerd kan worden dankzij een « pad ».

Aangezien een XML-document een hiërarchische structuur is, kan het voorgesteld worden door een boom. Bovendien kunnen alle elementen van deze boom genummerd worden. We zullen ze als volgt nummeren : het nummer toegekend aan een element zal overeenstemmen met de positie ervan (hoeveelste zoon) ten opzichte van het vader-element. Als een element dus het nummer n heeft, dan betekent dit dat het gaat om het zoon-element n van de vader.

Ofwel het volgende XML-bestand:

<Wagen>
  <binnenkant>
    <AantalZetels>5</AantalZetels>
    <ElektrischeRuiten>Avant<ElektrischeRuiten>
  </binnenkant>
  <buitenkant>
    <AantalDeuren>6</AantalDeuren>
    <Metaalglans>JAn<Metaalglans>
    <Lengte>4,23</Lengte>
  </buitenkant>
</Wagen>

Als we ervan uitgaan dat de enige toegelaten waarden voor het gegeven <Metaalglans> de waarden «JA» of «NEEN» zijn, dan merken we op dat het bestand een fout bevat. De zone bevat namelijk « JAn » als waarde.

Ziehier de boomstructuur die hoort bij dit document:

De fout gevonden in het gegeven « Metaalglans » zal eenduidig gelokaliseerd worden als volgt:

<Location>1,2,2,1</Location>

Algemene informatie over de ASR controles

De verwerking van de ASR, zowel via het Web-kanaal (SP10) als via het Batch-kanaal (SP07), vereist naast de schemacontroles ook een reeks zogenaamde "kruiscontroles". Deze kruiscontroles omvatten eigenlijk twee soorten van controles:

• kruiscontroles stricto sensu (vormcontroles die te complex zijn om uitgevoerd te worden op schemaniveau);
• inhoudscontroles (uitgevoerd via oproepen naar basisdiensten).

Voorbeelden van kruiscontroles:

• Nagaan of het gegeven 00045 (OccupationEndingDate) groter dan of gelijk is aan het gegeven 00044 (OccupationStartingDate).
• Als het gegeven 00016 (System5) de waarde 1 heeft, verifiëren dat het gegeven 00047 (WorkingDaysSystem) gelijk is aan 500.
• Nagaan of het gegeven 00112 aanwezig is indien het gegeven 00378 (EndYearBonusCode) de waarde 3 heeft OF het gegeven 00378 de waarde 4 heeft EN de gegevens 00387 (EndYearBonusAmount) EN 00111 (EndYearBonusValue) niet meegedeeld zijn.

Voorbeeld van inhoudscontrole:

• indien de datum sociaal risico in het lopende kwartaal ligt, moet het gegeven 00011 (NOSSRegistrationNbr) aanwezig zijn in het repertorium "Werkgeversidentificatie" en moet de datum sociaal risico liggen tussen inschrijvingsdatum en schrappingsdatum van dit stamnummer in het repertorium.
• Indien de datum sociaal risico kleiner is dan het lopende kwartaal, moet het gegeven 00011 (NOSSRegistrationNbr) aanwezig en actief zijn in het repertorium "Codebestand" op de datum sociaal risico.

In elk geval, indien het resultaat van een controle verkeerd is, wordt er een anomalie gegenereerd (die een anomaliecode bevat zoals bepaald in het glossarium) die zal voorkomen in de Notificatie die overeenkomt met de gecontroleerde ASR.

Bijvoorbeeld, de anomaliecode die overeenkomt met het vorige voorbeeld van inhoudscontrole is 00011-051.

Noteer tenslotte dat sommige controles gemeenschappelijk zijn voor verschillende sectoren/ scenario's, terwijl andere specifiek zijn.