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
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: payroll

[Derek Atkins]

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.

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
   [EMAIL PROTECTED]PGP key available
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: payroll

[Brian]

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 [EMAIL PROTECTED]

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [Fwd: Re: payroll]

[Conrad Canterford]

On Wed, 2005-05-25 at 19:07 -0700, Thomas Bushnell BSG wrote:
 Stuart D. Gathman [EMAIL PROTECTED] writes:
  For this kind of problem requiring continuous expert review and updates,
  I have always envisioned an open-source engine with paid-for data.
 Please remember, this is a free software project.  If people want to
 have non-free software (both programs and data are software), then
 that's up to them, but it shouldn't be our job or business to
 encourage them.

Yes and no. Gnucash shouldn't be requiring it, but by the same token,
shouldn't be restricting it either.

I don't see anything in the basic suggestion that is incompatible with
free software. If someone wants to provide the data free, and keep it
maintained, up to date and guaranteed accurate, for free - well that's a
bonus to people in their jurisdiction - assuming they trust it to be
maintained, up to date, and accurate.
I had rather assumed that the data files would probably be paid-for (at
least for people who are taking this seriously - who are running
businesses and really paying people money). Why? Because as a business
owner and manager, I want to know:
a) that I will get updates when updates are required, not just when
someone gets around to it; and
b) that the data is accurate, and isn't going to get me into trouble
with the tax office for failing to do the right thing.

Its not gnucashs business to make it exclusive (in either direction). If
you want the software to be used, be realistic, not restrictive.

  The tax lawyers would offer the xml-described data for sale on a 
  subscription basis, say quarterly updates.  
 This would be extraordinary.  Normally, legal advice is free (libre);
 that is, your lawyer gives you advice or explains the law to you, and
 you are free to repeat his advice or explanation to whoever you like.

I don't see how that is relevant in this case, since what you are paying
for is the update service, not advice. And leaving quite aside the
issues I have with your statement as it stands.

 I don't think businesses are helped by being forced to use restricted
 information.  Businesses would be much more helped by a free software
 product. 

Sure. If they could be assured that the accurate was accurate, etc. as
above. Paying for it gives a certain degree of assurance.

  Updates could include a digital signed serial number so
  that copyright violations could be detected.
 I want to urge very strongly that we not include *any* feature like
 this.  Geez, are we now cops on behalf of the software-hoarders too?

On this point, I will agree with you wholeheartedly. Gnucash should not
have this sort of functionality. That's not to say that the data file
cannot have such a thing, just that gnucash has no role to play in
using/verifying that number - although if someone produces custom
reports that somehow use that number, that's up to them.

Conrad.



___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: payroll

[Andrew Sackville-West]

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
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [Fwd: Re: payroll]

[Thomas Bushnell BSG]

Conrad Canterford [EMAIL PROTECTED] writes:

 I don't think businesses are helped by being forced to use restricted
 information.  Businesses would be much more helped by a free software
 product. 

 Sure. If they could be assured that the accurate was accurate, etc. as
 above. Paying for it gives a certain degree of assurance.

Well, those who think so can certainly shell out their money.  I have
found that libre software gives me more assurance than commercial;
that support help from friends is more reliable than that I pay for;
and so forth.


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: payroll

[Thomas Bushnell BSG]

Andrew Sackville-West [EMAIL PROTECTED] 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
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: payroll

[Derek Atkins]

Quoting Thomas Bushnell BSG [EMAIL PROTECTED]:

 Andrew Sackville-West [EMAIL PROTECTED] 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
   [EMAIL PROTECTED]PGP key available

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: payroll

[Andrew Sackville-West]

Derek Atkins wrote:

Quoting Thomas Bushnell BSG [EMAIL PROTECTED]:



Andrew Sackville-West [EMAIL PROTECTED] 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
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [Fwd: Re: payroll]

[Andrew Sackville-West]

Thomas Bushnell BSG wrote:

Conrad Canterford [EMAIL PROTECTED] writes:



I don't think businesses are helped by being forced to use restricted
information.  Businesses would be much more helped by a free software
product. 


Sure. If they could be assured that the accurate was accurate, etc. as
above. Paying for it gives a certain degree of assurance.



Well, those who think so can certainly shell out their money.  I have
found that libre software gives me more assurance than commercial;
that support help from friends is more reliable than that I pay for;
and so forth.

I can second that as I've watched quickbooks incorrectly compute taxes 
by a significant margin and had friends work out spreadsheets that just 
work


A


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [Fwd: Re: payroll]

[Conrad Canterford]

On Thu, 2005-05-26 at 09:01 -0700, Andrew Sackville-West wrote:
 Thomas Bushnell BSG wrote:
  Well, those who think so can certainly shell out their money.  I have
  found that libre software gives me more assurance than commercial;
  that support help from friends is more reliable than that I pay for;
  and so forth.
 I can second that as I've watched quickbooks incorrectly compute taxes 
 by a significant margin and had friends work out spreadsheets that just 
 work

Fine. If that works for you, and you're happy with that, great. All I'm
saying is that that is not the case for everyone, and we should be open
to the prospect of paid-for datafiles while at the same time not
requiring them.

In .au there are penalties for getting it wrong (hence my concern that
the data files be accurate), even though in practice the tax office can
claw back any shortfall through the tax return process.

Anyway. I think we're basically in agreement with that.

By the way, the formula types listed do basically match my recollection
of the .au system. If you're doing things strictly accurate, the
formulas are a bit more complicated then that (from memory) but in
practice they match up with this. I'll dig out the appropriate stuff at
some point and double check my memory though, as it has been a few years
since I looked at this.

Note that (as mentioned by other people) there may be a requirement that
the tax amount be rounded to the nearest whole $ amount or (in .au) the
next lowest whole $ amount.

With the interface, I was envisaging something like the standard
register, with perhaps a few extra fields. Not sure how well that will
integrate with g2 as I haven't looked at g2. Also not sure that we'll be
able to meaningfully include that much extra information in the register
format without making it really ugly. But its a thought anyway.

Conrad.

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [Fwd: Re: payroll]

[Stuart D. Gathman]

On Fri, 27 May 2005, Conrad Canterford wrote:

 In .au there are penalties for getting it wrong (hence my concern that
 the data files be accurate), even though in practice the tax office can
 claw back any shortfall through the tax return process.

I agree with the suggestion that the government *ought* to publish 
machine readable tax data at no charge.  Establishing an open format is a
necessary first step in that direction.  Our customers are US importers,
and the US gov publishes quite a bit of machine readable data 
necessary to properly file entries.  That trend needs to grow, if
they expect compliance with ever more complex tax codes.

-- 
  Stuart D. Gathman [EMAIL PROTECTED]
Business Management Systems Inc.  Phone: 703 591-0911 Fax: 703 591-6154
Confutatis maledictis, flamis acribus addictis - background song for
a Microsoft sponsored Where do you want to go from here? commercial.

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: [Fwd: Re: payroll]

[Brian]

On Thu, 2005-26-05 at 18:49 -0400, Stuart D. Gathman wrote:
 On Fri, 27 May 2005, Conrad Canterford wrote:
 
  In .au there are penalties for getting it wrong (hence my concern that
  the data files be accurate), even though in practice the tax office can
  claw back any shortfall through the tax return process.
 
 I agree with the suggestion that the government *ought* to publish 
 machine readable tax data at no charge.  Establishing an open format is a
 necessary first step in that direction.  Our customers are US importers,
 and the US gov publishes quite a bit of machine readable data 
 necessary to properly file entries.  That trend needs to grow, if
 they expect compliance with ever more complex tax codes.
 

In Canada the government publishes their payroll tax info on cd with a
java app to compute the taxes,etc.. FOR FREE :)  Unfortunately, it is
only for WindBlows and MAC. It seems to do just the basic calculations.
No storage of info other than initial config (Company name, # of pay
periods, etc).  They are trying to get away from the printed versions
which cost more to produce and distribute.

I think that if we can get a decent payroll module together with a
straightforward config for the tax formulae that they may even supply
the updates (eventually, if enough users keep requesting it).
-- 
Brian [EMAIL PROTECTED]

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: payroll

[Brian]

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 [EMAIL PROTECTED]

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: payroll

[Andrew Sackville-West]

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
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: payroll

[Andrew Sackville-West]

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
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

error on compile

[Andrew Sackville-West]

so I played around and make a few changes towards the payroll stuff just 
to see if I was getting anywhere and after what appears to be a normal 
autogen.sh I get this...


[EMAIL PROTECTED]:/home/andrew/gnucash# make
cd .  /bin/sh /home/andrew/gnucash/missing --run aclocal-1.7 -I macros 
-I m4

aclocal: configure.in: 39: macro


any ideas?

Files I changed: business-core/gncEMployee.c  .h, 
business-gnome/dialog-employee.c, business-gnone/glade/employee.glade


mostly all minor changes that incorporate just one additional field in 
the gncEmployee struct with a couple of setter and getter functions and 
miscellaneous bits so I could hopedully see if my changes show up...


thanks

A
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel