On Fri, Feb 24, 2012 at 11:14 AM, John Locke
<..hidden..> wrote:
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.
Not just taxes. Also things like health insurance, etc. And these have to be categorized so we know how to handle them tax-wise.
- 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
I think we need an interface for custom stored procedures here. This also provides an opportunity for handling these as reporting entities or as things which get tracked specifically elsewhere. Rule sets can be added as necessary.
- tracking usage of PTO
That could be done through tracking of income types for the employee. This is not only necessary to use to track something like the sorts of variations you have regarding required employer contributions that can crop up with things like agricultural labor in Washington State.....
- 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.
Timecards are for tracking billable labor for a project. A payroll timecard system would be somewhat different. Long-run these timecards are specific to cost accounting for business reporting units (projects, engineer-to-order jobs, manufacturing lots, and the like.
On a related note, I think I will probably want to replace the current timecard system with something a little more flexible, particularly where manufacturing is needed. To be honest, the logic here is such such that it probably makes more sense to do this sooner rather than later, and may not be a whole lot of work.
The key to what you need though is separation of duties, and that would have to be included. With separation of duties, it becomes reasonable to just import the data automatically from your other system, then review it, approve, etc. How that gets imported is then an implementation detail. It could be done via csv, xml, directly into the database, etc. and you are still in control of your books.
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.
I will look into it once trunk is stable enough for testing of transaction entry. That will put it along with csv imports of more things, and new reporting.
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.
So maybe a script which:
1) Converts XML and JSON into a $request object
2) Converts a $request object to XML or JSON
3) Hands off to web service modules for URL parsing and work
I am thinking those web service modules would all accept three arguments: $request, $url, $method
I am also thinking the stuff we are doing with Moose will make this better in the long-run. We can use the defined data structures there as both the documented API and the basis for XML and JSON formats.
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...
Sounds good.
Best Wishes,
Chris Travers
------------------------------------------------------------------------------
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
..hidden..
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel