ORA-20124: NULLVALUE "field is mandatory" in IFS Migration — When the Mandatory Field Isn't Even Empty

Quick fix: ORA-20124 … NULLVALUE: Field [X] is mandatory has two faces. If the field really is empty: map it or give it a default value. But if the field is populated in your source — the baffling case — then something else is wiping it: a parameter that changes the API's behavior (e.g. LineItemNo > 0), a key rebuilt on the IFS side, or a related row not yet migrated. The 3 validated cases below.

You're migrating data or calling the IFS API, and every row returns:

ORA-20124: Error.NULLVALUE: Field [PROBABILITY_TO_WIN] is mandatory for Order Quotation Line and requires a value.

You check your source: the field is populated. You check again. Still populated. And IFS keeps declaring it empty.

The symptom

The error appears in migration jobs (FNDMIG, Excel) or API calls (POST), with the pattern Error.NULLVALUE: Field [X] is mandatory for [Entity]. Two very different situations hide behind the same message:

• The field is genuinely missing from your mapping or source — the trivial case.
• The field is present and populated… and IFS still receives it as NULL — the vicious case.

The cause (3 validated mechanisms)

1. A parameter changes the API's behavior and overwrites your values

Real case (REST API, Sales Quotation, 23R1/23R2): ProbabilityToWin present in the payload, tested with every possible value — rejected every time. The cause, found by digging through the Order_Quotation_Line_API package: setting LineItemNo > 0 changes the API's internal logic, which then replaces some of the transmitted values — sometimes with NULL. Fix: don't send LineItemNo (let IFS handle it) → everything works. (Solved thread, fix confirmed by the author.)

2. The value is inherited from a record that hasn't been migrated yet

Real case (CUSTOMER_ORDER_LINE migration, 24R2): DEFAULT_ADDR_FLAG populated ('Y') and yet declared NULL. The cause: for package components (line_item_no > 0), IFS fetches this flag from the package header line (line_item_no = -1) — which hadn't been migrated yet. Fix: force the processing order with an Order By clause (order_no, line_no, rel_no, line_item_no) so headers load before components.

3. The key you populate is ignored and rebuilt on the IFS side

Real case (Basic Data translations, financial views): LU field populated, error anyway. On financial views, the validated route is the dedicated view COMPANY_KEY_LU_TRANSLATION (or, failing that, duplicating existing records with the target language code, then re-importing the labels). (Solved thread.) Same mechanism as PROGNOTEXIST (see our ORA-20110 article): some fields are rebuilt by the API — your value is ignored.

The diagnostic method

• Trivial case first: is the field mapped and populated? If not → map it or set a default (careful: a default writes as-is, sometimes bypassing an IFS auto-calculation).
• Field is populated? Look for what's wiping it: an optional parameter in your payload/mapping that switches the API's mode (remove non-essential fields one by one — LineItemNo is the classic suspect).
• Does the field depend on another row? (package components, related lines) → check the load order (Order By, parents first).
• Is the field a technical key? (LU, PATH…) → it may be rebuilt by the API: look for the dedicated migration view.

How to avoid it

• In API calls: send only the necessary fields — every extra optional field can change the package's behavior.
• In migration: on hierarchical structures (orders with packages, headers/lines), always an Order By.
• Test with one simple row, then one complex row (a package component, a linked line): that's where NULLVALUE hides.

Related IFS migration errors

The same kind of blocker shows up under other codes — all covered in our IFS Cloud data migration pillar guide:

• ORA-20110 — the violated business rule: same tag-based diagnostic logic.
• ORA-20114 FND_MODIFIED — the other forgotten technical field (OBJVERSION).
• ORA-20111 / FND_RECORD_NOT_EXIST — the missing prerequisite (close to mechanism #2).
• SE_UNAUTHORIZED — the job's projection not granted: a migration permissions problem.

For import/export management, see also the IFS Excel Import/Export page.

Migrate without guessing what the API expects

ORA-20124 on a populated field is the gap between what you send and what IFS's internal logic receives. ERP Control works with the grain of the OData API: minimal payloads built field by field, load order resolved automatically, and readable row-by-row errors before you commit the volume. No-code, across your CFG · UAT · TRN · PROD environments.

See how ERP Control simplifies IFS Cloud migrations — check the migration module.

Part of our pillar guide: IFS Cloud Data Migration — the Complete 2026 Guide.

FAQ

The field is populated in my source — why does IFS see NULL?

Because an intermediate mechanism wipes it before validation: a parameter that switches the API's mode (e.g. LineItemNo > 0), a value inherited from a not-yet-migrated row, or a key rebuilt on the IFS side. The field isn't empty at your end — it's empty on arrival.

Is setting a default value enough?

For the trivial case (unmapped field), yes — but beware: the default is written as-is, without triggering IFS's automatic calculations. Check the field wasn't supposed to be computed.

Why does the error hit only some rows?

Typical of the inheritance mechanism: simple lines pass, package components (or linked lines) fail because their parent isn't loaded yet. Add an Order By.

Sources

Real cases from the IFS community (solutions validated on the threads):

• IFS Community discussion — Sales Quotation API and the ProbabilityToWin field (2024)
• IFS Community discussion — Basic Data translations and the LU field (2024)
• IFS Community discussion — DEFAULT_ADDR_FLAG on customer order lines (2026)