# Fix Oracle EBS MTL_TRANSACTIONS_INTERFACE Rows Stuck With PROCESS_FLAG = 3 > Source: https://netray.co/erp-help/ebs-mtl-transactions-interface-error-process-flag-3-fix > Publisher: Netray (netray.co), AI and integration engineering for ERP and manufacturing systems. > Section: ERP Help ## 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. ## Kind error ## System oracle-ebs ## Erp Oracle E-Business Suite ## Module Inventory / Transaction Open Interface ## Query EBS MTL_TRANSACTIONS_INTERFACE PROCESS_FLAG 3 error ERROR_EXPLANATION ## Alternate Queries - 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 ## 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 ## Steps ### How to find and clear the error **Items:** Query 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. Open 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. Read 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. Fix 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. In the Pending Transactions form, tick Resubmit on the corrected rows and save. Resubmit sets PROCESS_FLAG back to 1 and clears the error text. For 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. Run 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. Confirm the result in MTL_MATERIAL_TRANSACTIONS using the SOURCE_CODE or TRANSACTION_SOURCE_ID you loaded. ## Sections ### What PROCESS_FLAG values mean **Body:** 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. **Code:** - 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 **Body:** 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 **Body:** 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. **Code:** 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 **Body:** 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. ## 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. ## Ai Angle 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. ## Faq ### Where do I see ERROR_EXPLANATION in the EBS UI? **Answer:** 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? **Answer:** 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? **Answer:** 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? **Answer:** 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. ## Search terms MTL_TRANSACTIONS_INTERFACE error, EBS process_flag 3, inventory open interface error, pending transactions form EBS, ERROR_EXPLANATION MTL, inventory transaction manager EBS, resubmit inventory transaction, Oracle inventory interface stuck, TRANSACTION_MODE EBS, R12 inventory transaction error --- Talk to an engineer: https://netray.co/contact?intent=erp_ai | Machine catalog: https://netray.co/agent/catalog.json