Hi Steve,
As I think on this, I lean more and more towards doing the computations
and storing them in a employee-payperiod summary table. Then all you have to
do is link to that table. There is a time to calculate on the fly and there
is a time to store the calculations. In my opinion, this is the latter
because of the changing nature of the constraints. Suppose you are asked to
go back and run a report for last year and you have the report set up for
this year? Or suppose they change the conditions again in six months? You
would then have a report that has to figure out which values to use depending
on which part of the year you are in. Depending on your situation, it may
make sense to do the computations and saving when the hours are entered or as
a separate batch process that adds in new rows for the new pay period. Going
back to the settings table I mentioned earlier, here is how I would adapt it
to fit this scenario. Instead of a single row, allow for multiple rows.
Replace the RecordID with an EffectiveDate field, which will be the primary
key. You could also add in columns for your other types of leave such as
vacation. Each time one or more of the values changes, add a new row with a
new effective date, copying the old data that does not change and entering
the new changed data. Backing up a bit, your employee payperiod summary
table could contain things like earned sick leave, used sick leave, earned
and used vacation, earned and used comp. time, and so forth, along with sick
leave balance, vacation balance, comp. time balance, etc. The primary key to
the table might be the combination of the employee ID and the starting date
of the pay period. Jumping forward, when doing the computations of the
summary information, you would check the settings table for the most recent,
but not future, row of information as compared to the pay period start and/or
end date and use the conditions specifice there.
So if the settings table has these values:
EffectiveDate MaxSickHours BiweeklySickAllotment
1/1/2006 5000 6.23
1/1/2009 1600 4.62
1/1/2010 1800 5.00
and you are calculating for the pay period that ends on June 5, 2009 you
would use the 1/1/2009 row. You can get the row with:
select *
from tblSettings as A
where EffectiveDate <= [the pay period end date] and not exists
(select * from tblSettings as B
where B.EffectiveDate > A.EffectiveDate)
The vacation issue you have alluded to most likely would be solved by
doing things this way.
You state that the system is to be replaced soon and you do not want to
spend a lot of time. I don't think it would take much time to put this in
place. You could start by pre-populating the table with a summary record for
the last pay period in 2008, then only create new records for 2009.
If you do not want to go that route, here is an untested alternative:
In your report's code, after the Option statements, before any
subroutines/functions add:
Private m_sngSickBalance As Single
Create an On Format event for the header where you display the employee
information (ID, name, starting sick leave balance, etc.). In it place:
m_sngSickBalance = txtBeginSickHrs
Create an On Format event for the detail. In it place:
m_sngSickBalance = m_sngSickBalance - txtSickUsed
If m_sngSickBalance < 1600 Then
m_sngSickBalance = m_sngSickBalance + 4.62
End If
Create an On Format Event for the employee's footer section. In it
place:
txtSickBalance = m_sngSickBalance
Hope that does the trick.
Clifford Bass