On Mon, Sep 29, 2014 at 7:53 AM, Mike Charlton <[email protected]> wrote:
> Sorry for the slow reply to this (my own thread even...). I wanted to
> think about it and got caught up in life.
>
> The issue of keeping an inventory of commodities isn't lost on me. It's
> definitely a difficult problem. For the most part, I like how ledger does
> it. However, I'm making a move to Japan in a month and I have not been
> able to figure out if the tax man likes FIFO, LIFO or weighted average
> cost. I've been practicing all three in Ledger :-)
>
FIFO vs. LIFO is an orthogonal issue. You can already do this in Beancount
as well, e.g., by specifying the cost or the (cost + acquisition-date) of
the lots you sell. I have a proposal which will significantly improve the
ability to specify lots, by doing partial matching against any mix of cost,
acquisition-date, and a user-supplied label. It will succeed if it is
unambiguous. You will be able to put a little information as necessary to
disambiguate. The degenerate case is that of having a single lot and
selling like this:
2014-09-01 * "Selling my only lot"
Assets:Ameritrade:AAPL -30 AAPL {}
...
The correct cost will be selected (not just any cost, but the actual cost
of the lot that happens to be present on the morning of 2014-09-01 upon
which this transaction will get applied).
Weighted average cost is not yet possible in Beancount, it requires special
treatment since I match lot reductions strictly against existing inventory.
Weighted average cost is possible in Ledger in the sense that anything is
possible... it lets you put any cost basis with no checks against the
inventory. You can probably create a situation of negative cost basis this
way. If you enter the correct data, it's by chance. If you are paranoiac
about making mistakes, you should want to write a script to check that the
resulting cost basis matches the post transaction book value your broker
might report to you.
I may be wrong, but the ability to choose whatever capital gains you want
> (or whatever non-existant lot-price you want) seems to be useful for doing
> weighted average cost. Of course your lot-price inventory gets completely
> blown out of the water, but presumably you don't care about that in this
> case -- you just want to make sure that the amount of money balances.
>
Yes, weighted average cost is more difficult. I don't have an
implementation for it yet - my own retirement account sales are currently
booked either FIFO or LIFO and fees taken at "current cost" are commented
out, so this is something I need to address soon, I need the feature myself
- but I have a detailed proposal for how to implement it, here are some
notes:
http://furius.ca/beancount/doc/proposal-inventory
At this point I've worked out all the kinks, it's just a matter of finding
time to code it. Recently this design was refined further to the following
(I need to update the doc): if you place a star (*) in the cost, it simply
means "merge all the lots for the given commodity before and after this
posting is applied". Here's an example lot addition (a buy):
Assets:Ameritrade:AAPL 30 AAPL {* 41.00 USD}
Here's a lot reduction, which automatically selects the single merged lot
(at average cost):
Assets:Ameritrade:AAPL -30 AAPL {*}
This is the default for sales for such accounts.
In addition, you should still be able to reduce the basis with an explicit
and possibly unexisting cost basis, something like this:
Assets:Ameritrade:AAPL -30 AAPL {* 42.32 USD}
This only makes sense for average cost booking: it deducts the cost basis
from the existing basis and recalculates the weighted average cost with the
remaining basis. In any case, no cost basis is lost nor created.
Separately from this, there will be a default method that can be applied to
each account, so you can specify even less if you want, FIFO, LIFO, etc.
One such method will be AVGCOST.
My main issue for bringing this up was some pain that I had when I entered
> the wrong price for something by accident. When I realized (much later), I
> had to change the lot-price for every transaction after it. Not a pleasant
> experience. I was looking for a notation that made the lot price more
> implicit. In retrospect, this is probably a bad idea. The pain of
> updating the journal is far outweighed by having the software pick the
> wrong lot-price silently ;-)
>
I absolutely feel your pain. I've been through a similar situation a couple
of times before I reimplemented my inventory booking to be strict. if you
have even just a moderate number of trades, It's extremely difficult to
enter all the data correctly without making a mistake. It's like walking a
tightrope without a safety, but you won't even notice when you fall. In my
experience it's impossible to do it without some kinds of checks! This is
why I decided to book inventory strictly, I think that the software really
needs to support you in entering your data correctly.
One simple improvement that could be applied to Ledger without changing its
current model is to allow the user to insert balance checks against the
cost basis. While this puts some burden on the user - he/she has to enter
the expected book values over time - at least it would provide a way to
make sure your data entry is correct. Maybe it can already do that?
>
> The Beancount notation is interesting. Do you support weighted average
> cost as well?
>
(See above.)
--
---
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.
