Entity-Specific Historical FX Rates for Acquisitions — A More Accurate IFRS Translation
Stop Fighting Your Equity Translation — Let HSR Do the Heavy Lifting A 5-minute read for anyone who's ever stared at a CTA movement and whispered: “Where did that come from?” _____________________________________________________________________________ The consolidation problem we all know It’s day 4 of close. Consolidation runs clean. FX looks fine. Then someone opens the equity rollforward. “Why is acquired share capital moving again?” The entity was acquired years ago at a historical acquisition rate, but the system is retranslating equity at current closing FX every month. CTA absorbs the movement. Auditors ask questions. Finance posts manual journals. Everyone loses time. This is the classic Historical Spot Rate (HSR) challenge. The design principle The goal was simple: Freeze selected equity accounts at acquisition FX rates while keeping the standard OneStream Software translation engine intact. No new cube. No custom dimensions. No complicated override framework. Just: metadata tagging, controlled FX logic, and safe fallback behaviour. The HSR pattern Component Design Entity activation Entity.Text5 = "HSR_Entity" Equity tagging Account.Text15 = "HSR_Accounts" Historic rates Stored in dedicated HSR rate technical accounts Translation logic Finance Business Rule Audit trail Dedicated FX movement flow HSR = Historical Spot Rate. The rule only activates when BOTH: The entity is tagged, and The account is tagged. This creates a simple but effective control framework. The historic rate storage design should remain flexible: use technical accounts, use whatever Text property the project governance model agrees on, and confirm all translation account tagging requirements with the Group Reporting Manager before deployment. What does the rule actually do? Check if Entity is HSR_Entity Check if Account is HSR_Accounts Retrieve stored historic rate Calculate FX adjustment Post adjustment to MVMT_TRANS_FX If anything fails → revert to standard FX That last line is important. The design intentionally prioritises: consolidation stability, auditability, and safe fallback behaviour. If metadata is incomplete or a rate is missing, the application simply reverts to standard FX translation logic. No broken consolidations. No blocked close process. Why did this work well in practice? The biggest advantage was operational simplicity. Adding a newly acquired entity became: Load historic rate Apply metadata tags Run consolidation No code changes required. The approach also kept: CTA cleaner, Equity movements are more stable, And audit support is significantly easier. The real challenge: governance The code itself was straightforward. The harder part was operational discipline: Maintaining 1:1 entity-to-rate mapping Controlling metadata tagging Defining fallback expectations Building reconciliation reporting Testing CTA behaviour thoroughly In my experience, most FX translation problems are not technical problems. They are governance problems. Community question I’d be interested to hear how other certified OneStream Software architects and administrators are handling Historical Spot Rate scenarios. Particularly: Are you using metadata-driven activation? How are you storing historic rates? Have you handled HSR entirely through translation override logic? Any alternative designs that further reduce maintenance? How are you handling CTA transparency and audit reporting? Always interested in seeing cleaner or more efficient approaches from the community.
Missing underscore in member names displayed via combo box
Hello! We have a missing underscore in a combo box and I'm not exactly sure why... Here's what shows: Here's how entities are set up: Anyone see this before? Seems related to this one which says it's resolved in 7.1.3 but I'm not seeing that: Underscore in member name not displaying in multiselect listbox | OneStream Community
Hybrid Scenario Issue: Copying Single Period Without Affecting Prior Months
Hello everyone, I’m encountering an issue with Hybrid Scenarios: I’m trying to copy data for a single period only. While I’ve successfully managed to copy Local data for that specific period by updating calc status, the results become inconsistent from Translated up to Top. To align the data from Translated through to Top in the target scenario, I currently need to run a Force Consolidate. However, doing so also brings in data from previous months, which is not desired. Has anyone faced a similar issue or found a way to restrict the consolidation to a single period without impacting prior periods? Thanks in advance,OS 9.2 Form Templates Parameters
Hi All, I have a cube view with a set of parameters as a member list. I attach the CV to a form template and override the cube view parameters by using the 'cube view parameters' feature in the form template. As an administrator, I can see the filters I added in the drop-down list, but for the end-user, it is completely blank. (See photo). All dimensions displayed are set to everyone, including templates, cube views, and workspaces. What is causing the issue? In 9.2, the members do not appear in the member list.
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)
