This has been reported previously

https://lists.gnucash.org/pipermail/gnucash-user/2019-September/086957.html

The only way I've reproduced this is by misassociating an existing transaction.

https://lists.gnucash.org/pipermail/gnucash-user/2019-September/087058.html

The aging report hasn't significantly changed for a while.

Well, cut me down and call me stumpy, Mr Lam, you've hit the nail on the head. Exceedingly well diagnosed! 

When processing payments, where only one invoice was outstanding, I assumed it would pick that invoice. Instead the payment is treated as a pre-payment instead of being associated with an invoice. 

Happily it is easy to remedy - go to the Accounts Receivable account, right click on the payment record -> edit payment... -> in the Documents pane, click on the invoice -> OK. The Receivables Aging report then comes out correctly. 

Many thanks for your assistance.

Resolved by editing payment and associating an invoice with it.

You're welcome.

Perhaps there's still a usability bug -- perhaps UI shouldn't allow process payment without invoice, or without customer. Did the payment get assigned to a customer? If so the next customer invoice and payment could link them together.

What should the report show?

(In reply to Christopher Lam from comment #4)
>
> Perhaps there's still a usability bug -- perhaps UI shouldn't allow process
> payment without invoice, or without customer. Did the payment get assigned
> to a customer? If so the next customer invoice and payment could link them
> together.

Every payment should have a customer (owner) associated with it.  If it does not, that's definitely a bug.  There is no requirement that a payment be associated with an invoice -- it could be a pre-payment.  But payment w/o customer/owner.... definitely an issue!  Not sure how that happened, that should not be allowed.

Ok tried on maint. No manual XML editing involved! Couple buggy cases as follows:

1) Customer currency != bank/APAR currency
   - create manual transfer bank <-> APAR
   - associate payment without document
   - success! (bug)
   -> what should be done about this?

2) Customer currency = bank&APAR currency
   - create manual transfer bank <-> APAR
   - associate payment without document
   - success! (not bug)
   - run aging report on APAR account
   - shows bad-url line as above
   -> what should be done about this?

(In reply to Christopher Lam from comment #6)
> Ok tried on maint. No manual XML editing involved! Couple buggy cases as
> follows:
> 
> 1) Customer currency != bank/APAR currency
>    - create manual transfer bank <-> APAR
>    - associate payment without document
>    - success! (bug)
>    -> what should be done about this?
> 
What exactly is the bug here according to you ?

> 2) Customer currency = bank&APAR currency
>    - create manual transfer bank <-> APAR
>    - associate payment without document
>    - success! (not bug)
>    - run aging report on APAR account
>    - shows bad-url line as above
>    -> what should be done about this?

IMO this is a bug in the report. It's not properly detecting the customer associated with the payment. This info is stored differently when a payment is assigned to an invoice or not. Perhaps the report doesn't cope with this (haven't looked at the actual code).

I'm reopening as it does look like there is a bug here.

(In reply to Geert Janssens from comment #7)
> (In reply to Christopher Lam from comment #6)
> > 1) Customer currency != bank/APAR currency
> >    - create manual transfer bank <-> APAR
> >    - associate payment without document
> >    - success! (bug)
> >    -> what should be done about this?
> > 
> What exactly is the bug here according to you ?

Either a warning that the transaction currency does not match the customer, or disallow customer from the 'partner' selection.

In any case, after assigning transaction to (different currency) customer, (a) editing the payment info pops up a 'there are no valid "post to" accounts' meaning there are no APAR post-to accounts which match the customer currency. (b) the payment is now damaged; while the txn is still balanced, on the APAR split, the split-amount is now zero.

Some scrubbing is called for :)

> > 2) Customer currency = bank&APAR currency
> >    - create manual transfer bank <-> APAR
> >    - associate payment without document
> >    - success! (not bug)
> >    - run aging report on APAR account
> >    - shows bad-url line as above
> >    -> what should be done about this?
> 
> IMO this is a bug in the report. It's not properly detecting the customer
> associated with the payment. This info is stored differently when a payment
> is assigned to an invoice or not. Perhaps the report doesn't cope with this
> (haven't looked at the actual code).

Agree report can't cope.

> I'm reopening as it does look like there is a bug here.

Yes, the payment was assigned to the customer (as a pre-payment), but not to the invoice unless clicked. Clicking the customer line's total creates a Customer Report showing zero dollars owed by this customer. So given this recognises zero owing, I suppose the Receivables Aging report should use the same logic and also report zero owing, rather than have a phantom customer whose total has a link to "does not compute".

I imagine paying invoices is a vastly more common than making prepayments, so if the payment sum matches the sole invoice outstanding, "process payment" should automatically select the invoice. And if it doesn't match, make it clear that this is being processed as a pre-payment (add a highlighted prepayment line to the list of invoices?) so the user has a chance to catch the error and select an invoice.

Thanks again

Phil Diacono

The current aging reports are far too old and unmaintained to fix. May I suggest the next gen aging report, just merged into maint in the experimental reports menu, will fix this issue.

Payments (with owner, but no invoice) will be correctly recognised and tallied into their own column, and added together with the other customer columns.

Created attachment 373438 [details]
A usability patch - warn if assigning payment without document

How's this for a usability fix?

Note the payment mechanism promises (via tooltips) to auto-assign to invoices but I don't quite know how it works. Hence the warning to doublecheck that empty-document-selection is really what user wants.

--- a/gnucash/gnome/dialog-payment.c
+++ b/gnucash/gnome/dialog-payment.c
@@ -937,6 +937,11 @@ gnc_payment_ok_cb (G_GNUC_UNUSED GtkWidget *widget, gpointer data)
         selection = gtk_tree_view_get_selection (GTK_TREE_VIEW(pw->docs_list_tree_view));
         gtk_tree_selection_selected_foreach (selection, get_selected_lots, &selected_lots);
 
+        if ((gtk_tree_selection_count_selected_rows (selection) == 0) &&
+            !(gnc_verify_dialog ( GTK_WINDOW(pw->dialog), FALSE,
+                                  _("No documents were selected to assign this payment to. This may create an unattachmed payment. Do you wish to continue?"))))
+            return;
+
         /* When the payment amount is 0, the selected documents cancel each other out
          * so no money is actually transferred.
          * For non-zero payments money will be transferred between the post account

Minor typo: unattachmed -> unattached

Sorry, rude of me. Thanks, that's a great help, should do the trick. Much appreciated.

Best regards

Phil Diacono

Thanks for typo fix. This warning is merged into maint and can be refreshed from github. The new aging-report is in beta in the Experimental submenu. If you're brave try compiling from maint and let me know!

I can confirm that as of v3.8 on MacOS Catalina, the experimental report works as expected. (and I like the larger 'total' line, and the 'pre-payments' column, thanks!)

The old report, apparently, has not been updated and still shows the phantom customer. Oddly, I've gone through all of my pre-payments and re-assigned them just to make sure. (to customers, not documents, as they are still outstanding pre-payments) Some pre-payments show properly in this old report belonging to customers, while others appear for a phantom customer still. Also, the old report wasn't even calculating 1-30 days properly. It showed zero for a customer that has outstanding recent invoices. The experimental report calculates this correctly.

Thanks for the fix! Now, if only the 'experimental' aging report would link to 'experimental customer/vendor reports'...  but all in due time, I suppose.

(In reply to Adrien from comment #15)
> I can confirm that as of v3.8 on MacOS Catalina, the experimental report
> works as expected. (and I like the larger 'total' line, and the
> 'pre-payments' column, thanks!)
> 
> The old report, apparently, has not been updated and still shows the phantom
> customer. Oddly, I've gone through all of my pre-payments and re-assigned
> them just to make sure. (to customers, not documents, as they are still
> outstanding pre-payments) Some pre-payments show properly in this old report
> belonging to customers, while others appear for a phantom customer still.
> Also, the old report wasn't even calculating 1-30 days properly. It showed
> zero for a customer that has outstanding recent invoices. The experimental
> report calculates this correctly.
> 

As Christopher hints in comment 10 this will not be fixed in the old reports. The goal is to replace them with the newer versions for gnucash 4.0. As you can see they are shaping up quite nicely for that.

> Thanks for the fix! Now, if only the 'experimental' aging report would link
> to 'experimental customer/vendor reports'...  but all in due time, I suppose.

I think we could implement this now already. As far as I can see this is just a matter of setting a different report guid to open. The important bit will be to remember to reset the GUIDs when promoting the reports to the main menus.

@chris can you look into this ?

(In reply to Geert Janssens from comment #16)
> > Thanks for the fix! Now, if only the 'experimental' aging report would link
> > to 'experimental customer/vendor reports'...  but all in due time, I suppose.
> 
> I think we could implement this now already. As far as I can see this is
> just a matter of setting a different report guid to open. The important bit
> will be to remember to reset the GUIDs when promoting the reports to the
> main menus.
> 
> @chris can you look into this ?

The new aging/owner reports are meant to be a clean upgrade with mostly compatible options: useful options are reused (using my interpretation of the option) whereas useless options (eg. sorting, show multicurrency eg) are ignored completely.

So when everyone's happy we'll do a guid dance: new reports' guids have '-new' removed; old reports guids have '-old' added. I'd keep the old reports as "Legacy" options within Experimental submenu, just to keep the whiners and luddites happy.

(In reply to Christopher Lam from comment #17)
On the contrary, I don't see sorting by as a useless option at all. There is definitely a use case for sorting AR/AP by amount in the Aging reports.

I've also seen several list threads about multi-currency AR/AP, so I could imagine quite a bit of consternation if the aging reports dropped that option. The reports would only show one currency, not the currency for each customer/vendor.

I can see dropping the selection of the payable account as right now, the business features only see the default one, though you can have many. (unless I've misunderstood how the business features work) If you can have multiple AP accounts working with the business features correctly, then I can also see how that option might be useful for some cases.

Sure, the old reports might hang around for those folks, but as noted, there are no plans to fix those reports where they are broken, so that really isn't any help or consolation.

(In reply to Adrien from comment #18)

Erm. No. I'm not applying effort unless there's a real need.

If you were paying attention you'd find that the new reports handle a lot of the old options much more intelligently than before. I'll wait until someone actually makes the effort of writing a bug report.

I'm much more interested in people actually beta testing more important changes (e.g. budget totals) rather than pandering to endless requests. Sorry.

Ok. Sorry. Apologies Adrien. This is from me, and I take it back before anyone scolds me.

I realise the content of your post is primarily positive and I will explain. I am aware documentation is severely lacking in many reports, and I'm not the best at writing them.

APAR account is not needed anymore because new report will scan *all* APAR accounts for the particular owner transactions, and will report all of them. It is easy to choose the wrong APAR account when there are many of them, and the report scanning all of them is much easier for newbies to handle than having an APAR account chosen which doesn't have any owner splits.

Currency option is not needed anymore because the currency is now derived from the APAR account currency.

Sorting options are not currently implemented because they'd add a layer of complexity that I'm not sure is really needed yet. I'd prefer await any bug report.

No worries. Thank you for the explanations. I seem to recall now a discussion about scanning all accounts and the currency solution.

As for sorting, that can certainly be a wait and see approach.

And please accept my apologies. I certainly didn't mean to imply you needed to maintain technical debt. (which would moot the point of writing a replacement report of course)

Thank you for your extensive work in this area. Reports have long needed attention and I am grateful for what you've accomplished thus far.

The replacement request is mine really, not Chris'.

Regardless I do prefer to actually replace the reports if at all possible for 4.0. Exactly to reduce technical debt.

It's worth gathering use cases that were supported by the old reports and not by the new ones and evaluate the cost of supporting them in the new reports. If the evaluation is positive we should implement it before replacement. Otherwise we choose not to support it any more.

Keeping duplicate reports however is a useless maintenance burden.

So, as for the sorting. Adrien do you have a valid use case for it yourself ? To me personally an aging report's primary concern is the historical order of events. For more flexibility, the sorting and filtering capabilities of the registers are available.

(In reply to Christopher Lam from comment #17)
> The new aging/owner reports are meant to be a clean upgrade with mostly
> compatible options: useful options are reused (using my interpretation of
> the option) whereas useless options (eg. sorting, show multicurrency eg) are
> ignored completely.
> 
Ok

> So when everyone's happy we'll do a guid dance: new reports' guids have
> '-new' removed; old reports guids have '-old' added. I'd keep the old
> reports as "Legacy" options within Experimental submenu, just to keep the
> whiners and luddites happy.

As you probably have understood by now, I strongly prefer not to keep old reports around for reasons explained earlier.

Also no guid dance on maint (which I guess you understood by now as well :)

But that was also not what I meant. Unfortunately when looking at the code, what I meant is not possible :(
It would require registering separate url handlers and generate separate urls only for these experimental reports. That would be overkill.

So, sorry Adrien, we do have to wait until 4.0 indeed for these links to open the newer reports.

(In reply to Geert from comment #22)
I personally don't have a current case for sorting by amounts. But when I was assisting a business with bookkeeping who had many, many customers and vendors, it was indispensable. Though it would be more useful if the sorting wasn't just on total owed but by aging as well. This helps with prioritizing collection efforts as well as managing vendor payments. While a small collection of customers/vendors fits on one screen and is manageable at a glance, books with more activity and entities will invariably want to sort by amount.

I think this is a case for polling the list and seeing what the demand is for the feature. If it is in demand, but too complicated, maybe it can be held off as a future enhancement rather than hold up the report for 4.0. (and you might see more feedback once it is removed and people notice than the initial list message)

As for sorting and filtering in registers, that doesn't provide much in the way of aging info. (this bug, and myself, are concerned with the aging reports. Owner reports are a different story.)

Finally, I understand the issue with linking these reports early. I suspected it wouldn't be possible. That was more of wishful thinking. Thanks for considering it though.

I see what you mean. I occasionally get a listing from a vendor that lists all bills due. This listing differs from the our aging reports in several ways:

1. it only lists bills due
2. It groups on bill rather than a single long list
3. Aside of the usual bill details (date, due date, total,...) for each bill it presents
* a list of payments already made
* the remaining amount due (which is invoice total - payment amounts)
* the number of days the bill is overdue (can be "not due yet")

I think while related to aging it really is a different report (which would also be a very valuable addition to gnucash). I'm not sure what it would be called in English though. "Vendor due"? "Outstanding bills"? "Customer reminders"?

(In reply to Geert Janssens from comment #25)
> I think while related to aging it really is a different report (which would
> also be a very valuable addition to gnucash). I'm not sure what it would be
> called in English though. "Vendor due"? "Outstanding bills"? "Customer
> reminders"?

This would be an addition to new-owner-report to filter e.g. 'show unpaid invoices only' or other filtering options, but this discussion belongs somewhere else.

Meanwhile this bug can probably be confirmed as fixed in 3.8: new 'experimental' aging reports handle unattached payments well nowadays. OP please review and feedback?

(In reply to Adrien from comment #21)
> No worries. Thank you for the explanations. I seem to recall now a
> discussion about scanning all accounts and the currency solution.
> 
> As for sorting, that can certainly be a wait and see approach.

Well, sort-by is reinstated in aging report. Please help debug it thoroughly prior to 3.9. Any issues please file a *new* bug.

(In reply to Christopher Lam from comment #26)
> (In reply to Geert Janssens from comment #25)
> > I think while related to aging it really is a different report (which would
> > also be a very valuable addition to gnucash). I'm not sure what it would be
> > called in English though. "Vendor due"? "Outstanding bills"? "Customer
> > reminders"?
> 
> This would be an addition to new-owner-report to filter e.g. 'show unpaid
> invoices only' or other filtering options, but this discussion belongs
> somewhere else.
> 
> Meanwhile this bug can probably be confirmed as fixed in 3.8: new
> 'experimental' aging reports handle unattached payments well nowadays. OP
> please review and feedback?

Yes, let's close this one. The original bug has been fixed.

(in reply to Christopher from comment #27)

Thank you! I'll test it out best I can.

(in reply to Geert from comment #25)

That would be a nice report to have. (or very useful enhancement to the owner-report as Christopher noted)

But, what I had in mind from comment #24 was being able to sort by total owed across all customers/vendors in the aging report to see "who owes me the most?" or "who do I owe the most to?" to guide prioritizing collections activities or vendor payments. (the sort by aging columns would be an enhancement and isn't currently implemented, I don't think) I'm involved in a list thread about AR right now and the OP mentioned they manage 100+ customers. Sorting at least by total in the Aging Report might be helpful to them. Restoring the existing sorting option should be good for now.

Sorry for the delay in getting back. Thanks, works great. I built 3.8 on Ubuntu 18.04 x64 and tested and all works as described above. "Experimental" Receivable Aging (beta) looks great, eliminates the phantom company and assigns payment as pre-payment where invoice not selected. Again thanks very much, team.