customer Hierarchy and product Hierarchy

[Former Member]

Hi friends what is customer Hierarchy and what is product hierarchy?

please explain step by step with examples.

mail id: y.s.rao.sap@gmail.com

Thanx.

[Former Member]

Hi Sirivas,

CUSTOMER HIERARCHY:

Customer hierarchies are available in Sales and Distribution, so that you can create flexible hierarchies to reflect the structure of customer organizations. If your customer base includes multi-level buying groups, cooperatives, or chains of retail outlets, for example, you can create hierarchies to reflect the structure of these groups. Use customer hierarchies during sales order processing and billing for determining pricing and running statistics.

 A customer hierarchy consists of nodes.

 To create a customer hierarchy:

1. Create master records for each node.

2. Assign the nodes to each other.

3. Assign the customer master records to the relevant nodes.

 Hierarchy nodes are only valid for a certain period of time. They may also be moved. If a node is moved, the system automatically reassigns all related nodes and customer master records.

With customer hierarchies, you can assign price or rebate agreements to a higher level node. The agreements are then valid for customer’s at all subordinate levels to this node. You can create pricing condition records for each node indicated as relevant for pricing. If one or more nodes in the hierarchy path of a sales order contain pricing information, the system takes them into account automatically during pricing.

'How to check'

All the customizing is in SD/Master Data/Business Partner/Customers/Customers hierarchy

All the customizing is in SD/Master Data/Business Partner/Customers/Customers hierarchy

1) Define hierarchy type: just put and ID and a name to the new hierarchy.

2) Set partner determination: if you want to user the hierarchy in price determination, then, in the orders, at the header level, you have to have a Partner Procedure with a partner function for each level. In the partner procedure, in each partner function you must indicate the source partner function. With this information, in the order, you obtain the business partner for each partner function.

3) Assign account groups: you indicate which accounts groups are allowed for being part or your hierarchy.

4) Assign sales areas: simple you indicate which sales areas are allowed in your hierarchy. (Here you can customize common sales areas, just for not having to build de hierarchy in all the different sales areas).

5) Assigning hierarchy type for pricing: you indicate which classes of documents uses hierarchy in pricing determination.

It is possible to maintain so called customer hierarchies. This might be useful when for example you create a condition discount for a customer that is part of such a hierarchy structure. All subnodes in the hierarchy below that customer, will thus receive the same discount.

Customer hierarchy setup, firstly decide the hierarchy type to be used.

The standard is type A.

You can also assign a partner function to the customer so that the higher level customer in the hierarchy is copied into a sales order as a partner function - but you don't need that right?

Next assign your customer account group to the hierarchy type. And enter the combinations that will be allowed for creating the hierarchy.

You want to assign a ship-to to a payer. So enter the ship to account group and enter the payer account group as the higher level.

You must also make an entry for permitted sales area assignments. So if you want to a hierarchy for customers in the same sales area then enter the sales area and enter the same one as the higher level sales area.

All these settings can be found in the IMG. Under SD - master data - business partners - customers - customer hierarchy

You use for example customer hierarchy when you have an company like Unilever and you agree both on a discount. Unilever does have different locations / businesses and you have to maintain the discount for all customers. If you use a customer hierarchy you can maintain the discount for the partner in the top of the hierarchy and in this way it will be valid for all customers in the hierarchy.

Product Hierarchy:

The product hierarchy on the Basic Data screen is used to depict the competitive materials of competitor 1 in relation to those of competitor 2. Here, your own company and its materials are also regarded as a competitor and as competitive materials respectively. You can use this representation as a basis for market analyses.

Normally we enter competitive materials using material type WETT. When entering your own materials as competitive materials, you can, however, display the product hierarchy on the Basic Data screen for other material types too.

Requirement type determination is based on the "Origin of requirement type in requirement type determination"

In this field you can select an alternative search strategy (source):

Source 0 = Material master strategy, then item category and MRP type

Source 1 = Item type and MRP type strategy

Source 2 = Item type and MRP type strategy (as for source 1) with additional check of the allowed requirements type

e.g. If you set value "0" system will first strategy group in material master based on that it will determine requirement type and no value found then it will determine requirement type based on item category and MRP type.

Above settings can be found at SD --> Basic Functions --> Availability Check and transfer of requirement --> Transfer of Requirement --> Determination of Requirement type using Transaction

For make to order std strategy group 20 is used to which req type KE is assigned.

Check

Check in Tcode OVZH, what requirement class is assigned to your requirement type

Check in Tcode OVZG, what value is assigned to field "Consumption" in requirement class because that determines consumption posting.

The product hierarchy is used to group materials by combining different features. It is used for analyses and pricing. A product hierarchy can consist of up to Eighteen characters. Its features can be combined in various ways.

Example: A dishwasher can be described by product hierarchy 000010000200000002. This series of characters states that dishwashers belong to the category electrical appliances (series of characters 00001, position 1-5), and also to wet appliances (series of characters 00002, position 6-10) and, finally, to dishwashers (series of characters 00000002, position 11-18).

One can maintain the product hierarchy via transaction "OVSV" and "V/76.

Path = IMG-Logistics General-Material master-Setting for Key fields-Data relevant to SD-Define Product hierarchy.

The product hierarchy is maintained in the Basic Data view of the material master record, and is used for evaluation as well as price determination in materials management.

The standard SAP allows only 3 levels, but you can go up to 6 levels, for additional 3 levels u will have to take abapper help and add 3 more fields and corresponding data element into structure. So that in material master drop down you will see 6 levels.

The transaction which will be useful to change product hierarchies for material master will be V/76.

Yes, You can print the levels of the product hierarchy through a report.

Use the view SE16 - V_T179 (Table Name) to display Product hierarchy with level numbers.

Field Name is PRODH

Please Reward If Really Helpful,

Thanks and Regards,

Sateesh.Kandula

[Manoj_Mahajan78]

Sriniwasa,

How to configure and maintain the SD Customer Hierarchy?

All the customizing is in SD/Master Data/Bussiness Partner/Customers/Customers hierarchy

1) Define hierarchy type: just put and ID and a name to the new hierarchy.

2) Set partner determination: if you want to user the hierarchy in price determination, then, in the orders, at the header level, you have to have a Partner Procedure with a partner function for each level. In the partner procedure, in each partner function you must indicate the source partner function. With this informacition, in the order, you obtain the bussiness partner for each partner function.

3) Assign acount groups: you indicate which accounts groups are allowed for being part or your hierarchy.

4) Assign sales areas: symple you indicate wich sales areas are allowed in your hierarchy. (Here you can customize common sales areas, just for not having to build de hierarchy in all the different sales areas).

5) Assigning hierarchy type for pricing: you indicate which classes of documentos uses hierarchy in pricing determination.

It is possible to maintain so called customer hierarchies. This might be useful when for example you create a condition discount for a customer that is part of such a hierarchy structure. All subnodes in the hierarchy below that customer, will thus receive the same discount.

Customer hierarchy setup, firstly decide the hierarchy type to be used.

The standard is type A.

You can also assign a partner function to the customer so that the higher level customer in the hierarchy is copied into a sales order as a partner function - but you don't need that right?

Next assign your customer account group to the hierarchy type. And enter the combinations that will be allowed for creating the hierarchy.

You want to assign a ship-to to a payer. So enter the ship to account group and enter the payer account group as the higher level.

You must also make an entry for permitted sales area assignments. So if you want to a hierarchy for customers in the same sales area then enter the sales area and enter the same one as the higher level sales area.

All these settings can be found in the IMG. Under SD - master data - business partners - customers - customer hierarchy

You use for example customer hierarchy when you have an company like Unilever and you agree both on a discount. Unilever does have different locations / businesses and you have to maintain the discount for all customers. If you use a customer hierarchy you can maintain the discount for the partner in the top of the hierarchy and in this way it will be valid for all customers in the hierarchy.

Product Hierarchy:-

Product hierarchy is used for pricing. A product hierarchy is an alphanumeric character string which consists of 18 characters at the most. Product hierarchy thus define the product and its composition. To take an example, a product hierarchy could be 00010002000300040005. The first four characters 0001 could indicate that the product is a car. The next four characters could indicate 0002 the plant in which the car has been manaufactured. The third set of characters could indicate the color of the car. The next set may determine its engine capacity and so on. Thus, the product hierarchy helps in defining the product composition.

Pricing Procedure in Product Hierarchy

But if you want an example here goes. Say, you want to base your pricing procedure on first three digits of product hierarchy, defined in the material master, via condition technique.

Pricing structure for line item is KOMP. A quick look thru KOMP structure (tx SE11) shows that you have only PRODH field for all 18 digits of product hierarchy, whereas you need only the first three. So you do the following:

1. Create the new data element ZZPRODH1. Also create a domain with the length "3" and the data type "CHAR" for the new data element. Remember that new data fields must start with the letters "ZZ" or "YY", since SAP reserved these letters to protect them from being overwritten during a release upgrade.

2. Check whether the product hierarchy (PRODH) is found at header or at item level. In table VBAP, document field PRODH is defined as an item field.

3. Integrate the field name ZZPRODH in the communication structure KOMP using the INCLUDE KOMPAZ and allocate the data element PRODH to it.

4. Activate the structure.

5. Check in which table the field PRODH exists.

The field is in table VBAP (sales document: item data).

6. Assign a value to the new field in the FORM routines for sales order processing and billing using the appropriate user exits: In sales order processing the user exit is found in member MV45AFZZ. The complete statement is:

FORM USEREXIT_PRICING_PREPARE_TKOMP.

MOVE VBAP-PRODH(3) TO TKOMP-ZZPRODH. ENDFORM.

The routines for assigning a value to the new fields in billing are found in member RV60AFZZ. The statement is as follows:

FORM USEREXIT_PRICING_PREPARE_TKOMK MOVE

XVBRP-PRODH(3) TO TKOMP-ZZPRODH. ENDFORM.

7. Allocate the specifications A, V and 001 to the field ZZPRODH in table T681F. Use "E" has been added for fields in rebate processing.

This is a standard example from SAP Library. In this case you must tell the ABAP three things:

- that your source field is VBAP-PRODH,

- that you need to get the first three digits from that field into your pricing structure KOMP

- and that you need to specify the transfer by user exit thru MV45AFZZ

Please note that this is a very simple example. Quite often you have to dig a lot deeper.

Modifications of Copy Control routines, making output forms (thru SapScript) and such requires you to know all the necessary tables, structures and fields.

The only advice I can give you is to use tx SE11, which will show you the organization of a table/structure, and can also help you check the contents of a specific table in a specific sales doc.

REWARD IF U FINDS THIS AS USEFUL...

Regds

MM