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
------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
