|
»
»
Re: Adding a Payroll calculator
|
View:
New views
18 Messages
—
Rating Filter:
Alert me
|
 |
|
|
|
Re: Adding a Payroll calculator
by Jay Scherrer
::
Rate this Message:
On Sat, 2005-10-29 at 21:44 -0400, Derek Atkins wrote:
> Quoting Jay Scherrer <jay@...>: > > > 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 with: <http://jay.scherrer.com/payroll.html> 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@... https://lists.gnucash.org/mailman/listinfo/gnucash-devel |
|
|
Re: Adding a Payroll calculator
by Conrad Canterford
::
Rate this Message:
On Sat, 2005-10-29 at 22:48 -0700, Jay Scherrer wrote:
<bits snipped> 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@... https://lists.gnucash.org/mailman/listinfo/gnucash-devel |
|
|
Re: Adding a Payroll calculator
by Andrew Sackville-West
::
Rate this Message:
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@... > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > _______________________________________________ gnucash-devel mailing list gnucash-devel@... https://lists.gnucash.org/mailman/listinfo/gnucash-devel |
|
|
|
|
|
Re: Adding a Payroll calculator
by Andrew Sackville-West
::
Rate this Message:
Jay Scherrer wrote: ><<snip>> > 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@... > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > _______________________________________________ gnucash-devel mailing list gnucash-devel@... https://lists.gnucash.org/mailman/listinfo/gnucash-devel |
|
|
Re: Adding a Payroll calculator
by Jay Scherrer
::
Rate this Message:
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 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; gboolean active; char * language; Account * tax_acc; }; Jay Scherrer _______________________________________________ gnucash-devel mailing list gnucash-devel@... https://lists.gnucash.org/mailman/listinfo/gnucash-devel |
|
|
Re: Adding a Payroll calculator
by Andrew Sackville-West
::
Rate this Message:
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; > gboolean active; > char * language; > Account * tax_acc; > }; > > > Jay Scherrer > > gnucash-devel mailing list gnucash-devel@... https://lists.gnucash.org/mailman/listinfo/gnucash-devel |
|
|
Re: Adding a Payroll calculator
by Jay Scherrer
::
Rate this Message:
<Snipit>
> > > > 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? > 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; > > gboolean active; > > char * language; > > Account * tax_acc; > > }; > > > > > > Jay Scherrer > > > > 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; gboolean active; 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; gboolean active; char * language; Account * tax_acc; }; My .02, Jay Scherrer _______________________________________________ gnucash-devel mailing list gnucash-devel@... https://lists.gnucash.org/mailman/listinfo/gnucash-devel |
|
|
Re: Adding a Payroll calculator
by Derek Atkins
::
Rate this Message:
Quoting Jay Scherrer <jay@...>:
[snip] > Derek Atkins's employee plus a couple more members: > struct _gncEmployee > { > QofInstance inst; > char * id; > char * username; > GncAddress * addr; > gnc_commodity * currency; > gboolean active; > > 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; > gboolean active; > 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 warlord@... PGP key available _______________________________________________ gnucash-devel mailing list gnucash-devel@... https://lists.gnucash.org/mailman/listinfo/gnucash-devel |
|
|
Re: Adding a Payroll calculator
by Jay Scherrer
::
Rate this Message:
On Tue, 2005-11-01 at 23:30 -0500, Derek Atkins wrote:
> Quoting Jay Scherrer <jay@...>: > > [snip] > > Derek Atkins's employee plus a couple more members: > > struct _gncEmployee > > { > > QofInstance inst; > > char * id; > > char * username; > > GncAddress * addr; > > gnc_commodity * currency; > > gboolean active; > > > > 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. > 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. > 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; > > gboolean active; > > char * language; > > Account * tax_acc; > > }; > > How does this deal with a graduated tax? > 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@... https://lists.gnucash.org/mailman/listinfo/gnucash-devel |
|
|
Re: Adding a Payroll calculator
by Derek Atkins
::
Rate this Message:
Jay Scherrer <jay@...> 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 warlord@... PGP key available _______________________________________________ gnucash-devel mailing list gnucash-devel@... https://lists.gnucash.org/mailman/listinfo/gnucash-devel |
|
|
Re: Adding a Payroll calculator
by Andrew Sackville-West
::
Rate this Message:
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; gboolean active; 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; gboolean active; 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@... https://lists.gnucash.org/mailman/listinfo/gnucash-devel |
|
|
Re: Adding a Payroll calculator
by Jay Scherrer
::
Rate this Message:
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. > > > 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; > gboolean active; > 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; > gboolean active; > 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 new variables: employeeHours, employeeTipIncome, businessCombinedTips, businessNumberEmployees businessAllocatedTips, businessIncome. employeeType = tipped employeeWage = (employeeHours * employeeRate); employeeTipIncome = (combinedTips / businessNumberEmployees); /* for Medicare and SSI wages and tips */ businessAllocatedTips = ((businessIncome *.20) / businessNumberEmployees); Because of the allocated tip section on the W-2 we should also offer for businesses a function for calculating this: Allocated tip income = (Business Gross Income * .20) / (number of employees); 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. 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. Jay Scherrer _______________________________________________ gnucash-devel mailing list gnucash-devel@... https://lists.gnucash.org/mailman/listinfo/gnucash-devel |
|
|
Re: Adding a Payroll calculator
by Derek Atkins
::
Rate this Message:
Quoting Jay Scherrer <jay@...>:
>> >>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 warlord@... PGP key available _______________________________________________ gnucash-devel mailing list gnucash-devel@... https://lists.gnucash.org/mailman/listinfo/gnucash-devel |
|
|
Re: Adding a Payroll calculator
by Bugzilla from p_christ@hol.gr
::
Rate this Message:
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@... https://lists.gnucash.org/mailman/listinfo/gnucash-devel |
|
|
Re: Adding a Payroll calculator
by Andrew Sackville-West
::
Rate this Message:
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@... https://lists.gnucash.org/mailman/listinfo/gnucash-devel |
|
|
Re: Adding a Payroll calculator
by Jay Scherrer
::
Rate this Message:
>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@... https://lists.gnucash.org/mailman/listinfo/gnucash-devel |
| Free embeddable forum powered by Nabble | Forum Help |
