This is version 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 . It is not the current version, and thus it cannot be edited.

Back to current versionRestore this version

Define UserCalcs#

The other component of workflow requires setting up the UserCalc to incorporate the action event created in IMWA. The integration of workflow required some additional functionality that was not previously available to UserCalcs. This section should be used as a supplemental aid to the User Calculations section and is not to be used in place of it. Please refer to the User Calculations section for a more thorough explanation of UserCalcs and their functionality.

The Define UserCalcs (IMUC) screen is where all of the coding is done for each UserCalc.

wf_4-1.jpg

'Define UserCalcs Usages' and Examples#

UserCalc Header data is stored in the P2K_AM_USER_CALCS table. Header wf_4-2.jpg

User Calc

This field refers to the user-defined name given to the UserCalc.;:Once the UserCalc has been created it can be edited, however, you can not edit it once the UserCalc is in production. You have to Un-Publish it on IMUCA first.

As with Benefit and Attendance UserCalcs, we recommend that a naming convention be used for Workflow UserCalcs. For example, AT is used for the Attendance application, BE for the Benefits application and WF for the Workflow application. This will allow for efficient queries once the UserCalc list becomes large.

Description

The description field may be used to further define the purpose of the UserCalc in more detail than is available in the UserCalc name.

Product

The product indicates which module the UserCalc has been defined for. For example, PR-Payroll, BE-Benefits, AT- Attendance, FC-Forecasting & Costing and WF-Workflow.With respect to Workflow, this field specifies the table code on which the workflow trigger is located. This field should be identical to the name of the "Table" in IMWA. In all cases except workflow, it is the application that controls which fields in which tables will be accessible by the UserCalc. For example, in an Attendance UserCalc, the Leave Accrual Table would be accessible, but not benefits information.

Status

This field describes the status of the UserCalc. The following values are available.

Under Construction	This status value indicates that the UserCalc has not been completed and therefore will not be published.
Being Tested	This status value indicates that the UserCalc has been completed, compiled and is being tested by the user who created it. It will not be published.
To Be Published	This status value indicates that the UserCalc is ready for publishing. You can not set the user calc to this value manually.
In Production	This status value indicates that the UserCalc has already been published and is in use.
Pre-Compiled	This status is now obsolete and will be removed in a future version.

Type

This field defines what values may be passed or used between UserCalcs and what capabilities may be performed. There are three types available:

Calculations	These are used by the main program and may call Qualifiers and Functions in order to perform a customized action or operation. The Payroll, Forecasting & Costing and Workflow modules exclusively use calculations.
Qualifiers	These are used to reduce the number or employees or calculations processed by the UserCalc.
Functions	These are used to perform a calculation or query and return a value to the calculation. The Benefits and Attendance modules exclusively use "Functions".

Return Value

The "Return Value" is used by Functions and Qualifiers to define what type of value will be returned by the Function or Qualifier UserCalc.;:If the UserCalc type is set to Calculation, then no return value is indicated. This field will automatically be grayed out once this type has been selected and the cursor has been tabbed to the next field.;:Since Workflow UserCalcs are always of the type "Calculation", they will not return a value.

Usage

This field is optional but can add additional definition to how/when this UserCalc should function. There are three entries to select from:

Not Specified	Use this or leave it blank for most purposes.
Disbursement Message	Not used for Work Flows - see UserCalc for more details on this usage.
Secondary WF	This option tells the Work Flow engine that this UserCalc is ONLY to be called from another UserCalc and should NOT be fired on its own by the triggering product.

Compile UserCalc SQL

This button allows the user to check the syntax of a UserCalc by generating the PL/SQL code that is used behind the scenes.:;This step does not ensure accuracy of the UserCalc. It merely checks that there are no UserCalc language errors such as incorrect syntax or infinite loops.

Publish UserCalc

This button preps the UserCalc for Publishing and sets the status as "To Be Published".

Line Tab#

Data for the Lines tab is stored in the P2K_AM_USER_CALC_DETAILS table.

Line

The UserCalc is processed according to the order of the line numbers indicated. For example, 10, 20, 30, etc… ;:If a UserCalc line refers to a line number, it must exist in the UserCalc.

Line	CMD	Type 1	Operand 1	OPER	Type 2	Operand 2	Type 3	Operand 3	If GOTO	Else GOTO
10	IF	CF	NewHire	EQ	B	TRUE			200	99999

(Line 200 must also exist in this example)

It is useful to increment line numbers to the next 100 or 1000 at the start of each section of logic. This will make your UserCalc easier to read and maintain by future users.

CMD

Commands are used to perform operations within a UserCalc.

Please refer to the User Calculations manual for a detailed description of the existing commands available.

There are two commands that are available and strictly used for Workflow. These are: ACT and STOP.

ACT	This command is used to initiate a workflow action event. The workflow action event is created in IMWA and referenced in the UserCalc using this command.
STOP	This command is used to raise an exception to the user. This command should only be used to absolutely stop a save from taking place. It throws a database exception that displays the brief text in Operand 1 along with the stack trace of where it came from.

The ACT command is unique in that once it has been selected Type 1, OPER and Type 3 fields are defaulted with the values AC, LOG, and RT respectively, as indicated in the diagram below.

Type 1 (Operand Type 1)

Operands must have a type. For example, DB, AC, V, etc…

Please refer to the User Calculations manual for a detailed description of the existing operand types available.

The following table indicates five special operand types that are available for workflow.

Old Value (OV)	This refers to the Old Value of the item being referenced in the Operand.
New Value (NV)	This refers to the New Value of the item being referenced in the Operand.
Action Code (AC)	This refers to the name of the workflow action code (Type 1 only)
Database Value (DB)	This refers to other database columns that are available based on the Product Tables (IMPT) records.
Recipient Type (RT)	This describes who will be in receipt of this action event as defined in the Maintain Workflow Actions IMWA screen (Type 3 only).

The Type 1 field will always default to the value "AC", if the "ACT" command is used.

Operand 1

Operand 1 is typically used to store the result of any line of a UserCalc, or to compare to a value in Operand2.

Line	CMD	Type 1	Operand 1	OPER	Type 2	Operand 2	Type 3	Operand 3	If GOTO	Else GOTO
200	ACT	AC	NEW EE EMAIL	LOG	$S	CURRENT-DATE	RT	Manager	300

In the case were the CMD is ACT, Operand1 displays the name of the workflow action event that was created in IMWA.

Clicking on the "Operand 1" LOV button will bring up a list from which a selection can be made.

OPER

Operators are the actions that need to be taken in regards to the command being issued and the operands indicated.:;i.e. Add, Divide, convert to a Character, Beginning of Day, etc. Please refer to the User Calculations manual for a detailed description of the existing operators that are available. :;The LOG Operator is a new operator that is available strictly for Workflow and ONLY for the ACT CMD; it is used to log the workflow action event. :;When the "ACT" command is selected this value automatically defaults into this field.

Type 2 (Operand Type 2)

Please refer to the User Calculations manual for a detailed description of the existing operand types that are available. In most cases, when the "ACT" command is selected, this field will need to refer to an operand type that references a constant. Typically the operand type used is $S - System Constant. Operand 2 Operand 2 is used to compare values or assign values. Please refer to the User Calculations manual for a detailed description of the existing operands that are available. With respect to the ACT CMD, this field will hold a date value. Once the value in Type 2 has been entered, click on the Operand 2 LOV button to obtain a list of values to choose from. Type 3 Please refer to the User Calculations manual for a detailed description of the existing operand types that are available. When the "ACT" command is selected, "RT" will always default in. RT refers to 'Recipient Type'. Operand 3 Please refer to the User Calculations manual for a detailed description of the existing operands that are available. This field indicates the recipient who is to receive this workflow action event. Depending on what event recipient is selected in IMWA a list of values is available once the Operand3 button is clicked. If GOTO Please refer to the User Calculations manual for a detailed explanation. The two new workflow commands ACT and STOP require an "If GOTO" value to be indicated. Else GOTO Please refer to the User Calculations manual for a detailed explanation. The two new workflow commands ACT and STOP do NOT take an "Else GOTO" value. Description This is the area where the user will write the messages to be used in the Workflow Action Events (i.e. emails or online messages). In the example above, the UserCalc calls the workflow action "NEW EE EMAIL" at line 200. This action has been set up to notify a manager, via email of a new hire (done in IMWA). The actual content of the email is taken from the 'Description' section. This text is customizable. In this example, the employee's name, hire date and Assignment title are stated in the email sent to the manager. This information is referenced (within double brackets << >>) in the notes section. The field is built with the table alias and column name. Note that it must be a table that is accessible via either the NV/OV or DB Types. The email from the example above that is received by the manager will look similar to: … This e-mail notification has been sent to you from the Human Resources system, to inform you that Jack Smith has joined our organization. Jack is scheduled to begin work on 01-Feb-2007 as a Patient Care Manager.… The following items are examples of what can be referenced in the Description; they MUST be referenced as follows: <<eid.first_name>> - states the employee's first name <<eid.last_name>> - states the employee's last name <<eem.hire_date>> - states the employee's hire date