Re: payroll

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: 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
>
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: payroll

Christian Stimming
Andrew Sackville-West schrieb:
>> 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)
> [...]

These (4) calculation methods you mentioned are already enough to also
cover the tax methods in e.g. Germany. Just remember that it should be
possible to have multiple deductions of each method, not only one, and
then you're done with Germany, too. (I.e. there's one flat % tax on the
gross income for medicare and another flat % tax on the same gross
income for pension etc.)

Aside from that, I would strongly support Derek's proposal that you
should just go ahead for a US payroll module (or whatever locale you
need) and not to worry too much about the
super-duper-hyper-international coding solution. Once the US solution is
in place (probably as one module), it is relatively easy to add modules
for other locales.

Regards

Christian Stimming
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: payroll

Derek Atkins
In reply to this post by Andrew Sackville-West
Hi,

Andrew Sackville-West <[hidden email]> 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
       [hidden email]                        PGP key available
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: payroll

Brian-5
On Thu, 2005-26-05 at 09:07 -0400, Derek Atkins wrote:

> 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.
>
> -derek
>
I agree.  Andrew, have you started preliminary designs for any of the
screens? I would like to help out what I can.  It looks like your grasp
of scheme is better than mine.

Also would it be better to store some of the info in a separate file(s),
or would you want to mesh it in with the main gnc data file (not the
locale specs/catculations)?

P.S.  Anyone know if doxygen can be config'd to work on the .scm stuff?
Or would there be a lot of work/changes required?

--
Brian <[hidden email]>

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: payroll

Andrew Sackville-West
In reply to this post by Derek Atkins


Derek Atkins wrote:
<<chomp chomp>> <<chew chew>> <<gulp>>
>
> 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.

oops, forgot I had pulled 1.8 branch down the other day...

>
> 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.

well, you'll get lots of dumb questions from me, but I know I can figure
it out eventually... so... sorry in advance ;)

>
> [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.

yup


thanks

A

>
>
>>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
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: payroll

Andrew Sackville-West
In reply to this post by Brian-5


Brian wrote:
> <<snip>>
>
> I agree.  Andrew, have you started preliminary designs for any of the
> screens? I would like to help out what I can.  It looks like your grasp
> of scheme is better than mine.

I haven't not started any of the ui. ui is something I have NO
experience in (told you it'sbeen a while). the scheme seems pretty
intuitive to me. I've been trying to figure out how the hell to get
some understanding of the gnc code and where to fit in and what, if any,
parts of it can be reused for this payroll. Obviously the parts that
write the transactions, the employee records need to be expanded to
store payroll data, probably whatever standard parts draw the ui...

>
> Also would it be better to store some of the info in a separate file(s),
> or would you want to mesh it in with the main gnc data file (not the
> locale specs/catculations)?

I suspect, haven't looked deep enough yet, that the engine can probably
take just about any data structure and write it to the main file which
is a cleaner solution, plus themore files, the more likely someone is to
lose one.

A
>
> P.S.  Anyone know if doxygen can be config'd to work on the .scm stuff?
> Or would there be a lot of work/changes required?
>
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: payroll

Thomas Bushnell BSG
In reply to this post by Andrew Sackville-West
Andrew Sackville-West <[hidden email]> writes:

> 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)

This is true, more or less.

The US withholding tables are just that: tables, which are sometimes a
little different than what formulas would produce.  Indeed, they don't
even have formulas.  Employers are required to withhold the amounts
listed in the tables, and that's that.

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: payroll

Derek Atkins
Quoting Thomas Bushnell BSG <[hidden email]>:

> Andrew Sackville-West <[hidden email]> writes:
>
> > 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)
>
> This is true, more or less.
>
> The US withholding tables are just that: tables, which are sometimes a
> little different than what formulas would produce.  Indeed, they don't
> even have formulas.  Employers are required to withhold the amounts
> listed in the tables, and that's that.

Actually, they DO have formulas, but they are only used for amounts greater than
$100k/year (or thereabouts).  However you are correct that when the amount
falls into the table it is supposed to use the table value.  It would be useful
to know how QB or other apps do it -- do they encode the tables themselves or
just the formulae?

-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
       [hidden email]                        PGP key available

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: payroll

Andrew Sackville-West


Derek Atkins wrote:

> Quoting Thomas Bushnell BSG <[hidden email]>:
>
>
>>Andrew Sackville-West <[hidden email]> writes:
>>
>>
>>>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)
>>
>>This is true, more or less.
>>
>>The US withholding tables are just that: tables, which are sometimes a
>>little different than what formulas would produce.  Indeed, they don't
>>even have formulas.  Employers are required to withhold the amounts
>>listed in the tables, and that's that.
>
>
> Actually, they DO have formulas, but they are only used for amounts greater than
> $100k/year (or thereabouts).  However you are correct that when the amount
> falls into the table it is supposed to use the table value.  It would be useful
> to know how QB or other apps do it -- do they encode the tables themselves or
> just the formulae?

Actually, you're both wrong... :) The US has both tables and formulas.
The tables are setup in $50 increments and the tax is rounded to the
nearest $1 (can't remember) but you are also free to use the formulas,
which give a more "precise" tax number. I believe the QB implements the
tables, or uses a modified formula that emulates the tables.

When I used QB, all US federal withholding was rounded to the nearest
dollar, which is also allowed. when I started using the formulas in my
spreadsheet, I got, of course decimal results.

The reality, for US, is that for federal income tax, precision is not
required because of the personal return filed at year end. Basically,
you only have to withhold approximately the right amount. What is
approximately right? depends on the auditor probably, and so some form
of reasonable implementation of the tax tables is required.

The formulas are very straightforward and while ugly, are easy to implement.

Other parts of the federal tax code, especially social security and
medicare require more precision than withholding because they are
reconciled quarterly and must line up at the end of the year and there
is no means to get extra ss or mcare money out of tax payers. These
taxes must reconcile within a few pennies each quarter, or you must make
adjusting transactions and fix it and still probably face penalties.

phew
A
>
> -derek
>
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: payroll

Brian-5
In reply to this post by Andrew Sackville-West
On Thu, 2005-26-05 at 08:11 -0700, Andrew Sackville-West wrote:

>
> Brian wrote:
> > <<snip>>
> >
> > I agree.  Andrew, have you started preliminary designs for any of the
> > screens? I would like to help out what I can.  It looks like your grasp
> > of scheme is better than mine.
>
> I haven't not started any of the ui. ui is something I have NO
> experience in (told you it'sbeen a while). the scheme seems pretty
> intuitive to me. I've been trying to figure out how the hell to get
> some understanding of the gnc code and where to fit in and what, if any,
> parts of it can be reused for this payroll. Obviously the parts that
> write the transactions, the employee records need to be expanded to
> store payroll data, probably whatever standard parts draw the ui...
>
[snip]

I'll play around in glade some and see if I can come up with something
similar to the other registers, etc. that should suit a general purpose
interface.

Now a question for the knowledgeable gnc devs:

   The number and types of incomes, deductions, etc. can be quite varied
depending on the users needs.  I was thinking that something similar to
the accounts view and editing features should work.   The primary
difference would be the different types such as:
        Income
                --Hourly
                --Salary
                --Commission

        Deductions
                --Employment Insurance
                --Pension Plan
                --Federal Tax
                --etc.

Could the existing Accounts editing/creation code be re-used without
difficulty? There will need to be new functions added for linking to the
required formula, setting min/max values, attaching to the appropriate
ledger account, etc..


--
Brian <[hidden email]>

_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: payroll

Andrew Sackville-West
In reply to this post by Derek Atkins
okay, looking in g2 now...

Derek Atkins wrote:

> Hi,
>
> Andrew Sackville-West <[hidden email]> 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
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: payroll

Andrew Sackville-West
wait, nevermind.

A

Andrew Sackville-West wrote:

> okay, looking in g2 now...
>
> Derek Atkins wrote:
>
>> Hi,
>>
>> Andrew Sackville-West <[hidden email]> 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
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: payroll

Kevin T. Broderick
In reply to this post by Brian-5

On 26 May 2005, at 9:22 PM, Brian wrote:

[CHOMP]
Now a question for the knowledgeable gnc devs:

   The number and types of incomes, deductions, etc. can be quite varied
depending on the users needs.  I was thinking that something similar to
the accounts view and editing features should work.   The primary
difference would be the different types such as:
    Income
        --Hourly
        --Salary
        --Commission

    Deductions
        --Employment Insurance
        --Pension Plan
        --Federal Tax
        --etc.

Just a note on types of income...you might also need to account for charge tips (where customers pay for something including a tip with a credit card and the company includes the tips for a pay period in the paycheck) or taxes on reported cash tips.  At least in Vermont, those tips are subject to an entirely different formula for taxation (I believe it's based on total revenue and an assumption of workers being tipped at a certain percentage, i.e. they are taxed based on additional income of x% of total food sales, where x is a number in the vicinity of 5, regardless of actual tipping).  I don't know if anyone else is more familiar with a jurisdiction that does things in a similar manner, and I'm not entirely sure what the correct double-entry manner of accounting for cash tips would be (since they are neither income nor expense for the company but may need to be accounted for in tax calculations).

If no one else has encountered a similar situation, I'll try to dig further into this one; I'm only semi-aware of it now due to being in the vicinity of payroll operations for restaurant operations.

Kevin Broderick / [hidden email]



_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: payroll

Andrew Sackville-West


Kevin T. Broderick wrote:

>
> On 26 May 2005, at 9:22 PM, Brian wrote:
>
>> [CHOMP]
>> Now a question for the knowledgeable gnc devs:
>>
>>    The number and types of incomes, deductions, etc. can be quite varied
>> depending on the users needs.  I was thinking that something similar to
>> the accounts view and editing features should work.   The primary
>> difference would be the different types such as:
>>     Income
>>         --Hourly
>>         --Salary
>>         --Commission
>>
>>     Deductions
>>         --Employment Insurance
>>         --Pension Plan
>>         --Federal Tax
>>         --etc.
>
>
> Just a note on types of income...you might also need to account for
> charge tips (where customers pay for something including a tip with a
> credit card and the company includes the tips for a pay period in the
> paycheck) or taxes on reported cash tips.  At least in Vermont, those
> tips are subject to an entirely different formula for taxation (I
> believe it's based on total revenue and an assumption of workers being
> tipped at a certain percentage, i.e. they are taxed based on additional
> income of x% of total food sales, where x is a number in the vicinity of
> 5, regardless of actual tipping).  I don't know if anyone else is more
> familiar with a jurisdiction that does things in a similar manner, and
> I'm not entirely sure what the correct double-entry manner of accounting
> for cash tips would be (since they are neither income nor expense for
> the company but may need to be accounted for in tax calculations).
>
> If no one else has encountered a similar situation, I'll try to dig
> further into this one; I'm only semi-aware of it now due to being in the
> vicinity of payroll operations for restaurant operations.

I can tell you, as a restaurateur, that the last thing the employer
wants to do is claim any amount other than what the employee reports for
tips, because doing so makes you liable for the actual amounts if they
differ. I'm a not a Vermonter, so I can't speak to that.

I envision one or more types of generic payroll additions and
deductions. There are a variety of things that come up:

potential additions:
  Tips reported (for taxing purposes)
  bonuses
  mileage and other expense reimbursements (not taxable in US, but still
part of payroll)
  retirement benefits
  ...

potential deductions:
  Tips reported (as the employee already has them and we only need them
for taxing)
  advance repayment
  health care premiums
  other employee paid "benefits"
  retirement plan contributions
  ...

there' abig ol' pile of them. some are taxable, some are exempt from
taxing, some reduce the taxable income for federal withholding but not
ss & mcare  etc etc etc..

A

>
> Kevin Broderick / [hidden email] <mailto:[hidden email]>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> gnucash-devel mailing list
> [hidden email]
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Reply | Threaded
Open this post in threaded view
|

Re: payroll

Thomas Bushnell BSG
In reply to this post by Andrew Sackville-West
Christopher Browne <[hidden email]> writes:

> It's then worth noting that commercial lawyers are not known for
> deferring fees; that is NOT an area where ideals of 'free software' have
> made many inroads.  The "idealistic" lawyers tend to head into 'human
> rights' sorts of directions as opposed to commercial law.

No, this is quite compatible with free software.  Someone has to pay
the lawyer to generate the data: "please give us the run-down on the
law here", and then the lawyer probably doesn't care at all what you
do with it.

Keep in mind: free means libre, not gratis.

Yet, it does take someone with the knowledge and time to do it, or
someone to commission them to.  Lacking that, we can provide a
pluggable feature.

Thomas
_______________________________________________
gnucash-devel mailing list
[hidden email]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel