Quoting Jay Scherrer <[EMAIL PROTECTED]>:
>>variables:
>>[$line41 = wages, $line42 = Tax, scheduleY1 = member function]
>>## Status = married filing joint ##
>>sub scheduleY1(){
>> my $line41 = shift;
>> if ($line41 >= 0 && $line41 <= 12000){
>> $line42 = $line41 * .10;
>> }elsif ($line41 >= 12000 && $line41 <= 46700) {
>> $line42 = ((($line41 - 12000)* .15) + 12000);
>> }elsif ($line41 >= 46700 && $line41 <= 112850) {
>> $line42 = ((($line41 - 46700)* .27) + 6405);
>> }elsif ($line41 >= 112850 && $line41 <= 171950) {
>> $line42 = ((($line41 - 112850)* .30) + 24265.50);
>> }elsif ($line41 >= 171950 && $line41 <= 307050) {
>> $line42 = ((($line41 - 171950)* .35) + 41995.50);
>> }elsif ($line41 > 307050) {
>> $line42 = ((($line41 - 307050)* .38.6) + 89280.50);
>> }
>> return $line42;
>
>
> Um, this seems particular hard-coded and not very flexible. It's even
> WORSE if it's in C, because then the numbers aren't user-settable.
> You /need/ to support this kind of configuration in a user-settable
> method. How do you propose to do that?
>
> This is why I'm suggesting scheme, because then you can configure this
> kind of "function" in scheme and users can change the values without
> having to rebuild gnucash. I'm open to other suggestions, too. We
> can certainly try to create a generalized "graduated tax" in C, but
> you'd need to figure out some way to allow the user to configure that.
>
Actually, this example was pulled right off of my head perhaps I had
jumped to far ahead. This example has to be hard coded because that is
the way the IRS stipulates this calculation according to pub 17. The
standard deductions of earnings above $100,000. But what I was trying to
show is that, If we have classes with user defined entries (wages,
hours, rates) then we would define functions as prototypes attached to
the particular calculation of mixed members and classes.
My point is that this needs to be data driven.. We can't hard-code
these values
into the source code. Instead, we need some way to provide the set of
variables to compute it. E.g. [ 0 , 12000, 0.10 ], [ 12001 , 47600 , 0.15 ]
...
My point is that we need some datafile that defines these values, not C code.
[snip]
I think now that we/I am starting to understand payroll. It's do-able as
long as we have some sort of user definitions that can be updated by the
payroll admin. Plus, I am in the midst of an Income tax course, so the
requirements are fresh in mind. Let me try to compile a simple payroll
program using c over the weekend.
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
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
[EMAIL PROTECTED] PGP key available
_______________________________________________
gnucash-devel mailing list
[email protected]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
