o INCTCM module: Process transactions interface
This program processes material transactions following changes in any of the transactions form. For optimal processing speed the system manager responsibility should be used to tune the Inventory Manager. The initial setup for this is defaulted with a single target process setup.
The number of target processes will limit the number of workers available to the transaction manager, workers can be run in parallel, therefore to significantly reduce the time taken to process your inventory transactions, then increase
the number of target processes to the maximum allowable within your system
limits. For this request the assistance of your dba, system memory and central processor performance will be the limiting factors for this target parameter. While running, the program: INCTCM, constantly checks for rows in the interface and interface temporary tables. First checking the interfaces
temporary tables and acting upon these records and then processing the
records in the interface tables, marking these records with header identifiers and subsequently moving them to the corresponding temporary tables, this process is repeated each time the workers are started.
For example:INCTCM polls and transacts upon records held in mtl_transactions_interface, mtl_transaction_lots_interface,and mtl_serial_numbers_interface moving theseto their respective temp tables, eg: mtl_material_transactions_temp, these arethen processed by the transaction processor, such rows have their lock_flag set to the value Y.
Different workers are submitted by the transaction processor to process Order Entry, Work in Progress and Inventory transactions,these are processed in
groups, depending on the value of the flag validation_required, values 1 or null = detailed validation 2=not detailed processed rows are assigned a transaction_header_id using the sequence mtl_material_transactions_s. o Records that are ready for selection will have:transaction_mode=3, process_flag=1 or Y for mtl_material_transactions_temp table lock_flag=2 or null(or N in mtl_material_transactions_temp) process_flaghas a range of values : 1=ready, 2=not ready, 3=failed lock_flag has a
range of values: 1=locked 2=not locked, NULL=not locked transaction_mode
has a range of values: 2=immediate mode 3=backgound mode The rows in mtl_transactions_interface are processed in 5 phases.1. Derives dependent columns, eg:acct_period_id, primary_quantity etc..2. Detailed validation performed on the records3. On hand qty check for negative qty's etc.,4. Reservations relieved if demand was created in order entry5. Rows are moved to mtl_material_transactions_temp where the transaction processor is called to process these rows and update the inventory levels etc. o Resolving Errors:If an error occurs with the transaction processor, the entire group of records will be marked with the error code; the actual failing row will contain the error explanation.
You can access failing rows using Inventory's View Pending Interface Activity form, additionally you can use this form to resubmit the records by setting the 'resubmit' flag to yes, this is only appropriate if the error that caused the
failure is unrelated to the interfaces transaction data, eg: database space problem. Errors can be determined by viewing columns: error_code and error_explanationon table mtl_transactions_interface, once the cause has been corrected, use sqlplus to update the process_fag = 1 and the lock_flag = 2 or null
During phases 1-3 above, rows are marked with an error code and explanation, for phase 4 all records with this header_id will be marked as errored regardless
For phase 5 all rows will be marked with the same error except for the single
bad row that caused the failure.
