Correction rapide :ORA-20124 … NULLVALUE : Field [X] is mandatorya deux visages. Si le champ est réellement vide : mappez-le ou donnez-lui une valeur par défaut. Mais si le champ est rempli dans votre source — le cas le plus déroutant — c'est qu'autre chose l'écrase : un paramètre qui change le comportement de l'API (ex.LineItemNo> 0), une clé reconstruite côté IFS, ou une ligne liée pas encore migrée. Les 3 cas validés ci-dessous.
Vous migrez des données ou appelez l'API IFS, et chaque ligne renvoie :
ORA-20124 : Error.NULLVALUE : Field [PROBABILITY_TO_WIN] is mandatory for Order Quotation Line and requires a value.
Vous vérifiez votre source : le champ est rempli. Vous le re-vérifiez. Toujours rempli. Et IFS continue de le déclarer vide.
Le symptôme
L'erreur survient en job de migration (FNDMIG, Excel) ou en appel API (POST), avec le motif Error.NULLVALUE: Field [X] is mandatory for [Entité]. Deux situations très différentes se cachent derrière le même message :
- Le champ est réellement absent de votre mapping ou de votre source — cas trivial.
- Le champ est présent et alimenté… et IFS le reçoit quand même à NULL — cas vicieux.
La cause (les 3 mécanismes validés)
1. Un paramètre change le comportement de l'API et écrase vos valeurs
Cas réel (REST API, Sales Quotation, 23R1/23R2) : ProbabilityToWin présent dans le payload, testé avec toutes les valeurs possibles — rejeté à chaque fois. La cause, trouvée en fouillant le package Order_Quotation_Line_API : renseigner LineItemNo > 0 change la logique interne de l'API, qui remplace alors certaines valeurs transmises — parfois par NULL. Correction : ne pas envoyer LineItemNo (laisser IFS le gérer) → tout fonctionne. (Thread résolu, solution confirmée par l'auteur.)
2. La valeur est héritée d'un enregistrement pas encore migré
Cas réel (migration CUSTOMER_ORDER_LINE, 24R2) : DEFAULT_ADDR_FLAG alimenté ('Y') et pourtant déclaré NULL. La cause : pour les composants de kit (line_item_no > 0), IFS récupère ce flag depuis la ligne d'en-tête du package (line_item_no = -1) — qui n'était pas encore migrée. Correction : forcer l'ordre de traitement avec une clause Order By (order_no, line_no, rel_no, line_item_no) pour que les en-têtes passent avant les composants.
3. La clé que vous remplissez est ignorée et reconstruite côté IFS
Cas réel (traductions Basic Data, vues finance) : champ LU rempli, erreur quand même. Sur les vues financières, la voie validée est de passer par la vue dédiée COMPANY_KEY_LU_TRANSLATION (ou, à défaut, dupliquer les enregistrements existants en changeant le code langue, puis réimporter les libellés). (Thread résolu.) Le mécanisme est le même que pour PROGNOTEXIST (voir notre article ORA-20110) : certains champs sont reconstruits par l'API, votre valeur est ignorée.
La méthode de diagnostic
- Cas trivial d'abord : le champ est-il mappé et alimenté ? Si non → mappez-le ou définissez une valeur par défaut (attention : une valeur par défaut court-circuite parfois un calcul automatique d'IFS).
- Le champ est rempli ? Cherchez ce qui l'écrase : un paramètre optionnel dans votre payload/mapping qui change le mode de l'API (retirez les champs non indispensables un à un —
LineItemNoest le suspect classique). - Le champ dépend-il d'une autre ligne ? (composants de kit, lignes liées) → vérifiez l'ordre de chargement (Order By, parents d'abord).
- Le champ est-il une clé technique ? (LU, PATH…) → il est peut-être reconstruit par l'API : cherchez la vue de migration dédiée.
Comment l'éviter
- En API : n'envoyez que les champs nécessaires — chaque champ optionnel en plus peut changer le comportement du package.
- En migration : sur les structures hiérarchiques (commandes avec kits, en-têtes/lignes), toujours un Order By.
- Testez sur une ligne simple puis une ligne complexe (un composant de kit, une ligne liée) : c'est là que NULLVALUE se cache.
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-20110 — la règle métier violée : même logique de diagnostic par l'étiquette.
- ORA-20114 FND_MODIFIED — l'autre champ technique oublié (OBJVERSION).
- ORA-20111 / FND_RECORD_NOT_EXIST — le prérequis manquant (proche du mécanisme n°2).
- SE_UNAUTHORIZED — la projection du job non accordée : un problème de permissions de migration .
Pour la gestion des imports/exports, voir aussi la page Import / Export Excel IFS page.
Migrer sans deviner ce que l'API attend
ORA-20124 sur un champ rempli, c'est l'écart entre ce que vous envoyez et ce que la logique interne d'IFS reçoit. ERP Control travaille dans le sens de l'API OData : payloads minimaux construits champ par champ, ordre de chargement résolu automatiquement, et erreurs ligne à ligne lisibles avant d'engager le volume. En no-code, 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
Le champ est rempli dans ma source, pourquoi IFS le voit NULL ?
Parce qu'un mécanisme intermédiaire l'écrase avant la validation : un paramètre qui change le mode de l'API (ex. LineItemNo > 0), une valeur héritée d'une ligne pas encore migrée, ou une clé reconstruite côté IFS. Le champ n'est pas vide chez vous — il l'est à l'arrivée.
Mettre une valeur par défaut suffit-il ?
Pour le cas trivial (champ non mappé), oui — mais attention : la valeur par défaut s'écrit telle quelle, sans déclencher les calculs automatiques d'IFS. Vérifiez que le champ ne devait pas être calculé.
Pourquoi l'erreur n'apparaît que sur certaines lignes ?
Typique du mécanisme d'héritage : les lignes simples passent, les composants de kit (ou lignes liées) échouent car leur parent n'est pas encore chargé. Ajoutez un Order By.
Sources
Cas réels issus de la communauté IFS (solutions validées sur les threads) :