Like many “techy” folks….developers….coders….what have you…my experience with Organizational Management (OM) configuration was limited at best in my early ESS/MSS and “HR ABAPper” (as I hated it to be called!) days. In most all cases, I came in after the fact once the “functional” person(s) had set up the “org structure” and all the nice and neat configuration was in place. The most I had to do was figure out the whole “relations” thing….like who reported to who…what contained what…what position managed the org….and of course, coming to know what SAP means by “chief” (haha). But that was years past and I got a pretty good handle on it. You get pretty handy at coming to know and use the more common standard SAP functions to read OM infotypes and relations, and you eventually might even get bold enough just to start going straight to the infotypes themselves and doing your own selects. Once you get the “relations” (HRP1001) dance steps down, it is pretty easy to “bend OM to your will” via coding. But a recent project reminded my of another OM lesson learned a while back…..INHERITANCE!

Imagine if you had a very large organizational structure…..something that might resemble a very large, well groomed tree on it’s best day, or a plate of old spaghetti on it’s worst. Having to assign and keep in synch every detail on every org unit (not to mention the positions in each org unit as well) would be quite the unenviable task (or full time job haha). That would mean that anytime we created new org units or positions under “parent” org unit, we would have to also go through the steps to insure we assigned all their additional information (Company code, cost center, etc). What if something changed on the “parent” org unit and we forgot to update all the positions or other org units under it? If there is anything I have learned from watching countless the late night infomercials however….”There’s got to be a better way!”

The Basics of Inheritance

Although I had seen and messed with OM inheritance a bit in the past, I had never seen it utilized to such an extent as my recent project. With HCM Processes & Forms OM related processes, we are often presenting “old”/current and “new”/updated data for things like jobs, positions and org units….standard OM objects. Therefore, when trying to “read” the “current” values for an object via our own generic services/operations, we might find it odd to not have a HRP1008 entry….unless we realize of course, that we are seeing inheritance firsthand. But what is inheritance in OM and how does it work?

Let us take a normal example as shown here given that our infotype 1001 relations layout the following:

As you can see, if we want to find the “personnel area”(PERSA) or “personnel subarea”(BTRTL) assignment of position 90003333, we simply pull it’s related infotype 1008 (table HRP1008) record for the same time period. The same can be said for the org unit 60227333 as well. For position 90003333, the personnel area would be “US02”. Usually, HRP1008 will give us all of our “account assignment” information in one convenient place:

But what about this example:

Our position 90003333 has no infotype 1008 record for this time period. But how can that be? It is because it is actually inheriting it from org unit 60227333:

So our personnel area is “US01” for the position 90003333 as well.

Let’s take it even a step further. What about a more complicated example?

Here, we can see that our inheritance is actually working its way up a few levels to the “parent”. Org Unit 60227333 actually inherits from it’s “parent” Org Unit 50009211.

We can actually “inherit” many values from a “parent” org unit. These include:

• Controlling Area
• Business Area
• Cost Center
• Company Code
• Personnel Area / Personnel Subarea

For any object, we can easily look at transaction PPOME and tell right away if our object is inheriting values and which ones. You will see something like this:

This example tells us that Cost Center, Company Code, Personnel Area and Personnel Subarea is inherited. We could also look for an infotype 1008 record for this which we would not find (another indicator of inheritance in action as mentioned earlier).

Keep in mind, at any point, we can also “turn off” inheritance”. That is, we simply click the “inheritance” icon to stop inheritance (if we have not set the auto-inherit for company code/controlling area flags as you will see later in this document)…

…and this allows us to assign the value(s) directly (which might in turn create a infotype 1008 record for us). When we “turn off” inheritance, the related field(s) suddenly becomes open for direct input.

But what allows us to “inherit” at all? Surely there is some setting somewhere….some kind of….hmmm….what do we call this in SAP lingo?…..ah yes…some “configuration” (haha).

Table T77S0

The first thing to understand is table T77S0 (yes, that is a zero on the end….there is another similarly named table with an “O” on the end but that is not what we want! Great job with the naming there, SAP! haha)

T77SO is a good table to know….but just not the right table for right now:

But this is the table we really want…T77S0:

Table T77S0 is where all the “magic” happens. More to the point, it is our configuration table that controls OM inheritance.

    The important fields for us are as follows:

• INHIC : If this value is set to “X”, this means that positions with inherit “Company Code” from their related Org Unit (ie.Obligatory/Mandatory inheritance of company code is active. Also keep in mind, this means the assignment is forced and not an option to change.).  If this value is not “X”, it means that we can assign positions to different company codes than their related Org Unit. This is typically not set to “X” unless we want all positions to have the same company code (smaller organization maybe?).
• INHIH : Same idea as INHIC but for “Controlling Area”. If set to “X”, it is assigned/inherited from the related Org Unit. If not, then a position can be assigned a different controlling area as the one assigned to its related Org Unit.
• INHS : This is typically our most important field to read as it is more flexible in its inheritance (it says that inheritance is “possible” but not mandatory as the other switches do). If this field is assigned the value of “X”, then our position can inherit any one or more of many Account Assignment features (Controlling Area, Company Code, Business Area and/or Personnel Area/Subarea).

(* keep in mind that although the documentation refers to “position” for inherited values, the same applies to “child” Org Units as well.)

In the HCM Processes & Forms world, this becomes particularly important especially in our processes such as “Position Move” or “Org Unit Move” where we might break this “parent-child” relation and thus the inheritance that might exist. But how do we write our own code to detect/read inheritance and then act accordingly? Well, that takes us to “part 2” of this discussion as this one has run on quite longer than anticipated.