Fix Oracle EBS MTL_TRANSACTIONS_INTERFACE Rows Stuck With PROCESS_FLAG = 3
EBS MTL_TRANSACTIONS_INTERFACE PROCESS_FLAG 3 error ERROR_EXPLANATION
Also searched as
- Oracle EBS inventory transaction stuck in interface PROCESS_FLAG = 3
- Pending Transactions form error EBS inventory resubmit
- MTL_TRANSACTIONS_INTERFACE error_code error_explanation how to fix
- Process transaction interface completed with error EBS
Short answer
A row in MTL_TRANSACTIONS_INTERFACE with PROCESS_FLAG = 3 failed validation or processing in the Inventory Transaction Manager. The reason is written to ERROR_CODE and ERROR_EXPLANATION on that row. Correct the data (item, subinventory, locator, period, lot or serial), set PROCESS_FLAG back to 1 and let the Process transaction interface program or the Transaction Manager pick it up again.
Applies to: Oracle E-Business Suite 11i, R12.1 and R12.2 Inventory, including custom feeds from MES, WMS, barcode scanners and conversion scripts that insert into the open interface
How to find and clear the error
- 1Query the failed rows: SELECT transaction_interface_id, inventory_item_id, organization_id, transaction_type_id, error_code, error_explanation FROM mtl_transactions_interface WHERE process_flag = 3.
- 2Open the same rows in the UI: Inventory > Transactions > Pending Transactions, then the Transaction Interface tab (the Interface Transactions form). The Error column shows the same text.
- 3Read ERROR_EXPLANATION first. It usually names the exact validation: inactive item, invalid subinventory, closed inventory period, missing locator, insufficient on-hand, or bad lot or serial.
- 4Fix the root cause in the setup or on the row. Examples: open the inventory period, assign the item to the organization, enable the subinventory, correct SUBINVENTORY_CODE or LOCATOR_ID.
- 5In the Pending Transactions form, tick Resubmit on the corrected rows and save. Resubmit sets PROCESS_FLAG back to 1 and clears the error text.
- 6For scripted fixes, UPDATE the row to PROCESS_FLAG = 1, LOCK_FLAG = 2, and null out ERROR_CODE and ERROR_EXPLANATION. Only do this on rows whose cause is fixed.
- 7Run the Inventory Transaction Worker or wait for the Transaction Manager. Check Concurrent > Requests for Process transaction interface and confirm the row disappears from the interface table.
- 8Confirm the result in MTL_MATERIAL_TRANSACTIONS using the SOURCE_CODE or TRANSACTION_SOURCE_ID you loaded.
What PROCESS_FLAG values mean
The open interface works like most EBS interfaces: your program inserts rows, a manager validates and processes them, and the rows either leave the table or stay flagged. In MTL_TRANSACTIONS_INTERFACE, PROCESS_FLAG = 1 means ready to process, 2 means being processed or not yet released, and 3 means error. LOCK_FLAG = 1 means a worker has the row, which matters when you are about to update it.
TRANSACTION_MODE is the other switch people forget. Mode 1 is online (the caller waits for the Transaction Manager), 2 is concurrent (the Process transaction interface program picks it up), and 3 is background. If rows sit at PROCESS_FLAG = 1 forever and never turn to 3, the problem is not data, it is that nothing is picking the rows up, so check the Transaction Manager and the concurrent program rather than the row contents.
SELECT process_flag, transaction_mode, lock_flag, COUNT(*) FROM mtl_transactions_interface GROUP BY process_flag, transaction_mode, lock_flag;
Common ERROR_EXPLANATION causes and their fixes
Inventory period problems account for a large share of failures. The transaction date must fall in an open inventory accounting period for that organization. Check Inventory > Accounting Close Cycle > Inventory Accounting Periods. If someone closed the period but a scanner or MES keeps posting backdated transactions, fix the feed to use the current date rather than reopening periods.
Item and location validation come next. The item must be assigned to the organization and enabled for the transaction (transactable, stockable, and for the right subinventory restrictions). Locator-controlled subinventories need LOCATOR_ID or a valid locator segment set. Lot and serial controlled items need rows in MTL_TRANSACTION_LOTS_INTERFACE or MTL_SERIAL_NUMBERS_INTERFACE keyed by the same TRANSACTION_INTERFACE_ID, and the lot quantities must sum to the transaction quantity.
Quantity and sign errors are the third group. Issues carry a negative TRANSACTION_QUANTITY, receipts a positive one, and the UOM must be convertible to the item's primary UOM. Negative on-hand is blocked unless the organization parameter allows it, which produces the insufficient quantity message on issues to WIP or sales orders.
Resubmitting safely
Resubmitting a row twice does not double-post as long as the first attempt really failed, because failed rows never reach MTL_MATERIAL_TRANSACTIONS. The risk is the opposite case: a row that did post but whose interface row was left behind by a crashed worker. Before bulk updating, compare TRANSACTION_INTERFACE_ID, SOURCE_CODE and SOURCE_LINE_ID against MTL_MATERIAL_TRANSACTIONS for the same date.
Take a backup of the failing rows before any scripted update. A simple CREATE TABLE ... AS SELECT into a custom schema gives you a trail and an easy rollback. Do not delete interface rows to make the form look clean unless the business has agreed the transaction is abandoned, because the physical movement already happened on the shop floor.
CREATE TABLE xx_mti_err_backup AS
SELECT * FROM mtl_transactions_interface WHERE process_flag = 3;
UPDATE mtl_transactions_interface
SET process_flag = 1, lock_flag = 2,
error_code = NULL, error_explanation = NULL
WHERE process_flag = 3
AND transaction_interface_id IN (SELECT transaction_interface_id FROM xx_mti_fixed_ids);Preventing repeat failures from integrations
Most recurring PROCESS_FLAG = 3 rows come from an integration that does not mirror EBS validation. Validate item, organization, subinventory, locator and period in the source system or in a staging table before insert. Log the TRANSACTION_INTERFACE_ID back to the sender so an operator can see which scan failed and why.
Add a monitor that counts error rows daily and emails the inventory controller. Silent failures are the real cost: material moves physically, on-hand in EBS drifts, and the mismatch shows up weeks later at cycle count or period close.
Common pitfalls
- !Setting PROCESS_FLAG to 1 without fixing the cause just makes the row fail again and burns Transaction Manager cycles.
- !Updating a row while LOCK_FLAG = 1 collides with a worker; wait for the worker or check for a hung Inventory Transaction Worker request.
- !Deleting error rows to clear the form leaves physical movement unrecorded and on-hand wrong.
- !Lot or serial child rows with a different TRANSACTION_INTERFACE_ID than the parent produce confusing lot errors even when the parent looks fine.
- !Reopening a closed period to push backdated rows distorts costing and period-end reports; fix the feed's transaction date instead.
How an ERP-grounded AI assistant handles this
An ERPray style assistant grounded in your EBS instance can run the read-only query against MTL_TRANSACTIONS_INTERFACE, group failures by ERROR_EXPLANATION and show which integration source and item caused each cluster, with the SQL visible. It respects your responsibilities and does not update rows by itself. Any proposed resubmit or PROCESS_FLAG change would go to an inventory controller for approval. It does not replace the Pending Transactions form for the actual fix.
Frequently asked questions
Where do I see ERROR_EXPLANATION in the EBS UI?
Use Inventory > Transactions > Pending Transactions and open the Transaction Interface tab. Failed rows show the error text in the Error Explanation field. You can correct fields on the row there and tick Resubmit. The same text is stored in the ERROR_EXPLANATION column of MTL_TRANSACTIONS_INTERFACE.
Is it safe to update PROCESS_FLAG directly in SQL?
It works technically and is commonly done for bulk fixes, but Oracle intends you to use the Resubmit option in the form. If you script it, back up the rows, fix the underlying cause first, and make sure LOCK_FLAG is not 1. Test on a clone before running in production.
Why do my rows stay at PROCESS_FLAG = 1 and never process?
That is a processing problem, not a data problem. Check that the Inventory Transaction Manager is running under Concurrent > Manager > Administer, that the Process transaction interface program is scheduled for concurrent mode rows, and that TRANSACTION_MODE matches how you expect rows to be picked up.
Can lot and serial rows be fixed separately?
Yes. Lot rows live in MTL_TRANSACTION_LOTS_INTERFACE and serial rows in MTL_SERIAL_NUMBERS_INTERFACE, both linked by TRANSACTION_INTERFACE_ID. Their own ERROR_CODE columns often explain the failure better than the parent row. The lot quantities must total the parent quantity after UOM conversion.
Related
How to Close an Inventory Accounting Period in Oracle EBS
Before closing an Inventory period, run the Pending Transactions report to clear every uncosted or erroring material transaction, then close through Inventory > Accounting Close Cycle > Inventory Accounting Periods. Inventory will refuse to close while pending transactions remain, and any that get force-closed into the next period will misstate both months' costed inventory value.
Error fixOracle EBS Concurrent Manager Will Not Start: How to Fix It
A concurrent manager that will not start in Oracle EBS is almost always one of three things: the node registered in FND_NODES no longer matches the actual hostname (common after cloning), stale OS processes are blocking a fresh start, or the database and listener the manager connects to are unreachable. Check the internal manager log, verify the node name, clear stale processes, and restart with adcmctl.sh.
Error fixFix Oracle EBS Uncosted Material Transactions Blocking Period Close
Uncosted material transactions are rows in MTL_MATERIAL_TRANSACTIONS whose COSTED_FLAG is N (waiting for the Cost Manager) or E (costing error). Use the Resolve Uncosted Transactions form to read the error, fix the cause in costing setup or item cost, then let the Cost Manager reprocess them. The inventory period will not close while these rows exist.
How-toOracle EBS Month-End Close Checklist: GL, AP, AR
Close sub-ledgers before General Ledger: finish and account for all Payables and Receivables transactions, close the AP and AR periods, transfer journals to GL through Create Accounting, reconcile sub-ledger to GL, then close the GL period last. Closing GL before a sub-ledger is fully accounted is the single most common cause of a reopen.
Error fixFix FRM-40735: WHEN-VALIDATE-RECORD Trigger Raised Unhandled Exception ORA-06508
FRM-40735 with ORA-06508 almost always means a PL/SQL package used by the form was recompiled while your session still held the old cached state, or the trigger's own exception handling does not trap a real data error. Exit the form completely and re-enter it; if the error repeats for all users, recompile invalid objects on the database and check for a bad custom trigger.
Error fixFix Oracle EBS Workflow Notification Mailer Not Sending Emails
When EBS notifications stop reaching inboxes, check the mailer status in Oracle Applications Manager (OAM) Workflow Manager first - a Suspended or Error status almost always points at an SMTP or IMAP connectivity or credential problem introduced by a mail server change, not at Workflow itself. Fix the mail server configuration, restart the mailer component, and requeue the backlog.
AI for ERPAI for Oracle E-Business Suite, Without Leaving On-Prem
Add AI to Oracle E-Business Suite 12.2 without moving off-prem. Query concurrent programs, interface tables, and AP/PO data with a private LLM. See how.
AI for ERPAI for Oracle EBS in Industrial Manufacturing: WIP, MRP, and BOM Questions Answered Directly
AI for Oracle E-Business Suite in industrial manufacturing: WIP jobs, BOMs, MRP, inventory and purchasing answered in plain English, private and read-only.
Stuck on Oracle E-Business Suite?
Talk to engineers who work inside Oracle E-Business Suite every week, and who build private AI that answers these questions from your own ERP data.