On Monday, November 2, 2020 at 12:22:27 AM UTC-5 [email protected] wrote:
> On Sun, Nov 1, 2020 at 8:40 PM Aaron Lindsay <[email protected]> wrote: > >> On Saturday, October 31, 2020 at 4:38:28 PM UTC-4 [email protected] wrote: >> >>> On Sat, Oct 31, 2020 at 4:09 PM Aaron Lindsay <[email protected]> wrote: >>> >>>> >>>> 2014-10-31 * "BUY 1 SPY @ 200" >>>> Assets:Current-Assets:Brokerage:SPY 1 SPY @ 200 USD >>>> Assets:Trading:CURRENCY:USD 200 USD >>>> Assets:Current-Assets:Brokerage -200 USD >>>> Assets:Trading:NYSE:SPY -1 SPY @ 200 USD >>>> >>> > Sales are in essentially the same form, just in reverse. In this way, my > Assets:Trading:CURRENCY:USD >>>> account ends up being a weird combination >>>> >>> >>> It's the aggregate P/L (without discounting commissions). >>> >> >> Isn't it only the aggregate P/L *after* I sell all positions? Otherwise >> it also includes the cash used to buy my currently-held investments. Or >> maybe I'm confused about the definition of "aggregate P/L"? >> > > Well you're inserting a corresponding cash amount on your buys too. That > original transaction is essentially applying the currency trading accounts > method but for your shares. > Basically, what that is going to reflect, is the total amount of cash > against all positions outstanding. You could compute your P/L by > subtracting that from the sum total of the position values. So technically > no, it's not just your P/L, it's all the cash you used to acquire the > positions + realized P/L from already sold ones, which piles up in that > account. > Okay, thanks, that matches my understanding. > To be honest, I haven't been tracking my P/L much, if at all. Though I'm > even a little unclear on how GnuCash would derive P/L given the 'Trading' > account setup it uses - how are you assuming GnuCash calculates P/L when > you say it's not going to match beancount's? > > It depends if it stores the realized gains in another account. What you > wrote originally above is a way to keep track of cash vs. positions in > order to be able to derive P/L, e..g, I spent $1000 to buy 2 shares, then > $600 to buy one more, now I have -$1600 and 3 shares, and so if I want to > compute P/L, say the price per share is $650, the P/L is then 3x$650 - > $1600. When you realize gains, do you keep the profits in that account? If > so, the P/L is going to be that over all time. If instead the realized P/L > gets moved to another account (I would suggest to do that, to be able to > break it apart), then it's the P/L of only the open positions. > Let me make this concrete. This is what it would look like in GnuCash (albeit in beancount syntax) if I sold the entire position from my purchase example above: 2014-11-01 * "SELL 1 SPY @ 205" Assets:Current-Assets:Brokerage:SPY -1 SPY @ 205 USD Assets:Trading:CURRENCY:USD -205 USD Assets:Current-Assets:Brokerage 205 USD Assets:Trading:NYSE:SPY 1 SPY @ 205 USD I take this to mean that GnuCash's approach (at least the way I was using it) is to "keep the profits in that account" in your wording. Correct? And what you're suggesting to translate this to in beancount is: 2014-11-01 * "SELL 1 SPY @ 205" Assets:Current-Assets:Brokerage:SPY -1 SPY {200 USD} @ 205 USD Assets:Current-Assets:Brokerage:Cash 205 USD Income:Brokerage:PnL > (BTW, this is precisely how you keep track of open positions in a trading > strategy with a very large number of transactions; this is the correct way, > as it is compressed (small in size) and the sums have interpretable > meaning.) > Interesting. I'm assuming that they must additionally track the cost basis for sales in some way, though, right? Assuming they're all recorded in a consistent form (which I'm not sure I >> believe), I have around 200 sales. I think I will probably end up letting >> bean-count do its best using "FIFO" and go back behind it and check up on >> the ones that I can find data for. >> > > Yeah, it's borderline. > You could also try to automate it, by analyzing the different instruments. > Your 200 trades are probably distributed over many stocks, so it's possible > it might be pretty easy to match them up manually because the number of > possible lots to match against might be small, with the help of a little > script. > What benefit does writing my own script provide over letting beancount do it for me using its FIFO booking method paired with `bean-query print`? I'm trying to figure out what I would do differently if I were to write one myself. I *think* I successfully did the conversion last night and was able to move back to using the STRICT booking method afterwards. It's possible I'm missing something, though (and haven't finished verifying everything). -Aaron -- You received this message because you are subscribed to the Google Groups "Beancount" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/666de662-a81e-4f55-87af-9e938d4b5516n%40googlegroups.com.
