OFX Bayesian import not working for me

[David Carlson]

On 8/19/2014 9:01 AM, John Ralls wrote:
> On Aug 18, 2014, at 9:21 PM, Eliot Rosenbloom <eliot at prosocialleadership.net> wrote:
>
>> HEY --  Possible success!   I just updated gnucash to 2.6.3, and -- in an infrequently used set of books -- 1 out of 1 xns WERE successfully assigned!  :-) 
>>
>> Transactions done using v 2.4.13  (for June and July) did NOT produce assignment for August xns I just imported.  But I am hoping those August xns just assigned manually  (using 2.6.3) will produce assignment henceforth.  I'm inclined not to post to the whole list until more info/data is in (unless you'd prefer otherwise), but I wanted to let you know.
>>
>> Also: Here is the link to the earlier part of this thread.  I can post it to the whole list, if that would be helpful.  Sorry about the posts getting separated.
>>
>> http://gnucash.1415818.n4.nabble.com/OFX-Bayesian-import-not-working-for-me-td4664949.html#none
>>
> Eliot,
>
> We generally prefer otherwise, so please go back to the list once Derek gets his router replaced (today, we hope).
>
> I t seems unlikely to me that upgrading to 2.6 would change anything about Bayesian matching, and 1 transaction isn't really a useful sample. I don't think that the screenshots would be helpful, but examining the account file might be. If you can send me that plus the backups from before you did each of the June and July imports I can compare the data stored in the Bayesian matching tree and perhaps find a clue about what's going wrong. Don't send *that* to the list.
>
> Regards,
> John Ralls
>
>

Elliott,

Just a warning:  When you do see a match, manually verify that it is
correct.  I see several mis-matches per year, sometimes more than one a
month for some accounts in my data.  Sometimes I see no similarity to
the incorrectly matched transaction, occasionally the correct matching
transaction is present in the register but it is not presented as a
possible manual match to the imported transaction. 

As for that last case, I think there may be a way to build a transaction
such that the user thinks it is new but it may actually contain some
hidden information that tells the import wizard that it has previously
been matched to some imported transaction, therefore it is not eligible
to be matched again.  That is pure conjecture on my part, but it is the
only way that I can think of to explain why the correct existing match
is not found.

David C