Cette page s'adresse à celles et ceux qui pratiquent déjà Employee Central : consultants, administrateurs SIRH, intégrateurs, équipes data. Son objectif est de rendre explicite la façon dont les entités s'articulent réellement, clés, cardinalités et navigation properties comprises, parce que c'est exactement là que se jouent les intégrations, les migrations et le reporting.
EC ne stocke rien « à plat ». Le modèle repose sur la séparation Person / Employment, sur l'historisation par tranches datées pilotée par les Event Reasons, et sur des référentiels partagés qui se répartissent aujourd'hui entre Foundation Objects legacy et objets MDF. L'API OData v2 expose l'ensemble, avec quelques subtilités héritées de cette histoire.
L'explorateur plus bas matérialise ces liens. Cliquez sur une table : vous verrez sa clé primaire, ses champs structurants et chacune de ses relations avec sa cardinalité et la navigation OData correspondante.
Tout le modèle EC découle de ces quatre idées structurantes.
PerPerson (person_id_external) porte l'individu, EmpEmployment (user_id) la relation de travail. Une personne, n emplois : concurrent employment, global assignment, rehire with new employment.
Clés composites (userId + startDate + seqNumber sur EmpJob). On insère des tranches, on n'écrase jamais. Lecture par asOfDate ou fromDate / toDate.
Trois familles à distinguer : FO legacy définis en XML, FO migrés vers le Metadata Framework, et objets MDF natifs comme Position.
Navigation properties et $expand pour parcourir les liens. Les entités FO* restent exposées même quand l'objet vit désormais dans le MDF.
À l'origine, tous les référentiels étaient des Foundation Objects définis en XML dans le Corporate Data Model. À partir des releases 2014 et 2015, SAP en a migré la majorité vers le Metadata Framework. Résultat : trois familles cohabitent, et elles ne se configurent pas au même endroit.
Définis en XML (déclinaisons pays dans le country-specific Corporate Data Model), administrés via Manage Organization, Pay and Job Structures.
Données gérées via Manage Data, extensibles par champs custom, associations et règles métier. Fonctionnellement, ils restent des foundation objects.
N'ont jamais été des FO : Position (hiérarchie de postes, synchronisation vers EmpJob pilotée par règles) et tous les objets custom cust_*, avec associations, workflows et sécurité RBP natifs.
FO* (FOCompany, FODepartment…) en plus de son entité MDF (LegalEntity, Department…). Les deux désignent la même donnée, mais les associations MDF y apparaissent sous des champs et des navigations différents. Vérifiez toujours quelle entité votre flux consomme avant de mapper.Tout parcours de données EC suit la même chaîne : la personne, la relation de travail, l'historique de poste, puis les référentiels pointés par clé étrangère.
En OData v2, cette chaîne se parcourt avec $expand sur les navigation properties. Exemple : reconstituer la situation complète d'un salarié à une date donnée, référentiels inclus, en un seul appel :
Trois réflexes d'expert : interrogez avec asOfDate (sans lui, l'API ne renvoie que la tranche effective du jour), pensez au seqNumber quand deux événements tombent le même jour, et rappelez-vous que EmpPayCompRecurring se lit via EmpCompensation/empPayCompRecurringNav, jamais directement depuis l'emploi.
Cliquez sur n'importe quelle table pour révéler ses liens, ses clés et ses champs. Touche Échap ou bouton « Réinitialiser » pour repartir de zéro.
clé : person_id_external
clé : user_id
clé : external_code (+ date d’effet)
Conseil, implémentation, support : notre équipe d'experts SIRH vous accompagne, avec une approche sur mesure et à taille humaine.
Contactez-nous pour en savoir plus