Correction rapide :ORA-20111 … does not existsignifie qu'IFS ne trouve pas un enregistrement dont votre ligne dépend : soit un champ de contexte absent du job (ex.CONTRACT/COMPANY), soit un objet parent jamais créé (ex. le Part Catalog avant l'Engineering Part). Ajoutez le champ manquant via Method List → Method List Attribute, ou migrez le parent d'abord. L'erreur disparaît.
Votre job de migration IFS Cloud tourne, les données sont propres… et chaque ligne se heurte à un message du type :
ORA-20111 : Site.NOTEXIST2 : The Site object does not exist.
Le plus déroutant : l'objet « manquant » existe bel et bien dans IFS. Le site est là, l'article est là. Alors pourquoi IFS prétend-il le contraire ?
Le symptôme
L'erreur survient au chargement ou à l'exécution d'un job de migration (FNDMIG, Excel Migration) ou d'un appel API, sous plusieurs formes — le motif est le même, seul l'objet change :
ORA-20111: Site.NOTEXIST2: The Site object does not exist.(migration de pré-imputations sur commandes client)ORA-20111: EngPartMaster.FND_RECORD_NOT_EXIST: The Engineering Part Master does not exist.(création d'articles viaENG_PART_REVISION)ORA-20111: ExtLoadInfo.FND_RECORD_NOT_EXIST: The Ext Load Info does not exist.(insertion de vouchers via l'API)
La cause
ORA-20111 n'est pas une erreur de données : c'est un prérequis manquant. La logique métier d'IFS a besoin d'un enregistrement de contexte pour valider votre ligne, et ne le trouve pas. Deux scénarios :
- Le champ de contexte n'est pas transmis par le job. Exemple typique : la pré-imputation (PreAccounting) exige
CONTRACT(le site) etCOMPANY— non pas comme clés, mais parce que la logique s'en sert pour récupérer une date et valider les code parts. Si votre job ne passe pasCONTRACT, IFS conclut « Site does not exist », alors que le site existe : il ne l'a juste jamais reçu. - L'objet parent n'a réellement pas été créé. En écran, IFS crée certains parents automatiquement (créer un Engineering Part crée le Part master). En migration, non : le job n'enchaîne pas ces créations implicites. Insérer dans
ENG_PART_REVISIONsans Part master préalable →FND_RECORD_NOT_EXIST.
Confirmé par les cas réels de la communauté IFS : « le système crée automatiquement le Part master à la création d'un Engineering Part — mais PAS via un job de migration, sauf si le job est explicitement conçu pour créer le Part master d'abord. »
Comment corriger
Cas 1 — champ de contexte manquant (ex. CONTRACT sur PreAccounting) :
- Ouvrez votre job de migration, onglet Method List.
- Clic droit sur la méthode concernée → Method List Attribute.
- Ajoutez le champ manquant (ex.
CONTRACT) en fin de liste et sauvegardez — il apparaît automatiquement dans l'onglet Source Mapping. - Mappez-le à votre colonne source et relancez. (Solution validée par la communauté IFS.)
- Si l'erreur persiste : renseignez aussi la colonne Attr Seq (ex.
20) sur la ligne ajoutée — c'est le complément remonté par les utilisateurs sur les versions récentes.
Cas 2 — parent jamais créé (ex. Engineering Part) :
- Identifiez le prérequis : pour un Engineering Part, c'est le Part Catalog / Part master ; pour des lignes, c'est l'en-tête.
- Créez-le d'abord : manuellement, ou via un job de migration séparé exécuté en amont.
- Relancez ensuite votre job initial : l'objet parent existe, la ligne passe.
Cas particulier — vouchers comptables via API : il n'existe pas de POST direct sur l'entité Voucher. Inutile d'insister sur ExternalVoucheSet ligne par ligne : la voie robuste validée par les consultants IFS est l'import de fichiers External Voucher (gabarit STDVOU copié et adapté, délimiteur CSV). Testé jusqu'à ~100 000 lignes, multi-sociétés, et automatisable en mode batch planifié.
Comment l'éviter
- Avant tout job, cartographiez les dépendances : quels objets votre vue référence-t-elle (site, société, article, en-tête) ? Chargez les parents avant les enfants.
- Méfiez-vous des champs « invisibles » : certains ne sont ni clés ni visibles dans le mapping par défaut, mais la logique métier les exige (ils servent à valider ou à récupérer une donnée). Le réflexe : comparer la Method List avec ce que l'écran IFS demande à la saisie manuelle.
- Testez sur une ligne avant le volume :
ORA-20111se diagnostique en 2 minutes sur 1 ligne, en heures sur 50 000.
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 — l'inverse exact : le job tente d'INSÉRER une ligne qui existe déjà (problème de clé).
- ORA-20122 « may not be modified » — un champ non modifiable via l'API standard.
- ORA-20110 — une règle métier violée (donnée hors plage, 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.
Faire ses migrations sans se battre avec les prérequis
ORA-20111 vient du fait que les jobs de migration IFS n'enchaînent pas les créations implicites que l'écran fait pour vous — c'est à vous de connaître l'ordre et les champs de contexte. ERP Control prend ce problème à la racine : il résout les dépendances entre objets et charge les données dans le bon ordre via l'API OData, en no-code, sans Method List ni PL/SQL — 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-20111 dit qu'un objet n'existe pas, mais je le vois dans IFS. Pourquoi ?
Parce que le job ne le transmet pas. L'objet existe en base, mais le champ qui le référence (ex. CONTRACT) est absent de votre Method List : pour la logique de validation, il n'existe donc pas. Ajoutez le champ via Method List Attribute.
Quelle différence entre NOTEXIST2 et FND_RECORD_NOT_EXIST ?
Aucune sur le fond : ce sont deux étiquettes du même mécanisme — IFS ne trouve pas un enregistrement requis. NOTEXIST2 vise souvent un objet de contexte (Site), FND_RECORD_NOT_EXIST un enregistrement parent.
Je migre des en-têtes et des lignes : dans quel ordre ?
Toujours parents d'abord (en-têtes, masters, catalogues), enfants ensuite. Si un même fichier mélange les deux, ajoutez une clause Order By dans le job pour forcer l'ordre de traitement.
Sources
Cas réels issus de la communauté IFS (solutions validées sur les threads) :