command-line utility.

Neil Williams linux at codehelp.co.uk
Mon May 9 03:53:07 EDT 2005


I won't have a GUI version of the full QOF functionality until the next 
release after G2, but I've got a command-line version already in place via 
qof-generator and pilot-qof.

What I'm thinking is that GnuCash G2 can already export, say, all invoices or 
all data between certain dates or the entire book - large files with lots of 
entities. This is easy to create from a menu command. However, QOF is (now) 
capable of refining this data using SQL-type queries handled recursively from 
the command line or from text/sql type files. Later, it will also support 
transforming data between objects using SQL and new data can also be created 
(to be merged later) using SQL INSERT commands.

Handling such permutations in the GUI is going to require the generic 
interface dialog that I've considered before - it's well within scope, it's 
just I can't realistically expect it to be ready for the first G2 release. It 
could handle arbitrary SQL commands and maybe even load a series of commands 
from a file (as well as export SQL versions of the commands created through 
the dialog itself, maybe). After all, there's no point creating a complex 
query in a series of dialog tabs if you have to do it all again later. 
However, even when this dialog is ready, there may be things that are just 
easier and more convenient to do via the command line. e.g. using pipes and 
redirects, scripting and automation.

A command-line utility can be easily adapted to use the existing QOF objects 
within GnuCash. It could therefore provide a SQL-type interface to exported 
QSF data and these files would be easily importable back into GnuCash - e.g. 
into a new file.

In effect, it becomes a data mining utility - working from exported XML. It 
would operate separately from GnuCash - it would neither access data files 
created using the GnuCash v2 xml nor interfere with a running GnuCash 
process. (Although I suppose it could do one or both if that was desirable.)

Should this be (yet another) stand-alone project (which would mean copying the 
QOF objects and keeping them in sync manually) or can it be included in the 
main GnuCash build (reducing it's size and complexity *considerably*)?

I'm also working on a PHP parser for QSF that will produce customised reports 
from the mined data and even export the data in other formats, XML or 
otherwise. That is part of the gof-generator project - it'll allow the C code 
behind the objects to be re-created from the QSF, amongst other things.

This kind of interface could provide answers for numerous queries about 
customised reports and data export. GnuCash cannot expect to support every 
permutation directly.

-- 

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/20050509/0a183186/attachment.bin


More information about the gnucash-devel mailing list