payroll

[Derek Atkins]

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.

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

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available