Symptoms

• The Inventory Transfer to GL process (Transfer Transactions to GL) fails or cannot be resubmitted for the affected group.
• GL_INTERFACE contains rows for the affected group_id from a previous failed transfer attempt that were never successfully imported to GL.
• MTL_MATERIAL_ACCOUNTS rows for the affected gl_batch_id show a non-negative batch ID, indicating the transfer was attempted but not completed — the records are locked to the failed batch and cannot be re-transferred.
• Re-running the Transfer to GL process does not pick up the affected transactions because the batch ID indicates they were already processed.

Root Cause

An inventory GL Transfer run failed after populating GL_INTERFACE but before completing the GL Journal Import. This left orphaned rows in GL_INTERFACE associated with the failed group_id. The corresponding MTL_MATERIAL_ACCOUNTS records have a positive gl_batch_id stamped from the failed run, which prevents the Transfer to GL process from re-selecting them. Resetting the gl_batch_id to -1 allows the Transfer to GL process to re-pick the transactions, and clearing the GL_INTERFACE rows removes the orphaned data from the previous failed attempt.

Resolution

Run data_fix.txt. Backup tables are created for:

• GL_INTERFACE rows for the affected group_id
• MTL_MATERIAL_ACCOUNTS rows for the affected gl_batch_id

Delete from GL_INTERFACE where group_id = <affected_group_id>. Commit. This removes the orphaned rows from the failed transfer run.

Update MTL_MATERIAL_ACCOUNTS to set gl_batch_id = -1 where gl_batch_id = <affected_gl_batch_id>. Commit. Setting gl_batch_id = -1 is the Oracle convention for "not yet transferred" — the Transfer to GL process selects rows with gl_batch_id = -1.

Resubmit the Inventory Transfer Transactions to GL concurrent program. After the transfer completes, run GL Journal Import for the new group to import the journals, then post the resulting journal batch.

Script Inventory

Key Tables Affected