False positive SOD conflicts for tcode F110-Compliance Calibrator 4.0

[Former Member]

We use Virsa Compliance Calibrator version 4.0. We are implementing Latin America. Brazil uses Boletos. Boletos are a used to invoice customers. To create Boletos, transaction code F110 (which is usually used to issue check or ACH payments) is used. Boletos use the same authorization objects as those which are used when issuing payments - F_REGU_KOA FBTCH and F_REGU_BUK FBTCH. People who issue Boletos will have SOD conflicts but they should not because, although they are using F110, they are not issuing payments, they are merely invoicing customers. Has anyone had this issue and, if so, can you explain how you resolved the false positive SOD conflicts?

[former_member9720]

Hi,

I've asked to my collegues also, but it seems there is no alternative to F110.

So, in my opinion, there are two possible solutions:

1) create a mitigation control: because, in your situation, is a kind to risk that, in some way, you have to accept.

2) if you have also the FireFighter module, you can assign one of the roles, that create conflict at user level, to a FF id, let's say the role with with tcodes that are used occasionally.

Regards

Emilio

[Former Member]

I was hoping that there was a alternate way to create Boleto's. We cannot use the FF approach since they issue Boleto's several times a day. I think we will end up mitigating those users. Thanks for your thoughts on the matter!

[former_member9720]

Hi,

is it possible to have more information about?

That is:

- which is the function involved in the false positive AR01 or AP01?

- does this false positive, appear only at user level?

- can you give an example of the values of the roles of a user who claims this false positive?

Thanks

[Former Member]

These Boleto users are processing customer invoice Boleto's and so they will have F_REGU_KOA KOART restricted to D. The conflict therefore comes from AR01 rather than AP01. They need F_REGU_KOA 11, 21, 25 and 31 to issue Boleto's and so to prevent an SOD conflict in a Security role, we are already splitting F110 and their customer master access (needed to adjust customer addresses on Boleto's) into several security roles. Although the security roles will be clean, the users will have S011 conflicts - AR01 and SD01 when we assign them these multiple roles. In theory, these users could use this access to refund a customer after first manipulating the customer master record because actions 11,21,25 and 31 are also used to run the payment program and so I suppose it is not really a 'false positive'. Unfortunately we cannot determine a way to restrict access to give them just the ability to do Boleto's but not do the payment program. It is frustrating that they have re-purposed F110 to do a harmless activity - issue customer invoice Boleto's - rather than create a new tcode for this activity. So, short of business process re-engineering to split this harmless process across multiple employess, we cannot figure a way around this because Boleto's use the same tcode and auth objects as actually making a payment. We are hoping that someone may know of an alternate, non F110, way to create Boleto's.