I am curious if anyone has a use case for intercompany accounting in Prophix. In our case, we have 18 business units, which may or may not have intercompany activity in the month. We want to true up (revenue/direct costs/AR/AP) discrepancies that may exist between two or more business units. It is challenging in Prophix because each business unit only has access to their respective business unit. Does anyone have a work around to be able to save data at another companies intersection but to maintain security so business units can only see the activity they need to?
I see this is an older post so you probably designed a solution already. If so, please share it.
We have multiple companies but not the security issue you mention here. One approach Iād consider is creating special accounts for each company that would be stored in each entity, then use an infoflex to update other entities based on each otherās adjustments, perhaps on a scheduled basis or triggered by a workflow.
Or perhaps a cube-based calculation that looks up values from the other entities to show in this one.
Assuming each company uses a different accounting system (a problem Iām fortunate not to have) you may need to get very detailed in an account-to-account mapping. But once configured it should be pretty static except for organizational changes such as acquisitions of new companies.
Hope this helps.
Would love to hear what you came up with.
I would echo this. The previous company I worked at had roughly the same number of divisions, but several had multiple entities so IC became very difficult. We extracted all of the intercompany transactions from the various systems (too many to count) to their own cube, created a cross-check grid for each category (trade, allocated expenses, dividends, debt, equity, etc.) and let the divisions hash it out amongst themselves. Security could be set on the āfromā and ātoā dimensions to narrow down what could be seen at a given division. When in doubt, the sending entity was considered the correct balance and it was plugged to in-transit.
I donāt have that problem anymore, but if I did that method was very effective and easy to control RLS.
1 Like
Thanks Frank and Bob,
We went with a hybrid of both of these solutions. We ended up creating a separate āintercompanyā cube, which essentially mirrored our financial cube, besides the fact that we removed any sensitive data. This way, we gave everyone access to all the business units, and used a ātoā and āfromā procedure. We have workflows set up to allow our end users to true up balances, and once this process gets finalized we push the data to our financial cube for reporting, using an export/import.
I like Bobās idea of creating a separate āsub-entityā that everyone has access to. In hind sight, probably a better solution, but the separate cube doesnāt add any extra effort to our end users, just more heavy lifting from the admin perspective. But to your point Bob, it is mostly a āset it and forget itā unless a new entity gets created.
2 Likes
There are generally a lot of ways to approach this problem. One that I havenāt seen mentioned yet is the use of Security Groups. In the Security Manager you can create Groups which have specific access and read/write restrictions to specific cubes. You can even fine-tune this access down to each individual hierarchy within a cube. A single user can then be a member of many Groups, and will always default to have more access if there is a conflict between Groups they are a member of.
In your instance you could, for example, have two Groups for each business unit. One would define all of the access a member of that business unit needs. The other would only define the access someone viewing that business unit needs. You could then assign the groups as needed to employees. So someone in unit A who needs to view unit D would have the Member Group for unit A and the Viewer Group for unit D. Giving them full access to their own data and only the restricted access you define to others.
I didnāt think Security Groups would help in this case because of the business unit restriction. Security Groups only provide access by dimension, not by unique intersection. Making a business unit visible to an outsider would make the full business unit visible, not just this one account. (Actually, all accounts available to any particular user would be visible for all business units.) What I thought we were looking for here was this ONE account to be visible, maybe even editable, across multiple (perhaps all) business units, but other accounts to be visible/editable only in the userās main business unit.
Itās unfortunate that the security groups donāt get down to intersection-specific rights; Iāve wanted that many times in my job-based cubes where the same user will play different roles in different jobs, but I have to give them consistent rights across all jobs rather than job-specific access rights.
Iād say having group of accounts (like Bob referred to) or separate cubes, would address the security issue here. Great going Josh on the solution that you have implemented.
We have created the companies and associated that in a GL accounting strings and we restrict access through security setting for that dimension which is just one element in the account string.
I echo this, but appreciate all the other insights!
1 Like
We were able to only create them gl strong but reading this thread opens up the possibilities a bit
Information was very helpful as we have multi companies that consolidation and intercompany are used for.
I like the solution that Josh have implemented.
Thank you for sharing.
Thank you for sharing.
Thank you for sharing.
Thanks everyone for sharing. Good place to get ideas.