Realignment

 

A realignment makes organizational changes in your product, customer, or sales structure. For example, you can reassign sales districts to regions, or products to product groups. Realignments affect data that has already been posted. You can perform realignments periodically.

Realignments make it possible to apply changes in customer or material master records, in the SD customer hierarchy, or in CO-PA derivation rules to the data that has already been posted to Profitability Analysis.

Following a realignment, only the new assignment is known in the information system and in planning. The characteristic values valid at the time of the original posting can only be analyzed in line item reports. Because the existing profitability segments are changed to adhere to the new assignment, all objects assigned to those profitability segments - such as sales orders or projects - and all existing SAP documents - such as billing documents or FI documents - reflect the new assignment as well.

Concepts

Realignment

A realignment changes the characteristic values of profitability segments and thereby activate master data changes for all existing data in CO-PA.

Selection Criteria

The selection criteria are a set of characteristics for which characteristic values are specified.

Conversion Rule

A conversion rule tells the system to do one of the following for each characteristic that can be changed by the realignment program:

  • Derive characteristic again (default)

  • Do not change (predefined and unchangeable for the controlling area, company code, business area, sales order, sales order item, and quantity units).

  • Replace with fixed value (value must also be specified)

Realignment Request

A realignment request consists of a set of selection criteria, a conversion rule, and a description. Realignment requests are based on the concept of change documents. That is, you should have one realignment request per change document for smaller master data changes.

Realignment requests cannot be carried out directly.

Realignment Run

A realignment run consists of one or more realignment requests.

The realignment run is the executable unit for realignments. Once you have executed a realignment run successfully, you cannot change or repeat it. It is possible to restore the data to the state it had prior to the realignment run. The system stores status information (who executed the run when, final status) as well as a log.

Strategy

In practice it is often difficult to limit changes to derivation-relevant master data to specific dates. These changes have an immediate effect on postings to CO-PA and constantly create new profitability segments, while the corresponding "old" profitability segments become obsolete and can no longer receive postings.

Example Example

Customer Sample (customer number 1) is assigned to sales representative Smith (representative number 1234) up to 2/7/2007. For sales of the product 1234.56.78.90 to Mr. Sample, a number of actual postings have been made to profitability segment 0000000001, which is defined by the characteristic values Customer Number 1, Sales Representative 1234, and Product 1234.56.78.90. Due to a restructuring of the sales department, customer Sample is assigned to sales representative Taylor (representative number 1235) beginning on 2/8/2007. The next time Mr. Sample buys product 1234.56.78.90, the revenues are posted to a new profitability segment 0000000002, which is defined by the characteristic values Customer Number 1, Sales Representative 1235, and Product 1234.56.78.90. Profitability segment 0000000001 will no longer receive any new postings. Using realignments, you can change this profitability segment later so that profitability segments 0000000001 and 0000000002 have the same combination of characteristic values.

End of the example.

This type of situation should be avoided where possible, because the redundant profitability segments slow down the system when it reads from the segment level and may even make up the bulk of the data volume after a while.

This makes it necessary to make changes as quickly as possible using realignment runs. Such reassignment runs do in fact invalidate the summarization levels and data already set up. Both have to be recreated afterwards (see Effects on Summarization Levels and Data).