UtterAccess.com
X   Site Message
(Message will auto close in 2 seconds)

Welcome Guest ( Log In | Register )

 
Reply to this topicStart new topic
> Salary Rate Increase    
 
   
ellachka
post Aug 4 2004, 03:08 PM
Post #1

New Member
Posts: 5



I'm creating database that stores personnel records.
One of its functions is to keep salary history. Based on the Salary History information, Annual & Actual salary for specific fiscal year is calculated.

There are couple problems that I'm looking to resolve:
1. Rate Increase:
If the start salary is given and so is % of rate increase, I could calculate the Annual End Salary.
However, what I need is for it to work the other way around. Given Salaries for each year, I want %
of rate increase to be calculated automatically.
2. What should I be doing if there's more than one raise during the fiscal year?

Thanks in advance for any suggestions.

Ella...

Edited by: ellachka on 08.04.04.
Go to the top of the page
 
+
strive4peace
post Aug 5 2004, 10:23 AM
Post #2

UtterAccess VIP
Posts: 20,187
From: Colorado



create a table linked on the personnel ID for salary data.

Salaries
IDfield, long integer
Salary, currency
StartDate, date
EndDate, date
IsCurrent, yes/no
Go to the top of the page
 
+
ellachka
post Aug 6 2004, 02:15 PM
Post #3

New Member
Posts: 5



I already have Salary Table with the following info:
EmployeeID, AnnualSalary, Review Date, Reason, FY (fiscal year), Notes

To find Rate Increase, I'm using this formula: AnnualSalary/PreviousAnnualSalary - 1

Any idea how to get and include PreviousAnnualSalary on the same line with the current salary?

Thanks
Go to the top of the page
 
+
strive4peace
post Aug 6 2004, 03:45 PM
Post #4

UtterAccess VIP
Posts: 20,187
From: Colorado



the table I suggested would JUST have the actual salary and fields to track when that value stopped and started. In addition to the fields I mentioned, you should add

LineNum, integer.

First salary is LineNum = 1, second is LineNum = 2, etc. This way, you could compare current vs previous

Review Date, Reason, FY (fiscal year), Notes .. should NOT be in this table. You should have just one record with this information per employee.
Go to the top of the page
 
+
NoahP
post Aug 6 2004, 08:58 PM
Post #5

Retired Moderator
Posts: 10,493
From: Lexington/Louisville KY USA



I'd go with something like what I have in the attached. If the review data is always tield to salary increase, you could keep it in the same table, IMO. If the employee can ever have a review that does not tie to salary increase then you would want a separate table for reviews only. If you wanted to check those folks who got no increase due to a bad review, I think it would be ok to have the review data there as well since the rateincrease would come out as 0%.

HTH
Noah
Go to the top of the page
 
+
ellachka
post Aug 9 2004, 09:41 AM
Post #6

New Member
Posts: 5



Thank you both so much. This problem has been bugging me for a while now. It looks like this is exactly what I need.
Go to the top of the page
 
+

Thank you for your support! Reply to this topicStart new topic

Jump To Forum:
 



RSS Go to Top  ·  Lo-Fi Version Time is now: 19th May 2013 - 03:36 PM