"Internal Lot Links" mess in Accounts Receivable

[Geert Janssens]

On Tuesday 16 September 2014 20:36:32 Geert Janssens wrote:
> 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.