internal link between invoice and payment lots

[Geert Janssens]

On Friday 17 January 2014 17:03:25 David Beattie wrote:
> Edward,
> 
> I had the same complaint/observation and I wrote a lengthy message
> about it a few days ago.  The developer who implemented the upgrades
> to the business features and chose the implementation responded to me
> (and the rest of the list) and we exchanged some additional
> informative discussion on the matter.  You may see the messages we
> wrote back and forth here:
> 
> http://lists.gnucash.org/pipermail/gnucash-user/2014-January/thread.ht
> ml
> http://lists.gnucash.org/pipermail/gnucash-user/2014-January/052226.h
> tml
> 
> In summary, I agree with you and I have proposed various ways to
> simplify the user experience, including but not limited to, hiding
> the "lot link" transactions that we're seeing now (after some needed
> bug fixes), OR changing the implementation in such a way that they
> are not necessary.  But for now, we know that the developer, Geert
> Janssens deliberately chose this as his new implementation in order
> to add two big features (credit notes and explicit assignment of
> payments to invoices), that are new and improved in GnuCash 2.6,
> which were missing from GnuCash 2.4.  Unfortunately, the new rows are
> necessary in this new version in order to link payments with
> invoices, and they can't be deleted or hidden, unless you go back to
> 2.4, or your invoices will no longer show as paid.
> 
> Geert already said he plans to review the ideas I've presented when he
> has some time; in the mean time, I just thought I'd let you know that
> you're not alone in finding the way it is to be non-optimal and that
> I'm also hoping for some improvement in one direction or another. 
> And for now, knowing that there's only one developer working on this,
> and volunteering his time and efforts, we have to be patient and use
> it the way it is, unless we want to go back to 2.4 and lose the new
> features.  I will probably stick with 2.6 myself.  I'm thankful the
> new features are at least functional and stable, even if they are
> messy and harder than they should be to use.  If you have anything to
> add to the discussion, I'm sure it will be helpful.
> 
> Best regards,
> 
> David Beattie

Thanks for the nice summary David. It says it all.

And yes, when I get some time available again I will revisit this part to see how the situation 
can be improved.

Geert