cancel
Showing results for 
Search instead for 
Did you mean: 

Headcount r

NicoleBruno
Contributor III

Hi all,

We’ve set up a UD1 member to account for headcount in our application. We have cost centers in our account dimension which we’re using in conjunction with the headcount UD1. The issue is that the numbers translate when reviewing at a base entity depending on the currency or, if we load a USD JE, the numbers are just not visible for base entities in a different currency than USD.

I’ve reached out to OS support and they have no reference for a customer using UD for headcount and say that any account type outside of Balance or NonFinancial will translate (CC accounts are expense). Any thoughts on workarounds for this? We’ve settled with the USD JE though that’s clearly not optimal. Any suggestions would be welcome!

Thank you,
Nicole

 

PS. I had to add a letter to the header because it didn’t meet the minimum which is why there’s a random r up there 

10 REPLIES 10

TerryLedet
New Contributor III

One thought without the complete picture is to possibly use a Flow member with Alternate Input Currency set to USD.

Michel_Sabourin
Contributor

Alternate Currency for Display is available for the UD members, but it’s limited to one currency. Have you tried setting the Is Consolidated property to True (regardless of Formula Type)? Not sure if that would do anything, but a thought.

Clarke_Hair
New Contributor III

When you say you are using the UD1 to capturer Headcount, are you saying that the UD1 members are numbers like 1,2,3 that represents the number of folks or just the type of Headcount (Salary, Hourly,…). Also, how are you putting Cost Centers in the Account Dim. Is that Cost Center A as a parent with a number of children’s as accounts or you are not using the Account dim as Accounts at all. Making the Account Type = NonFinancial should keep currency from coming into play. You still want it to consolidate so you get summary numbers at the top.

Hi Clarke,
We have the parent of Headcount_Total then children Headcount_Filled and Headcount_Vacant as the UD1 members which are then populated with the headcount number by cost center (account dimension). We have CCs in the account dimension the same as accounts - they’re in the opex area of the income statement where costs are driven by CC instead of account. CC is the base member in those areas of the IS with accounts being the base members in other areas (for example, the balance sheet). The CCs then work in conjunction with the UD1s where the shared expense accounts exist (for example, salary, bonus, benefits, etc.).
We can’t make the account nonfinancial because it’s a cost center where real dollars exist.
Does that make sense? I know it’s a bit confusing so just let me know.

I assume you wouldn’t want to have a sibling cost center labeled _HC? You could use that for just headcount and make that non financial. It wouldn’t be the most elegant solution, but it would stop the translation issue. You could also create a USD entity for each of your foreign currency entities to load the headcount in. We did that for one of our clients who wanted to be able to make top-down adjustments without having to calculate the translation for foreign subsidiaries.

Hello! 

Thanks for the suggestions but yes, we wouldn't want to duplicate all the cost centers just for headcounts as we have hundreds of cost center accounts. Similarly with the USD entity - that seems like too much extra master data in our case just for headcount tracking but good thinking outside the box! 

Sai_Maganti
Contributor II

Nicole

Have you considered an inbound translation to local currency on the USD JE so that all the amounts will be loaded to their respective local currencies and upon consolidation will re translate to USD.

Best

Sai

Hi Sai, 

Do you mean to put the JE into local currency when posting? What exactly do you mean by "inbound translation to location currency"? Thanks!

Nicole

What I meant was to translate when loading the journal using a BR from usd to local. Does it make sense?

Sai

Hi Sai, 

Thanks for the explanation - that does make sense.