On Tuesday 24 October 2006 23:50, David Reiser wrote: > On Oct 24, 2006, at 11:14 AM, Derek Atkins wrote: > > j debert <[EMAIL PROTECTED]> writes: > >> I have seen the same happen as you describe as well. > >> > >> Seems like this is related to bug 364104: when importing ofx it goes > >> ahead and reconciles transactions anyway when cancel is selected. > >> Changes accounts' balances to boot. > > > > This is an architectural problem with the way the generic importer > > works. It actually creates "real" transactions (and accounts!) well > > before you click "Finalize". > > > > -derek > > -- > > But in recent svn versions, this architectural problem has been made > worse. I've seen the transactions created by the generic import > matcher before, but the appropriate ones would be removed upon > Finalize. Now, the matcher seems to finalize based on whatever state > it guessed for the collection of transactions on initial import. > Changes made once the matcher shows the collection are ignored when > Finalize (and probably Cancel) is clicked.
Well then, either something changed in the matcher behaviour or in the engine revert code (so reverting a transaction no longuer really reverts). _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel