I think the problem may be because the field is a Computed Column. CustTrans and TransType is a good example to explain my logic. First, some background.
In BI speak, CustTrans is a "Fact Table"
technet.microsoft.com/.../aa905984
It contains some fields which are Measures and some fields which related to Dimensions.
Each Dimension also needs a Dimension Table
technet.microsoft.com/.../aa905979
Switching to your example, in the Perspective, the 'CustCube' contains the CustTrans table, which contains the field TransType. TransType is a Dimension field. In the real CustTrans table, TransType is an Enum. An Enum field contains values which are linked (via a label) to a Description. This Enum and Description needs to form the basis of the TransType Dimension Table in the Cube.
How is that represented in the Analysis Services database?
Well, there is a Data Source View for CustTrans, which contains the TransType field. BUT, there is also a relationship to another View called CUSTTRANS_DIM:
This View does not exist in the AX database, but is in fact based on a Table called SRSANALYSISENUMS (WHERE ENUMNAME = 'LedgerTransType'). From here, the Cube can get the TransType description (in many languages!). So CUSTTRANS_DIM is the Dimension Table.
A similar thing happens for Dimensions which are not Enums. For example, Method of Payment is also on the CustTrans table. Method of Payment is a Dimension Field. In the Data Source View, there is a relationship to a View based on the table CUSTPAYMMODETABLE, which gives the Cube the Name of the Method of Payment. CUSTPAYMMODETABLE is the Dimension Table.
In the case of Enums, the BI Wizard knows to use the SRSANALYSISENUMS table to create a Dimension Table. To create a Dimension Table for non-Enums, like Method of Payment, I assume the Relationship to the CUSTPAYMMODETABLE on the CustTrans table is used.
With your Computed Column, there is no way for the BI Wizard to create a Dimension Table, since there is nothing behind it.
