Re: Tentative Schedule for 1.4

[Michael Richardson <..hidden..>]

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

    Chris> Not just taxes.  Also things like health insurance, etc.  And
    Chris> these have to be categorized so we know how to handle them
    Chris> tax-wise.

Right now, I do payroll by calculating stuff using either a spreadsheet 
I cooked up, or using a calculator that cra.gc.ca provides, or sometimes
using the paper tables.  I then enter this into a GL entry for each
employee, and I then Post-as-New each time.

I know that 1.3 has much improvements for recurring transactions, and I
think can do some calculations in the recurring transaction.  
That in itself would go a LONG way for me.

What John writes above, about being able to get a list of
"contributions" on a per-employ basis would be a major low-hanging
fruit.

After that, the only thing necessary is to have plugins that can do the
calculation for you.  At first pass this might be actually a good use
for javascript!

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


    Chris> I think we need an interface for custom stored procedures
    Chris> here.  This also provides an opportunity for handling these
    Chris> as reporting entities or as things which get tracked
    Chris> specifically elsewhere.  Rule sets can be added as necessary.

So, PTO isn't a concern for me (we have other mechanisms to track this,
and for CREDIL.org, it's rather more complicated. And we want our
employees to be able to see the PTO values, but they don't get access to
the accounting system...)

If one have PTO in your books, it must be as a liability, then it seems
to me this is essentially identical to vacation pay.  

    Chris> Timecards are for tracking billable labor for a project.  A
    Chris> payroll timecard system would be somewhat different.
    Chris> Long-run these timecards are specific to cost accounting for
    Chris> business reporting units (projects, engineer-to-order jobs,
    Chris> manufacturing lots, and the like.

    Chris> On a related note, I think I will probably want to replace
    Chris> the current timecard system with something a little more
    Chris> flexible, particularly where manufacturing is needed.  To be
    Chris> honest, the logic here is such such that it probably makes
    Chris> more sense to do this sooner rather than later, and may not
    Chris> be a whole lot of work.

My opinion is that the timecard interface is inappropriate.
We need APIs here, not systems....

    Chris> The key to what you need though is separation of duties, and
    Chris> that would have to be included.  With separation of duties,
    Chris> it becomes reasonable to just import the data automatically
    Chris> from your other system, then review it, approve, etc.  How
    Chris> that gets imported is then an implementation detail.  It
    Chris> could be done via csv, xml, directly into the database,
    Chris> etc. and you are still in control of your books.

Exactly.

-- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] ..hidden.. http://www.sandelman.ottawa.on.ca/ |device driver[
   Kyoto Plus: watch the video <http://www.youtube.com/watch?v=kzx1ycLXQSE>
	               then sign the petition.