Gnucash Lots?

[Derek Atkins]

linas@linas.org (Linas Vepstas) writes:

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

Hmm, honestly I could never see how this would be useful..  To me, I
can see a customer account summary, or showing an individual invoice
to show what was done at a particular time, but a combination of the
two, like you seem to be proposing, just doesn't make sense to me.

> > Ahh, I see what you mean.  Unfortunately that's not how invoices are
> > implemented. 
> 
> 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. 
> I dunno.

Nope.  An Invoice has a list of Entries but has exactly one
Transaction pointer -- and that pointer is created when an Invoice is
Posted.  I'll define this later in this email.

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

We had this dicussion about 6 months ago, however I will reiterate
my reasons here.

1) Entries need to be tied to both Invoices and Orders, which means
   you need multiple pointers.  Both of these would have to be stored
   in kvp entries in the Split.

2) Splits want to be tied to an account, but I don't want to touch any
   accounts until you post the invoice.  This means you would need to
   store the account information in a KVP until you actually post.

3) Entries have discounts, discount types, taxes, and tax types, all
   of which would need to be stored in the kvp if an Entry were a
   Split.

In other words, almost ALL the information would be stored in the kvp
of a Split, if Splits were being used.  Very little information would
actually be stored in the Split itself.  When you wanted to search for
an Entry, it would make it much harder if you had to search by KVP.

At the time, I decided it would be much easier to make Entries their
own data structure.  This required me to implement an EntryLedger
(which is a "reimplementation" of the SplitRegister, but for Entry
objects instead of Splits).

The reason I'm saying this is hard is that the Invoice display
currently uses an EntryLedger, so it cannot display Splits, only
Entries.

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

Well, yes, but xaccTransCommitEdit() is not the same as
gncEntryCommitEdit().  The issue is that I necessarily want invoice
items to remain out of your Chart of Accounts until the end, when you
actually post it.  In other words, you collect the items on an
invoice, but it's not actually moving money in your accounts until you
click "Post Invoice".  When I say "post an Invoice", what I mean is a
call to gncInvoicePostToAccount() which does the following:

- walk through each entry in the invoice
- for each entry:
  - determine the entry's value and tax value
  - determine the account and add the value to the temporary
    storage tied to the account
  - determine the tax account add add the tax value to the temporary
    storage tied to the tax account
  - keep a running total
- create a new Transaction
- walk through the list of seen accounts.
- for each seen account, create a split with the sum of values
- create a split for the total invoice
- commit this transaction.

> > Do you really need a full "show invoice with line-items and all the
> > associated Lot Transactions?"  
> 
> 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.

Is it?  I've certainly never seen it in anything I've had access to.
I've seen:

- Show a full invoice (with balance due)
- Show a customer summary (unpaid balances and 'total due')

> > I can certainly show the Balance Due,
> > but showing each payment is going to be a bit challenging given how
> > it's currently implemented.  
> 
> 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).

Unfortunately it is a lot of lines of code, because there are no
Splits in the Invoices (and no SplitRegister in the Invoice Window).

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

See above:  no Splits, no SplitRegister in the Invoice Window.

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

Ok.  That makes life a lot easier.  I can do that.

> > > 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. 
> > > (which seems to be what you've done).  But I figured that there
> > 
> > Not quite.  I've "jammed" three things into the Transaction KVP:
> > 
> > 1) The Due Date
> 
> I'm guessing that the lot would be a more appropriate home for this.

Probably.

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

Well, the transaction type is just there to know when to show the Due
Date or not in the particular Transaction in the A/R account view.
The idea being you can get a quick summary of all your posted invoices
and posted payments, and the invoices will show due dates, but
payments will not.

Payment Terms are in the Invoice; I'm not conviced they need to be
duplicated in the Lot.  The discount is per-Entry, and definitely
cannot not live in the Lot.

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

No, there is too much information in the Invoice.  The Invoice really
is tied to the transaction that is posted, not the Lot.

> > 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 
> 
> Why?  I suspect/am hoping there's a 'deep' reason, not just a whim ...

See above.

> > (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? 
> The theory was that kvp solved 'all possible problems', so I'd like 
> to know why it doesn't do that here ...

I tried using Splits.  It turns out that about 75% of the information
I needed wasn't available in a Split, and would need to be stored in
the kvp.  When that much information needs to be stored elsewhere, it
certainly sounds like "I've got this hammer" syndrome to me.

[code snipped]

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

So long as this combination is only needed in the HTML Report,
then no, this wont be a big deal.

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

I don't want to think about that, if you don't mind ;)

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