payroll

[Andrew Sackville-West]

Derek Atkins wrote:
<<chomp chomp>> <<chew chew>> <<gulp>>
> 
> That was the way to do it in 1.8; not the way to do it in g2 (which is
> really where you should be working on this kind of feature
> enhancement).  The thinking is correct, the implementation has changed.

oops, forgot I had pulled 1.8 branch down the other day...

> 
> The scheme code you wrote above does exactly what you think it does.
> It creates a menu item and adds it into the menus..  And when that
> menu item is clicked it calls the "exported procedure" called spfh.
> Note that spfh could be written in C or Scheme, it doesn't matter.
> 
>>From a maintenece point of view it would be easier to implement it in C.
> 
> 
>>I know this seems like maybe the wrong way to start, but I really think 
>>the actual calculations of payroll are fairly trivial, for me it is 
>>figuring out how to use the mammoth beast i see before me and tying it 
>>all in.
> 
> 
> I agree that the actual calculations are trivial..  Much harder is the
> architecture to handle multiple locales, store per-employee prefs,
> load the locale data, and presenting all this to the user in a
> coherent UI.

well, you'll get lots of dumb questions from me, but I know I can figure 
it out eventually... so... sorry in advance ;)
> 
> [snip]
> 
>   > Seems to me there's really only a handful of ways to tax income:
> 
>>-- a flat % tax on all income (in US thats medicare)
>>
>>-- a flat % tax on a part of income (in US that's social security)
>>
>>-- a graduated % tax on all or part of income (US income tax)
>>
>>-- a unit price (?) tax on hours worked or some other non-income based 
>>value (in US, typically workers compensation -- my jurisdiction is some 
>>many $ per hour worked)
> 
> 
> I think this can be summerized into three types of taxes:
> 
>   1) flat % tax
>   2) graduated % tax
>   3) unit price tax
> 
> All of these taxes could be applied over some or all of income.

yup


thanks

A
> 
> 
>>So I think a couple of data structures for taxes that could encompass 
>>these (and any others that are lurking out there) would do it, then its 
>>up to the user to enter the values into these "generic" tax types, give 
>>them names, set the brackets etc. Quickbooks (boo) has this 
>>functionality to handle miscellaneous taxes they hadn't bothered to code 
>>for and it worked fairly well, you just entered a name for the tax, 
>>checked whether it was an employee deduction or an employer expense (and 
>>picked the expense account is so), picked the liability account to 
>>record it in and then set the tax rate, max amount and a couple other 
>>items. That's what I see in gnucash payroll as then it is fairly easy to 
>>implement for any jurisdiction.
> 
> 
> Sounds like a good approach to me.
> 
> 
>>I'm all for not changing C code (see comments above about lame and rusty 
>>coding skills)
> 
> 
> Let me rephrase.  I think C code will need to be written at the
> onset...  I just don't want the locale-implementers to have to write
> or change C.  I.e., it's okay for the generic code to be in C, but the
> user or locale data should not require changes to the C code.
> 
> -derek
>