Re^2: payroll, mysql and perl question

You understood me correctly, however the amount does matter, because it could be that they have other checks 'preissued' by the time we get the file from adp, that has the check numbers.

So the amounts are relevant, however, it will be the first ones I come to, as I don't upload a later file before an earlier one, so it could be that the amount will equal the FIRST 1 or more but not likely it would be the second and third and fourth but not the first...

So, what I need to do is something like this, I guess:

my $_startingAmount = sprintf('%.2f', $fileparts
[$_checkAmt]);
my @potids = ();
my $sth = $dbh->prepare(qq{SELECT * FROM `pot` WHERE `adpid` = ? AND `
+status` = "preissue" ORDER BYE `potid`});
$sth->execute($fileparts[$_emp_id]);
while(my $_pot = $sth->fetchrow_hashref()) {
 if(sprintf('%.2f', $_pot->{amount}) <= $_startingAmount) {
   push(@potids, $_pot->{potid});
   $_startingAmount -= $_pot->{amount};
   last if $_startingAmount == 0.00;
 }
 next;
}
$sth->finish();
## Now go update all the potid records in a foreach statement in @poti
+ds
[download]

I think I need to think that through, but it SHOULD work... but what if the payroll company messes up and he amounts do not match up... guess I could keep track of that in the while statement and if I never reach 0.00 set a flag for that record and don't update those records. Hmm, what do you think?

Thanks again for your input, BTW, the employee identifier is 'adpid' that is the record of the employee file primary key, unique to each employee (Currently we have just shy of 2,000 in that table).

thx,
Richard

Comment on Re^2: payroll, mysql and perl question Download Code

Replies are listed 'Best First'.
Re^3: payroll, mysql and perl question by graff (Chancellor) on Jan 02, 2008 at 19:44 UTC
... the amount does matter, because it could be that they have other checks 'preissued' by the time we get the file from adp, that has the check numbers. In other words, between the time that a set of rows goes out for check processing, and the time when the check-processing results come back to you for updating the table, there might be additional "preissue" rows that have been inserted for a given "empID". Is that it? In that case, you are missing a piece of information, which might be simple to add in the current table structure: the date when a given set of rows were sent out for check processing (i.e. when the status field was set to "preissue"). You appear to have a "statuschanged" field, which apparently holds a date value. If that field is set when the status field becomes "preissue", and if a set of check-processing results can be associated with that date, then you can select "preissue" rows with "statuschanged" less-than-or-equal-to the particular date, and you should get the right set of rows (excluding the rows that were added after the current list of payments were sent out for processing). Your alternative of looping over records until you reach the payment amount would most likely solve it as well, but seems like more work. (And you would have to fix the spelling: "ORDER BY" -- no final "E")	[reply]
Re^4: payroll, mysql and perl question by powerhouse (Friar) on Jan 02, 2008 at 23:30 UTC
lol, yeah, no bye ;o)... I have slept now, but had not slept in a long time when I did that. surprised I did not make more mistaks than that. Anyhow, yes you have the correct, and yes statuschanged is a unix timestamp(epoch), so yes I could use those to do this. However, we make two pay runs in each cycle. So there could be two different timestamps. Thank you much for your input, I really appreciate it. thx, Richard	[reply]