"Internal Lot Links" mess in Accounts Receivable

Geert Janssens janssens-geert at telenet.be
Wed Jan 15 07:38:15 EST 2014


David,

Thanks for your elaborate feedback. I'm currently too busy with real life to go into this in more 
detail, but I intend to come back to it later.

In general I have found the internals of the invoice/payment system rather complex. Touching 
something in one end frequently resulted in things suddenly going wrong in the other end.

To my disadvantage I am about the only active developer that really uses the business 
features still (Derek may still use them as well, but he's less involved in coding lately). As a 
result the implementation concept evolved gradually with little feedback to what is is now.

So I'm happy with your feedback and suggestions and will evaluate how realistic they are 
some time later.

Geert

On Wednesday 15 January 2014 02:45:24 David Beattie wrote:
> Geert,
> 
> Thank you of course for your work in development.  I am a former
> developer myself, so I know how time consuming and tricky it can be
> to get things right, so don't let my late-coming critical feedback
> give you the impression that your work is unappreciated!  I hope that
> my thoughts will be found to be helpful rather than a distraction,
> but if what I have to say just ends up showing an ignorance of the
> internal workings of GnuCash, then... well you can just take it as
> the perspective of somebody trying to figure out how to use the new
> features, and finding them to be a work in progress... which we
> already knew.  Version 2.6.0 seems stable, which is the most
> important thing, and the new features do work, even if there's room
> for improvement.  And I do like the new features. :)
> 
> I have thought a lot about the "lot links" that you implemented, and I
> understand your design now.  The old GnuCash 2.4 invoices are showing
> up in GnuCash 2.6 as a single lot for each invoice (perhaps this was
> the way it was implemented in 2.4 already?), with payments added to
> the lot until the lot is closed, at which point the invoice is
> considered paid.  But when payments go to more than one invoice, then
> the payment transactions had to be split in the register.  By
> introducing a "lot link", you now avoid creating splits for a payment
> transaction, and rather enter it in a "pure" manner... and then use a
> "payment lot" to link this to the "lot link" transaction, where the
> splits could be split out to the individual invoices with their
> invididual "invoice lots", and if a payment lot has a positive
> balance, then that's a pre-payment.  So your new implementation
> proxies the split assignment through the payment lot and into the lot
> link transaction, so in a sense it's cleaner because a payment itself
> never has to be split in AR.  But in another sense it's more
> complicated because it introduces persistent payment lots and an
> extra "lot link" transaction per payment, and pre-payment and split
> payments are really only visible in the dialog boxes and can't be
> seen easily in looking at the raw AR data (if you ignore the Lot Link
> transactions).  And you have to be careful to think about what might
> happen if the payment amount is adjusted in the register now, because
> it's not going to touch the lot links automatically, so you end up
> with a prepayment or underpayment in the payment lot, and need to
> re-assign the payment again.  Also, contrary to your simplified
> statement that you can see what payments pay each invoice in the lot
> viewer, because the link between payments and invoices is lots....
> it's actually not anymore,... the link between payments and invoices
> is now "lot links", and payments and invoices never meet in a single
> lot anymore, except in the legacy data,... so you can't see this data
> in the lot viewer for new invoices because it doesn't show the
> contents of "linked lots" in a special way.
> 
> To handle credit notes, it seems obvious that something like a lot
> link is helpful, since the credit from one invoice can be applied as
> payment to another invoice, but I'm sure this could have been handled
> in the simpler 2.4 style as a simple, differential-valued payment
> (possibly net-zero-valued if the credit matched the invoice amount),
> that "pays" the positive and negative invoices at the same time with
> opposite-signed splits--this is the same as a lot link, except it
> doesn't actually matter if the transaction type is marked as
> "payment", or "lot link", as long as the positive and negative
> invoice splits close out the invoice lots in question so they can be
> marked paid.
> 
> 
> So I still think it makes more sense the simpler way, to have invoice
> lots only, and be much more sparing with payment lots, but that's my
> opinion and I'm not the one writing the code, so I may be wrong.  In
> the old 2.4 implementation, payments were split and assigned
> automatically, and sometimes wrongly, so adding a dialog box to do
> the explicit assignment is a big improvement!  I imagine the new
> dialog could have just tweaked the splits for the payment, to make as
> many payment splits as assigned invoices, and added each payment
> split directly to the proper invoice lot; any leftover pre-payment
> split would have to be assigned to a temporary "pre-payment lot",
> which would disappear once the pre-payment were fully assigned to pay
> a future invoice.  Of course your implementation went a different
> direction, always making a permanent "payment lot" for each payment,
> and splitting the payment via the "lot link" transaction instead, and
> of course this will work if it's carefully implemented, I just have
> to wonder if it's unnecessarily complicated.  I read your list of
> problems you were trying to address with the new implementation, and
> none of them seem to require the lot links to me, at my admittedly
> naive distance from the source code.  If you still say they're
> necessary, I'll have to trust your judgment.  But I think
> reconciliation will continue to be a problem, perhaps worse now than
> before.  It definitely would have helped usability in GnuCash 2.4 if
> reconciliation flags were removed on payment splits that were paying
> an invoice, when that invoice was unposted.  But really, who is
> reconciling the Accounts Receivable?  (I was, obviously, since I
> actually did run into this as a problem.)  You already said we
> shouldn't be poking around in the AR register anyway!  With lot links
> present, reconciliation in Accounts Receivable is UGLY now and takes
> a lot of thought, so I probably won't even try it anymore.  But this
> was never necessary, either in 2.4 or now in 2.6, because we have
> intelligent reports like "Receivable Aging" to filter and display the
> Accounts Receivable data for us.  Rather, it is the asset accounts
> that payments are deposited in, that need to be reconciled, and this
> is unaffected by unposting an invoice that a payment may be assigned
> to, since it's the split in the asset account that's marked
> reconciled in that usage scenario, not the split in Accounts
> Receivable.  Reconciled splits from invoice line items can cause
> problems once re-posted, but that's an unrelated issue.  Similarly,
> deleting a payment may cause reconciliation problems in the asset
> account if that's already reconciled, but that's just asking for
> trouble!, and that should be covered by some sort of "delete
> reconciled transaction?" confirmation box, and that's also unrelated
> to unposting the invoice, except that we lose the assignment of the
> payment when it's unposted.
> 
> I actually have practical suggestions, believe it or not!
> 
> The "Assign Payment To", dialog is creating the Lot Link transactions,
> and I was wrong in stating that I couldn't make it work.  The reason
> it was coming up empty for me is that it doesn't auto-populate the
> Customer that the payment originally was intended for.  If there is a
> record of the customer number in the payment transaction (aside from
> the obvious, the memo text), then populating it automatically into
> the Assign Payment dialog would go a long way to making this easier
> to use.  The user could always change the customer in the dialog box


More information about the gnucash-user mailing list