SAP SRM Org structure- Concepts
https://www.linkedin.com/pulse/sap-srm-org-structure-concepts-sujit-deshmukh?trk=hp-feed-article-title-like
Concepts of SRM Organization
Structure
Applies to: SAP SRM 7.0 SRM 5.0
Summary: Organization structure is one of
the critical application component of SAP SRM System. This is the controlling
point for ensuring users are able to create and process documents they are
supposed to do in their day to
day business. This document describes features, concepts and details of SRM
Organization Structure.
Author: Sujit Deshmukh, Certified SAP MM,
and SAP SRM consultant
Company: Atos India Pvt. Limited
Created on: 14 September 2012
Goals of this Document
Discuss and Describe the Benefits of
Organizational Management in SRM
Discuss the Components of Organizational Plan
Importance and Role of Attributes in Org
Structure
Various Tools available for maintaining
Organizational Structure
Organizational Management
in SRM
Organizational Management in SRM
is a function of the following:
Depicting Structure of various Companies -in terms of their reporting
Structure
Depicting various Periods In terms of validity of
various positions and departments
Implementing or Using other components (e.g.
Workflow) - In terms of finding the correct approval
hierarchy for documents created on SRM
Planning Organizational Changes - In terms of planning the
proposed changes in the organization hierarchy and implementing it in the
enterprise
Organizational Structure in
SRM
SAP SRM heavily relies on
Organization Structure Hierarchy for SRM users to perform their day to day
operations. There are three types of hierarchies maintained in SRM:
SRM Organization Hierarchy
Vendor Organization Hierarchy
Purchasing Organization Hierarchy
Out of the above three
structures, Vendor Organization is maintained as a part of replication of
Business Partners from ECC to SRM. Purchasing Organization Hierarchy is
maintained in SRM manually. This is done on the lines of Purchasing
Organization—Purchase Group reporting structure in backend ECC. We can also
create manual purchasing organization hierarchy LOCAL in SRM
There are two ways we can
maintain SRM Organization Structure:
Maintain the SRM Organization Structure Manually
SAP HR hosts an Enterprise’s Organization
Hierarchy with full reporting structure. This hierarchy can be replicated
from HR to SRM via ALE Distribution. This avoids duplicate data
maintenance for maintain the organization hierarchy in HR as well as SRM.
Organization Structure
Business Workflow uses
organization structure to determine which agents are responsible for approving
documents in most of the cases. Org structure is used by self service
transaction for creation of user master records. Purchase Organizations and
Purchasing Groups are determined from org structure while creating Shopping
Carts. Attributes of the users which are required for creating application
documents in SRM are set up in Org structure.
Organization Structure: The hierarchy in which
various departments of an enterprise are arranged according to the tasks
functions assigned to them
Root Org Unit: This is the highest
Organization Unit at the highest level of an Organization Structure. This
org unit is needed to be created first of all while setting up the
enterprise structure for an enterprise.
Organization Unit: Organization Units are the
objects that make up organizational plans. Org Unit represent any type of
organizational entity found in any enterprise for example
subsidiaries, divisions, departments, or special project teams. The
Organizational units are represented by Object type O.
Users : Users are placed in various
org units through their assignment to Positions. Positions will be discussed
later in this Unit. Users are represented by object type US.
Purchasing Structure
Purchasing Structure is the
hierarchy in which various purchasing departments and groups of an enterprise
are arranged according to the tasks functions assigned to them
Purchase Organizations in SRM
Function tab in Org structure represent the
function of that org unit in the system. The department may be serving as
a Company, Purchase Organization or a Purchasing Group. We need to
maintain the function of org unit appropriately.
Just like Highest Level Org Unit in Org
structure, Purchasing structure has a Highest level org unit
Each Purchasing Organization in the Enterprise is
represented by an Org Unit in the Organization structure.
Users (professional purchasers) are assigned to
the Org units , If the purchasing organization is local.
In case when the purchasing organization is in
the ERP back end, the organizational units created in EBP are used only
for passing the necessary values to Back End system. We just assign
purchase groups to the org units representing Purchase Organizations. We
don’t assign any user to this org unit in this case.
Purchase Groups in SRM
Org Units for Purchase groups are created when we
have purchase organizations in Backend.
Product and Organizational responsibilities for
purchase groups are maintained in the Responsibilities tab.
Product Responsibilities are Optional. If your
procurement department is organized by product category, you should assign
all your product categories to purchasing groups using this attribute. If
you fail to do so, all the orders relating to unassigned product
categories will be assigned by the system to the same purchasing group.
This only makes sense if you intend a particular purchasing group to
assume the role of dispatcher
Organizational responsibility is Mandatory. You
can use the input help to select the departments or groups for which the
purchasing group is responsible
Responsibility Tab – is used only for maintaining
the Attributes of Purchase Group. Product Responsibility and Organizational
Responsibilities are maintained for purchase groups in this tab.
Finding Purchasing Data in SRM
Step 1: User Creates a Shopping cart
for a product Category E12345
Step 2: System picks up User’s department
from organization structure. Object id of the department is 50000614
Step 3: This department is available in
the organizational responsibilities of the Purchasing Group (one or more) in
the org structure. If the department of the user is in the organizational
responsibilities of more than one purchase groups, system will pick both the
purchase groups.
Step 4: Then the system will determine
for which product categories the respective purchase organizations are
responsible for. From the purchase group, purchase organization is derived by
the system from org structure.
Vendor Organization
Structure
We no longer use PPOMA_BBP to enter external
vendor organizational units and vendors. Instead they are represented in
PPOMV_BBP, where vendor groups (VGs) are entered as organizational objects
(including the vendors that belong to the groups).
The highest level org unit shows the Root for
External Vendors which generally represent the Vendor Groups from one
source system.
Next level shows the Vendor Group under that top
node
Under Vendor Group, individual vendors are
maintained. Whenever Vendors are created or replicated from R/3, those
vendors will get assigned to the vendor group mentioned here.
Attributes can be maintained at the top level ,
which get inherited in the Vendor Groups and individual Vendors below
in the Vendor Org Model
Notes on Vendor Org Structure for
Upgrade of SRM 4.0 and older versions to SRM 7.0
Vendors can not be represented by an
organizational unit in the org structure. So the employees of Vendors (if
have account in SRM) will no longer report to any organizational unit in
SRM any more.
Vendors are now grouped into new organizational
objects called vendor groups (VGs). It is not necessary to have one VG per
vendor, as it used to be in the case for organizational units. System
groups the vendors with identical attributes into vendor groups. Positions
under the vendor org units will no longer be required.
Report BBP_XPRA_ORGEH_TO_VENDOR_GROUP is
used to migrate the vendors from old org structure to the Vendor Org
structure at the time of Cutover during the Upgrade of SRM 4.0 or older
versions. This report , if gets cancelled before completion, can be
rescheduled again with same variant and system will pick up the conversion
from the point it was left. Report BBP_XPRA_ORGEH_TO_VENDOR_GROUP copies
only the standard attributes for external business partners: BUK, CAT, CUR, TOG, VENDOR_ACS, and VENDOR_SYS
Object Types in
Organization Structure
Each object in Org structure has
got a Object type and Object id assigned to it. The Object Type and Object id
make each object Unique in the Org Structure. Following are the object types in
SRM Organizational Structure:
Org Unit: Org Unit Object type is
always represented by ―O‖.
Org Units describe various units of an enterprise
which are structured according to their tasks and functions. Together
several organizational units and their hierarchical relationships form an
Organizational Structure.
Position: Position Object type is
always represented by ―S. Positions are concrete and can be occupied by
holders at any company. Each Position is generally occupied by one
employee but multiple assignments are also possible.
Positions can be 100% filled, partially filled or
vacant.
One position can be shared by several employees,
each working less than full time. For example, two employees can hold 60%
and 40% of one position
Central Person: Central Persons are the
objects which hold positions in SRM Org structure. CP Object type is
always represented by ―CP.
The SU01 users are technically of no use in EBP
unless they are incorporated into the Org structure. Each user id in Org
structure:
Belong to a certain Org Unit
Definitely has a Position created for it.
Has a Business Partner Id attached to it via
Central Person Record
Has a SU01 id
When a Object is created, an Object Id must be
assigned to it.
An object ID must be assigned for every object.
The object is identified by a combination of plan version, object type,
and object ID.
Object IDs are numeric. They cannot contain any
letters.
We do not need to use the object ID to find
objects because you can easily find objects using search terms, parts
of it, and certain characteristics. SAP recommends that you use internal
number assignment.
Note: The name of the object is not part of the
object key. This allows the same object number to be maintained in several
languages.
Object Validity Period
Each Object in Organization
Structure has got a Validity Period assigned to it. Functions of Validity
Periods are as follows:
Validity Periods allows you to define the life
span of an Object
It helps in identifying changes to your
organization while retaining historical data
Allows us to evaluate the organizational
structure on key dates
We must assign a validity period to every Org
Structure record we create. By doing this, we can depict all changes that
take place in the company, which provides us with a dynamic view of our
enterprise.
The validity period enables us to evaluate key
data or periods in the past, present or future.
The validity of an object’s relationships and
attributes can exist only within the life span of the object . If an
object is delimited, all the object’s relationships and characteristics
are also automatically delimited. Related objects are not changed.
However, a relationship is valid only if both objects themselves are
valid.
Object Relationships
Organization Structure is created by creating
relationships between organizational Units. Relationships play a key role
in smooth functioning of applications accessing Organization Structure.
Organization Unit: An Organizational Unit can
have many subordinate organizational units, but only one higher level
organizational Unit. Organizational Units
Reports to another Org unit
Can incorporate another Org Unit
Positions and Org Units: -Positions are related to
organizational units in the org structure. Positions inherit certain
characteristics of the organizational unit such e.g. CoCode, Cost Center
etc.
Belong to an Organizational Unit
An Organizational unit incorporates positions
When a person holds a position, they also inherit
some of the characteristics of the related organizational unit.
Position and Person(CP)
A person is assigned as holder of a position
The position is the object that links persons or
users to the organizational plan.
A position can be held by more than one person or
user and a person can hold more than one position
Note: a one-to-one relation between a Position and a
Person is the ideal
Position and User
Relationship between Position (S) and User (US)
is derived from two relationships S-CP and CP-US.
Organizational Unit and Chief Position
A position manages a Organizational Unit
Each Org Unit is ideally managed by a chief
position. In the standard system, the relationship "manages" or
"is managed by" is used to indicate that a position is
responsible for managing an organizational unit. If there is no chief
position in an organizational unit, this organizational unit is managed by
chief of higher level Organizational Unit.
Relationships are stored in info
type 1001. In SRM we can find the relationships between various Org Structure
Objects in table H
Notes on Vendor Org Structure for
Upgrade of SRM 4.0 and older versions to SRM 7.0
Vendors can not be represented by an
organizational unit in the org structure. So the employees of Vendors (if
have account in SRM) will no longer report to any organizational unit in
SRM any more.
Vendors are now grouped into new organizational
objects called vendor groups (VGs). It is not necessary to have one VG per
vendor, as it used to be in the case for organizational units. System
groups the vendors with identical attributes into vendor groups. Positions
under the vendor org units will no longer be required.
Report BBP_XPRA_ORGEH_TO_VENDOR_GROUP is
used to migrate the vendors from old org structure to the Vendor Org
structure at the time of Cutover during the Upgrade of SRM 4.0 or older
versions. This report , if gets cancelled before completion, can be
rescheduled again with same variant and system will pick up the conversion
from the point it was left. Report BBP_XPRA_ORGEH_TO_VENDOR_GROUP copies
only the standard attributes for external business partners: BUK, CAT, CUR, TOG, VENDOR_ACS, and VENDOR_SYS
Object Types in Organization
Structure
Each object in Org structure has
got a Object type and Object id assigned to it. The Object Type and Object id
make each object Unique in the Org Structure. Following are the object types in
SRM Organizational Structure:
Org Unit: Org Unit Object type is
always represented by ―O‖.
§ Org Units describe various
units of an enterprise which are structured according to their tasks and
functions. Together several organizational units and their hierarchical
relationships form an Organizational Structure.
§ Position: Position
Object type is always represented by ―S‖. Positions are concrete and can be
occupied by holders at any company. Each Position is generally occupied by one
employee but multiple assignments are also possible.
§ Positions can be 100%
filled, partially filled or vacant.
§ One position can be shared
by several employees, each working less than full time. For example, two
employees can hold 60% and 40% of one position
§ Central Person:
Central Persons are the objects which hold positions in SRM Org structure. CP
Object type is always represented by ―CP‖.
§ The SU01 users are
technically of no use in EBP unless they are incorporated into the Org
structure. Each user id in Org structure:
§ Belong to a certain Org
Unit
§ Definitely has a Position
created for it.
§ Has a Business Partner Id
attached to it via Central Person Record
§ Has a SU01 id
§ When a Object is
created, an Object Id must be assigned to it.
§ An object ID must be assigned
for every object. The object is identified by a combination of plan version,
object type, and object ID.
§ Object IDs are numeric.
They cannot contain any letters.
§ We do not need to use the
object ID to find objects because you can easily find objects using search
terms, parts of it, and certain characteristics. SAP recommends that you use
internal number assignment.
§ Note: The name of
the object is not part of the object key. This allows the same object number to
be maintained in several languages.
Object Validity Period
Each Object in Organization
Structure has got a Validity Period assigned to it. Functions of Validity
Periods are as follows:
§ Validity Periods allows
you to define the life span of an Object
§ It helps in identifying changes
to your organization while retaining historical data
§ Allows us to evaluate the
organizational structure on key dates
§ We must assign a validity
period to every Org Structure record we create. By doing this, we can depict
all changes that take place in the company, which provides us with a dynamic
view of our enterprise.
§ The validity period
enables us to evaluate key data or periods in the past, present or future.
§ The validity of an
object’s relationships and attributes can exist only within the life span of
the object . If an object is delimited, all the object’s relationships and
characteristics are also automatically delimited. Related objects are not
changed. However, a relationship is valid only if both objects themselves are
valid.
Object Relationships
Organization Structure is created by creating
relationships between organizational Units. Relationships play a key role
in smooth functioning of applications accessing Organization Structure.
§ Organization Unit: An
Organizational Unit can have many subordinate organizational units, but only
one higher level organizational Unit. Organizational Units
§ Reports to another Org
unit
§ Can incorporate another
Org Unit
§ Positions and Org
Units: -Positions are related to organizational units in the org
structure. Positions inherit certain characteristics of the organizational
unit such e.g. CoCode, Cost Center etc.
§ Belong to an
Organizational Unit
§ An Organizational unit
incorporates positions
§ When a person holds a
position, they also inherit some of the characteristics of the related
organizational unit.
§ Position and Person(CP)
§ A person is assigned as
holder of a position
§ The position is the object
that links persons or users to the organizational plan.
§ A position can be held by
more than one person or user and a person can hold more than one position
§ Note: a one-to-one
relation between a Position and a Person is the ideal
§ Position and User
§ Relationship between
Position (S) and User (US) is derived from two relationships S-CP and CP-US.
§ Organizational Unit and
Chief Position
§ A position manages a
Organizational Unit
§ Each Org Unit is ideally
managed by a chief position. In the standard system, the relationship
"manages" or "is managed by" is used to indicate that a position
is responsible for managing an organizational unit. If there is no chief
position in an organizational unit, this organizational unit is managed by
chief of higher level Organizational Unit.
Relationships are stored in info
type 1001. In SRM we can find the relationships between various Org Structure
Objects in table HRP1001
Attributes and Attribute
Inheritance
A user is of no use if he/she is
not integrated into the Organization Structure. In order for a user to perform
the activities defined for him as per his role, he will need a minimum set of
attributes defined for him/her in the organization structure. Role in SU01 id
of a user provide him access to carry out different transactions whereas
Attributes allows him to carry out those transactions
§ Attributes can either be
defined for a position or an organizational Unit
§ Who can Change User
Attributes
§ User can change their own
attributes i.e. attributes of its position (depending on their authorization),
using the web application for changing Attributes. This is done under Settings
Link in SRM Home Page.
§ Managers can change the
attributes defined for their organizational unit (s) or for users in their
organizational unit (s) using the Web application Changing Attributes
§ System Administrator
Extended Attributes
§ Product Category
§ In the product categories
section of Extended we can maintain Product categories which can be used by the
user while Shopping. If there is no product category here, user will not be
able to select any product category while creating SCs
§ Locations
§ In Locations section of
Extended we can maintain Locations which are synonymous with plants in R/3. The
values maintained here will be available for the user to select these values as
location while creating shopping carts.
§ Storage Locations
§ In Storage Location
Section of Extended we can maintain Storage Locations which are synonymous with
Storage locations in R/3. The values maintained here will be available for the
user to select these values as storage location while creating shopping carts.
The value is maintained here if Direct Procurement is used.
§ PO Value Limits
§ Value limits put here are
used in approval workflow defined by value limits for Budget and spending
limits of the person.
Attribute Inheritance
§ Attributes are maintained
for each scenario in transaction SM30. Inheritance can be activated for each
attribute in this table.
§ These attributes will work
in organization structure as per its characteristics defined in this table.
§ Caution: Do not
change any delivered settings without reason, for example, an SAP Note.
However, you can maintain your own attributes in this table and change the
inheritance logic for common attributes, depending on your company’s
requirements.
§ Characteristics of an
Attribute
§ An attribute is generally
inherited by all organizational units below the organizational unit where it
was defined.
§ Attributes can be defined
at any level of the organizational structure. In order to avoid redundant work,
maintain attributes at highest possible level.
§ Attributes can be defined
as visible or changeable for every user in customizing
§ If there are several
values for one attribute, you can select one as a default. Values for
attributes can be excluded also.
Common Attributes
Business Partners
§ The business partners
in EBP are based on the role based concept: An internal or external
business partner is created in SRM for every person, organization, or group of
people who could be involved in a business transaction.
§ Contact persons as well as
Organizations have a Business Partner Record associated with it
§ There can be a number of
BP Roles can be defined within a business partner
§ One BP can have several
roles
§ Business partners
aggregate the master data of a person, organization, or group of people in the
organization.
§ Business Partner
Relationships
§ Two business partners have
relationships with each other.
§ Few relationships are
time-dependent
§ Attributes are connected
to relationships for example
§ Contact person:
Relationship among an organization as a BP and a person as a BP.
§ Company participation:
relationship among two BPs that are organizations
Note: Partner function is used to
assign corresponding Business Partner to the relevant Documents of Business
Transactions
§ Internal Business
Partners
§ Requestor
§ Purchasing Company
§ Goods Recipient
§ Location
§ Ship to Address
§ Invoicing Recipient
§ Employee
§ External Business
Partners
§ Bidder
§ Vendor
§ Preferred Vendor\
VENDOR_ACS
System where Accounting for
Vendor has to be checked
Yes
Business Partners
§ The business partners
in EBP are based on the role based concept: An internal or external
business partner is created in SRM for every person, organization, or group of
people who could be involved in a business transaction.
§ Contact persons as well as
Organizations have a Business Partner Record associated with it
§ There can be a number of
BP Roles can be defined within a business partner
§ One BP can have several
roles
§ Business partners
aggregate the master data of a person, organization, or group of people in the
organization.
§ Business Partner
Relationships
§ Two business partners have
relationships with each other.
§ Few relationships are
time-dependent
§ Attributes are connected
to relationships for example
§ Contact person:
Relationship among an organization as a BP and a person as a BP.
§ Company participation:
relationship among two BPs that are organizations
Note: Partner function is used to
assign corresponding Business Partner to the relevant Documents of Business
Transactions
§ Internal Business
Partners
§ Requestor
§ Purchasing Company
§ Goods Recipient
§ Location
§ Ship to Address
§ Invoicing Recipient
§ Employee
§ External Business
Partners
§ Bidder
§ Vendor
§ Preferred Vendor
§ Contact Person
§ Ship From Address
§ Invoicing Party
User Maintenance
An EBP user is an SU01 User plus
Business partner
Position
Central Person
Relations between these Objects
EBP user can be maintained by
Self Service function
Administrator
Manager
Single EBP users can be created by
Self Service creation (Subject to approval)
Administrator Creation
Generic User Creation
Using USERS_GEN Transaction