F-02 without Acct typ K, D but posting with trading partner allowed

[Former Member]

Dear Experts,

I want to implement the authorization on F-02 for the GL team, they do not be able to post a transaction on a vendor or debtor with the posting key 31, 01 for example.

In PFCG and the F_BKPF_KOA object, I put only Account type = S, and it works very well. But this team have to be able to post with trading partner for cross-company code, example :

PstKy 40 : 130000 in Co code 2000

PstKy 50 : 760000 in Co.code 1000

For this posting the system will generate :

001 40 130000 Bank 2000 800.00

002 50 760000 Expense 1000 800.00-

003 31 KR1000 Kr2000 2000 800.00-

004 01 DR2000 Dr1000 1000 800.00

It will be not be possible because of the F_BKPF_KOA with the only Account type = S. It required to have also Account type = D + K. If I implement the D and K, the team will be able to post other debtor and creditor, and we do not allowed that.

I saw and tried other authorization object F_KNA1_BED , F_KNA1_GRP ; F_LFA1_BEK ; F_LFA1_GRP ; and activated the authorization field in the vendor, debtor master data, but it do not work. It is required Account type = D + K

How can I implemented that, it is my first little project in security and I have an issue.

Thanks.

[martin_voros]

Hi,

you can always introduce additional level of checks using FI validations. They are called for every posting so you can create a custom authorization object(s) and check it for all normal cases and don't check it for cross-company posting.

Cheers

[Former Member]

Hi Martin

At the risk of getting a roasting (shampoo advert next) because it's worth it...

Please could you give some pointers?

Here comes the science bit

Coz I am at a loss and this is a real **** to fix

Cheers

David

Forgot to say - without creating some z based non-sap silly solution

Edited by: David Berry on Nov 3, 2010 10:25 PM

[martin_voros]

David,

SAP has this tool called FI validations and substitutions. Basically, validations and substitutions are called for each FI posting. You can use validations to perform additional checks before posting such as for certain document type particular field is mandatory. What is really nice is that you can use custom ABAP code for validation. If document is not valid you just return an error message with reason why that document can't be posted. Because you can use custom code then you can easily put additional authorization check. For example for this case you could create a custom authorization object with two fields: cross-company posting and posting key. The custom code would need to figure out which posting is cross-company and which is not and then for each line check if user has authorization for that posting key and posting type. You have to remember that FI validations are company code specific so if you have multiple company codes then you have to set it up for each of them (you can reuse code). Another important thing is that you need to modify all roles related to FI posting to include this new object. Otherwise posting won't be possible. Obviously, you can restrict this additional check for subset of documents if your environment allows it.

Cheers

[Former Member]

Hi Martin

It sounds like there isn't an sap standard process to avoid SoD in RAR -do you know if your solution is GRC compliant?

Thank for the detailed background

David

[Former Member]

Hi David,

If your question is whether GRC considers FI validations and message type handling (table T100C) then I would suggest opening a new thread in the GRC forum.

Alternately I can move this thread over to the GRC forum if the original poster agrees (and follows up on the discussion...).

Cheers,

Julius

[Former Member]

Hi Julius and Martin

This sounds interesting, just checking what is being said - a copy of the SAP standard tcode/program with two new addtional objects and reference to table T100C are needed?

The A, K, D, M, S account types in FI really are painful to fix - high push back from the business when discussing this so anything in the GRC forum that can go towards controlling this would be great.

Hi Nicole

I'm not really following the guidance provided so far - do you have any options and, if you are using RAR, do you want to raise a new thread in GRC or have this thread moved there please?

Many thanks

David

[Former Member]

Hi David

Thank to everyone for different suggestions, you ask me to move my request to GRC , I just posted one in the GRC forum. I will see if somebody has a solution to do that.

Thanks a lot for everybody for your helps.

Nicole

[Former Member]

Hi Nicole

Welcome to what RAR in GRC tells us a lot - miixing A, K and D is a no-no for SoD - and a real pain.

I can't honestly remember the solution but creating multiple derived and splitting across users is a really messy option as already pointed out. I look forward to a solution!

Cheers

David

[Former Member]

Hello,

I can only think of making derived roles per permutation, and assigning the necessary ones to the authorised people.

e.g. User is able to use F-02 with Account types K and D for Comp A but S for Comp B would have 2 roles containing those very 2 restrictions (company code and account type) assigned to their User ID.

In an environment where there are many company codes, we are looking at a very messy situation in terms of roles.

Unless someone has any other intelligent solutions. Would be interested in hearing others opinions on this.