Topics of Interest
Procedures in Architecture - Global, Subledgers, and Transactions
Procedure Palette - Global, Subledgers, Transactions, User Functions
Sample Procedures - A mini-tutorial
Working with Draggable objects (with links to specific objects)
Search Inspector view including, Run-time button
and Comparison Value field (as part of Search explanation)
Expert Inspector view
Completing the Procedure
Functions in other Functions and Procedures
Transfer Templates and/or Procedures between databases
Procedures are executable flow-charts that are used to:
- add functionality and data entry efficiencies to data input Templates (Global,
Subledgers, and Transactions);
- create User Functions;
- retrieve data and compile Reports;
- carry out Processes.
In all cases, the creation of any Procedure starts with an UNTITLED Palette,
UNTITLED Workspace, and an UNTITLED Inspector. These windows
are displayed* by making selections from the Application Launchpad:
- Architecture > X Procedures (where X is either Global, Subledgers, or
- Architecture > User Functions
- Report Builder > Report Procedures
- Process Builder > Process Procedures
* A Template-based Procedure can display the Open Procedure panel or
bring up the last opened
Procedure, instead of the selection
panel, depending upon the Preferences setting
- select the Template name to which you want to attach one or more Procedures
(this will display the available trigger options in the Procedures column);
- select the trigger option (this will display the three windows).
Procedures in Architecture - Global, Subledgers,
The use of Procedures with Templates (Transaction, Subledger, and Global - Primary
or Cloned) is optional. Procedures allow you to carry out many tasks, such as:
- interrogate the database, download information and insert it "as is";
- use it to calculate new data for insertion into the record during data
- validate the accuracy, relationship, or selection of predetermined data.
Each Template can have a number of Procedures which are executed (triggered)
during Data Entry, based upon the following trigger criteria. Since most triggers
are available with Transactions/Subledgers/Global Procedures, we will use the
word Record to mean either a Subledger/Global record or a Transaction
line and/or document:
- New record
Executed when a New Record is started.
- Loading record
Executed when a Record is loaded from the Input window's record browser -
either to review, change, or clone.
- Entering record (Accounting Data Entry only)
Executed when a completed Record is being stored (in memory and displayed
in the Line Browser) by clicking on the New -Line button (mouse
click or Return key).
- Posting record (Accounting Data Entry only)
Executed for each Record when a saved document is being posted (either
by selecting the appropriate menu item or automatically - Source Document
of a zero balance condition.
- Saving record
Executed when a Record/Document is being saved. This trigger option allows
saving to be aborted, if user-specified conditions are not met.
- In the case of Global and Subledger records
(being a single database table row), the systems differentiates the record
status and invokes the Saving record Procedure for new records
only. For previously saved documents see Updating records.
- In the case of Accounting Data Entry,
the saving routine can be triggered manually by clicking the New-Doc button
or automatically (Source Document defined) because of a zero balance
- Updating record (Global and Subledgers only)
Executed when a previously saved Record is being updated and saved again.
This trigger option allows saving to be aborted, if user-specified conditions
- Deleting record
Executed for each Record when a saved record, document and/or transaction
line is being deleted. This trigger option allows deletion to be aborted,
conditions are not met.
- Check writing (Accounting Data Entry only)
Used in check-writing. For a detailed example see Make
- database field
Executed after the field, for which the Procedure is designated, is "disturbed."
- non-database field
Executed when the non-database field is "disturbed" such as:
- turning a switch on or off;
- pushing a button; or
- making a selection from a pop-up list
Completing The Procedure
Once all executable Objects are completed and connected, check the accuracy
of your work (the syntax
check validates not only the connectivity of the Objects (as with the fields
of Templates) but also the
accuracy of all instructions):
- press the Check syntax/Edit Again toggle button
image on the button will change and the appropriate syntax validation message
will appear in the Workspace window e.g. Missing operand over
the object that contains the error, or No errors, if none are
- if an error is found, press the Check syntax/Edit Again toggle button to
restore the Procedure into an editable state and reset the button image;
- repeat the Check syntax routine until No errors are indicated;
- shortly after flashing the No errors message, the Procedure Workspace
will be restored into an editable state and reset the button's icon to Check
The Procedure can be saved (select Save menu item) at anytime even when
the Procedure is incomplete (i.e. an error messages are generated). This Save
anyway option was introduced in order to allow Configurators to develop Procedures
in stages, if necessary.
Testing the Procedure
Once a Procedure is completed and syntactically correct, it can be tested before
putting it into production.
- press the Test menu item or button .
Depending upon the type of Procedure, this may display the actual (but with
Save disabled) Data Entry window based upon its Template design, or step
through the Report or Process flowchart;
- if you are testing a Transaction Template/Procedure, select New Source and
make a selection;
- if the selected Procedure is triggered by New record, press the New
Line button in the input window; or, if the selected Procedure's
trigger is Field-based, enter data into the trigger field; etc.;
- this causes the Test/trace window to be displayed. This window has a number
- Cancel button (terminates test mode),
- Run button (runs through the entire Procedure without stopping),
- Break button (will interrupt the Test in Run mode - select
the desired "stop" object, then press on the Break button,
repeat if necessary, then press on the Run button),
- Step button (steps through each phase of the Procedure, one
executable object at a time)
- as the steps are executed, the Object currently under execution
in the Procedure Workspace is framed with a black border,
- halts at the end of each step and awaits the next press on the Step button
before executing the next object);
- Trace switch (when set, displays the intermediate results as
the test progresses through the Procedure)
- on exiting the test, the Data Entry window is re-displayed with the data
processed as specified by the Procedure.
Save the Procedure
Simply select the Save menu item - may be done before or after testing
of the Procedure (upon receiving the
Save command, STEP FORWARD transparently performs the syntax check. If
errors exist, they will be identified
and an Alert Panel will offer the option to Save anyway.
A syntactically correct saved Procedure is automatically placed "into
production mode" i.e. ready to be
executed in the Data Entry mode. However, just because the syntax is correct
does not guarantee that the
Procedure performs as intended. Therefore, always test your Procedures.
Procedures can be invalidated as a result of making critical modifications to
the Host Template or to Print Templates.
Having invalidated Procedures does not necessarily mean that they are incapacitated
as to their original purpose. Rather, the purpose of this feature is to force
the Developer making changes to a Template to review all existing Procedures.
Invalidated Procedures are indicated in the Open Procedure window by a "broken
checkmark" next to the Template name and the specific Procedure trigger(s)
in addition to having the name/trigger text shown in bold. See the example
in the Overview.
When an invalidated Procedure is loaded for editing:
- review Procedure as to the viability of its original intent;
- make modifications, if required; and,
In the event that a Template with invalidated Procedures is being tested or
used in live mode, an Alert Panel is displayed with a message that names the
Trigger/Procedure(s) and the Template:
Functions in other Functions and Procedures
A completed Function can be imbedded in another Function or Procedure.
In order to do so,
- drag the Function object from the Palette into the Workspace;
- select the appropriate Function from
the Functions view of the Palette:
- A single click will display the Description, if any in the Palette
- a double-click will load the Function name into the Function
- You can also drag-and-drop the Function's name from the Palette into
the Function box
in the Workspace.
This causes the Function object to expand and display all required Parameters and
value. Each of the Parameter fields comes equipped with a Run-time button
allowing the required values to be hard-coded or loaded at run-time (soft-coded).
You may want to review the usage of the Run-time
Table of Contents