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