Not exactly an idea but rather point out a flaw in the Itemized Payees report

Sigfrido Garcia

Currently this report fails to include any transaction with "split" items, thus rendering useless since it will not be accurate.

I actually managed to show this problem to one of the support folks last week as I shared my screen with him and we went through the process of configuring the proper options to compare the results with an Itemized Tags report where the results should have been the same.

Jim_Harman

What I see with Premier R27.28 is that if the transaction is split and the first category of the split is included in the report's category selections, the full amount of the transaction is included in the Itemized Payees report.

If the first category of the split is not included in the category selections, the entire transaction is excluded from the report.

Does this match what you are seeing?

It seems to me that this is an error. I would expect that if any of the categories of the split are included in the report's category selection, the total of the selected categories should show in the report.

For example if I have ATM withdrawals and I have split the transactions between my Cash category and Bank Fees with Bank fees as the second category in the split, if I just have the Cash category selected for the report, it should show the cash amount, not the total transaction amount. If I just have the Bank fees category selected, it should show the bank fees, not nothing.

[edit] I can see however that this might cause confusion if you "drill down" in the report to see the individual transactions. The transactions should probably show all the split categories, not just the ones that are selected in the main report. This would make This would make the total of the transactions not equal the total in the main report.

Sigfrido Garcia

While configuring the Itemized Payees Report I am selecting all accounts, all categories and filtering by one specific tag, yet the report that is displayed will only include those transactions where there is but one category or in other words no splits.

Jim_Harman

Is the selected tag on the first split item or one of the others? My observation with the Categories is that when filtering it only looks at the first item.

Sigfrido Garcia

When I run the "Itemized tags" report while filtering on the one particular tag that I am interested in, the report displayed is correct.

When I then run the "Itemized Payees" report while filtering on the one particular tag that I am interested in, the report displayed does not match the "Itemized Tags" report at all.

Having developed software myself for many years, I cannot quite understand why this has taken so long to fix as from my standpoint it should be a simple modification to the existing query to make sure all split items are included in the requested report.

Chris_QPW

Sigfrido Garcia said:

Having developed software myself for many years, I cannot quite understand why this has taken so long to fix as from my standpoint it should be a simple modification to the existing query to make sure all split items are included in the requested report.

Here are the reasons in my opinion.

1. Before a problem can be fixed the develop team has to know about it.  From your post "best case" they would have known about it last week after you reported it.  I said "best case" because sometimes problems don't get submitted as problems for whatever reason.
2. The development team has to decide that they want someone to work on this problem.  It is certainly known that they have tons of requests for features and problems and as such have to give things a priority, and such a problem might get a low one given that it doesn't crash Quicken or affect a lot of people.
3. The problem has to be reproducible so that they can see what the problem is.
4. The developer has to fix the problem.
5. The problem has to be included in the next release build.
6. The development team has to decide that it is either "time" for a release (which they are shooting for once a month) or there is a fix in it so important that they will release it early.
7. A release has to be sent first to a "limited" number of users, and when it deemed "OK" released to the general population.

Even if your problem made it through 1 to 5, Quicken Inc doesn't release a new just for a little fix like this.

Most people concentrate on #4 and forget that all the rest has to happen too.

UKR

As of today, a new patch, R 27.42, will be made available to Q 2020 US users. It is reported to fix some of the report issues reported with R 27.24 and 27.28

If you can't wait for it to arrive in the regular patch process in the next few days and would like to try it immediately, download and install the patch file from

https://www.quicken.com/support/update-and-mondo-patch-20182019-release-quicken-windows-subscription-product

GeoffG

Chris_QPW said:

Here are the reasons in my opinion.

1. 
   
2. 
   
3. 
   
4. The developer has to fix the problem.

You overlooked what needs to happen after 4.

4b. QA test the developer code.

More stringent QA testing would reduce the Release fixes.

Chris_QPW

GeoffG said:

You overlooked what needs to happen after 4.

4b. QA test the developer code.

More stringent QA testing would reduce the Release fixes.

Yep!! Missed that one.  But note that even though I missed it, doesn't mean that they aren't doing it.  

Sigfrido Garcia

Interesting response Chris_QPW.

As a matter of fact, I had included in one of my original posts the fact that while sharing my screen with one of the support guys for a different issue I managed to demonstrate in detail the flawed report. And I do understand that product management needs to evaluate and weigh out what merits to be fixed or not. but this should have never made it out of QA.

Chris_QPW

Sigfrido Garcia said:

but this should have never made it out of QA.

Yeah, well that is a completely different problem.