Flexfield View Generation Failure during Oracle EBS Upgradation

In Oracle E-Business Suite, the view MTL_SYSTEM_ITEMS_B_KFV is normally a Key Flexfield View generated automatically by the Application Object Library (FND).

When Oracle cannot generate the actual KFV view successfully, it creates this dummy view instead. This indicates:

• Key Flexfield compilation failed.
• One or more dependent objects are invalid.
• Flexfield definition is corrupted or incomplete.
• APPS schema compilation encountered errors.

Common causes in Oracle EBS

For MTL_SYSTEM_ITEMS_B_KFV, the object is the Inventory Item Key Flexfield (System Items KFF). The upgrade worker or post-upgrade compilation typically fails because of one of the following:

• Invalid Item Flexfield definition.
• Invalid Item Flexfield (MSTK) metadata
• Missing grants/synonyms on underlying tables.
• Invalid APPS packages or dependent objects.
• Failed execution of Flexfield View Generator.
• Incomplete post-upgrade compilation. 
• Failed AutoConfig or AD utilities execution
• During EBS upgrade, KFF views were not regenerated
• Worker failure during the upgrade that was skipped and not fully resolved.

Usually indicates that the Inventory Item Key Flexfield (MSTK) failed to compile during the upgrade or post-upgrade object generation phase. Oracle EBS generates these KFV views automatically from the flexfield metadata; when generation fails, Oracle replaces the intended view with this placeholder.

Upgrade-specific logs to inspect

For 12.2.x, the actual ORA error is usually in:

• adwork*.log
• u*.log worker logs
• adadmin compile logs
• Flexfield generation logs (FNDFFMDC/FDFVGN related)

The placeholder view itself does not contain the root cause; the worker log contains the actual ORA- error.

Note: The relevant adworkxxx.log snippet, I can identify the exact root cause and tell you whether it is a flexfield metadata issue, invalid package issue, or a known 12.2.x upgrade problem like this.

CREATE OR REPLACE FORCE VIEW APPS.MTL_SYSTEM_ITEMS_B_KFV
(
VIEW_HAS_FAILED_CHECK_LOG_FILE
)
AS
SELECT 'View generation has failed. Check log file for error messages'
VIEW_HAS_FAILED_CHECK_LOG_FILE
FROM SYS.DUAL;

Verify the issue

Check the current view definition:

SELECT text
FROM dba_views
WHERE owner='APPS'
AND view_name='MTL_SYSTEM_ITEMS_B_KFV';

Check object status:

SELECT owner,
       object_name,
       object_type,
       status
FROM dba_objects
WHERE object_name='MTL_SYSTEM_ITEMS_B_KFV';

Check errors

SELECT line,
       position,
       text
FROM dba_errors
WHERE owner='APPS'
AND name='MTL_SYSTEM_ITEMS_B_KFV'
ORDER BY sequence;

Find invalid flexfield views / Verify Item Flexfield (MSTK)
select application_table_name,
       id_flex_code,
       concatenated_segs_view_name
from applsys.fnd_id_flexs
where concatenated_segs_view_name is not null;

Regenerate the Key Flexfield View

From EBS responsibility:

System Administrator
→ Application
→ Flexfield
→ Key
→ Segments

Query:

Application : Inventory
Flexfield Title : System Items

Then:

Compile

or use concurrent program:

Compile Key Flexfield Segments

Recompile invalid objects / Mandatory post-upgrade checks for 12.2.x

EXEC UTL_RECOMP.RECOMP_SERIAL();

or

@?/rdbms/admin/utlrp.sql

For Oracle EBS 12.2.x

If this occurred after clone, patching, or upgrade:

1. Run AutoConfig on both tiers.
2. Run adadmin → Compile APPS schema.
3. Run "Compile Key Flexfield Segments".
4. Verify that MTL_SYSTEM_ITEMS_B_KFV gets recreated with the actual item flexfield columns rather than the single message column.

                                                                     OR

Create MTL_SYSTEM_ITEMS_B_KFV view from MTL_SYSTEM_ITEMS_B table.

How to Delete a Concurrent Program in Oracle EBS

In Oracle EBS, a Concurrent Program cannot normally be deleted from the front-end forms once it has been created and used. The recommended approach in Production is usually to disable the concurrent program rather than delete it. Oracle provides APIs in the FND_PROGRAM package for deleting custom concurrent programs and executables from the backend.

Option 1: Disable the Concurrent Program (Recommended)

Navigation:

System Administrator
→ Concurrent
→ Program
→ Define

Query the program and uncheck:

Enabled = No

A disabled program will no longer appear in the Submit Request form and cannot be submitted.

Option 2: Delete Concurrent Program from Backend

DECLARE
  P_PROG_SHORT_NAME VARCHAR2(240) := 'XXX_EMAIL_VENDOR';
  P_EXEC_SHORT_NAME VARCHAR2(240) := 'xxx_email_vendor';
  P_APPL_FULL_NAME VARCHAR2(240) := 'XXNICSI Custom';
  P_APPL_SHORT_NAME VARCHAR2(240) := 'XXNICSI';
  P_DEL_PROG_FLAG VARCHAR2(1) := 'Y';
  P_DEL_EXEC_FLAG VARCHAR2(1) := 'Y';
BEGIN
  --Check if it exists
  IF FND_PROGRAM.PROGRAM_EXISTS(P_PROG_SHORT_NAME, P_APPL_SHORT_NAME) AND
     FND_PROGRAM.EXECUTABLE_EXISTS(P_EXEC_SHORT_NAME, P_APPL_SHORT_NAME) THEN
      IF P_DEL_PROG_FLAG = 'Y' THEN
      FND_PROGRAM.DELETE_PROGRAM(P_PROG_SHORT_NAME, P_APPL_FULL_NAME);
    END IF;
    IF P_DEL_EXEC_FLAG = 'Y' THEN
      FND_PROGRAM.DELETE_EXECUTABLE(P_EXEC_SHORT_NAME, P_APPL_FULL_NAME);
    END IF;
    COMMIT;
    DBMS_OUTPUT.PUT_LINE('Deleted successfully');
  ELSE
    DBMS_OUTPUT.PUT_LINE('Delete failed');
  END IF;
EXCEPTION
  WHEN OTHERS THEN
    DBMS_OUTPUT.PUT_LINE('Error: ' || SQLERRM);
END;

/