Gnucash Lots?

[Linas Vepstas]

On Mon, May 20, 2002 at 10:06:39AM -0400, Derek Atkins was heard to remark:
> linas@linas.org (Linas Vepstas) writes:
> 
> > Yes, each invoice is a 'lot'.
> > 
> > > The customer pays you a sum of money to
> > > pay for their whole outstanding balance at once (or, worse, only part
> > > of their outstanding balance).  What is the UI that processes this
> > > payment?  
> > 
> > I'm not sure I understand what you are asking.
> > There needs to be a UI that displays a 'lot' aka 'invoice'.
> 
> Except you're not showing just one lot.  Assume you've posted five
> invoices to this customer -- there are now five open lots awaiting
> payment.  This means the UI has to be able to display all five open
> lots at once (and allow a single "payment" transaction to split into
> all of them).

I don't see that you have to show all five invoices at once.  Maybe a
one-or-two-line summary of each invoice, showing the balance, the
due-date, the invoice number...

Imagine an invoice from digikey. It would be five pages long, listing
transistors, resistors,  and whatnot; I'm not sure I'd have the
intestinal fortitude to view more than one of these at a time ...

Otherwise, I'd show only one invoice per dialog, and include a button
that is labelled 'show next invoice for this customer'.

> > > In particular, how do you present "lots" to the user in an
> > > easy to understand manner such that the payment transaction can have
> > > multiple splits to clear out the various lots?
> > 
> > I don't quite understand why this is a 'hard question'.  I imagine
> > that there might be an 'invoice report' which looks similar to 
> > the 'transaction report', except that it only shows the
> > transactions/splits associated with a particular lot.
> 
> Showing just a particular lot is insufficient.  


I don't see why its 'insufficient'.  One lot == one invoice.  Other
accounting packages only display one invoice at a time, I don't see
anything wrong with that.

> Showing all the splits
> for a partcular _customer_ is an interesting report, and is on my list
> of reports-to-write.

Dunno, I'd think that showing a list of all invoices
(a line or two, each) is far more interesting ...

My year-old digikey order: I don't want to see each split.  I just want
to see the date, the amount and the words 'paid in full'.

> > It would be nice to be able to embed the register window into a visual
> > layout that looks more like an invoice, with name, address showing, etc.
> 
> Already done (have you even LOOKED at current cvs to see what's
> already there?)

Uhh, no, I was just answering your question.

> 
> > > I consider this challenging because, simplistically, a user wants to
> > > just say "This customer paid $X on date Y" and have everything else
> > > happen magically (perhaps with some configuration that says something
> > > like FIFO).  
> > 
> > Yes, you'd want to have something that searches through an account to 
> > find all unpaid invoices (all open lots), and apply payment to each.
> > A fifo would do the trick.  Someone needs to write such a fifo.
> > I've no particular opinion as to whether such fifoes belong in the
> > engine, or elsewhere ...
> 
> True, but the question is: how much control do you let the user have
> over this process?  The more control the user has, the more
> challenging the UI.  I've got a "payment dialog" which currently gives
> the user zero choice..  They choose a company, enter the amount, date,
> a reference number, a memo, and chose the bank and posting accounts,
> and the dialog does the rest.

A fifo, correctly implemented, allows payments to be automatically
applied, without having to reference a specific invoice.  This is
because the fifo can automatically find any open/unpaid invoices, 
and tell you what the balance is.

> Currently none of the invoice code (posting or paying) is tied into
> Lots.

Well, you *did* say you needed lots 'yesterday'.  

I don't expect you to start using lots immediately (they're not ready)
but I'm not going to give them high priority if I sense that there is no
interest ...

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