Gnucash Lots?

[Derek Atkins]

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

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

> Similarly, an invoice editor would be the register window, except
> that instead of showing all splits in an account, it would show all
> splits in a lot.  But the 'gui' doesn't need to change (other than
> column labels).  

Well, not quite.  An Invoice is quite different, because before it is
posted you have these dangling entities.  Editing invoices is done
outside the CoA.  Besides, invoice editing is already done. ;)

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

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

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

> >         Transaction * gnc_lot_get_initial_txn (GncLot *);
> 
> OK, yes.  By 'initial', I will take that to mean 'earliest'.

Maybe.  One would think intuitively that that is the case.  I mean,
how often does one pay an invoice before it is posted?  Although I'm
not exactly sure how to handle pre-payments, deposits, of
over-payments...

> > Note that there is already a "Due Date" in a Transaction (stored in
> > the kvp).  See xaccTransGetDateDueTS().
> 
> Hmmm. That should probably be depricated in favor of xaccLotGetDueDate()

Ok.  When Lots are more solid I'll switch.  For now, however, what
I've got is both implemented and working (at least with XML ;).

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