Re: Tentative Schedule for 1.4

[John Locke <..hidden..>]

On 02/23/2012 04:20 PM, Chris Travers wrote:

Payroll varies a tremendous amount from state to state and from country to country.  What we will have will be a framework for building systems which provide payroll functionality.  It isn't clear yet which locations will be supported.  Because of the fact that rules tend to change frequently, I think this is likely to be a framework which allows local or regional businesses (working with me or on their own) to create payroll systems.

I think we'll be able to plug in appropriate rules if there's a model we can use to get started.

Main things I'm thinking about needing here:

- tracking employer, employee contributions to each of the various taxes we need to pay, with variable rates for each. e.g. unemployment insurance varies quarter by quarter and employer by employer.

- tracking accumulation of PTO (Paid time off) which in our case accumulates per hour worked for hourly employees, and per pay period for salaried -- probably need to support a variety of rules based on company policy

- tracking usage of PTO

- we do PTO instead of splitting out sick leave, vacation, etc but a payroll system needs to accommodate these things

- calculate overtime per week

- schedule tax payments, post to correct accounts

- quick bulk entry of hours per pay period -- we don't use the LSMB timecard feature, we have another system for this.

I would like to make some UI improvements using Dojo Toolkit, but this
will be so much easier to do when there's a web services back end.

Web services are on the road map.  I guess my main question to everyone on the list is what I can do to facilitate contributions in this area? 

Right now I am thinking of reviving Jason Rodrigues's work on this area.and setting it up so that we can get more involvement in actually hooking it into old or new code.

At this point, I still don't have that much time to contribute. If there's a framework in place for this, I'd probably be able to do some fleshing out of individual resources.

Ideally web services, like reporting, would happen after the main transactional functionality is stable enough for early beta testing.

I think the first step is getting a framework in place that defines the endpoints, the formatting of the data, etc. Something that converts a web service payload into some sort of Perl object that can be populated based on LSMB data.

Then it's a matter of doing that mapping between the web service and the LSMB data structures. I would think there's some low hanging fruit here:

* account list, to populate GL transactions
* vendor/customer lists
* part lookups
* menu lookup

Without getting into any financial transactions at all at first, just providing simple access to JSON-formatted data for those items would facilitate making the user interface much nicer. Even if it's read-only to start...

Cheers,
John Locke
http://www.freelock.com