Implementing MOAC Security via Parameter LOVs

For better flexibility and maintainability, the recommended best practice is to use the unrestricted base tables, such as `ap_invoices_all` . Security should be applied by introducing the Operating Unit as a required parameter in your Blitz Report , . The LOV attached to this parameter is then automatically restricted to show only the operating units available to the current login user’s responsibility .

The LOV restriction approach provides greater flexibility . It allows users in roles like shared service centers to potentially view all data if configured, and it enables IT professionals to test the SQL query directly via database tools (like Toad or SQL Developer) without needing to fully initialize the application user session context, simplifying debugging and maintenance .

Yes, control over Ledger security is managed via a profile option . If your report typically only uses inventory organization security, for example, you can enforce restriction by ledger access set by setting the profile option ‘Blitz Report Use Ledger Security’ to Yes . Similarly, ‘Blitz Report Use Operating Unit Security’ allows activating or deactivating operating unit security .

Yes, you can use the utility function `XXEN_UTIL.USER_NAME` , . When passed the Oracle user name (e.g., ‘SYSADMIN’) as an input parameter, it returns the full user description, such as ‘SYSADMIN (System Administrator)’ . There is also an overloaded version that accepts the user ID as input . Note that displaying the user description can be deactivated by setting the profile option ‘Blitz Report Show User Description’ , .