Connected data

They say that everything in the world is interconnected.

There are many connections between different things in HR and payroll. The data in one module affects another, and in different ways. In Umana there are several ways data is connected.

For example

• Employee's age RRQ/CPP eligibility
• Employee's age & salary insurance premiums
• Employee's hire date, or maybe hours worked probation completion.
• Employee's province his tax calculation

A few of these connections are bi-directional. But most are uni-directional (one-way), and some of those are semi-automatic.

Bi-directional: You knock over the first domino and the others go down too; you pick up the first domino and the others come back up, as if they were tied together.

Uni-directional: You knock over the first domino, and the second one goes. BUT when you pick up the first domino, the others don't pop up by themselves. You have to pick up the others manually (if you want to).

Semi-automatic: You move or knock-over the first domino; then you run a tool to find and apply the changes to the others. This kind of link gives you the most control, but you have to stay awake.

1. "Rule-to-Instance" pattern

This semi-automatic uni-directional connection pattern is common in Umana: You define your company rules, which then get applied to employees. For example...

• Benefit plans (the rule) Employee benefit enrollment (the instance).
  (BPLAN BENEFIT)

• Time bank plans (rule) Employee bank entitlement. (APLAN TIMSUM)

• Rate table (rule) Employee salary and hourly rate. (See example below.)
  (RATE JOBHIST)

Example: Applying rates from the rate table to employees

Here is the normal process.

1. You enter rates in the RATE table for the new year, based on your collective agreement. At this point they are not yet applied to employee records (JOBHIST)

2. A bit before the new year arrives go to the RATE form and click on Tools > Apply New Rates. This takes you to wizard which creates new JOBHIST records with the new date when they are applicable.

3. Once the new rates are in the RATE table, you can enter a future movement in JOBHIST and Umana will pick up the new rates. When you do so, Umana looks in the rate table

This means that you can still go into JOBHIST and make changes.

However, there are also the exceptions and special cases. For example:

• Rates not known when future movement entered.
  In this case, you end up with a movement with the wrong rate. You can still correct it manually in the employee's JOBHIST, or use the apply rates wizard: it can correct existing future-dated records as well

• Collective agreement signed late This is when you will need a retroactive pay.

• The employee is an exception Just check the Red Circle option on JOBHIST.

2. Hard links, for Redundancy

This bi-directional linking is used in a couple of places:

JOBHIST PERS redundancy.

• The PERS record has fields which reproduce the values in JOBHIST. For example, the employee personal status is PERS.E_PSTAT and in JOBHIST.H_PSTAT. The value in PERS is the current status, but JOBHIST has the full history.
• This redundancy is maintained automatically by Umana. Whenever you change the current JOBHIST record, the PERS record is updated by the Umana engine.

TIMEDT TIMSUM redundancy.

(TIMEDT = Attendance detail. TIMSUM = Employee time banks)

• When you add, delete, or modify a transaction in attendance detail which affect a time bank, the bank balance is updated automatically by Umana.

Rebuilding redundancy

Sometimes the redundancy breaks: the values get "out of sync". This can happen when you change reference table values, for example.

Umana has tools to re-sync the values. Use them when some values seem out of whack.

To rebuild the JOBHIST PERS redundancy
Use the Check JOBHIST consistency tool.

To rebuild the TIMEDT TIMSUM redundancy
Use the Recalculate TIMEDT => TIMSUM tool.

3. Uni-directional and semi-automatic links

There are many soft links in Umana, to help automate your normal processes.

They are one-way: That means that when you correct mistakes in the source (pick up the first domino), you have to manually correct any automated consequences as well. These are your exceptions.

PERS BENEFIT links

For example

• When an employee changes status it can affect his benefit eligibility.
• When an employee's salary changes it can affect his benefit contribution.

The rules can be complex and are configurable. The automation is configurable as well, in the benefit plan. You can make the automatic or semi-automatic.

There are always tools which you can run, that check where synchronization is required and to trigger it as required.

Alarms

The PERS BENEFIT automation in handled in Umana by the alarm system. When you turn on automation for a benefit plan, Umana creates an alarm to to trigger the action. (Remember, this is always one-way.)

• You can also use the Alarm system to trigger many other functions in Umana, from sending emails to interfacing with other software.

• Dated alarms can trigger on a date calculated from employee information.

See also Umana watches, which show you upcoming dated events.

TIMEDT

TIMEDT = Attendance Detail = Gross pay.
What about actions that need to trigger when the employee has worked a specified number of hours? For example, enough hours to complete probation.

Because TIMEDT is part of the payroll process, it requires special handling. Transactions can be imported or created in TIMEDT and then tweaked and adjusted in many ways. Umana does not trigger any automation until the paymaster is ready and says "go". This is part of the payroll process.

While Umana offers many tools to determine and act when an employee reaches an hours-worked threshold, it is always a semi-automatic process.

• See Pre-pay process