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