Category code automatically changing (MUN's) and assigning tildes

[sasdev]

Transformer 8.3
Item dimension:
Item Class - no category code defined
Item SubClass - no category code defined
Item - Category code set for (ItemNK)
Item Key (Hidden) - Category code set for (ItemWK)...Categories  feature checked as (Unique)

Info on Item & Item Key (Hidden):
Item: Although not set as a Unique category within transformer, it is a unique field within the data source.
Item Key (Hidden) - Set as Unique category within transformer, and is also a unique field within the data source.

Problem: Query Studio report broke when query attempted to run and could not find a filtered member within the detail filtered query. The member it could not find was a member that was
assigned an ItemNK of 3697~88718. The user had dragged and dropped this item within the filter the week before to build it. The next week, the cube was rebuilt using the Clean House
feature (which we always do) and the MUN of the 3697~88718 changed to 3697~91045 and therefore nullified (broke) the filtered query because it could no longer find the previous item
within the data source.

Confusion: The Item level within the Item dimension uses the ItemNK field for the Category code. When checking to see what else in the Item level within dimension was trying to use
this Category code I saw that nothing else was...at least at this level. So, the MUN for this particular item is as follows:[OLAP - Marketing].[Item].[Item].[Item1]->:[PC].[@MEMBER].[3697~88718]

Question: I'm trying to understand why Transformer placed a tilde within the category code. In doing a search, there is no other Itemnk (category code) using the 3697 ItemNK.
The closest thing I've been able to find is a MUN (category code) of 3697 within another level within the Item dimension, and this level uses a different field for the category code (ItemWK)
The MUN for item in the different level within the Item dimension that could possibly be causing transformer to assign a tilde to the previous item number is: [OLAP - Marketing].[Item].[Item].[Item Key (Hidden)]->:[PC].[@MEMBER].[3697]

Question: They clearly would have the same @MEMBER key before Transformer would assign a tilde for uniqueness issues, however they are located in different locations within the dimension which
would ideally would give them a unique MUN, so why does Transformer still assign the tilde????

[MFGF]

Hi,

One of the fundamental concepts of any OLAP source (including Powercubes) is that each member in a dimension *must* have a unique ID.  This is the reason your ItemNK 3697 was originally modified by Transformer to ItemNK 3697~88718 - because another member in the dimension (almost certainly at a higher level) already used ID 3697.

As you're now discovering, if your dimensions do contain non-unique member IDs, using Clean House can cause huge problems, as the randomly generated tilde numbers enforcing uniqueness will not be the same as they were previously for the non-unique IDs.

One option that can be used as a workaround if the Category Codes are not being displayed is to concatenate a different character to the beginning of the value used for the category code for each different level where non-unique IDs could occur.

MF.