Extensibility report usage
HI, OS has report to verify extensibility. I wanted to know based on exp that what happen when report has an error from technical perspective.
We have some ragged hierarchy to full fill our req, bu...
Forum Discussion
Without knowing the specific errors you are receiving, I'm not sure anyone is going to be able to say whether the errors you are receiving will result in consolidation issues or not.
Here are a few common examples of dimension vertical extensibility issues that will definitely result in consolidation issues:
- Attaching an extended member to a parent member of the inherited dimension
- Having incompatible properties between the extended member and the base member to which it is attached in the inherited dimension. Eg - defining an extended member with a plug account, but using a different or no plug in the base member of the inherited dimension
- Constraints that are looser in the extended members than the constraints defined for the base member of the inherited dim to which it is attached. This is really just another variation of incompatible properties, of which there are many others to consider.
example of UD1. Since Patch Product is not created in Summary DIM, extensibility will throw an error.
If that example was used with vertical extensibility, the extended member "Patch Product" would be a problem given it is being attached to an inherited parent. This would be a problem in the summary cube, as other than Entity type dims, you cannot store data in a parent member ("Patch Product" would try to summarize to "Total Product").
With horizontal extensibility, as it would appear is the case in your example, it should not technically be a problem. Comparative reporting isn't really clean, but that might not matter. However, what are you going to do if "Patch Product" turns into a real product for which you then have Actuals data? At that point you do have a problem.
