Skip to Content

ORA-20111: "does not exist" in IFS Cloud Data Migration — the Missing Prerequisite (NOTEXIST2, FND_RECORD_NOT_EXIST)

June 15, 2026 by
ORA-20111: "does not exist" in IFS Cloud Data Migration — the Missing Prerequisite (NOTEXIST2, FND_RECORD_NOT_EXIST)
Quick fix: ORA-20111 … does not exist means IFS can't find a record your row depends on: either a context field missing from the job (e.g. CONTRACT/COMPANY), or a parent object that was never created (e.g. the Part Catalog before the Engineering Part). Add the missing field via Method List → Method List Attribute, or migrate the parent first. The error goes away.

ORA-20111 does not exist in IFS Cloud migration: the missing prerequisite (context field or parent object) and the fix — ERP Control

Your IFS Cloud migration job runs, the data is clean… and every row hits a message like:

ORA-20111: Site.NOTEXIST2: The Site object does not exist.

The confusing part: the "missing" object does exist in IFS. The site is there. The part is there. So why does IFS claim otherwise?

The symptom

The error appears on Load or Execute of a migration job (FNDMIG, Excel Migration) or an API call, in several flavors — same pattern, different object:

  • ORA-20111: Site.NOTEXIST2: The Site object does not exist. (migrating pre-accounting on customer orders)
  • ORA-20111: EngPartMaster.FND_RECORD_NOT_EXIST: The Engineering Part Master does not exist. (creating parts via ENG_PART_REVISION)
  • ORA-20111: ExtLoadInfo.FND_RECORD_NOT_EXIST: The Ext Load Info does not exist. (inserting vouchers via the API)

The cause

ORA-20111 is not a data error: it's a missing prerequisite. IFS business logic needs a context record to validate your row, and can't find it. Two scenarios:

  • The context field isn't passed by the job. Typical example: PreAccounting requires CONTRACT (the site) and COMPANY — not as keys, but because the logic uses them to fetch a date and validate code part values. If your job doesn't send CONTRACT, IFS concludes "Site does not exist" — the site exists, the job just never sent it.
  • The parent object genuinely wasn't created. In the client, IFS creates some parents automatically (creating an Engineering Part creates the Part master). In a migration job, it doesn't: the job won't chain those implicit creations. Inserting into ENG_PART_REVISION without a Part master first → FND_RECORD_NOT_EXIST.
Confirmed by real IFS community cases: "the system automatically creates the Part master with Engineering Part creation, however, the system does not create the Part master automatically when creating an Engineering Part using a migration job unless the job is specifically designed to create a Part master first."

ORA-20111 diagram: the migrated row depends on a context record or a parent; if it's missing, IFS returns does not exist — the fix: pass the field or load the parent first

How to fix it

Case 1 — missing context field (e.g. CONTRACT on PreAccounting):

  • Open your migration job, Method List tab.
  • Right-click the method → Method List Attribute.
  • Add the missing field (e.g. CONTRACT) at the end of the list and save — it automatically shows up in the Source Mapping tab.
  • Map it to your source column and re-run. (Solution validated by the IFS community.)
  • If the error persists: also fill in the Attr Seq column (e.g. 20) on the added line — the extra step reported by users on recent versions.

Case 2 — parent never created (e.g. Engineering Part):

  • Identify the prerequisite: for an Engineering Part it's the Part Catalog / Part master; for lines, it's the header.
  • Create it first: manually, or with a separate migration job executed beforehand.
  • Re-run your original job: the parent exists, the row goes through.

Special case — accounting vouchers via API: there is no direct POST on the Voucher entity. Don't fight ExternalVoucheSet row by row: the robust approach validated by IFS consultants is the External Voucher file import (copy and adapt the STDVOU template, switch the delimiter to CSV). Tested up to ~100,000 lines, multi-company, and automatable as a scheduled batch process.

How to avoid it

  • Before any job, map the dependencies: which objects does your view reference (site, company, part, header)? Load parents before children.
  • Watch out for "invisible" fields: some are neither keys nor visible in the default mapping, yet the business logic requires them (to validate or fetch data). The reflex: compare the Method List with what the IFS screen asks for during manual entry.
  • Test with one row before going to volume: ORA-20111 takes 2 minutes to diagnose on 1 row, hours on 50,000.

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-20112 FND_RECORD_EXIST — the exact opposite: the job tries to INSERT a row that already exists (a key problem).
  • ORA-20122 "may not be modified" — a field that can't be updated through the standard API.
  • ORA-20110 — a violated business rule (out-of-range data, missing basic data setup).
  • SE_UNAUTHORIZED — the job's projection not granted to the executing user: a migration permissions problem.

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

Run migrations without fighting prerequisites

ORA-20111 exists because IFS migration jobs don't chain the implicit creations the client does for you — knowing the order and the context fields is on you. ERP Control fixes this at the root: it resolves dependencies between objects and loads data in the right order through the OData API, no-code, no Method List, no PL/SQL — consistently 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

ORA-20111 says an object doesn't exist, but I can see it in IFS. Why?

Because the job doesn't send it. The object exists in the database, but the field referencing it (e.g. CONTRACT) is missing from your Method List — so as far as the validation logic is concerned, it doesn't exist. Add the field via Method List Attribute.

What's the difference between NOTEXIST2 and FND_RECORD_NOT_EXIST?

Nothing fundamental: two labels for the same mechanism — IFS can't find a required record. NOTEXIST2 usually points at a context object (Site), FND_RECORD_NOT_EXIST at a parent record.

I'm migrating headers and lines: in what order?

Always parents first (headers, masters, catalogs), then children. If one file mixes both, add an Order By clause in the job to force processing order.

Sources

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

ORA-20110 in IFS Cloud Data Migration: the Violated Business Rule — How to Read the Code and Fix It (4 Real Cases)