linux at codehelp.co.uk
Sun Jul 10 16:47:41 EDT 2005
OK, I've got a framework for the business objects inside the command-line
interface from Pilot-QOF / QOF-generator. Accounts, Trans, Lots, etc. will
I'm using it as a test bed for the remaining problems in QOF/QSF; namely
QOF_TYPE_COLLECT, QOF_TYPE_CHOICE and maps.
1. This will be G2 only - it does NOT read the current GnuCash XML. Data will
need to be exported (which is why I wrote it in the first place).
2. This is for data-mining using SQL and it outputs more QSF XML which can be
used to make your own reports, invoices, print-outs, calculations,
abstractions, databases .... whatever you like. You can use XSL, Perl, PHP,
whatever you fancy.
3. The data itself can always be updated from more recent G2 exports - just
save the SQL statements in a file and run them again.
4. The QSF XML itself will be importable back into GnuCash (G2) too.
5. So far, I've called it "cashutil". (I was short on inspiration).
6. Remaining problem is gncCommodity which doesn't work with QOF. (yet)
7. There's limited financial logic in this program - you cannot create data
that is incompatible with the *object* but you might be able to create data
that is financially inconsistent - non-existent accounts are the most
obvious. GnuCash (via qof_book_merge) will deal with problems like that when
merging the data back into it's own files.
The question is:
Is this a *new* project (SF), a new program and a new package?
(personally, I think it may be better standalone).
Or should it be folded into the GnuCash G2 tree where it will always have the
same object definitions as the rest of GnuCash? (not a big problem, really).
It'll be useful for some, maybe even many, but does it merit being installed
for everyone? If it's left on it's own, will people shy away from using it?
It's dependencies are:
libxml2 >= 2.5.10
qof1 (which will be the package name for the QOF 0.6.0 source tree).
Umm, actually, that's it. i.e. the same as QOF. It does not depend on GnuCash
- strange as that may sound. I don't see what you'd do with it without
GnuCash but you never can tell what users will get up to. :-))
It builds it's manpage using xsltproc, it is gettext ready and it compiles on
GNU/Linux and MacOSX (almost).
There's work left to do - the objects are in but not fully functional - but it
can be done. (Everything *except* the objects is already working.)
/opt/working/cashutil/src$ ./cashutil -l
cashutil currently supports these object names:
You can use the names with cashutil -d
and in SQL queries (as the table name) with cashutil -s|f
Descriptions are shown only for readability.
gncEntry Order/Invoice/Bill Entry
gncBillTerm Billing Term
Use '-d <database> --explain' to see the list of fields within
any supported database.
Thank you for using cashutil
Once G2 is out, I'm going to look at allowing QOF to accept objects at
run-time using shared libraries (as it does with backends), instead of
writing a new program for each collection of objects. One front-end, many
objects. There will still be a need for bigger programs to keep their own but
these small utility programs could get out of control. I'm also going to need
some form of object version control with more fine tuning than
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20050710/02b60822/attachment.bin
More information about the gnucash-devel