payroll

Andrew Sackville-West andrew at farwestbilliards.com
Thu May 26 23:08:52 EDT 2005


okay, looking in g2 now...

Derek Atkins wrote:
> Hi,
> 
> Andrew Sackville-West <andrew at farwestbilliards.com> writes:
> 
> [snip]
> 
>>Looked at the following in src: business-gnome.scm and 
>>gnc-menu-extensions.scm, and from them I gather what you are saying 
>>above is something like
>>
> 
> [scheme example snipped]
> 
>>placed in the (define (add-employee-items) section and register the 
>>thing a few lines below with
>>
>>(gnc:add-extension pay-employee-item)
>>
>>all in the business-gnome.scm section. These would place the menu item 
>>and link it to "some-payroll-function-here" (spfh) so that it was called 
>>by the click, right? so what is "spfh"? is it a C module with the 
>>payroll functionality? or is it some .scm with payroll functionality? 
>>does it matter? am I starting down the right road?
> 
> 
> 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.

so now I'm really confused but it looks to me like something in 
gnc-plugin-business.c ? I found a gnc:make-extension in the 
gnc-menu-extensions.scm but can't see where its actually used anywhere, 
is this deprecated?

I was on a roll there in 1.8 but lost all momentum now as it seems 
totally different. someone please point me in the right direction.

A
> 
> 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.
> 
> [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.
> 
> 
>>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
> 


More information about the gnucash-devel mailing list