Retrospective Payroll Processing in Oracle Payroll

Client and Business Case - A global manufacturing company wanted to automate the retrospective pay
calculation in Oracle Payroll for critical payroll processes like retrospective pay awards, temporary
promotions, secondments, retro pay for part timers etc.

Solution - Oracle Payroll allows you to make back pay adjustments through the RetroPay process. Key
points include:
–Inputs to pay that were originally correct have now changed retroactively.
–You receive late notifications of promotions.
–You can run the RetroPay process from the submit Requests window.

How Retro Pay Works - Oracle Payroll now rolls back and reprocesses all the payrolls for the
assignment set from the date you specified. The system compares the old balance values with the new
ones and creates entry values for the RetroPay elements based on the difference. These entries are
processed for the assignments in the subsequent payroll run for your current period.
No changes are made to your audited payroll data.

Configuration - All payroll elements configured during the implementation are assessed for whether
they are “retropay’able” or not. Usually all regular payments and allowances are considered eligible
for retropay. Voluntary deductions and some non-recurring payments are not normally eligible but can
be made so if required.

For each eligible element a corresponding “Retropay Element” is also configured. These elements will
hold the results of any pay adjustments calculated by the “Retropay” process.

A number of Retropay element “Groups” may also be configured. I.e. There will almost certainly be a
group which includes all eligible elements but there could be another group which is just for bonus
related adjustments. This gives flexibility when running retropay to restrict the process to just those
items where you are notified that a change is due.

Operational steps - Immediately prior to every payroll calculation the “Retropay Notifications” report
should be run. This lists any system changes that indicate a retrospective adjustment may be due. E.g.
One or more employees may have had a late or corrected entry of a new allowance, change of Grade,
change of Grade Step placement etc.

Using the “Retropay Notifications” report you can establish the assignments, period and elements for
which retrospection is needed.

If a retrospective calculation is needed, then run the standard “Retropay by Element” process.
Input parameters are :-
Assignment set – if you want to restrict the run to selected assignments
Retropay element group – if you want to restrict the run to selected elements
Start date – this is the earliest date you want the system to recalculate from
End date – this is the latest date you want the system to recalculate up to

The process recalculates for the assignments, period and elements indicated. Any resulting
adjustments are attributed to each relevant retropay element and entered into the current pay period
for processing in the full payroll gross to nett run. In this way the results of the previous period(s)
payrolls are not amended. The adjustments will only affect values and be costed in the current payroll
period.

How the notification process works - During the implementation “Dynamic Triggers” will be
configured. These identify when a change has occurred in the database which could mean an
adjustment to pay is needed. E.g. There will be dynamic triggers to detect changes in Grade, Spinal
Point, Standard Hours, Contract Type, FTE, Allowances etc. The “Retrospective Notifications” process
uses these triggers to notify you of the items which need retrospective calculation.

How the calculation process works - Assume a retropay run is for March and April with the
adjustments to be paid in May. The system retrieves all balances for the assignment as at end of
February payroll and notionally recalculates all eligible elements for March and April. These notional
element results are compared by the system with the original actual results in March and April for the
same elements. Any differences are automatically entered onto the relevant retropay element in May.
The end result will be exactly the same as if a payroll clerk had manually calculated the adjustments
needed and manually keyed them onto adjustment elements in the current pay period.

Optimising use of the Retropay functionality - It can be seen that as the exact same system process is
used to recalculate as was used in the original payroll calculation, then elements which have derived
values will automatically be correctly recalculated by the retropay process.

e.g.
Allowance X has a formula attached which specifies that the allowance value is 10% of basic salary plus
2% of all contractual allowances. If basic salary and all contractual allowances are part of the retropay
set then Allowance X will also be recalculated.

If the allowance has no formula and is populated by a user keying in an arbitrary amount then it will
not be affected by retropay on other elements. The only way this would generate a retropay
adjustment would be if the original allowance entry were changed, i.e. different start/end date or
value.

During the implementation, due consideration should be given to how elements are configured to
enable maximum use of the retropay functionality.

Pay Awards - When revising the values on a pay scale due to a pay award it will be essential to
datetrack to the correct effective date when the new values come/came into force. You can apply the
pay award in advance of the effective date or after it. If it is applied late then restrospective
calculations will be due and the operational steps outlined above will need to be followed. If you have
applied the pay award in advance then the old rates will be applied until the effective date of the pay
award when the new rates will automatically be applied. If this occurs mid-period then the calculated
values will be pro-rated accordingly.

Temporary Promotions, Secondments etc. - Any employee who is in a role which is not their usual
substantive assignment will still be eligible for retropay adjustments on their substantive assignment
for the period before their Temporary Promotion or Secondment started, and also on their extra
assignment for the Promotion or Secondment.

Part Timers - It can be seen that as the exact same system process is used to recalculate as was used
in the original payroll calculation, then elements which are pro-rated according to a part-timers FTE
will still be pro-rated in exactly the same way.

Overlapping Retrospective Runs - It is possible that having run Retropay in June to recalculate March-
May, you then have reason to run it in September for April-August. This is perfectly legitimate and the
system will correctly process the second retropay run which overlaps the time period covered by the
first run.

Posted by Seetharaman Radhakrishnan

Labels: Oracle Payroll, Real World Cases

2 comments:
 payroll information said...

Open enrollment is a time every year when employers offer you a chance to either enroll
in some benefits, or make some changes to your current benefits. These benefits are
usually health, disability, vision, and life insurance plans.

Posting Payroll Costs to General Ledger

Client and Business Case - A Banking Client who had implemented a full installation of HR (including
payroll processing) wanted to configure the system such that the payroll costs are posted periodically
to the General Ledger.

High Level Solution - There is a Key FlexField (KFF) in Oracle Payroll called “Cost Allocation
Flexfield”. Like any other KFF it must be setup to contain segments that together represent the full
analysis code to be used in posting payroll costs to General Ledger (GL).

This KFF also uses Qualifiers to determine where each segment is made accessible to the user.
There are 5 different places in the standard Oracle HRMS application where Costing information can be
configured by the user. This is true for any Oracle HRMS customer.

The 5 places are :-

1. Payroll – Each active payroll must have segments setup for Costing and Suspense. This is normally
maintained by technical Payroll Sysadmin staff.

Navigation = HR Responsibility > Payroll > Description:

2. Element Link – All Elements which pay/deduct money must have at least one link created. The
number of links for each element and their complexity is dependent on how Finance requires the
postings in GL. Each link has 2 costing flexfields, one for the Debit and one for the Credit entry in GL.
Each of these 2 records may need one or more of the Cost Allocation KFF segments populated. This is
normally maintained by technical Payroll Sysadmin staff.

Navigation = HR Responsibility > Total Compensation > Basic > Link:

3. Organization – Each Organization may have a single costing record populated with one or more
segments. This works most effectively where each HR Org can be directly related to a particular GL
Cost Centre. This is normally maintained by HR Sysadmin staff.

Navigation = HR Responsibility >Work Structures > Organization> Description:

4. Employee Assignment – Each Employee Assignment may have multiple costing records populated with
one or more segments. This is where split % costing’s applied. This is normally maintained by HR
Operational staff.
Navigation = HR Responsibility >People> Enter and Maintain > Assignment > Salary Information > Others
> Costing:

5. Employee Assignment Element Entry (sometimes called Element Entry Overrides) – Each element
entry may have a single costing record populated with one or more segments. e.g. Time entries from
Timesheets. This is normally entered by Payroll Operational staff.
Navigation = HR Responsibility >People> Enter and Maintain > Assignment > Salary Information >
Entries:

6. Final Setup
There is one final setup step to map the CostAllocation Flexfield segments to the corresponding
segments in the GL Chart of Accounts KFF.

High Level Costing Process:

There are two report processes available.

1. Cost Breakdown Report for Costing Run
2. Cost Breakdown Report for Date Range
These reports simply select a set of payroll calculation results according to run parameters and report
on them.

There is one process for collecting Payroll costs.

3. Costing - This process collects a set of payroll calculation results, attributes them to the full GL
analysis code and creates an output file in the correct format for posting to GL. The file can be viewed
via the normal view process results function.

There is one process for transferring the costs.

4. Transfer to GL - This process takes the results file and moves it to a designated area on the file
server from where it can be uploaded to GL under the control of an authorised GL user.

There is one process for retrospective costing adjustments.

5. RetroCosting Process - This process recalculates costs and compares the results with the original
costing process results to identify and differences.
Posted by Seetharaman Radhakrishnan
Labels: Oracle HRMS, Real World Cases

4 comments:

Anonymous said...

Who knows where to download XRumer 5.0 Palladium?

Help, please. All recommend this program to effectively advertise on the Internet, this is
the best program!

November 22, 2009 at 9:27 AM

businesses payroll service said...

Hey I have got y own software with the help of businesses payroll service

As they provide the best software you all can check this out.

Understanding Mass Additions

Client and Business Case - One of my clients (Oil and Gas - Retail) who implemented Oracle Assets
needed a simpler way to:
1. Convert Fixed Assets data from legacy system for Go-Live
2. Add new assets or cost adjustments from other (Oracle or Non Oracle) systems to the Oracle Assets
system automatically without reentering the data

Mass Additions - The Mass Additions process lets you:

1. Load (convert) assets automatically from an external source. You can review new mass addition lines
created from external sources before posting them to Oracle Assets. You can also delete unwanted
mass addition lines to clean up the system.
2. You can also load (convert) asset data into Oracle Assets using the Create Assets Feature in the
Applications Desktop Integrator (ADI), which allows you to import data from an Excel spreadsheet.
3. Maintian Assets data - The mass additions process lets you periodically add new assets or cost
adjustments from other systems (like Oracle AP, Oracle Projects ) to your Asset system automatically
without reentering the data.

Mass Additions Features:

1. Review Mass Additions - Clients can review newly created mass addition lines for entering additional
mass addition source, descriptive, and depreciation information, assign the mass addition to one or
more distributions, or change existing distributions. Once the mass addition is ready to become an
asset, change the queue to POST. On Posting Mass to FA this mass addition becomes an asset. The Mass
Additions post program defaults depreciation rules from the asset category, book, and date placed in
service which can be overridden

2. Add to Existing Asset - Clients can add a mass addition line to an existing asset as a cost adjustment.
Choose whether to change the category and description of the existing asset
to those of the mass addition and whether to amortize or expense the cost adjustment. When one
changes the queue name to POST for a mass addition line which is being added to an existing asset, the
queue name is changed to COST ADJUSTMENT. This makes it easy to differentiate between adding a
new asset or adjusting an existing asset.

3. Merge Mass Additions - Clients can merge separate mass addition lines into a single mass addition
line with a single cost. The mass addition line becomes a single asset when one
Posts Mass Additions. One can only merge mass additions in the NEW, ON HOLD, or user–defined hold
queues. Choose whether to sum the number of units. When one posts the merged line, the asset cost is
the total merged cost.

4. Split Mass Additions - Clients can split a mass addition line with multiple units into several single unit
lines. The original line is put in the SPLIT queue as an audit trail of the split. The resulting split mass
additions appear with one unit each, and with the same existing information from the source system.
Each split child is now in the ON HOLD queue which can be reviewed to become a separate asset.

5. Post Mass Additions to FA - Use the Post Mass Additions to FA program to create assets from mass
addition lines in the POST queue using the data entered in the Mass Additions window. It also adds mass
additions in the COST ADJUSTMENT queue to existing assets.

6. Clean Up Mass Additions -The Delete Mass Additions program removes mass addition lines in the
following queues:
• Mass additions in the SPLIT queue for which child mass addition lines created by the split has already
been posted.
• Mass additions in the POSTED queue that have already become assets
• Mass additions in the DELETE queue.

7. Create Mass Additions from Invoice Distributions in Payables - Mass Additions adds assets and cost
adjustments directly into FA from invoice information in Payables. The Create Mass Additions for
Oracle Assets process sends valid invoice line distributions and associated discounts from Payables to an
interface table in FA. One reviews them in and determines whether to create assets from the lines.

Pre-requisites steps for seemless Mass Additions Process:

1. Register the Accounts - Account Type Must Be Asset: Register the clearing accounts to be used as
Asset accounts. The create mass additions process selects Payables invoice line distributions charged to
clearing accounts with the type of Asset.
Define Valid Clearing Accounts in FA: For each asset category in FA for which invoice line distributions
are to be imported from Payables, define valid asset clearing and construction–in–process clearing
accounts. These accounts must be of type Asset. The create mass additions
process only imports lines charged to accounts that are already set up in asset categories.

2. Define Items with Asset Categories - Clients can define a default asset category for an item in
Purchasing or Inventory. Then when one purchases and pays for one of these items using
Purchasing and Payables, the mass additions process defaults this asset category. If mass addition lines
for an item are to appear in FA with an asset category, Cleints must:
• Define a default asset category for an item in the Item window in Purchasing or Inventory
• Create a purchase order for that item
• Receive the item in either Purchasing or Inventory
• Enter an invoice in Payables and match it to the outstanding purchase order
• Approve the invoice and Post the invoice to GL
After cleint runs create mass additions, the mass addition line appears with the asset category
specified for the item.

3. Enter Invoices in Payables - While entering a new invoice in AP, charge the distribution to a clearing
account that is already assigned to an asset category. The line amount can be either positive or
negative.

4. Units - If one enters a PO with multiple units and match it completely to an invoice in payables, the
Create Mass Additions process uses the number of units specified by the original PO for the mass
addition line. Mass addition lines created from invoices entered directly into AP without matching to a
PO default to one unit. After one approves and posts the invoice in AP, run the Create Mass Additions
process to send valid invoice line distributions to FA.

5. Handle Returns: Clients can easily process and track returns using mass additions.

6. Conditions For Asset / Expensed Invoice Line Distributions To Be Imported - For the mass additions
create process to import an invoice line distribution to FA, these specific conditions must be met:
• The line is charged to an account set up as an Asset account. (Expense in case of expense asset)
• The account is set up for an existing asset category as either the asset clearing account or the CIP
clearing account
• The Track As Asset check box is checked. (It is automatically checked if the account is an Asset
account)
• The invoice is approved and The invoice line distribution is posted to Oracle GL from AP
• The GL date on the invoice line distribution is on or before the date specified for the create program
• AP must be tied to the same GL SOB as the corporate book for which one want to create mass
additions

7. Running the Create Mass Additions For FA Program in Payables - Clients can run Create Mass
Additions for FA as many times as during a period. Each time it sends potential asset invoice line
distributions to FA. AP ensures that it does not bring over the same line twice.

Posted by Seetharaman Radhakrishnan

Labels: Oracle Assets, Real World Cases

2 comments:

first time blogger said...

Hi

It was a good article on Oracle Fixed Assets. I am having a scenario where in there is a
need to do change the life of assets from 5 years to 8 years and a consequential Change in
Depreciation Rate from 20% to 12.5%

Is there any way to do the same with retrospective effect ?

Thanks in Advance for your inputs on the above

 Ram Ganesh.B

How to create Custom Address Styles in Oracle Apps

Client – Clients who are having Global Rollouts and need for multiple address styles.

Business Case – Need to add country specific address style formats for addresses information which are
stored in the different core modules of Oracle Apps including Receivables (for Customer and Remit to
Addresses), Payables (Supplier and Payment Addresses), Banks (Bank Branch addresses)

Out of the box address styles - Oracle Applications provides one default and five predefined address
styles. These address styles cover the basic entry requirements of many countries. The different
address styles provided out of the box are:
• Default,
• Japanese,
• Northern European and Southern European,
• South American,
• United Kingdom/Asia/Australasia,
• United States

How to add a new Address Style -

Let us say the client has a Business requirement to add a new address style for ‘Canada’. The following
high level steps can be followed to define this new ‘Canada’ address style.

1. Choose address style database columns for your ‘Canada’ address style.

First you need to decide (as per client’s requirements) which columns from the database you are going
to use and how you are going to order them. All the seeded address styles include the following
database columns and some additional columns.

• Bank Addresses
• AP_BANK_BRANCHES.ADDRESS_LINE1
• AP_BANK_BRANCHES.CITY
• AP_BANK_BRANCHES.STATE
• AP_BANK_BRANCHES.ZIP

• Customer and Remit-To Addresses

• HZ_LOCATIONS.ADDRESS1
• HZ_LOCATIONS.CITY
• HZ_LOCATIONS.POSTAL_CODE
• HZ_LOCATIONS.STATE

• Supplier Addresses
• PO_VENDOR_SITES.ADDRESS_LINE1
• PO_VENDOR_SITES.CITY
• PO_VENDOR_SITES.STATE
• PO_VENDOR_SITES.ZIP

• Payment Addresses
• AP_CHECKS.ADDRESS_LINE1
• AP_CHECKS.CITY
• AP_CHECKS.STATE
• AP_CHECKS.ZIP

For example, in the Japanese address style, the address element called Province maps onto the STATE
database column and that in the United Kingdom/Africa/Australasia address style the address element
called County also maps onto the STATE database column. Oracle recommends that all custom address
styles also include at least the above database columns because these address columns are used
extensively throughout Oracle for printing and displaying.
Note: Most reports do not display the PROVINCE, COUNTY, or ADDRESS4/ADDRESS_LINE4 database
columns for addresses.

The following screenshot gives you an idea of how to setup database columns for your ‘Canada’ address
style:

2. Define ’Canada’ address style to database columns using Define Descriptive Flexfield Segments
Window.

Next step is to create a new context value for each of the descriptive flexfields.

Payables – Bank Address:

Payables – Site Address:

Receivables – Address:

Receivables - Remit Address Information:

3. Add address style to the address style lookup:

Add the ‘Canada’ address style name to the Address Style Special lookup so that you will be able to
assign the style to countries and territories.

To add a new style to the address style lookup:

A. Using the Application Developer responsibility, navigate to Applications > Lookups > Application
Object Library.
B. Query the ADDRESS_STYLE lookup.
Receivables displays all of the address styles used by Flexible Addresses.
C. Add your new ‘Canada’ address style, as follows:

D. Enable this style by checking the Enabled check box.

4. Assign the address style to the appropriate country using the Countries and Territories window.

· Using Receivable or Payables Superuser responsibility navigate to Setup > System > Countries. · Query
for Country = ‘Canada’
· Attach the ‘Canada’ Address Style created to the Canada Country
· Save the record
5. This completes the setup for the new ‘Canada’ address style, now you can use this new address style
while adding new Canada Customers, Suppliers etc. See screenshot below on how the Customer Form
displays the new ‘Canada’ address style:

Click on the Address filed and you will get a popup window with the new ‘Canada’ address style:

Posted by Seetharaman Radhakrishnan

The requirement from client to change the old leave accrual plan to a
new plan.
For grades G1 and G2, leave per year is 24 days and they are
increasing it to 28 days. we can simply change it in the formula and
the plans and elements are all saved like “Accrual Plan 24”. This has
to be changed to “Accrual Plan 28”. so we created a new accrual plan
its working correctly
The issue what we are facing is when we end date the accrual plan 24
and attaching the accrual plan 28, the leave balance is resetting to 0.
we need to add the older leave balance with the new one.
how it can be done?

With the current PTO

functionality, there is no mechanism to transfer accruals from one plan
to
another. So if an employee leaves Plan A in the middle of the year
and joins
Plan B, they lose all the year’s accruals for plan A. To correct
the accrual balance of Plan B, an adjustment element must be
created and added to the NCR (Net Calculation Rules) on the Accrual
Plan. Manual process:
• Create your new plan and elements for that plan (Navigation: Total
Compensation > Basic >Accrual Plans)
• End date the original plan and attach the new plan using the Element
Entries window
• If there is a balance to be transferred, then the New plan should
have an
element to adjust accruals:
a) Create an element: for instance, “Adjust Vacation”. Define
link information.
b) Attach element to the new plan using Net Calculation rules
window (net effect = ‘Add’)
Navigation: Total Compensation > Basic > .Accrual
Plans > Net Calculation Rules
• Get the net entitlement amount as of end date of original plan (use
View
Accruals window – Navigation: Fastpath > Accruals)
• Adjust the balance by attaching the other net contribution element
(element
created on previous step)
Element Entries window – Navigation: People > Enter and
Maintain > Assignment > Element Entries)