Use-When conditions

Overview

Some reference table have USE-WHEN condition or rule. Examples: EMPRNO, PAYGRP, DATERULE, WATCH

In the Use-when column you specify a simple rule (condition) which table entry applies to which employees by default.

How it works

For any table type with a USE-WHEN column

For each entry in the table you enter a condition specifying to which (subset of) employees that table entry applies. Below is an example of how you might build your PAYGRP table

Paygrp	Description	Use-When condition
BLUE	Blue collar, weekly pay	pers.E_UNION='FTQ'
MGMT	White collar, biweekly pay	pers.E_UNION=' '

When Umana needs to know which entry to apply to an employee, it scans the table entries (in TBLSORT + TBLID order). When it finds one whose condition is true for that employee, it uses that entry (and stops scanning).

Conditions

Conditions are expressions which are true about some employee, and false for others.

For some tables, use-when conditions are entered using the Expression Generator.
For other tables conditions are entered by filling in the employee selection / filter form

Always false, always true

An empty condition is always false.
You can have entries in your table without conditions, for values that you want to assign manually.
For a condition that is always true, use the expression 1=1.
This can serve as an "otherwise" catch-all case — just make sure the table SORT value is higher than the other entries.

The Good, the Bad, the Math

What's nice about this approach is that it is easy to configure.

What's bad about this approach is this it is easy to mess up (and not know it).

Like a CASE statement

If you understand programming, you'll recognize this as just a big sequence of IF / ELSE IF / ... (or DO CASE) statements.

Each condition in your table is another case to test.
Table entries with the lowest SORT order are tested first. For entries with the same SORT values, Umana goes in order by the CODE.

The pitfalls

There are two gotchas to watch out for.

Employee meets none of the conditions
In the diagram on the right shows, we might cover cases A and B. But what about case C?
In the PAYGRP example above, what about employees with E_UNION='CSN'?

Solution: Create an OTHERWISE catch-all case. You can do that by creating an entry in your table at the end (highest SORT value) and condition 1=1.

Employee meets more than one condition
In the PAYGRP example, that can't happen, but you can certainly create conditions where it does. That is where A and B intersect (overlap) in the diagram above.

Solution: Check your conditions carefully and put the ones with predominance first (lowest SORT value).