[rereading this thread more carefully now] On Monday, January 18, 2021 at 6:57:52 PM UTC-8 [email protected] wrote:
This looks all wrong, see other thread. To buy BTC at Coinbase, the money all comes from your Coinbase:Cash account. FWIW, Coinbase (and other exchanges) also offer (for better or worse) services where you can buy crypto with a debit or credit card, in which case, I think a debit posting in another institution's account could be appropriate? I of course have no idea if that's what happened here. Transfers from your bank are separate transactions. Reflect what's actually going on in the account On Mon, Jan 18, 2021 at 8:35 PM Ghanashyam Prabhu <[email protected]> wrote: I had a similar use case here and ended up using the plugin to report the transactions and then copied them manually into the transfer posting This is my entries list. However I see that when I run bean-check (v2), it errors out with an error No position matches "Posting(account='Assets:US:Crypto:Coinbase:BTC', units=-0.20778508 BTC, cost=CostSpec(number_per=Decimal('18078.87'), number_total=None, currency='USD', date=datetime.date(2020, 11, 28), label=None, merge=False), price=None, flag=None, meta={ Do you know why it complains on No Matching position when the Cost basis are exactly the same? 2020-11-28 * "Coinbase" "Buy BTC at Coinbase" Assets:US:Crypto:Coinbase:BTC 0.20778508 BTC {} @ 18078.87 USD Assets:US:Crypto:Coinbase:Cash -3500.00 USD Assets:US:BofA:Checking -256.48 USD 2020-12-17 * "Coinbase" "Buy BTC at Coinbase" Assets:US:Crypto:Coinbase:BTC 0.02109060 BTC {} @ 23707.24 USD Assets:US:BofA:Checking -500.00 USD 2020-12-26 * "Coinbase" "Buy BTC at Coinbase" Assets:US:Crypto:Coinbase:BTC 0.01977443 BTC {} @ 25285.18 USD Assets:US:BofA:Checking -500.00 USD 2020-12-30 * "Coinbase" "Buy BTC at Coinbase" Assets:US:Crypto:Coinbase:BTC 0.01741186 BTC {} @ 28716.06 USD Assets:US:BofA:Checking -500.00 USD 2021-01-01 * "Coinbase" "Buy BTC at Coinbase" Assets:US:Crypto:Coinbase:BTC 0.01667888 BTC {} @ 29978.03 USD Assets:US:BofA:Checking -500.00 USD 2021-01-03 * "Coinbase" "Buy BTC at Coinbase" Assets:US:Crypto:Coinbase:BTC 0.01464422 BTC {} @ 34143.16 USD Assets:US:BofA:Checking -500.00 USD 2021-01-04 balance Assets:US:Crypto:Coinbase:BTC 0.29738506 BTC 2021-01-04 * "Transfer BTC from Coinbase to CoinbasePro" Assets:US:Crypto:Coinbase:BTC -0.20778508 BTC {18078.87 USD, 2020-11-28} Assets:US:Crypto:Coinbase:BTC -0.02109060 BTC {23707.24 USD, 2020-12-17} Assets:US:Crypto:Coinbase:BTC -0.01977443 BTC {25285.18 USD, 2020-12-26} Assets:US:Crypto:Coinbase:BTC -0.01741186 BTC {28716.06 USD, 2020-12-30} Assets:US:Crypto:Coinbase:BTC -0.01667888 BTC {29978.03 USD, 2021-01-01} Assets:US:Crypto:Coinbase:BTC -0.01464422 BTC {34143.16 USD, 2021-01-03} Assets:US:Crypto:CoinbasePro:BTC 0.20778508 BTC {18078.87 USD, 2020-11-28} Assets:US:Crypto:CoinbasePro:BTC 0.02109060 BTC {23707.24 USD, 2020-12-17} Assets:US:Crypto:CoinbasePro:BTC 0.01977443 BTC {25285.18 USD, 2020-12-26} Assets:US:Crypto:CoinbasePro:BTC 0.01741186 BTC {28716.06 USD, 2020-12-30} Assets:US:Crypto:CoinbasePro:BTC 0.01667888 BTC {29978.03 USD, 2021-01-01} Assets:US:Crypto:CoinbasePro:BTC 0.01464422 BTC {34143.16 USD, 2021-01-03} On Saturday, 2 January 2021 at 03:10:52 UTC-8 David Terry wrote: Thanks for the detailed answers!! > BTW, David: as you can see, transfers work fine when fully specified, so this is a matter of convenience. I personally have a vim plugin that uses bean-doctor context to insert the lots. It seems to me that it's more than a matter of convenience. If the reductions / augmentations are explicitly specified, the booking will be potentially incorrect (i.e. no longer respect FIFO) if transactions that change the state of the inventory are subsequently added to the ledger with a date before that of the transfer. > Curious: is there anything specific to crypto that makes these transfers common? Transferring funds between institutions / accounts is very common when working with crypto. For example, it is not generally considered prudent to leave crypto custodied at a centralised exchange, so many users will transfer their assets into their own custody directly after having made a trade. As another example, users of DeFi applications will often move their assets between many different institutions (smart contracts) as the yields offered to depositors change. > If this is the defining/key feature that enables working with crypto currencies, we could consider supporting this explicitly in the core booking algos (in v3, not touching v2 much anymore) As mentioned above, these workflows are very common. I would certainly be very happy if these workflows were supported in the core booking algorithms. > Also: I'd love to gather a set of features that are key to making Beancount more usable for cryptocurrency trading. > Here's a doc where you can insert ideas: > https://docs.google.com/document/d/1taN9lbcNDf8bKgDwprWOhuaOsOgALZzmsfvec-rdaSk/edit# Very happy to hear that you're interested in working to make beancount more friendly for crypto users. I'll keep playing around and see if I can find some other pain points :) On Wednesday, December 30, 2020 at 8:22:33 PM UTC+1 [email protected] wrote: On Wed, Dec 30, 2020 at 1:39 AM [email protected] <[email protected]> wrote: On Tuesday, December 29, 2020 at 10:02:15 PM UTC-8 [email protected] wrote: On Wed, Dec 30, 2020 at 12:55 AM [email protected] <[email protected]> wrote: That makes sense. I was thinking of a system where plugin/booking/interpolation iterate over the same entries until no more modifications occur. This would involve some thought to prove (a) commutativity (order doesn't matter), and (b) convergence (no infinite iterations). "Iterate over the same entry until no more modification occurs" seems error prone to me, and a potential nightmare for debugging. Agreed. Although I've seen it work very well in systems where the key was to identify the constraints to make it work predictably. Reg. the other approach -- i.e., supporting this in core booking algos: even outside crypto, isn't the philosophy you've put forth "works on unambiguous source"? Given that, is there a syntax that removes ambiguity? For example: *2020-01-01 * "Transfer"* * Asset:BrokerageA -10 HOOLI {}* * Asset:BrokerageB: 10 HOOLI {}* might be unambiguous for FIFO, LIFO, and STRICT, and arguably for NONE (and AVG in the future). I.e., identical CostSpec after inverting the sign of one. I haven't thought deeply about all cases, and anyway, not the most important thing for v3. I'm not sure I understand what you mean by "works on unambiguous source", What I mean is: even if a CostSpec if incompletely specified, as long as it is unambiguous beancount will process it correctly. For example: there's no need to specify date in a cost specification as long as the price is adequate to uniquely identify the lot. Along those lines, I was making the argument that the transaction above is unambiguous in saying "transfer all lots from BrokerageA to BrokerageB," and thus, it would be nice for the core booking algos to handle it correctly rather than depend on a plugin. Yes The challenge is to design those things to be general. I think in this case the addition could be as simple as honoring a special flag on an interpolation posting, telling the interpolation code not to convert to cost. -- 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/bd63fee9-2635-4a7f-9d2f-c6be0ab723edn%40googlegroups.com <https://groups.google.com/d/msgid/beancount/bd63fee9-2635-4a7f-9d2f-c6be0ab723edn%40googlegroups.com?utm_medium=email&utm_source=footer> . -- 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/d6da06db-8d08-41b6-93f1-beb7d56261b3n%40googlegroups.com.
