Topics of Interest

General Overview:

Procedures in Architecture - Global, Subledgers, and Transactions
Procedure Palette - Global, Subledgers, Transactions, User Functions
Report Procedure
Sample Procedures - A mini-tutorial
System State
Working with Draggable objects (with links to specific objects)

Features

Trigger options
Search Inspector view including, Run-time button and Comparison Value field (as part of Search explanation)
Sort Inspector view
Expert Inspector view
Completing the Procedure
Invalidated Procedure
Functions in other Functions and Procedures
Grids
Transfer Templates and/or Procedures between databases

Preferences:

Date Formats
Start-up Mode
Time Format
Year 2000

Overview
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 Transaction)
• 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, and Transactions
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"; or
• use it to calculate new data for insertion into the record during data entry; or
• validate the accuracy, relationship, or selection of predetermined data.

_{Trigger Options}
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:

Template-based:

• 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 defined) because 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 condition.
• 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 are not met.
• 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, if user-specified conditions are not met.
• Check writing (Accounting Data Entry only)
  Used in check-writing. For a detailed example see Make TX object.

Field-based:

• 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}

Check Syntax
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

(the 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 found)

• 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 syntax.

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 of options:
  • 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.

_{Invalidated 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,
• Save.

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 box.
  • 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 the Return 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 button.

Go to:
Index
Table of Contents