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 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 . It is not the current version, and thus it cannot be edited.

Back to current versionRestore this version

USER PROCEDURES/WIZARDS#

A procedure is a type of user definable function that links together two or more system functions into a business procedure. The procedure can take you through a sequence of the various screens and/or reports required to complete a task.

Procedures are invoked through the command line. You must have execution rights before you are able to run them.

A Procedure Wizard provides a container for the procedure and controls the flow between the procedure steps. A side bar lists each of the functions that are part of the procedure, in the order they should be executed.

The flow takes you through each step in order; however, you are able to step outside the normal flow if you wish to correct something or you want to skip steps. Mandatory steps cannot be skipped.

In Admin, you may be in the middle of a procedure and switch to another form, change and save data without affecting the status of the procedure. You can continue the procedure where you left off when you are ready.

When you are finished entering data into a procedure screen, clicking ‘Next’ will commit the changes to the database and will navigate the user to the next sequential step in the procedure. Clicking ‘Finish’ will complete the procedure and will close it out.

Typically, complex processes like enrolling employees into benefit plans, multiple record changes like getting married, or post-hire processes are good candidates for definition as a procedure.

For examples of procedures see the page titled Procedure Examples.

How to Define User Procedures#

There are a couple of screens that require set up in order for a procedure to be fully defined.

Step 1 - Maintain Functions IMFN#

User procedures are first defined on the Maintain Functions (IMFN) screen.

• Click on the Add Record icon
  • Select the product that the procedure will be used for (i.e. HR for any Human Resource related procedures like a New Hire procedure)
  • Enter a function name for the procedure (i.e. NEW_HIRE)
  • Enter a description for the procedure
  • The Usage field MUST be set as ‘User Defined’
  • The Function Type field MUST be set as ‘User Procedure’
  • If the procedure is going to use a header, the subject table must be populated. The subject table is the table that is associated with the procedure. If the steps within the procedure are all tied to the same subject (ie:employments) then that subject table should be defined (ie: P2K_HR_EMPLOYMENTS). If the steps within the procedure are tied to different subjects, the subject table of the first step should be used to populate the procedure's subject table. One method of determining the subject table of a form is by checking IMFD to determine which FIND block is used by the form. Employee related forms are often tied to either FIND_EID or FIND_EEM. FIND_EID would indicate the subject table would be P2K_HR_IDENTITIES and FIND_EEM would indicate the subject table would be P2K_HR_EMPLOYMENTS. Another method would be to review the Entity Relationship Diagrams.
  • All other fields on IMFN are optional
  • The Purpose field can be used to indicate the purpose of the procedure. (i.e. to streamline the new hire process ensuring all appropriate screens/forms have been updated.)
  • If you want a change reason to ‘default’ on a certain form within the procedure, then you must add the change reason to that particular function definition. Currently, there is no way to mark a certain set of change reasons on a form, to be used only when the form is part of a procedure.
• Execution Rights tab - a role other than P2K_MASTER (which is reserved for HLC supplied functions) should be defined here for all new functions, in addition to any other roles that are required for users to access this procedure

Step 2 - Define User Procedures IMPC#

The second step in creating the procedure is going to the Define User Procedures (IMPC) screen where you can link together two or more system functions to complete the task.

The procedure form is divided into two parts: a "header" component that defines general aspects of the procedure and the "procedure steps" component that defines the individual functions that make up the procedure. The information entered for the function created in step 1 will show in the header portion of the screen.

• Procedure Steps tab
  • Seq #- The sequence number in this field dictates the sequence in which the procedure steps are performed.
  • Function Name – This field holds the abbreviated screen name of the function to be executed as part of the procedure.
  • Description– This field displays the full screen name of the function to be executed as part of the procedure. This name will default in when the function is chosen.
  • Mandatory – If this toggle is checked ‘on’, the form must be completed before the user may either go to the next or previous function, or exit the procedure. A mandatory step will appear with a red background in the navigation bar on the left.
  • Display Find - This toggle enables the function's find block to display within the procedure. The user would be allowed to select an employee from the list. This is typically used on the first step in the procedure. If the procedure has a header defined, only the first step should have this toggled On.
• Procedure Step Overflow
  • Create, Retrieve, Update, Delete – These toggles are used to determine what execution rights the user has when running the procedure. The CRUD defined will only restrict what is already set up for the function on IMFN.
  • Command – This field may contain a SQL statement that is to be executed by a procedure step.

The preference is to have two kinds of procedures; all steps have find blocks or all steps use a header. However, this would be difficult to do for some screens. It is more aesthetically pleasing when the header doesn't change and resize between steps, adding consistency to the procedure. In short, users can mix steps, but they shouldn't abuse it; only mix headers and find blocks when necessary.

Users can define a procedure with a mix of steps with and without find blocks however the following should be adhered to:

• If not all of the steps have the Find block toggle enabled, a header must be defined
• The steps without the Find block must use a subject similar/related to the other steps
  • Forms that are based on EID, EEM, EAS, or EASD can be mixed together in one procedure as there is special logic written for these tables to work together in procedures
  • The first step's subject table should be the table that is defined in the Subject Table field in IMPC or IMFN.
• Only the first step in the procedure should have the Find block toggle enabled.

Step 3 - Modify Form Definition IMFD#

Header Setup Part One (Table Usages)

All procedures must be tied to the P2K_AM_EXECUTIONS table in IMFD under Table Usages. The where clause 'NEW MEX ID ONLY' should also be tied to the table.

Full CRUD capability should be granted to the procedure.

Header Setup Part Two (Form Layout)

A dynamic header can be created for the procedure which will show the current subject when having a Find Block is impossible due to the fact that the user is creating new data, for example a New Hire procedure.

If defined, the header will be hidden on the first step of the procedure.

The header is based on the CONTEXT message of the subject table. Context messages are found in IMMS and are defined for a variety of tables. If the subject table was P2K_HR_EMPLOYMENTS, then the message with message_code ‘EEM_CONTEXT’ would provide the template for the header information.

A form group called 'HEADER' should be added to the form layout as a text item. The item 'MEX.DRV_SUBJECT_CONTEXT' should then be tied to the HEADER form group.

Executing the Procedure#

1. In the Command line, enter in the procedure name. (i.e. NEW_HIRE)
2. The first screen will automatically be brought up

• The Header information indicates the procedure and identifies the step by function.
• Navigation
  • Back – allows the user to go to the previous step in the procedure
  • Next – allows the user to go to the next step in the procedure and commits the changes on that page
  • Finish – Ends the Procedure

---

Notes#

Click to create a new notes page