Written by Cam Larner
President
Absolute Technologies, Inc.

Earlier this year, a customer contacted me to report that SoD Violations Manager for Oracle E-Business Suite was inaccurately identifying that a user could perform transactions via the Receivables Cash Receipts form function, technically known as AR_ARXRWMAI_BATCH.

She asserted that although the user was actively assigned a responsibility which contained the “Cash Receipts” function on one of its submenus, and could indeed access the form, the user could not actually make any transactions using the form, as it was “View Only”.

As it turned out, the SoD rule that flagged the violation was defined such that any user which had access to the AR_ARXRWMAI_BATCH form function and the CEXCABMR form function, aka “Enter/Reconcile Bank Statements”, would be flagged as a violation. Thus, as defined, SoD Violations Manager was accurately reporting the function conflict as a violation. And yet, the reality was that it was also reporting a false positive. Hmmm…

To resolve the issue, its helpful to take a step back and take a broader view of all the factors and nuances at work. The rule, as defined, did not take into account that in order to perform “Cash Receipts”, the user must have concurrent access to both a form function, which provides navigable access to the Receivables Receipts form (ARXRWMAI), and a subfunction which grants cash transaction permissions while the user is in the Receipts form.

In this case, the following form functions provide access to the Receipts form (ARXRWMAI):

Form Function Name	User Form Function Name
AR_ARXRWMAI_BATCH	Receipt Batches
AR_ARXRWMAI_BATCH_SUMMARY	Receipt Batches Summary
AR_ARXRWMAI_HEADER	Receipt
AR_ARXRWMAI_SUMMARY	Receipts Summary

And the following subfunctions provide Cash Receipt transactability to the Receipts form (ARXRWMAI):

Form Function Name	User Form Function Name
AR_ARXRWMAI_CASH_ENTER	Receipt: Enter
AR_ARXRWMAI_CASH_UPDATE	Receipt: Update
AR_ARXRWMAI_CASH_DELETE	Receipt: Delete

One nuance, however, is that in order to enter, update or delete records, the user must also be able to view records on the Receipts (ARXRWMAI) form. This feature is granted via the following subfunction:

Form Function Name	User Form Function Name
AR_ARXRWMAI_CASH	Receipt: View

So, in order to transact a cash receipt, the user must be assigned at least one of the above form functions, the Receipt: View subfunction and one or more of the remaining transactability subfunctions. That means the user must be assigned access to at least 3 functions to actually perform a cash receipt transaction.

Now the question becomes, how does one best define the SoD Policy in SoD Violations Manager to avoid a false positive?

The first consideration is that whenever a subfunction is defined in a policy, SoD VM will not consider it as a violation unless the user also has access to its “target” form function, whether the target function is defined in the policy or not.

Therefore, it is enough to merely define the desired subfunction(s) in the policy, instead of defining the related target form function, as was the case in the customer’s function conflict rule.

Since the “Receipt: View” function must be present to allow enter, update or delete, the policy must also be defined such that both are detected as assigned to the user. In this case, this can be achieved by creating an SoD VM Policy which requires a three-way match (where the user has access to all three functions).

Here is one possible approach:

This policy configuration logically translates to the following pseudo code.

An access violation will result when the user is assigned form functions… 

CEXCABMR
 and (
 AR_ARXRWMAI_CASH and
 AR_ARXRWMAI_CASH_ENTER and
 (AR_ARXRWMAI_BATCH_SUMMARY or
 AR_ARXRWMAI_BATCH or
 AR_ARXRWMAI_HEADER or
 AR_ARXRWMAI_SUMMARY)
 )

For Updates and Deletes, you simply define another similar policy to address each. Here’s an example for “Updates”.

Note that the “Rule” in each policy for Group B is “Any 2”, which means that access to any two of the functions in the group is required to constitute a violation. In these examples, there are only two function members defined for Group B, thus all functions in the group must be accessible.

In conclusion, although user access to a given E-Business Suite function is often complex and nuanced, SoD Violations Manager provides powerful and flexible rule making capabilities that support the definition of SoD policies that will yield accurate, false positive free violation results.

Cam Larner
President
Absolute Technologies, Inc.