Beancount has two ways to track any kind of currency/commodity: at cost, or
not at cost.
Generally, currency like USD, EUR, etc are not tracked at cost. Stock,
securities etc are tracked at cost so you can report capital gains.
Beancounts infers what mode you are working in by the presence of a
CostSpec { } when working with that lot (both for reducing and augmenting
lots).
It's actually possible for the same account to hold a commodity both at
cost, and not at cost. This is *strongly *not recommended, and
beancount.plugins.coherent_cost can be used to verify you don't do it.
That plugin would show you what is wrong here. It's:
2021-01-04 * "Transfer BTC from Coinbase to CoinbasePro" #transfer
  Assets:US:Crypto:Coinbase:BTC           -0.29738506 BTC
  Assets:US:Crypto:CoinbasePro:BTC        0.29738506 BTC

You are trying to work with the BTC in the non-cost-tracking mode. You
should at minimum add {}
2021-01-04 * "Transfer BTC from Coinbase to CoinbasePro" #transfer
  Assets:US:Crypto:Coinbase:BTC           -0.29738506 BTC {}
  Assets:US:Crypto:CoinbasePro:BTC        0.29738506 BTC {}

But really what you likely actually want is to recreate all the original
lots, just in a new account. That's the original subject of this thread.

On Mon, Jan 18, 2021 at 9:00 PM Ghanashyam Prabhu <[email protected]>
wrote:

> Hi Martin, Apologies if this was confusing. Can you elaborate on what is
> wrong?
> I have added comments to my transactions for your reference - Note the
> points till which bean-check shows no errors.
>
> Let me comment the individual transactions.
>
> ;; This transaction purchases BTC at Coinbase from Cash existing in
> Coinbase account
> ;; The $3500 already existed and is correct from from the previous
> transactions.
> ;; Also this transaction requires additional $256.48 which is used from my
> Checking account
> ;; There are previous transactions
> ;; which I have not listed here.. For our discussion, consider that the
> transaction starts here with
>
> 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
>
> ;; All the below transactions are purchases by using cash from the
> checking account
> 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
>
> ;; I've added a balance assertion here to sum up the BTC accumulated
> ;; because of the above purchases
> ;; A bean-check until this transaction inclusive of the balance assertion
> ;; does NOT show any errors.
> 2021-01-04 balance Assets:US:Crypto:Coinbase:BTC 0.29738506 BTC
>
> ;; The next transaction I want is a transfer transaction from Coinbase to
> CoinbasePro
> ;; I initially added the below
> 2021-01-04 * "Transfer BTC from Coinbase to CoinbasePro" #transfer
>   Assets:US:Crypto:Coinbase:BTC           -0.29738506 BTC
>   Assets:US:Crypto:CoinbasePro:BTC        0.29738506 BTC
>
> ;; I now added a balance assertion again to check if the transfer is
> complete
> ;; and if the balance in CoinbasePro is correct
> 2021-01-05 balance Assets:US:Crypto:CoinbasePro:BTC 0.29738506 BTC ;; to
> check transfer complete from Coinbase to CoinbasePro
>
> ;; bean-check runs without any error until this point
> ;; which means the transfer check is correct even at CoinbasePro account
>
> Now, at this point I want to add a sell transaction
> 2021-01-08 * "" "Coinbase dummy sell"
>    Assets:US:Crypto:CoinbasePro:BTC       -0.20295107 BTC {} @ 34860.28 USD
>    Assets:US:Crypto:CoinbasePro:Cash          7074.93 USD
>    Expenses:US:Crypto:CoinbasePro:Fees          35.37 USD
>    Income:Capital-gains
>
> When I added the above sell transaction and run bean-check I get the
> following error
> No position matches "Posting(account='Assets:US:Crypto:CoinbasePro:BTC',
> units=-0.20295107 BTC, cost=CostSpec(number_per=<class
> 'beancount.core.number.MISSING'>, number_total=None, currency='USD',
> date=None, label=None, merge=False), price=34860.28 USD, flag=None,
> meta={file} against balance (0.29738506 BTC)
>
> Ghanashyam
>
> On Mon, 18 Jan 2021 at 18:57, Martin Blais <[email protected]> wrote:
>
>> 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
>> <https://groups.google.com/d/msgid/beancount/CAK21%2BhOOPwB%3DbQe5GHdtiaZpEUYpYSZsp_Z1D124r0k47eSXZA%40mail.gmail.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/CABieCET5KOR5H2LqXBELTWnz4UiD0FEb%3DOYJ8uR6BqOM%2BGT%2BCA%40mail.gmail.com
> <https://groups.google.com/d/msgid/beancount/CABieCET5KOR5H2LqXBELTWnz4UiD0FEb%3DOYJ8uR6BqOM%2BGT%2BCA%40mail.gmail.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/CACGEkZsLWdkMLC0LTHy6HuFkfDzGzv2MHwJP0AX6Aje%2B-7Te0w%40mail.gmail.com.

Reply via email to