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/
pgpWx5p0UDC9Q.pgp
Description: PGP signature
_______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
