Adding Payroll

[Neil Williams]

On Tuesday 08 November 2005 5:51 pm, Derek Atkins wrote:
> Jay Scherrer <jay at scherrer.com> writes:
> > However, while investigating the 2005 forms issued from the
> > <http://irs.gov>, I found that we can sign up for e-services developer
> > status, providing the software goes through a series of tests for
> > accuracy. The testing transmission will now use .xsd or XML schema.
> > Right away I began thinking of QSF.

Hmm. Maybe. You'd certainly need QSF + XSL rather than just QSF. The format 
created by the XSL conversion would still need it's own schema and it could 
be this that was tested.

It removes the localisation from the C codebase - the XSL can be tweaked 
between releases because there would be no C changes.

> I'm not sure QSF is exactly what you want here...  But something
> /like/ QSF may be appropriate.

QSF will always be able to export your payroll / tax data generically and 
therefore it can be an option for those whose formats are not directly 
supported. It would just be a case of creating an XSL stylesheet to custom 
formats - taking some of the burden out of localisation. 

i.e. if you use QOF objects, you've always got QSF without writing any code of 
your own. Customised and localised formats should, IMHO, be as generic as QSF 
to make it easy for them to be transformed into other similar formats.

(Just remember that QSF, like QOF, doesn't care if you are querying 
watermelons or employees! It's all just objects and books.)

The IRS is just one tax authority and each have their own formats. You cannot 
expect to support them all, especially not in C.

I agree with Derek, QSF may not be exactly what you want but I would caution 
against making any new schema too specific to one tax authority unless you 
have a common format from which all other tax authority requirements can be 
derived.

I think you need a hierarchy - one top level format and XSL stylesheets acting 
like the gettext translation files by converting the top level source into a 
localised form. Then we can add new XSL stylesheets in a similar fashion to 
adding new translations.

> > But the main question, is this an option with the GnuCash developers?
> > This would mean offering the ability to originate and transmit US
> > employer's IRS forms 940 and 941 to start with.

and the rest of the world?

Each authority would want their own "tests for accuracy" and I don't think 
it's a good idea to code too much of this in C. If you are going to write a 
new backend, make sure it is as wide, generic, flexible and extensible as 
possible. You want one piece of unchanging C that generates XML in a "common 
format" which can then be converted using XSL into specific local sub-forms.

I want to be able to improve the generation of my UK tax returns - I think I 
can do that with cashutil, QSF and a little perl but only because my 
calculations are relatively simple. Creating one system that can cope with 
US, UK and, say, German, requirements (just to take a sample of current 
gnucash developer needs!) is quite a challenge.

> I think having GnuCash provide online 940 and 941 submission would
> be WAY COOL.  You may just need to plug the schema into libxml2
> (instead of using QSF).  QSF has it's own XML schema which probably
> doesn't map into the IRS tax schema.

No, it wouldn't map directly but I dare say it could be converted with XSL. 
Don't know for sure, haven't seen the requirements. Certainly you are likely 
to need one new schema for each new XSL that is based on the common format 
(whether that is QSF or not) - the differences are likely to be too large 
(and change too unpredictably) to manage it all in one and government testing 
is likely to require schema validation of the end format.

Also note that this is increasing the development burden somewhat by raising 
expectations that each format will be updated each time the relevant 
authority publishes their budget. All the more reason to have one static 
common format and easily modifiable XSL customisations.

-- 

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/20051108/d4068dd7/attachment.bin