Re: An Actual Payroll Module - When?

[Chris Travers <..hidden..>]

On Mon, Jan 31, 2011 at 9:08 AM, ERACC Subscriptions <..hidden..> wrote:
> On Sun, 2011-01-30 at 17:37 -0800, Chris Travers wrote:

>
> I would hope that would be of interest to more people than just me. As
> you can see the inquiries I have gotten are from all over the USA: one
> from Alaska, one from New York, two from Florida, one from Oregon. So
> these are not local to me and I have no clue about the local tax
> problems in these locations. In most cases they wanted a preconfigured
> POS system shipped to them with remote support for setup help if
> necessary. One was just looking for a general small business accounting
> package.
>
> All those mentioned were looking for FOSS software with Payroll. The one
> requirement I could not meet with LedgerSMB was Payroll. I really *want*
> to promote LedgerSMB over the other solutions offered on our web page. I
> did not get the business of any of these, so they are not my customers
> at this point. I am thinking of the future.
>
> A framework for Payroll where the end-user could set up a module for
> local requirements would be better than nothing. Actually that would
> probably be the best solution so that when changes to local tax laws
> occur the end-user could reconfigure the module. Of course this would
> require the end-user to either have knowledge of local Payroll
> requirements or hire an accountant that does. ...

The more I have looked into payroll stuff, the less I am convinced
that it is possible to have an end-user configure the rules.  There
can be subtle differences between jurisdictions about acceptable
practices.  If one ends up with a system that is truly configurable by
a non-programmer, I think we'd have a bad case of inner platform
syndrome.

For example, in Washington State, some payroll taxes only address some
forms of labor.  Other forms of labor are exempt from specific payroll
deductions.  This is a big deal where agriculture is concerned.

The way commercial offerings address this is to offer payroll on a
subscription basis.  I think there is a possibility for someone to
offer update subscriptions for specific jurisdictions, and so this is
what my current approach is favoring.

My current approach is to create an add-on for tracking deductions and
categorizing them.  Then jurisdiction-specific stored procedures would
be maintained for doing the actual payroll calculations.  I can't
think of a better way of doing it than this.

Like sales tax, this is something that seems easy until you come
across a jurisdiction that has crazy rules.  But unlike sales tax, the
rules under the best case scenario are not simple.  One of the things
we have done for 1.2 and 1.3 is to allow pluggable sales tax logic to
cover crazy jurisdictions.

As I say, I could have a federal module out pretty quickly which only
addresses federal income tax, medicare withholding, and social
security.   I could also come up with an estimate for producing local
jurisdiction procedures to a specific customer's needs.  I couldn't do
it on a subscription basis because I don't have the staff to track all
these jurisdictions and what changes might occur.  However, we could
get something started.  Would it be possible to talk further on the
phone?

Best Wishes,
Chris Travers