Tässä artikkelissa selitetään, miksi käyttäjän sama tehtäväpaikka saattaa näkyä eADM-järjestelmässä useammin kuin kerran, ja miten voidaan varmistaa, että syynä on Visma Enterprise HRM -järjestelmässä tulevaisuuteen ajoitettu tehtäväpaikan muutos eikä kyseessä ole todellisuudessa kaksi erillistä tehtäväpaikkaa.
Syy
Visma Enterprise HRM (VEP) on tämän asian lähdejärjestelmä. Kun VEP:ssä rekisteröidään tehtävänmuutos, jonka voimaantulopäivä on tulevaisuudessa (uudelleenorganisointi, prosentuaalinen muutos, uusi esimies jne.), VEP ei pelkästään päivitä olemassa olevaa tehtävätietuetta. Sen sijaan se lähettää viennissä kaksi erillistä versiota samasta tehtävästä:
-
Yksi versio, joka on voimassa kyseisen tehtävän alkuperäisestä alkamispäivästä lähtien.
-
Toinen versio, joka tulee voimaan tulevan muutoksen voimaantulopäivästä lähtien.
eADM tuo molemmat versiot sellaisina kuin ne toimitetaan. Koska molemmilla versioilla on sama PositionCodeId ja useimpien attribuuttien arvojen kohdalla ne näkyvät eADM:ssä samana sijaintina, joka esiintyy kahdesti, eivätkä kahdeksi eri sijainniksi.
Huomautus: Tämä on Visma Enterprise -ohjelmiston odotettua toimintaa, ei tuontivirhe. Kyseessä ei ole sama ongelma kuin Active Directory -palvelussa esiintyvä päällekkäinen käyttäjätili; katso alla oleva kohta ”Aiheeseen liittyvät artikkelit”, jossa käsitellään tätä erillistä tilannetta.
Miten tämä tunnistetaan eADM-järjestelmässä
Välilehti ”Tehtävät”
Avaa käyttäjän profiili ja siirry kohtaan Toiminnot. Välilehden otsikossa näkyy luku 2 (tai enemmän), vaikka käyttäjällä on vain yksi todellinen sijoitus. Kunkin merkinnän valitseminen tuo esiin lähes identtiset sijoitustiedot (samat APositionCodeName, AUnitName, APositionManager), joka on tämän ongelman näkyvä oire.
Lähdetiedot-välilehti
”Lähdetiedot”-välilehdessä näkyvät eADM:n kunkin attribuutin osalta vastaanottamat raaka-arvot. Kun sijainti on lähetetty kahdessa versiossa, useimpien attribuuttien kohdalla sama arvo näkyy kahdesti putkilla erotettuna parina, esimerkiksi:
AUnitId: 3200|3200|
Ominaisuus, joka eroaa näiden kahden version välillä, on AValidFromDate. Tämä on kenttä, josta voit tarkistaa syyn:
AValidFromDate: 2026-08-03|2026-11-01|
Tässä ensimmäinen arvo on tehtävän nykyinen alkamispäivä ja toinen arvo on tulevaisuudessa oleva päivämäärä, jolloin odottava muutos astuu voimaan. Mikä tahansa muu attribuutti, jossa näkyy kaksi erilainen arvot (ei kahta samanlaista) osoittavat, mikä muuttuu kyseisenä tulevana päivänä — esimerkiksi uusi AUnitId, APositionPercentage, tai APositionManager.
Huomaa, että kyseessä voi olla muutos, jota ei tuoda eADM-järjestelmään, kuten esimerkiksi palkkatarkistus.
Päätöslauselma
Useimmissa tapauksissa mitään toimenpiteitä ei tarvita. Päällekkäisyys johtuu VEP:n tavasta toimittaa tulevia muutoksia, ja se korjaantuu itsestään, kun tulevaisuuteen ajoitettu muutos tulee voimaan ja VEP lopettaa vanhentuneen version lähettämisen. Se ei tarkoita, että tili olisi vioittunut, synkronointi olisi epäonnistunut tai tunnistetiedot olisivat päällekkäisiä.
Jos myöhempi prosessi riippuu sijaintiluvusta, ensisijaisen sijainnin lipusta tai tietystä attribuuttiarvosta (esimerkiksi viestivirta, jonka laukaisee APositionStartDate), tarkista suhteessa Lähdetiedot varmista, mikä versio ohjaa tällä hetkellä eADM:n tulostusta, sen sijaan että olettaisit, että kyseessä on ensimmäinen tai viimeksi lisätty merkintä.
Aiheeseen liittyvät artikkelit