Capturing and processing the accounting data in SF follows the same model as the global data. A transaction template is laid out, then SF creates a database table and input form, with optional procedures to govern the process of entering/editing data.

The difference between them is in degree of freedom that is afforded to the process of creation of templates. Whereas global templates are all built individually, and one does not have to be a subset/superset of another, transaction templates are based on one foundational template ("Common") that captures the essential accounting data. The Common template establishes the minimum set of data that must be entered for the transaction to be valid. Other kinds of data that may have to be captured for specific accounts are entered through so called "Extra" templates. All Extra templates are based on the same Common template, and merely add fields needed to capture these "extra" pieces of information.

Extra TX template

Church_Demo database has one such template: OOZ_Pay

Once the template has been populated with additional fields, one has to set conditions that must exist during data entry in order for a given Extra Template to populate the Transaction Data Entry window. These conditions are set in the Inspector:

In the OOZ_Pay Template these trigger conditions are the Prefix #1, and the GL Numbers 311 or 675, regardless of the Source document or the Sign (+ or -) of the Amount.

Transaction Procedures 

Transaction Data Entry Templates can be assigned Template-based, Field-based, or Trigger-based Procedures. A number of these are utilized in the two Transaction Procedures of the “Church_Demo” database.

Two fields, the “Country Code” and “Trip ID”, have Procedures that call upon data maintained in two Global tables (OOZ_CC and OOZ_Trip respectively) to populate the applicable fields. These Procedures also utilize the “Stop and show” option which will cause the entire OOZ_CC or OOZ_Trip data to be displayed for selection, if the entered data does not find an exact match. This technique ensures that the data in these fields is accurate (except for clerical errors) and consistent in spelling.


In a Procedure attached to the “Reference #” field we check for the Source name:

If the Source is “JE” and upon entering any character(s) into the Reference # field, the Procedure will determine the last Journal Entry number (e.g. JE1402), increment it by 1 and insert JE1403 as the new Reference #.

If the Source is “Doc” or “PINV” and upon entering any character(s) into the Reference # field, the Procedure will determine the last Voucher number (e.g. VO2), increment it by 1 and insert VO3 as the new Reference #.

Process Builder – Process Procedures

This application is a powerful tool that can combine, into a single process:

User-Functions; other Process Procedures; Transaction generation (effectively inserting new data into TXDetail and OpenItem tables); Report Printing; Export data; and editing of Global and Subledger tables including Retrieval, Insert, Update, and Delete.

The “Church_Demo” database utilizes a number of Processes. One of these is the “Process 1IMM Receipt”.

The Parameter input requests the “Receipt Year” (e.g. 2015) and the “Cash Log” (e.g. 3). The Process checks to see whether the value “Receipt Number” field of the specified record is zero and, if it is, it will Update the applicable CashTrac record with the next “Receipt Number” and the “Receipt Date” (the current date). If the “Receipt Number” field is not zero, this Process will display an Alert Panel entitled “Please Confirm” and offer two options.

Click to enlarge