"Internal Lot Links" mess in Accounts Receivable

Geert Janssens janssens-geert at telenet.be
Mon Jan 13 17:16:59 EST 2014


Hi David,

Thank you for your feedback and sorry for the bad experience. But as you already mention 
yourself, it would have helped a lot if you gave this feedback during the development cycle.

Anyway further comments in between:

On Monday 13 January 2014 13:19:43 David Beattie wrote:
> Hi,
> 
> I'm new to this e-mail list, and I'm not sure if this discussion
> better belongs in the -devel e-mail list.  If so, I apologize, and
> somebody please let me know and I can ask it again over there, but my
> best guess was to ask it here.
> 
> I am a long-time user of GnuCash for business purposes, since the 2.2
> versions.  I just upgraded to 2.6.0 as soon as it was released.
>  Overall I am liking the new business features in concept, especially
> things like credit notes, and explicitly marking payments as applying
> to multiple specific invoices.  Unfortunately some of what I'm about
> to mention is probably feedback I should gave given during the "beta"
> testing phase (2.5 releases), but, since using GnuCash is critical
> for my business, I didn't want to risk data corruption, so I waited
> until 2.6 to even try it.
> 
That's fair enough. Let's work from where we are now.

> One thing that I think is unsatisfactory, is the way the Accounts
> Receivable works now.  Probably because of the new support for credit
> notes and the new explicit multiple-invoice payment feature I like,
> EVERY posted payment now incurs a "Lot Link" transaction in the
> Accounts Receivable register.  The problem with this is several fold:
> 
> 1) It clutters the Accounts Receivable register.  Rather than just two
> items per invoice (the invoice itself and the payment), there are now
> 4 showing, since the "lot link" takes up 2 lines on the screen,...
> and even worse, the lot links are not visibly associated with any
> payment, except by date, so it sometimes takes extra thought and
> guesswork to figure out what they belong to if this ever becomes
> necessary.  If they had a reference number of the invoice, or
> check/payment number, that they were associated with, at least it
> would be definitively clear which invoice or check they belonged to.
The Accounts Receivable register was never meant for direct interaction. So the idea that the 
additional transactions would "clutter up" this register was never considered and probably won't 
be in the future either.

> 2) The only association of a "Lot Link" transaction to the actual
> invoice and payment seems to be the date, BUT, if I enter a payment
> with the wrong date, then the "Lot Link" entries are given the date I
> mistakenly gave to the payment.  This means if I change the date on
> the payment, but not on the Lot Link entries, then the Lot Link
> entries are now in a random place in the timeline, and the only way
> to track them down is by the transaction amount, assuming that even
> matches.
Actually as the transaction name suggests the association between the invoice and the 
payment is a lot, not a date. So if you want to know which invoice is paid by which payments 
you can use the lot viewer which you find under "Actions->View Lots..."
I'll admit the interface probably can use some improvements though.

> 3) Deleting payments no longer works (at least, not easily).
>  Sometimes I make a mistake when entering a payment.  While I can
> imagine a dialog-based user interface to take care of this issue,
> none exists in GnuCash, so my old solution was to simply find the
> errant payment in the Accounts Receivable register, or in the asset
> account that the payment was transferred to, and delete it.  Now, I
> have to not only delete the payment, but the lot link transaction.
>  If I don't delete the lot link transaction, then the invoice is
> still marked as paid, which is WRONG, since the payment no longer
> exists in Accounts Receivable.  If, on the other hand, I delete the
> lot link transaction only, and not the actual payment, then it is no
> longer marked as paid, which is also wrong, since the payment is
> still listed and the accounts receivable would still reconcile for
> that customer.
This is clearly a bug indeed. If a payment is deleted, the invoice should no longer be marked as 
paid.

Until a fix has been released you may be able to avoid this by not deleting the payment, but 
instead modify it to the correct state. Granted that is not possible for all types of corrections.

> 4) Un-posting and re-posting invoices no longer works,
> in any way.  If I process payment for an invoice, then later need to
> modify the invoice, to add to it, for example (which would render it
> only partially paid, with an amount due), or even to edit details
> such as the account a line item was associated with, then re-post the
> invoice, the older versions of GnuCash would automatically
> re-associate the payment with the invoice, and it would automatically
> be marked as paid (or partially paid, depending on the
> circumstances).  In 2.6.0, this no longer works.  The Lot Link
> transaction goes away when the invoice is un-posted.
This is deliberate.

The code in 2.4 assumes that when you unpost an invoice you will eventually repost it again 
with minor changes (a different date, amounts changed,...). But it couldn't cope properly with 
other use cases like
- discard the invoice and recycle it for another customer
- when the total invoice amount decreased to be less than the already applied payment, this 
could mess up the accounts receivable register
- if the payment was already reconciled unposting could mess up reconciliation
- you could decide to post to another account, in which case the payment becomes invalid for 
that invoice.
So there were lots of corner cases that could cause trouble when the unposted invoice 
remained linked to the payment.

In 2.6 the underlying idea is that gnucash can't know what you will do with the invoice after you 
have unposted it. On the other hand your payments may have been reconciled or at least 
explicitly entered. So when an invoice is unposted the only sensible thing to do is to drop the 
link between the invoice and the payment and keep the payment around.

>  There is an
> "Assign As Payment" menu item for each transaction, but I've never
> successfully made this work yet for any purpose.  In this
> circumstance, it brings up an empty dialog box with no invoices
> available to be paid, despite the fact that the invoice is NOT marked
> as paid anymore.
That's probably a bug as well. I will check that later.

>  The normal/new "process payment" dialog box shows
> the previous payment available as a "pre-payment", and shows the
> invoice needing to be paid, but even trying to enter a $0.00
> psuedo-payment to associate the two fails, because a payment of $0.00
> is not accepted.
Hmm, I think that was supposed to work... That may have broken again then at some point. 
Should be fixed.

>  I have to assume that the "pre-payment"
> functionality of 2.4 and earlier GnuCash is completely broken now?
>  The only solution I can find is to write the payment details on a
> scrap of paper, delete it, and re-enter it after the invoice is
> re-posted.

> 5) Clearly these lot links are still optional internally,
> because all my old invoices before the 2.6 upgrade are still marked
> as paid, correctly, without them.  So I have old data that is not
> cluttered, and new data that is cluttered, but no way to enter data


More information about the gnucash-user mailing list