Version: 4.5 (using KDE 4.4.5) OS: Linux Existing stock investment, with several reinvest dividend transactions entered in earlier versions of KMyMoney. Added another, no problem, except that it comes up in red on the ledger display, with a yellow exclamation point. Hovering over it brings up the message "This transaction has a missing assignment of CNA.L 0". CNA.L is the investment's symbol. After a bit of experimentation trying to recreate it, it turns out to be caused by the security's price. (I have it set to display in £ sterling, not pence.) If I enter 3.2566 it's fine. If I enter 3.25665 (the correct value), it generates the error message. So it looks like a problem to do with handling over-long price values. Reproducible: Always Steps to Reproduce: Go to an existing stock investment's ledger display. Create a Reinvest dividend transaction where the security price has a lot of decimal digits. Actual Results: ledger displays transaction in red with "This transaction has a missing assignment of <id> 0" Expected Results: Transaction entered, ledger displays in black with no error message. OS: Linux (x86_64) release 2.6.34-gentoo-r6 Compiler: x86_64-pc-linux-gnu-gcc
Have you tried increasing the price precision? The default is 4 decimal digits and you probably need at least 6 in this case. The message is shown because the total amount is not consistent with the amount of the splits.
On Saturday 02 October 2010 11:36:37 Alvaro Soliverez wrote: > ... > --- Comment #1 from Alvaro Soliverez <asoliverez kde org> 2010-10-02 > 12:36:35 --- Have you tried increasing the price precision? The default is > 4 decimal digits and you probably need at least 6 in this case. > The message is shown because the total amount is not consistent with the > amount of the splits. Thanks for the reply. And thanks for working on such an excellent piece of software! I'll try that when I next have access to that PC (next week).
As old as this bug is, I am running into a very similar problem. I did an OFX import (direct connect) and several transactions imported as dividends instead of reinvest dividends. (That's a completely separate issue, part of my ongoing saga of the broker's odd OFX configuration.) I have many previous reinvest dividend transactions for this account and security. However, when I edit one of the imported transactions and convert it from dividend to reinvest dividend, it gives me the same error. Oddly, some of these transactions show the error after import even before I accept them. For those, if I accept the transaction, the error remains, and the transaction remains unmarked, If I edit the transaction and change it to cleared, the error disappears, but returns if I edit again and change it to reinvest dividend. I don't think it's the price precision, since there are plenty of older reinvest dividend transactions with the same price and number of share precisions. I've also tried increasing the price precision, and it does not seem to make any difference. So - do I have a different problem, or is there something else going on?
Since BUG 303026 has better documentation I'm marking this as duplicate even if it's older. *** This bug has been marked as a duplicate of bug 303026 ***
Jack could you check if this is really a duplicate and git master fixes your issue?
Once I was finally able to test against git master, I'm still not quite sure what to think. However, things do seem better, and a bit more understandable. Importing either a dividend or a reinvest dividend that imports as a dividend, the transactions show a missing assignment. Clicking accept does not change the error, nor does it change the transaction to cleared. However, editing the transaction automatically assigns the brokerage account, and "enter" becomes active once I either change the status to cleared, or change the type to reinvest and change the number of shares from 0. Once I save the transaction, the error is gone. So - I'm really not sure if these two are duplicates or not, I think my issue was different from either (not precision related) but git master does fix my issue (at least this piece of it) so I think it's ok to leave this marked duplicate, and consider it fixed as the other bug shows. If I find anything else I think is a problem, I'll either raise on the mailing list or as a new bug.
Jack isn't the behavior you just described the same as the one in BUG 296883? If it is please attach a testfile to that issue since it's still open so I can work on it. I'm not very familiar with investments so I can't fix anything without a file that I can use to reproduce and understand the problem.
Cristian - thanks for the pointer. That bug is more appropriate. I'll continue this conversation their. I have not had any precision related problems.