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 fortheir 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 customerhierarchy, one needs to determine what the requirement for the hierarchy is. If the requirement is areport, such as reporting bookings orbillings for global customers within a hierarchy, this can be done using a standard reporting hierarchywithin the sales information system, Should thedesire be merely to offer prices according to a specific group, one could think about using a customergroup 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 andrelies on the partner determination in conjunction with the customer hierarchy settings in order topromote the linking between the customers. The partner determination causes the customer hierarchyto be represented in the sales document. Thecustomer hierarchy is a hierarchical organizational structure that consists of higher and lower levelnodes. Each node is assigned within the structure to form a graphical diagram of the cust
organization.A node is represented by an account group. A node can be a customer, such as a sold-to party, thusaccount group 0001. A node could also be a platform or merely an organizational department; thus, wehave account group 0012. A customer hierarchy can only have a maximum of 26 hierarchy levels. Onecreates a customer hierarchy by first defining the hierarchy type. Menu PathThe 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 thehighest node of the partner represented in the hierarchy. There should not be a need for you to createmore than one hierarchy type, as you can only assign one hierarchy type per sales document type, The
Methods of Characteristic Derivation - SAP COPA
Methods of Characteristic Derivation
Depending on the characteristics that you have decided to use in the future, CO-PA allows different methods of deriving these characteristics or, more precisely, for also specifying the values for the characteristics when you post documents. The following methods are available:
- Table lookup
- SAP enhancement
- Derivation rule
You can also process the defined CHARACTERISTIC DERIVATIONS step-by-step in a logical sequence in a characteristic derivation strategy. What is a characteristic derivation strategy? For characteristic derivation, CO-PA enables you to execute all derivation steps in a logical sequence. You create a characteristic derivation strategy in customizing. The path is as follows: CONTROLLING • PROFITABILITY ANALYSIS • MASTER DATA • DEFINE CHARACTERISTIC DERIVATION. The table that appears is initially empty, as the system does not know yet what you want to derive. Step-by-step you can define the logical sequence that the SAP system is to follow to derive the characteristics. For example, you can define dependencies in your strategy, such as: first derive characteristic XY; then derive characteristic YZ based on characteristic XY. The table below shows an example of a characteristic derivation strategy.
Example of a characteristic derivation strategy
The characteristic derivation strategy is a mandatory prerequisite for characteristic derivation in CO-PA. The derivation does not work without this strategy. In case characteristic derivation steps are to be brought forward at any point, in our example we start with step 16.
Characteristic Derivations for Our Example
In the following table, for our example data we have described which characteristics are to be derived and with which characteristic values. Via the customer master record, we want to derive three customer hierarchy characteristics as well as the customer group and the sales employee of the customer, as shown in Table.
Characteristic assignments for customers
Firstly, we derive the customer hierarchy for the three characteristics Customer hierarchy 1, 2, and 3 from the customer master record via assignment — if you use the SAP ERP module SD (Sales and Distribution), you can create these customer hierarchies in SD.
Excursus: How do you maintain a customer hierarchy in SD? You can arrange your customers hierarchically using customer hierarchies. In accordance with our example above, our customer K1 is reflected at customer hierarchy level 3. The customer belongs to customer hierarchy KH21 at level 2, and in turn to customer hierarchy KH11 at level 1. You can maintain customer hierarchies via LOGISTICS • SALES AND DISTRIBUTION • MASTER DATA • BUSINESS PARTNER • CUSTOMER HIERARCHY • EDIT or using transaction VDH1N.
Editing customer hierarchies
In our example, we maintain the customer hierarchy for type A (you can define different types of standard hierarchies, type A is the SAP standard) and define a validity date for which we want to edit the customer hierarchy. For example, we maintain the hierarchy for customer K1.
You must first create all nodes that you want to reflect as hierarchy nodes via K1 as customer masters in the sales area beforehand (in the current example, KH11 and KH21).
If you execute according to the selection above, you can use the CREATE or EDIT buttons to maintain the customer hierarchy for customer K1.
Maintaining the customer hierarchy for customer K1
Once you have maintained the customer hierarchies for all of our end customers K1 to K6, your screen appears as shown in Figure.
Complete customer hierarchy for our example
Is the customer hierarchy maintained in SD sufficient for deriving the corresponding customer hierarchy characteristics in CO-PA? No — first you have to do the following:
1. Define a derivation step in your characteristic derivation strategy.
2. Fill the HIERARCHY ASSIGNMENT field in the general data of the customer master.
To define a derivation step in characteristic derivation maintenance, create a new step and then select DERIVATION RULES. In detail, the strategy step appears as shown in Figure.
Detail derivation step of a customer hierarchy
The definition contains source fields and target fields. The source has to be defined in this way because we want to derive the hierarchy from the customer master. In SD, a customer is always created for a sales area. The sales area always consists of the three fields SALES ORGANIZATION, DISTRIBUTION CHANNEL, and DIVISION. Therefore, these fields are also in the source.
The correct hierarchy level of a customer is transferred to the GENERAL DATA of the customer master via the HIERARCHY ASSIGNMENT field.
Hierarchy assignment field in the customer master
Each customer hierarchy is therefore created as a normal customer master. It is the additional maintenance of customer hierarchy type A in the SD customer hierarchy and the filling of the HIERARCHY ASSIGNMENT field that distinguishes this customer master as a customer hierarchy.
Since we only want to work with three customer hierarchy levels in our example, our original customer masters K1 to K6 also represent the lowest customer hierarchy level here. In the customer master, they receive hierarchy assignment number 3. Customer KH11 was also created as a customer master and also receives 1 in the HIERARCHY ASSIGNMENT field, and so on.
To check that the configuration is correct, simulate a business transaction using transaction KE21. You can use this transaction to create a line item in CO-PA manually — to do this, as a first step, enter the master data from which the derivation should take place, for example, customer, sales organization, etc.
Billing document header data of the simulation document
Then press DERIVATION: you will see that for customer K1, including Logistics data, you can derive the customer hierarchy to all three levels, as prescribed.
Evidence of the derivation of the SD customer hierarchy in CO-PA
Once the derivation step is complete, our characteristic derivation strategy looks as shown in Figure below. In case characteristic derivation, steps are to be brought forward at any point, in our example we start with step 16.
Derivation step for deriving the customer hierarchy
As an example for table lookup, let us select characteristics that can be derived from the product master. The basic data view of a product master, which you create in the SAP ERP module MM, contains the PRODUCT HIERARCHY field (the technical name of this field is MARA-PRDHA). This field can contain up to 18 characters. We want to derive two characteristics from the product master: kind of product and product group. According to their definition, both characteristics should have three characters each. For example, the PRODUCT HIERARCHY field of product A1 contains the combination PA1PG2. Within the framework of table lookup, the first three characters of the PRODUCT HIERARCHY table field are assigned to the target characteristic kind of product, and the last three characters to the target characteristic product group. Thus, product A1 belongs to the kind of product PA1 and product group PG2. Provided the PRODUCT HIERARCHY field for product master A1 is not changed, for each posting for product A1, these characteristics are also derived and are available, for example, for evaluations. If the field is changed, the CO-PA characteristics are provided with new characteristic values from the date of the change.
I will now show you the required steps in customizing. We will proceed from the starting position shown in the above Table.
Example of a product hierarchy
In the basic data view of products 1 to 6, the PRODUCT HIERARCHY field was filled by your master data team — for example, for product A1, with the value PA1PG20000.
Product hierarchy in material master
Using the characteristic derivation strategy described, we now want to read, for example, the PRODUCT HIERARCHY field for product A1 with its value PA1PG20000 such that the first three characters are read for the characteristic kind of product (i.e., PA1), and for the characteristic product group, the characters 4-6, i.e., PG2. Since the PRODUCT HIERARCHY field can be up to 18 characters long, but we only need the first six characters in our example, the remaining characters in the example are filled with “0.”
We will now define a further derivation step in the CO-PA customizing: in the example, step 17.
Product hierarchy derivation step
We can use the magnifying glass to look at the detail of this derivation step. Here too you must define a source and a target. We can find the source in the basic data view of the material master. The relevant SAP table is MARA. The CO-PA characteristic product (ARTNR) corresponds to the material number of the material master . In the target, we assign our user-defined characteristics WWPAR and WWPGR to the PRODUCT HIERARCHY field of the material master (MARA-PRDHA) and state that characteristic WWPAR is to be read from the first three characters of the field MARA-PRDHA and characteristic WWPGR from characters four to six (+ 3 ( 3)).
Detail derivation step of a product hierarchy
Therefore, for product A1, CO-PA reads PA1 for the characteristic kind of product and PG2 for the characteristic product group. But what do PA1 and PG2 mean? When we created operating concern Z111, we defined these two characteristics freely and with no template table. Therefore, we have to make the corresponding characteristic values known to CO-PA. We do this via transaction KES1 or via the path in the application menu: ACCOUNTING • CONTROLLING • PROFITABILITY ANALYSIS • MASTER DATA • CHARACTERISTIC VALUES • CHANGE CHARACTERISTIC VALUES.
Maintenance of characteristic values
By double-clicking the respective characteristics, you can maintain the values for that characteristic.
Characteristic values of the characteristic kind of product
Characteristic values of the characteristic product group
If you now create a CO-PA document, you can see that the product hierarchies for your new characteristics are derived (again, via a simulation using transaction KE21),
Billing document item data of the simulation document
Evidence of the derivation of the product hierarchy in CO-PA
Learn SAP COPA Tutorial
Now we have to give each sales product a conversion factor for translating the base quantity unit into the alternative quantity. We do this in the SAP module MM in the additional specifications for a product. Via transaction MM02, go to the BASIC DATA 1 view of the product and from there again to the additional data. Here, choose the UNITS OF MEASURE tab; the screen is shown in Figure.
Alternative quantity units for a product
Product A1 weighs 100 KG per item. For our user exit, this means that the alternative quantity unit KG must be derived. A CO-PA user exit is available in the customizing for CO-PA, under CO-PA TOOLS • SAP ENHANCEMENTS. Create a project and assign component COPA0001. By double-clicking the component, navigate to the Include ZXKKEU11. If you have a developer key in your system, you can fill this Include. First, maintain the header of the user exit analog to Figure.
User exit header for characteristic derivation
Then insert the line CASE I_OPERATING_CONCERN. Follow this with the coding shown in below figure.
User exit coding for deriving the quantity unit
To ensure that the user exit for deriving the quantity unit KG is also found in your operating concern, you have to make the user exit known in your characteristic derivation strategy in step 19 (see Figure below)
Enhancement of the characteristic derivation strategy for the user exit
By double-clicking line 19, you navigate to the detail screen for this derivation step.
Derivation of user exit I
We are accessing the quantity units of the product master and therefore this master must be named in the source. The objective of the derivation step and of course the user exit is to give the quantity field VVAMG that we have defined a quantity unit.
In the coding, we specified the derivation step “AMG” (see the coding in above figure — “CASE I_STEP_ID”). We specify this step on the ATTRIBUTES tab (see Figure below).
Derivation of the user exit attributes
Check whether the derivation works (using KE21, for example). The aim is for the quantity unit to be derived for the ALTERNATIVE QUANTITY UNIT field. You can see the evidence in Figure below.
Evidence of the correct derivation of the alternative quantity unit via the user exit