Peter, I'll step in to say that you're certainly welcome to create your own practices for your own books. I personally like to see that the sell transaction in the stock account matches what my brokerage indicates, and in my experience, that means a sale at the actual price and entries that account for the gain or loss. While the creation of the gain transaction is decidedly kludgy, I don't find it all that difficult to handle or understand. I certainly wouldn't call it "harmful."
David T. By the way, I'm not sure that the price database is used to calculate gains; I would rather expect that gains are calculated using the information from the purchase transaction. -------- Original Message -------- From: peterb <pet...@gmail.com> Sent: Tue May 25 09:15:30 EDT 2021 To: Geoff <cleanoutmys...@gmail.com> Cc: GnuCash Users <gnucash-user@gnucash.org> Subject: Re: [GNC] Proposed: "Realized Gain/Loss" transactions considered harmful On Tue, May 25, 2021 at 4:38 AM Geoff <cleanoutmys...@gmail.com> wrote: > I personally found the current process quite confusing for a long long > time until one day it finally "clicked" and now I am used to using the > Lots functionality for tracking capital gains & losses. > Hi, Geoff! I'm in the same boat. I'm used to it as well, but I spend a lot of time looking at how other systems model these transactions and that's what has me concerned; this is first and foremost a correctness issue, but it's also a data portability issue. I do want to distinguish between "using the lots feature to calculate capital gain" and "how the calculated gains are journaled." I'm focused entirely on how the capital gains are reflected in the journal entries - we should be able to keep the exact same view lots UI even if we change how the lots UI journals things. It seems to me that your proposal, in essence, involves including the > capital gain as one of the splits of the sale transaction, whereas the > current Gnucash functionality requires you to "transfer" the gain out of > the stock account and into the income account as a separate transaction > to the sale itself. And the Lots functionality can do this for you, > either by you choosing the individual lots, or automatically on a first > in, first out basis. > This is a fair description, although I think of the transfer as coming out of the income account, not into. The existing functionality works because stock accounts are not dollar-denominated, so the dollars (or whatever currency) you debit into it in your 0-share transaction evaporate upon contact. This brings up a related point that I didn't touch, which is that it's arguably better (though certainly not required) for the gain calculation to be part of the sale transaction - if you've ever made a sale which touches 10 lots, the current method creates 10 consecutive "Realized Gain/Loss" transactions which have no obvious ordering or connection to the lots sold - if you need to go back for any reason, you have to do detective work to figure out which is which. > Have you considered generalising your proposal to cover other stock > related capital gain scenarios, for example: > * The sale includes brokerage, taxes, or other charges > * The sale of several lots that were bought at different prices > These two should be treated just as they are now (GnuCash probably can't take a strong stance on them because of differing local tax laws.) > * A share split or consolidation with partial return of capital > * Takeover > * Liquidation > I haven't thought deeply about these scenarios yet, but they should be conceptually similar. > The biggest drawback I see with your proposal is that the selling price > is no longer recorded in the price column, but is only held in the split > description? You seem to be recording the original buying price as the > price on the sell transaction, which is confusing at first glance and, > in a sale of multiple lots scenario, would require the entry of many > such splits? > I want to be clear that what I was trying to get at in my proposal is a *simulation* of what we might want, and as such you can imagine UI changes that accomplish the same thing in a better way; I'm using the 'price' field here so I can show how I think it should be modeled, not because I'm literally saying we should actually use the price field like this. The crux of the issue to me is that the "price" field in the stock ledger is doing two things, and *those two things are actually unrelated*: (1) It is used as part of the calculation of the debit or credit of the account on buy or sell transaction (and GnuCash is so ambivalent about its role here that we need to throw a sheet to ask the user for their intent almost any time it changes - the "Do you want to recalculate value, price, or number of shares?" question) (2) It is used to populate the Price Database for the security for that date, which is in turn used to calculate unrealized gains/losses. I've got no problem with using the market price for (2), and if we wanted to keep it in the register for that purpose but also have a cost column I think that would be fine (although probably confusing in a different way). It's (1) that is the real problem here. In practice, the "price" for this transaction is always going to be a constructed or inferred value (even if the user types it in!) in the face of the two objective facts that drive the transaction: the change in the number of shares owned, and the amount of currency spent or received for those shares. Without getting too bogged down in what the UI should look like, I'm saying how this is journaled should be driven by a third objective fact: the cost basis of the shares being sold. I definitely think other UI choices are possible that could get you to the same correct outcome. I think the desire driving the current way of doing things is that we want to have our cake (treat stock sales as just another journal entry just like every other register) and eat it too (have this 'price' field on the register that actually interacts with the rest of the app in super-complicated ways.) If you've ever accidentally entered a stock transaction in the General Ledger, you've seen the Exchange Rate sheet appear and know that this is closely related to the stock price. You also know that the user is almost never going to make the correct decision when confronted with that sheet. I think inferring the exchange rate from facts that the user WILL know (how many shares, what were the gross proceeds) is going to be better for almost all of them. Regarding the multi-transaction issue, I think one is not required to have one gain split per lot sold; as long as you have a cost basis for whatever is being sold, you can use that cost basis in the stock account credit split and then have a single split for the capital gain. That is just my 20 cents (I am not an accountant), let's see what others > think. > I'm not an accountant either but my belief is that the complexity of this issue is one reason double-entry accounting systems often aren't the first choice for tracking investments. _______________________________________________ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information. ----- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All. _______________________________________________ gnucash-user mailing list gnucash-user@gnucash.org To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information. ----- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
