Inhoud
1. Inleiding...2
1.1. De structuur van de records ...2
1.2. Het gegevensschema ...2
1.2.1.De niveaus ...2
1.2.1.1. Niveau 0 ...2
1.2.1.2. Niveau 1 ...3
1.2.1.3. Niveau 2 ...3
1.2.1.4. Niveau 9 ...3
1.2.2.Het gegevensblok ...3
1.3. Het glossarium ...3
1.3.1.Identificatie...3
1.3.2.Versie...3
1.3.3.Naam van het gegeven...4
1.3.4.Beschrijving van het gegeven...4
1.3.5.Toegelaten domein ...4
1.3.6.Type ...4
1.3.7.Lengte ...4
1.3.8.Aanwezigheid...4
1.3.9.Foutcode ...4
1.3.10. Drukvorm ...5
1.3.11. Afkortingen...5
1.4. Bescherming van de gegevens ...5
1.5. Inlichtingen...5
2. Beschrijving van het bestand ...7
2.1. Technische kenmerken...7
2.1.1.Algemeen...7
2.1.2.Voorafgaandelijke aanvraag en testperiode ...7
2.1.3.De verschillende kanalen...8
2.1.3.1. FTP ...8
2.1.3.2. ISABEL ...9
2.1.4.Digitale handtekening ...10
2.2. Structuur van de records ...11
2.2.1.Indicatief gedeelte...11
2.2.2.Gegevensgedeelte...13
3. Gegevensschema...14
3.1. Niveau 0 : Verzender ...14
3.2. Niveau 1 : Werkgever ...14
3.3. Niveau 2 : Aangifte ...15
4. Uitgevoerde controles ...18
4.1. Wijzigingen...19
4.2. Schrapping...19
4.3. Voorwaarden...20
1. Inleiding
Deze inleiding heeft als doel een overzicht te geven van de technische kenmerken en de opgestelde procedure voor de transmissie naar de RSZ van de onmiddellijke aangiften van tewerkstelling op elektronische wijze.
1.1. De structuur van de records
De keuze wordt overgelaten aan de gebruiker. Hij kan kiezen tussen een vaste recordstructuur of een variërende recordstructuur waarin elk record bestaat uit twee delen :
• het indicatief gedeelte
• het gegevensgedeelte
In de vaste recordstructuur hebben alle records dezelfde lengte terwijl bij de variërende recordstructuur het recordeinde wordt aangegeven door een speciaal teken (CR/LF).
Meer details vindt u in het hoofdstuk 2.2 ‘Structuur van de records’.
Elk record komt overeen met een gegevensblok van het gegevensschema.
Het indicatief gedeelte laat toe elk record (of gegevensblok) te identificeren. Meer details over het indicatief gedeelte vindt u in de beschrijving van het bestand.
Het gegevensgedeelte bevat één of meerdere gegevens uit een bepaald gegevensblok, (eventueel) gevolgd door een filler-gedeelte.
Een gegeven bestaat uit een zonenummer gevolgd door informatie aangaande deze zone.
Wij verwijzen opnieuw naar de beschrijving van het bestand voor meer details over de technische kenmerken en de structuur van de records.
1.2. Het gegevensschema
Het gegevensschema verduidelijkt de gegevensblokken. Op dit moment moet een bestand 4 verschillende niveaus bevatten waarvan sommige meerdere keren kunnen voorkomen.
1.2.1. De niveaus
1.2.1.1. Niveau 0
Dit zijn de identificatiegegevens betreffende de verzender van het bestand. Dit niveau is uniek voor een gegevensbestand en bevindt zich aan het begin van de boodschap, voor alle andere niveaus.
1.2.1.2. Niveau 1
Dit zijn de gegevens aangaande de werkgever. Men kan verschillende niveaus 1 vinden in de boodschap (verschillende werkgevers) maar men kan ook eenzelfde werkgever verschillende keren terugvinden in dezelfde boodschap doch niet consecutief.
1.2.1.3. Niveau 2
Dit zijn gegevens aangaande de identificatie van de aangifte, gegevens betreffende de werknemer, het contract en, in voorkomend geval, de gebruiker (voor interim- kantoren). Er moet minstens één niveau 2 zijn per niveau 1, maar er kunnen er ook meerdere zijn (de werkgever heeft meerdere contracten getekend met verschillende werknemers).
1.2.1.4. Niveau 9
Dit niveau bevat totalen m.b.t. de gegevens in het bestand. Dit niveau is uniek en bevindt zich aan het einde van het bestand, na alle andere niveaus.
1.2.2. Het gegevensblok
In het gegevensschema wordt een gegevensblok geïdentificeerd door drie numerieke posities. De eerste positie geeft het niveau aan waartoe het blok behoort en de twee volgende posities geven het nummer aan dat werd toegekend aan het blok in zijn niveau.
1.3. Het glossarium
Het glossarium geeft een beschrijving van elk gegeven dat opgenomen is in het gegevensschema.
Per pagina beschrijft men één gegeven. Elke pagina bevat de hieronder besproken rubrieken.
1.3.1. Identificatie
Het identificatienummer van een gegeven (of zonenummer) bestaat uit vijf numerieke posities. Dankzij dit nummer kan men elk gegeven op eenduidige wijze klasseren.
Het identificatienummer heeft de volgende structuur : positie 1 geeft het niveau aan waartoe het gegeven behoort
posities 2-3 geven het bloknummer aan waartoe het gegeven in een niveau behoort posities 4-5 geven het nummer aan van de zone eigen aan het gegeven in een blok.
1.3.2. Versie
Het versienummer laat ons toe een historiek van de wijzigingen bij te houden. Het versienummer bestaat uit drie posities waarvan de eerste twee het jaar van de wijziging aangeven en de laatste een volgnummer in dat jaar. Het versienummer geeft een aanwijzing over het jaar waarin bepaalde wijzigingen van toepassing zijn geworden.
1.3.3. Naam van het gegeven
De naam geeft kort de inhoud weer van het gegeven. Het is ook deze naam die men terugvindt in het gegevensschema.
1.3.4. Beschrijving van het gegeven
De beschrijving geeft de betekenis van het gegeven meer uitgebreid weer.
1.3.5. Toegelaten domein
Het toegelaten domein specificeert de toegelaten waarden voor het gegeven. Onder deze rubriek vindt men ook verwijzingen naar de bijlagen van het glossarium.
1.3.6. Type
Het type gegevens geeft aan of het gegeven numerieke (cijfers) of alfanumerieke (cijfers, HOOFDLETTERS, speciale tekens) tekens bevat.
Andere alfanumerieke tekens dan HOOFDLETTERS en toegelaten speciale tekens zullen vertaald worden volgens de tabel in bijlage 8.
Karakters die niet in de tabel staan (met andere hexadecimale waarden), zullen automatisch worden vervangen door een blanco (ASCII Hex 20).
1.3.7. Lengte
Elk gegeven heeft een vaste lengte die volledig opgevuld moet worden. Is het gegeven numeriek, dan moet men de cijfers rechts uitlijnen en er nullen voor zetten. Is het gegeven alfanumeriek, dan moet men de tekens links uitlijnen en er blanco’s achter zetten.
1.3.8. Aanwezigheid
De aanwezigheid van een gegeven kan zijn :
• Facultatief : Het staat de verzender vrij deze zone in te vullen
• Verplicht indien : De zone moet aanwezig zijn onder de vermelde voorwaarden
• Onmisbaar : De zone moet altijd aanwezig zijn 1.3.9. Foutcode
De foutcode bestaat uit 5 posities die de zone identificeren waarin de fout zich heeft voorgedaan, gevolgd door het fouttype in twee posities. De twee delen zijn gescheiden door een koppelteken.
De foutnummers 01 tot 09 zijn klassieke fouten.
Voorbeelden : 01 = zone niet aanwezig en verplicht 02 = zone niet numeriek
08 = niet in het toegelaten domein
De andere foutnummers hebben een betekenis die eigen is aan het gegeven.
De fouten aangeduid door een letter B zijn blokkerende fouten (d.w.z. dat het volledige bestand geweigerd zal worden als men één van deze fouten vindt). De fouten aangeduid met een P worden opgeteld en wanneer zij een bepaald percentage overschrijden, zal het volledige bestand geweigerd worden. De overige fouten leiden niet tot een eventuele weigering van het bestand.
1.3.10. Drukvorm
Onder deze rubriek geeft men het standaardformaat waarin het gegeven in kwestie afgedrukt moet worden. Deze voorstelling heeft niets te maken met de samenstelling van de gegevens op de magnetische drager.
De letter X wordt gebruikt om eender welk teken aan te geven (alfanumeriek).
De letter N wordt gebruikt om een cijfer aan te geven.
De letter Z wordt gebruikt om aan te geven dat de nullen zonder betekenis (voor de cijfers met betekenis) niet afgedrukt moeten worden.
Bepaalde speciale tekens kunnen eveneens aangeduid worden. (:/.-)
Het inschrijvingsnummer met zijn controlegetal wordt bv. weergegeven als ZZZZNNNN-NN
1.3.11. Afkortingen
In het glossarium gebruikt men soms de volgende afkortingen :
• JJ : de twee laatste cijfers van het jaar
• JJJJ : het jaar in vier posities met de eeuw
• MM : de maand [01;12]
• DD : de dag [01;31]
• [1;4] : geeft aan dat het gegeven een waarde heeft tussen de opgenomen gespecificeerde grenzen (hier zijn de mogelijke waarden 1, 2, 3 en 4).
1.4. Bescherming van de gegevens
In bijlage 4 bevindt zich de informatie over de digitale handtekening.
1.5. Inlichtingen
Voor meer inlichtingen in geval van technische problemen of problemen i.v.m. de organisatie van de bestanden, kan men contact opnemen met het contactcenter van 8.00 uur tot 17.00 uur, op het nummer
• 02/511.51.51 (Nl en Fr) - Contactcenter Eranova Of op de volgende e-mail adressen :
• Nl: contactcenter@eranova.fgov.be
• Fr: centredecontact@eranova.fgov.be
Contactadres : SmalS-MvM
Koninklijke Prinsstraat 102 1050 Brussel
2. Beschrijving van het bestand
2.1. Technische kenmerken
2.1.1. Algemeen
De gestructureerde bestanden worden verzonden als flatfile tekstbestanden, in ASCII formaat, 7-bits.
Er zijn drie verschillende kanalen langswaar bestanden kunnen worden verzonden, namelijk via ISABEL, FTP (analoge dialup 56K of leased-line, voorafgaandelijk af te spreken) en MQSeries. Alle systemen zullen 24 op 24 u actief zijn, 7 dagen op 7 behoudens onderhoudswerken.
Dit technisch deel omschrijft de wijze van klaarmaken van een gestructureerd bericht en het verzenden ervan. Het omschrijft niet hoe een gestructureerd bericht aan te maken of te interpreteren. De digitale handtekening wordt uitgelegd in bijlage 4.
2.1.2. Voorafgaandelijke aanvraag en testperiode
Het zal niet mogelijk zijn een gestructureerd bestand door te sturen voor DIMONA via FTP of ISABEL of MQSeries aan de RSZ zonder voorafgaandelijke inschrijving.
De procedure is de volgende :
⇒ contact opnemen met de SmalS-MvM met een verzoek tot verzenden van DIMONA's, en afspreken over de praktische modaliteiten (Isabel of FTP of MQSeries; dialup of leased line, te verwachten volume, afspreken tijdstip van verzending, afspraken personen die geautoriseerd zijn, digitale handtekening, paswoorden, ...). Voor een exemplaar van het inschrijvings- formulier : zie bijlage 5 ;
⇒ ontvangst van het vormcontroleprogramma (via diskette of via e-mail) ;
⇒ doorgeven (op diskette 3,5” HD niet gecomprimeerd of via e-mail) van testbestanden :
→ 1e fase : test met minimum 2 bestanden met de ontvangsbewijzen zoals gegenereerd door het vormcontroleprogramma. Elk bestand bevat indien mogelijk minimum 2, maximum 5 werkgevers met minimum 50, maximum 200 werknemers;
Wanneer de eerste test met goed gevolg beëindigd werd, volgt de tweede:
→ 2e fase : test door generatie van een DIMONA-bestand met bijbehorend ontvangstbewijs op basis van door de RSZ opgelegde gegevens.
⇒ als de bestanden correct zijn :
- kent de RSZ het verzendernummer toe;
- geeft de RSZ de paswoorden voor toegang tot de test-FTP directories INTEST en OUTTEST (toegang wordt verleend voor de omgeving Isabel door Isabel, de verzender moet zijn mailbox-ID aan de RSZ doorgeven), of voor MQSeries geeft de RSZ toegang tot de queues INTEST en OUTTEST;
→ 3e fase : test door testbestanden via FTP of Isabel of MQSeries te verzenden met de correcte naam, om de verbinding te testen.
⇒ als de laatste tests correct zijn :
Toekennen van directories IN en OUT voor toegang tot de FTP directories van DIMONA of toegang geven voor de reële omgeving van Isabel of toegang tot de MQSeries queueq IN en OUT;
Verzenden van definitieve DIMONA's.
Voor de contactpersonen, zie punt 1.5.
2.1.3. De verschillende kanalen
2.1.3.1. FTP
• Infrastructuur
Verzenden van DIMONA's vereist dat men zich op het RSZ-netwerk aansluit. Voor FTP kan dit gebeuren via een gewone dialup (analoog, tot 56K - V.90) of een leased line (voorafgaandelijk af te spreken). Bij een verbinding via een toegangsserver zijn er twee logons nodig, die beveiligd zijn met paswoorden. Het eerste paswoord geeft toegang tot het netwerk, het tweede op de FTP-server, alleen op de aan elke verzender toegewezen zones. In deze zones heeft elke verzender de volle lees- en schrijfrechten, evenals de R.S.Z.. Zones van andere verzenders zijn niet leesbaar noch wijzigbaar.
Een verbinding via een router is ook mogelijk, daarbij wordt de logon op het netwerk van de R.S.Z. volledig automatisch gedaan door de router. De logon voor de FTP- server blijft.
Voor het uitwisselen van bestanden met FTP zijn er per verzender twee directories ter beschikking :
⇒ IN De bestanden met de DIMONA-aangiften van de werkgevers
⇒ OUT Alle ontvangstbewijzen per verzonden bestand, evenals de definitieve berichten.
Er bestaat de mogelijkheid om de laatste versie van het vormcontrole- programma ook in deze directory OUT te plaatsen.
De directories INTEST en OUTTEST, gebruikt voor de erkenning, blijven beschikbaar voor tests voor de verzender. Hier dient steeds de extensie
“T” te worden gebruikt. Aangiftes met extensie “T” worden geweigerd in IN, aangiftes met extensie “R” worden geweigerd in de INTEST directory.
• Methode om aangiften te verzenden
Een bericht met één of meerdere aangiften wordt opgemaakt bij de verzender.
Elk verzonden bericht moet een unieke naam krijgen die op volgende wijze samengesteld is :
DIMD.123456.20050701.00001.052.N.T
DIMD is de naamaanduiding voor de aangiften van Dimona, de andere gegevens zijn de volgende :
Nummer verzender : 6 posities (verkregen van R.S.Z.) Datum van verzending : 8 posities (formaat JJJJMMDD)
Volgnummer per dag : 5 posities (van 1 tot 99999 met stappen van 1.) Versie : 3 posities (nummer van de versie gebruikt op
het moment van de creatie van het bestand (formaat JJK))
Handtekening : 1 positie (altijd Y; zie bijlage 4) Test-reëel : 1 positie : T(est) of R(eëel)
Dit bestand wordt getekend (zie bijlage 4). Daarna wordt een tweede bestand aangemaakt met dezelfde naam met als prefix GO en zonder inhoud. Er zijn dus drie bestanden :
DIMD.123456.20050701.00001.052.N.T : het bestand met de aangiften DIMS.123456.20050701.00001.052.N.T : het bestand met de
handtekening
GODIMD.123456.20050701.00001.052.N.T : het startbestand (leeg) Alle bestanden worden dan via FTP naar de RSZ gezonden, en steeds het GO-bestand als laatste; dit start de verwerking bij de RSZ. Als het verzonden bestand verwerkt is, wordt het door de RSZ gewist in de IN-directory. Zolang het nog aanwezig is in de IN-directory, is het niet verwerkt.
2.1.3.2. ISABEL
• Infrastructuur
Werken via het Isabel netwerk vereist een abonnement op Isabel met een Multibank + of een Isagate. Gelieve Isabel te contacteren voor meer informatie.
Een specifieke procedure om de handtekening te implementeren is niet toegevoegd voor Isabel, daar de standaardprocedure bij Isabel alle bestanden tekent. Het abonnement op Isabel bevat ook automatisch een digitaal certificaat, waarmee kan worden getekend.
• Methode om aangiften te verzenden
Een bestand met één of meerdere DIMONA aangiften wordt opgemaakt bij de verzender. Elk verzonden bestand moet een unieke naam krijgen die op volgende wijze samengesteld is :
DIMD.123456.20050701.00001.052.N.T
DIMD is de naamaanduiding voor de aangiften van Dimona, de andere gegevens zijn de volgende :
Nummer verzender : 6 posities (verkregen van R.S.Z.) Datum van verzending : 8 posities (formaat JJJJMMDD)
Volgnummer per dag : 5 posities (van 1 tot 99999 met stappen van 1.) Versie : 3 posities (nummer van de versie gebruikt op
het moment van de creatie van het bestand (formaat JJK))
Handtekening : 1 positie (altijd Y, handtekening is via Isabel) Test-reëel : 1 positie : T(est) of R(eëel)
De wijze van verzenden is verschillend naargelang een Multibank+ of een Isagate wordt gebruikt.
1. De gebruiker van een Multibank+ moet het bestand als getekende mail aan de RSZ verzenden. Het adres staat in het adresboek van Isabel (X.500). Daarna moet in de mail het volgende worden ingevuld: de naam van het bestand (DIMD.123456.20050701.00001.052.N.T) komt in de zone ‘subject’ van de mail body. Daarna wordt het bestand als attachment aan de mail gehecht. Slechts één attachment is toegelaten. Alvorens te verzenden, moet de mail worden getekend en gecomprimeerd. Hij mag niet worden geëncrypteerd.
2. De gebruiker van een Isagate moet vier bestanden creëren (de documentatie File API moet aan Isabel worden gevraagd). Het eerste bestand heeft als extensie ‘.inf’.
In het veld ‘Free_text’ moet de naam van het bestand (DIMD.123456.20050701.00001.052.N.T) worden geplaatst, in het veld
‘Recipient_Mailbox_ID’ de produktie mailbox_id van de RSZ (3003906800140), in het veld ‘To_Sign’ (Y:getekend), in het veld ‘To_Compress (Y:
gecomprimeerd), in het veld ‘To_Encrypt (N: niet geëncrypteerd). De volgende twee bestanden hebben als extensie ‘.dat’. Eén ervan is een Memo waarin één lijn staat : MEMO: DIMD.123456.20050701.00001.052.N.T (zoals in subject van het bestand ‘.inf’). De andere bevat de aangiftes DIMONA. Het vierde bestand heeft als extensie ‘.cmt’. Alle bestanden moeten in de directory EBOUT van de Isagate worden geplaatst. Meer gedetailleerde informatie over deze procedure bevindt zich in bijlage 7.
2.1.3.3. MQSeries
• Infrastructuur
Verzenden en ontvangen van DIMONA's vereist dat men zich op het RSZ-netwerk aansluit. Voor MQSeries gebeurt dit na installatie van de MQSeries software en na het openen van kanalen met de RSZ (voorafgaandelijk af te spreken).
Voor het uitwisselen van bestanden met MQSeries zijn er per verzender twee queues ter beschikking :
⇒ IN De bestanden met de DIMONA-aangiften van de werkgevers
⇒ OUT Alle ontvangstbewijzen per verzonden bestand, evenals de definitieve berichten.
De queues INTEST en OUTTEST, gebruikt voor de erkenning, blijven beschikbaar voor tests voor de verzender. Hier dient steeds de extensie
“T” te worden gebruikt. Aangiftes met extensie “T” worden geweigerd in IN, aangiftes met extensie “R” worden geweigerd in de INTEST queues.
• Methode om aangiften te verzenden
De methode is identiek aan het aangeven via FTP, in plaats van de bestanden in de directories te plaatsen, moeten ze in de queues IN of INTEST worden geplaatst. Om de ontvangstbewijzen en de definitieve berichten terug te krijgen, moeten de queues OUT en OUTTEST worden gescand. Ook hier is, identiek als voor FTP, de digitale handtekening verplicht mee te sturen als apart bestand.
2.1.4. Digitale handtekening
De informatie over de digitale handtekening bevindt zich in bijlage 4 en is van toepassing op alle gestructureerde berichten.
2.2. Structuur van de records De records zullen uit twee delen bestaan :
• Het indicatief gedeelte (14 posities)
• Het gegevensgedeelte (maximum 256 posities) 2.2.1. Indicatief gedeelte
Het indicatief gedeelte heeft een lengte van 14 posities en zal de volgende 4 zones bevatten :
volgnummer 1 6 posities volgnummer 2 5 posities
niveaunummer 1 positie
bloknummer 2 posities
• Het volgnummer 1 stijgt met 1 bij elke verandering van een werkgever (d.w.z. elke verandering aan het inschrijvingsnummer of het voorlopig nummer).
• Het volgnummer 2 stijgt met 1 bij elke verandering van een aangifte (d.w.z. elke verandering op het vlak van de aangifte, de werknemer, het contract of de gebruiker). Dit nummer wordt opnieuw op 0 gezet telkens het volgnummer 1 verandert (om de inlichtingen van niveau 1 te vermelden). Daarna herbegint men vanaf 1 (voor de inlichtingen van niveau 2).
De inhoud van de verschillende zones van het indicatief gedeelte verschilt naargelang het niveau.
• Voor het niveau 0 : de zones 1, 2 en 3 staan op 0, alleen het bloknummer is ingevuld
• Voor het niveau 1 : zone 1 is ingevuld, zone 2 staat op 0, de zones 3 en 4 zijn ingevuld
• Voor het niveau 2 : alles is ingevuld
• Voor het niveau 9 : de zones 1, 2 en 3 worden gezet op 9..9 gevolgd door het bloknummer.
De records moeten in stijgende volgorde staan volgens de 14 posities van het indicatieve deel.
000 001 002 100 101 102 103 200 201 202 203 204 205 209
900
Als niveau / blok Volgnummer 1 Volgnummer 2
000, 001, 002 000000 00000
100 + 1 00000
101, 102, 103 ongewijzigd 00000
200 ongewijzigd + 1
201, 202, 203, 204, 205, 209
ongewijzigd ongewijzigd
900 999999 99999
2.2.2. Gegevensgedeelte
Het gegevensgedeelte heeft een lengte van maximum 256 posities en bevat één of meerdere gegevens die een gegevensblok vormen (Zie gegevensschema hierna).
De gegevens worden achter mekaar gezet met het zonenummer in 2 posities gevolgd door het gegeven zelf. Het saldo van het record wordt opgevuld met een filler die blanco’s bevat in geval van een vaste recordstructuur. In het tegengestelde geval worden de gegevens beëindigd door een speciaal teken (carriage return/line feed - CR/LF) waarmee men kan aanduiden dat men op het einde gekomen is van de gegevens die betrekking hebben op dit blok.
Het gegevensgedeelte bevat alleen de zones van een blok die van betekenis zijn.
Daaruit volgt dat wanneer een zone niet noodzakelijk is en zij niet ingevuld moet worden in het kader van de betrokken aangifte, ofwel noch het zonenummer noch het gegeven aangeduid moet worden, ofwel het zonenummer aangeduid en gevolgd moet worden door koppeltekens over de lengte van de zone. De koppels “zonenummer - gegevens” mogen slechts één enkele keer voorkomen in een blok voor een aangifte.
3. Gegevensschema
3.1. Niveau 0 : Verzender
• 000 : Identificatie van de elektronische drager
• 00001 : Identificatienummer van de verzender
• 00003 : Benaming van de verzender
• 00004 : Creatiedatum van het bestand
• 00005 : Versienummer van het bestand
• 00011 : Aard van het bestand
• 00099 : Commentaar verzender
• 001 : Adres van de verzender
• 00101 : Adres van de verzender
• 00102 : Postcode van de verzender
• 00103 : Gemeente van de verzender
• 00104 : Landcode van de verzender
• 00105 : Nummer van het erkend sociaal secretariaat – hoofdzetel
• 00108 : GSM-nummer van de verzender
• 00109 : E-mail adres van de verzender
• 002 : Contact
• 00201 : Contactpersoon
• 00202 : Functie van de contactpersoon
• 00203 : Telefoonnummer van de contactpersoon
• 00204 : Telefaxnummer
3.2. Niveau 1 : Werkgever
• 100 : Identificatie van de werkgever
• 10001 : Inschrijvingsnummer
• 10002 : Taalregime van het te versturen document
• 10005 : Voorlopig inschrijvingsnummer
• 10006 : R.S.Z.-P.P.O.
• 10099 : Commentaar werkgever
• 101 : Identificatie van de natuurlijke persoon
• 10101 : Naam van de werkgever
• 10102 : Voornaam van de werkgever
• 10103 : INSZ van de werkgever
• 102 : Identificatie van de rechtspersoon
• 10201 : Maatschappelijk doel van de werkgever
• 10202 : Rechtsvorm van de werkgever
• 10203 : Ondernemingsnummer
• 103 : Adres van de werkgever
• 10301 : Straatnaam en huisnummer van de werkgever
• 10302 : Busnummer van de werkgever
• 10303 : Postcode van de werkgever
• 10304 : Gemeente van de werkgever
• 10305 : Landcode van de werkgever
3.3. Niveau 2 : Aangifte
• 200 : Identificatie van de aangifte
• 20001 : Aard van de DIMONA - aangifte
• 20002 : DIMONA - nummer
• 20003 : Leescode van de SIS - kaart
• 20004 : Serienummer van het microcircuit
• 20005 : Certificaat van de directory PBDF
• 20006 : Certificaat van de directory ISDF
• 20007 : Deelentiteit
• 20008 : Vestigingseenheidnummer
• 20099 : Commentaar contract
• 201 : Identificatie van de werknemer
• 20101 : Nummer van de sociale identiteitskaart
• 20102 : Identificatienummer van de sociale zekerheid (INSZ)
• 20103 : Naam van de werknemer
• 20104 : Voornaam van de werknemer
• 20105 : Initiaal voornaam van de werknemer
• 20106 : Geboortedatum van de werknemer
• 20107 : Geboorteplaats van de werknemer
• 20108 : Landcode van de geboorteplaats van de werknemer
• 20109 : Geslacht van de werknemer
• 202 : Adres van de werknemer
• 20201 : Straatnaam van de werknemer
• 20202 : Huisnummer van de werknemer
• 20203 : Busnummer van de werknemer
• 20204 : Postcode van de werknemer
• 20205 : Gemeente van de werknemer
• 20206 : Landcode van de werknemer
• 203 : Identificatie van het contract
• 20301 : Datum indiensttreding
• 20302 : Datum van uitdiensttreding
• 20303 : Nummer Paritair Comité
• 20304 : Werkgeverscategorie
• 20305 : Nummer van het erkend sociaal secretariaat - bijkantoor
• 20306 : Werkgeversnummer binnenin een ESS
• 20308 : Aard van de werknemer
• 20309 : Uur van indiensttreding
• 20310 : Uur van uitdiensttreding
• 20311 : Gewijzigd uur
• 204 : Identificatie van de gebruiker
• 20401 : Inschrijvingsnummer van de gebruiker van een uitzendkracht
• 20402 : Benaming van de gebruiker van een uitzendkracht
• 20403 : Straatnaam en huisnummer van de gebruiker van een uitzendkracht
• 20404 : Busnummer van de gebruiker van een uitzendkracht
• 20405 : Postcode van de gebruiker van een uitzendkracht
• 20406 : Gemeente van de gebruiker van een uitzendkracht
• 20407 : Landcode van de gebruiker van een uitzendkracht
• 20408 : Ondernemingsnummer gebruiker
• 205 : Gegevens voor de bouwsector
• 20501 : Nummer van de C3.2A van de maand van indiensttreding
• 20502 : Nummer van de C3.2A van de maand volgend op de maand van indiensttreding
• 209 : Gegevens voor de plaats van tewerkstelling van de student
• 20901 : Naam van het bedrijf/agentschap van de plaats van tewerkstelling voor een student
• 20902 : Straatnaam en huisnummer van de plaats van tewerkstelling voor een student
• 20903 : Busnummer van de plaats van tewerkstelling voor een student
• 20904 : Postcode van de plaats van tewerkstelling voor een student
• 20905 : Gemeente van de plaats van tewerkstelling voor een student
• 20906 : Landcode van de plaats van tewerkstelling voor een student
• 900 : Eindtotalen
• 90001 : Aantal DIMONA - aangiften in het bestand
• 90002 : Aantal records in het bestand
• 90003 : Aantal werkgevers in het bestand
4. Uitgevoerde controles
Wanneer de aangiften onder gestructureerde vorm aankomen, zoals hierboven vermeld, dan ondergaat de boodschap in een eerste fase een controle op de digitale handtekening. Als er een probleem is op het niveau van het bestand (leesprobleem, parameterprobleem of ander probleem), dan wordt er onmiddellijk een boodschap teruggestuurd. Wanneer het bestand correct is, dan gaat zij over naar de fase van de vormcontrole. Deze fase verifieert de integriteit en de volgorde van de gegevens in het bestand. Tijdens deze etappe kan men drie soorten anomalieën vinden :
• De blokkerende anomalieën : één dergelijke anomalie volstaat om het hele bestand te laten weigeren. Deze anomalieën worden aangeduid met de letter B in het deel
‘Foutcodes op ontvangstbewijs’.
• De niet-blokkerende anomalieën : deze anomalieën worden bijgehouden en mogen een bepaald vastgelegd percentage niet overschrijden. Wordt dit percentage overschreden, dan wordt het hele bestand geweigerd en worden alle anomalieën gemeld. (Men stopt de controle niet zodra het percentage overschreden is). Deze anomalieën worden aangeduid met de letter P in het deel ‘Foutcodes op ontvangstbewijs’.
• De niet-bijgehouden anomalieën : men houdt geen rekening met deze anomalieën voor een eventuele weigering van het bestand. Ze worden ter informatie gemeld wanneer het bestand geweigerd wordt.
Het antwoord zal binnen een beperkte tijd teruggestuurd worden, eveneens onder de vorm van een gestructureerde boodschap (zie glossarium voor het ontvangstbewijs).
In deze boodschap is het bestand ofwel verkeerd en worden alle anomalieën gemeld, ofwel wordt het bestand aanvaard en deelt men de DIMONA-codes mee in de boodschap voor elke aangifte van het bestand. De anomalieën worden dan ook niet meegedeeld omdat zij automatisch verbeterd kunnen worden op het niveau van de berichten.
De aangiften waarvoor er een DIMONA-nummer werd toegekend, zullen daarna inhoudelijk gecontroleerd worden. Er wordt dan binnen de 10 dagen na ontvangst een bericht verstuurd met de gecontroleerde en eventueel verbeterde gegevens (zie glossarium van het bericht).
Als het bericht verkeerd is, heeft u 5 dagen om te reageren op de vastgestelde anomalieën.
Een vormcontroleprogramma wordt ter beschikking gesteld (zie technische deel). Het is dus sterk aan te raden dit programma te integreren in uw informaticasysteem; het geeft de garantie dat uw aangiften zullen worden aanvaard.
Voor aangiften met tijdsregistratie is er ook een inhoudelijke controle die niet door het standalone vormcontroleprogramma kan worden gedetecteerd. Een gestructureerd bericht dat de stanalone vormcontrole gepasseerd is, kan nog verworpen worden om inhoudelijke redenen.
4.1. Wijzigingen
Alleen de datum van indiensttreding en van uitdiensttreding mogen worden gewijzigd.
Alle andere gegevens mogen ter indicatie gegeven worden, maar moeten gelijk zijn aan de originele aangifte. De codes C3.2A mogen nooit worden gegeven in een wijziging.
Het DIMONA-nummer dat vermeld moet worden in de wijziging is het ontvangstbewijs-nummer van de INDIENSTTREDING of de UITDIENSTTREDING (als de indiensttreding plaats vond voor 01/01/1999). Het is in geen geval mogelijk één enkele van de aangiften die deel uitmaken van het contract te wijzigen als er verschillende zijn (bijvoorbeeld, een andere wijziging, een annulatie).
Volgende gegevens moeten ingevuld zijn om het te wijzigen contract te identificeren : OF: inschrijvingsnummer werkgever (zone 10001) EN INSZ
werknemer (zone 20102) EN nummer paritair comité (zone 20303)
OF: inschrijvingsnummer werkgever (zone 10001) EN Dimona nummer (zone 20002)
Deze gegevens mogen gelijktijdig voorkomen, in dit geval wordt het Dimona nummer gebruikt om het te wijzigen contract te identificeren.
Indien andere gegevens dan datum indienst en datum uitdienst moeten worden gewijzigd, kan dit niet via de gestructureerde berichten. Er dient schriftelijk of telefonisch contact te worden opgenomen met de kontroledienst van de RSZ.
4.2. Schrapping
Een annulatie verwijdert alle gegevens die geregistreerd werden voor een contract.
Het DIMONA-nummer dat vermeld moet worden, is het ontvangstbewijsnummer van de INDIENSTTREDING of de UITDIENSTTREDING (als de indiensttreding plaats vond voor 01/01/1999.) Het is in geen geval mogelijk één enkele van de aangiften die deel uitmaken van het contract te annuleren als er verschillende zijn (bijvoorbeeld, een wijziging of een uitdiensttreding).
Als het contract foutief is (fout in de data van indiensttreding en/of uitdiensttreding), kan men ofwel een wijzigende aangifte invoeren en er de goede data op vermelden, ofwel het hele contract annuleren en een originele aangifte van indiensttreding of uitdiensttreding opnieuw invoeren.
Alle gegevens mogen ter indicatie gegeven worden, maar moeten gelijk zijn aan de originele aangifte. De codes C3.2A mogen nooit worden gegeven in een schrapping.
Volgende gegevens moeten ingevuld zijn om het te schrappen contract te identificeren:
OF: inschrijvingsnummer werkgever (zone 10001) EN INSZ werknemer (zone 20102) EN nummer paritair comité (zone 20303)
OF: inschrijvingsnummer werkgever (zone 10001) EN Dimona nummer (zone 20002)
Deze gegevens mogen gelijktijdig voorkomen, in dit geval wordt het Dimona nummer gebruikt om het te schrappen contract te identificeren.
4.3. Voorwaarden
4.3.1. Een datum “indienst” kan enkel gewijzigd worden indien de oorspronkelijk aangegeven datum met één of meerdere dagen dient te worden vervroegd (bv.
men heeft een werknemer aangegeven met datum “indienst” op 6 juli 1999 daar waar hij effectief begint te werken op 5 juli 1999). Opgelet : de wettelijke maatregelen voorzien dat de aangifte van tewerkstelling ten laatste op het ogenblik van de indiensttreding moet voltooid zijn. Bijgevolg dienen zulke wijzigingen als uitzonderlijk te worden bestempeld. In geval van misbruik ziet de RSZ zich genoodzaakt sancties te nemen.
4.3.2. Indien de datum ‘indienst” later valt dan de oorspronkelijk aangegeven datum (bv. men heeft een werknemer aangegeven met datum “indienst” op 5 juli 1999 en deze werknemer biedt zich pas aan op 6 juli 1999) volstaat het de originele aangifte te annuleren op de dag zelf (binnen de kortst mogelijke termijn) van de voorziene indiensttreding (in het voorbeeld dus op 5 juli), en een nieuwe aangifte “indienst” te doen ten laatste op het moment van de werkelijke indiensttreding van de werknemer.
4.3.3. De datum van “uitdiensttreding” kan gewijzigd worden indien de betrokken werknemer de werkzaamheden heeft beëindigd voor de datum “uitdienst”
vermeld op de originele aangifte van “indiensttreding” (dit betreft praktisch alleen maar de uitzendkrachten). Indien de datum “uitdienst” moet gewijzigd worden omdat de werknemer zijn werkzaamheden verder zet na de oorspronkelijk voorziene datum van “uitdiensttreding” dient een nieuwe aangifte van indiensttreding te worden aangemaakt.
