QSF and qof_book_merge

[Geert Janssens]

On Friday 29 April 2005 19:35, Neil Williams wrote:
> 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.
>
The thread I was referring to in my message actually was your thread, and 
already led me to your website, thank you :)

There's a wealth of information there, and it will take me some more time to 
grok it all, and ever more time to really figure out the gnucash internal qof 
object structure and how to map my database structure against it. But I'm 
working on it.

> 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.
>
The code for my access application is all in Visual Basic (for historical 
reasons). I'm not sure if I can make VB work with QOF on Windows (right now, 
I don't understand QOF at all yet), and I'm not sure if it is worth the 
effort. The interfacing between the Access application and GnuCash is an 
intermediary step to a full Linux migration of our inhouse accounting system. 
Eventually the Inventory program itself will have to be replaced with 
something on linux. This 'something' could use QOF, to ease the interfacing 
with amongst others GnuCash, but the intermediary solution should mainly just 
do what it's required. There is no need to be able to extend it later, as it 
is going to be replaced anyhow.

> 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/
>
This will indeed be a requirement, and as you say, not an easy one.

> 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.
>
I'll let you know, when I'm a bit further in my investigation.

> > 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.
>
As explained before, the growth potential is not really an option for the 
intermediary solution, but will be kept in mind in the later migration steps.

> > 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.
>
What exactly is this bug ? I'm willing to look at it.

Also, do you have a sample QSF File I can use for import tests ?

> 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.
>
These ideas really show the potential of QOF and QSF. I'm already glad I came 
across these two concepts. It will also simplify later additions in our linux 
inventory app.

Back to grokking now...

Geert Jan