Gnucash Lots?

[Linas Vepstas]

--wRRV7LY7NUeQGEoC
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, May 21, 2002 at 09:17:33PM -0400, Derek Atkins was heard to remark:
> linas@linas.org (Linas Vepstas) writes:
>=20
> > But its equally critical to view a single invoice at a time:
>=20
> Of course.
>=20
> > 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
>=20
> 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).

My example ws for a 'typical' invoice, and they tyupically have a
balance due and sometimes other subtotals showing (e.g. balances before
a discount).

> > Payment received 24 january 2002   $50      Balance Due: $88.27
> > Payment received 13 february 2002  $88.27   PAID IN FULL
> >=20
> > 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 invoic=
e,=20
> > and one invoice per lot.   This one-to-one correspondance is why I said
> > that a lot is an invoice.
> >=20
> > Detail: the first transaction might also appear in a lot in the "paint"
> > inventory account, and also in lot in the "paintbrushes" inventory acco=
unt.
> > So in fact there are at least 3 lots here, maybe a fourth for taxes??
>=20
> Ahh, I see what you mean.  Unfortunately that's not how invoices are
> implemented.=20

Ahh, well, once lots are further along, I'll push to make it look more
like the above ... I don't think the changes to use lots will require
more than a few to a few dozen lines of modified code.  Some trasnaction
pointers will become lots pointers,and not much more.  That's my guess.=20
I dunno.

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

You mention later that the line-items aren't splits because somehow
splits weren't a 'freindly' interface to work with.  I'd like to
understand the technical/philosophical; reasons why, since, to me,
line-items should 'obviously' be splits.

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

I assume "post" translates into xaccTransCommitEdit(), right?
(because posting is what it was designed to do ... unless we are working
with different definitions of what "post" means, and, if so, I'd like
to figure that out now, rather than later ...


> Do you really need a full "show invoice with line-items and all the
> associated Lot Transactions?" =20

Well, I *personally* don't need it, but I think that this is a standard
and expected feature that a business accounting package would have.

Note that in my example, the formatting is 'interesting':  The=20
first transaction, the one that opened the lot, shows all the line
items.  The subsequent 'payment received' lines are merely summaries,
(summaries of the other splits in the lot) and don't show line
items or other gory detail.

> I can certainly show the Balance Due,
> but showing each payment is going to be a bit challenging given how
> it's currently implemented. =20

Well, I'm hoping, I'm guessing, that if lots are implemented correctly,
that its not a whole lot of lines of code to switch over.   On the
engine side, its no harder than looping over the splits in a lot,
and displaying the first split/trnasaction a bit differently than the
rest.  That should be easy.  But if your gui code does some sort of
implcit data fetching, rather than simple for loops, then I dunno, maybe
its hard(er).

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

Uhh, why do you say this? Normally, with the register, you say "here's a
bunch of splits, display them", unless the register is in 'ledger mode'
in which case the transactions are automatically displayed.   Since
a lot is just a date-ordered bag of splits, with a running balance
(i.e. its 'like an account'), I would have guessed it would  be=20
straightforward.

> I could do it from within a
> report, but I don't think that's what you intended.

Well, technichally, I guess I mean the report. The GUI allows the user
to enter the information, but when it comes time to print/fax/email
an invoice, one doesn't send a screenshot of the GUI.  One sends
a 'report', with the company logo on the top of the page, etc.=20

So all that nice formatting? I care about it less in the GUI, but in the
report, its critical to have a nice-looking printable report.

> > 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.=20
> > (which seems to be what you've done).  But I figured that there
>=20
> Not quite.  I've "jammed" three things into the Transaction KVP:
>=20
> 1) The Due Date

I'm guessing that the lot would be a more appropriate home for this.

> 2) A Transaction Type (Invoice or Payment) -- although I suppose I
>    really don't need this

Dunno, it should probably live with the due date (and payment terms, and
discount offered, etc.)

> 3) A pointer to the GncInvoice (the Invoice's GUID)

My 'obvious' assumption is that this would get moved to the lot as well.
As it would seem to be the more appropriate home for thiss info,
as it applies to the splits in the lot, and not to the transaction.

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

Why?  I suspect/am hoping there's a 'deep' reason, not just a whim ...

> (and Splits didn't like to play nicely
> with all the extra account information I wanted to store).

? What do you mean by this?  Can splits be fixed to play nicely?=20
The theory was that kvp solved 'all possible problems', so I'd like=20
to know why it doesn't do that here ...

> The straightforward algorithm to print a "customer report" would be:
>=20
>         lots =3D find_all_open_lots (account);

GList * find_all_open_lots (Account * acc)
{ =20
  GList *n, *open =3D NULL;
  for (n=3DxaccAccountGetLots(acc); n; n=3Dn->next) {
    if (!xaccLotIsClosed ((GNCLot *)n->data))=20
          open =3D g_list_append(open, n->data);
  }
  return open;
}

That's real code, not pseudocode. Should compile and run today ...

Although this should probably be added as a utility in the engine.

>         lots =3D find_lots_by_customer (lots, customer);

The following is pseudocode ...

GList * find_lots_by_customer (GNCLot *lots, BusXXXCust* ...)
{
   GList *n;
   for (n=3Dlots; n; n=3Dn->next) {
     kvp_frame * kvp =3D gnc_lot_get_slots (n->data);
     customer =3D kvp_get_value (kvp, "CustomerGUID"); =20
     ...
   }
}


The overall simplicity of these loops is why I'm hoping that this won't=20
be a big deal.   There are hard parts, but they're elsewhwere ...


(The hard part, for me, is how to convert 'old' gnucash datasets into
datasets that use lots, somehow automatically, with minimal or no=20
druid-ity.  That's the part that give me creeps.)

--linas


--=20
pub  1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <linas@linas.org>
PGP Key fingerprint =3D 8305 2521 6000 0B5E 8984  3F54 64A9 9A82 0104 5933

--wRRV7LY7NUeQGEoC
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE87C1dZKmaggEEWTMRAoLlAJ4tr9jITtqbtDXhIob6UZPlLO21EQCdFeKv
alodw7bu2fI/9zz3K3teITk=
=eoYj
-----END PGP SIGNATURE-----

--wRRV7LY7NUeQGEoC--