Insert Customer using QIF file

[Neil Williams]

On Friday 29 October 2004 5:31 pm, you wrote:
> Oaf is not a direct dependency, it's an indirect dependency. Gnucash does
> not use it, but GtkHtml does (and it's possible that guppi does, too).

It does look like overkill from this side. 

From my reading of OAF and CORBA, the basic types are very similar, standard C 
structures can be easily implemented (like enum, struct, typedef etc.), but 
the whole inter-program communication area is quite a lot to learn. Maybe I'm 
tired, but when the Hello World example takes several readings to make sense, 
things start to look like a lot of work.
http://developer.gnome.org/doc/guides/corba/html/corba-module-complete-helloworld.html
http://developer.gnome.org/doc/guides/corba/html/book1.html

I've got another BookMerge patch to send in over the weekend which 
significantly improves the function of the merge druid but still has 
difficulty with AccountGroup because the AccountGroup object cannot yet be 
merged. I've got to work on that and I think I can create parameters that will 
allow AccountGroup to at least be created and queried using QOF so that when 
the merged accounts appear in the target book, the GUID for the AccountGroup* 
parent still exists - that alone should be enough to allow the druid to 
properly re-parent the new accounts. At the moment, it's failing because any 
new AccountGroups are not created, leaving the accounts stranded. The code 
then has to assume that because the *parent is NULL, the account needs to be 
parented to the root account group, resulting in a flattening of the 
hierarchy - too many accounts get put as top-level.

On a side note, sometimes in this situation, I get an Orphan-GBP account 
created when I open any account in the book. What is missing from the book to 
cause GnuCash to create the orphan as a top-level account? It sometimes 
happens when I have a very limited test book too - i.e. before any merge.

I'm going to have to concentrate on getting the next druids done and probably 
the most useful thing to do now is to hard code the 'map' code in QOF for 
just what we need. Otherwise, it could take too long before the code that 
already exists is put to good use.

The mapping problem will have to be put off as it is not straightforward and 
is taking up time that is needed for other code. 

I'm hoping to get the 'Import Book' druid running next week - it should allow 
existing books to be merged and that will naturally lead into a third druid 
that will load partial book information from an XML format, such as that to 
be created by future pilot-link code. Maybe something like:
File -> Import -> GnuCash book
File -> Import -> ? 
It's QOF XML in the code but that means nothing to users. Just 'XML' is too 
bare and would leave people questioning what XML structure to create.

-- 

Neil Williams
=============
http://www.codehelp.co.uk/
http://www.dclug.org.uk/
http://www.isbn.org.uk/
http://sourceforge.net/projects/isbnsearch/

http://www.biglumber.com/x/web?qs=0x8801094A28BCB3E3
-------------- 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/20041030/810bbb68/attachment.bin