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/
pgpUEWoXisVpa.pgp
Description: PGP signature
_______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
