The idea behind this is that when creating a D-Cube you create it putting the D-List in order of 1-5. This helps in priority conflicts of formulas and formats. Plus, when you browse the library the D-Lists are sorted by the type of D-List. Easy Right? Maybe yes, Maybe no. The naming convention is open to interpretation. If I have a D-List for Years and it has no calculations, is it a 4 or a 3? What about a D-List that has Current Year Budget, Prior Year Actual, and a variance between Current Year Budget and Prior Year Actual. Is this a 5 since it has versions or is it a 1 since there is a calculation? What about a D-List that was a 3 but I’ve recently included a subtotal in the D-List do I need to go back and rename this to a 2?

The numbering method works great in a training class environment to help us learn the dimension order when creating the D-Cubes. After we learn the order, do we really need to number our dimensions?

Choosing the dimension for publish is one of the most critical steps in the Generate Framework Manager model process. The dimension chosen for publish will be treated as the Fact table in the publish process. In addition, the Generate Framework Model admin extension will model the dimension chosen for publish as the fact table. More simply put, the dimension chosen for publish will be your measure dimension.

Let me first start by saying this is not a how to or even necessarily the right way to do things… rather some options to explore learned from hours spent cursing at the computer trying to get the seemingly ‘simple’ things to work in crosstabs. You know, things like adding two columns together, calculate a variance, or filter out crosstab rows with no data. I run into these issues most when I’m building financial reports where we’re comparing multiple forecast/budget versions across specific spans of time.