The math on OFX import is incorrectly believed over the OFX total field. This OFX transaction: <SELLOTHER> <INVSELL> <INVTRAN> <FITID>14656805826101320140917 <DTTRADE>20140917000000.000[-4:EDT] <MEMO>YOU SOLD EX-DIV DATE </INVTRAN> <SECID> <UNIQUEID>42225P105 <UNIQUEIDTYPE>CUSIP </SECID> <UNITS>-0000000000100.00000 <UNITPRICE>000000012.020100000 <COMMISSION>+00000000000007.9500 <FEES>+00000000000000.0000 <TOTAL>+00000000001194.0300 <CURRENCY> <CURRATE>1.00 <CURSYM>USD </CURRENCY> <SUBACCTSEC>CASH <SUBACCTFUND>CASH </INVSELL> </SELLOTHER> results in a total entry of 1194.06 vs 1194.03 reported in the OFX record. I suppose I could talk to the broker about this, but in any case the entry total in the OFX record needs to be used. Reproducible: Always Steps to Reproduce: 1. Import an OFX transaction where the fees and transaction details mismatch the OFX total. 2. 3.
"...but in any case the entry total in the OFX record needs to be used. " Even if it is wrong? Why? 12.0201 * 100 = 1202.01, -7.95 = 1194.06.
Doing anything silently strikes me as wrong. The OFX record is inconsistent, and should be somehow flagged or rejected. Accepting the OFX total creates an incorrect transaction, although I suppose the import could create a split with missing category for the extra amount. Using a calculated total that does not match the OFX total will likely create a problem at reconciliation time. This really does need to be taken up with the broker to find out why the listed and calculated totals do not match.
(In reply to Jack from comment #2) > Doing anything silently strikes me as wrong. The OFX record is > inconsistent, and should be somehow flagged or rejected. Accepting the OFX > total creates an incorrect transaction, although I suppose the import could > create a split with missing category for the extra amount. Using a > calculated total that does not match the OFX total will likely create a > problem at reconciliation time. > > This really does need to be taken up with the broker to find out why the > listed and calculated totals do not match. My thoughts: Accept the transaction using the OFX total AND produce an error message or log. In this, PLEASE include in the message/log enough info to identify the transaction such as date, transaction type and amount as well as the reason for the report. (This sort of info would have help a LOT when doing QIF imports.) As you say, it should be taken up with the broker but in any case the total is what he/they have put in the account and any correction will likely be another transaction at a later time.
Created attachment 89196 [details] Imported transaction.
After fixing BUG 339192 the imported transaction looks like in the attached screenshot, which has a total of 1194.03 and seems correct to me, please re-check using git master.
(In reply to Cristian Oneț from comment #5) > After fixing BUG 339192 the imported transaction looks like in the attached > screenshot, which has a total of 1194.03 and seems correct to me, please > re-check using git master. Just tried this. Had to back date the OFX start date. Results: 1) The value is now correct. (By the way, the broker admitts to an error in his code which did not report a fee properly.) 2) The transaction still come up with the "missing assignment" triangle. Edit followed by Enter fix this, but still??? 3) I edited a boat load of DIV transactions to fix the negative values and all these got reloaded. It still looks to me like an edit of a transaction is deleteing the transaction ID. As a debug tool, if for no other reason, it would be nice to be able to ask KMM do dump all it knows about a transaction, including the transaction ID. Digging through the file to find this is, well, painful.
Created attachment 89588 [details] Sceen shot of bad transaction.
I just added a screen shot of a case of bad math in an investment download. The ! diamond seems to be saying that KMM thinks the investment total is off by twice the fee amount (16.160). This would seem to indicate that KMM thinks the fees should be added to the total rather than subtracted (it is a SELL).
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 set the bug status 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!
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now 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 Thank you for helping us make KDE software even better for everyone!