Adding Payroll

[Neil Williams]

On Tuesday 08 November 2005 9:38 pm, Derek Atkins wrote:
> We already depend on libxml2, so it wouldn't add a new dependency
> to use it yourself.  OTOH I do like Neil's approach of creating a
> generalized XML output and then an XSL translator from the general
> output to the specific IRS XML schema.  This way it doesn't require
> C coding to add new output formats; it just requires a new XSL template.

There's no inherent reason why gnucash has to do this XSL work directly - it 
could be handed over to a perl or bash script. OK it might be nice to do it 
ourselves but that just means gnucash has to have some way of controlling or 
predicting / finding the stylesheets to use and further encourages the user 
to believe that it is *our* collective role as gnucash developers to keep 
those stylesheets updated with each budget cycle - across all financial and 
geographic boundaries. IMHO, that is a task to which we are currently not 
well suited. 

Unlike translations, these stylesheets (and associated schema) will have to 
change at unpredictable and often inconvenient times quite separate from any 
gnucash development timeline. We may be better to make a clear dividing line 
that gnucash supports the method but not the individual stylesheets. Each 
would then be submitted to the relevant authority by a citizen under the 
remit of that authority for independent assessment. (Authorities might not 
accept a submission from a non-citizen.)

Tax and government policy cannot be relied upon to change within the design 
parameters of any format, no matter how generic. There will be times when the 
stylesheets will need radical overhauls at little or no notice. After all, we 
would be trying to keep up with forces over which we have no direct control. 
It could make organising the work of a team like Samba look trivial!

It takes time for a citizen to understand how government budget changes affect 
payroll and personal/business taxation - it is much more difficult for a 
developer living in a different system to change an internal structure to 
conform to such arbitrary changes. To expect to retain any compatibility with 
other systems that are absolutely unrelated is more than ambitious. All we 
can hope to do is provide a core format and let others do the specifics.

It is a *very* similar issue to the current US-centric tax code support - the 
dream of supporting the tax codes for each population for whom we currently 
have translations is just that - a dream.

Not to put too fine a point on it, we could end up needing official advice 
from an accountant in each region! (Which is one reason why Intuit QuickTax 
costs money every single year.)

e.g. in the UK recently, the government added a tax credit system for working 
families and the disabled. In each of the subsequent budgets, it was 
reviewed, changed, transformed or just tweaked. Highly paid accountants spent 
months deciphering the law for their corporate HR departments and *still* got 
it wrong. The Inland Revenue designed the system and THEY got it wrong - 
overpaying some individuals by thousands of pounds. The entire tax credit 
system is administered via payroll deductions done by the employer upon 
notification by the Inland Revenue of the results of means tests. The entire 
system was reworked again this financial year and is now a single tax credit 
but it's still not clear, unambiguous or easy to implement. Then there are 
student loan deductions, child support agency deductions, the list goes on.

> The downside of this approach is that it DOES add a new dependency
> on libxstl, which we currently do not depend on.

Not necessarily. Much like OFX and cashutil, payroll will not be needed by 
every single gnucash user so it's an optional add-on. Any dependencies are 
therefore optional too. 

FYI, cashutil has a build-time dependency on xsltproc (which then depends on 
libxslt).

What gnucash has done so far is largely region-neutral at it's core with 
optional modules (like OFX) that are region-specific. It is a model that has 
served us well.

If we stick with the core functionality, we may not need an xsltproc 
dependency at all.

-- 

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20051109/2fe47b31/attachment.bin