Row suppression not working with dynamic cube?
Hi folks, My suppression in my cubeview doesn't work. If I turn on any suppression (including 'invalid') the cubeview returns blank (no rows at all). It's a cube that's been loaded with dynamic data services and the data is showing as NotStored. I wonder if that could be the cause? Anyone else observe this or have any tricks? I've tried every combo of suppression option I can think of... I'm surprised it would return nothing even with only 'suppress invalid' checked..
Issue Referencing Parent Entity in an Stored Account Member formula
Hi, We have a few accounts that contain stored formulas. These accounts contain formulas that reference another Account and Parent entity and it stores the result at a Base Entity. Below formula is for an account that has a formula pass 4. We are storing the result in "BaseEntity" and calculate Account1 by looking at OPEX at a Parent Entity. Obviously, since it is referencing a Parent Entity we have to run our consolidations twice in order to get the result. Is there a way to sum up the Base entities of Parent1 and reference that value in a formula or is there a way to run a consolidation within the formula for just that Parent Entity? In other CPM/EPM products I've worked with in the past you can right rules where you run an aggregation on the Entity and then run your calculation. In OneStream I cannot seem to find a way to do this. If api.Pov.Entity.Name = "BaseEntity" Then api.Data.ClearCalculatedData("A#Account1",True,False,False,True) api.Data.Calculate("A#Account1 = A#OPEX:E#Parent1:C#USD",True) End If Any help or assistance would be appreciated. Thanks John
Same Scenario Across Two Cubes vs Separate Scenarios — Pros & Cons?
Hello everyone, I’m looking for feedback on the pros and cons of using a single Actual scenario across two cubes (e.g., Consolidation and FP&A) versus defining separate scenarios for each cube. For example: Option 1 (shared): Consolidation Cube : Actual (Scenario Type = Actual) FP&A Cube : Actual (Scenario Type = Actual) Option 2 (separate): Consolidation Cube : Actual (Scenario Type = Actual) FP&A Cube : Monthly (Scenario Type = Control) From your experience, how do these approaches compare in terms of data governance, maintenance, performance, flexibility for planning/reporting, and potential risks (e.g., unintended impacts between cubes)? Any best practices or lessons learned would be greatly appreciated. Thanks in advance!Error processing member. The item was not found. Member, -100.
I am running a cube view form in a workflow from OnePlace, i can able to execute other forms like Total Revenue, COGS, IC COGS, OPEX etc but not IC Revenue, Need help, if anybody come across this. Error processing member. The item was not found. Member, -100. Error Description: Unable to execute Business Rule 'CFO_NoInputRule'. Error processing member. The item was not found. Member, -100. User Interface Stack Trace: at OneStream.Client.Api.DataExplorerServiceReference.DataExplorerServiceClient.StartOpenCubeViewGridCompressed(SessionInfo si, Guid workspaceID, String cubeViewName, CubeViewUIModuleType uiType, Dictionary`2 customSubstVars, TriStateBool suppressRows, Int32 pageIndexForPreviousPage, CVGRowOrColUniqueIDStruct lastRowIDInPreviousPage, Int32 compressedRowIndex, List`1 overridenCubeViewMemberExpansions) at OneStream.Client.SharedUI.DataExplorerControl.InitializeGridAsync(TriStateBool suppressRows)
How to Add Adjustments with Add Back Category and Free-Form Add Back Name to Actuals in OneStream?
Hi Everyone, I’m working with Actuals data structured like the attached screenshot and want to add adjustments linked to this data. Key points: Adjustments must tie to Actuals by Company, Account, and Month Each adjustment includes: An Add Back Category An Add Back Name, which is free-form text and can vary monthly I want to maintain monthly detail and enable reporting and drill-down by both Add Back Category and Add Back Name My questions: What’s the best approach to model and load adjustments with both a Add Back Category and a free-form Add Back Name in OneStream? Should Add Back Name be a UD member with auto-create, a text attribute, or something else? How to avoid member explosion or reporting complexity given the free-form nature of Add Back Name? How can I ensure adjustments roll up correctly and maintain data integrity? Any recommendations for validation, governance, and reporting for this kind of adjustment detail? Thanks in advance for your insights!
