Re: An Actual Payroll Module - When?

[Chris Travers <..hidden..>]

On Mon, Jan 31, 2011 at 3:36 PM, Luke <..hidden..> wrote:
> On Mon, 31 Jan 2011, Chris Travers wrote:
>
>> 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.
>
> The idea of having jurisdiction based stored procedures, as opposed to a
> wider set of generalized procedures, seems like asking for trouble imo.
>
> There has to be a way to get general enough that some spreadsheet like
> logic can be plugged in to fill gaps, with stored procedures to implement
> it.

You'd think so....  And indeed it might work for a very few
jurisdictions.....  I really wouldn't count on it though!

Payroll taxes can be extremely complex things.  Some taxes can be
charged per hour that an employee is working, some can be charged as a
percentage of earnings, and some can be charged as a percentage of a
portion of earnings (Social Security tax in the US).  A few can be
charged as variable percentages of earnings based on a variety of
parameters, such as US federal income tax withholding, and the
formulas can vary year to year as well as employee to employee.  Some
are charged entirely to the employee.  Some are allotted in part to
the employee and in part to the employer.

Indeed, I don't see how I can get down below two stored procedures for
US federal payroll taxes (one for income tax withholding, and one for
social security and medicare).

Some of these may allow for accountants to configure, but most of
these parameters are jurisdiction specific.
>
> I'm thinking:
> These are the variables--we need to get from X information (available) to
> Y information (to-be-available).
> Pull a record from table Z that is specific to an employee class.
> That record, having been added during module config, contains whatever
> calculations are necessary to convert X to Y, in spreadsheet-like
> compatible form.
>
> That leaves the end user having to configure the module.  That would
> involve entering a set of spreadsheet-like functions to do what needs to
> be done, which could be obtained wherever such things are regularly sold
> (E.G. the accountant who would otherwise setup your Excel sheets for this
> purpose).

How would this handle different tax brackets for different employees?
Do we recreate a spreadsheet-like scripting language in LSMB?  If so,
isn't that an inner platform?
>
> Doing it in that, admittedly possibly un-doable, way, would eliminate the
> need to employ a LedgerSMB-familiar programmer to configure the
> jurisdictional stored procedures for you, or having you or someone track
> localities, which I could see getting out of hand.
>
> Maybe even absorb some external spreadsheet library or project to handle
> this, so that one could just import an Office or XLS sheet.

Importing a sheet is not a problem.  If someone wants payroll that
only processes ready-made data, we will have transaction import addons
for 1.3 (backportable for 1.2), but that doesn't do any of the
calculations.  It just imports GL transactions and maybe links them to
an employee record.  That would be easy.  We can do that.  (Typically,
I'd suggest importing from CSV though.)

If folks need a payroll solution, chances are they don't want a
payroll solution that requires them to build one on a spreadsheet
first, though again if this is needed it would not be expensive to pay
me to pull this over for 1.2 and modify for this purpose.
>
> I may not be describing this well, but the objective of what I'm saying,
> is to generalize as much as necessary in DB code, and leave the locality
> specifics up to a more common language, that the normal power user or his
> tax pro has some hope of being able to handle.  Even if it's not a great
> hope, at least it's "we use a standard spreadsheet type interface to
> handle this", which makes the situation seem manageable.

Well, I guess I am looking at this differently.

The general hope is that a system can provide a platform for payroll
functionality which will allow several users to share the maintenance
expense.  If you have, say, 5 users in a tax jurisdiction each of
which pays $200 per year, that's maybe $500 to keep up on tax law in
the jurisdiction and $500 to implement changes on average every year.
If, on the other hand, they have to hire someone to fix everything
themselves, it could cost quite a bit more for a single customer.

This is an area where there is a lot of room for other players in the
marketplace.  I don't have the resources to do it by myself, but I
would be very happy to partner with others to make it happen.

Best Wishes,
Chris Travers