payroll
Andrew Sackville-West
andrew at farwestbilliards.com
Thu May 26 23:53:55 EDT 2005
wait, nevermind.
A
Andrew Sackville-West wrote:
> 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
>>
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
More information about the gnucash-devel
mailing list