Did an OFX import. The result was that apparently every imported deposit was assigned the split details from a preexisting transaction which had payer = "Deposit". Reproducible: Always Steps to Reproduce: 1. Create deposit transaction with payer = "Deposit" and which contains a split. 2. Do OFX import. Actual Results: All imported imported transactions with payer "Deposit" inherit the split details from the pre-existing deposit. Expected Results: Imported transactions should be not inherit split info. If name of preexisting condition is changed from "Deposit" then the issue does not occur. Imported OFX deposit transactions were of the following format: <STMTTRN> <TRNTYPE>CREDIT <DTPOSTED>20160229120000.000 <TRNAMT>0.33 <FITID>[VALUE REDACTED] <NAME>Deposit 0.050% %% Apy Earned <MEMO>Deposit 0.050% %% Apy Earned 0.05% 02/01/16 To 02/29/16 %% </STMTTRN>
I can confirm I've seen this behavior in the past. It appears that KMM takes an imported transaction, and even if it doesn't actually match it to an existing transaction, if the closest match (although I have no idea what criteria it might use) is a split transaction, then it makes the imported one split also. It's been a while since I've seen it, but as I recall, it's not too hard to remove the extra/unneeded split, and make the transaction as it should be. Note that I can imagine some cases where this behaviour could be desired, such as for a pay check, and you have set up splits to handle various deductions. However, I think most of the time, it is not desireable. As much as I hate adding to configuration options, or pop-ups for the user to specify details about an import, I think the right solution to this requires one or the other - either a setting to say never create a split transaction on import, or a pop-up stating the import matched a split transaction - should it be used or not.
I found that one can workaround this for any particular payee by specify the "No Matching" option for the payee. Of course that precludes automatically setting the account during the import too. Note that the inherited splits included not only the accounts specified in the split, but the exact dollar amounts which were not at all related to the dollar amount of the imported splits. The split information therefore made no sense, and it's hard to imagine that anyone would want such a feature. It's pretty annoying to import hundreds of transactions before realizing that many of them have nonsensical splits defined and must all be manually corrected.
Thank you for reporting this bug in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version? If you can reproduce the issue, please change the status to "CONFIRMED" when replying. Thank you!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
I'm changing back to REPORTED, as I don't think the underlying behavior has changed. If there is no objection, I will change this to a wishlist to request one of the options I listed in Comment #1. I don't think that turning off matching for the payee (Comment #2) is realistic, although I suppose that's the best current workaround if this occurs too often. However, that requires you to manually assign the Payee for all such transactions.