Local update with service user

This document details the steps needed to set up the Journal Posting solution for update (posting and simulation) using a service user in the current system. It is a specific variant of the hub and spoke configuration used in a single SAP system.

Please review the hub and spoke background information before configuration of the solution

Scenario description

You have a range of users who are not authorised for access to powerful SAP FI transactions such as FB01, FBD1. You may also be removing these transactions from existing users to bring in additional control.

In the Promenta solution you can enable requesters across your business to make journal posting requests without the SAP authorisations by delegating the actual simulation and posting to a service user account which does have the access.

Promenta stores the full audit of the request (requester and all approvers ) against the posted journal so you can always check who was actually involved in every journal that was posted.

Standard configuration and setup

The solution is delivered with a default configuration which can be used immediately for this scenario. Note that Promenta offer general guidance in the use of SAP standard BASIS transactions as described below. You should refer to SAP documentation for additional information.

Step 1 : Create Service User

Create Service user (SAP System user type B) with authorisation to post and simulate and all other expected FI transactions authorisations. This user must also be able to store documents against the posted journal using the BDS or ArchiveLink service. The user should have decimal notation type X (ie period notation). Date format 4 (YYYY.MM.DD) is recommended.

In the screenshots below the service user is PROMENTA_UPD however you can use any user id that fits with your naming conventions.

This must be done in every SAP system as users are not transported

Step 2 : Create RFC destinations

Note : Since SP30 the HUB RFC is no longer required

Create two RFC destinations as described below.
These RFC destinations must contain the service user information as set up in step 2.

This must be done in every SAP system as RFC destinations are not transported

Transaction SM59

Connection type: ABAP connection (type 3) is recommended. Connection type “Logical Destination” (type L) can also be used.

Server settings: This connection will be to the same server (ie itself) so normally no parameters are required although some network/firewalls may need additional settings.



Additional settings

Additional settings may be required for your specific scenario such as SNC, trusted connections etc. Basis team should check these settings

Unicode : in a multinational project it is normal that non-Latin character-sets will be used (eg Cyrillic, Chinese, Japanese, Korean etc) . In this case you must set the Unicode flag on the MDMP & Unicode tab

Step 3 : Set the update scenario to 2

Update scenario 2 enables local update with service user.

Decision Tree : /PROMENTA/WSFI_JP005.  Note : You would normally do this in a customer-specific override tree

This change is done in the development system and saved in a transport. 

Step 4 : test connectivity

Scroll to Top