Adding a Payroll calculator

[P. Christeas]

Derek Atkins wrote:
>...
> Yes, exactly.  We need some user-updatable definitions (in particular the
> tax tables!) that we can "execute" on employee data.  I think for your
> testing you could just create a bunch of arrays or something, but just make
> sure you don't make assumptions about how many tax brackets there are or
> what the values
> or rates of those brackets are in the actual computations.
>
> > Some items for thought: based on 2004
> > Social security is withheld at 6.2% on all employees up to $87,900.
> > Employees are taxed 1.45% on all wages and tip for Medicare.
>
> Just keep in mind that there are state taxes, local taxes, various other
> deductions (pre-tax and post-tax).   We should really generalize this out
> as much as we can.
>
> > Jay Scherrer
>
> -derek


I may have joined the discussion late, but let me add a wish:
Whatever you do with the machine (Language, implementation etc.) you *should* 
provide a verification, in the form of showing which rule was used for the 
calculation:
You may end up with a hard-coded, flexible function which takes many arguments 
from a table. You may find some extension language/equation evaluator. But 
let the way be visible to the user, just by the form field, or some report.
Say: you end up with tax= $123.45  . Then show some hint indicating that this 
was computed based on the xx field (on gnc accounts), using the 8th row of 
the tax tables (and even the equation itself).

IMHO the user wouldn't feel comfortable just by looking at a result. 
Especially after he has entered himself the tables, he will want to verify 
that they work as planned.

In C, this would mean some extra programming effort. Having the parameters 
accessible to third functions, that is.

I hope I'm saying something useful here.. :)