Paying Invoices

[Geert Janssens]

On Wednesday 18 February 2015 14:24:27 R. Victor Klassen wrote:
> We have a “customer” [actually a Farmers’ Market that we attend
> weekly], which buys from us some collection of items every week.
> 
> Normal procedure is to put together an invoice (for internal record
> keeping only), and then once the total amounts the cash received for
> that week, post it and mark it as paid.
> 
> So far so good.
> 
> Not entirely uncommon is the case where some of the amounts on some
> invoices get reclassified later to different accounts - because
> GNUcash is way less fascist about it than Quickbooks, I can sell
> widgets and account for them under foo today, and bar tomorrow, and
> then only realize next month that they really should all be accounted
> under bar.  So I go back and fix it.  Or I realize that whatnots
> should have been classed as taxable (tax included in the price, so
> the customer pays the same amount), but I neglected to, so I need to
> go back and fix that.  All of which means unposting a paid invoice
> and then reposting.   Or I fell behind and got an invoice entered at
> the wrong date, and it’s really easier to read reports and the like
> if the dates are right, so I just have to unpost and repost the
> invoice to the right date.   I’ve found that when this happens, the
> link connecting the payment to the invoice is still there, but wrong,
> so I need to go to A/R, and delete the link, and then I can
> re-associate the payment using the “Assign as payment” feature.
> 
> So far so more-or-less good.   It would be nice if this just “worked”,
> without the link breaking, but that’s a story for another time.
> 
> What’s been happening lately is when going to pay the invoice, we’re
> presented with a list of “prepaid” amounts, and no unpaid invoices
> (including, most importantly, the one just created).
> 
> This includes a $22 prepaid amount from 2014, a matched pair from 2015
> (meaning they are both listed as pre-payments, even though one is a
> debit and the other a credit), and a couple of others.
> 
> So not so good.
> 
> In an attempt to debug the issue, I’ve run a report on Accounts
> Receivable for this customer, and over the 2014 time period,
> everything balances.  So the $22 is not something an accounts
> receivable report will find.
> 
> Similarly, a report on 2015 shows no imbalances from periods before
> this symptom appeared.
> 
> At this point, it seems the only way to pay an invoice as paid, is to
> go through the motions, and then type the amount without selecting an
> invoice (as none appear), and the corresponding payment account. 
> This only increases the number of prepaid  entries in the invoice
> payment window.
> 
> Alternatively I can select some prepayments, and still manually enter
> the amount paid, and any prepayments on the side where invoices
> normally appear will go away, if the amount paid is large enough. 
> But that seems wrong as it is associating payments with something
> other than the invoices to which they belong.
> 
> I’ve tried looking for links to matching amounts, but that has led
> nowhere.   As far as I can tell, it is possible for there to be
> payments/transactions findable from the “pay invoice” sub-window,
> that aren’t findable by other means.   Perhaps I’ve missed some
> means.
> 
> I’m thinking this is some kind of bug, but I’ve no idea how to isolate
> it to create a simple test case.
> 
> Thoughts?  Suggestions?
Hi Victor,

You seem be have gotten caught up in lot-link proliferation. All versions of gnucash between 
2.6.0 and 2.6.4 were very liberal in creating lot links for business transactions and you could 
eventually end up with lots of pre-payments in different directions.

The best solution IMO is to
1. upgrade to version 2.6.5
2. select your AR account in the account hierarchy (but don't open its register - in fact close the 
register if it's still open)
3. run "check&repair selected account"

GnuCash 2.6.5 has changed its lot link policy again and is now very conservative about 
creating one. It will do so only when absolutely necessary (which is when you offset an invoice 
with a credit note).

The check & repair step will go through your existing invoices and payments and will attempt 
to convert as much of the existing lot links as possible into straight invoice/payment links.

I am not sure if check & repair will manage to fix *all* left-over prepayments. Let me know how 
it goes as perhaps it might need some more tuning for the next gnucash release.

Geert