On Sun, Jul 13, 2014 at 1:12 PM, Stefano Zacchiroli <z...@upsilon.cc> wrote:
> On Mon, Jun 23, 2014 at 02:02:57AM -0400, Martin Blais wrote: > > I've been doing some thinking about improving the booking method used > > in Beancount. In the following document, I summarize the issues with > > inventory booking and list some unsatisfied use cases, identify > > current shortcomings in both Beancount and Ledger (with specific > > examples), list a set of requirements for a better inventory booking > > method and outline a design proposal for an improved method: > > > > > https://docs.google.com/document/d/1F8IJ_7fMHZ75XFPocMokLxVZczAhrBRBVN9uMhQFCZ4/ > > I've finished going through it only now. I'm affected by one of the > problems you describe, namely the inability to book against the average > cost lot (your "{*}" syntax), and I've found the solution you propose > quite elegant. Ditto for the mechanisms of specifying lots and > resolving incomplete (or "ambiguous", if you wish) lot specifications. > > [ In passing: the only way I've found with Ledger to actually find out > the average lot price is to first do > "ledger bal Stocks -l 'commodity == XXX'", then redo the same adding > "-B", and finally do the division myself. If there is a better way, > I'd be glad to learn about it. ] > That might even be incorrect, I'm not sure. I believe Ledger does not reduce lots, it seems to be matching positive and negative lots by "grouping" only at the reporting level (I'm not entirely sure about this, Zach make a comment on the doc this morning pointing out the --lot-prices and --lot-date options, and the behavior seems to point that way, e.g., you can "reduce" a lot that does not exist. I should go dig in the source code to find out). So if you have some past history of lot additions and reductions, they might affect the average cost you end up with using your method, whereas the current inventory may not include all the lots that are being used. I'm left wondering whether average cost basis should be a per account > property, rather than (or maybe: in addition to) something that > auto-magically happen the first time you post using "{*}". > Yes, and I like that too. I think I mentioned adding an attribute to the Open directive somewhere in order to let the user specify the default booking method. I'll add a more explicit section in the proposal about this, with an example. Your main example for average cost basis are tax sheltered accounts. By > definition that is an example of an account-specific property. If that > is a common use case for average cost basis, then it'd make sense to > allow user to declare accounts (or account/commodity pairs, as we > discussed in the customizable rounding thread) as average cost basis. > Those accounts will have the property that they always contain a single > lot, whose cost is updated every time you post something to it, > computing the new average cost. > > I wouldn't mind having both the ability to declare accounts as average > cost basis and, for other accounts, automatic fusion at the first > occurrence of "{*}". > Yes, you're understanding everything right. That is exactly the proposal: let a user provide the default booking method, while leaving the possibility open for manual overrrides. I've also added other (minor/editorial) comments to the document itself. > Thanks Stefano! :-) -- --- You received this message because you are subscribed to the Google Groups "Ledger" group. To unsubscribe from this group and stop receiving emails from it, send an email to ledger-cli+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
