Extracted from mymoneyqifreader.cpp, and probably been there for many
years, so I'm afraid you probably have to work around this.
Another alternative would be to open a wish-list item on Bugzilla.
However, particularly at the moment, developer time is extremely scarce.
Perhaps someone with a particular interest and knowledge may happen
along one day.
"
*/
/*************************************************************************
*
* These transactions deal with short positions and options, which are
* not supported at all by KMyMoney. They will be ignored for now.
* There may be a way to hack around this, by creating a new security
* "IBM_Short".
*
*************************************************************************/"
On 19/01/16 21:04, Jeff Barlow wrote:
On 01/19/2016 04:16 AM, aga wrote:
On 19/01/16 02:41, Jeff Barlow wrote:
First let me concur that the category amount on a reinvested
dividend should never be zero. If it was then there is no
transaction to record. As Jack says it's exactly a dividend and a
buy rolled into one. The dividend is income and must be accounted
for as such.
But some transactions involve no money, add or remove shares for
instance.
It not really important if they involve "money" (cash flow) or not. The
important question is whether they involve a net change in ones net
worth. If a transaction changes ones net worth it may well constitute a
taxable gain or loss. This must be tracked with some income category.
The snag is that any dividend gets added into the transaction total,
together with the share cost. That dividend/category payment will
add to your total income, and really is a duplication as it will also
appear in the value of the involved shares. At least that's how it
appears to my simple non-accountant's brain.
I think you have the sign reversed on one of the values. They don't add
they cancel (balance) each other.
Sorry, not me. I had been checking a fix for a different problem and, I
suspect I had been looking at a Sell and had added an interest category
to it. That does result in the total amount being the sum, but is not
relevant to your use case. With a Buy, however, the total does show as
zero, which is what you indicated.
I don't see how the income can purchase shares and also appear as an
apparent dividend payment. Perhaps someone can put me right on this.
The income is in fact what is used to purchase the shares. It's somewhat
like a currency conversion.
I receive dividends from several mutual funds. Some are reinvested
in shares of the same fund. Some are used to buy shares in a
different fund from the same institution (The Vanguard Group). Some
are paid as a cash transfer to my checking account (an ACH
transfer). No broker is involved. There is no actual brokerage
account. Vanguard does not allow cash accounts. Most of these
transactions represent taxable income and need to categorized as
such even though many involve no cash flow.
It's not unusual for 'virtual' accounts to be employed, sometimes to
allow for delays between, say, a cheque being raised and the bank's
clearing of it. Superficially, from the KMM point of view,
everything is simple and straight forward, but the users are far more
creative than that.
I don't see it quite that way. It's true that from the POV of KMM
everything seems "simple and straightforward" I see that as rather
naive. The problem is it fails to accurately model the rather more
complex reality of these transactions. This forces us users to manually
enter two or three KMM virtual transactions involving fictitious
brokerage accounts in order to book what is really a single transaction.
The only way I've found to record all these transactions in KMM is
to employ a fictional brokerage account within KMM. I have to
record these single transactions as two separate transactions into
and out of this fictional brokerage account.
Since this fictional brokerage account does not indeed exist in the
real world one would at least expect it to maintain a zero balance.
Alas, due to KMM rounding errors that is not even true.
Rounding errors in what parameter? Presumably not in the monetary
side, as generally a fixed two decimal places is the norm, except in
a few(?) countries.
Ah yes. If we were only dealing with monetary numbers there might not be
an issue. Alas, my mutual funds operate with fractional shares that run
to four decimal places.
A reinvested dividend transaction (for example) that I download from
Vanguard contains three important numbers: the dividend amount in
dollars (two decimal places), the number of shares (four decimal
places), and the share price (two decimal places). If KMM would just
accept all three of those as is there wouldn't be a problem. Instead KMM
insists on doing the math itself and comes up with a slightly different
answer for one of the three.
My understanding is that US banking and security regulations include
some "interesting" rules for how rounding is to be done. I wouldn't be
at all surprised to learn that other countries have slightly different
rules. I don't claim to understand that.
I'm left with a choice of inaccurate share balances, inaccurate dividend
income amounts, or inaccurate share basis values. The only work around
for this that I've found is to break up these transactions into two or
three parts and carry these "balances" of plus or minus a few cents in
these fictitious brokerage accounts in order to fudge the important
numbers to match reality. This causes KMM's idea of my net worth to
always be a bit off. I currently see no way around this.
This may also be worth a wish-list entry, and in fact, more so than the
support of options. If you do do that, it would be helpful to show an
example of your case.
Allan
