On Sun, Jul 13, 2014 at 01:27:30PM -0400, Martin Blais wrote:
> 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 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've already witnessed first hand that Ledger does allow you to reduce
lots that do not exist (going negative). So I'm still not seeing the
risk of incorrect calculation that you hinted at; if you think it's
real, can you try to build one? (or give me some extra hints so that I
can try building it).
> > 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 "{*}".
On Sun, Jul 13, 2014 at 01:29:10PM -0400, Martin Blais wrote:
> Actually, there already is one, right here:
> https://docs.google.com/document/d/1F8IJ_7fMHZ75XFPocMokLxVZczAhrBRBVN9uMhQFCZ4/edit#heading=h.k18hdhviv191
Your comments made me realize two things:
1) what I actually had in mind was the ability to declare *mandatory*
average cost posting for a given account, inhibiting usage of other
booking methods on it. That was not entirely clear to me when I wrote
my previous message, so thanks for making me realize that :)
What it is currently supported by your proposal is only setting the
*default* booking method, but that does not stop others methods from
being used. The invariant I've mentioned in the previous post
(ensuring that only one lot exists) can be guaranteed only by
mandatory booking method.
[ Aside: upon re-reading the above section, the AVERAGE option is
kinda confusing. My understanding of the FIFO and LIFO options is
that they are limited to disambiguating among the lots that have
been selected by your matching algorithms, i.e., they are not
LIFO/FIFO across all lots. OTOH AVERAGE makes sense only when
computed across all lots. So discussing FIFO/LIFO together with
AVERAGE is puzzling. If that is really what you want, this "detail"
should be communicated more clearly, IMHO. ]
2) in terms of design, it'd probably be better to enforce the constraint
of having a single lot as some sort of post-booking check, rather
than overloading even more the expressivity of account declaration
options. (Note: I'm not a Beancounter user, so it's not clear to me
if you've enough expressivity in your checks to encode this. But that
sounds like a better place where to put this.)
Cheers.
--
Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »
--
---
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.
