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 bl...@furius.ca wrote:
>
>> On Wed, Dec 30, 2020 at 1:39 AM redst...@gmail.com <redst...@gmail.com>
>> wrote:
>>
>>> On Tuesday, December 29, 2020 at 10:02:15 PM UTC-8 bl...@furius.ca
>>> wrote:
>>>
>>>> On Wed, Dec 30, 2020 at 12:55 AM redst...@gmail.com <redst...@gmail.com>
>>>> 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 beancount+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/beancount/bd63fee9-2635-4a7f-9d2f-c6be0ab723edn%40googlegroups.com.
