PAYROLL
PAYROLL
INTRODUCTION
Processing payroll is a very typical and fundamental business requirement
across enterprises. If we have human resource, we will have to pay them.
This sounds pretty simple. When we have 10 odd employees working in
our firm, and we write checks for them; this can be done with the help of a
spreadsheet and it won’t take a lot of time or resource to get something of
this sort to be done. But let's think about a big enterprise. Processing
payroll for a big enterprise is a gigantic task to do. It takes a lot of
preparation just for the payroll processing and again a lot of post
execution steps to make sure all the data are accurate and stored for
further usage.
Imagine doing all these by ourselves, without any software in place. Won’t
we have to run another enterprise, just to process pay checks for our firm?
Yes it might take those many numbers of people, just to do that job right.
We are here to avoid that. We will use Oracle Payroll for our firm.
Let’s take two minutes, and imagine Oracle Payroll has been successfully
implemented in our firm. Now we are trying to run our Payroll. For that
Processing portion of it, Oracle payroll, divides the entire payroll process in
to three broad divisions:
Pre-Processing
Capturing salary
Capturing time cards
Running BEE process
Processing
PYU_GEN Process
Retry and Rollback
Quick pays
Post-Processing
Running Payroll Registers
Tax remittance
Gross to Net Calculation
Determining Payment Methods
Check writers / BACS / NACHA/ ACS / Garnishments / Manual Payments
Payment Register
Retro-Pay
Reversals
Advance Payments
Archivers
Costing
Transfer to GL
A lot of words here sound like a foreign planet language, don’t they? We
will go through each and every step of it to understand what exactly
happens in the entire course of payroll processing. However we will have
to first get Oracle Payroll Implemented and running.
OVERVIEW
This chapter talks about:
Oracle Payroll as a module
Components of payroll: Earnings, Deductions, Taxes, Elements, Input
values, Balances
Different Payment Methods and Payment Frequencies
Setting up payroll for an Enterprise
Pre-Processing Steps: Pre-Payments to Transfer to GL
Payroll run validation and correction methodologies
Retro Pays
Case Studies
LEARNING OUTCOMES
After going through this Chapter, you should be able to:
Understand the basic components of payroll and relate them to a real time
pay check
Set up Oracle payroll for an Enterprise
Process the payroll for an Enterprise
Process and validate the payroll processes and supporting reports
Run a retro pay
DICTIONARY
DICTIONARY
Before getting started, we must know the terms that are going to be used
in this chapter. We must know the processes and taxonomy in order to
understand the basics easily, so here we go.
Elements
An element is the building block of payroll. It is a place holder to contain
values, which will be used for a Payroll processing. The primary usage is to
embed a type of income or deduction into an element, so that the entries
can be made on the Employee's record related to the element. Later with
the entries, we can calculate the payroll.
Earnings
An earning is a type of element which is as simple as what it means in
English. This is a type of element which actually Debits the amount value
attached to it. For an example, Regular salary/ Bonus will be an earning. In
Oracle Payroll prospective, Earning is a template form. We will learn more
about it when we start configuring Payroll.
Deductions
This is a type of element as well; however it credits the amount value.
These are used to deduct some amount from our payroll. For an example,
our Medical Insurance amount (Rate) is a deduction that gets credited
from our gross income. Our Tax amount, Provident fund etc are
deductions. To generalize, anything that gets deducted from your Salary is
known as a deduction. This is exactly opposite to Earnings.
Balances
A Balance is an aggregate of one or more elements that have a numerical
value attached to it. These are created for tracking purpose; to track the
aggregated values with different dimensions.
OK, let’s discuss that a little more with an example. Let's take an example
of Bonus again. We will create a balance with name BONUS_BAL. We will
attach my Bonus element to it. We would expect the BONUS_BAL to
answer the following questions for me.
How much Bonus did we pay in the fiscal year of 2010?
How much Bonus did we pay in 3rd Quarter of 2010?
How much Bonus did Jean receive in her entire length of service?
So these parameters Fiscal Year, Quarter, Length of service, these are all
Dimensions, based on which we can get a value. If we draw Bonus as X
axis, Time in Y axis, and plot a graph, it will give us a point for the Quarter
of 2010, Right? So the axis here is one dimension. Similarly we can put
dimensions of many types. So bonus is usually a Multi-Dimensional
architecture of a collection of data; where Data being the numbers
attached to the elements.
Why would we need that? In our pay slip, there is something called as
Income Tax deduction, and something called as YTD (Year To Date)
Deduction. Where is that YTD Deduction coming from? It’s coming from
the balance attached to the Income Tax element, and the dimension we
are using is Year to date, that is for the fiscal year being evaluated. Clear?
Nice. This is just a simple example of balance usages; there are actually a
lot of usages of balances, and we will discuss them while discussing about
the Payroll implementation steps.
Payment Methods
An employee gets options related to the way he wants to get paid. Those
options can be:
Check Payment
Direct Deposits (Bank Account credits)
Garnishments (Third Party Payments; for an example, a court order to pay
$200 every month to someone / charity)
Cash, although paying by cash is not a very standard practice, few of the
countries allow paying your employees by cash.
For an Example, If Joe has two accounts, one checking and one savings,
and then he might request his salary like this:
Give me a check for $300.
Then $500 should go as a garnishment to pay out my ex-spouse, as per
court order.
Rest of the money should go to my Savings account.
Payroll Frequency
Every enterprise runs on a schedule of payroll frequencies. These are the
frequencies on which the payroll is processed and payments are made.
The Frequency again depends upon the type of payroll a particular
employee is on. Examples are:
Monthly
Semi-Monthly
Bi-weekly
Weekly
So if Joe is entitled to the Monthly payroll, he will get paid every month. So
his payroll frequency is monthly.
Consolidation Sets
If an enterprise has three payroll cycles; Monthly, Semi Monthly and
weekly; it means, it has employees who are paid every week / once in a
fortnight / once a month. This also means it will have to process at least
one payroll every week (weekly). Every alternate weeks, it will have to
process two payrolls (one weekly and one semi-monthly), and all three on
the last week of the month. Its not just about the payroll process, the
enterprise must process post processing steps for each one of them.
Let's take an example of Mr. Joe, who is working in our enterprise since
last 7 years. Now he is a Project Manager, and his billing (his pay check)
should be paid by the department for which he is working. Similarly Ms.
Jean, who is a contractor, and has been hired to do some market research,
should get paid by the department of Sales.
We know that after the payroll is run, we are going to send these reports
to General Ledger aka GL, so that the books/accounts are updated
accordingly. However how do we specify, which pay check is paid by which
department? There will be situations where we want the cost to be paid by
the Admin cost centre, as the job was department independent. So to
cater all these requirements, we have a concept called Costing.
We define a cost allocation flex field just for the same purpose. It will have
different segments where we can attach my cost; like, Project, Product.
Cost centre, Account Code etc. These are highly based on my enterprise
hierarchy / design. With that in hand, we can start assigning costing to the
payrolls. We will also have places where we will be able to override costing.
We will learn more about it while configuring those.
The General Ledger has a Flex field called: Accounting Flex field. In a best
case design, the accounting Flex field and the cost allocation flex field
should match. However for all cases, we need to map these two flex fields
in order to link the accounts from HR end to the GL end. There is a form in
HRMS, where the Accounting flex field is mapped to the Cost Allocation
Flex Field via segments. That process is known as the GL Mapping.
Electronic payments
In case of direct deposits, when the payroll processing is done, the bank
must be informed to transfer the amounts to the respective accounts. So
how do we do it?
Element Classifications
There are a set of predefined classifications available with Oracle Payroll,
which can be used to represent the characteristics of a particular element.
Each and every element must have a classification attached to it. The
Classification in turn depicts the way the element behaves. For an
example, an Element of classification type ‘earning’, tells us that it’s an
Earning, and the money accumulated in it will be added to the pay check.
An element with Classification as "Information", tells us it’s just for the
information purpose only, and will not be holding any money.
Let's say, we have a primary classification that has 10 elements associated
to it. Out of those 10 elements, 5 elements are very similar. They belong to
the same payroll entity/ they have similar usage. In this case, we can define
a secondary classification that will help us group the similar elements
together. Although Secondary classifications are not mandatory they are
very useful in Balance configuration. As an example, a Travel Allowance,
House Rent Allowance, uniform allowance are of type Earning (Primary
Classification) and are type Paid Allowance (secondary classification).
SETTING KFFS
There is a swim lane procedure for the configuration of Oracle Payroll, and
w are going to follow the same. We will start with defining the KFFs.
OK, once we know the levels, let's configure them. See Figure 5.2 – Cost
Allocation Segments.
Figure 2 Cost Allocation Segments
As the segments are added now, the next task is to set the details for that
segment. To do so, click on the first segment and press open. See Figure
5.3 – Cost Allocation Segment Description.
In cases like this, we can make use of the range. A segment with high range
must always be bigger than the segment with the low range. To solve the
dates issue here, we can define the end date to be in High and the start
date as low.
Laws of Range:
We should have the Low segment appear before the High segment
We cannot just assign one segment as High and not assign any as low, or
Vice versa. If we have a low segment, we must have a high segment too.
As the ranges are set, let's talk about qualifiers. Remember we talked
about these while talking about the KFFs in the core HR and AOL section?
OK here it is; Qualifiers define the segments that can be updated at one
given level. Talking about the Cost Allocation KFF, we have the Following
places where a segment can be updated:
Payroll
Element link
Organization
Assignment
Element Entries
In these levels, the cost can be attained or assigned, with precedence from
payroll to element entries with increasing order. So it means, the cost
associated to an element entry has the highest precedence, hence it can
be overridden by anything we enter at any upper level.
So what's the role of the qualifiers here? The qualifiers define the
segments that can be updated in the above given levels. For an example, if
we have an Overtime element attached to an employee's record. The
costing is allocated to the HR department at the payroll (highest) level. On
Monday, the employee worked for 4 extra hours to support the Admin
Department. Now, the account Department wants the cost for those 4
hours to be added to the Admin department, not to the Payroll
department. We can then come down to the Element links (Lowest) level,
and override the costing to the Admin dept.
This configuration was possible, just because we made the Project code
(for an example) available to be updated at the element links level. If we
won’t make the project code segment available at the element links level,
we will have to choose any other segment code to override the cost. So we
have the autonomy to enable or disable any particular segment at any
level. This is done through qualifiers.
Click on the qualifiers tab on any segment.
Choose the places where we want the segment to be visible.
Close the window and repeat the same for the rest of the segments.
One of the most important reasons to have People Groups is the element
Link. In element links, there are various criteria based on which we can set
eligibility of an employee to have the element attached to him. However
the eligibility options are limited. In a case where the user cannot separate
the employees using the given eligibility options, he always has the liberty
to use people groups. We will discuss more about the usage of people
Groups while discussing Element links.
Steps:
Click on Title
Query for the string "People Group Flex field"
Define a new structure with the following data. See Figure 5.4 – People
Group Segments.
PAYROLL
ESSENTIALS
SETTING UP PAYROLL
As per Core – HR Design, every employee assignment must have a payroll
attached to it. The entity payroll, tells the system about the payroll
frequency/ cycles, the valid payment methods, the check dates to which
the assignment is entitled. Employees in a same payroll share the same
payroll frequency and pay dates.
Payment Methods
Every organization has rules for its payment methods. Some organizations
pay by Check, some by direct deposits to banks, and some even pay by
cash. These methods of payments that an organization follows to pay its
employees, is known as the Organizational Payment method.
Each employee of the organization may get to select the method with
which s/he liked to be paid every pay period. These are the valid options
that an employee can choose in order to get his salary. Some people like it
on their bank account, some might like a check, and for some it could be
both.
Each and every payroll clubs together a set of valid payment methods in it.
So the available options can be specific to each payroll. For an example, an
enterprise can define payment methods like this:
Weekly : Check only
Biweekly and Semi monthly : Check and Bank account (Automatic Transfer)
Monthly: Bank account only (Automatic Transfer).
The payment methods vary with the types of banks as well. For an
example, if the enterprise deals with 4 different banks, like A, B, C and D. It
will need four different payment methods defined for each of the banks it
deals with, even though all of the payment methods will be of type
‘Automatic Transfer’.
Consolidation Set
A consolidation set is a methodology that is used, to group payrolls with
similar timelines together. This makes payroll process and post processes
easy to manage and run. Although a lot of payrolls can be part of one
consolidation set; every payroll must have one, and only one consolidation
set attached to it.
Steps: Create a new row with the name of the consolidation set. We can
create as many as we want, based on our requirement. See Figure 5.16 –
Consolidation Sets.
Payroll Definition
Once the payment methods and consolidation sets are defined they can
now be associated with the payroll definition, along with the time period
and the costing information. So payroll definition is the screen where
payment dates, check dates, consolidation set, a default payment method
etc are assigned to a particular payroll.
Steps: Create a new record and fill in the details. See Figure 5.17 – Define
Payroll.
GL FLEXFIELD MAPPING
Payroll is all about paying salaries to employees. And the salary must be
heaved from an account in the enterprise. Usually the labour cost is
distributed based on different organizations that get benefited by the
work. The distribution system is known as costing.
The GL Flex field mapping helps the system link different accounts setup in
the HRMS system with the accounts available in GL (accounting flex field).
In other words, with the GL Mapping we are going to establish a
relationship between the Cost allocations KFF with the Accounting KFF.
With this mapping in place, when the costing process (A post processing
process) is run, it helps the system to carry the costing information to GL.
ELEMENT SETS
There will be many situations in payroll processing, where we need some
kind of grouping to keep things in order and to keep them easy. Tools like,
Element sets, or Assignment sets help us processing things easily on a
group of elements / assignments, without any hassle of re-entering the
Element Names and Assignment Numbers repeatedly.
Steps: Create a new record and start entering the details. See Figure 5.19 –
Element Sets.
ASSIGNMENT SETS
Assignment sets enable us to group a number of assignments together,
and then run any process on them. Examples of its usage are, running
payroll for a set of assignments, Loading Element entries for a set of
assignments etc.
Steps: Create a new record and start entering the details. See Figure 5.20 –
Assignment Sets.
ELEMENTS AND
LINKS
DEFINING ELEMENTS
We have talked a little about elements before. It’s a placeholder to hold the
values that can be assigned to store an entity of payroll; like an earning, a
deduction, a life insurance premium etc. Elements are the building block of
the payroll. If we look at a payslip, we will see different types of pay, like
the basic, travel allowance, Medical allowance, deductions etc. Those are
all elements.
Before going ahead and creating elements, we must make sure we list
down all the elements that we need, along with their names, reporting
names (that will appear on the pay slip), type of the element etc.
There are two ways to create an element.
Use the traditional Element screen
Use a template
Let's learn about the traditional way first.
Input Values
We know that the elements store values. However the actual places where
the values are stored / recorded by the elements are known as Input
Values. These are the place holders that keep the values that can be used
for calculations related to payroll. One element can have one or more
input values attached to it. The input values store the different values that
are used for the calculation of the final value of the element. In some cases
one Input value for an element might feed values to another element for
its calculations. Those are called indirect results.
The one input value that stores the final amount must be stored in an
Input value with name "Pay Value".
Let's navigate through the form. See Figure 5.6 – Input Values.
Formula Results
Fast Formulas can be used for various purposes like, Calculating Pay
values, validating entries, Skipping a payroll etc. There are precise places
where we can use a particular FF. We will concentrate on the most widely
used one; the payroll calculation formula.
Let's see the form, and discuss about the various possibilities. See Figure
5.7 – Formula Results.
Direct Result: This is used when we are updating the pay value of the
element being evaluated.
Indirect Result: This is used when the calculation result of one of the
Input Value of the element being evaluated needs to be fed to another
element's input value. The later then takes it as an Input and processes its
calculation. Continuing with our example, If Bonus needs to be 15% of the
regular Salary. Regular Salary might have an Indirect result to feed the
value to the Bonus element. Bonus element can then take the value and
calculate 15% of the value and use that amount as pay value. So to pass
the value from Regular salary to Bonus element, we can use the Indirect
Results.
Order Incorrect: This result updates the sub priority of the element
selected in element field.
Stop: This formula result uses the effective date of the payroll run to put
an end date on a recurring entry of this or another element (which must
be defined with multiple entries not allowed.)
Steps: Create a new record and start filling in the details. See Figure 5.8 –
Earnings Template.
· Replacement Value: This amount, if entered will replace the amount filled
in with the original element.
· Adjustment Value: This amount, if entered will be adjusted against the
amount filled in with the original element.
We know what tax deductions are. These are the taxes we pay. Oracle has
tied up with a vendor called Vertex, who takes care of all the taxes in
Oracle Payroll in US. So we do not have to worry about the tax percentage
and everything as of now. Oracle has got it covered. It will get cut from the
employee's payroll automatically, based on his work address and home
address. For all other localizations, there are specific taxing rules that are
to be followed.
What are the Non Tax Deductions? These are the voluntary and
involuntary deductions. Like a Life Insurance Premium / rate or a loan
amount to be paid or a debt to be paid back to the company etc. So to
configure these types of non tax deductions, we can either go for an
element creation or create it via a template. Let's see how the template
looks like. See Figure 5.9 – Deductions Template.
DEFINING LINKS
Once the elements are in place, some eligibility criteria must be defined to
help the system determine, whether an element can be attached to a
particular employee or not. That concept is known as linking. Element links
help us define the criteria using a set of indicative data. The elements will
be visible on the element entry screen of an employee, only if s/he passes
the eligibility criteria. One element must have at least one, and can have
more than one links in order to be attached to an employee’s element
entry.
The indicative data with which the eligibility criteria of an element link can
be defined are:
Organization
People Group
Job
Position
Grade
Location
Employment Category
Payroll
Salary Basis
Steps: Create a new record and populate the details. See Figure 5.10 –
Element Links.
ELEMENT ENTRIES
MANAGING ENTRIES
Once the elements and the links are defined, they are available to be
distributed to individual assignments (employees) based on the eligibility.
This distribution of elements is known as entries. The entries store the
name of the element along with the input values, and also the values
assigned to them. Later, when payroll is run, payroll manager engine picks
the entries with the input values and processes them.
Automatic Entries
In many cases automatic element entries can be done on assignments.
Mostly the regular earnings are configured in a way that the entries are
made by design. The assignment and element must satisfy the following
conditions for an entry of this type.
The element link must be standard
The element must be a recurring one
The assignment must be eligible for the link, based on the criteria defined
on the link
Manual Entries
There are cases where the payroll users key in entry by themselves. This
type of entry is known as the manual entries.
Navigation: Total Compensation -> Enter and Maintain -> <Query the
Employee> -> Assignments -> Entries
Steps: Select the element we want to update / create a new record with the
element name. See Figure 5.21 – Element Entries.
To give input values to the element, we will have to select entry values.
Steps: Create a new record with these details. See Figure 5.22 – Batch
Element Entries.
Now, this is the button, we would use, when we want to make an entry for
multiple element for a single assignments.
Using Assignment Set:
This is the Button, we would use, when we want to make an entry for a
single element for multiple assignments. However the multiple
assignments must be grouped together with an assignment set.
Using Totals:
Totals can be used to validate the BEE Transfer. We can put in conditions
in order to validate if the number of entries made matches with the
number of entries requested by us. Or even compare the sum of the
number of hours entered as a whole. Or even do the summation of the
monetary units and compare it with calculation. So this is a powerful tool
to validate data.
Type
Control Total
Message
Choose a type of validation we would need.
BALANCES
MANAGING BALANCES
A balance is helpful to store positive or negative accumulation of elements.
This can be fed by the pay run results or by an Input value. Usually a
balance is created when we need to track an aggregated value associated
to one or more elements, for the purpose of reporting or validations. To
Measure a balance, we have dimensions and levels.
Dimensions: These are the different axes through which the system can
calculate the numbers. For an example, the gross earning in this month, in
this Quarter, in this Year; are the different time dimensions.
Levels: These are the levels on which the dimensions will be applied. For
an example, if we take Month as the time dimensions, the levels can be,
Monthly Salary of an assignment, Monthly Salary of an employee, Monthly
Salary of a department etc.
Steps: Create a new record and start filing the details in the fields. See
Figure 5.11 – Define Balance.
Balance Feeds
As we discussed earlier, there are three ways to assign elements to a
balance. However we can broadly divide the ways into two, using
Elements, and using Classifications (Including both primary and
secondary). Let’s discuss both the ways in detail.
Using Elements:
Navigation: Total Compensation -> Basics -> Balance -> Feeds (Button)
Steps: Create new rows and start filling in the details. See Figure 5.12 –
Balance Feeds.
Figure 12 Balance Feeds
This screen helps us to seed the Input values of various Elements into the
Balance.
Using Classifications:
Steps: Create new rows and start filling in the details. See Figure 5.13 –
Balance Classifications.
Add / Subtract
The Name of the element to be associated
Balance Dimensions
As discussed earlier, Dimensions are the axes of a balance that can
provide data related to a specific area/ time. Most of the dimensions used
in balances are related to time.
Steps: Create new rows and start filling in the details. See Figure 5.14 –
Balance Dimensions.
Navigation: Total Compensation -> Basics -> Balances -> Initial Balance
Feed (Button)
The Input value of the selected element, to be used as the initial value.
PROCESSING
PAYROLL
Now, let's come back to the place where we started. In the flash back, we
learnt, how to configure things alright? Now we will learn about the
processing. Here we will use everything that we've defined this far.
PRE-PROCESSING
This is the stage where all the preparations are done; things like, creating
element entries, getting the costing in place, taxing etc. So let's talk about
these a little bit.
Now, as we have the time card in OTL, we can either run a process to get it
loaded on to Payroll system, or we might get the Time card entries in the
form of a file(Cases where Time card is managed by a vendor), which can
in turn be loaded by using BEE. So once either of the process is complete,
which means the data is transferred to the assignment entries, the time
sheet information is captured.
Getting Benefits Data
To move on, we should then look into the Benefits side of it; the
deductions by the Insurance premium / rate. It’s captured by OAB (Oracle
Advanced Benefits) OR OSB (Oracle Standard Benefits). If we have the
benefits system implemented, it will automatically create assignment
entries based on the deduction. However If our Benefits is managed by a
Vendor, we must request a Payroll Extract / Payroll Interface for the same.
Once we receive the Extract, we will have to use either an Interface or BEE
to load the Entries on to the assignments. So that takes care of the
Benefits portion of it.
Once all these data are captured, the next task is to Process the Payroll.
PROCESSING
Now, we will process a Payroll. To do the same, we will have to run it
through a seeded Concurrent Program. The name of the Program is
"Payroll Run / Payroll Process".
Navigation: View (M) -> Request (M) ->Submit a new request -> Single
request
Steps: Enter the name of the Process "Payroll Run / Payroll Process" and
enter the parameters. See Figure 5.23 – Payroll Process Parameters.
POST PROCESSING
So now, as the payroll is processed, what are the next steps? There is a lot
of processing involved. Some are mandatory processes, and some are
optional. Usually the Optional Processes are to generate reports that can
be used for verification. Usually Payroll Administrators ask for their own
set of reports for comparison and logging, which is very enterprise specific.
However in this section, we will learn about the Mandatory processes first
and then will look at some of the widely used optional Processes.
Prepayments
This is a mandatory Process. This process looks in to the amounts
processed for each of the employees and their respective Payment
methods. It then divides the money to be paid on to their Payment
methods. So for an example, Joe's salary for his month is $5000, and he
has two preferred payment methods, 20% as a check and rest of the
money in a Bank Account. After running Prepayments, the system will
know that it has to transfer $1600 in to his bank account and it has to give
$400 as a check to Joe. To run the process, we need to go to single Request
and put the process name as PrePayments. See Figure 5.24 – PrePayments
Parameters.
If the system does not find details about the Personal Payment methods,
then it will default the payment with the Default payment method used
with the payroll. Usually the default payment method is Check.
Magnetic Transfer
As we know, this is the process for direct deposits. UK localization supports
the BACS and North American Localization support NACHA, similarly all
localization follow a specific payment gateway. This process generates an
output file that can be sent to the Bank and the treasury.
Once the Process is run, we can select the output of the Process and verify
the details. We can then send the Output report to the Bank via
established Preferred Electronic Media.
Totals Only
NACHA Report
Choose the NACHA process that was run with the table above.
Archiver
Now, as the Payments are about to happen through the Direct Deposits,
which is Bank's headache now, we will proceed to the next action item,
Payroll Archive. This Process generates a pay slip kind of report. This is an
optional step for most of the localizations.
Here, we must have the start check number with us. We can get that from
the Printer. All we need is the number of the first check leaf which is going
to be printed.
We will have to run this Process twice, once for the Normal Payroll check,
and again for the Third party Garnishments.
Deposit Advice
The Deposit Advice actually prints the Pay slips that we might send to the
Employees. This Process goes through the Statements of Earning and gets
us the details of the Earning and Deductions in a more understandable
format as a report.
Costing
As Part of this process, Payroll Engine divides the costs according to the
Cost Allocation Flex Field, keeping Overrides in consideration. This Process
assures that the cost paid for labour is accurately being captured. If no
Costing Information is found on any particular entry, the cost goes to the
Suspense Account.
Transfer to GL
This Process is the one that takes care of the migration of cost to the
General Ledgers. The Payroll Costs are migrated to the General Ledger and
then it gets added against the actual financial accounts.
Payroll Activity Report: This report is run just after the Payroll Process
and before the Prepayments. With this report we can view the status of
the Payroll with details like, how many employees are processed, what is
the total Earnings, Total Deductions, Total Taxes etc. It can be processed
with the following details:
Third Party Payment Register Report: This is more or less the same as
the Payment Register Report. However this tracks the Third Party
Payments only.
US Gross to Net Summary: With this report, we can see the summation of
Salary information of the employees with Gross Earnings, Net Earnings
and deductions.
CORRECTING
PAYROLL
CORRECTIONS
There will be moments, where we have finished the Payroll run and Pre-
Payments. We processed some report and figured out that, there is some
issue with a set of Assignments. The same thing can even happen just after
the Payroll Run, or in some cases, after Transfer to GL. Now how do we
handle the situation? Is there any way we can correct the data. Yes. There
are three different Processes.
Rollback
Retry
Reversal
Rollback
This is the most commonly used feature. We can use this to un-process the
Payroll. However using a Rollback removes the entire history of the data.
Let's use Joe's example. All of a sudden we realize that Joe has been paid
$200 extra this time. Now we are at the last stage of our post processing.
We are running costing now. How do we fix the Issue?
We will Rollback the Payroll for Joe. We will Rollback the Costing for Joe
first. Then the Check writer job, then the NACHA / BACS, then the
PrePayments and finally we will rollback his payroll. We will fix his
elements, and rerun the entire set of jobs again in the actual order only for
Joe.
Reversal
Reversal is chosen in cases when all the processes are already complete,
and we see an issue with an assignment. This will reverse all the Processes
this far for the particular Run for the particular assignment.
Adjusting Balances
When Balances are calculated wrong, or we have done some manual
workaround and want the Balance to be updated for the same, we can opt
for Balance adjustments.
To view Balance of any particular assignment, we can go to View ->
Assignment Process Results -> Employee Assignment Processes
To Adjust Balances, we can go to the Assignment Record of the Employee,
Others->Adjust Balance.
QUICK PAY
QuickPay is the process that can be used to process Payroll and
Prepayments for one Individual assignment at a time. So this is the
Assignment level version of the Payroll Process. Although all the other Post
Processing except the Prepayments has to be done separately, but this
tool, can help us to do small changes on the assignments and rerun the
payroll for them, after a successful rollback. This can also be used as a
testing tool. We can just run a quick pay and see the SOE. Once our
validation is done, just roll back the Quick pay. It’s so simple.
RETRO PAY
Retro Pay are one of the Important tools with which we can fix something
that has happened in Past. For an example, salary of an employee is
increased to $300 as of March, effective from the Month of January. Now,
we need to make sure that the Amount of money accumulated since
January to March to be paid as part of March Payroll; Similarly, if the Rate
of Medical Insurance has been changed from $450 to $550 as of March,
effective from the month of January. Here we need to adjust the $100/
month for three months. How do we do that?
There is a process called the Retro Pay that can solve the problem. There
are three types of Retro pays, however not all of them are available in a
particular localization.
Retro Pay by Aggregate
Retro Pay by Run
Retro Pay by Element
Even though the concept looks simple, it’s not. We must think about the
deductions and taxes in place. If the salary increases by $100, my system
will need the entire calculation to be done once again. Not only that, even
my balances will need updates. Oracle Payroll takes care of all that. Let's
discuss how to achieve the same.
Retro by Aggegate
We can use this, if we do not want to see the way Payroll derives the
amount. If we take Joe's example forward, we will never see how payroll
came up with that $300 for the three Months, if we use Retro Pay by
Aggregate. It’s abstracted. Here it was simple to track, as its just $100/
month. But in Complex Calculations it will be completely abstract.
Set up:
Complete the Salary level changes.
First thing is to create/ update the element entries with the new value.
Now, create the retro pay elements with the following details.
Pick an appropriate classification. Should not be Information.
Type should be Non-Recurring
Should have three input values - Pay Value, Start Date, End Date
Create an Assignment set with the Impacted assignments
Link the element to the assignment set
Create a Retro pay set
Process Retro pay request.
Retro by Run
This one is similar to "Retro Pay by Aggregate". Just that it gives us the
clear picture without any abstraction. It allows us to see how backdated
changes are distributed across Individual processes. Here the system uses
the old information and also calculates the difference using the new
information and finally updates the system.
Set up:
Follow everything that's there in the "Retro Pay by Aggregate". However
with the following changes on the element:
Multiple Entries allowed flag should be checked
It just needs one Input Value "Pay Value". No Start date or end date would
be required.
Retro by Element
This option is chosen when we want the retro to be applied for one single
Element without recalculating the others. This is highly specific to Elements
and does not happen a lot often. Imagine just a Post Tax Bonus was
updated wrong in Joe's record. To correct situations like that, we might
need Retro Pay by Element
Set up:
Update the element entries with the desired value.
Create an assignment set
Create an Element Set of type Run Set
Process Retro Pay request
Retro by Set
This is not required in Retro Pay by Element. This is used only in the other
two cases.
Navigation: View (M) -> Request (M) ->Submit a new request -> single
request
SUMMARY
Payroll does not deal with a lot of tables, in comparison with other
modules like Benefits / Core-HR. So the idea was to go through the
functional set ups first and then look at the technical aspects, and peep
through the tables.
PAY_ELEMENT_TYPES_F: No need to say, that this is a date track enabled
table. This table stores the details about all the elements in the system.
The Primary key is ELEMENT_TYPE_ID and the two date fields. This is
usually used to get the name of the element, as ELEMENT_TYPE_ID is used
in a lot of places to refer to the element.
So these were the important tables in Payroll. However here is a list of few
others, which are use very frequently.
In the table below, if the Date tracked