payroll

[Andrew Sackville-West]

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
>