Some customers run several SAP Finance systems in their business and wish to consolidate the workflow and approval around one central system. This has the advantage of giving a central point for audit, control and reporting.
In addition some customers use one (or more) systems but wish to remove access to sensitive SAP transactions such as FB01 from end-users. In this case they can use the hub-and-spoke configuration to switch users at posting time to a system user and hence the end-users no longer need access to FB01.
Features of Hub-and-Spoke
- Centralised control in the hub.
- Audit captured in one system for entire organisation.
- Enables easier compliance as auditors can extract approval data easily.
- Control posting authorisations with central updates.
- Secure control – all within SAP using standard SAP technologies.
Communications from the hub to each spoke is via RFC (Remote Function Call) and can be further secured using SAP SNC
The term “service user” is used in this document and refers to the background user that is configured in the RFC destinations. From an SAP technical perspective this is a “System user” – Type B user.
Each spoke must have an entry in the configuration decision tree which holds its RFC destination
The Hub must also have a list of the currently active spoke systems as a master list
The image below shows two SAP FI systems (H05 and H01) configured. In addition the Hub also has an entry that defines its RFC destination for the purposes of callback.
In this case SAP FI system H01 is acting as both the hub and also a spoke
The possible update scenarios:
|Scenario||Name||Description||Which RFCs are needed||RFC settings |
|1||Standard||The hub/spoke is not used and updates occur using the users own SAP id in the local system||none||none|
|2||Local with service user||The hub/spoke is used to “switch” the users to a specific service user during simulation and posting.|
Postings occur in the local system (the hub)
This enables organisations to remove access to FI transactions such as FB01 for additional control.
|Posting RFC||Posting RFC must have a service user assigned with sufficient authorisation to perform simulation and postings|
|3||Spoke with actual user||The spoke system (an ECC or S4Hana system) is connected to using the actual (real) user of the requester.|
Postings occur in the spoke (remote) system
|Posting RFC to each spoke system||Posting RFC must be set up as a trusted RFC system with the “current user” flag set. No user is maintained in the RFC.|
|4||Spoke with service user||Postings occur in the spoke (remote) system||Posting RFC to each spoke system||Posting RFC must have a service user assigned with sufficient authorisation to perform simulation and postings|