In that case, is this the structure of your logical tables?
Sales Fact Table
1. Sales Quantity (Fact)
2. SKU (Attribute)
SKU Dimension Table
1. SKU (Attribute)
2. Contents (Attribute - 1-M Parent of SKU)
3. Units (Attribute - 1-M Parent of SKU)
There are several possible implementations, but I prefer this:
Create a fact named [Contents in Pounds] with fact expression:
[tt]
ApplySimple(
"(select [contents] *
(CASE
WHEN [contents_units] = 'kg'
THEN <kg to pound factor>
WHEN [contents_units] = 'tons'
THEN <ton to pound factor>
...
ELSE <default factor>
END)
from [SKU Table]
where [SKU Field] = #0)",[SKU Field])
[/tt]
Bind this fact expression to the Sales Fact table.
This fact pulls the contents in pounds for each SKU into the Sales Fact table. This way, you can create a metric that does a straightforward:
Sum([Sales Quantity] * [Contents in Pounds])
BTW, just because a field isn't numeric doesn't mean that it can't be a fact. The core of MSTR Architect is just a SQL generation engine. The goal is getting MSTR to generate the SQL you want, regardless of any data warehousing definitions or rules.