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: GnuCash design / new features

[Brian Rose]

Hi all,



1. OSX already has GnuCash via X11 and Fink (there could be licence problems 
with a native Cocoa port and it is not being considered).


Ok.
2. KDE can run GnuCash if the Gnome libraries are installed. KDE also has it's 
own alternatives to GnuCash.


Just a thought.

3. The web page idea is FAR more difficult than you may imagine and NONE of 
the work above even comes close to a HTML/PHP/Perl front end. I've done work 
on QSF (XML) which *could* be used to render GnuCash (and other QOF) data as 
HTML for purposes of data mining and customised reports but that's definitely 
as far as it goes.


Hmm, I was hoping it would be possible to use 
Gnucash via the desktop for one user
and via a webpage for another user 
simultaneously--maybe that is a longer way off than

I thought.

2. Mozilla designed for plugins from the very earliest stages, it's not easy 
to build a system into an existing program.


True.

3. Plugins can only go so far and still won't meet everyone's needs. IMHO, it 
is better to provide easier, more robust access to the data itself and let 
users handle it in Perl or PHP, Python or whatever. QSF is a flavour of XML 
that has a Schema and is intended to provide this simple and flexible data 
access.






http://www.data-freedom.org/


Well, the site explains the theory pretty well. 
However, I am throwing out ideas for
consideration to make Gnucash "tasty" to an 
enduser/small business owner who isn't
a Linux guy--e.g., avoids the command-line and 
doesn't want to code.



What functionality do you want in your module?


Well, for one it would be really awesome if the 
invoice template was similar to iBiz,
http://www.iggsoftware.com/ibiz/index.html . My 
wife uses iBiz. I don't like a lot of it--(it
is to click-happy for me), however the invoice 
template creator is pretty good. It uses a
"web template" like method of specifying where 
everything goes for an invoice template.
Highly flexible, but using a GUI and a template 
creator.





It seems very daunting 
and time consuming.



There's no escaping that one. Developing in gnucash could quite easily consume 
150% of your available time. The discipline to control that must come from 
you, as must the motivation to persist.




Most any project is similar that way, isn't it?


So I guess it depends on your motivation, your perspective and your "itch".

...
 We each need our own "itch" for motivation.


Are you happier in GUI development or CLI or both?

Web dev and backend stuff is where I am most 
comfortable.



What's your itch?

Well, I am not sure other than above on invoices 
and what others have mentioned in

this thread.

My primary purpose is speaking up is because I 
want to help enable more productivity
and more small business users and hence a better, 
stronger Gnucash.


Derek mentioned that there were enough web 
programmers. Is there a need for people
to port documentation from the dev list and 
doxygen to the web to help enable new
programmers with Gnucash to be productive more 
quickly?


Sincerely,
Brian

--
Contagious Design!
web . design . photo

Brian Rose .  web programmer
(604)-630-2426 . brianATcontagiousdesignDOTnet

___
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