nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

maintaining insert order when using multiple tags in one transaction

nc00ks0n

Some transactions are assigned multiple tags in a particular order. For example: X:Y:Z.
After restarting quicken nearly all of these transactions show the same tags but in a different order. For example Z:Y:X.
Those transactions are edited to re-establish the original order but they keep reverting back to the wrong order the next time quicken is started.

Is there a setting that will keep the tags in their original insert order?

Maybe this is a bug that needs fixing because his reordering causes problems when creating reports that are subtotaled by tag as there will be multiple subtotals, one for each ordering of tags.

Find more posts tagged with

Windows

Accepted answers

All comments

Quicken Kristina

Hello @nc00ks0n,

Thank you for reaching out to the Community with this issue. To help troubleshoot, please provide more information. When did you first notice this issue? Do the tags always change to the same order? Is there any pattern to it (such as shifting to alphabetical order)? Does the order change only after you have restarted Quicken, or are there any other behaviors that trigger this behavior?

Do you have cloud sync turned on? You can check this by going to Edit>Preferences>Mobile & Web.

I look forward to your reply!

Chris_QPW

One should be aware of the fact that tags aren’t like categories where there is a parent child relationship.

With categories Dining:Jack is different than Jack:Dining, but for tags this isn’t true. Tag1:Tag2 is exactly the same as Tag2:Tag1.

If you search for the category Dining:Jack you will not get transactions with Dining or Jack. If you search for the tag Tag1 you will get any transaction that has Tag1 on it, including Tag1 or Tag1:Tag2 or Tag1:Tag2:Tag3, …

As such tags have no “order”, and it isn’t a bug not to maintain the order.

Tom Young

There is no setting to control the order to Tags. It has been suggested that "Syncing" may be the culprit, but I'd say that's unproven.

I think the problem is that Tags are not well controlled programmatically. Categories, Subcategories, Subsub Categories, etc. are well controlled. You can't use a Category and a subcategory, etc. ad hoc, using some existing subcategory with a Category that doesn't that that relationship set up already. You first have to stop and set up the connection, formally, before you can use that combination.

Tags, on the other hand, are sort of like "stickers" in the real world. Although you have to formally create the Tags, they can used - or not be used - with any and all Categories. So I guess that the program "knows" what tags are used but doesn't go to the effort to keep then in the same order as entered.

That said, I've hardly ever used more than 2 Tags at a time. and just have not noticed that Tags are being presented in an order other than as I've entered them. I just ran a 5 year test. I have a "Gifts Given" Category and have always Tagged then as "BD:Name." Out of all that rather long list I only found one transaction that had that reversed as "Name:BD," Clicking through to look at that transaction, that's exactly as I typed it in,.

Maybe the program does maintain "order entered" for 2 Tags, but 3 Tags create the confusion?

nc00ks0n

first noticed this years ago.

Began using mobile quicken just this year. Which means sync was turned on this year and the problem predates turning on sync.

The reordering is a only a problem when reading reports that are subtotaled by tag. In which case the report has two different subtotals. One for X:Y and another for Y:X. The sum of the two is required to know the total for that combination of tags. Typically I have to edit (arggh) all forms of that combination of tags into insert order to get a single total.

The ordering problem occurs only in X:Y examples. ie, when two tags are used and one of the two is a tag associated with a business. bllcJCFC:bBookkeeping turns into bBookKeeping:bllcJCFC most of, but not all of the time. bllcJCF is the business tag and serves as an umbrella for the two small business we own.
Another way bllcJCFC is used is to identify home office tax deductions that will now show up in the Schedule C reports. In this case bllcJCFC:4429 is used. It winds up with two forms with the second being 4429:bllcJCFC

In cases where three or more are used the insert order seems to be maintained.

Tom Young

@Chris_QPW

":Tag2 is exactly the same as Tag2:Tag1."

It certainly is, but my brief test ("brief" in the sense of only 5 years in a much larger file) seemed to indicate that Quicken DOES keep the Tags in the order entered. Have you seen otherwise? Hence my speculation that somehow the "3' tags might be the culprit or, after @nc00ks0n 's reply, that perhaps the use of mixed business/personal Tags is to blame.

Even though Tags are not well controlled in Quicken it does strike me as odd that Quicken doesn't simply grab the transactions "as entered" to show on a Report.

@nc00ks0n Somewhere along the line I assume you've done a Validation of the file and that didn't fix it?

Chris_QPW

My mistake, I didn't test, just went off of what they "were". Somewhere along the lines they have changed the definition of tags. They are now treating them like a string. Which BTW I think weakens them tremendously.

Given this:

And a search like this:

With the original definition of a tags, I should have got all the transactions with A on them. Instead, this is what is gives:

With this change they have changed tags into nothing more than a second category!

The whole point of tags was to be able to tag different transactions with different "properties" and be able to retrieve the transactions that have a certain set of properties without regard to the order they were tagged.

Now A:B isn't the same as B:A.

As for the bug mentioned where in some cases the user can put in A:B and it gets changed to B:A I suspect that is because there are still parts of Quicken that adhere to the old definition of what a tag is and think it is perfectly OK to reorder them.

Chris_QPW

And I will add, that with this change them have made the Tag List useless.

Where is A:B? in the above list?

nc00ks0n

https://community.quicken.com/discussion/comment/20499810#Comment_20499810

Yes validation has been performed.

Tom Young

"Where is A:B?"

I may be smoking my socks, but hasn't always been this way?

There is no "A:B" Tag. It's a "A" Tag and then a "B" that's been chosen by the user to add to the transaction as inculcated by the colon (";"). I've never been a big user of Tags since they aren't well controlled by the program so maybe I'm wrong. I just tried creating "A:B" as a Tag, but couldn't.

Chris_QPW

https://community.quicken.com/discussion/comment/20499981#Comment_20499981

Yes, but the point is that when they changed the definition of what a tag is (actually made it inconsistently defined), this list is now wrong (wrong for one "definition" and right for another "definition).

Let me be blunt, they have completely messed up tags. In other words, in some places they are properly treating tags them by the original definition of a tag, and in other places they are treating them as a string.

In the proper definition of tags A:B and B:A are the same thing. As such the order should NEVER matter. It shouldn't be a bug if Quicken chooses to show it as A:B or B:A, but by the same definition this should NEVER happen:

There should only be one line that shows the total of "A:B". This report is treating the A:B is a string, instead of properly treating this as transactions that have both the A tag and the B tag.

This goes for the find command too:

This is finding transactions that only have A on them, missing transactions that have A and other tags.

Here is how tags are supposed to work:

So, why do I say the tag list is now wrong? Well, I guess it depends on what definition of tags you want to use at the moment. If you use the original definition it is right, A, B, C stand on their own. But the moment you say A:B is different than B:A then these are now their own "entries".

Look at it as if it was a category.

Auto:Fuel isn't two categories, it is one category.

If I switch this around:

Fuel:Auto that is yet another category.

Contrast that to the proper definition of tags.

A transaction that has Tag1:Tag2 on it says "This transaction is tagged with both Tag1 and Tag2". It say nothing about which tag "comes first".

Whereas I can see a report that shows the combinations of tags as being useful, they have got themselves into the quagmire of treating it like Tag1:Tag2 is now a separate entry/string. And as such the user is now expecting this string/entry to be preserved when in fact the code/database is not structured to do that.