On Sat, Jun 21, 2014 at 9:22 AM, Martin Michlmayr <[email protected]> wrote:

> * Martin Blais <[email protected]> [2014-06-20 23:16]:
> > > ; Selling 2 ShareB at 2014/04/01
> > > 2014-04-02 Selling 4 ShareA
> > >   Assets:Investments:Stocks:ShareA     -4 ShareA {20€} @ 30€
> > >   Assets:Cash                                   120€
> > >   Income:Investment Gains                       -40€
> >
> > What I think has been confusing some people is that the 120E and 30E
> values
> > above are [correctly] ignored (with your patch).
> >
> > They are going to be ignored, other than for adding an entry to the price
> > DB, right?
> > If not, how are they going to be used?
>
> They are not ignored - they are used to calculate the gain/loss.
>

How?



>
> In other woods, this would not balance:
>
>    Assets:Investments:Stocks:ShareA     -4 ShareA {20€} @ 30€
>    Assets:Cash                                   120€
>

If would not balance because -4x20 + 120 != 0, right?
So the 30E is ignored? How is it otherwise used?



Because you have 4 * 30, but also the 4*(30-20) gain, so you need:
>
>    Assets:Investments:Stocks:ShareA     -4 ShareA {20€} @ 30€
>    Assets:Cash                                   120€
>    Income:Investment Gains                       -40€
>

What's the amount used to balance the first leg? -4x20, right?
Do you have an implicit deposit to some other account?

AFAIK -4x20 here is balanced against the other postings, 120 + -40, and
THOSE are the ones really specifying the capital gain.



I actually ran into something that's not ideal the other day.  Since
> ledger just caculates and doesn't understand what's going on, you
> could happily do:
>
>    Assets:Investments:Stocks:ShareA     -4 ShareA {20€} @ 30€
>    Assets:Cash                                    80€
>

IMO that's a fine use case, I wouldn't worry about this. The transaction
did not actually receive the gain his cash or other accounts, so there has
been no gain materialized. The reality of these data entries is that the
cash amount deposited to your account will always be available from the CSV
/ OFX downloads, so you never make a "mistake" on it. The cash deposit
should always be the source of truth to determine the realized capital gain.




This still balances, but doesn't represent the nature of the
> transaction correctly -- it's exactly what you'd get without the
> capital gain.
>

I'm arguing (1) that it does: if you did not get the money, then you did
not actually realize the gain, and (2) as above, that the user will never
make a mistake on it. I've entered 8 years worth of data this way with no
errors, because when I import that data, the cash deposit amount is always
there. It works.



I'm not sure what to do about this... one solution is just to hope
> people will get it right.  Another would be new syntax to let people
> give the name of an account the capital loss/gain should be booked to,
> e.g.:
>
>    Assets:Investments:Stocks:ShareA     -4 ShareA {20€} @ 30€ =>
> Income:Capital gain
>    Assets:Cash                                    120€


> Then Assets:Cash is 120 and Income:Capital gain is -40
>

That's an interesting idea IMO, but I think goes against the spirit of
Ledger, which is very liberal and allows you to even book against lots that
don't exist in the account's inventory (see below). The syntax is irregular
and long-ish, but it's a cool idea! To interpret your example in more
general terms, you're saying that a posting with the syntax

  ACCOUNT UNITS {COST} @ PRICE => GAINS-ACCOUNT

will
1. balance against other postings at a value of UNITS x COST, and,
2. automatically insert a posting at UNITS x (PRICE - COST).

This way, the "Cash" leg in your example does not have to be 120E, it's
more flexible. It could be like this, for example:

   Assets:Investments:Stocks:ShareA     -4 ShareA {20€} @ 30€ =>
> Income:Capital gain
>    Assets:Cash                                    110.05€

   Expenses:Commissions                9.95€


This would transform into a transaction like this (could even be done with
pre-processing):

   Assets:Investments:Stocks:ShareA     -4 ShareA {20€}

   Income:Capital gain                              -4 @ 10€

   Assets:Cash                                    110.05€

   Expenses:Commissions                9.95€
>

This balances because you have -80 + -40 + 110.05 + 9.95 = 0

If you do implement this, if I were in your shoes I would run a
transformation stage that transforms the affected transactions instead of
complicating the balancing logic.



How do you handle this in beancount?
>

My approach has been to balance against the UNITS x COST and let the other
legs naturally specify the capital gain, like this:

   Assets:Investments:Stocks:ShareA     -4 ShareA {20€}

   Income:Capital gain

   Assets:Cash                                    110.05€

   Expenses:Commissions                9.95€
>

I'm using the difference in the balance to automatically calculate the
gain. I don't always care about the market price per share (it should be
clear by now you don't need it), but when I do, I add a @ 30€ to the ShareA
leg, and Beancount would add this to the price database -- that's the only
thing it would do with it (it's optional in the syntax), it would not get
used in balancing in any way.
http://memegenerator.net/instance/51434312

The fact of the matter is, you need a certain number of elements to compute
the gain, the syntax you propose just uses the price in the equation to
compute the gain instead of the cash deposit. That proposal is not
harvesting the opportunity to let Ledger extrapolate the missing amount, it
specifies all amounts, but that's okay, you're essentially saying "you'll
always have settlement price, so we can compute all the legs, no need for
extrapolation." In a sense, this is more strict (I like that).  But... I
claim that you don't always have the exact price of the transaction in the
downloads (usually comes with the paper/PDF confirmation statements later
on in the form of a settlement price). Moreover, the settlement price that
you transacted at may not reflect the actual market price that you'd want
to show in your price database, there are many reasons for this, e.g., the
offer price differs from what you got vs. average day or closing prices
that you might want in your DB or pull from Yahoo/Google, or maybe you
traded something off-market, and using the price in the gains computation
as you propose would implicitly force an off-market price entry in the
database.

But I think it's an interesting idea, still. Maybe some people find method
easier to grok.
If I were you, I'd make the new syntax something like this:

   Assets:Investments:Stocks:ShareA     -4 ShareA {20€} @ 30€ +

   Income:Capital gain                          +

   Assets:Cash                                    110.05€

   Expenses:Commissions                9.95€


whereby the "+" indicate where to report the computed gain.
Something like that. I've been toying with the idea of using such
"references," for computing the gains sans commissions, but I haven't
convinced myself I have some good use cases for this yet.




In the meantime, on a related topic maybe you can explain this to me:

2014-03-01 Details for shares
  Assets:Investments:Stocks     2 GOOG @ 500 USD
  Assets:Investments:Cash   -1000 USD

; This does not generate an error... it should.
2014-03-02 Details for shares
  Assets:Investments:Stocks    -2 GOOG {505 USD} @ 510 USD
  Assets:Investments:Cash

This demonstrates that Ledger is not strict about which lots you can
reduce... there are no "GOOG @ 505 USD" lots here, yet it allows us to
do this. Moreover, it created 20 USD out of thin air... the sum of all
accounts does not balance. This is one of many things I don't
understand about it: I cannot conceive correctly entering my data
without (1) strict inventory booking against existing lots, that is,
you cannot reduce a position against a lot that does not exist, as in
the above, and (2) the sum total of all transactions _must_ balance to
0 in all units. Beancount enforces both, always. Even when making
transformations, such as filtering the entries to show a balance sheet
and income statement and moving amounts from income accounts to
equity's net income, I check that the sum is zero.

$ ledger -f badstock.lgr  bal
              10 USD  Assets:Investments:Cash
              10 USD  Equity:Capital Gains
--------------------
              20 USD


Here is the detail:

$ ledger -f test.lgr  bal --lots

2 GOOG {500 USD} [2014/03/01]
   -2 GOOG {505 USD}
              10 USD  Assets:Investments
              10 USD    Cash
2 GOOG {500 USD} [2014/03/01]
   -2 GOOG {505 USD}    Stocks
              10 USD  Equity:Capital Gains
--------------------
2 GOOG {500 USD} [2014/03/01]
   -2 GOOG {505 USD}
              20 USD


And talking about strict inventory booking, even when you try to book
against an existing lot it doesn't work:

2014-03-01 Details for shares
  Assets:Investments:Stocks     2 GOOG @ 500 USD
  Assets:Investments:Cash   -1000 USD

2014-03-02 Details for shares
  Assets:Investments:Stocks    -2 GOOG {500 USD} @ 510 USD
  Assets:Investments:Cash


$ ledger -f test.lgr  bal --lots

2 GOOG {500 USD} [2014/03/01]
   -2 GOOG {500 USD}  Assets:Investments:Stocks
              20 USD  Equity:Capital Gains
--------------------
2 GOOG {500 USD} [2014/03/01]
   -2 GOOG {500 USD}
              20 USD


So now we have both 2 GOOG @ 500 USD and -2 GOOG @ 500 USD?

Is this a bug? The only way I could make it balance is by specifying
the date along.

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Ledger" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Reply via email to