Segregating F110 and F111

[Former Member]

Hi experts,

I hope somebody can help with this.  The business has the following situation:

The roles for transaction F110 are segregated so that one user performs the payment proposal and another performs the payment run.  The roles for transaction F111 are not segregated, so one user performs both tasks.

Transactions F110 and F111 both use the F_REGU_BUK authorisation object, so if a user has the roles for both transaction F110 and F111 they can perform both tasks in both transactions.

The authorisations need to be changed so that a user can be assigned the roles for both transactions, keeping the segregation in place for F110

My initial idea (after the business refused to change their business process) was:

The program behind transaction F111 is SAPF111V.  Searching this program for F_REGU_BUK authority checks reveals that it is referenced in 4 places.  Once for authority checks when performing actions and again for presentation

These authority checks need to be modified to ignore the action that the user is undertaking.

The roles that give access to F111 need to be modified, blanking out the actions within the F_REGU_BUK authorisation object.

This means that if a user is assigned the role containing transaction F111 then they can perform all actions within the transaction.  If a user is assigned the roles for both transactions F110 and F111 there are no actions within the F111 role to interfere with the actions within the F110 role.

This approach fell over because 2 of the required ABAP changes have enhancement points available, but the other 2 don't, so we would have been required to modify SAP standard code.

Does anybody out there have any more ideas, other than the obvious ones of changing the business process to segregate F111 the same as F110 or never assign one user both F110 and F111?

Regards

Chris

[Former Member]

You could try to use validation customizing of message control, but that is actually nonsense IMO.

Is it a hard requirement to segrate proposal from execute?

Much more efficient is a 2- or 3-way match to the order, receipt, invoice and monitor the hopefully rare exceptions. Then you dont need to turn the system on it's head.

Other payments from non-subledge applications should be subject to the same auditability and ideally the same user administration.

Most customers actually try to get the process before the payment proposal "water tight" and then monitor exceptions / patterns. Then you can even automate that which you now are wanting to create a bottle neck for.

Works for very large banks, so why not for you?

Cheers,

Julius

[Former Member]

If they want a segregation between the user who can de the payment proposal and the one who can do the payment run, maybe this problem can be solved via the F_REGU_KOA object?

F110 and F111 both need the F_REGU_BUK object. I don't know on top of my head which values F111 really uses for the  FBTCH (Action for Automatic Procedures)? If they require the same actions as F110 then you have a problem indeed. But maybe the F_REGU_KOA restriction on FBTCH can help solving this? Even if a user has all actions for F_REGU_BUK, but is properly restricted on F_REGU_KOA he cannot do all actions in F110 but can do all actions in F111.

I agree with Julius that it is possible that your company already have a compensating control set up to solve the SOD between F110 - payment proposal and payment run (example by a second person who does the actual bank payment via a seperate bank transfer). So this might be woth checking it out.

I hope your query will be solved!

Meta

[Former Member]

Hi Meta,

I didn't think of looking at the F_REG_KOA obejct.  I can use my original approach, but with the F_REGU_KOA object instrad of F_REGU_BUK.  Checking the ABAP shows that enhancement points are available for all F_REGU_KOA checks in the program behind F111

Thanks for your help Meta and Julius

Regards

Chris