GnuCash CLI

Neil Williams 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 
follow.

I'm using it as a test bed for the remaining problems in QOF/QSF; namely 
QOF_TYPE_COLLECT, QOF_TYPE_CHOICE and maps.

Notes:
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
glib2
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.

Name            Description
gncVendor       Vendor
gncJob  		Job
gncInvoice      Invoice
gncEntry        Order/Invoice/Bill Entry
gncEmployee     Employee
gncCustomer     Customer
gncBillTerm     Billing Term
gncAddress      Address

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 
QOF_OBJECT_VERSION.

-- 

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/20050710/02b60822/attachment.bin


More information about the gnucash-devel mailing list