Gnucash Lots?

Linas Vepstas linas@linas.org
Tue, 21 May 2002 19:09:50 -0500


On Mon, May 20, 2002 at 09:44:05PM -0400, Derek Atkins was heard to remark:
> linas@linas.org (Linas Vepstas) writes:
> 
> > I don't see why its 'insufficient'.  One lot == one invoice.  Other
> 
>  A Lot is not an Invoice.  

OK, yes, I was being glib.  Since we often understand each other, I 
was taking a communications shortcut and not being terribly precise.

> For example, AGAIN, if you've invoiced Customer XXX five times,
> wouldn't you like to see a report that says:
> 
>         invoice #258:   customer XXX    $138.27
>         invoice #327:   customer XXX    $1924.29
>         invoice #367:   customer XXX    $193.28
>         invoice #401:   customer XXX    $205.79
>         invoice #420:   customer XXX    $1000.17
> 
> This is viewing five lots at once.  Anything that can't do this
> is just broken.

I would not argue that.  Its nice to have a report where each invoice is
summarized in one line.

But its equally critical to view a single invoice at a time:

invoice #258    customer XXX
Order placed 20 December 2001
    quant (10) gallons paint    $10/each   $100
    quant (2) paintbrushes        $15/each  $30
               sales tax                     $8.27
                                         ------------
                Total due                  $138.27

Payment received 24 january 2002   $50      Balance Due: $88.27
Payment received 13 february 2002  $88.27   PAID IN FULL

The three transactions in this invoice are all part of one lot in
the "AR Invoicing" account.  In this sense, there is one lot per invoice, 
and one invoice per lot.   This one-to-one correspondance is why I said
that a lot is an invoice.

Detail: the first transaction might also appear in a lot in the "paint"
inventory account, and also in lot in the "paintbrushes" inventory account.
So in fact there are at least 3 lots here, maybe a fourth for taxes??

--------------------
There are times one wants the summary report, and times that one wants
the one-invoice-per-page report. They're both 'must-have' reports.

But I don't see what this has to do with our initial discussion (whose
point I've forgotten).

Now, I suppose that its possible to jam all of this info, and some
of the logic, into the kvp frames in the originating transaction. 
(which seems to be what you've done).  But I figured that there
would be some convenience in offering up lots to the invoicing
subsystem, and etc.  I admit that part of that convenience is for
the book-closing code ... other than that, you are free to do as you
like.   But If I am to close books properly, I need to be able to
handle lots correctly.


> Note that actually viewing the Invoice (which is NOT viewing the Lot)
> is separate.

I don't see a need for an actual lot viewer.  Instead, there's a 
customized viewer for stocks, and another customized viewer for
inventory. And one for invoices.  Maybe a generic lot viewer would be
handy for audting or something ... 

> Please re-read what I said.  I did not say "show all five invoices at
> once" I specifically said "show all five open lots at once".  Again, a
> lot != an invoice.  A lot is only the the transaction that results
> from posting an invoice.

? I'm confused.  A lot consists of many transactions, spread across
many dates.  Actually, to be precise, a lot consists of many splits,
but those splits can belong to different transactions.   The only
constraint on a lot is that all splits in a lot must belong to the same
account.

In this sense, a lot *is* like an invoice, with the exception that a lot
doesn't "natively" store the customer name, the billing terms, etc. 

To me, the only reports that make sense are:
"show summary of 5 lots at once"
"show one lot in gory detail"

What doesn't make too much sense to me is to show 5 lots in gory detail
at once.  I'm not sure what the benefit of that is.

Did you mean "show the open balance of 5 lots"? 


> mostly because I don't think you understand what's already
> been done.

I haven't even tried to understand what's already been done. 
I don't see how that's relevent to the conversation. 

> Perhaps we just don't have a common vocabulary, here?  I don't know
> for sure, but I think if you look at how Invoices work in current CVS,
> and how Invoices interact with A/R, A/P, and the current Chart of
> Accounts, I think this conversation can be much easier.

Uhh, I don't understand why I need to understand your code in order to
implement lots.   Per our earlier discussion, I was implementing lots
because (a) I gotta have it to close books correctly, and (2) it makes
certain stock reports easier (3) it makes depreciation easier (4) it
might make it easier for you to get invoices working correctly.  

I remember your complaing that you had trouble determining when an
invoice was paid in full.  So I offer lots as the solution to that. 

Division of labor.  Modularity.   You shouldn't need to understand 
my code to be able to use it. And v.v. 

> There is interest.  I do want to use them, as fifos, as a means to
> attach payments to invoices with something more that just a string in
> the Transaction Description that contains the Customer Name.  The
> reason I want something more is: what happens if you have two
> customers with the same name?

Ahh, I assume every customer gets a unique GUID?

In peachtree, the bookkeeper assigns a unquie customer ID, three letters
and three numbers e.g. LIN001 and WAR001 and if there's a second LIN
then they're LIN002, etc.  All reports, menus, listboxes, etc
use these user-defined customer ID's.   Ugly as sin, I think, but that's
what is commonly done.

--linas


-- 
pub  1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <linas@linas.org>
PGP Key fingerprint = 8305 2521 6000 0B5E 8984  3F54 64A9 9A82 0104 5933