okay, looking in g2 now...
Derek Atkins wrote:
Hi,
Andrew Sackville-West <[EMAIL PROTECTED]> 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
[email protected]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
