Personeelsbestand via LDM/Webservice dimonaDistribution WSCentralPersonnelFile WSDimona
Versie 0.0
Datum 10-03-2010
Verspreiding
0.1
11-03-2010
Werkgroep
0.5 0.6
01-04-2010 01-09-2010
Werkgroep Website
Status: werkdocument
Verschillen met vorige versie Basis document ‘A950__L950_Personeelbestand_basisdocumentatie. doc’ Aanpassingen na introductie Dimona New die de nieuwe technologie ondersteunt Uitwerking mutaties Extra codes ‘aard werknemer’ & ‘Channel’
1 2
3
4 5
Inhoudsopgave Doel, functionele beschrijving bericht en samenhang met andere berichten............3 Raadplegen van het personeelsbestand .....................................................................5 2.1 Technische uitwerking ......................................................................................5 2.2 Schematische weergave raadpleging ................................................................5 2.2.1 Scenario 1: Syntax- en veiligheidsproblemen...........................................5 2.2.2 Scenario 2: Integratieproblemen bij leverancier of bestemmeling ...........6 2.2.3 Scenario 3: De voorlegging wordt doorgestuurd ......................................6 2.3 Raadpleging ......................................................................................................6 2.3.1 Specifieke opmerkingen zones routering..................................................6 2.3.2 Beschrijving zones gegevensgedeelte.......................................................7 2.4 Antwoord ..........................................................................................................7 2.4.1 Beschrijving zones gegevensgedeelte.......................................................7 2.5 Semi-online .......................................................................................................7 2.5.1 Verschil online en semi-online antwoorden .............................................7 2.5.2 Uitwerking ................................................................................................7 Mutaties van het personeelsbestand..........................................................................8 3.1 Schematische weergave mutaties......................................................................8 3.1.1 Scenario 1: Syntax- & Veiligheidsproblemen ..........................................8 3.1.2 Scenario 2: Integratieproblemen bestemmeling........................................8 3.1.3 Scenario 3: De voorlegging wordt doorgestuurd ......................................9 3.2 Distributierecord ...............................................................................................9 3.2.1 Specifieke opmerkingen uitwisselingsinformatie KSZ-Klant ..................9 3.2.2 Beschrijving zones gegevensgedeelte.....................................................11 Feedback via status ................................................. Error! Bookmark not defined. Voorbeelden............................................................ Error! Bookmark not defined.
1
Doel, functionele beschrijving bericht en samenhang met andere berichten
Het personeelsbestand is een gegevensbank van contracten (arbeidsovereenkomsten) tussen werkgevers en werknemers die gevoed wordt door de Dimona-aangiften. Sinds 1 januari 2003 zijn alle werkgevers verplicht om Dimona-aangiften te doen1. In het personeelsbestand kan men het resultaat van de oplading van de Dimonaaangiften zien. Het personeelsbestand is een voorstelling van het papieren personeelsregister. Het heeft echter niet dezelfde juridische weerslag.2 Een Dimona-aangifte, een onmiddellijke aangifte van tewerkstelling, is een elektronisch bericht waarmee de werkgever de Rijksdienst voor Sociale Zekerheid (RSZ) of de Rijksdienst voor Sociale Zekerheid van de provinciale en plaatselijke overheidsdiensten (RSZPPO) op de hoogte brengt van een indiensttreding of uitdiensttreding van een werknemer. Met de originele Dimona-aangiften bedoelen we de aangiften zoals die zijn ingegeven door de werkgever, zonder aanpassingen door de RSZ(PPO). Deze consultatie kan gebeuren van zodra de aangifte gedaan is. Het gebruik van Dimona en het personeelsbestand brengt een grote vereenvoudiging met zich mee die zich op meerdere vlakken situeert: • Er is een vrijstelling van het bijwerken van het papieren personeelsregister. • Tevens is er een afschaffing van het verplicht opsturen van studentencontracten naar de Inspectie van de Sociale Wetten van de FOD Werkgelegenheid, Arbeid en Sociaal Overleg. • Er is ook een afschaffing van het individueel document (thans verplicht indien personeel op verschillende plaatsen tewerkgesteld wordt). • Ook is er een vereenvoudiging van het speciaal personeelsregister (enkel indien personeel op meer dan 1 vaste plaats tewerkgesteld wordt). • Bovendien krijgen alle betrokken instellingen via het netwerk van de sociale zekerheid automatisch de betreffende gegevens doorgestuurd. Dit spaart zowel schrijfwerk als opvolging. De Dimona-aangiften kunnen ingediend worden via verschillende communicatiekanalen: via het internet, via bestandsoverdracht (FTP en ISABEL) en via de vocale server (te bereiken via het nummer van het Contact Center Eranova: 02-511 51 51). Bepaalde personen krijgen toegang tot de gegevens die op hun van toepassing zijn. Hiervoor moeten er, voor men toegang krijgt tot de elektronische diensten, verschillende stappen doorlopen worden. Zo dient er een lokale beheerder aangesteld te worden die dan een unieke gebruikersnaam en een wachtwoord krijgt, waarmee hij toegang krijgt tot het beveiligde gedeelte van de site. Voor meer informatie in verband met de aangifte zelf kan men terecht op het portaal www.sociale-zekerheid.be of bij het Contact Center Eranova.
1
Er zijn enkele kleine uitzonderingen, zie KB 5.11.2002 in BS 20.11.2002.
2
KB 25.02.2003 in BS 05.03.2003
De informatie in het Personeelsbestand is op verschillende manieren toegankelijk. Men kan on line de gegevens raadplegen via het portaal of langs de Kruispuntbank. Of men kan mutaties ontvangen op regelmatige/dagelijkse basis via de Kruispuntbank. In dit document betreft het enkel de toegangen via de Kruispuntbank via XML. In het eerste deel betreft het de (semi-)online raadpleging (via Webservice), de ontwikkelingen dienen hier door de instelling zelf gedaan te worden, maar de raadpleging heeft wel dezelfde functionaliteiten als de raadpleging via het portaal. Anderzijds gaat het in het tweede deel over de mutaties (full XML) die op regelmatige basis overgemaakt worden aan de geïnteresseerde instellingen.
2 Raadplegen van het personeelsbestand Consultatie van het personeelsbestand kan on line of semi-online3. Er kan gevraagd worden welke werknemers actief waren gedurende de opgevraagde periode, ook al was er voor de betreffende periode geen wijziging van het contract. Voor contracten die begonnen zijn vóór de gevraagde periode, zijn dat de contracten die doorlopen gedurende de gevraagde periode. Die contracten kunnen op het moment van consultatie nog altijd doorlopend zijn of beëindigd na de gevraagde periode. Tevens is het mogelijk om contracten in de toekomst of het verleden te zien. Dit betekent dat contracten consulteerbaar zijn die reeds afgesloten zijn, maar ook contracten die nog niet begonnen zijn. Ten slotte is het ook mogelijk om de geschrapte contracten te bekijken.
2.1 Technische uitwerking Op de website van de KSZ staan uitgebreide documentatie met beschrijving van de verschillende stappen om een verbinding tot stand te brengen met de beschikbare webservices. Te raadplegen via ‘Algemene documentatie webservices’4
2.2 Schematische weergave raadpleging 2.2.1 Scenario 1: Syntax- en veiligheidsproblemen Voorlegging KSZ
ISZ Antwoord
De KSZ ontvangt een voorlegging van de ISZ en controleert deze. De voorlegging wordt verworpen omwille van veiligheidsproblemen, syntactische problemen. Het antwoord blijft beperkt tot een status gedeelte. Hier worden geen business gegevens overgemaakt, en is een definitief antwoord. 3
Een online voorlegging, gevolgd door een tussentijds online antwoord en een batch definitief antwoord. 4
Algemene documentatie webservices: http://www.ksz.fgov.be/nl/bcss/page/content/websites/belgium/services/docutheque/webservice s_architecture/Documentation-web.html
2.2.2 Scenario 2: Integratieproblemen bij leverancier of bestemmeling Voorlegging KSZ
ISZ Antwoord
De KSZ ontvangt een voorlegging van de ISZ en controleert de voorlegging. De voorlegging wordt verworpen omwille van problemen met de controle legale context bij de ISZ of RSZ(PPO). Het definitieve antwoord is een antwoord met enkel een status waarin aangegeven wordt dat de persoon niet gekend is in de juiste legale context
2.2.3 Scenario 3: De voorlegging wordt doorgestuurd
voorlegging ISZ
voorlegging KSZ
antwoord
RSZ(PPO) antwoord
De KSZ ontvangt een voorlegging van de ISZ en controleert de voorlegging. De voorlegging wordt niet verworpen. De KSZ stuurt de voorlegging naar de RSZ(PPO). De KSZ ontvangt een definitief positief of negatief antwoord van de RSZ(PPO) en stuurt dit door naar de ISZ. Indien het gaat om een positief antwoord, wordt een antwoord gegeven met een gegevensgedeelte dat het antwoord op de voorlegging bevat. Indien het gaat om een negatief antwoord wordt enkel een status teuggegeven met de reden van niet-antwoord.
2.3
Raadpleging
2.3.1 Specifieke opmerkingen zones routering Dit wordt specifiek afgestemd met klant, en in een blok ‘KlantenInformatie’ uitgewisseld
2.3.1.1 Soort_aanvraag Er zijn 2 soorten opvragingen mogelijk via de aangeboden webservices: - werkgever-werknemer relatie
- gedetailleerde aangifte gegevens
2.3.2 Beschrijving zones gegevensgedeelte Todo .
2.4 Antwoord Todo .
2.4.1 Beschrijving zones gegevensgedeelte
2.5 Semi-online Voor de consultatie van zeer grote werkgevers in het personeelsbestand of lange carrières is een semi-online opvraging aangewezen. De vraag wordt online gesteld, eerst volgt online een ontvangstbevestiging en later via een bestand een volledig antwoord.
2.5.1 Verschil online en semi-online antwoorden Door de beperking in lengte van de on-lineberichten is een online antwoord niet altijd volledig vanaf de eerste keer, ondanks het feit dat meerdere tewerkstellingen kunnen worden meegegeven in één antwoord. Deze situatie doet zich vooral voor bij personen die veel interimopdrachten aanvaarden of een lange carrière achter de rug hebben.
2.5.2 Uitwerking Todo
3
Mutaties van het personeelsbestand
In het personeelsbestand bestaat 1 record per arbeidsrelatie, dit is een relatie INSZInschrijvingsnummer-Deelentiteit-Periode-Paritair Comité, ongeacht hoeveel aangiften er voor die relatie al gebeurd zijn. Als er een wijziging is aan één van deze gegevens wordt er een mutatie gegenereerd. Een wijziging in OriolusValidatiecode zal ook resulteren in een mutatie, een naamswijziging echter niet. Elke dag wordt er een mutatie verstuurd van de laatste situatie van elke gewijzigde en gevalideerde arbeidsrelatie (niet-gevalideerde relaties worden niet gemuteerd). Bij elke aangifte wordt de laatst gevalideerde situatie opgestuurd. In 2006 werden de mutatieberichten uitgebreid met een gegevensblok “tijdsregistratie”, die een begin- en einduur van tewerkstelling bevatten voor extra’s in de horeca, interim, land- of tuinbouw. Een wijziging in deze gegevens veroorzaakt ook een mutatie, voor bestemmelingen die de betreffende gegevens niet krijgen, kan het daardoor soms wel lijken alsof er geen aanleiding was voor een mutatie.
3.1 Schematische weergave mutaties Een mutatie kan door de KSZ naar meerdere bestemmelingen doorgestuurd worden.
3.1.1 Scenario 1: Syntax- & Veiligheidsproblemen
Voorlegging KSZ
RSZ(PPO) Antwoord
De KSZ ontvangt een voorlegging van RSZ(PPO) en controleert de voorlegging. De voorlegging wordt verworpen omwille van veiligheidsproblemen (zie LDM) of syntactische problemen. Het antwoord blijft beperkt tot een antwoord met een status waarin het probleem wordt beschreven.
3.1.2 Scenario 2: Integratieproblemen bestemmeling
Voorlegging KSZ
RSZ(PPO) Antwoord
De KSZ ontvangt een voorlegging van de RSZ(PPO) en controleert de voorlegging. De voorlegging wordt verworpen omwille van problemen met de integratiecontrole van de bestemmeling(en). Naar andere bestemmelingen kan de mutatie nog doorgestuurd worden als voor die bestemmelingen aan de integratiecontrole voldaan wordt.
3.1.3 Scenario 3: De voorlegging wordt doorgestuurd Voorlegging ISZ RSZ(PPO)
KSZ Antwoord
Distributie ISZ
De KSZ ontvangt een voorlegging van de RSZ(PPO) en controleert de voorlegging. De voorlegging wordt niet verworpen. De KSZ stuurt een antwoord naar de RSZ(PPO) waarin vermeld wordt dat de voorlegging doorgestuurd is (statuscode: DISTRIBUTION_SUCCESFULL). De KSZ geeft niet aan naar welke bestemmelingen de voorlegging is doorgestuurd. Naar de ISZ stuurt de KSZ een distributie. Dit zijn mutaties voor de dossiers die geïntegreerd zijn in het verwijzingsrepertorium van de Kruispuntbank.
3.2 Distributierecord Onderstaande beschrijving geeft een beeld van de beschikbare data en velden en businessregels, dit is geen technisch bindende documentatie. Daarvoor wordt verwezen naar de specifieke schema’s die door de KSZ per klant ter beschikking gesteld worden.
3.2.1 Specifieke opmerkingen uitwisselingsinformatie KSZ-Klant Hieronder volgt een voorbeeld van de informatie die kan uitgewisseld worden tussen de KSZ en de Klant, dit is indicatief, en dient afgestemd te worden bilateraal met de klant Een mogelijkheid kan zijn:
-
informationSuplier
-
informationCustomer
o ssin : Het gevalideerde INSZ van de werknemer voor deze dimonaPeriode. Dit kan eventueel afwijken van de oorspronkelijk aangegeven gegevens door de werkgever -
informationCBSS
3.2.2 Beschrijving zones gegevensgedeelte Hier worden de mogelijke zones beschreven die meegedeeld worden in het gegevensgedeelte. Per klant wordt dit afgestemd op de behoeftes en de machtiging van het Sectoraal Comité en worden desgewenst bepaalde datavelden niet meegedeeld en door de KSZ gefilterd. Het algemene schema van het datagedeelte ziet er als volgt uit (afgestemd op het schema: dimonaMutations):
-
MutationTrigger : aanleiding van de mutatie. Kan de volgende waarden bevatten: DimonaDeclaration, Reprise of ReIdentification
-
ProcessingDate : datum van verwerking van de aangifte
-
ChildBenefitFund
Dit element bevat informatie over het kinderbijslagfonds van de werkgever waarop de mutatie betrekking heeft. FundID : nummer van het fonds. FileNbr : dossniernummer van de werkgever binnen het kinderbijslagfonds. - FundOfficeID : nummer van het bureau van het kinderbijslagfonds van de werkgever. Ten behoeve van RKW worden het nummer van het kinderbijslagfonds van de werkgever, het aansluitingsnummer van de werkgever bij het kinderbijslagfonds en de code van het bevoegde bureau toegevoegd. Indien een werkgever aangesloten is bij meerdere kinderbijslagfondsen wordt er 999 ingevuld en wordt de zone kinderbijslagdossier opgevuld met 999999999999. -
-
ssinAmbiguityIndicator : duidt aan of de betrokken werknemer al dan niet een INSZ met “flag bis” heeft. Dit element kan de waarden true of false aannemen.
-
employerId
Dit element bevat informatie over de werkgever waarop de mutatie betrekking heeft. -
NOSSRegistrationNbr : NOSS of voorlopig NOSS van de werkgever (enkel indien het gaat om een RSZ-werkgever)
-
NOSSLPARegistrationNbr : NOSS van de RSZPPO-werkgever (enkel voor PPO-werkgevers) Meer informatie over de werkgever is beschikbaar in het werkgeversrepertorium via het portaal of via de Kruispuntbank. Voor meer informatie verwijzen wij naar de website van de Kruispuntbank (bericht A701,L raadpleging op basis van inschrijvingsnummer of uniek ondernemingsnummer of webservice EmployerAttestationService) of het portaal van de sociale zekerheid.
-
CompanyID : ondernemingsnummer van de werkgever. Een werkgever kan zijn aangifte doen met zijn KBO-nummer (companyID), RSZ(PPO) zal het nummer intern converteren voor verdere verwerking. Bij
een aangifte met een KBO-nummer waarvoor geen RSZ(PPO)-nummer gekend is, wordt een voorlopig stamnummer gecreëerd. Een werkgever kan dus al werknemers aangeven zonder al een bij RSZ(PPO) gekend KBO-nummer te hebben. In principe wordt ofwel het KBO-nummer ofwel het RSZ(PPO)-nummer aanvaard in de aangifte. -
-
IdentificationInProgress : duidt aan of het identificatieproces van de werkgever in het werkgeversrepertorium al dan niet afgerond is. Dit element kan de waarden true of false aannemen.
dimonaDeclaration
Dit element bevat informatie over de aangifte die aan de basis van de mutatie ligt. - DimonaDeclarationId : bevat het aangiftenummer.
Indien de mutatie veroorzaakt is door een wijziging van het inschrijvingsnummer (NOSS(LPA)RegistrationNbr) wordt dit veld niet ingevuld, daar dit ook geen echte ‘aangifte’ betreft. -
ReceptionDate : bevat de datum van ontvangst van de aangifte verricht door de werkgever (of het sociaal secretariaat). Formaat 2008-1121T09:30:47Z.
-
DeclarationType : Type aangifte. Kan de waarden I(in), O(out), U(update), C(cancel) of D(delete) aannemen. De code van de laatste aangifte duidt aan of het om een originele aangifte, een wijziging of een schrapping gaat. Alleen de data van indiensttreding en van uitdiensttreding mogen worden gewijzigd. Een wijziging van de indiensttredingsdatum kan enkel door de datum te vervroegen. Als de indiensttredingsdatum later valt, volgt eerst een annulatie en daarna een nieuwe aangifte. Een wijziging van de uitdiensttredingsdatum kan ook enkel door de datum te vervroegen. Als de uitdiensttredingsdatum later valt, volgt een nieuwe indiensttredingsaangifte voor de extra periode. Een fysieke schrapping verwijdert alle gegevens die geregistreerd werden voor een contract (dimonanummer). Deze gegevens zijn dan ook in de historiek niet meer zichtbaar.
-
Channel : inputkanaal van de aangifte. Kan de volgende waarden bevatten: FTP, MQL (MQlink), ISA (Isabel), WNS (niet-beveiligd web), WSE (beveiligd web), WSM (beveiligd web Multi Dimona), VOC (vocal server), SMS en tijdelijk de dubbele inputkanalen via het klassieke dimonasysteem: FTP-C, MQL-C, ISA-C. 2 extra kanalen kunnen worden gebruikt; SFTP en MTOM (webservice).
-
FormVersionNbr : versienummer van het glossarium.
-
NaturalPerson : bevat de gegevens van de werknemer die meegedeeld werden in de aangifte. Dit element kan dus enkel aanwezig zijn voor de mutaties die het gevolg zijn van een aangifte Dimona IN. Deze gegevens zijn niet gevalideerd door RSZ(PPO) en kunnen dus afwijken van de gevalideerde gegevens op andere plaatsen in het bericht, zoals bijvoorbeeld naturalPerson>ssin (= input werkgever) <> informationCustomer>ssin (gevalideerde ssin door RSZ(PPO).
-
dimonaImpactReport
Dit element bevat informatie over de gemuteerde periodes. -
DimonaPeriodId : identificatienummer van de periode.
Het Dimonanummer (DimonaPeriodId) wordt toegekend aan de "origineel indienst"-aangifte door de RSZ(PPO) bij een onmiddellijke aangifte van tewerkstelling. Dit nummer identificeert een contract tussen een werknemer en zijn werkgever. De werkgever dient dit nummer te gebruiken voor alle gegevenswijzigingen van de aangifte -
JointCommissionNbr : paritair comité van de periode. Het nummer van het paritair comité of subcomité waaronder de werkgever ressorteert. Voor de paritaire comités: 3 cijfers onder de vorm NNN. Voor de paritaire subcomités: 3 cijfers, een punt en 2 cijfers onder de vorm NNN.NN. Voor bepaalde sectorale tewerkstellingsakkoorden met een beperkt toepassingsgebied t.o.v. het paritair (sub)comité: 3 cijfers, een punt en 3 cijfers onder de vorm NNN.NNN. De lengte van de zone is volgens de KSZ-standaarden. "PPO" voor de werkgevers van de lokale en provinciale overheden en de intercommunales (RSZ-PPO).
-
WorkerType : type werknemer van de periode. Code die het type of de aard van de werknemer aangeeft met de volgende waarden: - STU: als de aangifte een student betreft (in alle sectoren) - OTH: voor alle werknemers (uitgezonderd studenten) in alle sectoren buiten de bouwsector - RTA: voor alle erkende leerlingen en gelijkgestelden in de bouwsector - BCW: voor alle andere werknemers (uitgezonderd studenten) in de bouwsector - IVT: individuele beroepsopleiding in alle sectoren - EXT: extra in de land- en tuinbouw en horeca - STX: student als extra in de land- en tuinbouw en horeca - TEA: onderwijzend personeel (code enkel geldig bij aangiftes RSZPPO) - DWD: werknemer niet onderworpen aan RSZ-Bijdragen. Hiervoor moet een Dimona worden ingediend maar geen DmfA. Dit type werknemer moeten verplicht worden gebruikt voor alle werknemers die onder deze categorie vallen, behalve voor de werknemers van het type IVT waarvoor de situatie ongewijzigd blijft.
-
SubEntityNbr : Deelentiteit van de werkgever voor de periode. Voorbehouden voor de publieke sector. Code toegekend aan de deelentiteit van de werkgever, na akkoord van de RSZ.
-
UsingEmployer UsingEmployerName : benaming van de gebruiker van een uitzendkracht. UsingEmployerCompanyID : ondernemingsnummer van de gebruiker van een uitzendkracht. UsingEmployerNOSSRegistrationNbr : RSZ-nummer van de gebruiker van een uitzendkracht.
-
ConstructionControlCards FirstMonthC32ANbr : nummer van de C3.2A-kaart die toegekend werd aan de werknemer voor de beginmaand van zijn Dimona-periode. NextMonthC32ANbr : nummer van de C3.2A-kaart die toegekend werd aan de werknemer voor de maand volgend op de beginmaand van zijn Dimona-periode.
-
StudentPlaceOfWork
-
Denomination : benaming van de plaats van tewerkstelling van een student. Street : straat van de plaats van tewerkstelling van een student. HouseNbr : huisnummer van de plaats van tewerkstelling van een student. PostBox : postbus van de plaats van tewerkstelling van een student. ZIPCode : postcode van de plaats van tewerkstelling van een student. City : gemeente van de plaats van tewerkstelling van een student. Country : landcode van de plaats van tewerkstelling van een student.
DimonaPeriodBefore: situatie van de periode vóór de mutatie. StartingDate: aanvangsdatum van werkperiode. StartingHour: deze zone komt enkel voor als het een aangifte van een gelegenheidswerknemer betreft. (Per mutatie kan er maar 1 tijdsperiode voorkomen). EndingDate: einddatum van werkperiode. EndingHour: deze zone komt enkel voor als het een aangifte van een gelegenheidswerknemer betreft. (Per mutatie kan er maar 1 tijdsperiode voorkomen). ServiceType : S = Small = 5 uur; L = Large = 11 uur Komt voor in combinatie met het beginuur van tewerkstelling van gelegenheidswerknemers, als alternatief voor het preciese einduur. DimonaPeriodBefore is ingevuld indien DeclarationType = O,U,C. Opmerking : Betreffende gelegenheidsarbeiders die een gewerkte periode hebben die middernacht overschrijdt: dit geldt als één gepresteerde dag. Tot nu toe werden dergelijke aangiften in de mutaties vertaald naar eenzelfde begin- en einddatum waarbij het uur horende bij de einddatum groter werd dan 24h. Bijvoorbeeld: 13/2/2010 22:00 - 14/2/2010 03:00 werd doorgegeven als 13/2/2010 22:00 - 13/2/2010 27:00. Het is historisch zo gegroeid dat een dag meer dan 24u kan tellen. Doch dit is niet meer bruikbaar in de huidige technologie. In deze nieuwe mutaties komt dus de realistische effectieve tijdsduur: 13/2/2010 22:00 - 14/2/2010 03:00 Het is hier belangrijk dat de sociale rechten van de werknemers correct worden toegekend. Voor een dergelijke gewerkte periode moet dit blijven beschouwd worden als één gewerkte dag met name de begindatum, en niet als 2 gewerkte dagen.
-
DimonaPeriodAfter: situatie van de periode na de mutatie. StartingDate StartingHour EndingDate EndingHour ServiceType DimonBeriodAfter is ingevuld indien DeclarationType = I, O, U. Opmerking : Indien de mutatie veroorzaakt is door een wijziging van het inschrijvingsnummer (NOSS(LPA)RegistrationNbr) en de mutatie dus geen echte aangifte betreft, is de DimonBeriodBefor = DimonBeriodAfter en DeclarationType = type van laatste aangifte.
3.2.3 De mapping van de xml-tags De mapping van de bovenstaande xml-tags met de vroeger gebruikte naamgeving in de A1-berichten van personeelsbestandmutaties (A950/A850) dimonaDistribution
A850
A950
OPM
mutationTrigger
processingDate
Timestamp
childBenifitFund
childBenifitFund
fundID
fundID
fileNbr
fileNbr
fundOfficeID
fundOfficeID
ssinAmbiguityIndicator
OriolusValidationCode
employerId
nossRegistrationNbr
Inschrijvingsnummer
NOSSRegistrationNbr
nossLPARegistrationNbr
Inschrijvingsnummer
NOSSRegistrationNbr
companyID
Ondernemingsnummer
CompanyID
identificationProgress
dimonaDeclarationId
Nummer ontvangstbewijs
receptionDate
Datum & uur van ontvangst
declarationType
Aangiftecode
LastDImonaAction
channel
Code oorsprong
5
formVersionNbr
Versienummer aangifte
naturalPerson
ssin
workerName
workerFirstName
workerInitial
workerBirthdate
workerBirthplace
workerBirthplaceCountry
workerSex
workerStreet
workerHouseNbr
workerPostBox
workerPostalCode
workerCity
workerCountry
nationality
dimonaImpactReport
dimonaPeriodId
Dimona‐nummer
DimonaNbr
dimonaFeatures
jointCommissionNbr
Paritair comité
jointCommissionNbr
workerType
Type werknemer
KindOfWorker
4
1 2
subEntityNbr
Deelentiteit
Subentity
usingEmployer
usingEmployerName
InterimUserName
usingEmployerCompanyID
Benaming gebruiker Ondernemingsnummer gebruiker
usingEmployerNOSSRegistrationNbr
Inschrijvingsnummer gebruiker
CompanyID usingEmployerNOSSRegistrationN br
constructonControlCards
firstMonthC32ANbr
Nummer 1 C3.2A
nextMonthC32ANbr
Nummer 2 C3.2A
studentPlaceOfWOrk
StudentWorkPlace
denomination
Naam van de onderneming student
Name
address
street
Adres van de onderneming
Address/Street
houseNbr
postBox
Postbus
PostBox
postalCode
Postcode
PostCOde
city
Plaats
Town
country
Landcode
CountryCode
dimonaPeriodBefore
startingDate
Datum indiensttreding
BeginDate
startingHour
BeginTime
endingDate
Datum uitdiensttreding
EndDate
endingHour
EndTime
serviceType
DurationCode
dimonaPeriodAfter
startingDate
Datum indiensttreding
BeginDate
startingHour
BeginTime
endingDate
Datum uitdiensttreding
EndDate
endingHour
EndTime
serviceType
DurationCode
Commentaar
3
Waarde XML Waarde A850 Waarde A950
(1) bij een scenario Wijziging RSZ-nummer
Niet aanwezig
0
(2) declarationType
I,O,U,C,D
1,2,3,4,S
(3) endingHour
tot 23u59m59s STU STU IVT IBO EXT EXT STX STX OTH 3 blanco’s RTA 035 BCW 000 TEA TEA DWD DWD
(4) workerType
3
1,2,3,4,S tot 47u59m59s STU IBO EXT STX 3 blanco’s 035 000 TEA DWD
(5) Channel
FTP MQL ISA WNS WSE WSM DBI VOC SMS FTP-C MQL-C ISA-C SFTP MTOM
3 3 4 2 2 2 2 1 5 3 3 4 3 6
FTP FTP Isabel WebSite WebSite WebSite WebSite Modif.Int C-ZAM FTP FTP Isabel FTP WebService
4 Feedback via status todo
5 Voorbeelden -
todo
5.1.1
