Scenario Personal
Wat dit scenario doet
Synchroniseert de persoonlijke gegevens van de medewerker.
Dit is het scenario dat een nieuwe medewerker in Nmbrs aanmaakt wanneer iemand start in HiBob,
dus alle andere scenario's zijn hiervan afhankelijk.
Voordat je begint
- HiBob-autorisatie is ingesteld (zie de HiBob Authorization Guide).
- Nmbrs-autorisatie is ingesteld (zie de Nmbrs Authorization Guide).
- Debtor + Company zijn ingesteld op het tabblad Configuration van de interface.
Instellen
Een uitleg van de instelling door een BrynQ-engineer
Deze opname is een momentopname; de BrynQ-interface of de template kan sindsdien iets zijn veranderd.
Stap 1: Controleer de unieke sleutel
Kernbegrippen:
Samenvatting
De unieke sleutel bestaat uit velden waarmee elke medewerker wordt geïdentificeerd bij het vergelijken van HiBob en Nmbrs.
Aan de hand van de unieke sleutel bepaalt de interface of die medewerker in Nmbrs wordt aangemaakt of bijgewerkt.
Belangrijk:
Als beide systemen al medewerkergegevens bevatten, zorg er dan voor dat de waarden van de unieke sleutel exact overeenkomen voordat je de interface activeert. De interface behandelt een afwijkende sleutelwaarde als een volledig nieuwe medewerker, niet als een wijziging.
In BrynQ kun je de unieke sleutel controleren door te kijken naar de record waarbij de sleutel blauw is gemarkeerd.
De standaard (aanbevolen instelling)
Standaard is de unieke sleutel het HiBob-veld Employee ID, te vinden onder de sectie Work van het medewerkerprofiel.
In Hibob komt dit overeen met dit veld:
In Nmbrs komt dit overeen met dit veld:
Wat je moet doen:
Met deze configuratie hoef je niets te doen in BrynQ.
Controleer alleen bij systemen die al gevuld zijn of de HiBob Employee ID voor elke medewerker overeenkomt met het Nmbrs-personeelsnummer.
Tip: gebruik een gedeeld veld zoals het e-mailadres of BSN als referentie om medewerkers in beide systemen aan elkaar te koppelen. Dat is prima voor een eenmalige controle.
Aangepaste instelling: wanneer je afwijkt van de aanbevolen instelling
Het kan voorkomen dat het veld 'Employee ID' in Hibob niet geschikt is voor jouw omgeving en dat je in plaats daarvan een eigen (custom) veld in Hibob hebt ingericht om medewerkers uniek te identificeren.
Dat kan zijn omdat je omgeving meerdere entiteiten omvat en je één overkoepelende eigen identificatie nodig hebt.
Voer in dat geval de volgende stappen uit in BrynQ:
- Verwijder 'Work Employee ID' door op het kruisje te klikken.
- Wijzig het type bronveld naar custom.
- Selecteer het custom veld als primaire sleutel.
FAQ
1. Kunnen we andere standaardvelden, zoals het e-mailadres, als unieke sleutel gebruiken?
Nee, gebruik altijd een speciaal veld in Hibob dat overeenkomt met het veld "employee number" in Nmbrs.
2. Waarom kunnen we geen ander standaardveld in Hibob en een ander Nmbrs-veld gebruiken om medewerkers uniek te identificeren?
Andere velden zijn geen betrouwbare kenmerken van een medewerker. E-mailadressen zijn bijvoorbeeld niet betrouwbaar, omdat het domein kan veranderen.
Of een typfout of een verschil in opmaak van het BSN kan ertoe leiden dat er nieuwe medewerkers worden aangemaakt, wat niet de bedoeling is.
3. Wat moet ik doen als ik de standaardvelden gebruik en mijn gegevens voor de unieke sleutels overeenkomen?
Niets, je bent klaar.
Stap 2: Controleer de waardemappings (concept vanaf dit punt)
Waardemappings vertalen een HiBob-label naar de code die Nmbrs verwacht. Ze staan op de afzonderlijke records binnen dit scenario en zijn vooraf ingevuld door BrynQ.
Records met een waardemapping: Gender, Nationality.
Pas een waardemapping alleen aan als het runrapport een niet-gemapte waarde meldt. Dat is het enige signaal dat er voor jou een gat in de mapping zit.
Typische voorbeelden van waardemappings. Dit zijn fictieve invoer-uitvoerparen om de opbouw te laten zien; de mapping van jouw interface wordt tijdens de onboarding door BrynQ ingesteld en kan meer of minder regels bevatten.
personal_nationality in HiBob → nationality_code_iso in Nmbrs
American | → | US |
Australian | → | AU |
Basotho | → | LS |
Belarusian | → | BY |
Belgian | → | BE |
Bissau-Guinean | → | GW |
Brazilian | → | BR |
British | → | GB |
(meestal staan er meer invoer-uitvoerparen; open het tabblad Mapping van de interface voor de volledige lijst.)
home_legal_gender in HiBob → gender in Nmbrs
Female | → | female |
Male | → | male |
Non-binary | → | unspecified |
Other | → | unspecified |
(meestal staan er meer invoer-uitvoerparen; open het tabblad Mapping van de interface voor de volledige lijst.)
Wat er achter de schermen gebeurt
Dit zijn de dingen die het scenario tussen HiBob en Nmbrs doet, naast een rechtstreekse kopie. Je stelt ze niet zelf in (ze zitten ingebouwd in de template), maar als je ze kent, herken je beter wat je in het runrapport ziet.
Sommige rijen worden weggefilterd
- Het scenario negeert rijen die in Nmbrs geen zin hebben (bijvoorbeeld medewerkers die niet op de loonlijst staan, of contracten die zijn geannuleerd voordat ze ingingen).
Medewerkers blijven synchroniseren, ook als er een waarde ontbreekt
- Het scenario schrijft de record toch weg, ook als de bronwaarde leeg is of niet wordt herkend. De ontbrekende waarde wordt gemeld, maar de rest van de medewerker wordt gewoon verwerkt.
De waarde wordt ingevuld als HiBob deze leeg laat
- Als HiBob geen waarde aanlevert, schrijft het scenario een logische standaardwaarde weg, zodat Nmbrs de record toch accepteert.
De waarde wordt opgesplitst voordat deze wordt verstuurd
- Het scenario splitst één HiBob-tekst op in de afzonderlijke delen die Nmbrs opslaat (bijvoorbeeld de adresregel in straat, huisnummer en toevoeging).
Waarden die dit scenario altijd wegschrijft, ongeacht wat er in HiBob staat
Sommige doelvelden in Nmbrs liggen vast in de template. Deze stel je niet zelf in: ze geven weer hoe BrynQ Nmbrs inricht voor een interface die vanuit HiBob wordt aangestuurd.
| Employee Type | = | payroll |
| Ascription Code | = | 1 |
Wanneer je een mapping aanpast
Mappingwijzigingen worden over het algemeen afgeraden: de template is al ingericht zoals BrynQ aanbeveelt voor HiBob en Nmbrs. Er zijn vier situaties waarin een wijziging echt gerechtvaardigd is:
- Het standaard HiBob-veld dat de record leest, past niet bij jouw inrichting. Koppel de record aan een ander standaardveld via de bronkiezer van de record.
- Geen van de standaardvelden van HiBob past en je hebt een custom veld nodig. Voeg eerst het custom veld toe in HiBob en wijzig daarna de bron op de record.
- Nmbrs heeft dat veld niet nodig voor jouw bedrijf. Als het doelveld optioneel is in Nmbrs, verwijder dan de record. Zie About Records voor hoe je een record netjes verwijdert.
- Er ontbreekt een veld dat Nmbrs wel nodig heeft. Voeg een nieuwe record toe. In About Records lees je hoe dat werkt.
De volledige klikpaden voor het toevoegen, bewerken en verwijderen van records vind je in About Records - How to map fields inside a scenario.
Het wijzigen van een unieke sleutel zorgt ervoor dat bij de volgende run elke bestaande record opnieuw wordt gematcht; doe dit nooit op productiegegevens.
Testen en valideren
Zo ziet 'klaar' eruit
- Nieuwe HiBob-medewerkers verschijnen na de run als nieuwe medewerkers in Nmbrs.
- Het BSN-veld op de medewerkerkaart in Nmbrs komt overeen met de waarde in HiBob.
- Het vergelijkingsrapport toont geen onverwachte 'edited'-rijen voor stabiele gegevens.
Test nooit tegen een productiebedrijf in Nmbrs; gebruik een Demobedrijf totdat de vergelijking klopt.
Waarom mislukt een BSN-upload terwijl de waarde geldig lijkt?
De reden staat altijd in de runlog voor die specifieke record. Nmbrs past een eigen validatie toe (lengte, controlegetal, toegestane patronen) en weigert elk BSN dat daar niet aan voldoet. Kijk naar de exacte foutmelding voor de mislukte record in plaats van uit te gaan van een mappingprobleem; mappingproblemen komen eerder aan het licht en geven andere fouten.
Waarom geeft Nmbrs soms de fout 'employee number already exists'?
Nmbrs bewaart inactieve medewerkers en hun personeelsnummers blijven gereserveerd. Als de interface er een (opnieuw) probeert aan te maken, geeft Nmbrs 'already exists' terug. De interface slaat die record over met een duidelijke melding in plaats van het opnieuw te proberen. Jij beslist of je de Nmbrs-record opnieuw activeert of een nieuw nummer toekent.
Hoe wordt het BSN opgeschoond voordat het naar Nmbrs wordt geüpload?
BSN's uit HiBob worden automatisch opgemaakt voordat ze naar Nmbrs worden gestuurd: voorloopnullen worden toegevoegd als de waarde korter is dan negen cijfers, en koppeltekens worden verwijderd. Een BSN dat is opgeslagen als '12-345-678' wordt bijvoorbeeld '123456780'.
Wat omvat het onderwerp Personal?
Personal synchroniseert identiteitsvelden (naam, geslacht, BSN, nationaliteit, geboortedatum, datum in dienst) van HiBob naar Nmbrs. Het draait als eerste, omdat latere onderwerpen ervan uitgaan dat de medewerker al in Nmbrs bestaat. Onderweg worden BSN's opgeschoond, worden tussenvoegsel en achternaam gesplitst, wordt de nationaliteit vertaald met de waardemapping en worden de voorletters afgeleid van de voornaam.
Gerelateerde artikelen
- FAQ
- Set Up Scenarios in a Template Interface
- About Scenarios - Organizing your interface into topics
- Set Up Scenarios in a Template Interface
- About Records - How to map fields inside a scenario
Bronnen