I've searched and searched and can't find the answer for what seems should be fairly simple.
I have a hierarchy of employees in a dimension. Employees have points (in a fact table). I can easily see the points summed properly when I drag my hierarchy onto rows. The problem is that employees are judged differently based on job code, which doesn't necessarily correspond to levels in the hierarchy.
For instance, I have Project Engineer Is. They are judged on individual points. I can pull Name onto rows, filter by job code, and put points into measures and I have exactly what the user wants to see.
Project Engineer IIs are a different story. They are judged on TEAM points. I pull name onto rows, filter by job code, and I need a calculated measure to sum up all points belonging to them, just as it would if I had dragged the hierarchy onto the rows. The problem is I can't seem to relate the Name or EmployeeID to the hierarchy in order to get that team value. In fact I can't even grab the Employee ID primary key because it is hidden under the parent child hierarchy. I have to grab a copy of it.
How can I accomplish this requirement? I've experimented with a lot of different MDX (a language in which I am no expert) but the crucial block seems to be that I cannot get the hierarchy member based upon the row value. It is as if they are totally unrelated, when, in fact, I know that my copy of the key relates to one and only one specific member of the hierarchy. For this reason, I am also thinking that it might not be the MDX so much as the dimension attributes/relationships/properties that may need changing.
Please help! And let me know if there are any questions I can answer about the cube or requirement.
Update: I have set up the dimension using a bridge table and a many to many relationship as described at the following link : http://www.sqlbi.com/wp-content/uploads/The_Many-to-Many_Revolution_2.0.pdf on page 70. I didn't mention it because I didn't think it was relevant and it clouds the question. I set it up this way because there is both a formal and an informal hierarchy. Conceptually, I don't see how it matters, because the parent child relationship is exactly what you would expect - there is a parent field which corresponds to a key value.