1 person found this helpful
I don't believe they work with Financial Reports.
1 person found this helpful
Valid Intersections control where data can be entered; they do not control access. Use security on an alternate hierarchy.
Do you mind me asking if you find valid intersections; -
a. Take a large amount of maintenance
b. Are generally worthwhile
c. Make any difference to the way that business rules run
thank you!! - cheeky of me I know!!!
How do I apply security in the case of the CEO (& other Execs), who need to be able to see all data for all Entities/Departments but don't want to sort through a list of 100+ Salespersons to find the 5 that are relevant to the Entity/Department they have just chosen?
I have implemented Valid Intersections twice. Once fairly simple and once pretty complex. They require attention to detail and close testing during development. But when in place, they work very well with a few caveats (below). I recommend a close reading of the documentation, as there are some unique features and terms for VI. The question of maintenance is system-dependent. Both of my implementations so far require very few changes over time, so the maintenance is small. I could see where maintenance could be a challenge, but I can also imagine some ways to ease it.
1. Although one can name and describe the VI groups, the rules within a group cannot be so identified. One of my groups has a dozen rules with some subtle differences, so modifications can be tricky.
2. Valid Intersections do not honor shared members the same as other planning tools. I have forms for which the accounts are determined by an alternate hierarchy of shared members. This works fine. But VI will not restrict data entry by shared members, so I cannot use the same hierarchy to control VI. Oracle's response is that this is by design. I have asked for an enhancement, but who know if they will ever do it.
3. Valid intersections prevent everyone (including admins) from entering to invalid intersections via web forms, planning form opened in smart view, and smart view ad hocs. It does NOT prevent entry into invalid intersections via smart view formula "HsSetValue". We found this out by accident and Oracle so far has offered only to use the Valid Intersections reports to check for invalid data. These reports are very limited and do not fit into our forecasting cycle.
I really like the functionality and my client loves the results (except for the HsSetValue bug), but it has not developed much since initial deployment. Oracle could really use to survey users/implementers and make some improvements.
You could create numerous security groups and apply them to both dimensions, but that would likely be difficult to maintain. You could hard code in reports, but the same thing.
Perhaps a reporting cube where you combine the entity and salesperson hierarchies into one dimension?
Many thanks for your extremely generous answer, which I am liking - though I really wish I could give you points!
You do not mention loading data via data management - I take it this is still open?
You also do not mention any effects on business rules - again I take it that this is also open?
The purpose of valid intersections is to block users from entering data. They are not designed to block business rules nor data management. Nor would I want them to. I have numerous statistical accounts and export accounts which are calculated by business. I do not want users to change those values.
Makes sense, I was just trying to confirm all aspects.