{"id":496,"date":"2011-10-30T04:42:26","date_gmt":"2011-10-30T04:42:26","guid":{"rendered":"http:\/\/sapsecurityanalyst.com\/WP\/?page_id=496"},"modified":"2015-05-03T09:19:07","modified_gmt":"2015-05-03T09:19:07","slug":"organizational-levels","status":"publish","type":"page","link":"https:\/\/sapsecurityanalyst.com\/WP\/general-disclaimer\/organizational-levels\/","title":{"rendered":"Organizational levels ( org levels in SAP )"},"content":{"rendered":"<p>&nbsp;<\/p>\n<p><span style=\"color: #0000ff;\"><br \/>\n<span style=\"color: #4c4c4c;\">Organizational level ( org level in SAP ) is a very important field as far as role design is concerned. The basic concept behind having this in role design to have same value across all objects for a given role, unlike any other authorization field which can have different values across different authorization objects.<\/span><\/span><\/p>\n<p>&nbsp;<\/p>\n<p><span style=\"color: #4c4c4c;\"><!--more--><br \/>\nCertain fields which seldom have different values for different authorization objects are used as org level fields. Some of the commonly used org level fields are Company Code, Division, Sales Organization, Plants etc.<\/span><\/p>\n<p>&nbsp;<\/p>\n<p><!--more--><br \/>\n<a href=\"https:\/\/sapsecurityanalyst.com\/WP\/wp-content\/uploads\/2011\/10\/org_level.jpg\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-497\" title=\"org_level\" src=\"https:\/\/sapsecurityanalyst.com\/WP\/wp-content\/uploads\/2011\/10\/org_level.jpg\" alt=\"\" width=\"571\" height=\"271\" srcset=\"https:\/\/sapsecurityanalyst.com\/WP\/wp-content\/uploads\/2011\/10\/org_level.jpg 571w, https:\/\/sapsecurityanalyst.com\/WP\/wp-content\/uploads\/2011\/10\/org_level-300x142.jpg 300w, https:\/\/sapsecurityanalyst.com\/WP\/wp-content\/uploads\/2011\/10\/org_level-290x137.jpg 290w, https:\/\/sapsecurityanalyst.com\/WP\/wp-content\/uploads\/2011\/10\/org_level-150x71.jpg 150w\" sizes=\"(max-width: 571px) 100vw, 571px\" \/><\/a><\/p>\n<p>&nbsp;<\/p>\n<p><span style=\"color: #0000ff;\"><!--more--><br \/>\n<span style=\"color: #4c4c4c;\">As we can see that org level fields can be maintained by &#8220;Organizational levels&#8221; button at the right top of pfcg-maintain authorization screen.<\/span><\/span><\/p>\n<p><span style=\"color: #4c4c4c;\"><br \/>\n<\/span><\/p>\n<p><span style=\"color: #0000ff;\"><span style=\"color: #4c4c4c;\"><!--more--><\/span><br \/>\n<span style=\"color: #4c4c4c;\"> Based on the requirement, other non-org level authorization fields (barring a few exceptions) can also be converted into org level fields. Program<\/span> <strong>PFCG_ORGFIELD_CREATE<\/strong> <span style=\"color: #4c4c4c;\">needs to be executed for this purpose. But this should be done only after thorough analysis because this step may impact several other roles as that authorization field might be present in many roles and once converted to org level, the value will have to be maintained via organizational level button for all those roles.<\/span><\/span><\/p>\n<p><span style=\"color: #0000ff;\"><br \/>\n<\/span><\/p>\n<p><!--more--><br \/>\n<span style=\"color: #4c4c4c;\">Some of the authorization fields which cannot be converted to org level fields are ACTVT (Activity), TCD(Tcode) etc.<\/span><\/p>\n<p><span style=\"color: #4c4c4c;\"><br \/>\n<\/span><\/p>\n<p><span style=\"color: #0000ff;\"><span style=\"color: #4c4c4c;\"><!--more--><\/span><br \/>\n<span style=\"color: #4c4c4c;\"> As we saw that a normal authorization field can be converted to an org level field via program PFCG_ORGFIELD_CREATE. Similarly an org level field can be converted to a non-org level authorization field via program<\/span> <strong>PFCG_ORGFIELD_DELETE<\/strong>.<\/span><\/p>\n<p><span style=\"color: #0000ff;\"><br \/>\n<\/span><!--more--><br \/>\n<span style=\"color: #0000ff;\">Table <strong>AGR_1252<\/strong> <span style=\"color: #4c4c4c;\">maintains roles to org fields values relationship. In this table we can find the org field values that have been maintained for a role.<\/span><\/span><\/p>\n<p><span style=\"color: #0000ff;\"><br \/>\n<\/span><\/p>\n<p><!--more--><br \/>\n<span style=\"color: #0000ff;\">Table <strong>AGR_1251<\/strong> <span style=\"color: #4c4c4c;\">maintains roles to auth fields values relationship. In this table, we can find the auth field values that have been maintained for roles. One point to notice here is that for fields which are org level fields, we do not get any value in this table, but some alphabets beginning with <strong>$<\/strong>, e.g. $WERKS which means plant.<\/span><\/span><\/p>\n<p><span style=\"color: #4c4c4c;\"><br \/>\n<!--more--><\/span><br \/>\n<span style=\"color: #4c4c4c;\"><br \/>\nEarlier in this topic, we had stated that org levels are important because in some roles we need to have same values for some authorization fields across all authorization objects. So instead of maintaining this value individually in all objects, we maintain it only once at the top by clicking on &#8220;Organizational levels&#8221; button. When a field is defined as org level field, it acts as an org level field for all the roles where it is used.<br \/>\n<\/span><br \/>\n<span style=\"color: #4c4c4c;\"> <!--more--><\/span><\/p>\n<p><span style=\"color: #0000ff;\"><br \/>\n<span style=\"color: #4c4c4c;\">Now let us assume a scenario where there is an org level field called plant ($WERKS). For all authorization objects where this field is being checked, we want to maintain the same value, except for an object (say XYZ) where we do not want this due to some security requirement. Suppose we want plant values 100 and 200 for all the objects, but for object XYZ we want to maintain only value 100.<\/span> <\/span><\/p>\n<p><span style=\"color: #0000ff;\"><strong>Can this be done?<\/strong> <\/span><\/p>\n<p><span style=\"color: #0000ff;\"><span style=\"color: #4c4c4c;\">Because once we maintain plant values 100 and 200 at the top using organizational levels button, object XYZ will also get value 100 and 200 for field plant. We can achieve our requirement by applying the concept of<\/span> <strong>org level breaking<\/strong>.<\/span><\/p>\n<p><span style=\"color: #0000ff;\"><br \/>\n<\/span><!--more--><br \/>\n<span style=\"color: #0000ff;\"><br \/>\n<span style=\"color: #4c4c4c;\">To apply only value 100 for object XYZ, we need to manually change this field.<\/span><\/span><\/p>\n<p><script type=\"text\/javascript\">\/\/ < ![CDATA[\ngoogle_ad_client = \"ca-pub-1241348474673689\";\n\/* All content above *\/\ngoogle_ad_slot = \"3293572617\";\ngoogle_ad_width = 468;\ngoogle_ad_height = 15;\n\/\/ ]]><\/script><br \/>\n<script src=\"http:\/\/pagead2.googlesyndication.com\/pagead\/show_ads.js\" type=\"text\/javascript\">\/\/ < ![CDATA[\n\n\n\/\/ ]]><\/script><br \/>\n<span style=\"color: #0000ff;\"><br \/>\n<\/span><!--more--><br \/>\n<span style=\"color: #4c4c4c;\">There is a bit of caution involved here!<\/span><\/p>\n<p><span style=\"color: #4c4c4c;\">If we are dealing with master-derived roles, this will impact all the derived roles. Also any change in the org level values using organizational field button does not change value for this object in this role in future. Hence it should only be done when we are left with no other option. In fact it is not a good practice to break org levels, but in some unavoidable situations we are forced to do this.<\/span><\/p>\n<p><span style=\"color: #0000ff;\"><br \/>\n<\/span><!--more--><br \/>\n<span style=\"color: #4c4c4c;\">As soon as we click the change button to maintain org field manually, we get the following information message:<\/span><\/p>\n<p><span style=\"color: #0000ff;\"><br \/>\n<\/span><\/p>\n<p><!--more--><br \/>\n<a href=\"https:\/\/sapsecurityanalyst.com\/WP\/wp-content\/uploads\/2011\/10\/org_level_break.jpg\"><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-507\" title=\"org_level_break\" src=\"https:\/\/sapsecurityanalyst.com\/WP\/wp-content\/uploads\/2011\/10\/org_level_break.jpg\" alt=\"\" width=\"567\" height=\"420\" srcset=\"https:\/\/sapsecurityanalyst.com\/WP\/wp-content\/uploads\/2011\/10\/org_level_break.jpg 567w, https:\/\/sapsecurityanalyst.com\/WP\/wp-content\/uploads\/2011\/10\/org_level_break-300x222.jpg 300w, https:\/\/sapsecurityanalyst.com\/WP\/wp-content\/uploads\/2011\/10\/org_level_break-290x214.jpg 290w, https:\/\/sapsecurityanalyst.com\/WP\/wp-content\/uploads\/2011\/10\/org_level_break-150x111.jpg 150w\" sizes=\"(max-width: 567px) 100vw, 567px\" \/><\/a><\/p>\n<p><a href=\"https:\/\/sapsecurityanalyst.com\/WP\/wp-content\/uploads\/2011\/10\/org_level_break.jpg\"><br \/>\n<\/a><!--more--><br \/>\n<span style=\"color: #0000ff;\"><br \/>\n<span style=\"color: #4c4c4c;\">As we discussed above that table AGR_1251 stores org level values with $ and some character (as $WERKS for plant values). But as soon as we break the org level for any object, AGR_1251 starts storing the &#8220;broken&#8221; numerical value which has been stored for that particular object. This happens because the relationship for that field in the object breaks with organizational level.<\/span><\/span><\/p>\n<p><span style=\"color: #0000ff;\"><br \/>\n<\/span><!--more--><br \/>\n<span style=\"color: #0000ff;\"><span style=\"color: #4c4c4c;\">So table AGR_1251 can act as a<\/span> &#8220;<strong>broken org level finder<\/strong>&#8221; <span style=\"color: #4c4c4c;\">in case we need to know in what all roles which org level fields have been broken. For this we need to put a filter for all the org level fields and check if any field is having<\/span> non-&#8220;$&#8221; value.<\/span><\/p>\n<p>&nbsp;<\/p>\n<p><!--more--><\/p>\n<p>&nbsp;<\/p>\n","protected":false},"excerpt":{"rendered":"<p>&nbsp; Organizational level ( org level in SAP ) is a very important field as far as role design is concerned. The basic concept behind having this in role design to have same value across all objects for a given role, unlike any other authorization&nbsp;<a class=\"read-more\" href=\"https:\/\/sapsecurityanalyst.com\/WP\/general-disclaimer\/organizational-levels\/\">&hellip;<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"parent":38,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":{"footnotes":""},"_links":{"self":[{"href":"https:\/\/sapsecurityanalyst.com\/WP\/wp-json\/wp\/v2\/pages\/496"}],"collection":[{"href":"https:\/\/sapsecurityanalyst.com\/WP\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"https:\/\/sapsecurityanalyst.com\/WP\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"https:\/\/sapsecurityanalyst.com\/WP\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/sapsecurityanalyst.com\/WP\/wp-json\/wp\/v2\/comments?post=496"}],"version-history":[{"count":26,"href":"https:\/\/sapsecurityanalyst.com\/WP\/wp-json\/wp\/v2\/pages\/496\/revisions"}],"predecessor-version":[{"id":2136,"href":"https:\/\/sapsecurityanalyst.com\/WP\/wp-json\/wp\/v2\/pages\/496\/revisions\/2136"}],"up":[{"embeddable":true,"href":"https:\/\/sapsecurityanalyst.com\/WP\/wp-json\/wp\/v2\/pages\/38"}],"wp:attachment":[{"href":"https:\/\/sapsecurityanalyst.com\/WP\/wp-json\/wp\/v2\/media?parent=496"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}