QFX import problems

Derek Atkins warlord at MIT.EDU
Thu Aug 5 18:21:39 EDT 2004


Benoit Grégoire <bock at step.polymtl.ca> writes:

>> Arguably the accounts should not be touched until the user clicks
>> "OK"...  I.e., IMHO the transactions should never be "committed" to
>> the CoA until the user ok's the import.  The current behavior can have
>> VERY bad side-effects with a multiuser sql backend!
>
> Well, since I was told at the time not to use the engine's revert function, 
> there isn't much choice is there...

What "engine's revert function"?

But yes, there is a choice -- you could do what the QIF importer does:
not actually create a Transaction* or Split* until *after* the user
hit's OK.  Until the user hit's OK the importer makes no changes
to the CoA.

Basically the import does the following:

1) Duplicate the account tree, and always present the new account
   tree to the user when trying to add new accounts or choose existing
   accounts.
2) Make all transactions with respect to the duplicate account tree.
   Note that these are not really Transaction* objects, but importer-internal
   objects.
3) Once the user is done and clicks "finish" or "ok" then merge back
   into the real CoA...  Create new accounts as necessary, and create
   the Transaction*s.

Unfortunately most of this was done in Scheme so it wasn't very
general or reusable.

-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



More information about the gnucash-devel mailing list