Enterprise Resource Planning Blogs by Members
Gain new perspectives and knowledge about enterprise resource planning in blog posts from community members. Share your own comments and ERP insights today!
cancel
Showing results for 
Search instead for 
Did you mean: 
ashisK
Discoverer

1.  Introduction


1.1     Objectives


The purpose of this document is to provide extensive understanding of Customer Hierarchy Solution in S4 and its usage in various business processes.

 

1.2     High Level Understanding


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.

 

1.3     Why and when to use Customer Hierarchy



  • Before setting out and maintaining a customer hierarchy, we would need to determine the requirement for the hierarchy. 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.

  • If the requirement is 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, business wants to have a customer hierarchy 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 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.


 

2.  Maintain Customer Hierarchy


2.1     Prerequisite Steps:



  • Create Customer Master Records:


Make sure that customers (Sold to Party) are created in the system using BP TCode.

 

  • Create Customer Hierarchy Node


Hierarchy Nodes can be created as customer masters using BP TCode, and like any other customer master, the hierarchy node is defined also on sales area level. The following fields are mandatory in customer hierarchy node master data:



2.2     Building the Customer Hierarchy Structure (TCode: VDH1N)


VDH1N transaction code is used in S4 to create customer hierarchy structure.


Maintenance of customer hierarchy in S4 comprises below processes:

  1. Create new hierarchy structure.

  2. Add new node/customer to an existing hierarchy structure

  3. Change validity period of existing hierarchy assignment

  4. Reassign node/customer from an existing hierarchy structure

  5. Remove node/customer from an existing hierarchy structure


 

 

Steps/Governance to be followed for each business processes are mentioned below:

2.2.1    Process variant 1 – Create new Hierarchy structure


As per the business need, customer hierarchy structure can be created either Single Level or Multilevel. Prices (net price/discount) and CMIR can be maintained at any level hierarchy node, accordingly, the lower-level end customers will inherit all the prices and CMIR from the higher-level node.

Business Governance

  1. A request for a new Hierarchy assignment is issued containing the business reasoning.

  2. Business validation and approval or rejection is given from relevant managers.


 

Operational Governance

  1. Once the hierarchy nodes are created in MDG, hierarchy structure can be built in S4 using “Create Assignment” functionality in VDH1N transaction code.

  2. As required by business scenario, Higher level node number and lower-level node/customer number along with Sales Org., Distribution Channel and Division needs to be provided to create a new hierarchy assignment.

  3. Validity period needs to be maintained for the newly created assignment. Once the validity period expires, system automatically deactivate the hierarchy assignment.

  4. By using this Create Assignment functionality, multilevel hierarchy structure can be created for a specific lower-level end customer.


 

Click on the “Create Assignment” button (highlighted in red) to create a new hierarchy assignment.



2.2.2    Process variant 2 – Add new node/customer to an existing hierarchy structure


After the customer hierarchy structure is built in S4, there might be a business need to add a new node/customer to that existing hierarchy structure. In such cases, Assign functionality should be used to add a new node/customer to the existing hierarchy structure.

Business Governance

  1. A request for a new Hierarchy assignment of a new node/customer to an existing hierarchy structure is issued containing the business reasoning.

  2. Business validation and approval or rejection is given from relevant managers.


 

Operational Governance

  1. “Assign” functionality in VDH1N transaction code is used to add new node/customer to an existing hierarchy structure.

  2. Higher level node number and lower-level node/customer number along with Sales Org., Distribution Channel and Division needs to be provided to add a new node/customer to the existing hierarchy structure.

  3. Validity period needs to be maintained for the newly added assignment. Once the validity period expires, system automatically deactivate the hierarchy assignment.


 

Click on the “Assign” button (highlighted in red) to add a new node/customer to an existing  hierarchy structure.  In below example customer 1003096 is assigned under Hierarchy Node 5000.



2.2.3    Process variant 3 – Change validity period of existing hierarchy assignment


After the customer hierarchy structure is built in S4, there might be a business need to change validity period of existing hierarchy structure. In such cases, “Change Validity” functionality should be used to change the validity period to past or future date as per the business requirement.

Business Governance

  1. A request for changing the validity period of existing hierarchy assignment is issued containing the business reasoning.

  2. Business validation and approval or rejection is given from relevant managers.


 

Operational Governance

  1. “Change Validity” functionality in VDH1N transaction code is used to change the validity period of an existing hierarchy assignment.

  2. Validity period can be changed to past or future date according to business needs. If past date is entered in From and To Date, then as per the current date that particular hierarchy assignment will be deactivated. Similarly, if future date is entered in From and To date, then from that specific future date the hierarchy assignment will be active in the system.

  3. If there is any active assignment present in the system, and the requirement is to make that assignment to future date assignment, then it is always recommended to end the current assignment by entering past date first, then create a new assignment with future date as validity period. This is not a standard SAP restriction; you can directly use Change Validity functionality in standard process to change validity date in one step only by entering the new validity date.

  4. This above two-step process is required to store the previous assignment in the system, which will be used to send CMIR (Customer Material Info Record) details (with deletion indicator) of previous assignment to a third-party Legacy system via material master interface. This restriction/guideline is imposed only by the custom(Z) material master interface to Legacy system (this is client specific).


Click on the “Change validity” button (highlighted in red) to change validity period of an existing hierarchy assignment.

Validity period can be changed to past date or future date as per the business need.



2.2.4    Process variant 4 – Reassign node/customer from existing hierarchy structure


Once the customer hierarchy structure is built in S4, there might be a business need to reassign a particular node/customer to change the existing structure. Being flexible in nature, customer hierarchy can easily accommodate this requirement.

Business Governance

  1. A request for reassignment of node/customer of existing hierarchy structure is issued containing the business reasoning.

  2. Business validation and approval or rejection is given from relevant managers.


 

Operational Governance

  1. To reassign a particular node/customer from an existing hierarchy structure, the following steps should be performed:



  • End the current assignment by entering past date as validity period using “Change Validity” functionality in VDH1N transaction code.

  • Create new assignment with appropriate node/customer as per the business need using “Assign” functionality in VDH1N t-code.


 

  1. In standard SAP, there is no provision to store the previous assignment if any particular node/customer is directly reassigned from one node to another node using “Reassign” functionality in VDH1N t-code. In such cases, system overwrites the previous assignment with the new one. Hence there is no way to find out the previous assignment of that reassigned node/customer.

  2. Hence, “Reassign” functionality in VDH1N t-code should not be used to directly reassign a node/customer. Instead, the above mentioned (in step 1) two-step process should be followed. This is not a standard SAP restriction; you can directly use Reassign functionality in standard process.


 

  1. This above two step process is required to store the previous assignment in the system, which will be used to send CMIR (Customer Material Info Record) details (with deletion indicator) of previous assignment to a third-party Legacy system via material master interface. This restriction/guideline is imposed only by the custom(Z) material master interface to Legacy system (this is client specific).



If there is no such requirement to send previous assignment to any third-party legacy system via any Interface, you can directly use Reassign Functionality provided by SAP standard.

As an example, Customer 1003096 was assigned with node 5000 as shown in above figure. To reassign customer 1003096 from node 5000 to node 5002, current assignment needs to be ended using “Change Validity” functionality and then “Assign” functionality needs to be used with node 5002.

Step 1: From and To Date has been changed to past date 2021-05-30 to 2021-05-30.


Step 2: Select node 5002 and click on “Assign” functionality. Provide lover-level customer as 1003096 along with validity period to assign the customer to node 5002.



2.2.5    Process variant 5 – Remove node/customer from existing hierarchy structure


In case a node/customer is no longer valid or needed within a hierarchy structure, it can be deleted/ended from the existing structure.

Business Governance

  1. A request for removal of node/customer of existing hierarchy structure is issued containing the business reasoning.

  2. Business validation and approval or rejection is given from relevant managers.


 

Operational Governance

  1. To remove a particular node/customer from an existing hierarchy structure, the following steps should be performed:



  • End the current assignment by entering past date as validity period using “Change Validity” functionality in VDH1N transaction code.


 

  1. In standard SAP, whenever any node/customer is deleted from hierarchy structure using “Remove” functionality in VDH1N t-code, the relevant table data is deleted from the system. Therefore, there is no way to find out the previous assignment of that deleted node/customer.


 

  1. Hence, “Remove” functionality in VDH1N t-code should not be used to directly remove a node/customer. Instead, the above-mentioned (in step 1) step should be followed. This is not a standard SAP restriction; you can directly use Remove functionality in standard process.


 

  1. This step (mentioned in point 1) is required to store the previous assignment in the system, which will be used to send CMIR (Customer Material Info Record) details (with deletion indicator) of previous assignment to a third-party Legacy system via material master interface. This restriction/guideline is imposed only by the custom(Z) material master interface to Legacy system (this is client specific).



If there is no such requirement to send previous assignment to any third-party legacy system via any Interface, you can directly use Remove Functionality provided by SAP standard.

As an example, in above figure customer 1003096 was assigned to node 5002. To remove the assignment of customer 1003096 from node 5002, “Change validity” functionality should be used to change the validity period to past date.

Step performed: Validity period of the assignment of customer 1003096 has been changed to past date 2021-05-30 to 2021-05-30, which ended the current assignment from node 5002 as per current date.


 

3.  Customizing Customer Hierarchy (Configurations)


3.1     Define Customer hierarchy Account Group


SPRO Path:


As per standard SAP Customer account Group 0012 is available. You can copy this account Group and create a new starting with “Z”.


 

3.2     Assign Number Range with Customer Account Group


SPRO Path:


As per standard SAP number range 01 is assigned to 0012 account group. You can create a new number range and assign as per business requirement.


 

 

3.3     Define BP Grouping & Assign Number Range with BP Grouping


SPRO Path:

SPRO: Cross-Application Components -> SAP Business Partner -> Business Partner -> Basic Settings -> Number Ranges and Groupings –> Define Groupings and Assign Number Ranges


 

In this configuration node, create a new BP Grouping starting with “Z” and assign appropriate number range to it. Number range should be same as Customer Hierarchy account Group.

 

3.4     Setting for Customer Integration with BP


SPRO Path:

SPRO: Cross-Application Components -> Master Data Synchronization -> Customer/Vendor Integration -> Business Partner Settings -> Settings for Customer Integration -> Field Assignment for Customer Integration -> Assign Keys -> Define Number Assignment for Direction BP to Customer and Define Number Assignment for Direction Customer to BP


 

In this configuration node, you need to assign BP grouping with Customer Hierarchy Account Group along with Number range and vice versa. Make sure to use “Same Number” field as marked.

3.5     Define Hierarchy Types


SPRO Path:


In this configuration node, you need assign hierarchy type with Hierarchy partner function. You can use the standard hierarchy type and hierarchy partner function. No need to create new one if not required by business needs.

 

3.6     Assign Account Group with Customer Hierarchy Type


SPRO Path:


In this configuration node, you need to assign Sold Party customer account group (or Ship to party customer account group based on business requirement) with Customer hierarchy account group.


This setting controls whether you can assign Sold to party or Ship to party or both against the customer hierarchy node while building the hierarchy structure.

 

 

3.7     Assign Sales Area with Customer Hierarchy Type


SPRO Path:


In this configuration node, you need to assign all the required sales organization which shall use this customer hierarchy feature.


 

3.8     Assign Hierarchy Type for Pricing by Sales Document Type


SPRO Path:


In this configuration node, you need to make sure that all the Sales Document Type which shall use customer hierarchy feature is assigned with Customer Hierarchy Type “A”.


 

3.9     Set Up Partner Determination for Hierarchy Categories


 

Determination of customer hierarchy nodes are usually done based on Sold to Party partner function. To achieve multilevel hierarchy structure, below 4 standard partner functions have been introduced:

  • 1A - Customer hierarchy 1 – 1st level hierarchy

  • 1B - Customer hierarchy 2 – 2nd level hierarchy

  • 1C - Customer hierarchy 3 – 3rd level hierarchy

  • 1D - Customer hierarchy 4 – 4th level hierarchy


 

SPRO Path:


In this configuration node, you need to maintain all the Customer Hierarchy Partner Functions (1A, 1B, 1C and 1D) are assigned properly with Sales Document Partner procedure and Billing Document Partner procedure. New partner functions will appear in the partner screen of the document header (depending on the number of levels used in the hierarchy).


 

3.10   Access Sequence and Condition table with Customer Hierarchy


To maintain Price or Discounts based on Customer Hierarchy Nodes, you need to create new condition table and add newly created condition table in access sequence with Customer Hierarchy field from field catalogue.



4.  Usage of customer hierarchy in Pricing



  • As per the business needs, you might need to use customer hierarchy to maintain price or discount. If a group of customer shares the same price or discount %, instead of maintaining on each customer level, you can maintain the Pricing condition record on Customer hierarchy Node considering that you have correctly created one hierarchy structure with all the customers.


 

  • Hence, Net Price & Discounts can be maintained at the customer hierarchy node level. As a result, all lower-level end customers can inherit the same prices/discounts from higher level node. In such cases, it will not be required to maintain prices/discounts at each customer level, which reduces pricing master data maintenance effort drastically.


 

  • VK11 transaction code is used to maintain price condition records in SAP. As shown in below snippet, prices/discounts can now be maintained with Customer Hierarchy node as well.


     


 

5.  CMIR (Customer Material Info Record) based on Customer Hierarchy in Sales Order Line:


 

  • Customer Material Info Record (CMIR) can be fetched from hierarchy node in sales order line item, if no CMIR maintained against Sold to Party, during sales order creation in SAP using VA01 transaction code.

  • If a group of customer shares the same CMIR, then no need to create CMIR records (using TCode VD51) for each customer separately. You can create CMIR records directly against Customer Hierarchy Node and SAP will automatically fetch the CMIR from customer hierarchy if no CMIR is maintained against Sold to Party.


 

Please note: SAP always takes precedence of the CMIR maintained against Sold to Party over Customer Hierarchy. So, if any CMIR is maintained against Sold to Party then that CMIR will always be copied in the Sales Order Line irrespective of Customer Hierarchy based CMIR.

 

 

Hopefully this blog will help you to get a better understanding and configuration related to Customer Hierarchy Solution in SAP S4.

If you like this blog, please give rating. Your comments and feedback are always appreciated.

If you need to learn more about SAP Sales and Distribution, please follow my page:

ashiskarmakar

Also please check out the SAP community page for any SAP related learning.

https://community.sap.com/

 

 
Labels in this area