Using Oracle HRMS you can define payroll events and action parameters to control your payroll processing.
A payroll event is any routine or exceptional occurrence that acts as a precondition for further processing. For example, you can specify that a particular event or group of events should trigger prorated calculations or RetroPay notifications.
An action parameter enables you to set conditions that control your payroll processes.
To enable you to set up payroll events and parameters correctly, you need to understand these key concepts:
See Reports and Processes in Oracle HRMS, Oracle HRMS Window Navigation and Reports Guide
Payroll events identify significant changes which imply a specific processing response.
You define your own payroll events to match your processing requirements. You can also group related events together so that you can process them as a single event.
Database administrators can modify the behavior of Oracle HRMS and control the way in which standard payroll processes run by doing some or all of the following:
Creating dynamic triggers.
Enabling or disabling dynamic triggers.
Grouping triggers into functional areas.
Database triggers are created in the Oracle HRMS database when Oracle HRMS is installed. Oracle HRMS uses two types of database trigger:
Static triggers
Dynamic triggers
It is important that you understand the difference between these two types of trigger.
Static triggers are an integral part of Oracle HRMS and should not normally be disabled. They apply to the entire Oracle HRMS system. The most likely situation in which you would disable a static database trigger is when you are working with your support representative to identify a technical issue with the way in which Oracle HRMS is behaving on your site.
Dynamic triggers are designed to be selectively enabled and disabled by HRMS system administrators. They can be enabled for specific legislations, business groups and payrolls. For example, if you are outsourcing some of your payrolls to a third party, you can enable some third party interface dynamic database triggers as part of your Oracle HRMS implementation.
Your database administrator is responsible for:
Defining dynamic triggers
Specifying whether they should fire on update, insert or delete
Database administrators can use a forms interface to view existing triggers and create new dynamic triggers. A database administrator or HRMS system administrator can enable a dynamic trigger to fire for specific legislations, business groups, and payrolls, or a combination of these.
A database administrator can also group triggers into a functional area so that multiple triggers can be manipulated in a single operation.
If you are interfacing Oracle HRMS to a third party payroll system using the Oracle HRMS Payroll Interface Toolkit, your database administrator can enable or disable triggers for a particular legislation, business group or payroll.
A number of predefined dynamic triggers are delivered with Oracle HRMS. These prevent certain information from being updated or deleted in Oracle HRMS, and prevent data in Oracle HRMS from getting out of step with data in your third party payroll system.
These triggers are grouped into predefined functional areas. Individual triggers can be enabled or disabled for specific legislations, business groups and payrolls using the Dynamic Triggers Functional Area Grouping window.
The following predefined functional areas are supplied with Oracle HRMS:
Generic Payroll Interface Toolkit
ADP Payroll Interface
Ceridian 100 Payroll Interface
Ceridian 500 Payroll Interface
Duplicate Element Reporting Names
These correspond to the payroll interfaces that are supplied as standard with Oracle HRMS. The triggers contained within these payroll interface functional areas are not enabled for legislations, business groups or payrolls on delivery. You must enable them for specific legislations, business groups and/or payrolls to make them active.
If you are not using a third party payroll interface you do not need to enable any of these triggers. Although they will appear as enabled on the Define Dynamic Triggers window they will not fire because they have not been enabled for any legislations, business groups or payrolls.
Database Administrators can use the Action Parameters window to select alternative values for process parameters. For example, you can assign the number of threads to a process and select the combination of levels for logging.
You can also create parameter groups with different values for different business groups:
Create group A which contains the Threads set to 4, and the Logging Value set to N.
Create group B which contains the Threads set to 1, and the Logging Value set to the GMF combination.
You use the user profile option HR:Action Parameter Group Name to specify a parameter group for your responsibility. When you use this responsibility to run a payroll process, Oracle Payroll uses the values you have selected for this parameter group, and it uses default values for any parameter not specified in the group. If you leave the profile option blank, Oracle Payroll uses default values for all the parameters.
Logging parameters are identified by a combination of letters, and you use the logging tab to enable logging categories. For example, if logging is set to RGE this corresponds to the following combination of logging categories:
R - Routing
G - General
E - Element Entry
Use the Dynamic Trigger Definition window to:
Find a trigger that already exists. Existing triggers are referred to as static triggers.
Create a new trigger. Any new triggers that you create are referred to as dynamically generated triggers.
Enable and disable triggers.
Note: If you are using a third party payroll product do not use this window. Use the Dynamic Trigger Functional Area Grouping window to enable business groups and their associated triggers.
To find an existing trigger
Select either Dynamically Generated Triggers or Static Database Triggers.
Select an Application to restrict the range of your search. Note that this does not refer to the application owning the trigger. It refers to the application owning the table to which the trigger is applied.
Enter one of the following:
A table name.
A trigger name.
A table name and a trigger name.
Select a Triggering Action or a combination of triggering actions.
Select the Trigger Type (static database triggers only).
All - displays all existing triggers
Before Each Row
Before Each Event
After Each Row
After Each Event
Instead of Each Row
Instead of Each Event
Statement
Note: These criteria do not apply to triggers created dynamically. Dynamic triggers are always defined to run after each row.
To enable and disable dynamic triggers:
Warning: These instructions apply to dynamic database triggers only. You should never disable a static database trigger.
When you have found the database trigger corresponding to your search criteria, you can see whether the trigger is enabled or disabled. The Enabled flag is checked if the trigger is enabled, and unchecked if the trigger is disabled.
You can change the status of the trigger by checking or unchecking the Enabled flag.
Changes become effective immediately.
To create a dynamic trigger
Select Dynamic Database Triggers.
Enter a description for the trigger. This description will appear as a comment in the generated code.
Select the table on which this trigger operates.
Select the action type for the trigger:
Insert - the trigger may be created after Insert.
Update - the trigger may be created after Update.
Delete - the trigger may be created after Delete.
Dynamic trigger creation does not support:
The combination of insert, update and delete actions available when creating static triggers.
Triggers that are not of the after each row type.
Save the trigger definition.
When you have saved the trigger definition you cannot change the table on which a trigger is run, nor can you change the action that the trigger performs. Instead, you must delete the trigger and then recreate it with the correct details.
Use the Dynamic Trigger Functional Area Grouping window to include all triggers for the functional area into a single group. You can then enable or disable all triggers for the entire area in a single operation rather than enabling each trigger individually.
We deliver functional area groupings as predefined data for those customers who are using Oracle HR with a third party payroll. However, third party payroll users can also define a subset of this grouping and use it in preference to the predefined grouping.
To group dynamic triggers into functional areas:
Enter a description for the new functional area, or query an existing functional area.
Select one of the following from the next block:
Legislation
Business Group
Payroll
Choose the name of the legislation, business group or payroll.
Select the description of each trigger to be assigned to the functional area.
Enable or disable this grouping for this legislation, business group or payroll.
You can specify groupings for legislation only, business group only or payroll only, but you can also specify any combination of these. If you do not select any of these then the triggers operate on all occasions.
To enable selected triggers from a predefined grouping
If you only want to enable some of the triggers delivered in a predefined grouping, then you disable the predefined grouping and create a new grouping containing your selection of triggers. You then enable the new grouping.
When there are changes to employee data this may also imply changes to current or retrospective payroll run results for that employee. For example:
RetroPay - where an employee receives an adjustment in the current pay period, but the adjustment was first incurred in a previous payroll period
Recalculation - where changes are confined to the current pay period
Proration - where adjustments earned on a pro-rata basis in another pay period are applied in the correct proportion to the current pay period
To identify when critical changes such these as have occurred, you can define each change as a table event and specify the action that you wish to take whenever the event is detected.
You can also group a related series of events into an event group so that you can process multiple events as a single group.
See Defining Event Groups, Oracle HRMS Compensation and Benefits Management Guide
For details of primary key information and column names, refer to the Oracle HRMS Technical Reference Manual.
You define table events from the Table Event Updates window:
Defining a table event
Select the Table Name.
Select the Primary Key for your table.
Define the period for which you wish this event to be active. You do this by selecting a start date and then an end date.
Selecting Row Level Events
You enter the details of the change as a row level event.
Select the Event Type to specify the type of database update that will initiate this event. You can select from:
Insert - If you select this event type, you are making a change at row level only, and the Column Name field is not enabled.
Delete - If you select this event type, you are making a change at row level only, and the Column Name field is not enabled.
Update - If you select this event type, you also need to specify a column name because updates are not confined to the row level.
Select the Column Name.
Select the Change Type. You do not need to select a change type for retro-notification and proration. You need only make a selection here if you are defining an event for Continuous Calculation. In this case, the following change types are available:
DATE_EARNED - to trigger recalculation of the payroll run based on the date earned.
DATE_PROCESSED - to trigger recalculation of the payroll run based on the effective date of the run. Use this if you want to recalculate tax information.
PAYMENT - to trigger recalculation of the Prepayments process
COST_CENTRE - to trigger recalculation of the Costing process.
REPORTS - to track all events that generate reports. However, if you have already selected DATE_EARNED as a change type this includes the REPORTS type, and you do not need to specify REPORTS as a separate selection.
Action parameters enable you to set the conditions that control your payroll processing. Use the Action Parameters window to define your parameter values and create parameter groups. You can create a default group to specify global values, or you can define your own group to provide a customized set of processing conditions.
Note: If you create your own group, select it in the user profile option HR:Action Parameter Group Name for a responsibility. Use that responsibility when you want to run processes using the customized parameters.
To maintain parameter groups
Do one of the following:
To define or maintain the default group, check the default group check box. Only do this if you want the parameter values that you select to be the default for all processes and business groups.
To create your own parameter group, enter the name of the group.
Note: You cannot enable a named parameter group as the default group.
To maintain process parameters
From the parameters tab, select the name of the parameter that you want to modify, or enter a parameter name.
For details of the parameters that you can enter, see the Technical Essay: Payroll Action Parameters, Oracle HRMS Implementation Guide.
Enter a value for the parameter name. For example, Trace has a value of either Y or N.
Note: We recommend that Trace is set to N, because setting it to Y imposes an extra processing load on the payroll processes.
If you do not specify any values for the parameters that you select, then the values held at the global level default to the group level. But, if values are specified at the group level, then the group level values take precedence over the global parameter values.
To maintain logging parameters
Select the logging tab.
Check each of the logging categories that you want to enable.
Uncheck any logging categories that you want to disable.
Save your changes.