SAP ABAP Data Element RKE_EXCEPTIONS (Exceptions in Segment-Level Characteristics)
Hierarchy
BBPCRM (Software Component) BBPCRM
   CRM (Application Component) Customer Relationship Management
     CRM_APPLICATION (Package) All CRM Components Without Special Structure Packages
       KE0C (Package) Customizing for Profitability Analysis
Basic Data
Data Element RKE_EXCEPTIONS
Short Description Exceptions in Segment-Level Characteristics  
Data Type
Category of Dictionary Type D   Domain
Type of Object Referenced     No Information
Domain / Name of Reference Type CHAR20    
Data Type CHAR   Character String 
Length 20    
Decimal Places 0    
Output Length 20    
Value Table      
Further Characteristics
Search Help: Name    
Search Help: Parameters    
Parameter ID   
Default Component name    
Change document    
No Input History    
Basic direction is set to LTR    
No BIDI Filtering    
Field Label
  Length  Field Label  
Short 10 Exceptions 
Medium 15 Exceptions 
Long 20 Exceptions 
Heading Exception 
Documentation

Definition

Exceptions concerning segment-level characteristics

The aim of this function is to reduce the quantity of profitability segments generated. This is achieved by only updating in detail those values that are also relevant for running an analysis. You specify an exception for a characteristic that you generally do not wish to be involved in the creation of profitability segments. In the exception, you define the conditions (in other words, you specify the characteristic values) dictating when the characteristic should be not be included among the segment-level characteristics.

In this way, it is possible for an engineering company to arrange for the heavy machinery division to be updated at the detailed product level, while the spare parts division is updated at a higher level, that of the product group. In this example, the characteristic for which the exception is defined is the product. It is hidden when the division receives the characteristic value spare parts.

Another useful example of how an exception can be applied is the distinction between key customers and other customers. It makes sense to analyze and update key customers at the detailed customer level, whereas other customers can be summarized at the customer group level.

When the exception is applied, the number of profitability segments generated is reduced, thereby improving performance in reporting and in the system in general. However, to ensure that system performance is actually enhanced, you should use this function sparingly and only use it in specific cases. Once applied in a productive system, an exception should no longer be changed, because changes to it would cause inconsistencies in your data, especially if you remove an exception and thereby include the corresponding characteristic in the creation of profitability segments.

It is essential that you apply the following rules when using this function:

  • You should only define an exception for characteristics representing a detailed level of analysis and that therefore take a large number of characteristic values. The larger portion of these characteristic values should be excluded as a result of the exception.
  • Complicated conditions should not be defined in an exception because analysis with such a condition counteracts any improvements in performance. It makes better sense to use as your condition one or two characteristics, each having no more than two or three characteristic values. For best results, aim to keep the definition of your exception as basic as possible. To achieve this, it is sometimes necessary to create an additional characteristic (see example 2 below).
  • Exceptions should not be changed once applied in a productive system. In particular, such exceptions should not be deactivated because this prevents the data from being analyzed correctly. In certain cases, it is possible to maintain extra exceptions. However, you must run a realignment for the affected characteristic beforehand. To do this, select in the selection condition the characteristics and characteristic values specified in the exception. In the conversion rule, enter # (= nonassigned) for the characteristic that the exception was defined for.
  • Characteristics that have an exception maintained for them cannot be be changed by realignments!
  • To define an exception, you can use almost all characteristics that create profitability segments (technically all the characteristics from table CE4xxxx, where xxxx = operating concern). This does not apply in the case of Unit of measure or the characteristic for which the exception has been defined.
  • If you define an exception with dependent characteristics, then all of the characteristics in those dependencies should be included in that exception.
  • Note that the definition of the exception applies for all flows of actual data, as well as for the summarized update of data during the transfer of billing documents. The setting do not apply in planning; there, the detail level for data entry is specified in the planning level. The detail level for planning should not be greater than that for the flow of actual data in order that useful comparisons between actual and planning data are possible.

Characteristics that are hidden due to an exception are still updated in the line item table (CE1xxxx). Furthermore, they remain visible when you display the line items with the current structure.

If a line item contains such a characteristic, the system always accesses the line item list to display the line items.

This is equally the case if you call up the line item display from a profitability report with the current structure. In the profitability report, the affected characteristic has the value "initial" because the report accesses the segment level (CE4xxxx).

This value is also used to select the line item. Since a value for the characteristic exists in the line item table, the system cannot find the correct line item.
You can circumvent this problem by calling up the function Goto -> Line Item at a higher expansion level in the report. In this way, the hidden characteristic is not selected.

Examples of typical uses

1. Hiding all products in the spare parts division

As in the case described above, an engineering company produces large machinery to order but also sells spare parts. Detailed analyses at the product level are only necessary for heavy machinery. The operating concern contains the divisions heavy machinery and spare parts that are determined by appropriately defined derivation steps.

In this case, an exception is defined for the characteristic product. Depending on the type of profitability analysis used, this involves setting the Costing-based or Costing-/Acct-based indicator and selecting the Exceptions pushbutton. In the following screen, the condition for hiding the data is specified: when the characteristic Division takes the value Spare parts.

2. Hiding "other customers" by defining the new characteristic Key customer indicator

A repetitive manufacturer does not want to analyze all their data at the customer level. Instead, only a selection of key customers should be looked at in detail. However, there is no characteristic in the operating concern that makes any such distinction. Not only is it not possible to define an exception along the lines of "Hide characteristic "Customer" when customer = A and customer = B and ...", but this would not be practical either. Hence a new characteristic - with which a distinction can be made between key customers and other customers - needs to be created. It is possible, for example, to define an additional characteristic Key customer indicator and then, by means of characteristic derivation, to set it to X for the key customers and leave it empty for all other customers. For data that has already been posted, it is necessary to run a realignment during which these other customers are set to the initial value. The following exception can then be defined: The characteristic "Customer" is hidden when the key customer indicator = initial (for the initial characteristic value, enter # in the entry field). Once this exception has been applied, no further analysis can be run on the other customers at the customer level because the exception cannot be canceled.

History
Last changed by/on SAP  20000201 
SAP Release Created in 46C