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/94ae1b29-5adb-49c5-87d3-8101e41e8a28n%40googlegroups.com.
