wait, nevermind.
A
Andrew Sackville-West wrote:
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
_______________________________________________
gnucash-devel mailing list
[email protected]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
