Authorization checks for FM Derivation Rules?

[Former Member]

I have searched this forum for posts related to derivation rules but have not found any relevant discussions.

We have Public Sector Management active in our system. We have defined about 50 derivation rules in FMDERIVE.

As a result of the execution of these rules, users are able to create postings to Org Level Objects (such as Business Area and Fund) for which they do not have authorization.

On the one hand, by their nature the intent of the rules is that if X conditions are present, then postings must be made to Y and Z account assignments. But on the other hand, these effect of these rules is to remove ability to restrict which users can make postings to these account assignment elements.

We have two security questions:

1) are there authorization objects which we can use to limit instances where a derivation rule can be invoked?

For example, a derivation rule states that for cash journal X, Business Area will be ABCD and Fund will be 9876. However, the user only has authorization to post to Business Area EFGH and Fund 1234. We want a hard stop that says the user is not authorized to create a posting to Business Area ABCD and Fund 9876.

2) Are we able to apply authorization checks for derivation rules at the user level, or is the execution of the derivation rule independent of the user?

For example, we have a savvy user who has figured out that she can enter Business Area EFGH in FV50, and the rule will change it to ABCD. We ran a trace in ST01, and found that the system only checks her authorization for the value she entered, and not for the value which is called by the rule. Is the derivation rule executed only after control has been passed from the user to a system object? (We talked to her and she said "I know I'm not authorized to post directly to that BA so I do it this way instead")

Thank you for any help or guidance you can give me.

[Former Member]

For these delightful concepts embedded within sub-concepts of the original concept, you are often left to your own and the documentation's devices, and the best weapon of choice IMO is to read through the code itself and debug it.

Sorry - have not even heard of this derivation before.. 😞

Cheers,

Julius

[ThomasZloch]

In your place I would send a message to SAP via SMP describing the issue. Maybe there is a quick fix for it (included in more recent SPs, what is your SP level?), or you will have weeks-long back and forth with several support levels until there is a new SAP note based on your message, or they declare it's not part of the standard because bla bla.

One counter argument I can think of is that these rules (which hopefully cannot be changed directly in production) are on a technical level that kicks in after user interaction. You are saying that A should become B in certain cases, so you are implicitely allowing people with authorization for A to go to B (in these cases only). Otherwise, they would enter A and be irritated about subsequent error messages. They will correctly be rejected if they enter B directly.

Thomas

[Former Member]

Julius and Thomas, thank you both for your replies.

Thomas raises the fundamental business question. We have defined that a standard value must be posted under certain conditions. The disconnect is that only certain users should be allowed to create those entries to those posted values. This is especially true when crossing organizational structures to post to other agencies' control structures

The conditions themselves do not necessarily have available authorization objects. If they do have relevant objects, they are not necessarily organizational level objects. This in turn leads to a geometric increase in complexity of role creation and maintenance. What want to do is to be able to control at the root level (Person A can only post to org level Z) rather than chasing the posting downstream.

I'm going to take both of your suggestions. I'm going to work with the development team to trace the code execution. Once I have more specific information, I will open a message with SAP.

If we find a solution, I will post it here.