Support "white space" in renaming rule argument

photojon

I have several transactions from Big Box stores that when downloaded contain the store's number, city etc. I would like a renaming rule to just have the store name. For example "The Home Depot #20016 Santa Clara" I would like to rename to just "The Home Depot". Sadly, when I try to add the phrase "The Home Depot" in renaming rules under "If statement name contains", Quicken Classic for Mac currently breakes it into three words "The" "Home" and "Depot". In talking for over an hour with your tech support people, they confirm this is a boolean OR operator across these three words. It would be nice if you would include a radio button with the a choice "must contain all words" or "may contain any words" so that the user can decide if its a boolean OR or AND operation. Current behavior is as shown in the attached image and it broken. Thank you for considering improving the usability.

jacobs

Your description is accurate; Quicken uses only individual words as search terms in a local renaming rule. My question is: in what what does this not work for you. If you have "the" "home" "depot" in the renaming rule, that should work exactly the same as if you could specify a text string like "the home depot".

The only cases I'm aware of where this really fails is if the financial institution omits and delimeters (spaces, punctuation, symbols) between words. So if the dowloaded payee was "TheHomeDepot#1234" and "TheHomeDepot#9876", you couldn't create one rule to rename both into "The Home Depot".

If I remember correctly, the former Quicken Mac product manager explained back when they first implemented Renaming Rules that this approach had something to do with needing to work like Quicken Windows because both must use the =same approach for Quicken Cloud (mobile and web interface). I don't know whether or not this can be changed in Quicken Mac alone, or requires coordinated changes across their products.

photojon

Jacobs, thank you for your response. As it was explained to me by a level 2 tech today at Quicken, the words are a "boolean OR", meaning if I have a downloaded payee with the word "The" in the title, it will be renamed to "The Home Depot". If I had a payee named "Home Town Buffet", it would be renamed to "The Home Depot" because of the word "Home". If I had a payee named "Office Depot", the fact that it had the word "Depot" in it, it too would be renamed "The Home Depot". I would have no objection if it behaved as a boolean AND, but the level 2 tech assured me that it did not work that way, and that indeed I would experience the behavior I outlined above. Thoughts? Thanks again for weighing in.

Jim_Harman

Here is an example of a QWin renaming rule

This rule certainly does not rename all downloaded Payees that contain "Restaurant" to Bonda Restaurant; the downloaded Payee must have both words. It is an AND, not an OR. If you wanted to make it an OR on the two words, you could make two Payee contains lines, one for Bonda and one for Restaurant.

According to the Help, in order to match, they must be separate words and in the same order as in the rule, so it would not match BondaRestaurant or Restaurant Bonda. The Help implies that it would also match Bonda Italian Restaurant, but I have not encountered that situation.

jacobs

@photojon It's definitely an "AND", not an "OR". As the dialog box says, "matches when all tags are in the same order". The Support representative either confused what AND and OR mean, or just gave you incorrect information.

The Help implies that it would also match Bonda Italian Restaurant, but I have not encountered that situation.

I just confirmed this in Quicken Mac. If you create a rule for Renaming "The" "Depot" to "Home Depot", then a downloaded Payee of "The Home Depot #1234" will trigger the rule and rename the Payee to "Home Depot".

photojon

Thanks Jim and Jacob. Jim, i believe your image you shared is from the windows version and I agree with you that is how it worked in windows (when I was on that platform). Jacob, thank you for verifying that it is an AND. I was surprised when during a screen share with the support person, they called out a different behavior that what you have verified. (In your example I assume you meant to include "Home" in the renaming rule as well.) I will give it a try and wait for my next download that contains a multi word payee. Thanks again to both of you.

jacobs

In your example I assume you meant to include "Home" in the renaming rule as well.

Actually, no. The point I was making is that the Renaming Rule will work as long as all the words in the rule are in the downloaded Payee name and appear in that order.

Os if the downloaded payee name is “The Home Depot #1234 Anytown” the any of the following sets of words in the Renaming Rule would work:

• ”The” “Home” “Depot”
• “Home” “Depot”
• “The” “Depot”
• “Depot” “Anytown”

Jim_Harman

Of course if you just used "The" and "Depot", the rule would also match "The Depot Restaurant" and "The Train Depot" which you probably don't want.

Yes, my example was from Windows. I showed it because apparently the agent you spoke to said the rules in QMac had to work the same as QWin and I wanted to describe how QWin works.

Also note that the Payee after renaming can be whatever you want. It does not need to contain any of the words in the downloaded Payee.

Your original request would be nice enhancement. This would be to allow you to use a string with embedded spaces, so that a match would require all the words in the correct order with nothing else between them. This would typically be entered with quotes, so "Home Depot" (with the quotes) would not match Home Run Depot, for example.

photojon

Thanks again Jim and Jacob. I will give it a try. Both your descriptions make a ton of sense.

jacobs

Of course if you just used "The" and "Depot", the rule would also match "The Depot Restaurant" and "The Train Depot" which you probably don't want.

@Jim_Harman Yes, I was just using that as an example of word order; I agree that the specific words you’d use in a Renaming Rule need to consider whether they will be unique enough to not generate unintended matches.