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