SAP for Automotive Blogs
Explore blog posts by automotive thought leaders and SAP experts, paving the way for a smoother journey with SAP. Post a blog to share your own expertise.
Showing results for 
Search instead for 
Did you mean: 
Former Member


In the automotive industry, the major players are as below:

  • Ø  OEM
  • Ø  Importer/National Sales Center (NSC)/Distributor/OEM Sales Organization
  • Ø  Dealers
  • Ø  End Customer

The OEM is based out of the countries where the manufacturing plants are present. For a country specific sale, the importer/NSC imports the vehicles from the OEM and then sells them to the dealers, who in turn sell the vehicles to the end customers. This implies there is a multi-level buying group involved in the sale of an automobile. In large countries, there might be a huge number of dealers involved in the sales of vehicles to the end customers. There might be a very big dealer, under whom branches exist, or a logical grouping of dealers under a particular region might exist in that country. This grouping of dealers might have an impact on the sales of the vehicles, pricing of the vehicles or the mode of sales. Hence, a hierarchy in the customer structure exists involving the OEM / NSC / Dealers. In order to achieve this hierarchy, the SAP functionality of ‘Customer Hierarchy’ can be used.

Why Customer Hierarchy

There can be a lot of business reasons for an OEM to opt for customer hierarchy. Few of them are mentioned below:

Ø     Vehicle Sales

o    For an automotive company to get a better idea of the market demand for its products, it is useful if it has a clear demarcation of the market space. For this, it can opt for customer hierarchy where in it can ensure that its dealers operate in hierarchies belonging to different verticals. Through this, it can keep a track of individual node/entity wise demand, ensure better planning and can manage its stock in a better fashion.

o    When operating in markets with huge geographies, in order to have a structured sales format in place, companies can opt for customer hierarchy. This ensures ease of operation for the OEM in huge countries.

o    A company would want to have a clear demarcation of regions in a market (north, south, east, west or area wise) in order to empower the individual regions and ensure they operate as an independent entity for optimal results. This can be achieved through customer hierarchy; where in the head of every node in the hierarchy is responsible entirely for that particular node for better results. This also gives the flexibility of incorporating different sales and pricing strategies for different regions, based on the varying dynamics.

o    A company can opt for a hierarchy structure if it needs to keep a tab on individual regions or nodes in a hierarchy for their targets. Hence, in order to better monitor the sales targets, customer hierarchy can be used.

o    There might be cases where a very big dealer might have branches under him performing the sales functions, which is a common scenario and is applicable to almost all the automotive OEMs’ setup worldwide. In order to map the same in SAP, customer hierarchy can be used.

Ø     Pricing/Discount Handling

o    In a particular market, a company’s pricing might vary based not only on the product line, but also on the region it is selling. This can be handled in the form of discounts. For this, customer hierarchy can be used to ensure that products being sold in one region are priced differently or certain discounts are applicable only for certain regions.

o    An auto company might want certain incentives to apply only to certain dealers (best selling dealers, etc) based on certain criteria. Customer hierarchy can be used to achieve the same.

Ø     Default business partner determination – There might be a requirement for certain automotive OEMs to have default partners for a particular order – say a payer, etc. in order to address the requirement of specific pricing or any other sales related process which is driven by the partner functions. If we assign a partner procedure to a partner function, we can obtain the desired business partner in the orders for each partner function.

Ø     Process specific requirements, like order cancellation, returns, where the customer determination of the vehicle might differ based on the customer hierarchy – In specific cases, there might be requirements that certain processes like order cancellation, returns, etc should determine a specific customer in the hierarchy. This can be achieved by modifying the functional modules in order to determine the desired customer. This can address the need of managing regional stocks effectively and avoid unwanted goods movement between regions, especially in bigger geographies.

Ø     For huge automobile companies, operating in big countries, it is typical to have a grouping of dealers region wise. This will have an impact on their sales and delivery related processes. In order to achieve the same, customer hierarchy can be used.

1.            Customer Hierarchy Creation in SAP

a.            Setting up the basics for customer hierarchy creation

  1. In order to achieve the customer hierarchy structure, the configuration settings needed as pre-requisite are mentioned below. They are all present in the path Sales & Distribution à Master Data à Business Partners à Customers à Customer Hierarchy

Ø     Define Hierarchy Types – OVH1

There are some default hierarchy types already provided by SAP. However, in case we need different hierarchies for different business processes, or if we need our own behavior of the hierarchy, we can define new hierarchy types. Here, we assign a customer hierarchy type to a partner function. There are 4 default customer hierarchy type partner functions available in SAP.

Ø     Set Partner Determination for Hierarchy Categories

In this, we can set up the partner determination at various levels of partner determination procedures – customer master, sales/billing document header/item or the delivery level, for the partner functions defined for the customer hierarchy types. Once the partner functions relevant for hierarchy types are assigned, we need to assign the same to the desired partner determination procedure in order to ensure that the required maintenance is possible.

Ø     Assign account groups – OVH2

In order to be able to create the customer hierarchy, we need to map the lower level customers’ account group to that of the higher level customers’ account group. For example, a particular sold-to-party customer can exist under both ship-to-party and sold-to-party. Once this is maintained, creation of hierarchy with customers will be possible only according to this mapping.

Ø     Assign Sales areas – OVH3

For a particular account group, it is possible to restrict extending a customer to a higher level customer at a sales area level. This is to achieve the flexibility of the customer hierarchy related functionalities to apply only for certain sales areas. For example, a customer should fall under another region customer and be eligible for a discount only in case of normal business, and not when he is involved in lease sales.

Ø     Assign Hierarchy Type For Pricing By Sales Document Type – OVH4

For a particular sales document type, only one customer hierarchy type can be assigned for pricing relevance. Hence, once a new customer hierarchy type is defined, and if it needs to reflect upon the pricing in the quotation or the sales order document, it needs to be assigned to both the document types.

b.            Creation of customer hierarchy - VDH1N

Once all the set up for the customer hierarchy creation is done, the hierarchy can be created by clicking on the shown path in SAP menu or using the transaction VDH1N. For the maintained account groups and sales areas, we can give the higher level customer and the lower level customers’ sales areas and save. If the number of records for maintenance is too high, LSMW recording can be done, after which a file upload can be done in order to maintain the same in mass. Creation of records using VDH1N results in the table entries of KNVH.

Any process specific function module (like order creation, order cancellation, returns, etc) can be modified in order to fetch the higher or lower level customers from the table KNVH.

Bibliography & References: