我们现在对事务处理接口的理解，我想，很多人跟我的理解一样，还停留在只知道有两个接口表，或者说，知道一接口一临时表的程度。到底这两个表功能有什么区别？各自是如何运作的？
本文我将带着这些疑问，和大家一起进入讨论。
看看Oracle给他们的解释：<右边框给出比较>
MTL_TRANSACTIONS_INTERFACE MTL_TRANSACTIONS_INTERFACE is the interface point between non– Inventory applications and the Inventory transaction module. Transaction Manager concurrent program polls this table at a user–specified process interval, and submits the Transaction Workers to process them. Processing consists of data derivation, validation, and transfer of records from MTL_TRANSACTIONS_INTERFACE, MTL_TRANSACTION_LOTS_INTERFACE, and MTL_SERIAL_NUMBERS_INTERFACE into their respective TEMP tables, from where they are processed by the transaction processor. MTL_TRANSACTIONS_INTERFACE follows the Inventory standard for interfacing flexfields. Any parameters which are represented by flexfields may be entered in the interface table either as code combination identifiers or as flexfield segment combinations. The Transaction Worker will validate that any given identifiers are valid and enabled. If no identifier is given, then the Transaction Worker will validate and decode the flexfield segment values, and where appropriate, create new flexfield combinations in the database. The Transaction Manager picks up the rows to process based on the LOCK_FLAG, TRANSACTION_MODE, PROCESS_FLAG to manipulate the records in the table. Only records with TRANSACTION_MODE of 3, LOCK_FLAG of ’2’, and PROCESS_FLAG of ’1’ will be picked up by the Transaction Manager and assigned to a Transaction Worker. If a record fails to process completely, then PROCESS_FLAG will be set to ’3’ and ERROR_CODE | 1、Interface是连接非库存系统与库存系统的桥梁 2、Interface的数据经常事务管理并发处理后，将插入对应的临时表，再由事务处理器处理。 3、数据处量条件限制请见左边 |
MTL_MATERIAL_TRANSACTIONS_TEMP MTL_MATERIAL_TRANSACTIONS_TEMP is the gateway for all material transactions. Records are processed from this table into Inventory through the transaction processor. All Inventory transaction forms write directly to this table. Outside applications must write transaction records to MTL_TRANSACTIONS_INTERFACE to be processed through MTL_MATERIAL_TRANSACTIONS_TEMP and the transaction processor by the Transaction Worker concurrent program. Lots and serial numbers for a MTL_MATERIAL_TRANSACTIONS_TEMP(MMTT) record are stored in the tables MTL_TRANSACTION_LOTS_TEMP(MTLT) and MTL_SERIAL_NUMBERS_TEMP(MSNT). If the item is under lot control, then MMTT.TRANSACTION_TEMP_ID joins to MTLT.TRANSACTION_TEMP_ID. If the item is also under serial number control, then MTLT.SERIAL_TRANSACTION_TEMP_ID joins to MSNT.TRANSACTION_TEMP_ID. If the item is only under serial number control, then MMTT.TRANSACTION_TEMP_ID joins to MSNT.TRANSACTION_TEMP_ID. Transfer transactions are stored in this table as a single record. The transaction processor creates two transactions from the single record. | 看看左边的红色标识的话：所有事务处理的必经的步骤。 所有插入事务处理正式表的数据，都必须经过TEMP表后，（自动）运行Transaction Processor后插入正式表。 |
从Oracle官方给出的解释，我们可以基本上得到如下一个逻辑图：
如果照上图描述，那么，我们能否通过一些实例来来说明或者说证明我们的想法呢？
一、先了解它
首先，我们明确一下这两个表：
临时表： MTL_MATERIAL_TRANSACTIONS_TEMP （以下简称TEMP表）
接口表： MTL_TRANSACTIONS_INTERFACE （以下简称INTERFACE表）
二、运用它
OK，我们已经知道这两个TABLE的区别及流程，那么，我们怎么运用它呢？
接下来我们针对这两个表分别具体来描述它们的运用。
1） Interface
·直接插入数据入接口表。这里面有几个需要注意的地方：
字段 | 描述 |
Source_code, Source_header_id, Source_line_id | 来源行，供追溯使用，可以随便填 |
transaction_source_name | 事务处理来源名称，可以随便指定。 |
PROCESS_FLAG | transaction is ready to be processed by the Transaction Manager or Worker (’1’ for ready, ’2’ for not ready); if the transaction fails for some reason, the Transaction Worker sets the value of PROCESS_FLAG to ’3’ |
TRANSACTION_MODE | the transaction is to be processed in immediate concurrent processing mode (2) or background processing mode(3) |
LOCK_FLAG | Flag indicating whether the transaction is locked by the Transaction Manager or Workers (’1’ for locked, ’2’ or NULL for not locked); this prevents two different Workers from processing the same transaction; You should always specify ’2’ |
TRANSACTION_TYPE_ID | Transaction type identifier，这里要注意一下的是，如果你是做做杂项处理，那么，如果事务处理数据小于0，那么应该指定为32（Miscellaneous issue），反之则为42（Miscellaneous receipt） |
Organization_id Inventory_item_id subinventory_code locator_id revision transfer_organization transfer_subinventory | 指定传送仓库及物品有关的信息，如果这些值有，请指定。 |
transaction_quantity transaction_uom transaction_cost transaction_date | 指定事务处理的数量、单位、成本等信息，成本的话，如果指定为NULL，系统会以事务处理器运行时的成本出（入）库。请慎重指定。 |
distribution_account_id | 如果是杂项出入库，请指定库存成本帐户，如果是帐户别名出入库，则需指定。 |
WHO 字段 | 需要指定 |
插入数据完成后，那么，按我们的流程，需要进行Transaction Processor，进行后续数据处理
简称：INCTCM
参数：无
提交语句Sample：
l_request_id := fnd_request.submit_request('INV',
'INCTCM',
'',
to_char(sysdate,'YYYY/MM/DD HH24:MI:SS'),
false,
chr(0))
1） TEMP
在INV的内部处理中，系统都会直接将Process插入至TEMP表，再通过自动请求Transaction Processor，将数据导入至正式表中。
直接插数据入TEMP表一般存在于INV模块，不过，ORACLE官方并不太支持这种方式，“Load the transaction records into MTL_TRANSACTIONS_INTERFACE table .Loading the transaction records directly into MTL_MATERIAL_TRANSACTIONS_TEMP table is not supported.”
那么，能不能这么做呢？
其实，Oracle这句话是正确的，人家是说“你可以直接插MTI，但你不能直接插数据入MMTT”。
因为这两者有区别的：MMTT表是联机处理用的，也就是说是form通过API往里面写数据并可以用API直接处理的，MTI表是接口表，里面的数据是通过Conc Req转到MMTT中并通过txn worker来处理的。
OK，理解这一条后，我们很容易就想到这个问题，MMTT的API是什么？API的工作机制是什么样的？
首先来说MMTT的API，我们随机打开了一个RORM－杂项事务处理FORM，它的主BLOCK就是基于MMTT的，在Trigger Pre-Insert中，写了很多前期处理的操作：如取Temp transaction id，如果系统启用了批次/序列，需要在LOT的BLOCK中先写入相关的信息。插表的操作即通过标准API APP_STANDARD.KEY_COMMIT来完成，将数据保存至MMTT中。
所以，我觉得（没实验过）我们完全可以模仿ORACLE标准FORM来往MMTT中插入数据，但是，这前期涉及的针对批次、序列的处理可能会相当烦锁，如果没有这些麻烦，往MMTT中插数据可能与MTI中插数据一样简单。
在这里我先将TEMP表几个关键字段列出来：
字段 | 描述 |
TRANSACTION_HEADER_ID TRANSACTION_TEMP_ID | Header_id为主键，即MMTT的KEY，TEMP ID可有可无，即未来的Transaction ID |
TRANSACTION_SOURCE_TYPE_ID | 固定值，一般有如下值 1 Purchase order 2 Sales order 3 Account number 4 Job or schedule 5 Job or schedule 6 Account alias |
SOURCE_CODE SOURCE_LINE_ID | 来源码和来源行ID |
TRANSACTION_MODE | the transaction is to be processed in immediate concurrent processing mode (2) or background processing mode(3) |
LOCK_FLAG | Flag indicating whether the transaction is locked by the Transaction Manager or Workers (’1’ for locked, ’2’ or NULL for not locked); this prevents two different Workers from processing the same transaction; You should always specify ’2’ |
TRANSACTION_TYPE_ID | Transaction type identifier，这里要注意一下的是，如果你是做做杂项处理，那么，如果事务处理数据小于0，那么应该指定为32（Miscellaneous issue），反之则为42（Miscellaneous receipt） |
Organization_id Inventory_item_id subinventory_code locator_id revision transfer_organization transfer_subinventory | 指定传送仓库及物品有关的信息，如果这些值有，请指定。 |
transaction_quantity transaction_uom transaction_cost transaction_date | 指定事务处理的数量、单位、成本等信息，成本的话，如果指定为NULL，系统会以事务处理器运行时的成本出（入）库。请慎重指定。 |
distribution_account_id | 如果是杂项出入库，请指定库存成本帐户，如果是帐户别名出入库，则需指定。 |
WHO 字段 | 需要指定 |
三、实践它
我们已经大概知道两者的描述、区别、运用了。那么，我们接下来做几个SAMPLE实验一下
先验证Interface，再验证Temp
-- 这部份脚本我已经验证通过了，但脚本篇幅太长，不在这里写了。有需要的请根据我提供的联系方式联系我。