Those who are familiar with CO-PA in SAP R/3 should read this blog. In order to assist clients who run realignment, I prepared this blog based on my experience as a SAP support employee.
What is realignment, first of all?
Using realignment, you can alter the characteristics that were previously uploaded or enter values for a new characteristic that has been introduced for the current profitability sectors. To be able to do this, the feature being changed’s derivation logic must be based on traits that already exist in the CE4XXXX table. Only the CE4XXXX table (where XXXX is an operating concern) is affected by realignment.
Let’s use a very simple example where on day one you have one inactive characteristic (the model) and two active qualities (the client and the product) (wwmd1). You publish a document with the customers C1 and P1 in it. For the pairing of C1 and P1, PA segment number 1 is generated, and a corresponding item is added to the CE4XXXX database.
On day 2, you turn on the wwmd1 characteristic. According to your deduction reasoning, M1 will follow C1 and P1, and so on. On day three, you upload a new document containing client C1 and product P1. The model, M1, will be derived. C1, P1, and M1 will each receive a second PA segment.
You can now realign the data so that M1 fills the earlier entry (PA segment 1). However, realignment was only possible since the derivation logic was founded on the client and the product. If it was based on a different set of rules or on characters that the KEQ3 settings prevent from being filled in in table CE4XXXX. Since realignment only affects the CE4XXXX table, it cannot be done.
How can value realignment alter values?
- With a legitimate derivation rule that modifies the value. The source fields of the respective derivation steps in table CE4XXXX must be filled in if a characteristic is intended to be derived once more during the realignment.
- By providing a fixed value for the characteristic to be realigned, values can also be altered during realignment. You can specify the replacement value of the characteristic in the “Characteristics to have values replaced” block of the “ConversRule”.
In the aforementioned illustration, you only choose PA segments with FKART = F1.
If there is a valid derivation rule, EFORM in the chosen PA segments will be modified. However, for all chosen PA segments, BONUS will be changed to ’02’.
How does the realignment mode handle derivation?
All derivation steps are handled in “Overwrite” mode, however if a derivation step modifies the value of a characteristic, all subsequent derivation steps that reference that characteristic are processed in accordance with the definition of that characteristic in the “Attributes” settings. In actuality, this is the same situation as if derivation processing were performed on an INITIAL char value: the first step prevails (regardless of the ‘Attribute’ settings), and subsequent stages will only overwrite if they are declared in this manner.
When ought to realignment be conducted?
Realignment should be carried out primarily in two situations:
1. After adding a new characteristic, when it’s time to update the current PA segments.
2. When you want your existing PA segments to reflect changes to your derivation logic or master data.
If one of the aforementioned actions is taken, realignment is not immediately triggered. It must be manually executed.
Some customers I’ve encountered conduct realignment as part of their month-end operations. This is incorrect! Only the unique circumstances mentioned above should trigger realignment.
Why is the validity date important in realignment?
Recently, I encountered a client who was utilising realignment for a future date! This has no use!
The current date or system date is always used for the derivation in realignment cases. Therefore, no derivation or realignment will take place if a validity date in the future is specified. However, regardless of how far in the past the date is, derivation or realignment will take place if a validity date in the past is provided (= system date).
We have a validity date because certain attributes must be generated in cases of normal derivation (without realignment), such as when you publish a sales order or a billing document. Here, the document date—rather than the posting date or system date—is always used for the derivation. The doc date will typically always be in the past. The validity date becomes significant in this situation. For instance, you are placing a sales order with a 2 week old date (July). You have a derivation rule with two rule entries for the characteristic wwmdm, one valid through the end of July and the other beginning in August. In this instance, the rule entry that is valid through the end of July will be used.
To sum up, only rule elements from a derivation rule that are still valid as of the current date are taken into account when derivation is done for realignment purposes. When you submit data from SD, FI, etc. to COPA, an usual derivation occurs. In this situation, the validity date is primarily helpful.
Is it possible to realign according to the posting period or date?
Customers that demand realignment depending on posting period have been encountered by me. This simply indicates that they are unaware of the idea of profitability sectors!
PA parts are independent of time.
Take a look at a very basic example to help illustrate this. Let’s assume that you only have the two attributes of goods and client. Assume you only have 2 clients (C1 and C2) and 2 items (P1 and P2). Thus, there are four possible combinations ( 4 entries in CE4XXXX)
PA segment no combination
1 P1C1
2 P1C2
3 P2C1
4 P2C2
Now, the system will verify the customer and product whenever you post, say, an invoice, and it will select the PA portion. This holds true regardless of the time frame or fiscal year.
Therefore, you may employ the aforementioned PA segments for, say, 10 years.
However, because line items are time-dependent, the posting date is filled in when it is done to the CO-PA line items table CE1XXXX.
Therefore, readjustment based on posting date or period is not possible.
Can KEND jobs be scheduled on a recurring basis?
Since each realignment run generates entries in table CE4XXXX KENC with the realignment run number in field CHGRUN, doing so would result in duplicate records in this table if the same segment number PAOBJNR was changed twice by the SAME realignment run. As a result, this is not possible (instead of using a different realignment run at second time what would be the correct procedure). Or, to put it another way, each realignment run can only be carried out ONCE!
A realignment run is typically prevented from being done twice by Note 399997 (by determining whether the realignment run has previously been executed), but this check is invalidated if the status of the realignment run is “Running”. There would be a notification informing that the realignment run could no longer be completed if the status was “Successful.”
The correct technique to iterate a realignment is to construct a new realignment run for the subsequent execution of the same realignment (by copying the old realignment run within transaction KEND). This is because you really shouldn’t execute the same realignment run more than once. Periodic planning cannot be done.
Realignments may they be undone?
It is possible to undo a realignment if the definition of the realignment run has been retained (transaction KEND: Run/request > restore). The system stores the old PA segments when you do a realignment in table CE4XXXX KENC.
The PA portion is unaffected by realignment. Restoring a realignment run merely resets the content of the CE4XXXX segment numbers to their initial values.
How can I retrieve a realignment run’s history?
At the first KEND screen, a realignment run can be double-clicked to reveal further information. You may find out who carried out this realignment by clicking on the magnifying glass next to the entry labelled “update run” in the “Change history” list.
What impact does level realignment have on summarization?
Customers are perplexed to discover summary levels deactivated and inquire as to why. The realignment may be one of them.
Only those summary levels that contain a characteristic that was modified during realignment are deactivated when you perform realignment.
Status is set to “active without data,” for example. There must be a rebuilding of these summary tiers. Only those summarization levels that are deactivated due to realignment must be recreated.
KE24
There are two ways to execute transaction KE24: “read as posted” or “read according to existing structure.” Choosing “read as posted” causes the system to read only the CE1XXXX line items. There is a connect on CE4XXXX and CE1XXXX if you choose to “read according to current structure,” which takes realignment into account.
It will always be read in “read as posted” mode if you view a costing-based CO-PA document from the originating programme, i.e. VF03/FB03/MB03 -> Accounting Documents -> Profitability Analysis. Use transaction KE24 to see the document if you want to see how realignment has affected something.
SFIN realignment
Realignment can be done starting with S/4 HANA OP 1610. Notes 2344759 and 2350123 in S/4 HANA Finance OP 1605 can be used to implement realignment. For the lower releases of SFIN, the account-based CO-PA does not provide the realignment functionality. Realignment is conceivable if only CO-PA with a costing basis is in operation.
In my Expert Webinar, which is captured in KBA 2444746, I describe S/4 HANA realignment. In-depth webinar Controlling and profitability analysis for S/4 HANA Finance (CO-PA)
The flag “Rederivation of ACDOCA Characteristics for Attributed Line Items” in KEND can be used to realign the characteristics in ACDOCA of attributed PA segments. Only line items in table ACDOCA are impacted by KEND’s “Rederivation of ACDOCA Characteristics for Attributed Line Items” option. The attributable profitability segments in table CE4XXXX are unaffected. Because the profitability segment could be used in another process and provide an incorrect attribute, this logic avoids unfavourable side effects.
I hope the information above helps dispel any misunderstandings about realignment. I’ll update this blog whenever I have new experiences to share on the subject.