Book clsoing [was: Re: Addition of HBCI support, Maturity of 1.7-branch, next stable release time frame?
16 Apr 2002 11:15:56 -0400
email@example.com (Linas Vepstas) writes:
> Hi Derek,
> Don't alarm me ...
> On Tue, Apr 16, 2002 at 10:35:29AM -0400, Derek Atkins was heard to remark:
> > The real problem is that we do not track individual widgets in the
> > "stock" accounts.
> Huh??? Sure we do! Or did you mean 'lots'?
No, we track the total number of widgets, not each individially. We
don't keep track of which individial widget is sold (or which lot is
was sold from). So, perhaps I do mean "lots", but I really don't.
> > 1) when you close a book, you only need to copy the unsold widgets
> > into the new book
> ?? Well, of course: this is the 'balance' of the account.
> And the book-closing code does handle this.
> But its not the 'only' thing; you also need the 'age'.
Right, this is what I mean by tracking individual widgets.
> > 3) a business "inventory" solution would fall out as well (because you
> > do need to track individual widgets).
> The gnucash engine has been designed, from almost the begining, to
> deal with inventory, by counting widgets, not dollars. That's why
> there's a price DB. That functionality has always been in there.
But this is insufficient for stocks. You need more than just the
total number of widgets in your inventory. You also need to know
when each widget was bought, and at what price.
> > add information to the "sell a widget" transactions
> *All* gnucash transactions are 'sell widget' transactions, even the
> dollar ones, where the widget is a dollar, and the price of the dollar
> is 1.00000000 dollars per dollar.
> > which point back
> > to the lot(s) that were (partially) sold.
> What gnucash does *not* do is track lots. Version 1.2 used to, with a
> FIFO, but that functionality was lost in 1.4 due to political reasons.
> Some of the developers did not understand the concept, and trashed the
> code. :-(
> Tracking lots is the 'definition' of A/R and A/P. You want to be able
> to say that this bill is 120 days old, and its balance has been partly
> paid off; and this whether or not there are also other bills, of
> different ages, to the same company. This is *identical* to tracking
> lots of stock or widgets. If/when you add A/R and A/P, you will
> defacto have a lot tracking system that is suitable for inventory.
Perhaps. That's not the way the current A/R and A/P are implemented.
While each transaction has a post date and a due date, there is no
logic to see when a particular bill has been paid, and there is no
support currently for partially-paid (or over-paid) bills.
But I don't see this as the same as inventory or stock tracking.
> I am somewhat concerned about how you phrased yourself in this note...
> Either you don't really understand how the engine really works (and this
> surprises me), or, I dunno... your choice of phrasing is funny ...
Perhaps the latter. Hopefully my comments inline here help clear
up this definitional difference? My issue is that while gnucash does
deal with widgets, it doesn't track them individually -- it tracks them
en-masse. When you buy a widget, it gets combined with all the other
widgets, and loses its identity.
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warlord@MIT.EDU PGP key available