Denne artikkelen forklarer hvorfor det kan se ut som om en bruker har samme stilling oppført flere ganger i eADM, og hvordan man kan bekrefte at årsaken er en stillingsendring med fremtidig dato i Visma Enterprise HRM, og ikke at det faktisk dreier seg om to forskjellige stillinger.
Årsak
Visma Enterprise HRM (VEP) er kildesystemet for dette tilfellet. Når en stillingsendring registreres i VEP med en ikrafttredelsesdato i fremtiden (en omorganisering, en prosentvis endring, en ny leder osv.), oppdaterer VEP ikke bare den eksisterende stillingsoppføringen. I stedet sender systemet to separate versjoner av den samme stillingen i eksporten:
-
Én versjon som gjelder fra stillingens opprinnelige startdato.
-
En ny versjon som gjelder fra den fremtidige ikrafttredelsesdatoen for den planlagte endringen.
eADM importerer begge versjonene slik de leveres. Siden begge versjonene har samme PositionCodeId og de fleste attributtverdiene vises i eADM som én og samme posisjon som forekommer to ganger, ikke som to forskjellige posisjoner.
Merk: Dette er forventet oppførsel fra Visma Enterprise, ikke en importfeil. Det er ikke det samme problemet som en duplisert brukerkonto i Active Directory; se «Relaterte artikler» nedenfor for det separate scenariet.
Hvordan identifisere dette i eADM
Fanen «Stillinger»
Åpne brukerens profil og gå til Stillinger. Fanetittelen viser tallet 2 (eller mer), selv om brukeren bare har én faktisk posisjon. Når man velger hver enkelt oppføring, vises nesten identiske posisjonsdata (samme APositionCodeName, AUnitName, APositionManager), som er det synlige symptomet på dette problemet.
Fanen «Kildedata»
Fanen «Kildedata» viser råverdiene som eADM har mottatt for hvert attributt. Når en posisjon er sendt i to versjoner, vises de fleste attributter to ganger med samme verdi i et par adskilt med vertikalt strek, for eksempel:
AUnitId: 3200|3200|
Det som skiller de to versjonene fra hverandre, er AValidFromDate. Dette er feltet du må sjekke for å finne årsaken:
AValidFromDate: 2026-08-03|2026-11-01|
Her er den første verdien stillingens gjeldende startdato, og den andre verdien er den fremtidige datoen da den planlagte endringen trer i kraft. Ethvert annet attributt som viser to annerledes verdiene (ikke to identiske) angir hva som vil endres på den fremtidige datoen — for eksempel en ny AUnitId, APositionPercentage, eller APositionManager.
Vær oppmerksom på at den forestående endringen kan være noe som ikke importeres til eADM, for eksempel en lønnsjustering.
Beslutning
I de fleste tilfeller er det ikke nødvendig å gjøre noe. Duplikatet er en visningsfeil som skyldes måten VEP leverer endringer som venter på å tre i kraft på, og det løser seg av seg selv når den fremtidige endringen trer i kraft og VEP slutter å sende den foreldede versjonen. Det tyder ikke på en feil i kontoen, en synkroniseringsfeil eller en duplisert identitet.
Hvis en etterfølgende prosess er avhengig av posisjonstallet, flagget for primærposisjon eller en bestemt attributtverdi (for eksempel en meldingsstrøm utløst av APositionStartDate), sjekk opp mot Kildedata Sjekk hvilken versjon som for øyeblikket styrer utdataene fra eADM, i stedet for å anta at det er den første eller den sist lagt til oppføringen.
Relaterte artikler