Derek and all others who answered this initial post:
thanks for the prompt replies and insight. SO, this is a really huge
thing and I'm really rusty so I'm going to pepper you guys with
questions of the over-obvious idea. I've never even looked at scheme and
my history with C was years ago and not very successful (always liked
Ada myself and a little bit of Fortran and saw some lisp which seems to
be helping with the Scheme thing). Anyway
big snips and then a question below, and I"ll digest all that has been
said over the next few days.
Derek Atkins wrote:
Well, there's a couple ways of doing it
The way I envisioned it working is a combination of a gnc-module that
implements the generic payroll computations, perhaps plugging into the
business features, extending the employee objects. Then we'd plug-in
the various tax entities into the generic module (I envisioned this
being done by scheme).
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
(define pay_employee_item
(gnc:make-menu-item (N_ "Pay Employee")
(N_ "Pay Employee")
(list main-window top-level-employee "")
(lambda ()
(some-payroll-function-here
(gnc:owner-get-employee last-employee)
(gnc:get-current-book))))))
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?
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.
For each employee in the system you could set up the various locales,
deductions, etc. The generic module would then use that information
to call out into the locale-specific plugins.
<<snippity snap snap>>
That's not true. I for one would be happy so long as the architecture
is generic and extensible to multiple locales, even if the original
implementation is specific to one locale. C.f. the TXF report, which
was US only until recently.
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)
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.
Note that the system DOES have to be generic enough that users could
create their locale-specific definition files and plug those in. But
I think we can release code without supplying those definitions at the
onset.
2. If a plug-in was developed it would probably be fairly easy to modify
it on a case-by-case basis to make country-specific plug-ins. or
True. Note that I don't think we want to require changing C code for
each locale, so I don't want to require changes to the payroll module.
So it would be a "module + plugin" architecture. (I'm sorry I keep
harping on this).
I'm all for not changing C code (see comments above about lame and rusty
coding skills)
Andrew
3. it may be fairly straight-forward to create a very generic payroll
feature that would allow the user to create their own tax tables (which
we sort-of have to do every year in the US anyway) thereby making the
implementation easier and also absolving the developers of
responsibility for keeping track of all those jurisdictions.
Exactly.
your thoughts are appreciated
Andrew
-derek
_______________________________________________
gnucash-devel mailing list
[email protected]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
