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/
pgpZanRQgw9cq.pgp
Description: PGP signature
_______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
