Random Deductions
Subject: [orahrms-l] Random Deductions
From: "Phillips, Laura" LPhillips@jwrinc.com
Date: Fri, 2 Apr 1999 15:45:11 -0600
In our company we have deductions called Disability Fund and Benevolent
Fund. Our Union employees can be signed up for these deductions so that
in the event that they die or are disabled their fellow employees can be
cut $25.00 and the total amount of money will be given to them or to
their family. My problem is this - I want to attach these deductions to
many, many, many employees but I can't set frequency rules since these
events happen randomly. I sure don't want to have to put these in as
special inputs every time I need to deduct (which is more often then you
would think). All I want is for the deductions to be attached to the
employees and then sit quietly until I ask for them to be deducted. Any
suggestions?
Thanks!
Laura Phillips
Alabama
Subject: RE: [orahrms-l] Random Deductions
From: "Venkatesh, Masoor" mVenkate@wssc.dst.md.us
Date: Fri, 2 Apr 1999 17:15:22 -0500
Laura: You need to use the BEE process. Just get your technical folks to
create a batch load process for BEE with all the employees who need these
deductions, and then load it whenever you need to. Hope this helps.
Regards,
Tony Venkatesh
(301) 206-8452
(703) 793-0847
tonyv@mcsgroups.com
Subject: RE: [orahrms-l] Random Deductions
From: "Mark F. West" mwest@estee.com
Date: Fri, 2 Apr 1999 17:35:22 -0500
Laura,
Perhaps your skip rule could reference a Global Value. It could be a simple
Yes/No switch for each of your funds.
Mark F. West
Estee Lauder
Hawaii SDI problem
Subject: [orahrms-l] Hawaii SDI problems?
From: "Smith, Amy" Amy.Smith@fmr.com
Date: Tue, 11 May 1999 13:16:57 -0400
Is anyone out there still having problems with
Hawaii SDI even after applying mandatory patch
860231? It is coming out for us now, but not the
correct amount. Thanks!
Amy Smith
Fidelity Employer Services
Application Support - Oracle HRMS
Email: amy.smith@fmr.com
TAMS/O and PTO Accruals
Subject: [orahrms-l] TAMS/O and PTO Accruals
From: "William C.Stratton" bstratton@sprynet.com
Date: Wed, 12 May 1999 09:28:46 -0400
We are currently implementing Oracle HR/Payroll along with TAMS/O and have run into a situation that could use some outside opinions. The client has a very complex set of PTO (Paid Time Off) plans that do not fit very well into the standard structure that Oracle offers. Therefore, we will be designing our own PTO accrual and tracking subsystem. An employee can have multiple "banks" or available hours that can be used to pay for time off. They have discrete rules that dictate when employees call in sick, for example, the hours must first be deducted from the Swing Holiday bank, then from the Furlough Time bank, then from their Compensatory Time bank, and then to non paid time. These rules could be incorporated into the Fast Formula for Sick Time, but we run into a problem with reconciling the timecard in TAMS/O with the actual hours paid in Oracle Payroll. Some here feel that the timecard in TAMS/O is the prevailing legal document and must match what is paid in Oracle. The problem is that it will take some development effort to allow TAMS/O to check all of the available banks before generating the correct timecard.
What's the feeling in the Payroll world about the timecard being the legal record of time paid? Does anyone else allow the payroll process override timecard entries based on some business rules? And if so, have you run into problems when grievances are filed and you must go back and reconstruct pay? By the way, this site has over 40 unions represented.
Thanks in advance for your input into this discussion.
Bill Stratton
BOSS Corporation
Better Organization Service Solutions
6455 East Johns Crossing, Suite 404
Duluth, GA 30097
770-622-5500 (V) 770-622-5400 (F)
http://www.bosscorporation.com
Subject: RE: [orahrms-l] TAMS/O and PTO Accruals
From: Pat Keeley PKeeley@amctheatres.com
Date: Wed, 12 May 1999 09:08:06 -0500
Bill, my experience in payroll and with federal wage and hour (even most
unions, including Teamsters and Retail Clerks) has been that the time card
is the legal document for reporting hours WORKED.
In this case, where you are reporting absence hours (that may be paid or
unpaid) it would be well within the realms of legality to report 40 hours of
sick and be paid 5 hours sick time or no hours of sick time. Time cards are
often used to report unpaid absences and they are a great way to track that
information, but it is not necessary to pay everything that is entered on a
timecard.
Note: You should never try this with overtime!
Hope this helps.
Pat Keeley
Subject: Re: [orahrms-l] TAMS/O and PTO Accruals
From: "William C.Stratton" bstratton@sprynet.com
Date: Wed, 12 May 1999 12:53:04 -0400
Thanks for the responses so far. After sharing them with the folks here,
there is still a concern when they use the retro option within TAMS/O. Has
anyone had the issue where Oracle Payroll has made adjustments to a timecard
during the payrun based on a business rule, then sometime in the future,
used the retro option in TAMS/O to regenerate hours that were not eventually
paid? (confusing enough?).
Subject: Re: [orahrms-l] TAMS/O and PTO Accruals
From: "Bob Cody" Bob_Cody@norstanconsult.com
Date: Wed, 12 May 1999 18:10:49 -0400
Bill,
The TAMS/O system does retro processing by using the date-track
functionality
of the Timecard. When a change is entered on an old timecard a newly
effective
retro record is created.
When the retro data is transferred to PayMIX the new record and old record
are compared.
The retro transfer of hours related data does one of the following things
based on
that comparison:
* Creates an adjustment negative or positive for the change to the pay
element.
(ex: You entered 8 hrs. PTO last month, corrected it this month
to 4 hrs. The transfer moves -4 hrs. to PayMIX
representing the delta of the entries)
* Backs out the old entry by passing a negative entry
(ex: You entered 8 hrs. PTO last month, and deleted it
this month
The transfer moves -8 hrs. to PayMIX to
negate the original entry)
* Backs out the old entry by passing a negative entry, and send a new
entry
(ex: You entered 8 hrs. PTO last month, and replaced
it this month with a new cost center
The transfer moves -8 hrs. to PayMIX to
negate the original entry
and moves 8 hrs. to PayMIX to represent the
newly costed entry)
* Creates an entirely new entry
(ex: You entered 8 hrs. PTO that somebody forgot to put in last
month
The transfer moves 8 hrs. to PayMIX to represent the new
entry)
I think if your PTO balances scheme is coded to increment the appropriate
banks
when negative amounts are passed into payroll, you should be ok.
The nice part about the timecard is that it allows you to datetrack to any
point in time and view what
entries were effective on that date. The retro transfer process adjusts pay
simply by sending
positive or negative hours amounts to PayMIX representing these changes.
These new entries
then adjust the employee's paycheck for the period being processed.
Bob Cody
bob_cody@norstanconsult.com
Subject: Re: [orahrms-l] TAMS/O and PTO Accruals
From: "William C.Stratton" bstratton@sprynet.com
Date: Thu, 13 May 1999 08:34:30 -0400
Bob,
Thanks for your response, but you just outlined the problem we will have.
When TAMS/O only looks at PayMix, it will assume that we paid the 8 hours of
PTO in your example. During the payrun, the Fast Formula might adjust these
hours to 4 hours PTO and 4 hours non-paid. This adjustment is never updated
back in PayMix.
Therefore, TAMS/O might send a negative 8 hours of PTO to correct a
miscoded timecard, and the pay process would ADD 8 hours back into his bank.
In reality, he should only get 4 hours, since that is what he eventually
received from the Fast Formula adjustment.
From: Scott Madole smadole@solbourne.com
To: 'William C.Stratton' bstratton@sprynet.com
Date: Thursday, May 13, 1999 8:31 AM
We are working on a public sector site that has 5 unions. We to are
implementing TAMS/O (OTM). We are having to adjust the hours after they are
entered on the time card, however, legal document issue is not an issue
here. We are adjusting the timecard hours, due to several factors, after the
time is transferred to the Payroll system. Therefore what is actually paid
is not necesarily a reflection of the timecard. Our way of getting around
this is a report. We are creating a report to be run prior to the time card
hours being transferred to the Payroll system. The report will contain the
same logic that our fast formulas and custom payroll code will, therefore
the report will provide the organization with a valid way of auditing the
timecard data.
I don't know if this helps you,
Scott Madole
smadole@solbourne.com
Subject: Re: [orahrms-l] TAMS/O and PTO Accruals
From: "William C.Stratton" bstratton@sprynet.com
Date: Thu, 13 May 1999 08:58:22 -0400
Scott,
I think you hit the nail right on the head!!! It would be easier to add a
post process to the timecards after they have been transferred by TAMS/O,
than modifying TAMS/O itself. If the retro process looks at PayMix, as Bob
points out, then this would solve the retro problem as well.
Thanks for your timely input. That's what I like about this job. You learn
different ways to solve complex problems every day.
Deduction against Prepaid Health Insurance
Subject: [orahrms-l] Element entry dates and coverage dates for insurance
From: "Mavis O'Connor" moconnor@IR.ColoState.EDU
Date: Wed, 12 May 1999 13:29:37 -0600 (MDT)
We'd like some feedback from HRMS users regarding how you
are managing prepaid deductions for health insurance, etc.
For some groups of employees (monthly payroll) the health
insurance premium is deducted the month prior, so if your
coverage begins on February 1, 1999 the premium is deducted
on the January 31 paycheck. For other groups of employees
the insurance premiums are deducted in the current month
so a deduction occurs on January 31 for coverage that actually
began on January 1.
For our prepaid elements in particular, it seems confusing to
look at the element entries start/stop dates and get an accurate
picture of what the coverage dates were for the various plans.
Similarly, when there is a rate increase or a change in plans,
what's the best strategy to use for start/end dates for these
prepaid insurances and still be sure that we are deducting the
right amount from the paycheck prior to the coverage starting
the following month?
PTO accruals
Subject: [orahrms-l] PTO Accruals
From: Ellen Young EYoung@FAMILYDOLLAR.com
Date: Fri, 21 May 1999 15:03:13 -0400
I understand that in Release 10.7 PTO accruals are defined on a calendar
year basis. I can't find anything in Release 11 product upgrade notes that
addresses a change in this functionality. How are companies that do not use
a standard calendar year for vacation accruals handling this? We don't want
to do any customization as we will probably upgrading to Release 11 in the
next 6-8 months.
Ellen L. Young
Oracle Applications Project Mgr.
Family Dollar Stores, Inc.
704-814-3365
eyoung@familydollar.com
Subject: RE: [orahrms-l] PTO Accruals
From: Pat Keeley PKeeley@amctheatres.com
Date: Fri, 21 May 1999 14:18:09 -0500
Ellen, up to release 11.2 there was no change in the standard functionality
for accruals. Sorry, I can't give you better news. This is an issue for
many clients.
Pat Keeley
ARIS Corporation
Subject: [orahrms-l] PTO Accrual
From: Ellen Young EYoung@FAMILYDOLLAR.com
Date: Tue, 25 May 1999 11:31:36 -0400
We are having an issue with the calculation (or lack thereof) of PTO
(vacation). We went live January 1on 10.7 NCA. We set up the recurring
element for vacation on January 1. We then set up a non-recurring element
for vacation time on January 10 and loaded the balances into that element
(both dates were in the same payroll period). The system is not calculating
the balance for employees who have taken vacation since January 1; employees
who take vacation in 1999 are showing up on the SOE, but the vacation time
taken is not being subtracted from the intial balance; everything is going
negative. We have found that if we datetrack to January 14 (the first day of
the next pay period) and reset up the non-recurring element to that date
(and put the initial balance in that element), the system calculates
correctly. However we have over 10,000 employees, so this manual workaround
is not feasible. Any ideas on why this is working this way, and what we can
do to correct it automatically? Will running the PTO Carryover process buy
us anything? We are on a May 1 - April 30 vacation year, so we need to zero
out the previous vacation balance anyway.
HELP!!
Ellen L. Young
Oracle Applications Project Mgr.
Family Dollar Stores, Inc.
704-814-3365
eyoung@familydollar.com
Subject: Re: [orahrms-l] PTO Accrual
From: Kit Stephenson kstephen@earthlink.net
Date: Fri, 28 May 1999 09:11:01 -0500
Ellen,
Why the Jan 10 element entries are not working, it's hard to say without
seeing all the setups BUT from what I recall from my last project, the
'Plan' element may have to be on the person's record PRIOR TO THE FIRST PAY
PERIOD in which entries are to be made. This would be why it works for Jan
14 but not Jan 10. (I made the link to the plans 'Standard' links but this
may not work for you and would be too late anyway.)
Can you use Batch Element Entry to put the 'Plan' recurring element on the
employee assigments as of a date within the last pay period end date PRIOR
to the Jan 10 pay period, ie, Dec 25? (You shouldn't have to have a
payroll defined for that pay period in order to add a recurring element.)
Still a lot of work, I know, but you wouldn't have to enter any specific
amounts, just the Plan element.
PTO Carryover will not help you. All it does is look at the net accrual as
of the last pay period of the prior calendar year (it goes by pay period
end date) and puts the net balance in the 'Carried Over' element as of the
first pay period ending in the next calendar year (based on your carryover
rules as defined in the Plan).
The way the Plan balances are calculated (get_net_accruals function) is
that all entries are summed for those elements you have specified in the
Plan's Net Calculation Rules for pay periods ending within the calendar year.
In order for you to zero out April's balance, the easiest thing may be to
write a custom process. I've used a non-recurring element (remember to
include in Net Calculation Rules) to hold the amount to be cleared and had
a custom process calculate the net to be cleared. The process creates an
entry to this element for the first pay period ending in 'new accrual year'
that, when all entries are added together, the net is zero. (You decide in
Net Calculation Rules whether to add or subtract this element and this will
determine whether the entry is positive or negative).
Hope this helps.
Kit