Maintaining different values for Accounting Type (KOART)

[Former Member]

Hi experts,

I have several accounting tcodes such as FBV0, FB03, FB08, FV65,FV60 in one parent role.

FV60, FV65 are added to this role as FBV0 is checking internally for this authorization object.

All these tcodes share a same object F_BKPF_KOA which differ by activity and the accounting type (KOART).

The KOART field is an org level field defined by SAP and I have entered D,K,S as values.

But the auth object values should be different for the accounting types.

i.e 03 for D,K,S

01,02,03,77 for S

03,77 for K

All the derived/child roles for this parent should also have the same document type as the parent. How can I achieve this as this object is maintained at the org level.

I could not delete this obj from being an org level element as it is defined by SAP.

Appreciate your response.

Thanks

Kee

[jurjen_heeck]

I think your only option will be to split the parent role into three new ones.

[sdipanjan]

Yes, you can define separate set of Ref-Der roles for each set of Account type.

i.e. 1 set for "03 for D,K,S". Another set for 01,02,03,77 for S and Next set for 03,77 for K. But this has already been suggested. I want to add (rectify) few points you mentioned:

> The KOART field is an org level field defined by SAP and I have entered D,K,S as values.

>

> All the derived/child roles for this parent should also have the same document type as the parent.

Parent role is not the place to define the Organization boundaries. Child roles are meant for Org. separation. So, don't maintain org. levels in Parent roles. Rather do it in Child role only. Thus your separate value sets can also be imposed here without creating separate set of Parent-Child roles.

> I could not delete this obj from being an org level element as it is defined by SAP.

>

Don't do this. This way you can't revoke the check as it is carried out while executing the Dynpro for that particular screen by means of "Authority-Check".

Regards,

Dipanjan

[jurjen_heeck]

> > All the derived/child roles for this parent should also have the same document type as the parent.

>

> Parent role is not the place to define the Organization boundaries. Child roles are meant for Org. separation. So, don't maintain org. levels in Parent roles. Rather do it in Child role only. Thus your separate value sets can also be imposed here without creating separate set of Parent-Child roles.

If KOART is an org field you cannot differentiate between authorized activities for each of the KOART values in one role. Whether you maintain values in the parent or not only matters if you're planning to assign the parent roles to users or if you just use them as templates.

> > I could not delete this obj from being an org level element as it is defined by SAP.

> >

> Don't do this. This way you can't revoke the check as it is carried out while executing the Dynpro for that particular screen by means of "Authority-Check".

Please elaborate on this one. I think we're running into an urban myth here....

Organizational levels are only instruments to assist in building roles. For the final profile it does not matter whether a field is organizational or not. It will not influence the behaviour of the authority-check.

[sdipanjan]

> If KOART is an org field you cannot differentiate between authorized activities for each of the KOART values in one role. Whether you maintain values in the parent or not only matters if you're planning to assign the parent roles to users or if you just use them as templates.

>

Parent Roles should not be assigned to any users. It should only be used as Template to grant and control Non-Organization Level authorizations centrally (you can see these option in Parent roles). Concept of Parent-Child role is to avoid creating same roles where all authorization field values are exactly same and differs only for Organization Values (different Site / Branch Office specific constants). So we can maintain the Org. levels as different sets for a single Parent role as I already explained.

For more details: Note#314513 - PFCG: Maintaining individual organizational levels

Note#532695 - PFCG: Incorrect organizational level values in derived roles

>

> Please elaborate on this one. I think we're running into an urban myth here....

>

> Organizational levels are only instruments to assist in building roles. For the final profile it does not matter whether a field is organizational or not. It will not influence the behaviour of the authority-check.

For the final profile it matters during loading of User authorization data to User Buffer. Think about the Parameter values stored for a particular user. How it behaves for all Objects containing a particular Auth. Field and providing default assignment for that user whenever he tries to perform any action where this field is required to populate.

If we delete any Object from SU24 proposal then it doesn't mean that the check will not be carried out or the Org. Field contained in that object will not be populated with it's values. I tried to make this clear to the requester.

Regards,

Dipanjan

Edited by: Dipanjan Sanpui on Jun 8, 2009 7:49 AM

[jurjen_heeck]

> Parent Roles should not be assigned to any users.

I consider that to be a matter of taste

> For the final profile it matters during loading of User authorization data to User Buffer. Think about the Parameter values stored for a particular user. How it behaves for all Objects containing a particular Auth. Field and providing default assignment for that user whenever he tries to perform any action where this field is required to populate.

This I do not understand. I thought we were discussing whether it matters if a field is organizational or not?

> If we delete any Object from SU24 proposal then it doesn't mean that the check will not be carried out or the Org. Field contained in that object will not be populated with it's values. I tried to make this clear to the requester.

See above, I wasn't talking about SU24.

[Former Member]

Guys,

Just a question

Cant we have a parent role with the Object F_BKPF_KOA inserted twice manually (so in total you would have the object 3 times)

Maintain the value S in the org level

For the first time the object appears mantain values as 01,02,03,77 (the values S is default populated)

For the secod object maintain values 03, 077 - Manually change the default value of S to K (you will get a message on how bad it is to do something like this, but i guess you can continue)

For the third object Maintain value 03, change the values S to D, K

Create any number of derived rles from this parent the values would remain the same - isnt it?

Bad practice..........Hmmmm - I am not sure

I would think it is more on individual judgement based on the guidelines and limitations of the client & the project.

So before using / trying the approach suggested - the good & bad aspect of this approch should be looked into & let common sense and judicious decision making prevail

[Former Member]

If you are going to break the auth concept like that then you might as well retain consistency by demoting the org level to a standard field value.

[Former Member]

Alex,

I take your comments in the right spirit

On the project i work on, we have 2500 users spanning in 16 (more or less) countries - the management DOES NOT want any more than a defined set of roles created (their logic being that it is not manageable once i go

this could be logical for the management but ridiculous to my thoughts........but with little choices and strong views on the ever-debating topic here, the approach i suggested is the approach that is followed here........

But, in principle and In all fairness i do agree with what you say..............(thats the reason i mentioned the common sense and Judicious decision making part before considering the views expressed

[Former Member]

Interesting trick, but these sorts of workarounds can have unexpected sideaffects later on?

For example, there is a limit to the org field values per role, which is computed from a formula which involves the longest field and the number of fields. Now while this new org.level might appear to be "small fry" it will cause big problems for you when you reach the limit and other fields for which org.levels are more suited cannot be maintained or promoted to them.

You mentioned that you have 16 countries and want few roles as possible - so I think this is a real risk for you.

Cheers and thanks for your interesting posts and contributions to the forum, even if controvertial :-). I for one always read them with interest.

Julius

[Former Member]

>

> Interesting trick, but these sorts of workarounds can have unexpected sideaffects later on?

>

> For example, there is a limit to the org field values per role, which is computed from a formula which involves the longest field and the number of fields.

I know that there is a limit for the authorizations per user, number of roles a user can have ....but org field values.....hmmm didnt know that, this is a new learning for me and i am curious to know how many org field values can one have per role? any suggestions on where i could read/investigate more?

>

> Cheers and thanks for your interesting posts and contributions to the forum, even if controvertial :-). I for one always read them with interest.

thank you.

I woudnt want to be personally associated with controversies but i would like to explore and discuss different ways of doing things.........For a start, i didnt really face difficulties in the approach i took, the org values that are manually inserted always show up in AGR_1251 with the specifc values manitained, all other org values that are populated in the normal role generation are shown with $......

Moreover, out here we have the auditors checking for SOD compliance and the tool the auditors use to check role consistency and SOD has nothing to do with the org values, so the approach works for us (my apologies to Alex -i am sure he wouldnt be happy for not following the Correct approach

[Former Member]

Yeah, it would be nice if the field value remained $ when you generate the authorizations, because it would be 100% bullet-proof SOX compliant... )

=> No one would have any access, except for DUMMY checks. See the last sentence of SAP note 410993.

Cheers,

Julius

[Former Member]

>

> Moreover, out here we have the auditors checking for SOD compliance and the tool the auditors use to check role consistency and SOD has nothing to do with the org values, so the approach works for us (my apologies to Alex -i am sure he wouldnt be happy for not following the Correct approach

SoD can have plenty to do with organisational values depending on your situation. Data segregation is as important for some companies as the segregation of duties. There are plenty of situations where you can get in more legal data with data visibility than you can with segregation of incompatible functions.

If I was auditing an implementation with hard coded org values, it would be picked up and commented on as an example of poor practice. There are workarounds which mean that hard coding this stuff is not possible. A design that requires that sort of bodge is usually (though not always) a poor design to start with.

Doing things differently is all well and good if it has a benefit. If you leave the company/client and have not done a thorough handover then someone will take a look and wonder what you have done. This is risk enough in itself. Standard SAP functionality is not perfect by any means, breaking that usually makes it worse, not better.

[Former Member]

>

> Yeah, it would be nice if the field value remained $ when you generate the authorizations, because it would be 100% bullet-proof SOX compliant... )

Julius, i would think Audit compliance whether it be SOX or J-SOX (which apparently is supposed to be more stringent ) and the technicality of SAP, are equally indivudalistic as they are inter-dependent

so i wouldnt mix SOX compliance with a technical set-up

• Please seee my reply to Alex too**

[Former Member]

> SoD can have plenty to do with organisational values depending on your situation. Data segregation is as important for some companies as the segregation of duties. There are plenty of situations where you can get in more legal data with data visibility than you can with segregation of incompatible functions.

> If I was auditing an implementation with hard coded org values, it would be picked up and commented on as an example of poor practice. There are workarounds which mean that hard coding this stuff is not possible. A design that requires that sort of bodge is usually (though not always) a poor design to start with.

I absoultely agree with what you say

It is a valid point you make on data segregation being equally importants as segregation of duties.

we have a set up where for all inter-company sales, data on sales, logistics, finance is shared amongst companies in all the countries. so in principle we have a central company code, central sales organization, plants owned by the central company and customers and vendors linked to the central company.

so, in my inheritance set-up, for a local company that does say customer or vendor postings, they have authorizations on create, change, display on their company code and customer authorization groups. But when they need to check the document flow of financial document in the intercomapny flow, they will not be able to do it if they do not have a display access on 3 or 4 objects related to the central company code, customer authorization group, and FI document display

Now, the trade-off is in between creating a new role for the required authorizations OR to duplicate the object in the existing role -

the way i found, seems to work for the situation and the esteemed auditors dont have a problem

Edited by: Shekar.J on Sep 7, 2009 3:04 PM

[Former Member]

>

> Doing things differently is all well and good if it has a benefit.  If you leave the company/client and have not done a thorough handover then someone will take a look and wonder what you have done.  This is risk enough in itself.  Standard SAP functionality is not perfect by any means, breaking that usually makes it worse, not better.

On the lighter side, I made sure of my livelihood, isnt it

Standard SAP functionality is not perfect by any means, breaking that usually makes it worse, not better.

100% Agree

The only thing i would like to say would be - i havent come across a ABSOLUTE idea or work pattern for SOD and technical set-up from SAP, what i mean is there doesnt seem to be a 100% fool-proof methodology

[Former Member]

>

> so i wouldnt mix SOX compliance with a technical set-up

SOX compliance is reasonably dependent on technical setup.

General risk management is more dependent on it as it encompasses more than just SoX does for example.

If you are going to step outside the normal operating parameters for a tool, an auditor would usually expect to see where the risk is reduced by doing it that way.

[Former Member]

>

> >

> > so i wouldnt mix SOX compliance with a technical set-up
> 

>

> SOX compliance is reasonably dependent on technical setup.

> General risk management is more dependent on it as it encompasses more than just SoX does for example.

I agree completely

> If you are going to step outside the normal operating parameters for a tool, an auditor would usually expect to see where the risk is reduced by doing it that way.

I still dont see the audit-risk involved in having a org value object duplicated and manually maintained - if this is agreeable to business and if this does not cause any compliance issue with the auditors

Technical set-up apart, Ideally i would think, such a option of dupliicating an object for a common org value should be agreed by the business and by Internal control team, the ones who define the processess within an organization and test them for completeness and ensure that there are no major flaws in the way business processes are built and managed

[Former Member]

>

> I still dont see the audit-risk involved in having a org value object duplicated and manually maintained - if this is agreeable to business and if this does not cause any compliance issue with the auditors
> 
> Technical set-up apart, Ideally i would think, such a option of dupliicating an object for a common org value should be agreed by the business and by Internal control team, the ones who define the processess within an organization and test them for completeness and ensure that there are no major flaws in the way business processes are built and managed

Compliance is one component of audit and if you are performing an audit against any framework, you need to be comfortable that the objective is met. If you come up against a poor technical build (I am talking generically, not aimed at this situation) or a technical build that is not consistent then it is fair to comment on the meeting of that objective within the context which you are looking i.e. it's passed but more by luck than judgement.

In terms of "normal" audit, Security is an integral part of the control framework so often the technical build it looked at by the auditors. In the example of the hard coded org values, it is symptomatic that role the technical design does not meet the control requirements as it forces you to "break" the concept. That is avoidable as we have covered in the last few pages.

1. Building roles in a different way, build additional roles

2. Demoting the org level to a field level

<to be continued in next post....>

Edited by: Julius Bussche on Sep 7, 2009 7:34 PM

[Former Member]

<continued from above>

As you mentioned earlier, it keeps you in a job , unfortunately from a risk perspective, you have introduced exceptions in the role build which will need to be documented etc. The risk is that by breaking the concept, the design is no longer working along standard lines and requires (your) specific knowledge to support. Without you, they are in trouble. It would (should) also be an indicator to the auditor to start looking at other things like undocumented manual auth objects, auth objects in changed mode etc. It's not going to get your accounts qualified, but if your auditor does not have faith in your technical build then they may choose to perform more substantive testing which will cost your company more.

p.s. since when did the business or Internal Control team know enough about security to make a judgement call on this type of thing I have worked with some very capable IC folk but If they knew this stuff, they wouldn't need you!

Edited by: Julius Bussche on Sep 7, 2009 7:35 PM

There is a limit of 2000 characters per post

[Former Member]

Wow.....the wrath of Alex

Alex, if the technical change is documented does it make a valid approach

I remember reading in one of the threads where you suggest to convert a org value to a field level - isnt that going away from the procedure?

I am not questioning on why that is right and this is worng, but, i feel what is good for the goose should be good for the gander what say?

[Former Member]

oops, don't know what happened to the formatting!

No wrath there, hopefully an idea about what auditors look for and why etc.

Swapping between org levels & field levels is a bit different because you are using standard SAP behaviours to enforce consistency. Org levels are there to ensure that all values of a certain field are the same, as maintained in the org level popup. If you have a field where you want that, then with a few exceptions, you can promote it to org level to do that. If you don't want an org level, then you can demote it again to give yourself the granularity you need. By using this technique, you avoid having the same field being treated in a different way depending on the role.

Documenting your exceptions is a good way of mitigating the risk if you don't want to avoid it in this case. If it's in somewhere like the role long text field then it should be pretty obvious.

[Former Member]

I only mentioned SOX compliance because if the org.field value in the authorization were infact $xxx, then the business process would be paralyzed...

Unless you use the "role merge" feature - but the limits are still the same.

Cheers,

Julius

[Former Member]

I wonder whether the original OP is still following this thread...?

Anyway....

> we have a set up where for all inter-company sales, data on sales, logistics, finance is shared amongst companies in all the countries. so in principle we have a central company code, central sales organization, plants owned by the central company and customers and vendors linked to the central company.

Perhaps what you want to do is distinguish between an ABAP transactional system (ERP) and reporting system (BI/BW(BO)?

In that case you need to choose the transactions carefully and the S_A* (ABAP Information System) namerange in particular where it does not conflict with your (navigation) requirements.

You might also want to re-use those role assignments and their org. levels?

Returning to the original question.... => account type as org.level. Sounds like a BW aspect to the question if you ask me.

Cheers,

Julius

[Former Member]

This message was moderated.