Purpose: This blog focuses on SAP Security measures concerning the Post/Approve functionality of Group Journal Entries in S4, specifically addressing restrictions and controls.
Scenario: For organizations seeking to enhance control over the F2971 Group Journal Entry application, this entails creating dedicated inboxes solely for approving Group Journal Entry workflow items. Additionally, implementing Segregation of Duties (SOD) rule sets ensures that users granted access for posting journal entries are restricted from approving them.
The blog covers the following topics:
Restriction on document type: When dealing with Group reporting document types, standard authorization objects like F_BKPF_BLA may not be available for direct restriction. However, an alternative approach involves restricting task types by associating specific document types to tasks.
Implementing scenario-based inbox: Discussing the implementation of scenario-based inboxes to facilitate the approval process for Group Journal Entry workflow items.
Restricting SBWP on Journal entry workflow items: Exploring methods to restrict the SAP Business Workplace (SBWP) access specifically for journal workflow items.
SOD risk definition: For users who have access to both create and approve Group reporting Journal items.
1) Restriction on document type
If there is a requirement that only a specific team should be able to create group journals for a particular document type.
For Group reporting document types, direct restriction using standard authorization objects like F_BKPF_BLA may not be available. However, an alternative method involves restricting task types by linking specific document types to tasks. In the example below, the role restricts task 21XX using the authorization object E_CS_CATT
Please refer to the following link for detailed information on the authorization object restrictions used for group reporting:
Authorization Object Restrictions for Group Reporting
To associate a task with a document type, you can navigate to SPRO (SAP Project Reference Object) > Navigate to define tasks for manual posting or use transaction code CXP5.
Navigate to document type to view the list of document types associated with tasks.
By implementing this restriction, users attempting to post journal entries outside of the designated tasks 21XX will encounter the following error. Additionally, tasks 21XX will be granted access to specific document types.
2) Scenario based inbox for Group reporting workflow items.
Perquisite : Automated work inbox setup has to be completed. Please refer to below blogs
In this blog, we'll explore how to create a scenario-based inbox for a specific Goods Receipt (GR) workflow, even though post group entries can be sent via workflow for approval.
a) Identifying workflow tasks for scenario specific inbox
For identifying the workflow associated with the group reporting, you can click on specific workflow items in the standard inbox and navigate to support information. This method provides a direct way to access details within the Fiori app. Alternatively, you can examine the workflow configuration or tables at the backend to obtain this information
The next step involves creating a scenario ID and associating the workflow tasks. For detailed steps on implementing workflow tasks, please refer to the SAP link provided: SAP S/4HANA On-Premise Documentation.
To proceed with this task, you can navigate to Gateway Service Enablement Content Task Gateway Service Scenario Definition, or you can use transaction code SIMG. These methods will guide you through the process of creating a scenario ID and associating it with the required workflow tasks.
b) Create new scenario (as shown below) to approve Journal entries
c) Associate consumer type to each scenarios as needed
d) Role restriction - Only users with specific role do have access to approve Group reporting inbox
e) Last important step is to add Task definition for scenario.
Add the GR workflow task identified in step a earlier
f) Modify custom catalog which has access for inbox app
Navigate to custom catalog associated with Inbox tile using tcode /n/ui2/flpd_cust > click on catalog which has my inbox app > then click on my inbox tile
To modify the custom catalog for SAP Inbox to filter on the above scenario ID, ensure that the scenario ID is added exactly as "scenario" in the parameter tab. This customization will ensure that the Inbox filters tasks based on the specific scenario ID
Also changed the service url highlighted above to scenario id
Now when user navigate to above inbox it should show only Group reporting specific workflow items.
3) Restricting SBWP on GR workflow items
SBWP is a common transaction code accessible to all users in our landscape. Despite restricting users' access to specific inboxes for approving Group journal entries, they retain the ability to execute SBWP, which displays all workflow items available in the system.
The SBWP standard transaction code lacks options to restrict access to specific workflow items; instead, access can only be restricted for the entire transaction code. However, this transaction code is utilized in other processes outside of Group reporting where scenario-specific inbox implementation is not in place.
The provided blog
offers guidance on filtering inbox items in SBWP for specific tasks. Please follow the steps outlined in the blog. However, if you aim to restrict access solely to Group Reporting (GR) specific workflow items, you will need to modify the BAPI Extension for the method on DEF_GUID specific to the GR workflow items.
Now user when navigating to SBWP, it will not show any GR workflow items and it will be accessible only via custom inbox fiori tile for GR which we configured above
4) SOD ruleset updates
Creating post group journal entries and approving them by the same user can potentially lead to a Segregation of Duties (SOD) conflict if the user has access to both the post group journal entries app and the custom inbox tile for Group reporting.
To mitigate this risk, we can define separate functions for the custom catalog containing the inbox tile and for others containing the SAP Post Group Entry app.
Note that the [FCAT] action can be utilized to associate the custom catalog with the appropriate function, aiding in enforcing the necessary access controls.
Through this way SOD checks can be implemented and risks can be mitigated.
- SAP Managed Tags:
