In purchasing release strategies in SAP are used to ensure that purchase requisitions, purchase orders and purchase agreements are only released by an authorized individual with sufficient approval authority. The system prevents an approver from releasing a purchase document which value exceeds his or her approval authority limit or from releasing a purchase document at all. These approval values and the ability to release purchase documents are captured in SAP roles through authorization objects and transactions and are assigned to the user ID. The GRC Access Control module can be used to report on user IDs with specific purchase document authority limits.
In invoice processing no release strategies in SAP exist to ensure that invoices are only processed by authorized individuals with sufficient approval authority. The system does not prevent an individual from releasing an invoice which value exceeds his or her approval authority limit. Authority limits are not captured in roles through authorization objects and there is no ability to run a report on user IDs in GRC using the standard GRC rules with specific invoice authority limits. For invoices that are matched with a purchase documents and goods receipts this is not an issue as the authority limit of the approver is checked when the purchase document is released.
One of the advantages of SAP Invoice Management (VIM) is that it offers a solution for ‘none three way matched’ invoices (invoices without a purchase document reference). Authority limits and levels of are maintained in the charts of authority (COA) table and mapped to user IDs. Without an entry of the User ID in the COA table the user ID will not be able to release an invoice which value exceeds his or her approval authority limit.
Invoices allocated to a specific user that are handled through SAP invoice management can be accessed by executing the transaction code VIM workplace (/OPT/VIM_WP) or alternatively by executing SAP Business Workplace (SBWP) and display the allocated tasks in the user’s inbox. As you can imagine running a risk analysis in GRC to identity users that are able to process VIM invoices will result in many false positives, simply because most users in SAP will have authorization to access to SBWP work inbox. The important factor is whether users can also release the invoice. By adding a supplementary rule these false positives can be eliminated and additional information can be provided to the GRC access rule.
Let me give an example. Access risk ID ZRARPC10 (VIM process invoices) is a critical action that consist of GRC function ZFAVM001 (VIM process invoices). ZFAVM001 is the GRC function used to capture the relevant transaction codes and authorization objects to process VIM invoices. We will run a risk analysis on access risk ID ZRARPC10 and user IDs TDEJONG and NHARMANUS
As expected the result, as displayed below, shows that both user IDs can process VIM invoices which is in line with their authorizations in the target system.
However user ID TDEJONG does not exist in the Charts of Authority (COA) table and in fact cannot release invoices. The result showing that TDEJONG can release invoice is a false positive.
User ID NHARMANUS is entered in the COA table and can approve up to level 5 (highest amount) standard invoices.
As stated earlier by adding a supplementary rule to the VIM process invoices GRC function ZFAVM001 the false positive can be eliminated and additional information, in this case who can approve level 5 invoices, can be provided.
The following supplementary rule is created and assigned to the GRC function ZFAVM001. The supplementary rule in this example looks for all User IDs in the COA table which can approve standard invoices up to level 5. The total value (amount) is defined in a different tab of the COA table.
Let’s re-run the risk analysis with the same criteria.
As expected only the user ID that can release standard invoices up to level 5 is displayed and the false positive is eliminated.
By using the supplementary rules user’s authority limits in SAP invoice management can be included in the GRC risk analysis. The great thing about supplementary rules is that it can be used for other approval authorities as well such as SRM shopping cart approval, approval authority engine, HR position approvals etc.
Want to learn more about supplementary rules or GRC access control in general? Please contact me