Not sure how it works internally. Perfect matches whereby fitid=online_id are hidden. I'd prefer not to hide, but just grayed out... Because it's disconcerting downloading an ofx and find that the import list is very sparse.
Unmatched ofx txns attempt to match register txns by multiple approaches: I think amount, date, description-parsing into words then Bayesian matching using internal probability list. It's imperfect. My major issue is the current importer does *not* reveal its best guessed register-txn therefore I have no idea what it matched against... And also it does not reveal which register-txns were left unmatched. On Fri., 31 May 2019, 11:00 Christopher Singley, <csing...@gmail.com> wrote: > On 5/30/19 6:53 PM, Christopher Lam wrote: > > Thanks, a terminal/keyboard based ui would be an acceptable compromise > > to get the functionality right; other devs could then convert to C > > using the python templates. > > > > Unfortunately my python is now very rusty compared to my scheme. > > > > Anyone is very welcome to take up the challenge! > > The GnuCash import logic has worked pretty well for me. I was under the > impression that it mainly does two things: > 1) Match imported transactions to existing transactions, in order to > exclude from import > 2) Failing a match, find similar transactions from earlier dates in > order to use them as templates (i.e. map accounts to split structure) > > Do I have that roughly right? And do I understand correctly that you're > focused on the first of these tasks? > > Is it the case that you have a large number of existing ledger > transactions (presumably from manual entry), and you're looking to use > the import process to match/exclude them and just keep anything you > missed entering already? > > _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
