*******ORACLE Apps DBA & ORACLE DBA Blog*******: 2026

Friday, 5 June 2026

Compilation of Invalid APPS Schema Objects After Oracle EBS 12.2.x Upgrade

In Oracle EBS 12.2.x upgrades, compiling invalid objects in the APPS schema is a critical post-upgrade activity. You can use the following notes in your upgrade documentation or interview discussions.

Why APPS Invalid Objects Occur

Invalid objects in the APPS schema may occur due to:

Database upgrade (11g → 19c)
Oracle EBS upgrade (12.1.x → 12.2.x / 12.2.14)
Failed ADOP patching cycle
Missing grants or synonyms
Dependency changes in packages, views, and materialized views
Custom objects referencing obsolete Oracle objects

Check Invalid Objects

SELECT object_name, object_type FROM dba_objects WHERE owner='APPS' AND status='INVALID';

Compile invalid object whole APPS Schema:

$ . /apps/EBS122/EBSapps.env run

[applmgr@proderpappl ~]$ sqlplus apps/apps_pwd

SQL*Plus: Release 10.1.0.5.0 - Production on Thu Jan 15 10:42:43 2026

Connected to:

Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production

SQL>@$AD_TOP/sql/adutlrcmp.sql

Session Information:

INSTANCE_NAME SCHEMA_NAME EDITION_NAME SYSDATE

---------------- --------------- --------------- ----------------

PRODCDB APPS ORA$BASE 2026-01-15 10:42

Invalid Objects per Owner (before compile):

OWNER ACTUAL STUB TOTAL

------------------------------ ---------- ---------- ----------

APPS 26 0 26

Compiling Objects...

PL/SQL procedure successfully completed.

Elapsed: 00:00:08.58

Invalid Objects per Owner (after compile):

OWNER ACTUAL STUB TOTAL

------------------------------ ---------- ---------- ----------

APPS 26 0 26

Commit complete.

Disconnected from Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production

Parallel recompilation:

SQL>EXEC UTL_RECOMP.RECOMP_PARALLEL();

SQL>EXEC UTL_RECOMP.RECOMP_PARALLEL(8);

Run AD Administration


[applmgr@proderpappl ~]$ adadmin

Navigate to:

AD Administration Main Menu
--------------------------------------------------
1. Generate Applications Files menu
2. Maintain Applications Files menu
3. Compile/Reload Applications Database Entities menu
4. Maintain Applications Database Entities menu
5. Change Maintenance Mode
6. Exit AD Administration

Enter your choice [6] : 3

Compile/Reload Applications Database Entities
---------------------------------------------------
1. Compile APPS schema
2. Compile menu information
3. Compile flexfields
4. Reload JAR files to database
5. Return to Main Menu

Enter your choice [5] : 1

One by one compile invalid object:

[applmgr@proderpappl ~]$ sqlplus apps/apps_pwd

SQL*Plus: Release 10.1.0.5.0 - Production on Thu Jan 15 13:53:42 2026

Connected to:

Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production

SQL> ALTER PACKAGE APPS.xx_package COMPILE;
SQL> ALTER PACKAGE APPS.xx_package COMPILE BODY;
SQL> ALTER VIEW APPS.xx_view COMPILE;

SQL> ALTER SYNONYM APPS.xx_synonym COMPILE;

Oracle Recommended Script

Run Oracle's recompilation utility:


Connect as SYSDBA and run the script through SQL*Plus:
$sqlplus "/ as sysdba"

SQL> @?/rdbms/admin/utlrp.sql

Enable Archive Mode and Archive Log Destination Change During Database Upgrade

During the Oracle Database upgrade for the Oracle EBS 12.2.x environment, the archive log destination was relocated to a new filesystem to ensure adequate storage capacity for the increased archive log generation that occurs during upgrade activities. This preventive measure helps avoid archive destination space issues, which could interrupt the upgrade process and potentially cause database downtime.

During an Oracle Database upgrade (especially for Oracle EBS 12.2.x upgrades), it is recommended to:

Enable ARCHIVELOG mode (if not already enabled).
Configure a dedicated archive log destination with sufficient free space.
Prevent upgrade failures caused by archive destination space exhaustion.
Facilitate database recovery in case of upgrade rollback requirements.

Pre-Upgrade Validation

Verified current archive log configuration.
Checked available filesystem space for existing archive destinations.
Confirmed archive log generation rate during upgrade windows.
Created and validated the new archive log directory with appropriate ownership and permissions.

Why This Step Is Required

Database upgrade operations generate a large volume of redo logs due to:

Data dictionary upgrades
Invalid object recompilations
AD/TXK patches
Statistics gathering
Online patching synchronization activities

Implementation

Create New Archive Log Directory

[root@proderpdb ~]# mkdir -p /oradata/prod/db/data/archive

[root@proderpdb ~]# chown oracle:dba /oradata/prod/db/data/archive

[root@proderpdb ~]# chmod 775 /oradata/prod/db/data/archive

Reviewed the existing archive log destination:

[oracle@proderpdb ~]$ . PRODCDB_proderpdb.env

[oracle@proderpdb ~]$ sqlplus / as sysdba
SQL*Plus: Release 19.0.0.0.0 - Production on Thu Dec 18 13:53:15 2025
Version 19.28.0.0.0
Copyright (c) 1982, 2025, Oracle. All rights reserved.
Connected to:
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.28.0.0.0
SQL>

SQL> show parameter recovery
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest string
db_recovery_file_dest_size big integer 20G
recovery_parallelism integer 0
remote_recovery_file_dest string

SQL> archive log list
Database log mode No Archive Mode
Automatic archival Disabled
Archive destination /oradata/prod/app/oracle/product/19.3.0/dbs/arch
Oldest online log sequence 9
Current log sequence 11

SQL> shutdown immediate
Database dismounted.
ORACLE instance shut down.
Database closed.

SQL> startup mount
ORA-32004: obsolete or deprecated parameter(s) specified for RDBMS instance
ORACLE instance started.
Total System Global Area 1.6106E+10 bytes
Fixed Size 18662888 bytes
Variable Size 1946157056 bytes
Database Buffers 1.4126E+10 bytes
Redo Buffers 14888960 bytes
Database mounted.

SQL> ALTER DATABASE ARCHIVELOG;
Database altered.

SQL> alter system set log_archive_dest_1= 'LOCATION=/oradata/prod/db/data/archive' scope=both;
System altered.

SQL> archive log list
Database log mode Archive Mode
Automatic archival Enabled
Archive destination /oradata/prod/db/data/archive
Oldest online log sequence 9
Next log sequence to archive 11
Current log sequence 11

SQL> alter database open;

Database altered.

SQL> select destination,STATUS from v$archive_dest where status='VALID';

DESTINATION
--------------------------------------------------------------------------------
STATUS
---------
/oradata/prod/db/data/archive
VALID

SQL> alter system switch logfile;
System altered.

SQL> archive log list
Database log mode Archive Mode
Automatic archival Enabled
Archive destination /oradata/prod/db/data/archive
Oldest online log sequence 10
Next log sequence to archive 12
Current log sequence 12
SQL>

Thursday, 4 June 2026

Oracle Central Inventory (oraInventory) Not Found / Missing oraInst.loc Configuration

This error occurs when Oracle Universal Installer (OUI) or RapidWiz cannot find the Oracle Central Inventory (oraInventory).

Central Inventory does not exist. Skipping central inventory check...
Trying local inventory in Oracle Home...
Cannot find oraInventory
Please create oraInst.loc in the proper directory for your operating system.
The contents should look like this:
inventory_loc=/oracle/oraInventory
where "/oracle/oraInventory" is the direcotry where the central inventory is to be located.

1. Check if `oraInst.loc` exists

On Linux:


# cat /etc/oraInst.loc

If the file does not exist, create it.

2. Create Oracle Inventory Directory

As root: DB Side


# mkdir -p /oradata/prod/app/oraInventory
# chown -R oracle:dba/oradata/prod/app/oraInventory
# chmod -R 775 /oradata/prod/app/oraInventory

As root: Application Side
# mkdir -p /apps/EBS122/oraInventory
# chown -R applmgr:dba/apps/EBS122/oraInventory
# chmod -R 775 /apps/EBS122/oraInventory
Adjust ownership & directory according to your installation user and group.

3. Create /etc/oraInst.loc
As root:
#vi /etc/oraInst.loc
Contents: DB Side
inventory_loc=/oradata/prod/app/oraInventory
inst_group=dba

Contents: Application Side
inventory_loc=/apps/EBS122/oraInventory
inst_group=dba

Set permissions:
chmod 664 /etc/oraInst.loc

4. Verify
As root:
#cat /etc/oraInst.loc

While launching R12.2.x installer in RHEL/OEL encountered issue

Error

This is a very common issue when running Oracle EBS 12.2.x Rapid Install (RapidWiz) on newer Linux servers.

[applmgr@proderpappl rapidwiz]$ Exception in thread "main" java.lang.UnsatisfiedLinkError:
/apps/stage122/startCD/Disk1/rapidwiz/jre/Linux_x64/1.6.0/lib/i386/xawt/libmawt.so: libXtst.so.6: cannot open shared object file: No such file or directory
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(Unknown Source)
at java.lang.ClassLoader.loadLibrary(Unknown Source)
at java.lang.Runtime.load0(Unknown Source)
at java.lang.System.load(Unknown Source)
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(Unknown Source)
at java.lang.ClassLoader.loadLibrary(Unknown Source)
at java.lang.Runtime.loadLibrary0(Unknown Source)
at java.lang.System.loadLibrary(Unknown Source)
at sun.security.action.LoadLibraryAction.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.awt.NativeLibLoader.loadLibraries(Unknown Source)
at sun.awt.DebugHelper.<clinit>(Unknown Source)
at java.awt.Component.<clinit>(Unknown Source)
Could not find the main class: oracle.apps.ad.rapidwiz.RIWizard. Program will exit.

Root Cause

RapidWiz is trying to load the X11 library libXtst.so.6, but the package is not installed on the OS:


libXtst.so.6: cannot open shared object file: No such file or directory

Because the Java GUI libraries cannot load, RapidWiz fails to start:


Could not find the main class: oracle.apps.ad.rapidwiz.RIWizard

Solution
RapidWiz is trying to load a 32-bit library.

If using OL7/OL8 x86_64, install 32-bit compatibility packages:

Step 1: Verify Missing Library
$ locate libXtst.so.6
or
$ find /usr -name "libXtst.so*"
If nothing is returned, install the package.
Step 2: Install Required Package
RHEL/OEL 7
Install below missing two rpms in the same order.

[root@proderpappl ~]# rpm -ivh libXi-1.3-3.el6.i686.rpm
warning: libXi-1.3-3.el6.i686.rpm: Header V3 RSA/SHA256 Signature, key ID fd431d51: NOKEY
Preparing...                ########################################### [100%]
   1:libXi                  ########################################### [100%]

[root@proderpappl ~]# rpm -ivh libXtst-1.0.99.2-3.el6.i686.rpm
warning: libXtst-1.0.99.2-3.el6.i686.rpm: Header V3 RSA/SHA256 Signature, key ID fd431d51: NOKEY
Preparing...                ########################################### [100%]
   1:libXtst                ########################################### [100%]

Verify:
[root@proderpappl ~]# rpm -qa | grep Xtst
[root@proderpappl ~]# ln -s /usr/lib64/libXtst.so.6 /usr/lib/libXtst.so.6

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();


@?/rdbms/admin/utlrp.sql

For Oracle EBS 12.2.x

If this occurred after clone, patching, or upgrade:

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

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;

How to Register a Concurrent Program from the backend in Oracle EBS Applicaton

If you want to register a Concurrent Program from the backend (without using the System Administrator forms), Oracle EBS provides APIs in the FND_PROGRAM package.

Backend Registration Steps

Register Executable
Register Concurrent Program
Define Parameters
Add Program to Request Group
Compile Security Cache

Step 1: Create the Concurrent Program Executable

Use the FND_PROGRAM.executable procedure to register your source script or database procedure.

BEGIN

FND_PROGRAM.executable(

executable => 'XXX_EMAIL_VENDOR', -- Executable Name (User visible)

application => 'XXNICSI', -- Application Short Name

short_name => 'XXX_EMAIL_VENDOR', -- Executable Short Name

description => '', -- Description

execution_method => 'PL/SQL Stored Procedure', -- Execution Method (e.g., Host, SQL*Plus, PL/SQL Stored Procedure)

execution_file_name => 'XXX_EMAIL_VENDOR', -- Database Package.Procedure or physical filename

subroutine_name => NULL,

icon_name => NULL,

language_code => 'US'

);

COMMIT;

DBMS_OUTPUT.put_line('Executable Created Successfully.');

EXCEPTION

WHEN OTHERS THEN

DBMS_OUTPUT.put_line('Error creating executable: ' || SQLERRM);

ROLLBACK;

END;

Note: Change execution_method according to your requirement, such as 'SQL*Plus', 'Host', or 'Oracle Reports'.

Step 2: Register the Concurrent Program

Link the executable you created in Step 1 to a newly defined concurrent program using FND_PROGRAM.register.

BEGIN

FND_PROGRAM.register(

program => 'NICSI EMAIL VENDOR', -- Program User Name

application => 'XXNICSI', -- Application Short Name

enabled => 'Y', -- Enabled status (Y/N)

short_name => 'XXX_EMAIL_VENDOR', -- Program Short Name

description => 'Custom Program Registered from Backend',

executable_short_name => 'XXX_EMAIL_VENDOR', -- Short name from Step 1

executable_application => 'XXNICSI', -- Executable Application Short Name

execution_options => NULL,

priority => NULL,

save_output => 'Y', -- Save Output (Y/N)

print => 'Y', -- Allow Printing (Y/N)

cols => NULL,

rows => NULL,

style => NULL,

style_required => 'N',

printer => NULL,

request_type => NULL,

request_type_application => NULL,

use_in_srs => 'Y', -- Visible in Submit Request Screen (Y/N)

allow_disabled_values => 'N',

run_alone => 'N',

output_type => 'XML' -- Output format (TEXT, PDF, HTML, XML)

);

COMMIT;

DBMS_OUTPUT.put_line('Concurrent Program Registered Successfully.');

EXCEPTION

WHEN OTHERS THEN

DBMS_OUTPUT.put_line('Error registering program: ' || SQLERRM);

ROLLBACK;

END;

Step 3: Adding Parameters from Backend (Optional)

If your concurrent program requires run-time input parameters, you can add them dynamically via FND_PROGRAM.parameter:

BEGIN

FND_PROGRAM.parameter(

program_short_name => 'XXX_EMAIL_VENDOR',

program_application => 'XXNICSI',

sequence => 10, -- Parameter Sequence Number

parameter => 'p_input_date', -- Parameter Token Name

description => 'Reporting Date', -- Parameter Description

value_set => 'Standard_Date', -- Value Set Name

default_type => 'Current Date', -- Default Type (Constant, Current Date, Profile, etc.)

default_value => NULL,

required => 'Y', -- Is Mandatory? (Y/N)

enable => 'Y',

display => 'Y' -- Visible to User? (Y/N)

);

COMMIT;

DBMS_OUTPUT.put_line('Parameter added successfully.');

END;

Step 4: Add Concurrent Program to a Request Group

To make the concurrent program accessible via the front-end Oracle Standard Request Submission (SRS) window, assign it to a designated Request Group using FND_PROGRAM.add_to_group.

BEGIN

FND_PROGRAM.add_to_group(

program_short_name => 'XXX_EMAIL_VENDOR', -- Program Short Name from Step 2

program_application => 'XXNICSI', -- Program Application Short Name

request_group => 'NICSI Reports', -- Target Request Group Name

group_application => 'XXNICSI Custom' -- Request Group Application Short Name

);

COMMIT;

DBMS_OUTPUT.put_line('Program Successfully Added to Request Group.');

EXCEPTION

WHEN OTHERS THEN

DBMS_OUTPUT.put_line('Error assigning to request group: ' || SQLERRM);

ROLLBACK;

END;

Verification Query

Verify your backend registration details instantly by executing this SQL select statement:

select * from FND_APPLICATION_VL where APPLICATION_NAME='XXNICSI Custom';

SELECT fcp.user_concurrent_program_name, fcp.concurrent_program_name, fe.execution_file_name, fe.execution_method_code

FROM fnd_concurrent_programs_vl fcp, fnd_executables fe

WHERE fcp.executable_id = fe.executable_id

AND fcp.concurrent_program_name = 'XX_CUSTOM_PROG_SHORT';

Useful Backend Tables

Object	Table
Executable	FND_EXECUTABLES
Concurrent Program	FND_CONCURRENT_PROGRAMS
Program Translation	FND_CONCURRENT_PROGRAMS_TL
Parameters	FND_DESCR_FLEX_COL_USAGE_VL
Request Groups	FND_REQUEST_GROUPS
Request Group Units	FND_REQUEST_GROUP_UNITS

Migration Script (Common in EBS)

Many Apps DBAs and Technical Consultants create deployment scripts like:


BEGIN
   -- Register Executable
   FND_PROGRAM.EXECUTABLE(...);

   -- Register Concurrent Program
   FND_PROGRAM.REGISTER(...);

   -- Add Parameters
   FND_PROGRAM.PARAMETER(...);

   -- Add to Request Group
   FND_PROGRAM.ADD_TO_GROUP(...);

   COMMIT;
END;
/

This approach is commonly used during Oracle EBS R12.2.x migrations, cloning, and deployment of custom concurrent programs between DEV, TEST, and PROD environments.

Monday, 1 June 2026

[Oracle]APP-SQLAP-10062 The Payment Document Has No Associated Invoice Payments

Users reported that the system crashed halfway through processing data, causing the payment to be closed before the invoice was printed.

An error occurred while pressing the button: APP-SQLAP-10062 The Payment Document Has No Associated Invoice Payments.

Search Oracle related documents

R12: AP: APP-SQLAP-10062 Error Trying to Void a Manual Type Payment (Doc ID 1546742.1)

R12: AP/IBY: Generic Data Fix (GDF) Patch To Correct Checks with Missing Invoice Reference (Doc ID 2115968.1)

Use PL/SQL Developer to execute `@C:\ap_incorrect_checks_sel.sql` to confirm if there is a problem with the data. Alternatively, the following SQL should also be able to determine the issue.

Query1:

SELECT ac.check_id
, ac.amount
, ac.payment_id
, ac.status_lookup_code
, ac.currency_code
, ac.payment_type_flag
, ac.org_id
, ac.vendor_id
, ac.vendor_name
, ac.vendor_site_id
, aph.transaction_type
, aph.posted_flag
, aph.trx_pmt_amount
, aph.accounting_event_id
FROM ap_payment_history_all aph
, ap_checks_all ac
WHERE ac.check_id = aph.check_id(+)
AND ac.status_lookup_code NOT IN ('OVERFLOW','SET UP','SPOILED')
AND NVL(aph.historical_flag,'N') <> 'Y'
AND AC.CHECK_NUMBER=11802347
AND NOT EXISTS (SELECT '1' FROM ap_invoice_payments_all aip WHERE ac.check_id = aip.check_id)
AND ac.creation_date > (SELECT MIN(creation_date) FROM ad_bugs WHERE aru_release_name = 'R12')

Query2:

Select distinct ac.check_id,ac.checkrun_name,ac.checkrun_id,ac.payment_id
FROM ap_payment_history_all aph
, ap_checks_all ac
WHERE ac.check_id = aph.check_id(+)
AND ac.status_lookup_code NOT IN ('OVERFLOW','SET UP','SPOILED')
AND NVL(aph.historical_flag,'N') <> 'Y'
AND AC.CHECK_NUMBER=11802347
AND NOT EXISTS (SELECT '1' FROM ap_invoice_payments_all aip WHERE ac.check_id = aip.check_id)
AND ac.creation_date > (SELECT MIN(creation_date) FROM ad_bugs WHERE aru_release_name = 'R12')

Execute PL/SQL Developer to execute @C:\ap_incorrect_checks_fix.sql to correct the data.

Postscript:

One day, for some reason, the above methods suddenly stopped working. According to the standard operating procedure, an SR query should be initiated, but due to time constraints, I started reviewing the ap_incorrect_checks_fix.sql program and found that it performs the following actions.

1. Querying the TEMP TABLE provides data generated by ap_incorrect_checks_sel.sql.

2. Backup related tables, such as AP_CHECKS_ALL, AP_PAYMENT_HISTORY_ALL, and XLA_EVENTS.

3. Formal information on the anomaly (see the equation below)

-Delete the erroneous record AP_CHECKS_ALL and use the CHECK_ID recorded in the TEMP file.

-Delete the erroneous record AP_PAYMENT_HISTORY_ALL and use the CHECK_ID recorded in the TEMP file.

-Update XLA_EVENTS to EVENT_STATUS_CODE = 'N' and PROCESS_STATUS_CODE = 'P'.

select * from AP_CHECKS_ALL where CHECK_NUMBER=11802347
select * from AP_CHECKS_ALL where CHECK_ID=2417002
select * from AP_PAYMENT_HISTORY_ALL where CHECK_ID=2417002
select * from XLA_EVENTS where EVENT_ID=3613439

create table AP_TEMP_DRIVER_17927828_AC as select * from AP_CHECKS_ALL where CHECK_ID=2417002;

create table AP_TEMP_DRIVER_17927828_APH as select * from AP_PAYMENT_HISTORY_ALL where CHECK_ID=2417002;

create table AP_TEMP_DRIVER_17927828_XE as select * from XLA_EVENTS where EVENT_ID=3613439;

select * from AP_TEMP_DRIVER_17927828_AC
select * from AP_TEMP_DRIVER_17927828_APH
select * from AP_TEMP_DRIVER_17927828_XE

DELETE FROM AP_CHECKS_ALL WHERE CHECK_ID IN (SELECT DISTINCT CHECK_ID FROM AP_TEMP_DRIVER_17927828_AC);

DELETE FROM AP_PAYMENT_HISTORY_ALL WHERE CHECK_ID IN (SELECT DISTINCT CHECK_ID FROM AP_TEMP_DRIVER_17927828_APH);

select * from fnd_user where user_id=2809 lud---2312

UPDATE XLA_EVENTS
SET EVENT_STATUS_CODE = 'N',
PROCESS_STATUS_CODE = 'P',
last_updated_by = 2312,
last_update_date = SYSDATE,
last_update_login = (-1)
WHERE APPLICATION_ID = 200
AND EVENT_STATUS_CODE <> 'P'
AND EVENT_ID IN (SELECT DISTINCT ACCOUNTING_EVENT_ID FROM AP_TEMP_DRIVER_17927828_APH);

How to check a port is open on the firewall

To check whether a port is open in the firewall on Linux, use the method appropriate for your firewall.

1. Check if the service is listening

First verify the On the database server is listening on the port:

$ ss -tulpn | grep 1536

$ netstat -tulpn | grep 1536

$ lsof -i :1536

If nothing is listening, the firewall is not the issue.

2. Check Firewalld (RHEL/OEL/CentOS 7/8/9)

Check firewall status:

$ systemctl status firewalld

$ firewall-cmd --list-ports

$ firewall-cmd --query-port=1536/tcp

Output:

yes/no

3. Check iptables

List rules:

$ iptables -L -n

Search for port 1536:

$ iptables -L -n | grep 1536

For more details:

$ iptables -L INPUT -n --line-numbers

4. Test from a Remote Server

From another server, test connectivity On the application server:

Using telnet

$ telnet hostname 1536

$ telnet erpuatappl.nicsi.in1536

Using nc (netcat)

$ nc -zv hostname 1536

$ nc -zv erpuatappl.nicsi.in 8015
Ncat: Version 7.50 ( https://nmap.org/ncat )
Ncat: Connected to 10.24.248.33:8015.
Ncat: 0 bytes sent, 0 bytes received in 0.03 seconds.

5. Oracle Listener Specific Check

If port 1536 is for an Oracle listener:

$ lsnrctl status

Look for:

Listening Endpoints Summary...

(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=dbhost)(PORT=1536)))

Then test from the application server:

$ tnsping SERVICE_NAME

How to allow only specific users to access Oracle EBS Applications

During some special time periods, Business management wants to restrict users to access Oracle EBS Application but allow only one or two users to complete some dedicated tasks, such as month-end process.

Oracle EBS has a way to do that See below doc:

Doc ID 605538.1 (How To Lock Users Out Of E-Business Suite And Allow Specific Users). This only works if EBS application does not have multiple web nodes which may use load balancing in the middle.

R12.1.X

1. Backup file $ORA_CONFIG_HOME/10.1.3/Apache/Apache/conf/custom.conf

2. Edit file $ORA_CONFIG_HOME/10.1.3/Apache/Apache/conf/custom.conf and add a list of ip addresses for the users system that you want to allow access to the system.

The benefit of using custom.conf is that it is preserved when autoconfig is run.

$ vi $ORA_CONFIG_HOME/10.1.3/Apache/Apache/conf/custom.conf

Order deny,allow

Deny from all

Allow from 10.23.124.64--Users IP who allow to access EBS

#Allow from XX.XXX.XXX.XXX

#Allow from X.XXX.XXX.XXX

Allow from localhost

Allow from erpuatappl.nicsi.in

Allow from 10.24.248.33---Oracle EBS Application Server IP

</Location>

ErrorDocument 403 "Oracle Application Service is temporarily unavailable!!!. We are currently performing the maintenance activity. Normal Service will be restored soon........

Note:
You need to include localhost and your apps tier server name. One can use the PC name rather than IP address, however PC name is more sensitive to network config

3. Restart Apache

[applmgr@erpuatappl scripts]$ cd $ADMIN_SCRIPTS_HOME
[applmgr@erpuatappl scripts]$ ./adopmnctl.sh status
You are running adopmnctl.sh version 120.6.12010000.5

Checking status of OPMN managed processes...

adopmnctl.sh: exiting with status 0

adopmnctl.sh: check the logfile /UATappl/inst/apps/UAT_erpuatappl/logs/appl/admin/log/adopmnctl.txt for more information ...

[applmgr@erpuatappl scripts]$ ./adapcctl.sh stop

You are running adapcctl.sh version 120.7.12010000.2

Stopping OPMN managed Oracle HTTP Server (OHS) instance ...

opmnctl: stopping opmn managed processes...

adapcctl.sh: exiting with status 0

adapcctl.sh: check the logfile /UATappl/inst/apps/UAT_erpuatappl/logs/appl/admin/log/adapcctl.txt for more information ...

[applmgr@erpuatappl scripts]$ ./adopmnctl.sh status

You are running adopmnctl.sh version 120.6.12010000.5

Checking status of OPMN managed processes...

adopmnctl.sh: exiting with status 0

adopmnctl.sh: check the logfile /UATappl/inst/apps/UAT_erpuatappl/logs/appl/admin/log/adopmnctl.txt for more information ...

[applmgr@erpuatappl scripts]$ ./adapcctl.sh start

You are running adapcctl.sh version 120.7.12010000.2

Starting OPMN managed Oracle HTTP Server (OHS) instance ...

opmnctl: opmn is already running.

opmnctl: starting opmn managed processes...

adapcctl.sh: exiting with status 0

adapcctl.sh: check the logfile /UATappl/inst/apps/UAT_erpuatappl/logs/appl/admin/log/adapcctl.txt for more information ...

[applmgr@erpuatappl scripts]$ ./adopmnctl.sh status

You are running adopmnctl.sh version 120.6.12010000.5

Checking status of OPMN managed processes...

adopmnctl.sh: exiting with status 0

adopmnctl.sh: check the logfile /UATappl/inst/apps/UAT_erpuatappl/logs/appl/admin/log/adopmnctl.txt for more information ...

4. Now only the users who are assigned to the ip addresses added will have access. All other users will get a forbidden error when they attempt to login.

This is a very simple solution and what makes it good is that it can be done programatically.

If Any user tries to login he will get below error

The forbidden error looks like this:

Forbidden
You don’t have permission to access /OA_HTML/AppsLocalLogin.jsp on this server

If you want to change the message you can do this: edit custom.conf add a line as follows (change the text to suit your requirements)

ErrorDocument 403 “Forbidden oops, you cannot access the production instance as it is month end, only certain users have access at this time

ErrorDocument 403 "Oracle Application Service is temporarily unavailable!!!. We are currently performing the maintenance activity. Normal Service will be restored soon........

R12.2.X

If users use VPN or Normal to login onto company's network PC.

1. Backup file $IAS_ORACLE_HOME/instances/EBS_web_OHS1/config/OHS/EBS_web/custom.conf

2. Edit file $IAS_ORACLE_HOME/instances/EBS_web_OHS1/config/OHS/EBS_web/custom.conf
and add a list of ip addresses for the users system that you want to allow access to the system.

The benefit of using custom.conf is that it is preserved when autoconfig is run.

Only those users can access our Oracle EBS Application whose users IP allow in custom.conf file and all other users get "Forbidden oops." message on the login page.

$ vi $IAS_ORACLE_HOME/instances/EBS_web_OHS1/config/OHS/EBS_web/custom.conf

Order deny,allow

Deny from all

Allow from 10.23.124.64--Users IP who allow to access EBS

#Allow from XX.XXX.XXX.XXX

#Allow from X.XXX.XXX.XXX

Allow from localhost

Allow from erpuatappl.nicsi.in

Allow from 10.24.248.33---Oracle EBS Application Server IP

</Location>

Use "grep ohs_inst $CONTEXT_FILE" to identify the OHS# (i.e. EBS_web_OHS1) and the location.

3. Restart Apache

If load balancing is used, above method may not work because end-user's IP may not reach EBS server. Other ways can be used to accomplish this but additional work is needed.

1. Create a special Responsibility. Then, disable all other Responsibilities. Only users in the new Responsibility will be able to log into EBS site to do the work.

2. You can disable/enable users in bulk using API. But this will change last_update_date and last_updated_by of table fnd_user, and may become a security auditing concern (specially when we have bulk active users in the system. Huge worry is users' password would still work).

fnd_user_pkg.disableuser('<username>');

fnd_user_pkg.enableuser('<username>');

3. Ask internal firewall team to restrict access to the EBS Load Balancer URL to specific IP addresses.

4. Change the Load Balancer port to a temporary port that only will be given to the authorized users, and after the archive process is complete, the port can be switched back to the original port so it becomes available to all users.

Friday, 5 June 2026

Why APPS Invalid Objects Occur

Run AD Administration

Oracle Recommended Script

Pre-Upgrade Validation

Why This Step Is Required

Implementation

Thursday, 4 June 2026

1. Check if oraInst.loc exists

2. Create Oracle Inventory Directory

3. Create /etc/oraInst.loc

4. Verify

Error

Root Cause

Solution

Common causes in Oracle EBS

Upgrade-specific logs to inspect

Verify the issue

Check errors

Find invalid flexfield views / Verify Item Flexfield (MSTK)

Regenerate the Key Flexfield View

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

For Oracle EBS 12.2.x

Backend Registration Steps

Useful Backend Tables

Migration Script (Common in EBS)

Monday, 1 June 2026

1. Check if `oraInst.loc` exists

3. Create `/etc/oraInst.loc`