importing happens even when transaction matcher told not to

Benoit Gregoire bock at step.polymtl.ca
Wed Oct 25 18:40:33 EDT 2006


On Tuesday 24 October 2006 23:50, David Reiser wrote:
> On Oct 24, 2006, at 11:14 AM, Derek Atkins wrote:
> > j debert <jdebert at garlic.com> 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). 


More information about the gnucash-devel mailing list