Lots in Account screen : Value sign
geert.gnucash at kobaltwit.be
Thu Aug 25 05:59:11 EDT 2016
On Wednesday 24 August 2016 23:12:54 Linas Vepstas wrote:
> Wow... you're asking me to remember something from 12 years ago ...
Your memory is good! Though it reminds me we're not only commenting our
code for other devs, but also for our future selves...
> Here's my best guess: for a "lot", I had the mental model of starting
> with 100 of something ... e.g. 100 cans of paint, and then selling
> them off in dribs and drabs. Thus, the first entry, that opens the
> lot, has a sign that differs from all the others. By definition,
> there can be only one such entry in the lot, -- by definition, all of
> the other entries must have the opposite sign. Lots can only shrink
> and get smaller.
> So -- I buy 100 cans of paint at $10 per can, then sell 20 at $15 a
> can, then sell 35 at $17 a can, then sell 45 at $12 a can, closing
> out the lot (forever, since all the paint in that lot is now gone).
> Lots could be shares of stock, could be cans of paint, cartons of milk
> marked by expiration date -- anything that is naturally counted in
> non-monetary units, and come in lots (i.e. you want to sell/use/drink
> the oldest milk first, so you really do want to track the
> date/lot-number). More abstractly, lots could be shipments to a
> customer, unfilled or partially filed orders, whatever --
So far so good...
> With this concept of a lot, its impossible to add more to the lot --
> once opened, it can only be depleted. Thus, the split that opens the
> lot is "special". By assumption, its the very first split; it doesn't
> really make sense for it to be any other. That is, I can't sell cans
> of paint that I don't yet have. At least, that was the initial
> conception of how lots work.
According to the code that "very first split" is determined by date
posted. This works well for the scenarios you describe above. It fails
however for business transactions of which you provide one example
> Now, we all have read the news about corporations that sell things
> before the customer takes delivery, leading to various accounting
> scandals. I suppose there are other legitimate uses of lots, which
> somehow get overdrawn before they are stocked up. Or something. But
> that got confusing to think about, and was not a part of the design.
That's fair. So I'll need to think about how to extend the design to
work well for the extra business use cases as well.
> I'm not at all clear as to why payments or invoices are going through
> the lot system, other than maybe you bill someone $100 and they pay
> you in installments? Ans so you want to match up the installments
> with the original invoice, until its paid off? I guess that's a
> valid use of lots...
Payments in installments, pre-payments, over-payments, paying multiple
invoices with a single payment,... all these have been made possible by
> If the sign is wrong for that special, first
> entry, then that's the fault of whomever opened that lot.
It did ignore the assumptions made in the original implementation. It
seems the date based method of finding the opening split is too limiting
to accommodate the business requirements. But that's fine. I can work
from here to get that fixed.
Thanks for the design background!
More information about the gnucash-devel