Insert Customer using QIF file

[Derek Atkins]

Neil Williams <linux at codehelp.co.uk> writes:

> 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. 

Hmm...  Keep in mind that a QofBook can have multiple AccountGroup*
objects.  Last I checked this is used by the SX code to maintain the
list of SX templates.  The more this bites us (it would make some of
the Queries significantly easier if I could query on something like
ACCOUNT->GROUP->PARENTLIST matches GUID to see if an account is a subaccount
of a particular accountgroup.

The downside of turning Groups into first-class objects is that
existing data files don't have any storage mechanism for group
information, so we'd make a backwards-incompatible data file change.

Note that you can use Group->Parent->GUID for all Groups _EXCEPT_ the
top-level group.  Unfortunately it's the top-level group that is
usually the most interesting.  :(

>   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.

Uhh...  I dont understand why this is true.  *parent should only be
NUL for the top-level group; any "sub-account" should have a non-NULL
*parent.

> 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 not sure.

> 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.

Let's worry about the naming of the menu item(s) when we come to it. ;)
However, I'd suggest:

File -> Import -> Gnucash File
File -> Import -> QSF

:)

-derek
-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available