Showing results for 
Search instead for 
Did you mean: 

customer hierarchies

Former Member
0 Kudos

dear sap gurus

i want to know in what scenarios customer hierarchies is used . please explain with an example and step by step configuration . thanks in advance

my mail id is

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

This message was moderated.

Answers (1)

Answers (1)

Former Member
0 Kudos

Hey Check this!

Customer hierarchies are used when a customer has a complex chain or organizational structure in which all or some of the parts of this structure will benefit from an agreement made for the customer’s company as a whole. For example, a large customer may have dependent offices, each responsible for their own purchasing, and as individuals, they would not benefit from a global pricing scheme. However, as part of a customer’s hierarchy, they would still benefit from

being associated with the larger parent company. Before setting out and maintaining a customer hierarchy, one needs to determine what the requirement for the hierarchy is. If the requirement is a report, such as reporting bookings or

billings for global customers within a hierarchy, this can be done using a standard reporting hierarchy within the sales information system, Should the

desire be merely to offer prices according to a specific group, one could think about using a customer group on the customer master record, rather than a customer hierarchy.

If, on the other hand, one wants to have a customer hierarchy in order to offer special price agreements or rebates across a customer’s organization on a global level, which may not be covered by a standard grouping, this can be covered by using the customer hierarchy. The customer hierarchy integrates and relies on the partner determination in conjunction with the customer hierarchy settings in order to promote the linking between the customers. The partner determination causes the customer hierarchy to be represented in the sales document. The

customer hierarchy is a hierarchical organizational structure that consists of higher and lower level nodes. Each node is assigned within the structure to form a graphical diagram of the customer’s organization.

A node is represented by an account group. A node can be a customer, such as a sold-to party, thus account group 0001. A node could also be a platform or merely an organizational department; thus, we have account group 0012. A customer hierarchy can only have a maximum of 26 hierarchy levels. One creates a customer hierarchy by first defining the hierarchy type. Menu Path

The menu path here is IMG, Sales and distribution, Master data, Business partners, Customers, Customer hierarchy, Define hierarchy types. Transaction Code OVH1.

For e.g.we have a customer hierarchy type A. This is assigned to the partner function1A, which is the highest node of the partner represented in the hierarchy. There should not be a need for you to create more than one hierarchy type, as you can only assign one hierarchy type per sales document type, The only time you may need a new hierarchy type is when one uses a different hierarchy for different business transactions.

One can now proceed to create the associated partner determinations for customer hierarchies. Creating the associated partner determinations for customer hierarchies can be done by going to IMG, Sales and distribution, Master data, Business partners, Customers, Customer hierarchy, Set partner determination for hierarchy categories. Transaction Code VOPA.

One can assign partner functions up to 26 levels, from 1A through to 1Z. . It is advisable to set the partner function as not changeable and one also needs to

maintain the source as a B, representing a customer hierarchy. This should be carried out for the sales document header and the billing document header, as one may need the hierarchy to be represented in both document types.

Be careful also to maintain enough partner determination levels as are needed to represent the customer’s structure. For example, let’s say the customer’s company had seven levels in the hierarchy, and we only maintained five levels in the partner determination. The system would only copy data relevant to the five maintained levels into the sales document, and thus would only search for condition records up to the five levels of partners. After the partner determination has been maintained, one needs to maintain the association between the higher and lower level customer account groups. As we know, the hierarchy is formed by a linking of account groups, and we need to maintain what account groups are to be linked Menu Path IMG, Sales and distribution, Master data, Business partners, Customers, Customer hierarchy, Assign account groups.

Transaction Code OVH2.

Here one assigns which account group can be assigned to a higher level account group, per the customer hierarchy type. For example, we can see for hierarchy type A that a sold-to party (0001) can be assigned to another sold-to party (0001), while a sold-to party (0001) can also be assigned to a payer (0003) and a hierarchy node (0012). Further down the table, we see that a hierarchy node (0012) can also be assigned to a sold-to party. This is logically assigning account groups, but if we do not introduce some form of organizational definition, the hierarchy could easily run out of control, especially because the system would not have a definitive organizational path to follow for condition records.Thus, one needs to assign lower level sales areas to higher level sales areas.

Menu Path Assigning lower level sales areas to higher level sales areas is done through IMG, Sales and distribution, Master data, Business partners, Customers, Customer hierarchy, Assign sales areas. Transaction Code OVH3.

Now that all the master data is maintained, other than the creation of the actual hierarchy itself, one needs to assign the hierarchy type to the actual sales document type. Menu Path IMG, Sales and distribution, Master data, Business partners, Customers, Customer hierarchy, Assign hierarchy type for pricing by sales document type. Transaction Code OVH4]. This simple assignment of the hierarchy type, such as A to a sales document type OR (or TA ) means that you cannot have more than one hierarchy type per sales document, but you can have more than one customer hierarchy within the hierarchy type.

The only step to be carried out is the creation of the hierarchy to match that of the customer.Let’s use the example that our customer International is a global account with branches represented in Africa, the Americas, Europe, Asia, and Australia. Each branch in these areas is further broken down into a national office and a subsequent regional office. Due to the size of the customer, we offer all 的nternational regional offices across the globe the same pricing discount of 10 percent off all our products. This would be represented in a hierarchy. Menu Path

To create this hierarchy, go to Logistics, Sales and distribution, Master data, Business partners, Customer hierarchy, Change. Transaction Code

VDH1. Do not forget to create the customer hierarchy nodes in the same way

that you would create all customer master records either using [VD01] with the account group 0012 or using the path. Got to Logistics, Sales and distribution, Master data, Business partners, Hierarchy nodes, Create transaction code V-12.

Also do not forget to indicate the customers or nodes as relevant for customer hierarchy-specific pricing and/or rebates. This is done by setting the indicators on the billing screen of the customer master .

following nodes and customers can be created:

Customer: 10011—Munich Regional office of Account group 0001

International Node: 10051—Germany–National office Account group 0012

Node: 10052—Europe Account group 0012

Node: 10054—Africa Account group 0012

Node: 10055—Americas Account group 0012

Node: 10056—Asia Account group 0012

Node: 10053—International—Global account Account group 0012

On creation of the hierarchy node using transaction code VDH1, one must select the Create assignment button and then enter the higher level and the assigned lower level node.

When creating a sales order, one can clearly see the customer hierarchy in the partner’s overview,

Sales document If you do not initially see the hierarchy, note the four buttons at the bottom of the display, and Click Select All Partners

This concludes the determination of the customer hierarchy. Its usefulness remains in that it can be used in conjunction with the condition technique to offer discounts, surcharges, or special pricing. Do not forget that if the sole purpose of your customer hierarchy is to report bookings or billings in a hierarchical form, this can be done by using the standard logistics information systems (LIS) hierarchies