Deductions may be entered manually at any time. However, most deductions are repetitive and repeated manual entry just increases the chances of entry errors. The Payroll provides a structure for defining deductions to minimize the need to make manual entries. A deduction definition is identified by a Deduction Code and an Employee Id. A general deduction has a Deduction Code and a blank Employee Id. The general deduction does not initiate an employee deduction without additional data. The simplest automatic deduction is an employee deduction taken every pay period. In this case all the data to do the calculations are on the employee-Deduction entry. When a deduction is added to an employee the data fields are defaulted from the general deduction definition. In order for the employee-deduction entry to apply independent of anything else the Status must be set to F, for forced. Then there are Department Deductions. These are associated with the department through the Deduction Sets. When a deduction appears in a Deduction Set with a simple Action code it is calculated every pay period in which that deduction set is active for every employee. The definition of the calculation is provided by the Employee-Deduction entry. If there is no specific Employee-Deduction entry the definition is taken from the general deduction definition. The Employee-Deduction entry can be used to deactivate the deduction by using Calculation Type A and zero in all the amount fields.
The most complex automatic calculation is the Conditional Deduction. A Conditional Deduction is taken only when:
The calculation may be defined directly on the Employee-Deduction entry by providing all the values. It may be defined indirectly by having a blank Calculation Type on the Employee Deduction entry. In this case the generator gets the calculation definition from the general deduction definition. The Employee-Deduction entry can be used to deactivate the deduction by using Calculation Type A and zero in all the amount fields.
There are two classes of deductions that are generated. Before either class is generated all earnings must be posted to the Earnings History. Generated deductions go into a batch where they can be edited further before posting. Manual entries can be added to a generated batch, or processed in an independent batch.
The programmed generation of deductions is driven by the Employee Masters. Deductions are generated for every active employee, whether he has income or not. If an employee is not to be included in a payroll, simply delete his entries from the generated batch. If the employee is going to be inactive for a time set their status to I. If they are no longer employed set their status to T.
Once the raw earnings have been totaled for the employee, generation begins with the deductions found in the Deduction Set for the Department. The order of processing is controlled by the sequence of codes in the Deduction Set. A simple Action Type, like Y, is done immediately. A conditional Action Type (*) requires a check for a paired Employee Deduction. i.e. the Deduction Type is also *. Initially only deduction calculations can be conditional. If no Calculation Type appears on the Employee Deduction the definition of the deduction is taken from the General Deduction in the series. A Deduction Set entry can be suppressed by setting the status of the associated Employee Deduction to F.
After the Deduction Set is processed the list of Employee Deductions is scanned. The order of processing is defined by the Deduction Code, initially. Conditional entries, Action Type = *, are ignored. This is a one-pass generation process with no consideration for previously posted deductions. There are also constraints on sequences of processing in this implementation.
First the posted earnings are totaled. Then the posted calculations are applied according to their type. Totals are accumulated of gross earnings, taxable earnings, and UIC amounts. The government deductions are calculated in the order CPP, UIC, then income tax.
UIC is based on weekly earnings no matter how the earnings are reported. To do this the Period End Date must also be the end date of a UIC week. Earnings and hours are then allocated to the weeks depending on the Effective Date of the transaction and the number of days to which it applies, assuming an even distribution over these days. Taxable benefits and calculated income transactions are assigned to the week in which their Effective Date falls. From these totals we determine which weeks qualify for UIC and for how much. A deduction transaction is generated for the UIC premiums and a UIC History transaction is generated to record the Insurable Earnings.
If the resultant cheque is negative it checks to see if the employee can have an automatic advance. i.e. Does this employee have access to Deduction Code ZAI? If he can, an advance is issued in this pay period to bring the check to zero. When this entry is posted, a second entry is posted to the next pay period to recover the advance. The first entry is an income and the second is a deduction, and the distribution codes are flipped to effect account clearing. Otherwise, the entries are identical.