Solved: Receivables Aging Misreporting

[Pablo Francesca]

I had kept a backup copy, so  I wasn't worried about messing up anything.

In summary, (while I dont understand the math behind it, nor the reason it was caused), your advice did resolve the issue.  However, it was not necessary to delete all the payments.  All I needed to do was delete any auto-pay forward that did not correspond with an actual payment. There were three, the two we discussed and another one more recently.

For anyone who can benefit from this discussion in the future, be aware that the amount of the discrepancy between the two reports will not necessarily be related to the auto-pay forwards that you delete. For example, I initially started with a discrepancy of +125. I deleted an auto-pay forward for 850 with no effect on this amount.  I deleted an auto-pay forward of 750 and the discrepancy changed to -625.  Finally, I deleted an auto-pay forward for 500 and the two reports matched.

--- On Thu, 3/18/10, Derek Atkins <warlord at MIT.EDU> wrote:

From: Derek Atkins <warlord at MIT.EDU>
Subject: Re: Receivables Aging Misreporting
To: "Pablo Francesca" <rshgeneral at yahoo.com>
Cc: "trythis" <grahamlane at gmail.com>, gnucash-user at gnucash.org
Date: Thursday, March 18, 2010, 1:14 PM

Hi,

Pablo Francesca <rshgeneral at yahoo.com> writes:

> I've circled what I considered a lot in the a/r screenshot file.  I quoted the
> term lot to indicate that i was using the term according to my understanding  
> of the bug report.  I used the term transaction to encompass the debit/credit 
> entries that accompany the creation of an invoice.                            

What you've circles are not lots.  What you've circled are the
Auto-Payment-Forward transactions that I've talked about.  See the
Action field?

Basically, these transactions get created when you have an
over-payment.  When you post an invoice (or a payment) such that the end
result is an overpayment then GnuCash will use the auto-forward
transaction to start a new lot for the next invoice.

If you get one of these created and then later unpost the invoice you
could certainly leave the A/R account in a strange state!

> The customer_report file shows a zero balance (not seen on screenshot).  None 
> of the entries created in A/R account were created w/o using normal create    
> invoice dialog or post payment dialog. Again, I've never created an invoice   
> for this customer (active or otherwise) for $750 or $850.  I've also never    
> taken a payment for this customer for those amounts.                          

Right.  Those aren't invoices.  Those are over-payments.  What it means
is that on April 8, 2009 you had posted an invoice or a payment that
caused an overpayment of 850 for Customer 1 (probably because they had
already given you a deposit of 950 and you posted a $100 invoice?).
Then on April 15th the same thing, you posted an invoice of $100
(invoice 002131) which reduced the overpayment from 850 to 750...  So
GnuCash was creating the auto payment forward for the NEXT invoice to
come in....

> Let me know if you need more screen shots of A/R entries.                     

I don't think I need more pictures...  And if you deleted these
auto-payment transactions then you probably messed up the internal lot
calculations of which invoices are actually paid.

What I would recommend is that you go into A/R, record all the ACTUAL
payments for this customer, then delete all payment and
auto-payment-forward transactions, and then Process Payment for all the
actual payments.  That should clear it up.  But make sure you delete the
auto-payment-forward transactions for this customer (and ONLY for this
customer)!

-derek
-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available