P. Christeas wrote:
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.
I think its reasonable to assume that if a user is actually running
their own payroll, they have a good general knowledge of how payroll
works. If they have created their own tax tables and brackets based on
the information they recieve from their respective governments, then the
only thing the user has to be comfortable with is the accuracy of the
*calculations* and the accuracy of the information he or she has
manually entered.
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.
This is why I used the taxFloor and taxCeiling fields. You could easily
set up a series of these
TaxBracket1
Floor = 0
Ceiling = 12000
Rate = .10
TaxBracket2
Floor > 12000
Ceiling = X
Rate = .15
etc.
THen you can apply each of these items to the payroll and get your tax
computed accurately.
I agree that the more general the solution the better. I also agree that
setting a lot of this up in Scheme is probably better. If a solution
doesn't work for someone it would be relatively simple to make adjustments.
A
_______________________________________________
gnucash-devel mailing list
[email protected]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
