On Mon, May 20, 2002 at 10:06:39AM -0400, Derek Atkins was heard to remark: > [EMAIL PROTECTED] (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!) <[EMAIL PROTECTED]> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 _______________________________________________ gnucash-devel mailing list [EMAIL PROTECTED] http://www.gnucash.org/cgi-bin/mailman/listinfo/gnucash-devel
