Oracle Payroll Event model (PEM) is the basic architecture which
is used by Retropay, Continuous calculations, Proration, iterative engine etc…
This post describes about PEM architecture and its setups
needed.
Basic function of PEM architecture is to capture and process
the runtime changes (also named as events) that are caused by the manual changes recorded by users in
HRMS, for example compensation changes, supervisor changes, location changes
etc…
This is simple architecture; it has 3 steps, Event Capture, Incident
Register and Event Interpretation.
Each phase has to be configured to restrict/process the actual
events that need to be tracked. It works like an AUDIT system, but more
tailored to what is actually interesting.
Step 1) Event Capture:
Configuring event capture is the first and important step in
PEM. It is done by enabling dynamic triggers. Dynamic triggers are nothing but
the database triggers which are generated automatically using the form.
Navigation Super HRMS Manager Responsibility -> Other Definitions ->
Dynamic Triggers Form
The following screenshot shows the options to query existing
dynamic triggers on a specific table.
When clicked on Find button, Actual trigger definition is
displayed. No need to add any code, it is auto generated. All that we need to
make sure is to check if “Generated” and “Enabled” check boxes are selected.
Dynamic triggers are also called as continuous calculation trigger, as the name
says, this trigger enables the tracking on the desired changes continuously at
runtime. Triggered code can be viewed using “view source” button.
General Naming Convention for the name of dynamic trigger is
given below.
- Name of Insert Trigger on PAY_ELEMENT_ENTRIES_F is PAY_ELEMENT_ENTRIES_F_ARI
- Name of Update Trigger on PAY_ELEMENT_ENTRIES_F is PAY_ELEMENT_ENTRIES_F_ARU
- Name of Delete Trigger on PAY_ELEMENT_ENTRIES_F is PAY_ELEMENT_ENTRIES_F_ARD
Step 2) Incident Register:
Configuring Incident Register is nothing but the high level
functional areas for which the events (changes) have to be tracked. It is
obvious that events can be tracked only for the tables which have dynamic triggers
enabled in previous step. Configuring Incident Register facilitates the
previous step.
After configuring this step system immediately start
recording the changes.
Navigation, Super HRMS Manager Responsibility -> Other
Definitions -> Functional Areas Form and query for “INCIDENT REGISTER”;
Event capture can be enabled at 3 levels.
- Trigger Level: If events on specific table have to be tracked. Screenshot below is configured to track Inserts, updates and Deletes on PAY_ELEMENT_ENTRIES_F table.
- Legislation level: If all the events at legislation level have to be tracked. Screenshot below is configured to track all events (Inserts, updates and deletes) at US, MX and FR legislations.
- Business Group level: If all the events at business group level have to be tracked. Screenshot below is configured to track all events (Inserts, updates and deletes) at Progress UK and Vision Corporation business groups.
Step 3) Event Interpretation:
This step is nothing but configuring system to look for
specific events out of all the events that are recorded in the system (because
of HR changes). This is done by defining event group, which is used in Retropay
and Proration. Navigation, Super HRMS Manager Responsibility -> Other
Definitions -> Define Event Group
Following screenshot shows the event group definition, which
is expected to interpret on Datetrack Inserts, Datetrack Delete, Datetrack
Correction on a specific column, Datetrack Update on a specific column. This
inclusion may vary depending on how you want retro process to pick your
changes. This screenshot will only pick up changes to element entry values,
because it has only those events included.
This event group can only be used in Retropay processing,
because event group type is selected as Retro (Other choice is Proration).
Want to read more? Then read HRMS DEVELOPMENT WHITE PAPER -
Continuous Calculation (Doc ID 188154.1)
Very nice Suresh..
ReplyDelete