[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: An Actual Payroll Module - When?
- Subject: Re: An Actual Payroll Module - When?
- From: Luke <..hidden..>
- Date: Mon, 31 Jan 2011 18:36:34 -0500 (EST)
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
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
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
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.
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.
Just my $.02.