canada payroll
Mike or Penny Novack
stepbystepfarm at dialup4less.com
Tue May 9 08:56:29 EDT 2017
On 5/8/2017 10:24 PM, R. Victor Klassen wrote:
> Having written a perl module that handles only a subset of the cases for only one jurisdiction, and knowing how complex they make it, I have no reason to believe no other jurisdiction is more complex yet,
> and possibly in very different ways. For a given jurisdiction, handling the year-to-year changes is <mostly> a matter of changing a few parameters. Unless they change the laws in a way that forces the formulae to be changed, and not just the constants used as thresholds and multipliers. For more than one jurisdiction, potentially very different from each other, to say that it would be a lot of work is to put it mildly.
>
> R. Victor Klassen
> rvklassen at gmail.com
> 226-792-0733
The real issue here is not how hard to do for ONE jurisdiction. The
issue is the sheer number of different jurisdictions involved (for
example, in the US one federal plus large number of states have state
income tax and some cities do)
That is why usually "payroll" is handled not within the main bookkeeping
package but as a separate system that feeds (interacts with) the main
bookkeeping package.
And payroll is not the only such "subsystem" possible. IMHO the first
step might be for gnucash to be modified so that it can send and receive
batch feeds. THEN we look for teams to create the interacting "payroll",
"inventory", "point of sales", etc. << these teams would start out with
a defined interface for sending or receiving feeds >> Maybe we could
even find a team to do the extra stuff an non-profit would like <<
unified statement, pledge accounting, etc. >>
Of course being able to send or receive batch feeds also solves some of
the importing problems.
Michael D Novack
PS: It is MUCH harder to debug monolithic systems. Break things apart
when possible to isolate problems.
More information about the gnucash-user
mailing list