Gnucash Lots?

[Linas Vepstas]

On Mon, May 13, 2002 at 12:13:23PM -0400, Derek Atkins was heard to remark:
> linas@linas.org (Linas Vepstas) writes:
> 
> > On Tue, May 07, 2002 at 01:13:59PM -0400, Derek Atkins was heard to remark:
> > > I could use it as soon as yesterday ;)
> > 
> > I roughed in a very minimal API; there is not backend support yet.
> 
> I think the UI issues are more fundamental that the engine issues.
> In particular:
> 
>  . how does the UI represent lots to the user?
>  . how does the UI allow transactions to cross multiple lots?
>  . how is this latter part done "easily" (i.e. easy for the user?)
> 
> Here's my scenario: You've invoiced a customer a few times (because
> you've had a number of work orders for them).  Each posted invoice is
> going to have its own transaction (does this imply each invoice is its
> own lot?  I would think so).  

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

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

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

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.

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

> Obviously there needs to be a more advanced dialog for
> users that really want to specify their lots.

obviously, there's a 'lot' more code to write.  

The goal of 'lots' was to knock off inventory, invoices and cap gains
with the same piece of code.  Unfortunaltely, at higher levels, the code
diverges, and these three things need three distinct guis.

> > Please review what's there, let me know what other API routines are
> > needed.   e.g. do you need a date-posted field?  if so, can I return the
> > date of the transacton of the earliest split in the lot?  etc ...
> 
> I've only looked at gnc-lot*.h so far.  Looks fine to me.  I don't
> think we need a date-posted field, however a function that looks like
> this would be useful:
> 
>         Transaction * gnc_lot_get_initial_txn (GncLot *);

OK, yes.  By 'initial', I will take that to mean 'earliest'.

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

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