"Internal Lot Links" mess in Accounts Receivable

[Geert Janssens]

Hi David,

As promised I'm coming back to the lot link story.

On Wednesday 15 January 2014 02:45:24 David Beattie wrote:
> 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.
> 
As I have mentioned earlier on the list, the lot links have been reworked for the upcoming 2.6.4 
release. They will only remain for offsetting invoices with credit notes, very similar to what you 
mentioned above.

All other payments are now handled again as in 2.4 with the added flexibility of mixing and 
matching multiple documents with several pre-payments and the actual payment.

I have also added code to clean up the lot links that have been created in the meantime. This 
code can be accessed via Action -> Check & Repair on the respective AP/AR accounts in the 
Account Hierarchy.

<snipped long design discussion>
> 
> I actually have practical suggestions, believe it or not!
> 
Great ! I haven't found time to implement all of this (yet). To make sure your suggestions won't 
get lost I have added them in our bug tracker, unless it was already there.

> 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
> if he needed to, although if so, I wonder if a dialog box confirming
> or ignoring an autocorrect to change the memo field on the payment to
> the new customer name would be helpful.  If the customer is no longer
> referred to in the payment transaction, then a non-optional pop-up to
> choose the customer would be the obvious solution, otherwise it takes
> a while to figure out what went wrong for a new user like me.
> 
This is still a useful suggestion. I found an enhancement request in bugzilla that more or less 
deals with this as well [1].

> Another helpful change to the current "Assign Payment To"... feature
> would be to show any existing payment assignment in the dialog.
>  Currently, the Assign Payment feature can be run twice in a row, and
> the second time you run it, the stuff you've already assigned is not
> there, and there's also no indication that the payment is fully
> assigned already (the amount is still there in full).  I'm scared to
> find out what would happen to the original payment assignment if I
> did in fact try to assign it to another, unpaid invoice, and I don't
> want to corrupt my live data to risk finding out.  But I would
> suggest that populating that dialog with the UNION of the
> currently-assigned invoice splits and the available, unpaid invoice
> amounts, would be more user-friendly than what it currently does.
>  Then if a payment got mis-assigned, the assignment could be edited
> in an obvious way.  Doing the re-assignment could even change the
> amount sent to an invoice that the payment was already partly
> assigned to, in which case, the new amount could be combined in with
> the existing lot link, rather than adding a second split to the same
> invoice in the lot link.  Thus the "assign payment" would essentially
> be an edit button for the lot link, rather than only designed to
> create them.  Also, the "Assign Payment" menu item could be removed
> from Invoice lines (except credit notes) in the register, since it
> doesn't make sense there.  AND, it doesn't make sense to assign the
> payment to itself, so if assigning an unassigned payment, the payment
> itself should be deleted from the assignment dialog (it is visible
> there, currently, listed as a pre-payment).
> 
That would be a nice improvement as well. Created a new enhancement request for it [2].

> Yet more feedback on the "Assign Payment": every time I assign a
> payment, I'm getting an "Imbalance-USD" split, with no value, added
> to the payment transaction.  I can delete it with no negative
> consequences.  This brings to mind the idea of what would happen if a
> payment amount was edited though... I am imagining in the future, an
> option to trigger the Assign Payment dialog box to come up
> automatically if a payment amount is ever edited in the register.
> 
That looks like a bug, and I suspect already reported [3]

> I do think it's a bit naive to expect us, real users of the program,
> to never have to go poking around in the internals of Accounts
> Receivable.  Until lot links are automatically deleted when payments
> are deleted (they obviously should be!), then we'll have to go in
> there to manually delete them, or correct their dates to make sense.
>  And in terms of the actual payments, I should be able to edit them
> either from their asset account, or from the Accounts Receivable
> account, just like any other transaction can be edited from any of
> the accounts its splits belong to.  Most importantly for the new
> features, where else would I go if I wanted to "Assign as Payment"?
> 

You could actually call the "Assign as Payment" from the Asset account on the other end of 
your payment transaction. It was intended to be used that way... :)

> Don't I have to do that from the Accounts Receivable register?  So if
> Lot Links are going to remain as the internal implementation of
> payment assignments, and if they can be fully maintained by the
> Assign as Payment dialog box, then I think there will soon be no
> reason to show them in the register (once the bugs are worked out),
> so why not hide them?  That way when we do have to go into Accounts
> Receivable to re-assign a payment, we won't have to see them, while
> we will, in fact, be editing them behind the scenes.
> 
I'm reluctant to hide them. And with the reworked code I believe there will be even less reason 
to do so. They will be used much more sparingly and when they are used, they actually reveal 
that the and invoice was offset by a credit note.

Best regards,

Geert