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 CommunityHybrid 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,
SetLiteralParameterValue issue on web
In our first workflow step, we set the value of a literal parm using dashboard extender and then in next step use that parm in a DM job to export data based on that parm value. On windows client, our DM job works fine but when we try it on web, it does not find the value of the parm and errors out. Can someone please share any experience with this kind of setup and how to make it work on web?
Consolidate / Aggregate Averages
Good morning all, i've been asked to add some customer satisfaction values to our reports and its just a score out of 5, this works fine for base entities but I really need to parents to be an average of the base Entites that have a value. Is there a way t achieve this? appreciate your time. TadSame 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!TXM - TXM - Reconciling Duplicate Lines with the Same Amount in the Same Data Set
Hi, We are working on a Proof of Concept (POC) with the aim of implementation. However, one issue remains a roadblock and is hindering the adoption of the solution: the deletion of lines loaded with the same amounts, which we are unable to reconcile or isolate. In TXM, our ERP system sends us many identical lines (following corrections by the accountants): e.g., Transaction ID 1, CPT1, Invoice: 10000 Amount: 10; Transaction ID 2, CPT1, Invoice: 10000 Amount: 10; Transaction ID 3, CPT1, Invoice: 10000 Amount: 10. I would like to know how, within a single Data Set and from the same Data Source, to reconcile and/or isolate these lines, which represent unnecessary noise in the analyses. From my understanding, intra-Data Set reconciliations are not possible in this case. I sometimes have 2, 3, 4, 5 or even more almost identical lines that unnecessarily clutter the analyses and hinder the actual cases that need to be studied. Do you have a solution for reconciling these lines and placing them in a reconciliation status awaiting validation? (Ideally, matching them with a reason code like "same lines," for example.) Thanks! BR
