In dit artikel wordt uitgelegd waarom het kan lijken alsof een gebruiker dezelfde functie meer dan eens in eADM vermeld staat, en hoe u kunt nagaan of de oorzaak hiervan een toekomstige functiewijziging in Visma Enterprise HRM is, in plaats van dat het daadwerkelijk om twee verschillende functies gaat.
Oorzaak
Visma Enterprise HRM (VEP) is het bronsysteem voor deze kwestie. Wanneer in VEP een functiewijziging wordt geregistreerd met een ingangsdatum in de toekomst (een reorganisatie, een procentuele wijziging, een nieuwe leidinggevende, enzovoort), werkt VEP niet simpelweg het bestaande functierecord bij. In plaats daarvan verstuurt het twee afzonderlijke versies van dezelfde functie in de export:
-
Eén versie die geldig is vanaf de oorspronkelijke ingangsdatum van de functie.
-
Een tweede versie die van kracht wordt vanaf de toekomstige ingangsdatum van de aanstaande wijziging.
eADM importeert beide versies precies zoals ze worden aangeleverd. Omdat beide versies dezelfde PositionCodeId en de meeste attribuutwaarden worden in eADM weergegeven als dezelfde positie die twee keer voorkomt, en niet als twee verschillende posities.
Opmerking: Dit is het verwachte gedrag van Visma Enterprise en geen importfout. Het gaat hier niet om hetzelfde probleem als een dubbel gebruikersaccount in Active Directory; zie ‘Gerelateerde artikelen’ hieronder voor dat afzonderlijke scenario.
Hoe kun je dit in eADM herkennen?
Tabblad 'Functies'
Open het profiel van de gebruiker en ga naar Functies. In de tabbladkop staat een aantal van 2 (of meer), hoewel de gebruiker slechts één daadwerkelijke positie heeft. Als je elk item selecteert, worden vrijwel identieke positiegegevens weergegeven (dezelfde APositionCodeName, AUnitName, APositionManager), wat het zichtbare symptoom van dit probleem is.
Tabblad Brongegevens
Op het tabblad ‘Brongegevens’ worden de ruwe waarden weergegeven die eADM voor elk kenmerk heeft ontvangen. Wanneer een functie in twee versies is verzonden, wordt bij de meeste kenmerken dezelfde waarde tweemaal weergegeven in een door een verticaal streepje gescheiden paar, bijvoorbeeld:
AUnitId: 3200|3200|
Het kenmerk waarin de twee versies van elkaar verschillen, is AValidFromDate. Dit is het veld dat u moet controleren om de oorzaak vast te stellen:
AValidFromDate: 2026-08-03|2026-11-01|
Hier is de eerste waarde de huidige startdatum van de functie en de tweede waarde de toekomstige datum waarop de geplande wijziging van kracht wordt. Elk ander kenmerk dat twee anders waarden (geen twee identieke) geven aan wat er op die toekomstige datum zal veranderen — bijvoorbeeld een nieuwe AUnitId, APositionPercentageof APositionManager.
Houd er rekening mee dat de aanstaande wijziging mogelijk iets is dat niet in eADM wordt geïmporteerd, bijvoorbeeld een loonaanpassing.
Besluit
In de meeste gevallen hoeft u niets te doen. Het duplicaat is een weergavefout die ontstaat doordat VEP nog niet doorgevoerde wijzigingen weergeeft; dit verdwijnt vanzelf zodra de wijziging met een toekomstige datum van kracht wordt en VEP stopt met het verzenden van de verouderde versie. Het duidt niet op een defecte account, een synchronisatiefout of een dubbele identiteit.
Als een volgend proces afhankelijk is van het aantal posities, de primaire positievlag of een specifieke attribuutwaarde (bijvoorbeeld een berichtstroom die wordt geactiveerd door APositionStartDate), controleer dit aan de hand van de Brongegevens Controleer in welk tabblad staat welke versie momenteel bepalend is voor de uitvoer van eADM, in plaats van ervan uit te gaan dat het de eerste of de meest recent toegevoegde vermelding is.
Gerelateerde artikelen