Re: Adding a Payroll calculator

[Derek Atkins]

Quoting Jay Scherrer <[EMAIL PROTECTED]>:


Do you think a good place to start would be to add an gnc_employeeType
and a to your class _gncEmployee? Then we could create an editable
member of the tax class to match the companies Labor and Industry's
employee classification. Then would it be wise to add a business class
to gncBusiness.c to include a member like ( gnc_BusinessIndustry and
gnc_BusinessRating for unemployment rates ) or something? Is there a
class for different Job descriptions already? We already know that FICA
and Medicaid are pretty much uniform but still should be adjustable.


Honestly, I don't know..  I suspect the best approach would be to look
at it from the other side.  Figure out what information you need to
compute payroll and write the code that computes that.  Then we can
figure out where to store the necessary information.  Also keep in mind
that Gnucash's payroll system needs to handle more than just US payroll.
(This is where the payroll plugins come in).

Specifically, yes, I can see where you might need to extend GncEmployee
to store information about the employee's salary/rate and payroll types,
and potentially even per-person deduction information.  There is no
"GncBusiness" object; the business information is stored in the book itself.
So, no, nothing to extend there.

I don't know enough about payroll systems to know whether you need an
industry type -- I would think that you could just create appropriate
plugins for various tables and just use a reference to the table in
the data file to know which one to use.  But that's why I think it would
be best to start by figuring out how to compute the payroll and then
work backwards towards object extensions.

I think further discussions should be on gnucash-devel.  You should subscribe
there and follow-ups to this message should go to -devel and not -user.


Jay Scherrer


-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: Adding a Payroll calculator

[Jay Scherrer]

On Sat, 2005-10-29 at 21:44 -0400, Derek Atkins wrote:
> Quoting Jay Scherrer <[EMAIL PROTECTED]>:
> 
> > Do you think a good place to start would be to add an gnc_employeeType
> > and a to your class _gncEmployee? Then we could create an editable
> > member of the tax class to match the companies Labor and Industry's
> > employee classification. Then would it be wise to add a business class
> > to gncBusiness.c to include a member like ( gnc_BusinessIndustry and
> > gnc_BusinessRating for unemployment rates ) or something? Is there a
> > class for different Job descriptions already? We already know that FICA
> > and Medicaid are pretty much uniform but still should be adjustable.
> 
> Honestly, I don't know..  I suspect the best approach would be to look
> at it from the other side.  Figure out what information you need to
> compute payroll and write the code that computes that.  Then we can
> figure out where to store the necessary information.  Also keep in mind
> that Gnucash's payroll system needs to handle more than just US payroll.
> (This is where the payroll plugins come in).
> 
> Specifically, yes, I can see where you might need to extend GncEmployee
> to store information about the employee's salary/rate and payroll types,
> and potentially even per-person deduction information.  There is no
> "GncBusiness" object; the business information is stored in the book itself.
> So, no, nothing to extend there.
> 
> I don't know enough about payroll systems to know whether you need an
> industry type -- I would think that you could just create appropriate
> plugins for various tables and just use a reference to the table in
> the data file to know which one to use.  But that's why I think it would
> be best to start by figuring out how to compute the payroll and then
> work backwards towards object extensions.
> 
> I think further discussions should be on gnucash-devel.  You should subscribe
> there and follow-ups to this message should go to -devel and not -user.
> 
> > Jay Scherrer
> 
> -derek
I would like to use my payroll calculator as an example to start working
with:  although it is written with
html and JavaScript, the basic function's are the same and created in c
pretty easy. The sections that require tables (rates) should be left to
the payroll admin to adjust, they would be notified of the rates by
their state or government. [view source: payroll.html ] I am suggesting
that when an employee is added that a selection of employee type be
offered. And when a Business is created that their respective business
type be recorded. Then as businesses and or employee's are added the
classification they can be entered respectively. The payroll admin
should be given an option if any changes occur by the state to update.
This shouldn't need any sort of subscription just an entry while
creating the employee or business. Any way am I on the right track? How
can I help?
   
payroll.html source
###These rates are based on state notification
##Employee section##
empMedi = document.payroll.medi.value = Math.round(empWages * .0145); 
/* Employee medicare rate */
empSSI = document.payroll.ssi.value = Math.round(empWages * .062);
/* Employee Social security rate */
empFed = document.payroll.fedWit.value = Math.round(empWages * .087);
/* Employee's Federal withholding rate figured from W-4 */
eLandI = document.payroll.empLandI.value = Math.round(empWages * .0256);
/* Employee's portion of L&I insurance */

##Business Section##
sui = document.payroll.stateUnemployment.value = Math.round(empWages * .0276);
/* State unemployment */ 
suio = document.payroll.stateUnemploymentOffice.value = (empWages * .0002);
/* State Unemployment Office expense "Washington" */ 
compLandI= document.payroll.compLandI.value = Math.round(empWages * .2270);
/* Company's L&I portion*/
compMedi = document.payroll.compMed.value = Math.round(empWages * .0145);
/* Company's Medicare portion */
compSSI = document.payroll.compSSI.value = Math.round(empWages * .062); 
/* Company's Social Security portion */

Jay Scherrer

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

Re: Adding a Payroll calculator

[Conrad Canterford]

On Sat, 2005-10-29 at 22:48 -0700, Jay Scherrer wrote:


Jay,
On my very quick look at what you had there, it makes various
assumptions about the structure and nature of the payroll deductions.
Not adaptable to different structures as they exist in different
countries. For example, most of our tax deductions work a graduated
scheme, which does not lend itself to a flat-rate percentage calculation
(and for added complication, often includes a tax-free amount). Other
deductions work as a fixed percentage of the total (like you appear to
be showing).

Your also seem to require the accounts person to know/calculate the
appropriate percentage each time (or rely on the fact that it hasn't
changed from last time) - that is all good for permanent employees with
very little variation, but does nothing for people employing casual
staff for example, where their earnings may vary from week to week.

For reporting purposes, you will almost certainly need to record how
much of each deduction you take from each employee. This could probably
be done in accounts within the gnucash account tree, and might not be
that hard, but you'd need to think about how that was structured. I
admit to having no concept whatsoever how these things are handled in
countries other than my own (I've never employed staff anywhere but
here).

I guess what I'm saying is that such simple approach does not really
solve the problem. Having said that, it might nevertheless provide a
basis for someone else to work on to provide a more generic approach.
I'm actually envisaging something along the lines of a plug-in module
(specific to each country) which calculates those percentages for you
for all the taxes and deductions. Having not seen any code, I cannot say
how practical that might be.

Conrad.

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

Re: Adding a Payroll calculator

[Andrew Sackville-West]

Conrad Canterford wrote:
<< snipping>>

Jay,
On my very quick look at what you had there, it makes various
assumptions about the structure and nature of the payroll deductions.
Not adaptable to different structures as they exist in different
countries. For example, most of our tax deductions work a graduated
scheme, which does not lend itself to a flat-rate percentage calculation
(and for added complication, often includes a tax-free amount). Other
deductions work as a fixed percentage of the total (like you appear to
be showing).


Still other deductions are based on units of work (hours usually). For 
example, in WA state you collect from employees at a rate per hour for 
L&I and also accrue liability for employer at another rate per hour. 
Some of those employees are salaried and have no set hours and in that 
case you have to know to collect on 160 hours per month regardless of 
what hours they work. Also, many taxes hage "wage bases" above which the 
tax does not apply... .


Your also seem to require the accounts person to know/calculate the
appropriate percentage each time (or rely on the fact that it hasn't
changed from last time) - that is all good for permanent employees with
very little variation, but does nothing for people employing casual
staff for example, where their earnings may vary from week to week.

For reporting purposes, you will almost certainly need to record how
much of each deduction you take from each employee. This could probably
be done in accounts within the gnucash account tree, and might not be
that hard, but you'd need to think about how that was structured. I
admit to having no concept whatsoever how these things are handled in
countries other than my own (I've never employed staff anywhere but
here).


Some agencies want reporting based on when work was performed and some 
want it based on when wages were paid.


I guess what I'm saying is that such simple approach does not really
solve the problem. Having said that, it might nevertheless provide a
basis for someone else to work on to provide a more generic approach.
I'm actually envisaging something along the lines of a plug-in module
(specific to each country) which calculates those percentages for you
for all the taxes and deductions. Having not seen any code, I cannot say
how practical that might be.


I have to agree that the problem is definitely NOT simple. However, 
soemthing is better than naught.


A


Conrad.

___
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: Adding a Payroll calculator

[Jay Scherrer]

On Sun, 2005-10-30 at 20:03 -0500, [EMAIL PROTECTED]
wrote:
> 
> Conrad Canterford wrote:
> << snipping>>
> > Jay,
> > On my very quick look at what you had there, it makes various
> > assumptions about the structure and nature of the payroll
> deductions.
> > Not adaptable to different structures as they exist in different
> > countries. For example, most of our tax deductions work a graduated
> > scheme, which does not lend itself to a flat-rate percentage
> calculation
> > (and for added complication, often includes a tax-free amount).
> Other
> > deductions work as a fixed percentage of the total (like you appear
> to
> > be showing).
> 
> Still other deductions are based on units of work (hours usually).
> For 
> example, in WA state you collect from employees at a rate per hour
> for 
> L&I and also accrue liability for employer at another rate per hour. 
> Some of those employees are salaried and have no set hours and in
> that 
> case you have to know to collect on 160 hours per month regardless of 
> what hours they work. Also, many taxes hage "wage bases" above which
> the 
> tax does not apply... .
> > 
> > Your also seem to require the accounts person to know/calculate the
> > appropriate percentage each time (or rely on the fact that it hasn't
> > changed from last time) - that is all good for permanent employees
> with
> > very little variation, but does nothing for people employing casual
> > staff for example, where their earnings may vary from week to week.
> > 
> > For reporting purposes, you will almost certainly need to record how
> > much of each deduction you take from each employee. This could
> probably
> > be done in accounts within the gnucash account tree, and might not
> be
> > that hard, but you'd need to think about how that was structured. I
> > admit to having no concept whatsoever how these things are handled
> in
> > countries other than my own (I've never employed staff anywhere but
> > here).
> 
> Some agencies want reporting based on when work was performed and
> some 
> want it based on when wages were paid.
> > 
> > I guess what I'm saying is that such simple approach does not really
> > solve the problem. Having said that, it might nevertheless provide a
> > basis for someone else to work on to provide a more generic
> approach.
> > I'm actually envisaging something along the lines of a plug-in
> module
> > (specific to each country) which calculates those percentages for
> you
> > for all the taxes and deductions. Having not seen any code, I cannot
> say
> > how practical that might be.
> 
> I have to agree that the problem is definitely NOT simple. However, 
> soemthing is better than naught.
> 
> A
> > 
> > Conrad.
> > 
For discussion, this was why I had at first suggested a payroll
calculator under GnuCash->tools. Using a framework much like the
Financial calculator by letting the user edit any taxable percentages.

Or, as I found your gnc_Employee and gnc_business classes. You could add
a table (class) specifically for payroll taxes that would reflect upon
the nature of the employee and the business. You started by adding a
rate classification.  
Seems only logical to add to the employee class: 
Type key (hourly, salary, commission), 
Job description key (laborer, assembly, management).
And for the Business class:
An industry key, to match the country's industry classifications. 
Example For US: matching the IRS business classification (for LandI
rates).
The entries for these would be presented while one is creating the
company and or employee (GnuCash->Business->Employees->New).
Then these keys would be assigned to an editable field by the account
creator allowing for any changes/updates to the tax tables issued by the
respective governments. These factors would be used when entering any
wage or salary payments to the employee to automatically calculate
deductions.

Just a suggestion.

Jay Scherrer


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

Re: Adding a Payroll calculator

[Andrew Sackville-West]

Jay Scherrer wrote:

<>
For discussion, this was why I had at first suggested a payroll
calculator under GnuCash->tools. Using a framework much like the
Financial calculator by letting the user edit any taxable percentages.

Or, as I found your gnc_Employee and gnc_business classes. You could add
a table (class) specifically for payroll taxes that would reflect upon
the nature of the employee and the business. You started by adding a
rate classification.  
Seems only logical to add to the employee class: 
Type key (hourly, salary, commission), 
Job description key (laborer, assembly, management).

And for the Business class:
An industry key, to match the country's industry classifications. 
Example For US: matching the IRS business classification (for LandI

rates).
The entries for these would be presented while one is creating the
company and or employee (GnuCash->Business->Employees->New).
Then these keys would be assigned to an editable field by the account
creator allowing for any changes/updates to the tax tables issued by the
respective governments. These factors would be used when entering any
wage or salary payments to the employee to automatically calculate
deductions.

Just a suggestion.

Jay Scherrer


IMHO, based on the broad requirements of many jurisdictions in the 
gnucash user base, the more generic the solution the better. I suppose 
that at some point it becomes no easier than using a spreadsheet, but 
bypasses the importing requirements of that solution.


In my past  thoughts on this, it seemed reasonable to come up with a 
handful of different classes of payroll items with all the numbers (tax 
percentages, wage bases, etc) applied directly by the user. Ummm.. sort 
of like setting up tax tables. Create a table, assign a name and a 
variety of features for that particular instance and save it. Then apply 
the appropriate items to each employee as they are created/edited. Is 
this what you are getting at?  Each employee record would point to its 
payroll record and have any number of fields for various requirements 
(wage, taxes, deductions, etc). Some of the fields could have a prompt 
flag that would prompt the user for this information at the time payroll 
is executed. Obvious one would be hours worked, but other could be 
"reported tips" or "reimbursements". IIRC I had narrowed this down to 
just a handle of classes to get most thigns to work. (My knowledge of 
gnucash code is -> 0 and my coding is rusty -> infinity so my vocabulary 
above is probably wrong ;) ).


When you process the payroll, at the point that you execute the payroll, 
the pertinent information is calculated and then stored in the payroll 
transaction (probably in the memo and description fields).


Am I following you correctly? are we talking about the same thing?

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: Adding a Payroll calculator

[Jay Scherrer]

On Mon, 2005-10-31 at 10:16 -0800, Andrew Sackville-West wrote:
> IMHO, based on the broad requirements of many jurisdictions in the 
> gnucash user base, the more generic the solution the better. I
> suppose 
> that at some point it becomes no easier than using a spreadsheet, but 
> bypasses the importing requirements of that solution.
> 
> In my past  thoughts on this, it seemed reasonable to come up with a 
> handful of different classes of payroll items with all the numbers
> (tax 
> percentages, wage bases, etc) applied directly by the user. Ummm..
> sort 
> of like setting up tax tables. Create a table, assign a name and a 
> variety of features for that particular instance and save it. Then
> apply 
> the appropriate items to each employee as they are created/edited. Is 
> this what you are getting at?  Each employee record would point to
> its 
> payroll record and have any number of fields for various requirements 
> (wage, taxes, deductions, etc). Some of the fields could have a
> prompt 
> flag that would prompt the user for this information at the time
> payroll 
> is executed. Obvious one would be hours worked, but other could be 
> "reported tips" or "reimbursements". IIRC I had narrowed this down to 
> just a handle of classes to get most thigns to work. (My knowledge of 
> gnucash code is -> 0 and my coding is rusty -> infinity so my
> vocabulary 
> above is probably wrong ;) ).
> 
> When you process the payroll, at the point that you execute the
> payroll, 
> the pertinent information is calculated and then stored in the
> payroll 
> transaction (probably in the memo and description fields).
> 
> Am I following you correctly? are we talking about the same thing?
> 
> A
Right on target. I my self don't know yet how GnuCash stores the
information into each account. But it would be nice if there was a form
to fill out while performing payroll that resembled a time clock or
pay-stub format (Once hours were entered all the calculations are
preformed).
Of course the other options would include strait salaries and
commissions. But these would be definable at the time of employee
Creation/Hire.

There are two major occurrences of payroll calculation. 
1: performing the actual paycheck calculation.
2: Then reporting the totals for the quarterly tax return. 

Payroll taxes could be members of the Tax class and still be different
from regular sales and income taxes. However Payroll taxes for the us
will be accounted on a quarterly basis with the IRS form 941. 
I myself am very rusty on c but here's a shot. And I haven't the
experience with any GUI's except Perl::Tk and html.

I have used Derek Atkins's _gncEmployee class as a template for this
Example: 

struct _gncTax 
{
  char *  id; 
  char *  taxName;   /* Medicare, SSI, Sales,..etc */
  char *  taxType;   /* Payroll, Payroll, Sales  */
  char *  taxCatagory;/* Employee, Salary, Sale */
  gnc_numeric taxRate;   /* .0145, .062, .893 */
  gnc_numeric taxFrequency; /* hourly, monthly, unit */ 
  gnc_commodity * currency; 
  gbooleanactive;
  char *  language;
  Account *   tax_acc; 
};


Jay Scherrer

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

Re: Adding a Payroll calculator

[Andrew Sackville-West]

Jay Scherrer wrote:

<< snippetty doo dah >>

Right on target. I my self don't know yet how GnuCash stores the
information into each account. But it would be nice if there was a form
to fill out while performing payroll that resembled a time clock or
pay-stub format (Once hours were entered all the calculations are
preformed).
Of course the other options would include strait salaries and
commissions. But these would be definable at the time of employee
Creation/Hire.

There are two major occurrences of payroll calculation. 
1: performing the actual paycheck calculation.
2: Then reporting the totals for the quarterly tax return. 


FOr my own purposes, I accumulate tax liabilities throughout the period 
and with a couple of reports can determine both my outstanding tax 
liabilities and labor expenses (used to calculate FICA, and MCare, among 
others. WHat I can't get is units of work (hours in this case) and there 
would have to be some method of recording that as some taxes are $x.xx 
per hour as opposed to a percentage.


Payroll taxes could be members of the Tax class and still be different
from regular sales and income taxes. However Payroll taxes for the us
will be accounted on a quarterly basis with the IRS form 941. 
I myself am very rusty on c but here's a shot. And I haven't the

experience with any GUI's except Perl::Tk and html.

I have used Derek Atkins's _gncEmployee class as a template for this
Example: 

struct _gncTax 
{
  char *  id; 
  char *  taxName;   /* Medicare, SSI, Sales,..etc */

  char *  taxType;   /* Payroll, Payroll, Sales  */
  char *  taxCatagory;/* Employee, Salary, Sale */
  gnc_numeric taxRate;   /* .0145, .062, .893 */
  gnc_numeric taxFrequency; /* hourly, monthly, unit */ 


is this ---^ used to store what unit the tax is calculated on or 
how often the tax is accumulated? IOW where do you store information as 
what the tax is applied to?


  gnc_commodity * currency; 
  gbooleanactive;

  char *  language;
  Account *   tax_acc; 
};



Jay Scherrer



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

Re: Adding a Payroll calculator

[Jay Scherrer]

> > 
> > There are two major occurrences of payroll calculation. 
> > 1: performing the actual paycheck calculation.
> > 2: Then reporting the totals for the quarterly tax return. 
> 
> FOr my own purposes, I accumulate tax liabilities throughout the period 
> and with a couple of reports can determine both my outstanding tax 
> liabilities and labor expenses (used to calculate FICA, and MCare, among 
> others. WHat I can't get is units of work (hours in this case) and there 
> would have to be some method of recording that as some taxes are $x.xx 
> per hour as opposed to a percentage.
> > 
> > Payroll taxes could be members of the Tax class and still be different
> > from regular sales and income taxes. However Payroll taxes for the us
> > will be accounted on a quarterly basis with the IRS form 941. 
> > I myself am very rusty on c but here's a shot. And I haven't the
> > experience with any GUI's except Perl::Tk and html.
> > 
> > I have used Derek Atkins's _gncEmployee class as a template for this
> > Example: 
> > 
> > struct _gncTax 
> > {
> >   char *  id; 
> >   char *  taxName;   /* Medicare, SSI, Sales,..etc */
> >   char *  taxType;   /* Payroll, Payroll, Sales  */
> >   char *  taxCatagory;/* Employee, Salary, Sale */
> >   gnc_numeric taxRate;   /* .0145, .062, .893 */
> >   gnc_numeric taxFrequency; /* hourly, monthly, unit */ 
> 
> is this ---^ used to store what unit the tax is calculated on or 
> how often the tax is accumulated? IOW where do you store information as 
> what the tax is applied to?
> 
This table would only store the different types and rates of taxes (SSI,
Medicare, State sales tax). For Labor and Industries we are given rates
according to the nature of the business. And with Unemployment we are
give rates according to the rating a business has, length of time and
turnover of employees. 
> >   gnc_commodity * currency; 
> >   gbooleanactive;
> >   char *  language;
> >   Account *   tax_acc; 
> > };
> > 
> > 
> > Jay Scherrer
> > 
> > 
The resulting calculations would come when we combine or the tables. 
Perhaps an example would relate ideas:

Joe Smith a construction laborer [businessCatagory] who is paid hourly
[employeeType] at the rate of $17.50 [employeeRate] an hour. He has
accumulated 86 hours [employeeHours] for this pay period [payPeriod].
Over time is calculated at time and one half [employeeOverTimeRate]. 

To figure this employee's paycheck we would need to figure the
following: employeeOverTime, employeeSSI, employeeMedicare, employeeL&I,
employeeFICA, CompanySSI, CompanyMedicare, companyUnemployment,
companyLandI, PayPeriod.

By using the given: businessCatagory, employeeType, employeeRate,
employeeHours, payPeriod.

The Taxable items are:
Employee's over time
employeeOvertime = (employeeHours - 80) * (employeeOverTimeRate);

Employee's SSI and Medicare
employeeSSI = (employeeRate * employeeHours) * (taxType = SSI = .062); 
employeeMedicare = 
(employeeRate * employeeHours) * (taxType = medicare = .0145);

Company's SSI and Medicare
companySSI = (employeeRate * employeeHours) * (taxType = SSI = .062); 
companyMedicare = 
(employeeRate * employeeHours) * (taxType = medicare = .0145);

Company's Labor and Industries
employeeLandI = (employeeHours * taxType = employeeBusinessCatagory);
*employee's portion
companyLandI = (employeeHours * taxType = businessCatagory);
*Company's portion
*Labor and industries charges by business classification, in this case
Construction Laborer. 

The totals should be stored in one table or [account] that collects
payroll for the whole company. This table will be used when quarterly
taxes are due. And one for the employee.

You see there are at least three classes:
[employee] [business] [tax]

Derek Atkins's employee plus a couple more members:
struct _gncEmployee 
{
  QofInstance inst;
  char *  id;
  char *  username;
  GncAddress *addr;
  gnc_commodity * currency;
  gbooleanactive;
 
  char *  language;
  char *  acl;
  gnc_numeric workday;
  gnc_numeric rate;
gnc_numeric type; /* employeeType */
gnc_numeric overTimeRate; /* employeeOverTimeRate */
 
  Account *ccard_acc;
};

struct +gncBusiness
{
char *  id; 
char *  businessName;   /* Name */
char *  businessType;   /* sole-proprieter, partnership, LLC  */
char *  businessCatagory;/* LandI or IRS listing*/
}

struct _gncTax 
{
char *  id; 
char *  taxName;   /* Medicare, SSI, Sales,..etc */
char *  taxType;   /* Payroll, Payroll, Sales  */
char *  taxCatagory;/* Employee, Salary, Sale */
gnc_numeric taxRate;   /* .0145, .062, .893 */
gnc_numeric taxFrequency; /* hourly, monthly, unit */ 
gnc_commodity * currency; 
gbooleanactive;
char *  language;
Account *   tax_acc; 
};

My .02,
Jay Scherrer

___

Re: Adding a Payroll calculator

[Derek Atkins]

Quoting Jay Scherrer <[EMAIL PROTECTED]>:

[snip]

Derek Atkins's employee plus a couple more members:
struct _gncEmployee
{
 QofInstance inst;
 char *  id;
 char *  username;
 GncAddress *addr;
 gnc_commodity * currency;
 gbooleanactive;

 char *  language;
 char *  acl;
 gnc_numeric workday;
 gnc_numeric rate;
   gnc_numeric type; /* employeeType */
   gnc_numeric overTimeRate; /* employeeOverTimeRate */


technically, gnc_numeric is the wrong type for all but the 'rate'.
the workday and type should be an enum, or a string.


struct +gncBusiness
{
char *  id;
char *  businessName;   /* Name */
char *  businessType;   /* sole-proprieter, partnership, LLC  */
char *  businessCatagory;/* LandI or IRS listing*/
}


There is no 'gncBusiness' object.  This should all go into the QofBook
where it belongs.


struct _gncTax
{
char *  id;
char *  taxName;   /* Medicare, SSI, Sales,..etc */
char *  taxType;   /* Payroll, Payroll, Sales  */
char *  taxCatagory;/* Employee, Salary, Sale */
gnc_numeric taxRate;   /* .0145, .062, .893 */
gnc_numeric taxFrequency; /* hourly, monthly, unit */
gnc_commodity * currency;
gbooleanactive;
char *  language;
Account *   tax_acc;
};


How does this deal with a graduated tax?


My .02,
Jay Scherrer


-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: Adding a Payroll calculator

[Jay Scherrer]

On Tue, 2005-11-01 at 23:30 -0500, Derek Atkins wrote:
> Quoting Jay Scherrer <[EMAIL PROTECTED]>:
> 
> [snip]
> > Derek Atkins's employee plus a couple more members:
> > struct _gncEmployee
> > {
> >  QofInstance inst;
> >  char *  id;
> >  char *  username;
> >  GncAddress *addr;
> >  gnc_commodity * currency;
> >  gbooleanactive;
> >
> >  char *  language;
> >  char *  acl;
> >  gnc_numeric workday;
> >  gnc_numeric rate;
> >gnc_numeric type; /* employeeType */
> >gnc_numeric overTimeRate; /* employeeOverTimeRate */
> 
> technically, gnc_numeric is the wrong type for all but the 'rate'.
> the workday and type should be an enum, or a string.
> 
I think Derek was using the numeric workday for date arithmetic. However
Employee_type should be char * but Employee_overTimeRate should remain a
number.

> > struct +gncBusiness
> > {
> > char *  id;
> > char *  businessName;   /* Name */
> > char *  businessType;   /* sole-proprieter, partnership, LLC  */
> > char *  businessCatagory;/* LandI or IRS listing*/
> > }
> 
> There is no 'gncBusiness' object.  This should all go into the QofBook
> where it belongs.
> 
I was looking for that. In what directory is QofBook located under
gnucash/src/ ? 
> > struct _gncTax
> > {
> > char *  id;
> > char *  taxName;   /* Medicare, SSI, Sales,..etc */
> > char *  taxType;   /* Payroll, Payroll, Sales  */
> > char *  taxCatagory;/* Employee, Salary, Sale */
> > gnc_numeric taxRate;   /* .0145, .062, .893 */
> > gnc_numeric taxFrequency; /* hourly, monthly, unit */
> > gnc_commodity * currency;
> > gbooleanactive;
> > char *  language;
> > Account *   tax_acc;
> > };
> 
> How does this deal with a graduated tax?
> 
We probably could create member functions something like this function I
had created for calculating 2001 income taxes using perl. This should
not be to difficult to convert to "c". It's just a bunch if statements. 

Example: scheduleY1()

This example is used for calculating the income tax for someone who is
married, filing jointly, and earns more then $100,000 according to the
IRS 1040 2001 rates. 

variables: 
[$line41 = wages, $line42 = Tax, scheduleY1 = member function]
## Status = married filing joint ##
sub scheduleY1(){
my $line41 = shift;
if ($line41 >= 0 && $line41 <= 12000){
$line42 = $line41 * .10;
}elsif ($line41 >= 12000 && $line41 <= 46700) {
$line42 = ((($line41 - 12000)* .15) + 12000);
}elsif ($line41 >= 46700 && $line41 <= 112850) {
$line42 = ((($line41 - 46700)* .27) + 6405);
}elsif ($line41 >= 112850 && $line41 <= 171950) {
$line42 = ((($line41 - 112850)* .30) + 24265.50);
}elsif ($line41 >= 171950 && $line41 <= 307050) {
$line42 = ((($line41 - 171950)* .35) + 41995.50);
}elsif ($line41 > 307050) {
$line42 = ((($line41 - 307050)* .38.6) + 89280.50);
}
return $line42;
} 
> > My .02,
> > Jay Scherrer
> 
> -derek
> 
Jay Scherrer

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

Re: Adding a Payroll calculator

[Derek Atkins]

Jay Scherrer <[EMAIL PROTECTED]> writes:

>> >  gnc_numeric workday;
>> >  gnc_numeric rate;
>> >gnc_numeric type; /* employeeType */
>> >gnc_numeric overTimeRate; /* employeeOverTimeRate */
>> 
>> technically, gnc_numeric is the wrong type for all but the 'rate'.
>> the workday and type should be an enum, or a string.
>> 
> I think Derek was using the numeric workday for date arithmetic. However
> Employee_type should be char * but Employee_overTimeRate should remain a
> number.

Actually, now that I look back again (remember, I /am/ Derek ;)
I was ysing the numeric workday in order to handle fractions of
days (or fractions of hours).  But of course this really only
makes sense for a 'default' -- you still need to track actual
hours.  I'll also note that "overTimeRate" is still a "rate" ;)
I meant the workday and the type..

>> > struct +gncBusiness
>> > {
>> > char *  id;
>> > char *  businessName;   /* Name */
>> > char *  businessType;   /* sole-proprieter, partnership, LLC  */
>> > char *  businessCatagory;/* LandI or IRS listing*/
>> > }
>> 
>> There is no 'gncBusiness' object.  This should all go into the QofBook
>> where it belongs.
>> 
> I was looking for that. In what directory is QofBook located under
> gnucash/src/ ? 

  engine

But you don't want to look there.  The information is stored in the
QofBook KVP in the File->Properties hierarchy.  See the business
prefs:

  src/business/business-utils/business-prefs.scm

> We probably could create member functions something like this function I
> had created for calculating 2001 income taxes using perl. This should
> not be to difficult to convert to "c". It's just a bunch if statements. 
>
> Example: scheduleY1()
>
> This example is used for calculating the income tax for someone who is
> married, filing jointly, and earns more then $100,000 according to the
> IRS 1040 2001 rates. 
>
> variables: 
> [$line41 = wages, $line42 = Tax, scheduleY1 = member function]
> ## Status = married filing joint ##
> sub scheduleY1(){
> my $line41 = shift;
> if ($line41 >= 0 && $line41 <= 12000){
>   $line42 = $line41 * .10;
> }elsif ($line41 >= 12000 && $line41 <= 46700) {
>   $line42 = ((($line41 - 12000)* .15) + 12000);
> }elsif ($line41 >= 46700 && $line41 <= 112850) {
>   $line42 = ((($line41 - 46700)* .27) + 6405);
> }elsif ($line41 >= 112850 && $line41 <= 171950) {
>   $line42 = ((($line41 - 112850)* .30) + 24265.50);
> }elsif ($line41 >= 171950 && $line41 <= 307050) {
>   $line42 = ((($line41 - 171950)* .35) + 41995.50);
> }elsif ($line41 > 307050) {
>   $line42 = ((($line41 - 307050)* .38.6) + 89280.50);
> }
> return $line42;

Um, this seems particular hard-coded and not very flexible.  It's even
WORSE if it's in C, because then the numbers aren't user-settable.
You /need/ to support this kind of configuration in a user-settable
method.  How do you propose to do that?

This is why I'm suggesting scheme, because then you can configure this
kind of "function" in scheme and users can change the values without
having to rebuild gnucash.  I'm open to other suggestions, too.  We
can certainly try to create a generalized "graduated tax" in C, but
you'd need to figure out some way to allow the user to configure that.

-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: Adding a Payroll calculator

[Andrew Sackville-West]

This is in response to several above and my own thoughts on it last 
night.


Derek Atkins wrote:



Example: scheduleY1()

This example is used for calculating the income tax for someone who is
married, filing jointly, and earns more then $100,000 according to the
IRS 1040 2001 rates. 

variables: 
[$line41 = wages, $line42 = Tax, scheduleY1 = member function]

## Status = married filing joint ##
sub scheduleY1(){
   my $line41 = shift;
   if ($line41 >= 0 && $line41 <= 12000){
$line42 = $line41 * .10;
   }elsif ($line41 >= 12000 && $line41 <= 46700) {
$line42 = ((($line41 - 12000)* .15) + 12000);
   }elsif ($line41 >= 46700 && $line41 <= 112850) {
$line42 = ((($line41 - 46700)* .27) + 6405);
   }elsif ($line41 >= 112850 && $line41 <= 171950) {
$line42 = ((($line41 - 112850)* .30) + 24265.50);
   }elsif ($line41 >= 171950 && $line41 <= 307050) {
$line42 = ((($line41 - 171950)* .35) + 41995.50);
   }elsif ($line41 > 307050) {
$line42 = ((($line41 - 307050)* .38.6) + 89280.50);
   }
   return $line42;



Um, this seems particular hard-coded and not very flexible.  It's even
WORSE if it's in C, because then the numbers aren't user-settable.
You /need/ to support this kind of configuration in a user-settable
method.  How do you propose to do that?

This is why I'm suggesting scheme, because then you can configure this
kind of "function" in scheme and users can change the values without
having to rebuild gnucash.  I'm open to other suggestions, too.  We
can certainly try to create a generalized "graduated tax" in C, but
you'd need to figure out some way to allow the user to configure that.



WHy not do something like this:

struct _gncTax
{
  char *  id;
  char *  taxName;   /* Medicare, SSI, Sales,..etc */
  char *  taxType;   /* Payroll, Payroll, Sales  */
  char *  taxCatagory;/* Employee, Salary, Sale */
  gnc_numeric taxRate;   /* .0145, .062, .893 */
  gnc_numeric taxFrequency; /* hourly, monthly, unit */
gnc_numeric taxFloor; /* minimum value below which tax is NOT 
applied */
gnc_numeric tax Ceiling; /* max value above which tax is NOT 
applied */
  gnc_commodity * currency;
  gbooleanactive;
  char *  language;
  Account *   tax_acc;
};

This allows you to set tax brackets which would work for US graduated 
taxes by setting a different instance for each bracket with min and max 
values set by the user. But it could also apply to "Wage base" taxes 
like Social Security or Unemployment Tax which both only apply to the 
first $x of wage per year. by setting the taxFloor to 0, and taxCeiling 
to $x then you only tax the first $x wages. etc. you couuld hard code a 
default so that if tax Ceiling is $0 then the tax always applies (i.e. 
medicare).


I think we might need something like this as well:

struct _gncPayrollItem
{
  char *  id;
  char *  PIName;   /* name of the item */
  char *  PIType;   /* addition or deduction  */
  Account *  PIAccount;/* account linked to this Item (can be 
blank, can we do that with Account?) */

  gbooleantaxable; /* some items are taxable */
/* some method of determining which taxes apply??? */
  gnc_numeric PIAmount;   /* the amount */
  gnc_commodity * currency;
  gbooleanactive;
  char *  language;

};

I really don't know what I'm doing here as far as gnc code goes, but it 
works like this. Everything that is part of a paycheck has to be 
associated with an _gncPayrollItem. Each of these items is previsouly 
set-up by the user and linked to the employee. you can have one for 
wages, one for employee mileage reimbursements, one for reported tips 
(and then another one to deduct the employee tips back out), one for 
reclaiming employee advances etc. etc. etc. This idean is stolen right 
out of QB by  the way The point is there are lots of other things 
that go on in payroll besides taxes and any reasonable solution, in my 
mind, needs to include these things. So you can have an employee with a 
variety of _gncTax applied and a variety of _gncPayrollItem applied to 
build up the whole transaction.


For those that question the tips portion above it works like this: If 
you have tipped employees (/me) then you have to tax them on their tips 
so their tips are included in the Total Wages before taxes are 
calculated. Then those tips are deducted back out (because the employee 
already has them) out of the final paycheck.


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

Re: Adding a Payroll calculator

[Jay Scherrer]

On Wed, 2005-11-02 at 09:33 -0800, Andrew Sackville-West wrote:
> This is in response to several above and my own thoughts on it last 
> night.
> 
> Derek Atkins wrote:
> >
> >>Example: scheduleY1()
> >>
> >>This example is used for calculating the income tax for someone who is
> >>married, filing jointly, and earns more then $100,000 according to the
> >>IRS 1040 2001 rates. 
> >>
> >>variables: 
> >>[$line41 = wages, $line42 = Tax, scheduleY1 = member function]
> >>## Status = married filing joint ##
> >>sub scheduleY1(){
> >>my $line41 = shift;
> >>if ($line41 >= 0 && $line41 <= 12000){
> >>$line42 = $line41 * .10;
> >>}elsif ($line41 >= 12000 && $line41 <= 46700) {
> >>$line42 = ((($line41 - 12000)* .15) + 12000);
> >>}elsif ($line41 >= 46700 && $line41 <= 112850) {
> >>$line42 = ((($line41 - 46700)* .27) + 6405);
> >>}elsif ($line41 >= 112850 && $line41 <= 171950) {
> >>$line42 = ((($line41 - 112850)* .30) + 24265.50);
> >>}elsif ($line41 >= 171950 && $line41 <= 307050) {
> >>$line42 = ((($line41 - 171950)* .35) + 41995.50);
> >>}elsif ($line41 > 307050) {
> >>$line42 = ((($line41 - 307050)* .38.6) + 89280.50);
> >>}
> >>return $line42;
> > 
> > 
> > Um, this seems particular hard-coded and not very flexible.  It's even
> > WORSE if it's in C, because then the numbers aren't user-settable.
> > You /need/ to support this kind of configuration in a user-settable
> > method.  How do you propose to do that?
> > 
> > This is why I'm suggesting scheme, because then you can configure this
> > kind of "function" in scheme and users can change the values without
> > having to rebuild gnucash.  I'm open to other suggestions, too.  We
> > can certainly try to create a generalized "graduated tax" in C, but
> > you'd need to figure out some way to allow the user to configure that.
> > 
> 
Actually, this example was pulled right off of my head perhaps I had
jumped to far ahead. This example has to be hard coded because that is
the way the IRS stipulates this calculation according to pub 17. The
standard deductions of earnings above $100,000. But what I was trying to
show is that, If we have classes with user defined entries (wages,
hours, rates) then we would define functions as prototypes attached to
the particular calculation of mixed members and classes.   
> WHy not do something like this:
> 
> struct _gncTax
> {
>char *  id;
>char *  taxName;   /* Medicare, SSI, Sales,..etc */
>char *  taxType;   /* Payroll, Payroll, Sales  */
>char *  taxCatagory;/* Employee, Salary, Sale */
>gnc_numeric taxRate;   /* .0145, .062, .893 */
>gnc_numeric taxFrequency; /* hourly, monthly, unit */
>   gnc_numeric taxFloor; /* minimum value below which tax is NOT 
> applied */
>   gnc_numeric tax Ceiling; /* max value above which tax is NOT 
> applied */
>gnc_commodity * currency;
>gbooleanactive;
>char *  language;
>Account *   tax_acc;
> };
> 
> This allows you to set tax brackets which would work for US graduated 
> taxes by setting a different instance for each bracket with min and max 
> values set by the user. But it could also apply to "Wage base" taxes 
> like Social Security or Unemployment Tax which both only apply to the 
> first $x of wage per year. by setting the taxFloor to 0, and taxCeiling 
> to $x then you only tax the first $x wages. etc. you couuld hard code a 
> default so that if tax Ceiling is $0 then the tax always applies (i.e. 
> medicare).
> 
> I think we might need something like this as well:
> 
> struct _gncPayrollItem
> {
>char *  id;
>char *  PIName;   /* name of the item */
>char *  PIType;   /* addition or deduction  */
>Account *  PIAccount;/* account linked to this Item (can be 
> blank, can we do that with Account?) */
>gboolean taxable; /* some items are taxable */
> /* some method of determining which taxes apply??? */
>gnc_numeric PIAmount;   /* the amount */
>gnc_commodity * currency;
>gbooleanactive;
>char *  language;
> 
> };
> 
> I really don't know what I'm doing here as far as gnc code goes, but it 
> works like this. Everything that is part of a paycheck has to be 
> associated with an _gncPayrollItem. Each of these items is previsouly 
> set-up by the user and linked to the employee. you can have one for 
> wages, one for employee mileage reimbursements, one for reported tips 
> (and then another one to deduct the employee tips back out), one for 
> reclaiming employee advances etc. etc. etc. This idean is stolen right 
> out of QB by  the way The point is there are lots of other things 
> that go on in payroll besides taxes and any reasonable solution, in my 
> mind, needs to include these things. So you can have an employee with a 
> variety of _gncTax applied and a variety of _gncPayrollItem applied to 
> build 

Re: Adding a Payroll calculator

[Derek Atkins]

Quoting Jay Scherrer <[EMAIL PROTECTED]>:


>>variables:
>>[$line41 = wages, $line42 = Tax, scheduleY1 = member function]
>>## Status = married filing joint ##
>>sub scheduleY1(){
>>my $line41 = shift;
>>if ($line41 >= 0 && $line41 <= 12000){
>>$line42 = $line41 * .10;
>>}elsif ($line41 >= 12000 && $line41 <= 46700) {
>>$line42 = ((($line41 - 12000)* .15) + 12000);
>>}elsif ($line41 >= 46700 && $line41 <= 112850) {
>>$line42 = ((($line41 - 46700)* .27) + 6405);
>>}elsif ($line41 >= 112850 && $line41 <= 171950) {
>>$line42 = ((($line41 - 112850)* .30) + 24265.50);
>>}elsif ($line41 >= 171950 && $line41 <= 307050) {
>>$line42 = ((($line41 - 171950)* .35) + 41995.50);
>>}elsif ($line41 > 307050) {
>>$line42 = ((($line41 - 307050)* .38.6) + 89280.50);
>>}
>>return $line42;
>
>
> Um, this seems particular hard-coded and not very flexible.  It's even
> WORSE if it's in C, because then the numbers aren't user-settable.
> You /need/ to support this kind of configuration in a user-settable
> method.  How do you propose to do that?
>
> This is why I'm suggesting scheme, because then you can configure this
> kind of "function" in scheme and users can change the values without
> having to rebuild gnucash.  I'm open to other suggestions, too.  We
> can certainly try to create a generalized "graduated tax" in C, but
> you'd need to figure out some way to allow the user to configure that.
>


Actually, this example was pulled right off of my head perhaps I had
jumped to far ahead. This example has to be hard coded because that is
the way the IRS stipulates this calculation according to pub 17. The
standard deductions of earnings above $100,000. But what I was trying to
show is that, If we have classes with user defined entries (wages,
hours, rates) then we would define functions as prototypes attached to
the particular calculation of mixed members and classes.


My point is that this needs to be data driven.. We can't hard-code 
these values

into the source code.  Instead, we need some way to provide the set of
variables to compute it.  E.g.  [ 0 , 12000, 0.10 ], [ 12001 , 47600 , 0.15 ]
...

My point is that we need some datafile that defines these values, not C code.

[snip]

I think now that we/I am starting to understand payroll. It's do-able as
long as we have some sort of user definitions that can be updated by the
payroll admin. Plus, I am in the midst of an Income tax course, so the
requirements are fresh in mind. Let me try to compile a simple payroll
program using c over the weekend.


Yes, exactly.  We need some user-updatable definitions (in particular the
tax tables!) that we can "execute" on employee data.  I think for your testing
you could just create a bunch of arrays or something, but just make sure you
don't make assumptions about how many tax brackets there are or what 
the values

or rates of those brackets are in the actual computations.


Some items for thought: based on 2004
Social security is withheld at 6.2% on all employees up to $87,900.
Employees are taxed 1.45% on all wages and tip for Medicare.


Just keep in mind that there are state taxes, local taxes, various other
deductions (pre-tax and post-tax).   We should really generalize this out as
much as we can.


Jay Scherrer


-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: Adding a Payroll calculator

[P. Christeas]

Derek Atkins wrote:
>...
> Yes, exactly.  We need some user-updatable definitions (in particular the
> tax tables!) that we can "execute" on employee data.  I think for your
> testing you could just create a bunch of arrays or something, but just make
> sure you don't make assumptions about how many tax brackets there are or
> what the values
> or rates of those brackets are in the actual computations.
>
> > Some items for thought: based on 2004
> > Social security is withheld at 6.2% on all employees up to $87,900.
> > Employees are taxed 1.45% on all wages and tip for Medicare.
>
> Just keep in mind that there are state taxes, local taxes, various other
> deductions (pre-tax and post-tax).   We should really generalize this out
> as much as we can.
>
> > Jay Scherrer
>
> -derek


I may have joined the discussion late, but let me add a wish:
Whatever you do with the machine (Language, implementation etc.) you *should* 
provide a verification, in the form of showing which rule was used for the 
calculation:
You may end up with a hard-coded, flexible function which takes many arguments 
from a table. You may find some extension language/equation evaluator. But 
let the way be visible to the user, just by the form field, or some report.
Say: you end up with tax= $123.45  . Then show some hint indicating that this 
was computed based on the xx field (on gnc accounts), using the 8th row of 
the tax tables (and even the equation itself).

IMHO the user wouldn't feel comfortable just by looking at a result. 
Especially after he has entered himself the tables, he will want to verify 
that they work as planned.

In C, this would mean some extra programming effort. Having the parameters 
accessible to third functions, that is.

I hope I'm saying something useful here.. :)
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Adding a Payroll calculator

[Andrew Sackville-West]

P. Christeas wrote:

IMHO the user wouldn't feel comfortable just by looking at a result. 
Especially after he has entered himself the tables, he will want to verify 
that they work as planned.


I think its reasonable to assume that if a user is actually running 
their own payroll, they have a good general knowledge of how payroll 
works. If they have created their own tax tables and brackets based on 
the information they recieve from their respective governments, then the 
only thing the user has to be comfortable with is the accuracy of the 
*calculations* and the accuracy of the information he or she has 
manually entered.


Derek Atkins wrote:

>>...
>> Yes, exactly.  We need some user-updatable definitions (in 
particular the

>> tax tables!) that we can "execute" on employee data.  I think for your
>> testing you could just create a bunch of arrays or something, but 
just make

>> sure you don't make assumptions about how many tax brackets there are or
>> what the values
>> or rates of those brackets are in the actual computations.

This is why I used the taxFloor and taxCeiling fields. You could easily 
set up a series of these


TaxBracket1
Floor = 0
Ceiling = 12000
Rate = .10

TaxBracket2
Floor > 12000
Ceiling = X
Rate = .15

etc.

THen you can apply each of these items to the payroll and get your tax 
computed accurately.


I agree that the more general the solution the better. I also agree that 
setting a lot of this up in Scheme is probably better. If a solution 
doesn't work for someone it would be relatively simple to make adjustments.


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

Re: Adding a Payroll calculator

[Jay Scherrer]

>Snip>
On Wed, 2005-11-02 at 17:36 -0500, Derek Atkins wrote:
> Yes, exactly.  We need some user-updatable definitions (in particular
> the
> tax tables!) that we can "execute" on employee data.  I think for your
> testing
> you could just create a bunch of arrays or something, but just make
> sure you
> don't make assumptions about how many tax brackets there are or what 
> the values
> or rates of those brackets are in the actual computations.. 
Since I come from a state that doesn't have an income tax (Washington),
I wasn't paying attention. Do you calculate state income tax much like
the federal? Is this why you keep referring to tax tables and brackets?
Because I was referring to tables and classes in the same conjunction as
a database table. If it would help I have a very reliable tax calculator
in case you have already seen partly ( scheduleY1() calculations). This
program figures the Individual income tax using the current IRS Tax
tables by parsing the actual ASCII based file (if needed), or the
schedules X, Y-1, Y-2, and Z if required. This is written in Perl cause
I don't know how to parse ASCII using c. And was created for web based
Tax calculations. If you could use these calculations in the State or US
income tax, let me know. But for now I was concentrating on the Payroll
side of things.  

Calculating payroll taxes:  
> > Some items for thought: based on 2004
> > Social security is withheld at 6.2% on all employees up to $87,900.
> > Employees are taxed 1.45% on all wages and tip for Medicare.
> 
For the US, the IRS has their own set of rates. (pretty straight
forward) And entered on the form 941.

> Just keep in mind that there are state taxes, local taxes, various
> other deductions (pre-tax and post-tax). We should really generalize
> this out as much as we can.
> 
For the State and local payroll, they have their own rates. These
definitely should need a user defined input.



The end results should consist of these views:
1. Employee time clock. viewed by(employer/employee?)frequency(daily) .
2. Paycheck and stub. viewed by (employee) frequency (pay period).
3. Employer's form 941. viewed by (employer) frequency (Quarterly).
4. form W-2. viewed by (employee) frequency (annually).

And I'll work backwards,
Jay Scherrer




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