Understanding Transaction Processing

Transaction processing ensures data integrity for specific programs and tables. If a database error or failure of a server while the system is committing inventory to the database, all table updates that are related to a transaction must be rolled back from the database to maintain data integrity. Transaction processing enables the system to store data in a queue until a commit command is issued, at which time the data is moved to the corresponding table.

The system creates boundaries for each process that is covered by transaction processing. A transaction boundary includes all data elements that constitute a transaction. When a failure occurs, the system generates a work flow message stating that the system resets to its original state before the failure occurring.

The Item Location File table (F41021) reflects on-hand and committed quantities of items by branch/plant, location, and lot/serial number. Maintaining the F41021 table accurately is extremely important. Transaction processing ensures that you do not commit items to a sales order before having a valid, processed order. If an item or order is held up for any reason, the system does not commit the order.

The system places the data in the Transaction Workfile table (F41021WF). This table is identical to F41021, except that it holds the data only temporarily. The update of the F41021 table is performed outside of the transaction boundary to ensure data integrity. The system updates the data in the F41021 table and deletes data from the work file table when the commitment is successful.

You can specify for the work file to be populated by entering 1 in the Special Handling field of user-defined code (UDC) table 00/AT (Auto Transaction Processing Rollback Level).

Transaction processing works with these programs in sales update:

• Sales Order Entry (P4210).

• Shipment Confirmation (P4205).

• Backorder Release (P42117).