Cet article explique pourquoi un utilisateur peut sembler occuper plusieurs fois le même poste dans eADM, et comment vérifier que cela est dû à un changement de poste daté d'une date future dans Visma Enterprise HRM, et non à l'existence de deux postes réellement distincts.
Cause
Visma Enterprise HRM (VEP) est le système source concerné par ce problème. Lorsqu’un changement de poste est enregistré dans VEP avec une date d’entrée en vigueur future (réorganisation, modification du pourcentage, nouveau responsable, etc.), VEP ne se contente pas de mettre à jour la fiche de poste existante. Il envoie plutôt deux versions distinctes du même poste dans le fichier d’exportation :
-
Une version valable à compter de la date de prise de fonction initiale du poste.
-
Une deuxième version qui entrera en vigueur à la date d'entrée en vigueur de la modification en cours.
eADM importe les deux versions telles qu'elles sont fournies. Étant donné que les deux versions partagent le même PositionCodeId et la plupart des valeurs d'attribut apparaissent dans eADM comme une même position répétée deux fois, et non comme deux positions distinctes.
Remarque : il s'agit d'un comportement normal de Visma Enterprise, et non d'une erreur d'importation. Ce problème est distinct de celui lié à la présence d'un compte utilisateur en double dans Active Directory ; pour ce cas de figure, consultez la section « Articles connexes » ci-dessous.
Comment identifier cela dans eADM ?
Onglet « Postes »
Ouvrez le profil de l'utilisateur et accédez à Postes. L'en-tête de l'onglet affiche un nombre de 2 (ou plus) alors que l'utilisateur n'a qu'une seule position réelle. La sélection de chaque entrée fait apparaître des données de position quasi identiques (mêmes APositionCodeName, AUnitName, APositionManager), qui est le symptôme visible de ce problème.
Onglet « Données source »
L'onglet « Données source » affiche les valeurs brutes reçues par eADM pour chaque attribut. Lorsqu'un poste a été envoyé en deux versions, la plupart des attributs affichent deux fois la même valeur sous la forme d'une paire séparée par une barre verticale, par exemple :
AUnitId: 3200|3200|
L'attribut qui diffère entre les deux versions est AValidFromDate. C'est le champ à cocher pour vérifier la cause :
AValidFromDate: 2026-08-03|2026-11-01|
Ici, la première valeur correspond à la date de début actuelle du poste et la seconde à la date future à laquelle la modification en attente prendra effet. Tout autre attribut comportant deux différent valeurs (qui ne sont pas identiques) indiquent ce qui changera à cette date future — par exemple, un nouveau AUnitId, APositionPercentage, ou APositionManager.
Veuillez noter que la modification à venir peut concerner un élément qui n'est pas importé dans eADM, par exemple un ajustement salarial.
Résolution
Dans la plupart des cas, aucune intervention n'est nécessaire. Ce doublon est un artefact d'affichage lié à la manière dont VEP transmet les modifications en attente ; il disparaît de lui-même dès que la modification datée d'une date future devient effective et que VEP cesse d'envoyer la version remplacée. Cela n'indique pas un compte défectueux, un échec de synchronisation ou une identité en double.
Si un processus en aval dépend du nombre de positions, de l'indicateur de position principal ou d'une valeur d'attribut spécifique (par exemple, un flux de messages déclenché par APositionStartDate), vérifier par rapport à la Données sources Vérifiez quelle version régit actuellement la sortie d'eADM, plutôt que de partir du principe qu'il s'agit de la première entrée ou de la plus récente.
Articles connexes