ORA-20112 : FND_RECORD_EXIST en migration IFS Cloud — « l'enregistrement existe déjà » et comment corriger

Correction rapide : ORA-20112 … FND_RECORD_EXIST signifie que le job de migration n'a pas réussi à identifier la ligne existante, donc il a tenté de l'INSÉRER à nouveau. Passez le job en INSERT_OR_UPDATE, puis corrigez la clé dans Method List → Method List Attribute : retirez le flag K (mettez -) sur la colonne clé que vous n'alimentez pas. Puis relancez.

Vous lancez un job de migration de données dans IFS Cloud pour mettre à jour des enregistrements existants. Au lieu de ça, chaque ligne se heurte à :

ORA-20112 : NomEntité.FND_RECORD_EXIST : The … already exists.

Le plus déroutant : vous avez bien activé l'option Modify, et pourtant le job refuse de mettre à jour. Voici ce qui se passe réellement, et comment le régler.

Le symptôme

L'erreur apparaît au chargement, à la validation ou à l'exécution d'un job de migration, dès que vous visez des lignes déjà présentes dans la base. Elle prend la forme (le nom d'entité change, le motif non) :

• ORA-20112: CustomerInfoAddressType.FND_RECORD_EXIST: The Customer Info Address Type already exists.
• ORA-20112: ProdStructureHead.FND_RECORD_EXIST: The Prod Structure Head already exists.
• ORA-20112: WarehouseBayBin.FND_RECORD_EXIST: The Warehouse Bay Bin already exists.

La cause

C'est un malentendu sur la clé, pas un vrai doublon.

Quand le job de migration n'arrive pas à identifier de façon unique la ligne existante, il en conclut qu'elle n'existe pas… et tente alors de l'INSÉRER. L'insertion entre en collision avec la ligne réellement présente → FND_RECORD_EXIST.

Pourquoi le job n'identifie‑t‑il pas la ligne ? Presque toujours parce que la composition de la clé dans le mapping est incomplète :

• vous ne renseignez que la valeur _DB (base) d'une colonne clé, sans la valeur client (ou l'inverse) ;
• ou une colonne reste marquée comme clé (flag K) alors qu'elle n'est pas alimentée.

Confirmé par plusieurs cas réels de la communauté IFS : « la cause la plus probable est que le job de migration ne peut pas identifier l'enregistrement de manière unique et tente donc d'en créer un nouveau. Il faut revoir la composition de la clé (flags P et K). »

Comment corriger

Deux réglages, dans cet ordre.

1. Passez le job en INSERT_OR_UPDATE — pour qu'il mette à jour la ligne si elle existe, au lieu de toujours insérer. Vérifiez d'abord que l'objet supporte réellement le modify : certains objets ne l'acceptent pas, et l'option seule ne suffit jamais si la clé est mauvaise.

2. Corrigez la clé pour que le job retrouve la ligne. Ça se passe dans la liste de méthodes, pas dans les données :

• Ouvrez Method List → Method List Attribute sur la vue concernée par le job (ex. CUSTOMER_INFO_ADDRESS, PROD_STRUCTURE_HEAD).
• Repérez la colonne clé qui n'est pas alimentée par votre source (typiquement le doublon client/_DB d'un même champ, ex. BOM_TYPE vs BOM_TYPE_DB, ou ADDRESS_TYPE_CODE vs ADDRESS_TYPE_CODE_DB).
• Retirez le flag K de cette colonne : remplacez K par - (ou x).
• Assurez‑vous que la colonne clé réellement utilisée est, elle, correctement mappée (valeur client et _DB selon le cas — l'API convertit automatiquement la valeur client à partir de la valeur _DB).
• Relancez le chargement / la validation : le job identifie désormais la ligne et la met à jour au lieu de tenter une insertion.

Cas particulier : une colonne alimentée par une séquence Oracle

Si l'erreur vient d'une colonne de type séquence (ex. LOCATION_SEQUENCE sur WarehouseBayBin), le réflexe est différent :

• laissez la colonne vide dans le mapping (pas de valeur, pas de valeur par défaut) → IFS récupère automatiquement la séquence ;
• ou passez par un job en 2 étapes : charger d'abord les données dans la table temporaire, puis migrer via MIGRATE_SOURCE_DATA (la séquence est alors prise en compte automatiquement).

Exemple détaillé : ProdStructureHead

Vous migrez des en-têtes de structure produit (type Manufacturing). La clé de l'objet combine CONTRACT ; PART_NO ; ENG_CHG_LEVEL ; BOM_TYPE. Problème : votre source n'alimente que BOM_TYPE_DB (valeur base), pas la valeur client BOM_TYPE — du coup le job ne retrouve pas l'en-tête existant et tente un INSERT.

• Ouvrez Method List Attribute sur PROD_STRUCTURE_HEAD.
• Repérez le couple BOM_TYPE (client) / BOM_TYPE_DB (base).
• Sur la colonne que vous n'alimentez pas, remplacez le flag K par -.
• Vérifiez que la procédure du job est bien INSERT_OR_UPDATE.
• Relancez : le job identifie désormais l'en-tête et le met à jour. (Solution confirmée par la communauté IFS.)

Trois cas réels (communauté IFS)

Le motif est toujours le même, seule l'entité change :

• ProdStructureHead (structures de produit, type Manufacturing) — sur les structures déjà existantes, ORA-20112: ProdStructureHead.FND_RECORD_EXIST. La cause : le job ne peut pas identifier la ligne car la clé est ambiguë. Dans le mapping, soit BOM_TYPE, soit BOM_TYPE_DB est alimenté ; il faut retirer le flag K de celui qui ne l'est pas. Solution validée par la communauté.
• CustomerInfoAddressType (adresses client, champ DEF_ADDRESS) — ORA-20112: CustomerInfoAddressType.FND_RECORD_EXIST. Ici, seule la valeur _DB d'ADDRESS_TYPE_CODE était passée ; il faut alimenter aussi la valeur client ADDRESS_TYPE_CODE (l'API la convertit) pour que le job retrouve la ligne et la mette à jour.
• WarehouseBayBin (emplacements de stock) — la première ligne s'insère, mais dès la deuxième : ORA-20112: WarehouseBayBin.FND_RECORD_EXIST. En cause, la colonne de séquence LOCATION_SEQUENCE qui réutilise la même valeur. On la laisse vide dans le mapping (IFS la génère), ou on migre en deux étapes via MIGRATE_SOURCE_DATA.

Comment l'éviter

• Avant de lancer un job de mise à jour, vérifiez la composition de la clé (flags P et K) dans Method List Attribute : une seule combinaison de clé doit identifier la ligne.
• Ne laissez jamais en flag K une colonne que votre source n'alimente pas.
• Gardez en tête la règle : FND_RECORD_EXIST = le job a voulu INSÉRER au lieu d'UPDATER → c'est un problème d'identification, pas de donnée en double.

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-20122 « may not be modified » — un champ non modifiable via l'API standard (ex. CATALOG_TYPE sur SALES_PART).
• ORA-20111 / Site.NOTEXIST2 — un prérequis contextuel manquant (charger les en-têtes avant les lignes).
• ORA-20110 — une règle métier violée (donnée hors plage, ou paramétrage 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.

Le Kit ORA-20112 (gratuit)

Pour garder la parade sous la main pendant votre reprise : une fiche d'une page — la cause en clair, la correction (INSERT_OR_UPDATE + clé), les trois cas réels (ProdStructureHead, CustomerInfoAddressType, Warehouse Bay Bin) et la check‑list d'évitement.

Téléchargez le Kit ORA-20112 (PDF) — gratuit, contre email

Un piège à ne pas confondre

Le code ORA-20112 apparaît aussi dans un contexte totalement différent : l'uplift EBR lors d'une montée de version (ex. 25R2), avec des messages comme « Prepare_Table_For_EBR error: Table X_TAB cannot be renamed to X_RTB as that table already exists ». Ce n'est pas le même problème : il concerne le renommage de tables custom pendant un upgrade, pas la migration de données. Si vous tombez dessus dans ce cadre, la piste est côté scripts CDB/EBR, et non Method List.

Faire ses migrations sans se battre avec les clés

ORA-20112 / FND_RECORD_EXIST vient de la gestion fine des clés des jobs de migration IFS — même avec l'option « Modify ». ERP Control évite le problème à la racine : il identifie la ligne existante et exécute un vrai update (PATCH via l'API OData) au lieu d'un INSERT à l'aveugle — donc plus de FND_RECORD_EXIST. Le tout en no‑code, sans toucher aux Method List ni écrire de PL/SQL, et de façon cohérente 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

ORA-20112 FND_RECORD_EXIST veut dire que j'ai un doublon ?

Non. Ça veut dire que le job n'a pas pu identifier la ligne existante et a tenté de l'insérer. C'est un problème de clé/mapping, pas de doublon réel.

J'ai activé « Modify » et ça ne met toujours pas à jour, pourquoi ?

Parce que l'option Modify ne sert à rien si la clé ne permet pas de retrouver la ligne. Corrigez la composition de la clé (flags P/K) dans Method List Attribute.

Ça marche pour une ligne mais échoue dès la deuxième ?

Souvent un souci de séquence (la même valeur est réutilisée). Laissez la colonne séquence vide dans le mapping, ou migrez en 2 étapes via MIGRATE_SOURCE_DATA.

Sources

Cas réels issus de la communauté IFS (solutions validées sur les threads) :

• Discussion IFS Community — migration de Prod Structure Head (2025)
• Discussion IFS Community — modifier DEF_ADDRESS par migration (2025)
• Discussion IFS Community — job de migration Warehouse Bay Bin (2023)
• Discussion IFS Community — uplift de personnalisations 25R2, le faux jumeau EBR (2025)