Re: [SL] Payroll

[Santoken <san...@br...>]

Jeff Vian wrote:

> On Mon, 2004-10-11 at 17:06, Santoken wrote:
> 
>>Jeff Vian wrote:
>>
>>
>>>Just from my limited experience in doing payroll for one company, in the
>>>US there are things like medicare, ssa, FUTA, SUTA, state income,
>>>federal income, local taxes, and probably others I have missed. 
>>>There are also withholdings for IRAs, stock purchase plans,
>>>garnishments, medical savings plans, insurance plans, etc.
>>
>>Yes...so, what you are saying is we start with a big number (gross 
>>income) and do some deductions (some will be percentages, others static 
>>numbers, etc.) and then we are left with a smaller number...that's the 
>>total of the paycheck, right?
>>
>>
>>>This will be a very complex issue even if only addressed for one
>>>country, and making it multinational will be even more.
>>
>>Complex?  Hardly.  Look, doing payroll (as I and my company have been 
>>doing for 8+ years now) is nothing more than simple math.  You start 
>>with a big number, subtract some numbers or percentages from it, and the 
>>total left is the check amount.  Granted, there are other things 
>>happening in the background, but it's hardly more complicated than this.
>>
> 
> 
> The complexity is not in doing the math, but in making the interface
> easy to use and easy to update values.  Even worse is the need to make
> it intuitive on "how to get there from here."  Many (probably most)
> users don't care about the backend, as long as the interface is friendly
> and easy to use and the results are accurate.  

Making the interface easy to use?  What exactly do you mean there? 
Again, this is only payroll, there is no need to make it more 
complicated than it already is not.  Look, starting with only the basics 
and keeping it at that is all that is needed.  You offer an employee 
maint. screen, a deduction maint. screen, a payroll generation screen 
and a payroll report screen.  What more is needed?

Of course most users don't care about the backend...they want a software 
package that works...that's all.  Frankly, they just have a job to do 
and when that's done, they go on with their lives.  Most users of an 
office package could give a whit how it gets the job done, they just 
want the job done, done right, and done easily.

> As I see it, the hardest programming part will be in defining what
> deductions apply to which employees and when. Then making the interface
> and automation handle that correctly with suitable reports and data
> entry screens.

Again, applying the defined deductions (defined in the deduction screen) 
to the appropriate employees can be easily maintained in the employee 
maint. screen I proposed.

> The interface and making it flexible enough to encompass many different
> locales  will require some basic knowledge of what is needed in each
> locale.  Once the requirements are known the actual implementation
> should be fairly straight forward and similar to what Chris is already
> working on.

The only reason it would need to be flexible enough is if it becomes 
over-complicated.  If it is kept simple enough to allow the user to 
create, enter, and maintain the deduction tables, then specify which 
employees those deductions apply to or which deductions apply to which 
employees.  No point it making it so structured and complicated that the 
package I use a person in Oz or UK can't use it.  Essentially, the core 
of payroll is the same everywhere, you start with gross, deduct, end 
with net.  Again, payroll is simple math.

> Not really - divide and conquer.  Once it is done for one locale, the
> modifications to fit additional areas become simple and in many cases
> obvious.

Again, why make it so difficult and complicated that what works here 
won't work there.  I guess that what I'm saying is that the procedure 
that (if I did payroll manually) not really any different than the way 
the do payroll in Canada, Europe, etc.  So, why not make the module work 
the same way?  To approach payroll in any other fashion is insane!  :)

> You may the updates to the taxes tables manually, but do you have all
> the knowledge of what is required in all situations?  And do you know
> how to make the software do what peachtree does in the background?  If
> so, please collaborate and help produce the modules to make this happen.

Knowledge of what is required in all situations?  What do you mean by 
situations?  Again, you start with gross pay, make deductions, you are 
left with net pay...you write the check.  Regarding whether "I know how 
to make the software do what peachtree does in the background," I do 
not.  I am not a coder, as I said in an earlier email...I dabble with 
perl, sql, C, etc.  However, what little bit of dabble I do, I can tell 
you that what is needed for a payroll module is far from complex.

Regarding your last statement, about collaborating and making this 
happen, at first I took that as a personal slam and a 'put your money 
where your mouth is' type statement.  Then, I got to thinking about it. 
  If you'll notice, I started the heated debate about payroll and I've 
been the one keeping it going, continuing to debate my point.  I'm not a 
programmer, I'm a computer hack and a small business owner.  I don't 
have the time to devote learning perl enough to create a payroll module. 
  I don't have to, I pay money to people that do...you can ask Dieter. 
However, SL has everything that I need...save for payroll.  SL has 
matured to the point that it needs to offer a payroll module...that's 
just the way it is.  Anyone that says different, or offers a crude 
workaround, is blind to the potential of SL.  Besides, do you really 
want a hack to come along and make a module and show up all the 
programmers on this list?  :)

Kent