Thanks a lot, David. I have completely missed that checkbox. Will try it out.
Also, to comment on your reference to single- vs multi-split import. I saw the Transfer Account field available and decided to use it from the start. That way I don't need two splits for simple transactions, meaning this is quite suitable more category-like approach, not double accounting. Single CSV rows match what is available though QIF, for example. Hence I'm not even trying the case that you describe, and I guess completely skipping the matcher for two split rows in one transaction. My test records look like this: date, description/payee, deposit, withdrawal, account, category/transfer account 2016-01-27,"Falafel",,4,"cash","Food:Dining out" This fits more to my source schema. Note that I'm writing a library that will allow me to pull records from MoneyManagerEx database, which is based on categories. I see that, with Multi-split checked, I can no longer select the Transfer Account destination field. This is a dead end for my current approach, using Transfer Account. At the last screen, I now get all mismatches as the destination account is missing and I'm prompted to select one. This makes no sense as I could have simply selected that at the first screen and save my matcher schema. Should I raise this as a bug or am I misunderstanding how this is supposed to work? Thanks a lot for your assistance. Note that there's also no rush from my side. For me, this is a hobby project that will, in the end, save me some time in automating the transaction transfer from my phone app to GnuCash. So don't feel pressured on that end, either. -- Sent from: http://gnucash.1415818.n4.nabble.com/GnuCash-Dev-f1435356.html _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
