Understanding Transaction Master Business Functions

Transaction master business functions provide a common set of functions that contain all of the necessary default values and editing for a transaction table in which records depend on each other. Transaction master business functions contain logic that ensures the integrity of the transaction being inserted, updated, or deleted from the database. Event flow breaks up logic. You use cache APIs to store records that are being processed. You should consider using a transaction master business function in these situations:

• You accept transaction file records from a non-JD Edwards EnterpriseOne source.

• Multiple applications update the same transaction file.

These transaction tables are examples of candidates for transaction master business functions:

• The F0911 table accepts updates across application suites, as well as external sources.

• The F06116 table accepts updates from batch, interactive, and external sources.

A master business function (MBF) can be called from several different applications. Rather than duplicating the processing options for the MBF on each application, you typically create a separate processing option template for these processing options. You can use interactive versions to set up different versions of the MBF processing options. Various calling programs then pass the version name to the version parameter of BeginDoc.

From within BeginDoc, the business function AllocatePOVersionData can be called to retrieve the processing options by version name. The processing options needed by other modules can be written to the header cache and accessed later, rather than calling AllocatePOVersionData multiple times.

The cache structure stores all lines of the transaction. Transaction lines are written to the cache after they have been edited. The EndDoc module then reads the cache to update the database.

This table describes the components of the header section:

Field Description	Field	Key	Type	Size
Job Number	JOBS	X	Num	N/A
Document Action	ACTN	N/A	Char	1
Processing Options	N/A	N/A	N/A	N/A
Currency Flag	CYCR	N/A	Char	1
Business View Fields	N/A	N/A	N/A	N/A
Work Fields	N/A	N/A	N/A	N/A

This table explains the fields:

Field Description	Purpose
Job Number	A unique system-assigned number assigned when the BeginDoc module starts the job. This distinguishes transactions in the cache for each job on the workstation that is using the cache. Use next number 00/4 for the job number. If you are using a unique cache name (Dxxxxxxxxx[job number]), you do not necessarily need the job number field stored in the cache for a key because you would only be working with one transaction per cache. You can, therefore, use any field as the key to the cache.
Document Action	The action for the document. Values are: A or 1 = Add C or 2 = Change D = Delete
Processing Options	Processing option values were read in using AllocatePOVersionData, and are needed in other modules of the MBF.
Currency Flag	A system value that indicates whether currency is on and what method of currency conversion is used (N, Y, or Z).
Business View Fields	The fields required for processing the transaction and writing it to the database. All fields in the record format that are not saved in the header cache will be initialized when the record is added to the database using the APIs.
Work Fields	Fields that are not part of the business view (BV), but are needed for editing and updating the transaction. For example, Last Line Number is the last line number written to the detail cache. It will be stored at the header level, and retrieved and incremented by the MBF. The incremented line number will be passed to the header cache and stored for the next transaction.

This table describes the components of the detail section:

Field Description	Field	Key	Type	Size
Job Number	JOBS	X	Char	8
Line Number	(Application-specific)	X	Num	N/A
Line Action	ACTN	N/A	Char	1
Business View Fields	N/A	N/A	N/A	N/A
Work Fields	N/A	N/A	N/A	N/A

This table explains the fields:

Field Description	Purpose
Job Number	A unique number assigned when the BeginDoc module starts the job. This distinguishes transactions in the cache for each job on the client that is using the cache. If you are using a unique cache name (Dxxxxxxxxx[job number]), you do not necessarily need to store the job number field in the cache for a key because you work with only one transaction per cache. You can, therefore, use line number only as the key to the cache.
Line Number	The number used to uniquely identify lines in the detail cache. This line number can also eventually be assigned to the transaction when it is written to the database. The transaction lines are written to the detail cache only if they are error-free.
Line Action	The action for the transaction line. Values are: A or 1 = Add C or 2 = Change D = Delete
Business View Fields	Fields required for processing the transaction that will be written to the database. All fields in the record format that are not saved in the detail cache will be initialized when the record is added to database using the APIs.
Work Fields	Fields that are not part of the business view, but are needed for editing and updating the transaction line.