Gnucash Lots?

Derek Atkins warlord@MIT.EDU
21 May 2002 21:17:33 -0400


linas@linas.org (Linas Vepstas) writes:

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

Of course.

> 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

Yes, I know I'm in the middle of your example, however I just wanted
to say here that what you've got so far is currently done (except it
doesn't print the total due in the normal interface, but that can be
added if necessary).  Viewing a single invoice at a time is exactly
the same as 'entering' an invoice (except viewing an invoice is a
read-only operation).

> 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??

Ahh, I see what you mean.  Unfortunately that's not how invoices are
implemented.  The line-items in an Invoice are _not_ Splits.  As you
enter items on an invoice, it adds line-items but does not create any
Splits, nor does it touch any Accounts.  When you "post" the invoice
(there is a "post" button in the toolbar), it creates a single
Transaction and the Invoice-Posting code sums up all the line items
and creates one Split per Account as necessary.

Do you really need a full "show invoice with line-items and all the
associated Lot Transactions?"  I can certainly show the Balance Due,
but showing each payment is going to be a bit challenging given how
it's currently implemented.  I can probably add the "last payment" and
"last payment date", but showing ALL of them is going to be really
hard, at least in a normal register view.  I could do it from within a
report, but I don't think that's what you intended.

> --------------------
> 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.

Invoices are currently core objects.  When you view an Invoice, it
pops up a window (with a register) that shows all the line items.  So,
your single invoice isn't quite a report, but it exists.  Similarly, I
think the summary report is also done in a register-style, although
using the Split Register instead of the Entry Register.

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

I think we were talking about how to view multiple Lots at once....

> 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

Not quite.  I've "jammed" three things into the Transaction KVP:

1) The Due Date
2) A Transaction Type (Invoice or Payment) -- although I suppose I
   really don't need this
3) A pointer to the GncInvoice (the Invoice's GUID)

> 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.

Of course.  I certainly understand why you want/need them, and
honestly I want them for similar reasons.  I'd like to be able to use
Lots to keep track of which Invoices have been paid, and which have
not.

> > 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 ... 

Well, I suppose that a 'generic lot viewer' would just be a ledger
with a Query that looks like: "find Txns where LOT=<guid>"

> ? 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. 

Except that Invoices don't use Splits.  There is a completely separate
storage mechanism for Invoice line-items, because they need to exist
outside the Account hierarchy (and Splits didn't like to play nicely
with all the extra account information I wanted to store).

When you post an invoice, it will create a new Lot with a single
Transaction.  This one Transaction will contain a single Split in
each necessary account.  For example, if the Invoice contains:

Desc            Acct            Qty     UnitPrice
paint brushes   Paint           10      $2.95
paint           Paint           5       $19.95

When you post this Invoice, assuming you post to A/R, you will get a
Transaction with only TWO splits, one split tied to A/R, the other
split tied to Paint.  The date of this Transaction will be the Invoice
Post Date.

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

I agree.  The former needs to be done, and the latter I talked about
already.

> 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"? 

Oh, Yes.  I meant "show the summary of all open lots for Customer
XXX".  The summary would be similar to what is currently shown in the
A/R account in CVS: Customer Name, Invoice Number, Memo, Values, and
Payments.  Sorry, I did not mean "show 5 Invoices in gory detail".

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

True.

> > 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?

Yes.

> 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.

Well, with Lots it wont matter as much.  The reports can just link the
transactions by Lot instead of linking them by "Customer Name".  Then
the visible entries in the transactions are for the user but
internally the "right thing" will happen.

The straightforward algorithm to print a "customer report" would be:

        lots = find_all_open_lots (account);
        lots = find_lots_by_customer (lots, customer);
        show ...

To print an aging report, you would just leave out the second step,
because you'd want a total for each customer.

(This procedure would be instead of comparing the Description from
each Transaction, which is what is currently done).

> --linas

-derek

-- 
       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