Apologies for bumping an old thread with an off-topic question, but
Redstreet, you said:
> I personally have a vim plugin that uses bean-doctor context to insert
the lots.
This is really interesting; I wonder if this is something that's openly
available or if it's a personal hack whether you'd be interested in
sticking it on Github?
On Wednesday, 30 December 2020 at 4:58:35 pm UTC+11 redst...@gmail.com
wrote:
> 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.
>
> Curious: is there anything specific to crypto that makes these transfers
> common?
>
>
> On Tuesday, December 29, 2020 at 9:55:53 PM UTC-8 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).
>>
>> 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.
>>
>>
>>
>> On Tuesday, December 29, 2020 at 9:29:55 PM UTC-8 bl...@furius.ca wrote:
>>
>>> Ahh yes, indeed. That's a bit of a problem. I don't have a good solution
>>> for this yet.
>>> Simply providing parser-level plugin functionality wouldn't work here,
>>> because the information for the postings to be transferred is filled in by
>>> the interpolation code. This is a feature that would need to be applied in
>>> the booking code, e.g., apply the inventory updates based on the result of
>>> the transfers.
>>>
>>> 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).
>>>
>>> Another idea would be to create a new kind of hook, one that is
>>> registered from a plugin, e.g. a callback of yours invoked by the booking
>>> code itself, and whose results applied to a transaction are immediately
>>> reflected on the state of the affected inventories. Maybe this is the right
>>> place to do this (I've never had this idea before.) Now, imagine
>>> generalizing this further to provide and implement all opf the current
>>> booking mechanisms that are currently built in the core. Call this
>>> "customizable booking."
>>>
>>>
>>>
>>>
>>> On Tue, Dec 29, 2020 at 7:34 PM redst...@gmail.com <redst...@gmail.com>
>>> wrote:
>>>
>>>> This is interesting. From what I can tell:
>>>>
>>>> - Beancount's loader proceeds thus: parse -> booking+interpolation
>>>> -> plugins -> validate.
>>>> - Therefore, when booking+interpolation is run on your parsed
>>>> source, the transfer plugin has not had a chance to transform the
>>>> entries
>>>> and transfer the lots.
>>>> - This means, that the reduction in your source (-120 XYZ {}) can't
>>>> be done because there are no lots to reduce at booking+interpolation.
>>>> Therefore, it's interpreted as an augmentation (aka buying a short
>>>> position). (Side note: your "sell" transaction should look like "-120
>>>> XYZ
>>>> {} @@ 480 EUR", or " -120 XYZ {} @ 4 EUR", so it's a reduction, and not
>>>> an
>>>> augmentation, and should include an "Income:" posting to capture
>>>> gain/loss, which you'll need to do anyway once this problem is fixed)
>>>>
>>>> AFAICT, this means that the transfer lots plugin won't work without
>>>> some rethinking of the loader, perhaps allowing for pre-booking plugins.
>>>> Martin may have other ideas or workarounds though.
>>>>
>>>>
>>>> On Tuesday, December 29, 2020 at 12:23:38 PM UTC-8 David Terry wrote:
>>>>
>>>>> Hey,
>>>>>
>>>>> Just getting started with beancount and I ran into this problem when
>>>>> entering some crypto trades. I tried out the transfer_lots plugin in the
>>>>> beanlabs repo, and I ran into some issues that I don't really understand.
>>>>> I
>>>>> can attach cost basis and buy and sell lots within one account without
>>>>> issue (see here
>>>>> <https://gist.github.com/xwvvvvwx/75acb4c05dd9b061e8eb46636dbcbc18#file-works-bean>),
>>>>>
>>>>> however when I transfer some assets to a new account and then attempt to
>>>>> see them, I'm running into problems (example file
>>>>> <https://gist.github.com/xwvvvvwx/75acb4c05dd9b061e8eb46636dbcbc18#file-broken-bean>
>>>>> ).
>>>>>
>>>>> Once there is a transfer involved, beancount no longer seems to reduce
>>>>> lots according to FIFO, and instead seems to attach a new cost basis to
>>>>> the
>>>>> removed lots based on the price at the time of the sale. The output from
>>>>> running `bean-doctor context` against the last trade in the problematic
>>>>> file is below. You can see that the sale has resulted in an extra 120
>>>>> lots
>>>>> @ 4EUR being deducted from the inventory. Is this a bug, or am I using
>>>>> the
>>>>> plugin wrong?
>>>>>
>>>>> ------------ Balances before transaction
>>>>>
>>>>> Assets:Binance:XYZ 100 XYZ {2 EUR, 2020-12-25}
>>>>> Assets:Binance:XYZ 50 XYZ {3 EUR, 2020-12-25}
>>>>>
>>>>> Assets:Binance:EUR
>>>>>
>>>>>
>>>>> ------------ Transaction
>>>>>
>>>>> 2020-12-25 * "Binance" "Sell 120 XYZ"
>>>>> Assets:Binance:XYZ -120 XYZ {4 EUR, 2020-12-25} ; -480 EUR
>>>>> Assets:Binance:EUR 480 EUR ; 480 EUR
>>>>>
>>>>>
>>>>> Basis: (-480 EUR)
>>>>>
>>>>> ------------ Balances after transaction
>>>>>
>>>>> Assets:Binance:XYZ 100 XYZ {2 EUR, 2020-12-25}
>>>>> Assets:Binance:XYZ 50 XYZ {3 EUR, 2020-12-25}
>>>>> * Assets:Binance:XYZ -120 XYZ {4 EUR, 2020-12-25}
>>>>>
>>>>> * Assets:Binance:EUR 480 EUR
>>>>>
>>>>>
>>>>> On Saturday, December 26, 2020 at 5:17:08 PM UTC+1 bl...@furius.ca
>>>>> wrote:
>>>>>
>>>>>> Here, refined further to show how it's leveraging the reduction spec:
>>>>>>
>>>>>> https://github.com/beancount/beancount/blob/master/experiments/plugins/transfer_lots_test.py
>>>>>>
>>>>>> Maybe this should be part of the builtin plugins.
>>>>>> Love my little plugin system
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Sat, Dec 26, 2020 at 11:14 AM Martin Blais <bl...@furius.ca>
>>>>>> wrote:
>>>>>>
>>>>>>> Here, that's what I meant:
>>>>>>>
>>>>>>> https://github.com/beancount/beancount/commit/9e6e8f8c3793982a6de5af5321e3026d326f8170
>>>>>>> This plugin does what you want (I think).
>>>>>>>
>>>>>>> On Sat, Dec 26, 2020 at 10:29 AM Martin Blais <bl...@furius.ca>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> On Wed, Dec 23, 2020 at 11:11 PM Justus Pendleton <
>>>>>>>> jus...@ryoohki.net> wrote:
>>>>>>>>
>>>>>>>>> On Wednesday, December 23, 2020 at 11:03:44 AM UTC+7
>>>>>>>>> bl...@furius.ca wrote:
>>>>>>>>>
>>>>>>>>>> Short answer is: no, but that's quickly becoming a FAQ from
>>>>>>>>>> crypto users.
>>>>>>>>>> It could be designed, but that would be a new feature.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I only use Spec ID booking so I might be missing something but
>>>>>>>>> isn't moving lots just a small 5 or 6 line python script iterating
>>>>>>>>> over
>>>>>>>>> beancount.ops.holdings.get_final_holdings? Would this work or is it
>>>>>>>>> more
>>>>>>>>> complicated? I'm not sure that a plugin is simpler/clearer than just
>>>>>>>>> generating the transaction externally and then inserting it into the
>>>>>>>>> beancount file.
>>>>>>>>>
>>>>>>>>
>>>>>>>> There's that. OTOH if this is super common for crypto, I'm thinking
>>>>>>>> we should design it in and make it convenient in the input syntax to
>>>>>>>> make
>>>>>>>> such transfers.
>>>>>>>>
>>>>>>>> In theory it *could* be done with a plugin today as Ben suggest: I
>>>>>>>> imagined it more like this though:
>>>>>>>>
>>>>>>>> 2020-12-19 T "Binance" "Transfer BTC Coinbase-Pro => Binance"
>>>>>>>> Assets:Crypto:BTC:Binance 0.2 BTC {}
>>>>>>>> Assets:Crypto:BTC:Coinbase-Pro
>>>>>>>>
>>>>>>>> whereby the plugin would know to select transactions with flag 'T'
>>>>>>>> (or perhaps a tag given in its config, whatever) and convert the
>>>>>>>> posting on
>>>>>>>> Assets:Crypto:BTC:Coinbase-Pro to include all the original matched
>>>>>>>> reductions. I think this should be doable today actually.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> holdings = beancount.ops.holdings.get_final_holdings(entries,
>>>>>>>>> included_account_types=('Assets',))
>>>>>>>>> print(f'{datetime.date.today()} * "ACATS" "Autogenerated lot
>>>>>>>>> transfer to new account"')
>>>>>>>>> for h in filter(match, holdings):
>>>>>>>>> cost_date = None
>>>>>>>>> print(f' {h.account} -{h.number} {h.currency} {{ {cost_date},
>>>>>>>>> {h.cost_number} {h.cost_currency} }}')
>>>>>>>>> print(f' {args.destination} {h.number} {h.currency} {{
>>>>>>>>> {cost_date}, {h.cost_number} {h.cost_currency} }}')
>>>>>>>>>
>>>>>>>>> The only problem I see is that get_final_holdings returns a
>>>>>>>>> Holding tuple that doesn't include the acquisition date. But there's
>>>>>>>>> a note
>>>>>>>>> in the code saying the Holding tuple should go away and just be
>>>>>>>>> replaced by
>>>>>>>>> a Position, which would hold the acquisition date.
>>>>>>>>>
>>>>>>>>
>>>>>>>> beancount.ops.holdings is gone in v3. It was superfluous anyway
>>>>>>>> (well when I started it I wasn't sure if it would start acquiring more
>>>>>>>> features than just an inventory). Now you can simply aggregate over an
>>>>>>>> inventory and enumerate its contents (positions).
>>>>>>>>
>>>>>>>> --
>>>> 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+...@googlegroups.com.
>>>>
>>> To view this discussion on the web visit
>>>> https://groups.google.com/d/msgid/beancount/58b12132-c3cd-401b-98e5-3035d034846dn%40googlegroups.com
>>>>
>>>> <https://groups.google.com/d/msgid/beancount/58b12132-c3cd-401b-98e5-3035d034846dn%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 beancount+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/beancount/e8a70f01-c1d9-4b4f-8276-841f34dfda18n%40googlegroups.com.
