This is a tricky business then.

A conventional way of dealing with this would be to translate the codes to a new, common basis. So if companies A, B, and C all have different codes for the product category "fuel", you would define a single standard "fuel" code (and it need bear no relation to the existing codes -- in fact, it's probably better if it doesn't, in order to avoid confusion). It's alsways nice if you can find some industry standard set of codes to map to, though it's not always possible to do so.

If you really require that the companies be able to view their native codes then you could take one of two approaches.

Approach 1 is to make the company's native codes children of the standard code, and do the company/code concatanation thing to make them unique. Only the company native code would appear in the fact table -- the standard code would be related to the native code through the dimension table.

Approach 2 is to make the standard and native codes completely independant of each other by storing both in the fact table and maintaining separate dimensions tables for each.

Whatever approach you take i would still maintain the company as a separate column from the product category in the fact table.

It's stuff like this that means 70-80% of the DW effort is devoted to ETL coding.