Any sign of payroll yet?

[Mike or Penny Novack]

Derek Atkins wrote:

>Plenty of businesses use GnuCash without payroll
>
>Doing payroll right is hard. It requires significant recurring updates of local tax rates, rules, etc. It would be a full time job to do that.  Best case GnuCash could create a framework and require the end user to enter the details.  Even getting the rules input would require lots of effort.
>
>Patches always welcome.
>  
>
Just a comment about this that might help folks understand.

The problem is DIFFERENT for gnucash, which we expect to be more or less 
jurisdiction neutral and a commercial product like QuickBooks. It is 
MUCH more difficult for gnucash to solve a request like this because in 
the unregulated commercial market a commercial vendor like QuickBooks 
only has to handle the special feature for the jurisdictions which 
represent a large enough commercial market for their product.

Those of you who say "but QuickBooks can do payroll" should keep in mind 
that what that means is probably JUST "for the US and in the states and 
local jurisdictions that follow the most common patterns". And even that 
is perhaps a full time job for somebody keeping up with the annual 
changes. Thus if gnucash were modified to do payroll for "the US and 
states following the pattern of NY" and "the US and states following the 
pattern of CA" (most, but not all states will follow the pattern of 
either NY or CA) but failed to handle doing payroll for Australia, or 
Great Britain, or Germany we would say "gnucash can't do payroll".

And course it's not just payroll not being supported. So maybe we should 
be looking at the problem more generally. I used to do financial system 
software, and in the world of large systems it isn't usual for the 
accounting program ITSELF to do all these other things. What you have is 
more usually a number of systems (like "payroll", "point of sales", 
etc.) and these produce FEEDS to the accounting system (likely called 
"general ledger"). In other words, for those transactions, instead of 
somebody entering the transactions one at a time in the general ledger 
system those other systems produced files of transactions that were 
brought in all at once. Much as we do importing now.

So might I suggest instead of trying to support these requests (for 
payroll, for point of sales, etc.) the developers think about a 
generalized "batch transaction system". Something that would (first) 
"read" a set of gnucash books (so it could know what accounts existed) 
and then read in (and input edit for validity) a file of transactions 
(produce an error report for any bad ones; like trying to use an account 
that didn't exist), and if valid, apply them. THEN (if something like 
that existed) other teams that wanted to tackle a problem like "payroll" 
could work on developing  a"payroll system" that produced as its output 
a file of transactions intended for this "import transactions to 
gnucash". Another team could tackle "point of sales", etc.

Why divide up a problem like that? Well it becomes MUCH easier to test, 
is much more flexible, etc.

Michael D Novack