On Sat, Aug 19, 2017 at 7:54 AM, <[email protected]> wrote: > One clarification: over lunch I was thinking about this, and realized that > beancount does FIFO booking reductions correctly for securities like stocks > under the usually valid assumption a security is sold/ reduced in the same > currency it was purchased in, since each security is denominated in the > currency of its exchange. >
That is correct. The main issue is that there are two processes going on, and it's not clear which one could come first: - Interpolation of missing values - Booking against existing inventories of lots Resolving this is hard - one can come up with useful cases where one would be preferred to run before the other - and part of it involves inferring the currency of a lot. Once the currencies are resolved, then the booking takes place. So the currency is fixed. > This is reasonable: if one buys shares in Nokia (NOK) listed on the New > York Stock Exchange, they're always listed in USD. Shares listed in EUR are > available on the Helsinki Stock Exchange, but their symbol is NOKIA, hence > a different security. > > Where thinks currently seem not to work is if one is tracking a real > commodity -- apples, bitcoin, or coffee -- anything that doesn't have an > intrinsic currency for valuing it. > What you call a "real commodity" here is generally a currency. Beancount differs from Ledger in this regard, you can treat currency as they are. > > Does that make sense, or have I misunderstood something? > No, I think you get it. However, I think there may be a better resolution here. I think you may be able to treat Bitcoin as a currency, disregard its cost basis, yet still be able to account for gain/loss for it. Let me explain. When a currency conversion is accepted by Beancount, no cost basis is stored. However, if the exchange rate takes place, a gain or loss will be incurred. In other words, the sum of all postings will not be an empty inventory. In order to deal with this, Beancount inserts an ugly conversion transaction which makes us for exactly this. This transaction is inserted by this code: http://www.mscs.dal.ca/~selinger/accounting/tutorial.html Its purpose is to exactly counterbalance this difference, across all currencies. One problem is that its contents must depend on the set of transactions being summarized. That's why it's inserted when you open or close on the set of directives, e.g.., before producing a report. Now, please take a few minutes to dive in and go read this: http://www.mscs.dal.ca/~selinger/accounting/tutorial.html This method resolves the problem elegantly. Each of the transactions posts the currency differences to a dedicated set of currency accounts. Unfortunately, it would be a pain to enter your transactions in this way. However, it would be simple to do this automatically with Beancount, even as a plugin. I plan to do this eventually. (You're welcome to get ahead about that, I'm working on other things these days.) Now, how does this relate to your question? Well, with this "trading accounts" method, you could later (in time) unwind some of these currency account at their current rate, and post the difference as a gain/loss. I know I've said previously it would be easier to use the cost basis. What you get from that is specific lot reduction methods, e.g. FIFO, LIFO. On the other hand, if you'd like not to have a particular cost currency, really you are dealing with currencies. In this case, you won't have any booking, but you could still have total gain/loss. (I hope this makes sense.) > > Thanks for all you work on beancount. It's a great tool! > Thanks, and please keep on finding problems, that's the way software gets stronger. > > Joel > > Le samedi 19 août 2017 11:38:11 UTC+2, Joel a écrit : >> >> Thanks for your response. >> >> >>>> 2. If I explicitly put "USD" in all my empty {}, how does will FIFO >>>> booking option handle the occasional cases where I've purchased bitcoin >>>> with euros? >>>> >>> >>> I don't understand the question. If you try to reduce and provide USD in >>> the description, it will only match against lots in USD. Can you provide an >>> example pair of transactions? >>> >>> >>> >>> >>>> Will it always reduce the oldest bitcoin lots first, regardless of the >>>> currency I'm reducing with, or will explicitly specifying the reducing >>>> currency mean I have to manually check the order lots are cleared to make >>>> sure that the total of the two currencies reduces correctly per FIFO? >>>> >>> >>> I'm still not sure I understand, it will never convert currencies when >>> reducing. >>> >>> >> Here's an example, from a fictitious episode in which I rode Amtrak back >> and forth a few times between New York City and Montreal to sell apples: >> >> >> option "title" "My Personal Ledger" >> option "operating_currency" "USD" >> option "operating_currency" "CAD" >> option "booking_method" "FIFO" >> >> 2016-01-01 open Equity:Opening-Balances >> 2016-01-01 open Assets:US:Cash USD >> 2016-01-01 open Assets:CA:Cash CAD >> 2016-01-01 open Assets:MyBackpack:Stuff APPLES >> 2016-01-01 open Income:CapitalGains >> >> 2016-05-26 price CAD 0.77046 USD >> 2016-05-28 price CAD 0.76761 USD >> >> 2016-05-24 * "Opening Balances" >> Assets:US:Cash 40.00 USD >> Assets:CA:Cash 0.00 CAD >> Equity:Opening-Balances >> >> 2016-05-25 * "Bought some apples in New York" >> Assets:MyBackpack:Stuff 10 APPLES {1.00 USD} >> Assets:US:Cash >> >> 2016-05-26 * "Convert USD to CAD" >> Assets:CA:Cash >> Assets:US:Cash -15.03 USD @ 1.29792 CAD >> >> 2016-05-26 * "Bought some more apples in Montreal" >> Assets:MyBackpack:Stuff 13 APPLES {1.50 CAD} >> Assets:CA:Cash >> >> 2016-05-27 * "Bought some apples in New York" >> Assets:MyBackpack:Stuff 11 APPLES {1.20 USD} >> Assets:US:Cash >> >> 2016-05-28 * "Sold some more apples in Montreal" >> Assets:MyBackpack:Stuff -14 APPLES {USD} @ 1.70 CAD ; should sell 10 >> APPLES {1.00 USD} & 4 APPLES {1.50 CAD}, a cost basis of 14.605 USD >> Assets:CA:Cash 23.80 CAD ; converts to >> 18.269 USD >> Income:CapitalGains ; revenue ( >> 18.269 USD) - cost basis (14.605 USD) = 3.665 USD >> >> ; CapitalGains = 3.47 USD per beancount when the {1.50 CAD} lot doesn't >> get reduced. >> >> I don't think beancount is reducing my apples by FIFO correctly, because >> when I run the *bean-report *sample *holdings* when selling 14 apples, >> its reducing from my {1.00 USD, 2016-05-25} and {1.20 USD, 2016-05-27} >> lots, but not reducing any apples from my {1.50 CAD, 2016-05-26} lot. Since >> apples are apples, shouldn't it reduce the lots by date order? >> >> If I replace the {USD} with an empty {} beancount tries to reduce all 14 >> sold apples form the {1.50 CAD, 2016-05-26} lot, but fails because there's >> only 13 apples in that lot. The only was I can find to have beancount >> reduce my apple inventory selling the oldest lots first is manually, like >> this: >> 2016-05-28 * "Sold some more apples in Montreal" >> Assets:MyBackpack:Stuff -10 APPLES {USD} @ 1.70 CAD >> Assets:MyBackpack:Stuff -4 APPLES {CAD} @ 1.70 CAD >> Assets:CA:Cash 23.80 CAD >> Income:CapitalGains >> >> So, I'm not sure FIFO is reducing the oldest lots first. It depends on >> the lot currency. >> >> >> -- > 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 post to this group, send email to [email protected]. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/beancount/dc892eed-3ce2-4372-92c3-6decc85ccab0%40googlegroups.com > <https://groups.google.com/d/msgid/beancount/dc892eed-3ce2-4372-92c3-6decc85ccab0%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- 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 post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/CAK21%2BhNa-R2tFx3P_7ySTJ6W8XtZTLEi3Ha3a6UramVp%2BFU73Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
