Skip to Content
Author's profile photo Former Member

TCodes F110 and FBZ0 – Segregation of Duty Fix

Generally Tcode F110 is a potential SoD risk. F110 combined with FBZ0 creates numerous SoD violations. Let’s discuss what is exactly the risks are and how to avoid it.

F110 – Automatic Payment Transactions : Status
FBZ0 – Payment Proposal

Through F110, we can do two activities i.e. Payment Run and Payment Proposals.
(While running payment proposal it asks for FBZ0 access at the background, that is why I have combined both of the transactions while describing it)

Now the risk is that payment run and payment proposals should not be given to the same person who will access F110 because of SoD violation.

To remove this SoD risk, we need to play around some authorization objects i.e. F_REGU_BUK and F_REGU_KOA.

These authorization objects contain some activities which are given as numbers inside the role.

The meaning of those numbers are provided below.

02            Edit parameters
03            Display parameters
11            Execute proposal
12            Edit proposal
13            Display proposal
14            Delete proposal
15            Create payment medium proposal
21            Execute payment run
23    Display payment run
24            Delete payment run payment data
25            Create payment media of payment run
26            Delete payment orders of payment run
31            Print payment medium manually

To make payment run and payment proposal mutually exclusive, we need to restrict the activities accordingly.

So one role should not contain 11, 12, 13, 14 and 15 and the other role should not contain 21, 23, 24, 25, 26 and 31.

Restricting the authorization objects with above activities we can remove the potential SoD risk easily.

Assigned tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member
      Yours is a very interesting proposition, because in our ECC 6.0 system, those activity values with the exception of activity = 24 come in as the default values for those objects to enable F110. I am curious to see if any auditors concur with your risk assessment. If there seems to be a consensus, leading to the conclusion that that the standard configuration enables SOD violations, we should consider influencing SAP to change these settings. It should not be up to every customer to spend time doing SU24 changes and regenerating roles to resolve the risk if it is indeed one.


      Author's profile photo Former Member
      Former Member
      Dear Gretchen,

      Yes. You are right. In ECC6 EHP 4, all the above activities are available by default with F110. However, this was my company's requirement to divide the responsibilities of payment proposal and payment run to two different persons. Hence the auditors were keen on checking the company specific SoDs.

      This was just an information so that it might help somebody who is also having similar issue with F110.

      Author's profile photo Former Member
      Former Member
      The short answer is, from my view anyway, that this is not an SOD issue.  But SOD is never a cut-and-dried issue.

      Different companies want to handle their processes and transactions their own way.  With different resources available, there may be an internal desire to more strictly control individual processes or, conversely, a need to combine duties and implement a compensating control such as management review.

      There is no such thing as a risk of SOD violation -- SOD is a control for some other business risk.  The key is to look at the risk of having both F110 and FBZ0.  These are both payment transactions, which alone is not so bad.  You would want access limited to those whose job required it.  It's really only when you combine a payment transaction with access to credit memos, POs, goods receipt, invoice entries, and/or vendor master data that a true SOD issue will arise.

      Anyone with any update access can intentionally or accidentally mess up the master data.  But SOD controls are there primarily to prevent one person from committing an undetectable fraudulent transaction.  The bottom line is this: if the combined roles assigned provide enough access for someone to commit fraud, then you have an SOD violation. This can be corrected by modifying or removing roles, or by adding an automated or manual review of the potentially suspect transactions.

      Author's profile photo Former Member
      Former Member
      The proposal indicators are an *indicator* of the intended capabilities of the transaction.

      You should never follow them blindly, as they are in many cases created blindly from the RZ11 parameter auth/authorization_trace. It is a special feature in SAP's development systems to document the capabilities of the transaction and a best guess at the intended use a customer might have for the transaction, depending on your config and business processes.

      That is what SU24 is for: To tune the proposals for that which you do configure and use.

      Also take note that the functionality can be executed via SA38 and several other protocols as well, so the tcodes are not the real risk but rather that which it is processing.

      My 2 cents,