Hi, you are applying a relational blend logic here which is a great use of the OneStream Platform!
The thing here is that relational blend typically applies many to one logic in terms of reporting. I.e. in your example, I presume you have many rows loaded from your ERP to the OneStream Stage that aggregate into a single project (group?) in the Cube, i.e. a single row in your cube view. That means that there are multiple Attribute 9 values applicable to a single data point in the Cube I assume (aggregated to a single project / project group).
That means that you need to determine whether the loaded project status is always the same for each source line from the ERP for a given project. If so, you can filter the lines and just return the first Project Status for your Cube View. This works with a dynamic member such an one in a UD8.
If the status field can vary then you have a reporting problem as the system cannot decide for you which of the status' you wish to see. Is it "Closed", "Cancelled", "In Progress",...? In the latter case, I always remove a column such as your project status from the Cube View and add a click-dependent grid view to the dashboard that pulls the corresponding rows from the ERP load into the grid, depending on the cell a user clicked on in the Cube View. That way, a user can analyze the line item details in a grid for a selected CV cell, easily identifying the different status rows. (--> "Relational Blend")
This is also the reason why there is - to my knowledge - no such thing as a dimension-based member selector that one can use to just say "return Attribute 9 from Stage load". Attributes refer to the Stage table, not to a (Cube) dimension.
Adding this also for other users of the forum who might read this: Please note that projects should often not be added to the metadata as those may often be better served in a custom table. In my view, large projects of project groups may be added to the cube if that serves project reporting best, but if a company has tens of thousands of projects, I strongly advise against cube-based reporting and apply a more relational-blend centric logic. If in doubt, please discuss with the corresponding architect on a given project.
