Re: [SL] Payroll

[Jeff V. <jv...@ch...>]

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.  

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.

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.

> > My approach would be to do this for one country at a time and then add
> > additional countries as the need arises and time permits.  A separate
> > payroll module for each country, with the processing output being
> > plugged into the GL is likely required in order to make it flexible
> > enough for all environments.
> 
> That type of approach only makes this module look more difficult than it 
> really is.
> 

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.

> > A complete knowledge of the requirements for each country/state will be
> > needed and the ability to do updates to the calculations (percentages,
> > etc.) as changes occur will be mandatory. 
> 
> Nope.  Currently, I use Peachtree for my payroll.  I haven't paid for 
> their tax tables since I bought the software.  I have manually entered 
> my deduction tables since then.
> 

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.

> Look, payroll is not rocket science.  If you think it is, your 
> accountant (or your payroll contractor) has kept you in the dark for far 
> too long. Payroll is quite simple, as some have indicated by still using 
> ledgers, pens, and adding machines.
> 
> There is NOTHING (as least here in Ohio) that has to be filed 
> electronically.  I mean NOTHING. Not on any Federal, State or local.
> 
> Kent
> 

Exactly, but reports will have to be designed to provide the values
needed for you to fill in the periodic reports that do need to be filed
- monthly, quarterly, or whenever.