Correction rapide :ORA-20114 … FND_MODIFIEDlors d'une mise à jour en masse signifie que le job n'envoie pas le champOBJVERSION— le verrou optimiste d'IFS. Sans lui, IFS croit que l'enregistrement a été modifié entre-temps et refuse l'update. MappezOBJVERSIONdans le Source Mapping (avec une valeur fraîchement exportée) et relancez.
Vous lancez un job de migration pour changer en masse le statut d'enregistrements existants — par exemple passer des projets d'« Initialised » à « Released ». Et chaque ligne renvoie :
ORA-20114 : Project.FND_MODIFIED : The Project record has already been changed. Please refresh the record and reenter your changes.
Le plus déroutant : personne n'a touché à ces enregistrements. Aucun utilisateur connecté, aucun job concurrent. Alors qui les a « modifiés » ?
Le symptôme
L'erreur survient à l'exécution d'un job de mise à jour (changement de statut, modification en masse), sur des enregistrements que personne ne modifie réellement en parallèle. Le message cite l'entité (Project, CustomerOrder…) mais le motif est toujours FND_MODIFIED … has already been changed.
La cause
C'est le verrou optimiste d'IFS qui parle.
Chaque enregistrement IFS porte un champ technique OBJVERSION : un horodatage de version. À chaque update, IFS compare l'OBJVERSION que vous envoyez avec celui stocké en base. S'ils diffèrent — ou si vous n'en envoyez aucun — IFS conclut que quelqu'un a modifié l'enregistrement entre votre lecture et votre écriture, et bloque pour éviter d'écraser ses changements.
En migration, la cause n'est presque jamais une vraie modification concurrente : c'est le mapping qui n'inclut pas OBJVERSION. Le job envoie un update « sans version » → IFS le rejette systématiquement.
Cas réel validé (IFS Community, réponse d'un Hero IFS confirmée par l'auteur) : « based on the hardcopy you missed to map the OBJVERSION field » — l'ajout du mapping a immédiatement résolu l'erreur.
Comment corriger
- Ouvrez le job, onglet Source Mapping.
- Vérifiez que la colonne
OBJVERSIONest présente et mappée depuis votre source. - Assurez-vous que sa valeur est fraîche : exportez les données (avec
OBJVERSION) juste avant la mise à jour. Un export d'il y a deux semaines peut contenir des versions déjà obsolètes. - Relancez : IFS retrouve la version attendue et exécute l'update.
Si l'erreur persiste avec OBJVERSION mappé
Là, c'est une vraie collision de versions : quelque chose a modifié les enregistrements entre votre export et votre import — un autre job, un workflow, une intégration, ou… une étape précédente de votre propre job multi-méthodes (la méthode 10 modifie l'enregistrement, la méthode 20 arrive avec l'ancienne version). Dans ce cas : ré-exportez les OBJVERSION au plus près de l'exécution, ou enchaînez lecture+écriture dans le même job.
Comment l'éviter
- Toujours inclure
OBJVERSIONdans les exports destinés à être réimportés en update — réflexe à ancrer dans vos gabarits de jobs. - Minimiser le délai entre export et import sur les données vivantes.
- Geler les flux concurrents (workflows, intégrations) pendant les mises à jour en masse.
Erreurs de migration IFS liées
Le même type de blocage se joue sur d'autres codes — tous décortiqués dans notre guide pilier Migration de données IFS Cloud:
- ORA-20112 FND_RECORD_EXIST — le cousin : là c'est la clé qui n'identifie pas la ligne ; ici c'est la version qui ne correspond pas.
- ORA-20124 NULLVALUE — un champ obligatoire que le job croit vide.
- ORA-20111 / FND_RECORD_NOT_EXIST — un prérequis contextuel manquant.
- SE_UNAUTHORIZED — la projection du job non accordée à l'exécutant : un problème de permissions de migration .
Pour la gestion des imports/exports, voir aussi la page Import / Export Excel IFS page.
Mettre à jour en masse sans gérer les versions à la main
ORA-20114 révèle la mécanique cachée des updates IFS : pour modifier 500 projets, il faut transporter soi-même le verrou optimiste de chacun. ERP Control s'en charge : il lit l'enregistrement et applique la modification dans la même transaction (PATCH via l'API OData) — la version est toujours fraîche, jamais d'FND_MODIFIED. En no-code, sans Method List ni export intermédiaire, sur vos environnements CFG · UAT · TRN · PROD.
Découvrez comment ERP Control simplifie les migrations IFS Cloud — voir le module migrationFait partie de notre guide pilier :
Migration de données IFS Cloud — le guide complet 2026 Migration de données IFS Cloud — le guide complet 2026Fait partie de notre guide pilier :
FAQ
Personne ne modifie ces enregistrements, pourquoi IFS dit le contraire ?
Parce que votre job n'envoie pas d'OBJVERSION. Pour le verrou optimiste, « pas de version » = « version inconnue » = modification potentielle → refus. Mappez le champ.
Où trouver la valeur d'OBJVERSION ?
Elle est présente sur toutes les vues IFS. Incluez-la dans votre export source (Excel, vue SQL) : c'est cette valeur que le job renverra à l'update.
OBJVERSION est mappé et l'erreur persiste ?
Vos versions sont obsolètes : les enregistrements ont changé depuis l'export (autre flux, ou étape précédente de votre propre job). Ré-exportez au plus près de l'exécution.
Sources
Cas réel issu de la communauté IFS (solution validée sur le thread) :