08-08-2024 02:36 AM
hi
we are using stored calc to apply tax rate on pre tax income and eventually calculating net income. Tax rate is pretty static throughout the year but it may change in middle of the year. we've given users to enter tax rate as applicable throughout the year so this tax computation remains dynamic. Actuals scenario is YTD.
the issue we're facing is if we change the % (lets say 20% up until Jan to May and starting April, it goes up to 25%). In other words, we want April YTD tax to be 25%, it is not footing to 25% at lower level. any ideas how to achieve this?
08-08-2024 04:27 AM
Hi, the easy solution is to just enter the new tax rate into April and adjust the rule so that it takes the tax rate for each month individually. That way, 20% will be applied to January - March and 25% from April onwards. There are other ways, but those require more effort in my view.
08-08-2024 04:43 AM - edited 08-08-2024 04:52 AM
08-08-2024 05:02 AM
Yes, your data will not change in January to March if you follow this. You just need to change your parameter "taxRate" to pull the data from each month, enter the new 25% tax rate in April and all data will remain as needed (as the formula will pull the 20% for calculating January to March, still).
The OneStream Remote Consulting team may be able to help with this too if needed (billable service).
08-08-2024 09:03 AM
ok. i am changing taxrate parameter for each month. and the tax calculation at entity level in local currency is as expected. 20% till march and 25% YTD in April. but converted USD is slightly off..25.xx%. we've 50+ entities. and where entity currency is USD, USD Tax is 25%. it is just for entities where entity currency is non usd.
08-08-2024 10:23 AM
I notice when adding in the V#YTD:T#POVPrior1 you are reading from F#Top:U4#Top, which differs from where you are writing your calculated result. Is it possible F#Top:U4#Top is including additional non-calculated intersection?
I effectively use the same method you showed to apply rates that can vary over time, and it works very well. But, I do make sure I read the V#YTD:T#POVPrior1 from exactly the same intersection I wrote to, so that I have no chance of including any additional 'surprise' data.