I did an OFX import with a transaction for a sale of 281.543 shares, but shows up as 21.5400 because the import created a new security with precision of 1/100. It also looks like the price per share was adjusted from 10.019997 in the OFX file to 10.0201 in KMM (I have it set to use total price per transaction.) I'm not sure of the right way to deal with this, but would it make sense to set the precision to handle all the digits actually used in the OFX file? (I'm assuming any import would have the same problem, and not just OFX.) Final point - I'd acutally prefer that KMM does NOT automatically create the security account. This is because the string it uses (at least from Merrill Lynch) is not just the security name, but includes other info related to the transaction and not just the security. Within KMM, I often adjust the security name, which often causes this issue for future imports of transactions for the security.
(In reply to Jack from comment #0) > I did an OFX import with a transaction for a sale of 281.543 shares, but > shows up as 21.5400 because the import created a new security with precision > of 1/100. This is not a regression, as this behavior is also observed in a build from the 4.8 branch by using account bug458847 from https://kmymoney.org/ofxtest.php > It also looks like the price per share was adjusted from 10.019997 in the > OFX file to 10.0201 in KMM (I have it set to use total price per > transaction.) This seems to be from investment, which probably does not fit https://invent.kde.org/websites/kmymoney-org/-/blob/master/ofxtest.php#L447. Can you show an example of a corresponding OFX fragment ?
Agreed it's not a regression. New securities are always created with 1/100; this is perhaps the first time I have noticed that the values seem to be changed on import because of this. I suspect the default name for my securities depend on what Merrill Lynch sends for the initial purchase, and most of the time, later transactions either match or are corrected by matching to a similar previous transaction. However, some security names I modify such as adding a leading character to force sorting to the beginning or end of the list of securities, and those are the ones which cause this problem with later imports. (I wonder if there could be some sort of security name matching similar to payee name matching?) Here is one sell transaction from OFX: <SELLMF> <INVSELL> <INVTRAN> <FITID>20220607TB190801450137952 <DTTRADE>20220607110000.000[-5:EST] <DTSETTLE>20220608110000.000[-5:EST] <MEMO>Sale: PUTNAM ULTRA SHORT DURATION INCOME FD CL Y VSP 01/04/21 FR </INVTRAN> <SECID> <UNIQUEID>74676P698 <UNIQUEIDTYPE>CUSIP </SECID> <UNITS>-281.543 <UNITPRICE>10.019997 <MARKDOWN>0 <COMMISSION>0 <FEES>0 <TOTAL>2821.06 <SUBACCTSEC>CASH <SUBACCTFUND>CASH </INVSELL> <SELLTYPE>SELL </SELLMF> It imports as 281.54 shares, total $2821.06, share price $10.0200. The <SELLMF> is within <INVSTMTRS> and yes, this is within an investment account.
I'll also add that the Security created on import uses the name after "Sale: " from the <MEMO> field. Wouldn't it make more sense to use the one from <SECNAME> later on in the file? (In my case, that wouldn't help, as that is an even longer version of that from the Memo field, thanks to Merrill Lynch.
Can you also provide the following part from your download: <SECLIST> <STOCKINFO> : : </STOCKINFO> </SECLIST> that matches the above SELLMF? If you want, please send it to me via PM if you don't want to post it here.
<MFINFO> <SECINFO> <SECID> <UNIQUEID>74676P698 <UNIQUEIDTYPE>CUSIP </SECID> <SECNAME>PUTNAM ULTRA SHORT DURATION INCOME FD CL Y VSP 01/04/21 FRAC SHR QUANTITY .543 PER ADVISORY AGREEMENT. PRICE 10.020 <TICKER>74676P698 <FIID>9MI21 <UNITPRICE>0 <DTASOF>20220804110000.000[-5:EST] </SECINFO> <MFTYPE>OPENEND <YIELD>0 <DTYIELDASOF>20220804110000.000[-5:EST] </MFINFO> Don't know if it's relevant here, but note the strange SECNAME.
Git commit 142a43555b4ad22b95af309c31549e77b41721f3 by Ralf Habacker. Committed on 08/09/2022 at 09:15. Pushed by habacker into branch 'master'. ofxtest.php: Add test case for selling mutual fund M +34 -0 ofxtest.php https://invent.kde.org/websites/kmymoney-org/commit/142a43555b4ad22b95af309c31549e77b41721f3
Git commit d65cb8a432ce107fa69be617aa815f6a10173f7b by Thomas Baumgart. Committed on 10/09/2022 at 17:10. Pushed by tbaumgart into branch 'master'. Improve OFX importer Allow fractions of security smaller than 1/100. A new security is created with a default fraction of 1/100. In case the import contains a transaction with more fractional digits, the fraction of the security is automatically adjusted so that no information is lost. Securities are also detected by their unique id not only by their name. This allows to change the name after the import without re-creating the security during the next import. Security accounts are using the oldest postdate found in the OFX import file as their opening date and not the current date. This prevents the consistency check to report and fix the opening date later on. M +19 -4 kmymoney/converter/mymoneystatementreader.cpp M +9 -1 kmymoney/mymoney/mymoneystatement.cpp M +3 -0 kmymoney/mymoney/mymoneystatement.h M +22 -2 kmymoney/plugins/ofx/import/ofximporter.cpp https://invent.kde.org/office/kmymoney/commit/d65cb8a432ce107fa69be617aa815f6a10173f7b
> This allows to change the name after the import without re-creating the security during the next import. if I remember correctly, there might already be a related bug