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