HRMS DEVELOPMENT WHITE

PAPER
Continuous Calculation


Prepared by
Authors: N.Bristow

Version: 1.0

Copyright (C) 2000 Oracle Corporation
All Rights Reserved



Product Design and Architecture




Contributors

Name Position
Neil Bristow
Martin Reid





Change Record

Date Author Version Change Reference
28-Feb-2000 Neil Bristow 0.1 Initial version
23-Mar-2000 Neil Bristow 0.2 Changes after review




Reviewers

Name Position Initial and Date











Continuous Calculation

2

Contents
Contents 3
Synopsis 4
Overview 5
Dynamic Triggers and Functional Areas 6
Triggers 6
Functional Areas 8
Incident Register 10
Creating Triggers for the Incident Register. 11
Starting the Incident Register 13
Viewing Changed Processes 15
Running Continuous Calculation 16
Limitations 18
Summary 19

Continuous Calculation

3

Synopsis

The Oracle Payroll system currently works over a processing period, during which the Payroll Run, Pre-
Payments, Payments (CheckWriter, Magnetic Tape, Cash, External/Manual Payments), Costing and
Transfer to GL are processed. Each process has to be run in a specific point in the processing cycle.

The processing time is typically at the end of the Payroll Period, for example the Payroll period could be a
Calendar month, during the month the Payroll Department may allow employee changes (salary increase,
pension changes etc.) up to the 22nd of the month, from the 23rd to the end of the month all
the Payroll processes must be performed and validated.

With a growing number of assignments it is clear that clients are finding it increasingly difficult in
performing and validating all the payroll processes in the required processing time. Continuous Calculation
is a mechanism that spreads the processing across the whole payment period. It involves performing a large
amount of the processing at the beginning of the period and subsequently only performing processing for
changes made.
Continuous Calculation

4

Overview

Continuous Calculation is primarily aimed at large clients that have relatively static payrolls (salaried
employees). The reason for this is that these types of employees are rarely changed, thus their payroll
calculation could be performed early in the payroll period. Thus allowing the payroll staff a large period of
time to validate the results.

In addition to this, the Continuous Calculation mechanism allows the CPU load to be distributed more
evenly over the payroll period.

Oracle's understanding of this is that the Payroll Run, Pre-Payments and Costing can have Continuous
Calculation applied to them, however the Payment and Transfer to GL cannot have Continuous Calculation
applied. The reason for this is that these types of operation group the actions together, thus either all the
assignments are processed to completion or non are completed.

By performing the Run, Pre-Payment and Costing at the start of the Payroll Period, the system needs to
automatically detect any changes to the assignments that are in those processes, that will effect the results.
As a result of the detection the system will reprocess the affected processes in a batch process that could be
set up to process on a periodic basis (every night, every other night, once a week etc.). This doesn't mean
that daily taxation is performed, taxation is based on the employees normal payroll period and not the
number of hours worked for hourly rate employees.

Reprocessing of these processes will not take place if the assignment has been included in a subsequent
Payments or the Transfer to GL process, this signals the end of processing for the assignment.

Real Date Person Process Date Supplied to
Process
01-JUN-1999 Fred Bloggs Payroll Run 30-JUN-1999
01-JUN-1999 Fred Bloggs Prepayment 30-JUN-1999
05-JUN-1999 Fred Bloggs Salary Increase From 01-JUN-1999
06-JUN-1999
(overnight)
Fred Bloggs Mark for Retries From 01-JUN-1999
06-JUN-1999
(overnight)
Fred Bloggs Reprocess Payroll
Runs
From 01-JUN-1999
06-JUN-1999
(overnight)
Fred Bloggs Reprocess
Prepayments
From 01-JUN-1999
12-JUN-1999 Fred Bloggs Payment Method
change
From 01-JUN-1999
13-JUN-1999
(overnight)
Fred Bloggs Mark for Retries From 01-JUN-1999
13-JUN-1999
(overnight)
Fred Bloggs Reprocess
Prepayments
From 01-JUN-1999
25-JUN-1999 Fred Bloggs ChequeWriter 30-JUN-1999



This table shows the simple processing order in which things may be performed, but what actually triggers
the continuous calculation for a person is a change made to their data. The change can fall into 3 broad
categories, a change that affects Costing, a change that affects Prepayments and finally a change that affects
all three continuous Calculation processes (Payroll Run, Prepayment and Costing).

In this example, both the Payroll Run and Prepayment processes are processed at the start of the payroll
period (Calendar month), during this period a Salary increase is made to Fred Bloggs. This triggers a
recalculation for Fred. Later in the month a Payment change is made and as a result the Prepayment
processes is rerun for Fred.

Finally the ChequeWriter process is run, this creates the cheque for Fred and signals the end of the
automatic recalculations.

Continuous Calculation

5

Dynamic Triggers and Functional Areas

Dynamic Triggers and Functional Areas is a mechanism that allows the user to add extra validation to data
being placed into tables, this validation will happen at RDBMS row level. The validation could then be
combined into specific modules that could be enabled by legislation and business group.

Triggers
Dynamic Triggers are basically a method that has been developed by HRMS that allows us to define
triggers on the database, that can have global and legislative sections to the triggers that can be enabled
dependent on the requirements. These triggers should always be just for validation purposes and should
never alter data.

The Dynamic Triggers can be set up via a form, the form allows the user to view static triggers that already
exist on the database and allows the user to set up Dynamic Triggers.
Static Triggers
The Dynamic Trigger form acts in two modes static and dynamic. Just for completeness we will briefly
look at the static option first, the static option allows the user view triggers that exist on the database for a
specified table. No changes are allowed to be made to these triggers since many of these triggers are
standard triggers delivered by the HRMS application. The follow query will look for insert triggers on
PAY_DEFINED_BALANCES.



When the user clicks on the find button, the form will show the details of all the triggers that fulfil this
criteria.

Continuous Calculation

6


Dynamic Triggers
Dynamic Triggers unlike static triggers are not triggers on the database until they are generated. Basically
Dynamic Triggers are code fragments held in HRMS tables that can be built into triggers on the database.
Those code fragments may be relevant globally, legislatively or by business group, thus the code can target
itself.

The dynamic option in the form starts in a similar manner to the static option in that the user specifies what
type of trigger to query or created.



By Clinking on either the Find or New button, the user is navigated into the Dynamic Trigger screen. The
screen displays the table that the trigger applies to with the trigger name and details about the trigger. There
are three tab sections on the form. The Declaration section simply defines variables that are going to be
used in the trigger, with the initialisation section setting the starting values. Initialisation can take the forms
of simple value assignment, select statements or function calls.
Continuous Calculation

7


The final section is the component section, this section contains package procedures that are to be called as
part of the triggers. These procedures can be global, legislative or per business group, that is global
procedures are always run, legislative procedures are run if the procedure is associated with the legislation
of the business group and business group procedures are run if the user has log on to that particular
business group. Parameters can be passed in and out of these procedures by clicking on the Parameters
button at the bottom of the form. These trigger components are only included in the trigger if they are
enabled, the component Enabled check box must be checked to include the component in the trigger.

By clicking on the View Source button the user can view the code that will be created for this trigger.
When the user is happy with this, then the Generated check box can be clicked, this will physically create
a trigger on the database. The name of the database trigger will be generated by the system. Any errors
encountered when generating the trigger will be displayed, and must be resolved before the trigger can be
used. The database trigger will be created disabled, to enable the trigger for use the user must click on the
Enabled check box.



Functional Areas
A Functional Area is a group of Dynamic Triggers that have been grouped together. Functional Areas
allow Functionality to be turned on by either legislation or business group. Thus for a Functional Area
functionality can be turned on for Business Group A but not Business Group B.

The following form shows the Functional Areas form, it details two Functional Areas with the highlighted
Incident Register showing the Dynamic Triggers that are associated with that Functional Area.

Continuous Calculation

8



The following form is again the Functional Areas form, but this time the Business Group tab section is
shown for the Incident Register. This shows that the SD Business Group has the Incident Register
enabled. Thus, changes defined by the triggers are being recorded for this business group.





Continuous Calculation

9

Incident Register

Continuous Calculation requires a system of identifying changes that take place in the system that can
affect a Payroll Run, Prepayment or Costing process. Thus the Incident Register has been developed that
records changes that take place in the system, note that the Incident Register is not an auditing system, it
merely records changes that it has been told to look for.

The Incident Register is not only used by the Continuous Calculation functionality, but it is also in other
sections, do not assume that the Incident Register is for Continuous Calculation only. E.G.
RetroNotification and Global Proration use the Incident Register.

The Incident Register is loaded via special triggers built on top of tables, the triggers are data driven to load
the Incident Register with the required values. The Incident Register is then used by Continuous
Calculation, the Global Proration mechanism and Retro Notification reports. Both Proration and the Retro
Notification reports use the Incident Register Interpreter to interrogate the Register, however Continuous
Calculation accesses the Register directly. This direct access of the Register results in some issues with
Continuous Calculation, see the section regarding Limitations.




The Incident Register is defined as a Functional Area, thus can be enabled by Business Group or
Legislation. The triggers defined against this Functional Area are special triggers in that they record the
changes that take place on the database. The triggers created for the Incident Register should be generated
by the utilities that are provided. See later sections on Creating Triggers.

Continuous Calculation

10

Creating Triggers for the Incident Register.

Triggers that are used in the Incident Register must be created in a certain way, these triggers use a data
driven mechanism to decide whether information should be recorded in the Incident Register. As a result of
this there are a number of utilities that should be used to create a template for the trigger.

Firstly, when creating a trigger for the Incident Register, the user must ensure that a trigger doesnt already
exist. This can be done simply by looking at the existing Dynamic Triggers and looking at the Functional
Area.

Secondly the procedure that is to be the component of the trigger must be created. There is a utility that can
be run to generate the code for this procedure. Simply run the generate_upd_trigger in PROCEDURE
mode and PYUPIP output will write out a template for the generated procedure. Several arguments must be
supplied to the utility:-

Table Name for which the procedure is being created
Username that owns the requested table name
Surrogate key ID column name
Column name of the effective start date
Column name of the effective end date
Mode in this case will always be PROCEDURE

The following is an example of how to run this utility and the output that you can expect to receive.

begin
pay_continuous_calc.generate_upd_trigger(
p_table_name => 'PAY_ELEMENT_ENTRIES_F',
p_owner => 'HR',
p_surr_key_name => 'ELEMENT_ENTRY_ID',
p_eff_str_name => 'EFFECTIVE_START_DATE',
p_eff_end_name => 'EFFECTIVE_END_DATE',
p_mode => 'PROCEDURE');
end;
/

In another session the user needs to run the PYUPIP executable:-

$ PYUPIP <username>/<password> PAY_ELEMENT_ENTRIES_F
connected: monitoring pipe PAY_ELEMENT_ENTRIES_F
1
2
procedure PAY_ELEMENT_ENTRIES_F_aru(
p_business_group_id in number,
p_legislation_code in varchar2,
p_effective_date in date
,
p_old_ASSIGNMENT_ID in NUMBER,
p_new_ASSIGNMENT_ID in NUMBER
,
p_old_ATTRIBUTE1 in VARCHAR2,
p_new_ATTRIBUTE1 in VARCHAR2
,
p_old_ATTRIBUTE10 in VARCHAR2,
p_new_ATTRIBUTE10 in VARCHAR2
,
p_old_ATTRIBUTE11 in VARCHAR2,
p_new_ATTRIBUTE11 in VARCHAR2

pay_continuous_calc.event_update(p_business_group_id,
p_legislation_code,
'PAY_ELEMENT_ENTRIES_F',
'EFFECTIVE_START_DATE',
p_old_EFFECTIVE_START_DATE,
p_new_EFFECTIVE_START_DATE,
p_new_effective_start_date,
least(p_old_effective_start_date,
p_new_effective_start_date)
);
end if;
--
/* Now call the API for the affected assignments */
Continuous Calculation

11

declare
l_process_event_id number;
l_object_version_number number;
cnt number;
begin
if (pay_continuous_calc.g_event_list.sz <> 0) then
for cnt in 1..pay_continuous_calc.g_event_list.sz loop
pay_ppe_api.create_process_event(
p_assignment_id => p_assignment_id?,
p_effective_date => g_event_list.effective_date(cnt),
p_change_type => g_event_list.change_type(cnt),
p_status => 'U',
p_description => g_event_list.description(cnt),
p_process_event_id => l_process_event_id,
p_object_version_number => l_object_version_number,
p_event_update_id => g_event_list.event_update_id(cnt),
p_business_group_id => p_business_group_id,
p_calculation_date => g_event_list.calc_date(cnt),
p_surrogate_key => p_new_element_entry_id
);
end loop;
end if;
pay_continuous_calc.g_event_list.sz := 0;
end;
--
end PAY_ELEMENT_ENTRIES_F_aru;
The output from the PYUPIP utility is a PL/SQL procedure that can be placed in a PL/SQL package. The
procedure produced is a template and will require some editing, one example is that the affected assignment
id must be passed to the create_process_event API, in addition to general formatting changes.

The assignment_id in these procedures must be passed to API, if there is a direct affect on the assignment.
Tables that affect multiple assignments should have the assignment id set to null, these tables will not cause
a recalculation in Continuous Calculation, and example would be PAY_INPUT_VALUES_F. Since these
tables affect a potentially large number of assignments, and for the Continuous Calculation to try to work
out which assignments are affected by this type of change, it would be easier for users to rerun the whole
payroll run cycle. See Limitations for these types of tables.

The third part of setting up a trigger for the Incident Register is to set up the trigger definition, again there
is a utility that can be used to set this up. The utility is again generate_upd_trigger but this time called in the
TRIGGER_DATA mode, by calling this procedure information will be created on the system that can be
viewed via the Dynamic trigger form.

begin
pay_continuous_calc.generate_upd_trigger(
p_table_name => 'PAY_ELEMENT_ENTRIES_F',
p_owner => 'HR',
p_surr_key_name => 'ELEMENT_ENTRY_ID',
p_eff_str_name => 'EFFECTIVE_START_DATE',
p_eff_end_name => 'EFFECTIVE_END_DATE',
p_pkg_proc_name => 'pay_continuous_calc.pay_element_entries_f_aru',
p_bg_select => '''select paf.business_group_id from per_assignments_f paf
where assignment_id = ''||:new.assignment_id||'' and
to_date(''||to_char(:new.effective_start_date, ''DD-MON-YYYY'')||'',''''DD-MON-YYYY'''')
between paf.effective_start_date and paf.effective_end_date'''
p_mode => 'TRIGGER DATA');
end;
/

Finally, the trigger that has been created needs to be added to the Functional Area for the Incident Register,
this can be performed in the Application itself via the Functional Area form.

Continuous Calculation

12

Starting the Incident Register

Before Continuous Calculation can be used the Incident Register must be started, to start the Register the
user/administrator must decide which triggers need to be started for Continuous Calculation. Once this
decision has been made then the triggers can be generated and enabled via the Dynamic trigger form.
Note: Make sure that the components are enabled also.

The Continuous Calculation system uses a data driven mechanism to decide what is recorded in the
Incident Register, for each table the user/administrator can decide at the database row level what should be
recorded. This is performed via the Dated Tables form, basic information about the table is automatically
placed in the Dated Table repository by the generation utilities described previously.



Within this form the user can decide which columns on the database to monitor, these are row level
database events not datetracked events. The form shows that for the table PAY_ELEMENT_ENTRIES_F,
the system is monitoring for row level changes in the COST_ALLOCATION_KEYFLEX_ID,
EFFECTIVE_START_DATE and EFFECTIVE_END_DATE, thus every time one of these columns
changes on the database information is placed in the Incident Register.

Note: The form also shows the system monitoring row inserts and deletes for this table. This data is seeded
by Oracle HRMS and requires special trigger to do this. There should be no reason why insertion/deletion
triggers should be needed by clients.

The form also shows the field Change Type, this field is used by Continuous Calculation to target what
effect the change has. There are 4 values used by Continuous Calculation:-

DATE_EARNED - This type of change triggers the recalculation of the payroll run based on the Date
Earned of the Payroll Run.
DATE_PROCESSED - This type of change triggers the recalculation of the payroll run based on the
Effective Date of the Payroll Run.
PAYMENT - This type of change triggers the recalculation of the Prepayments process.
COST_CENTRE - This type of change triggers the recalculation of the Costing process.

The change type is very important for changes that affect the Payroll Run, the user must ensure that the
correct change type is used. An example, is that all element entries use the change type of
DATE_EARNED since the payroll run accesses entry information as of date earned. However, tax
information is accessed as of the effective date, thus these changes are DATE_PROCESSed type.

Continuous Calculation

13

Many of the trigger points have already been seeded correctly for each legislation, however personal
information accessed by Fast Formula written by the client may not be included in the seeded data. Thus,
entries will be needed in this form.
There should be no reason for the client to create PAYMENT and COST_CENTRE entries, all of these
should be covered by the seed data.
Continuous Calculation

14

Viewing Changed Processes
Once the Incident Register has been started, the system will immediately start recording changes. This
information may be used in the View Assignment Action form, to show actions that may have changes
against them. The following example shows a person that has been processed in 2 payroll runs and a
prepayment, all of which have the status of Modified. The Modified status basically means that the
results have been created with no error, the user is still able to view the results and process as if the status is
Complete. The Modified status simply means that the system has detected a change in the assignment
that may result in a change to the calculation, it does not stop subsequent processing of this action.


Continuous Calculation

15

Running Continuous Calculation

For employees to be recalculated a process must be submitted to the Concurrent Manager, this process will
recalculate all assignments that have Run, Prepayment or Costing actions that are not Complete. The
process submitted is called Continuous Calculation and simply takes one parameter of Payroll Name, as
shown in the following form.



When submitting the process the user can use the Application Object Library (AOL) sheduling system to
decide when the process is to be processed and whether it is to be repeated on a regular basis like once
every night.



Once the job has been submitted to the Concurrent Manager the process will run at the appointed time, the
process will result in several child processes that will perform the required reruns for the required payroll.
The following form shows the Continuous Calculation process Running. The process has submitted a
Continuous Calculation

16

number of child processes to perform the work required, the number of child processes will vary depending
on the number of processes that need to be reprocessed.




Continuous Calculation

17

Limitations

The initial release of Continuous Calculation has a number of limitations, this in time will be removed as
the system moves to using the Interpreter on the Incident Register rather than directly looking at the
Incident Register.

When Continuous Calculation starts using the Interpreter then some additional set up will be needed.

1. Continuous Calculation should only be set up for Person/Assignment level tables. It should not be set
up for tables that affect multiple People, for example, grade rates, element types etc.
2. Continuous Calculation looks directly at the Incident Register, rather than use the Interpreter. As a
result the View Assignment Actions shows the Modified status for more assignment actions than
actually physically need reprocessing.
3. Hence, Continuous Calculation actually reprocesses more assignments than actually need reprocessing.
4. Triggers are used to record changes in the Incident Register. It is vital that clients ensure that these
triggers are always in place.

Continuous Calculation

18

Summary
Oracle Payroll have provided a mechanism in Continuous Calculation that allows clients to process their
Payroll Runs well in advance of the actual payments having to be made. The system can detect any changes
that that take place for an employee and recalculating the employees Net payment when required.
Continuous Calculations ability to be enabled by Business Group and Legislation allows the system to be
globally implemented in a multi business group environment. Combined with the expandable Dynamic
Trigger mechanism give Continuous Calculation a flexible change detection system.


Continuous Calculation

19