[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: An Actual Payroll Module - When?

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.

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).

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.