QSF and qof_book_merge

[Neil Williams]

On Friday 29 April 2005 11:02 am, Geert Janssens wrote:
> While gathering more info for my mini project to import sales info from
> acustom Access database,I came across a thread on this mailing list about
> qof_book_merge and qsf (qof serialization format).

http://code.neil.williamsleesmill.me.uk/
should provide all the answers you need. If not, I'll add answers to whatever 
questions you have.

There is no intrinsic reason why QOF could not run on Windows - it has no GUI 
requirement. As part of GnuCash it already runs on Mac OSX. When I've done 
some more on the low level code, I'm hoping to fold some of those OSX 
modifications into the QOF code so that it's easier to build on OSX and 
possibly elsewhere.

QOF is also small enough to run on embedded systems - there is a good chance 
of it being used to share data on certain palmtops.

> Since I can have my 
> inventory program export it's sales info in qsf format in relatively short
> notice,

Export is always easier than import - if there is any data that your program 
will need to import from GnuCash then you will need to spend more time 
declaring your own QOF objects. This is what has taken the majority of time 
in developing pilot-qof - the application that wraps pilot-link in QOF 
objects to import, export and synchronise data between the PDA and XML and 
therefore GnuCash.
http://pilot-qof.sourceforge.net/

I will offer any help you need but please read what I've written so far on the 
above sites as I have a keen interest in writing usable documentation and I 
would appreciate comments on whether it is sufficient.

> this combination seems to go a long way in solving my problem. 

Indeed - although there are still issues around converting between 
applications and that part of the code isn't complete. I'm finishing the 
object handling in pilot-qof and GnuCash so that I've got a known QSF layout 
for each before returning to the code for the maps.

Pilot-link objects are quite dissimilar from GnuCash objects and more is 
involved in converting one to another. If your program uses objects that are 
more similar, you may be able to convert more easily using XSL etc. However, 
I would not recommend that you simply implement GnuCash objects in your code 
- that would limit your use of QSF to only GnuCash when it could develop into 
much more. Define the objects as close to your own code as you can - it makes 
them easier to update and maintain, it allows the greatest potential for 
growth and development and it makes the best use of QOF itself.

e.g. Why shouldn't users be able to query their inventory data outside your 
program? If you define your objects as inventory objects, the user can use 
QOF to query their inventory data directly using a SQL-like interface. It 
frees your program from having to provide little-used reports or excessively 
customised report features. 

Concentrate of making your program data accessible to as many users as 
possible and you'll reap the rewards in QOF.

Inventory (personal and business) is one of the most recognisable benefits 
from having an open and extensible import/export format.

As I've said before here, I see no point in GnuCash handling inventory 
directly. What I think we need is an inventory program that can interface 
with GnuCash so that the user can view their data in both programs and 
together, you and I can create such an interface. The inventory program tells 
the (business) user the fastest and slowest lines, stock holding, discount 
performance, highlights shelving issues - eye level etc. - whilst GnuCash 
uses the same data to assess profitability, handle invoices and payments, tax 
reports and reliable double-entry accounting.

> So I'm really interested to hear what the current implementation and
> integration status of qsf and qof_book_merge are within GnuCash.

QSF is an inherent part of G2. It's implemented and working. It produces valid 
XML, according to the schema, and some export routines are now present. 
Currently, a bug in the G2 GUI code is preventing the import of QSF data but 
99.9% of the required code is again, present and working.

qof_book_merge is implemented in G2 and current CVS HEAD. Some improvements 
have been made in G2 but the most useful testing is only possible when the 
bug in the GUI is fixed. (Importing any QSF involves merging the data into 
the existing dataset, so an import of QSF always calls qof_book_merge.

I would recommend that your program exports it's own objects in QSF. This will 
make it easier to interface with other QOF programs - e.g. perhaps your 
inventory program could interface with GnoTime or pilot-link or something 
else. Maybe a labelling program or some form of barcoding software, maybe 
direct with an EPOS system, etc.

(GnoTime is to be packaged on Debian to use the external library version of 
QOF rather than it's internal version that uses older code. With some tweaks 
to GnoTime, it could be possible for it to use QSF and therefore share data 
with GnuCash and pilot-link itself.)

-- 

Neil Williams
=============
http://www.dcglug.org.uk/
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/20050429/0cd10f99/attachment.bin