This looks all wrong, see other thread. To buy BTC at Coinbase, the money all comes from your Coinbase:Cash account. 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/CAK21%2BhOOPwB%3DbQe5GHdtiaZpEUYpYSZsp_Z1D124r0k47eSXZA%40mail.gmail.com.
