Hierarchy

⤷

⤷

⤷

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 | 9 | 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 |