Vertex enhancements
Subject: [orahrms-l] Vertex enhancements
From: "Schmit, Mark" mschmit@Mail.Donaldson.com
Date: Wed, 28 Jul 1999 14:05:27 -0500
We have people that are living in one city but have told payroll that they
are living in another city. Tax issues aside, the payroll people here would
like to know what other companies are doing about that situation. Or here's
another situation, Joe lives in cow-town, USA. But he wants to say he's
from big-city, USA. He uses the correct zip code for cow-town, so the post
office has never missed delivering him a piece of mail. But Vertex says
that the city/state/zip doesn't work out in Joe's case.
In Joe's case, we'll probably make him fess-up and admit he really lives out
in the sticks. But in the case of a new hire, we might have to issue a
check within days of hiring them and won't be able to get the correct
information to update their address record in time (it's a work related
thing ... we entered their data into the system when the clerk got back from
vacation, about a day before checks were to be issued).
Does anyone out there modify Vertex tables to allow for this obviously bad
data?
And now the really dangerous question ... does anyone out there have an
opinion on the practice of entering temporary data into Vertex?
Mark Schmit
Donaldson Inc.
(612) 703-4606
Vertex Payroll Tax updates
Subject: [orahrms-l] Vertex Payroll Tax updates
From: James Wood JWOOD@FAMILYDOLLAR.com
Date: Fri, 5 Feb 1999 09:03:21 -0500
I'm looking for guidance on Vertex's monthly payroll tax updates for
Oracle HRMS. As many of you know, Vertex, Inc. provides monthly updates of
federal, state, and local payroll tax changes to HRMS customers. We noticed
on the last update, however, which we received in mid January, that some of
the tax changes had gone into effect January 1, 1999. Therefore, depending
on the rate change, we either overpaid or underpaid our tax liability for
that payroll tax for that month.
Has anyone else encountered this situation? If so, how did you
address the discrepancy between the tax liability paid and what should have
been paid? Finally, is anyone aware of a way to receive all tax change
updates from Vertex before the change is effective? Thanks for any
suggestions.
James Wood
Subject: Re: [orahrms-l] Vertex Payroll Tax updates
From: "Gregory A. Clark" GACLARK@us.oracle.com
Date: 05 Feb 99 08:19:37 -0800
James,
I have found that, for the most part, Vertex is fairly current with their
monthly updates. The situation you describe is very typical. Legislation at
all jurisdiction levels often is enacted at the last moment or even
retroactively. For example, look where all our representatives in the Sanate
Chambers have been focusing their attention lately. Have they been addressing
major tax issues this last week? I think NOT!
It some situations, the next payroll run may correct the discrepancies if
self-adjust applies and is turned on. In the case of some mid-year rate
changes, you may want to turn self-adjust off for the remainder of the year.
Possibly in some circumstances, adjustments to tax balances may need to occur.
Every situation needs to be evaluated separately.
Regards,
Greg
Outsourcing Payroll
Subject: [orahrms-l] Outsource Payroll
From: "Menke, Irene M." menke@Mail.Donaldson.com
Date: Tue, 23 Feb 1999 11:58:20 -0600
Hello,
We are exploring the option of only bringing up HR and outsourcing Payroll.
Does anyone know the vendors which provide this service besides Ceridian.
Thank you,
Irene Menke
menke@mail.donaldson.com
612.887.3605
Subject: RE: [orahrms-l] Outsource Payroll
From: sredrova@es.com
Date: Tue, 23 Feb 1999 12:36:28 -0700
We are using ADP. I know that they have an interface to Oracle HR but we are
using an in-house develop solution.
Stephanie Redrovan
Information Technologies
Evans & Sutherland Inc. (http://www.es.com)
sredrova@es.com · 801.588.1825
Passing parameters to a Fast Formula to fetch values from a user defined Table
Date: Wed, 28 Jul 1999 14:47:44 +0400
From: IjlalR@mashreqbank.com
Subject: GEN: URGENT - User Defined Tables
Hi,
I'm using the function GET_TABLE_VALUE in a Fast Formula to get values in a
user defined table. If the parameter I'm passing does not exist in the
table, I get an error during the payroll run. What I want is this: If the
parameter (e.g. x) is not found in the table then another parameter (y)
should be used. How can this be done?
Thanks in advance for your help.
Ijlal
Date: Wed, 28 Jul 1999 07:08:08 -0400
From: Tim Lavery tlavery@gate.net
Subject: Re: GEN: URGENT - User Defined Tables
I would look at one or more of the seeded Fast Formulas that use
Tables. That should probably give you a clue as to how they are used...
Good Luck1
- Tim
Vacation/Sick accrual plans on monthly basis
Date: Mon, 13 Sep 1999 13:08:02 -0400
From: "Richards, Annele" Annele_Richards@compuware.com
To: "'OraApps-L@CPA.QC.CA'" OraApps-L@CPA.QC.CA
Subject: HR PTO Accrual Plans
Has anyone setup Oracle HR to accumulate Vacation/Sick accrual plans on a
monthly basis rather than annual without any customization?
We need to be able to have it accrue an amount of time monthly based on
start/hire date.
Any help is greatly appreciated.
Leave Balance adjust
From: "Lewis Cunningham" LCunningham@gwmail.valencia.cc.fl.us
8/30/99 8:47 PM
Subject:[orahrms-l] PTO Sellback
Hi all,
I have a situation where after a number of years an employee can sell
back a portion of their leave for a percentage of it's value. That much
I can handle. What I'm not sure of is how to reduce their remaining
leave balance. Has anyone done this? It seems pretty standard (famous
last words!).
Thanks,
Lewis
From: "William C.Stratton" bstratton@sprynet.com
8/30/99 10:45 PM
Subject: Re: [orahrms-l] PTO Sellback
Hi Lewis,
Have you tried including your payback element in the Net Calculation Rules for your accrual plan. If it is not showing up in the pick list, then there are some special settings you will need to make via the Element Description screen. (I am assuming that this element is an Hours x Rate element). I can't remember what they are at this moment, but you could check the Payroll User's Manual. Something to do with the Termination Rule.
Hope this helps.
Bill Stratton
BOSS Corporation
Regular Salary Vs Regular Wages
From:
Rangaraju_Krishna@tmac.com
8/31/99 2:09 AM
Subject:
[orahrms-l] Regular Salary Vs Regular Wages
Hello Folks:
We are in the process of implementing Oracle HR and Payroll. We have a business
requirement of paying Salary based on a Timesheet. However, if there are less
than 40 hours exists in the Timesheet, then it should go under loss of pay
(means we don't pay them). So, if I set the Salary Basis as Regular Salary then
does the system imposes a "must" 40 hours or it will pay the salary to employees
irrespective of 40 hours?.
Alternatively we have an option of defining the Salary Basis as Regular Wages
because we are calculating the employee rate for every week (for Oracle Projects
Total Time Accounting purposes). Since I know both rate and hours for the
employee is this a correct option?.
Can anyone suggest me which option is better. I also want to know if there are
any major differences between Regular Salary and Regular Wages
Thanks
Krishna
From:
"Ken Conway" ken.conway@bosscorporation.com
8/31/99 2:49 AM
Subject:
Re: [orahrms-l] Regular Salary Vs Regular Wages
Rangaraju:
If you set up an employee as salaried, where the salary basis is tied to the
seeded Regular Salary element, the system will pay the entire salary each
pay period by default. On one of my past projects, we used the Regular
Salary Special Inputs element to reduce salary based on necessary criteria.
In this situation, if the employee worked 4 out of 5 days in the week, then
we created an interface to perform a 1-time decrease of their weekly salary
by 1/5 of normal rate. To complicate the matter, this client was on a
biweekly payroll. Thus, we might need to decrease the next week's salary
2/5 if the employee only worked 3 days.
Normally, you can include several Special Inputs elements for a
corresponding user-defined earning element. However, Regular Salary only
allowed one Special Input within the pay period (This was probably a past
bug that Oracle hopefully corrected a few years ago). Thus, in the example
above, we had to be careful with the timing of the interface process so that
we only created one Regular Salary Special Input for the pay period with a
decrease of 3/10 of the employee's biweekly salary.
Regular Wages is the earnings element associated with an hourly salary
basis. It is probably easier to implement your solution using a salary
basis of hourly if the business requirements will allow. In our example
above, the client did not consider it an option to use an hourly salary
basis.
Hope this helps,
Ken
From:
Rangaraju_Krishna@tmac.com
From:
Hankins Parichabutr Hankins@spinsoftware.com
From:
"Ken Conway" ken.conway@bosscorporation.com Payroll Tax Setup
From:
"Weidman, Rob" rweidman@uswa.org
From:
"Cooprider, Karen" Coop@RGIS.com
From:
"Schwartz, Ken" kschwar@rwjf.org
From:
Pakeeley@aol.com Employee Tax info - convert
From:
"Julie Hertzler" Hertzler.Julie@summitgroup.com
From:
"William C.Stratton" bstratton@sprynet.com Pretax Element causes APP-06867 error
From:
"Kelly, Paul" KellyPa@rf.suny.edu
From:
Kim Bauman kbauman@midcom-inc.com
From:
Laurie Bosley lbosley@solbourne.com
From:
"Smith, Amy" Amy.Smith@fmr.com Termination Date (actual) zeroes balances
From:
"Scott Frost" sfrost@noblestar.com Strikes - its effect on payroll process
Date: 25 Oct 99 12:10:23 PDT
Date: Mon, 25 Oct 1999 14:30:18 -0500
8/31/99 3:27 AM
Subject:
[orahrms-l] Re[2]: [orahrms-l] Regular Salary Vs Regular Wages
To:
"Ken Conway"
Ken,
Thanks for your help. I think I may choose implementing it using Regular Wages
and bring the Hours and Rates from Oracle Projects and then Pay.
By the way did you know any major implications to worry if we implement
"Salaried" employees using "Regular Wages"? Does W2 creation depends on Regular
Salary or Regular Wages?. If any major issues are there to worry about (because
they are normal Salaried employees just that we enforce the "must 40 hours"
business rule) please let me know.
Once again thanks for your help. I really appreciate it.
Note: I read your latest White Paper "Challenges Implementing Oracle HR/Payroll
after Financials" - It's really a good one. It has lot of useful stuff in it.
Krishna
8/31/99 3:34 AM
Subject:
Re: [orahrms-l] Regular Salary Vs Regular Wages
To:
Rangaraju_Krishna@tmac.com
CC:
Ken Conway
Hi Krishna,
I think if you enter time for an employee w/Regular Salary - the timecard entry
will override the Regular Salary calculation altogether. In the absence of a
timecard, Regular Salary will calc based on the salary basis...ie. 40 hrs / week
or whatever.
As Ken says, the only real difference between Reg Sal and Wages is the pay basis
they get associated with - ie. Reg Wages with Hourly salary bases...RegSal for
all others.
It sounds like your pay basis is hourly, and you'll be calculating/determining
rates and hours every period to make Time Entry Wages entries.
Also sounds like you've got some business logic to put somewhere regarding the
"less than 40 hours on timesheet" requirements.
Cheers, let us know how you get along...
"hparicha"
Hankins Parichabutr
Spin Software
Practice Director
228 Queen Street, Level 3
Auckland, New Zealand
(+64) 25.771.275 (mobile) or 9.366.0348 ext. 804
8/31/99 3:57 AM
Subject:
Regular Salary Vs Regular Wages
To:
Rangaraju_Krishna@tmac.com, OraHRMS-L@mail-list.com, oraapps-l@cpa.qc.ca
Krishna:
No, I am not aware of any implications on W-2s. I do not understand the
need to combine Regular Wages with a Salary Basis = Salaried. I would have
suspected some problems either with the Salary Basis definition itself or
with payroll processing. However, I've never tried to do this so I will
assume it has been researched thoroughly.
Overall, I've seen the Projects/Payroll interface issue approached in
several ways (either from Payroll Costing to Projects, Projects into PayMIX,
or an external Time & Attendance system to both Payroll and Projects).
Thank you for the kind words about our most recent White Paper. I didn't
realize this paper had been released to the public yet! Hope you can still
attend the OAUG session anyway.
Thanks,
Ken
Ken Conway
BOSS Corporation
9/1/99 1:06 AM
Subject:
[orahrms-l] Payroll Tax Regulations
I am looking for any information that would allow me to understand the
concepts of setting up payroll taxes for an employee who works in one state
and resides in another. More specifically, are there "rules of thumb" that
apply for all states or do payroll tax laws vary from state to state?
Thanks, Rob Weidman
9/1/99 2:15 AM
Subject:
RE: [orahrms-l] Payroll Tax Regulations
Rob,
Yes, there are many State tax withholding laws that very from State to
State. You will need to familiarize yourself with "Reciprocity Agreements"
with each State an employee works in and resides in.
You will find some states such as California have no reciprocity agreements
with any other state and requires tax withholdings for residence and
non-residence who work in their state, and the other state will also
withhold there part.
Some States require a Non-resident certificate to be filed to wave tax
withholdings of the Non-resident worker in their state.
Your best bet is research. Vertex has the reciprocity rules listed on the
state control records, so you know if any reciprocity rules apply and with
what states. Also, using a payroll forms library (RIA Payroll guide for
example) you can find forms such as a State W-4's and also the Non-Resident
certificates if the state allows them. Also a Payroll guide should contain
detailed information on the State laws for tax withholding on reciprocity
agreements and non-resident rules.
When we went live on Oracle Payroll at the beginning of 1998 it was a big
change for the payroll department and the employees. If you would like to
talk more in depth on this subject feel free to contact me direct, I think I
can give you a few pointers.
Good Luck.
Karen Cooprider
Salaried Payroll Manager
Coop@rgis.com
9/1/99 3:12 AM
Subject:
RE: [orahrms-l] Payroll Tax Regulations
Rob:
The only 'rule of thumb' that I am aware of is how do you currently tax your
employees for state taxes? There are only two answers. You either tax them
in the work state (determined by the Location in Oracle HRMS) or you tax
them in their resident state (determined by their PRIMARY address in oracle
HRMS).
Once that is determined, the other issues are mostly minor.
Regards,
Ken Schwartz
Independent Consultant
Specializing in Oracle HRMS
Site: 609-720-7529
Cell: 404-226-6334
Mail: kenschwartz@mindspring.com
9/1/99 7:31 AM
Subject:
Re: [orahrms-l] Payroll Tax Regulations
Rob,
Vertex handles reciprocity agreements very well with very few exceptions. My
experience has been that legacy systems did not/do not. Most legacy systems
require(d) manual efforts to correct support tax withholding and reporting.
Oracle/Vertex recognizes the special rules that exists between the various
taxing jurisdictions. Oracle recognizes when an employee changes work or
residence locations and will adjust the taxes accordingly.
However -- there are times when the correct taxation can become a "pain!" As
I stated, most legacy systems required manual efforts to support correct
taxation. This allowed the users to set employees up in Tax Jurisdictions
where they "really" didn't work, but reported to. Example: Remote sales
people in many different locations and set up in the "Corporate Sales
Office." If you convert the data in this same way, all your employees will
be taxed incorrectly (based on state "worked").
Most payroll departments prefer the Oracle way, once they understand it.
Good Luck!
Pat Keeley
9/1/99 3:18 AM
Subject:
[orahrms-l] Converting Employee Tax Information
We are currently implementing version 11.02 of Oracle HR and Payroll and are working on our
employee conversion. Can anyone tell me if there is any way to convert Employee Tax
Information? This includes information such as number of allowances and filing status.
Can this be done through a procedure or is it something that has to be entered manually
after the conversion for each employee? We converted the employees using the HR Employee,
Assignment, and Address APIs.
Thank You,
Julie Hertzler
9/1/99 5:46 PM
Subject:
Re: [orahrms-l] Converting Employee Tax Information
Julie,
There is a date-track W4 API patch on the FTP site under HR/PAYROLL Additional Functionality that will give you the necessary APIs to load in employee W4 information. Its number is 813822 for release 11 systems.
Hope this helps
Bill Stratton
BOSS Corporation
9/1/99 6:04 PM
Subject:
[orahrms-l] Pretax elements and R11
Good morning,
We are implementing release 11.0.2 for both HR and payroll. When running a
payroll, our pre-tax elements are causing the following error message:
APP-06867: An error occurred during formula execution:NULL value for
US_401K_ANNUAL_LIMIT at line 287 of (element name)_PTX .
None of the pretax elements we created are 401K elements. All other
elements seem to be working fine. It is only the pretax ones that error.
Has any run across problems in R11 with pretax elements causing errors our
during payroll? Has anyone seen this error message before? We are having
trouble tracking why this error is occurring.
Any help would be greatly appreciated.
Thanks,
Paul Kelly
Paul C. Kelly
Research Foundation of SUNY
OASIS Project HRMS Group
518-434-7185
9/1/99 6:22 PM
Subject:
RE: [orahrms-l] Pretax elements and R11
We have been on HR/PR v 11.02 since April of this year. We ran into this
problem after applying patch # 892049. Support has been unable to determine
why this occurs after applying this patch.
Sorry, I don't have a solution. We chose to not apply the patch to our
Production instance after seeing in the test instance.
Kim Bauman
Oracle HD Coordinator
ANZA, Inc.
Kbauman@anza.com
9/1/99 7:21 PM
Subject:
RE: [orahrms-l] Pretax elements and R11
As Kim stated, one of the payroll patches nulls this field. Run the
following sql and it should fix it:
update pay_us_federal_tax_info_f
set fed_attribute1 = 10000
commit;
Credit on this fix goes to Sabita at Oracle support.
Good luck
Laurie K. Bosley, PMP
Solbourne
1790 W. 38th St. Suite 300
Boulder, CO 80301
9/1/99 7:26 PM
Subject:
RE: [orahrms-l] Pretax elements and R11
To:
"'Kim Bauman'" kbauman@midcom-inc.com, "'Kelly, Paul'" KellyPa@rf.suny.edu
We had this problem as well and it is not caused by patch
892049 (c-code). It is caused by patch 870803 (JIT patch).
There is a very easy workaround for this though - you just
need to modify the driver d870803.drv and change:
compatible parallel always
to
compatible parallel no
The reason this patch was causing the problem was that the
scripts were being executed in the wrong order due to the
'parallel always'. The script that wipes out certain values
(causing NULL error) was being executed AFTER the script
that re-delivers the values.
Hope this helps!
Amy Smith
Application Support - Oracle HRMS
Phone: (603) 791-7201
Email: amy.smith@fmr.com
9/1/99 7:20 PM
Subject:
[orahrms-l] Actual Term Date Zeros Balances
Hi All-
We are future date terminating employees due to a RIF that is occurring
within the organization at the end of the year. Rather than maintain a
large folder of those people that are being terminated and entering their
appropriate dates at the end of the year, we are using the datetrack feature
to terminate these employees.
The problem occurs when we enter the ACTUAL DATE for their terminations in
the future.
When we do this, and we view an employee's Accrual Balances, for some reason
they are zeroed out. Even if we go back a few months and look while they
are still employees, the balances are zeroed out.
We took a look at the function we think this is calling
PAY_US_PTO_ACCRUAL.GET_ACCRUAL and we think it is not properly calculating
the Actual Date balances. We believe it sees this actual date and just
spits it out of the system since this function initiailizes the balances to
0 before it calculates the new ones.
Because the Actual Date is a 'thing of the past' rather than in the future,
we are assuming it just says, "oh, they are not employees anymore, so give
them 0...."
This would defeat the purpose of Oracle having a DATETRACK feature in the
application, and presents a major flaw in the datetrack logic.
Has anyone run across this situation before? Any work around besides
keeping a folder until the new year and then Actual Date ending them?
I am assuming it would be a technical fix rather than functional.
Thanks
Scott
Scott L. Frost
Oracle HRMS Consultant
Noblestar Systems Corporation
703.464.4000 x2549
From: Lolka Bolek lolka@itconvergence.com
To: oraapps-l@cpa.qc.ca
Subject: Payroll stuff
Hi guys,
we are implementing payroll, and I am kinda uncertain about how to deal with
unions. Is there anyway a strike can mess up the payroll? This might sound
dum, but can you calculate back pay automatically?
Thanx,
Lolka Bolek
From: "Ken Conway" ken.conway@bosscorporation.com
To: oraapps-l@cpa.qc.ca
Subject: Re: Payroll stuff
Lolka:
Yes, a strike can certainly impact payroll. First of all, your unions
probably have set pay scales based on job, years of service on job, total
years of service, etc. You have to ask questions such as, whether the
strike affects pay advances to bump union employees to the next step of the
pay scale. Then you need to determine if you have integrated Pay Scales to
Salary Administration.
Oracle Payroll does have a mechanism for calculating back pay through the
Retro Pay functionality. However, the effectiveness of this calculation is
based on your various union and other calculation rules. For example, let's
say that your retro pay must also re-calculate Overtime. Depending on how
you have solved the FLSA compliance issue in the overtime calculation could
influence the accuracy of the Retro Pay calculation.
Moreover, during the strike, there will be many employees who choose to work
part-time jobs previously performed by a union person. Your company will
need to analyze how this people will be paid. For instance, you may have
Office Personnel and even executives helping out with various Shifts. Thus,
you may need to set up these employees in your Time and Attendance system.
My experience with unions from several Oracle HR/Payroll implementations is
that there are numerous other benefit issues that can be affected. We are
only scratching the surface of the issues. I hope this helps as you begin
the analysis.
Good luck,
Ken
Ken Conway
BOSS Corporation
Better Organization Service Solutions