Skip to Content
Author's profile photo Waman Shirwaicar

Realignment in CO-PA

This blog should be read by those who are familiar with CO-PA in SAP R/3. I work in SAP support and based on my experience i have created this blog to help customers who run realignment.

Firstly what is realignment ?

You can change the characteristics posted earlier or input values for a newly introduced characteristic for the existing profitability segments using realignment.  However this can be done provided the derivation logic for the characteristic being changed is based on the characteristics already existing in the CE4XXXX table. Realignment only touches the CE4XXXX table (XXXX = operating concern).

To give a very simplistic example let us say on day 1 you had 2 active characteristics customer and product and one inactive characteristic model (wwmd1). You post a document with customer C1 and product P1. PA segment no 1 is generated for the combination C1 and P1 and a corresponding entry is posted to CE4XXXX table.

On day 2 you activate the characteristic wwmd1. You have a derivation logic that says for C1 and P1 it will be M1 and so on.  On day 3 you post another document with product P1 and customer C1. Model will be derived as M1. PA segment no 2 will be generated for C1, P1 and M1.

Now you can do a realignment so that the earlier entry (PA segment 1) will be filled with M1. However realignment could be done only because the derivation logic was based on product and customer. If it was based on some other logic or on chars that are not filled in table CE4XXXX because of KEQ3 settings. Realignment would not be possible since realignment only touches the CE4XXXX table.

How are values changed in realignment ?

  1. With a valid derivation rule which will change the value. If a characteristic is supposed to be derived again in the realignment, the source fields of the corresponding derivation steps must be filled in table CE4XXXX.
  2. Values can also be changed in realignment by giving a fixed value for the characteristic to be realigned. In the ‘ConversRule’, in the block ‘Characteristics to have values replaced’ you can specify the new value of the characteristic.

  

In the example above you select only PA segments having FKART = F1

In the selected PA segments EFORM will be changed if there is a valid derivation rule. However BONUS will be replaced with ’02’ for all selected PA segments.

How is derivation processed in realignment mode ?

All derivation steps are processed in the “Overwrite” mode but as soon as a derivation step has changed a characteristic value all later derivation steps that refer to the same characteristic are processed according to their definition in the ‘Attributes’ settings. This is actually the same scenario as if derivation was processed for an INITIAL char value: the first step wins (independent on the ‘Attribute’ settings), later steps will only overwrite if they are defined like this.

When should realignment be run ?

Realignment should be run basically in 2 cases:

1. When you have introduced a new characteristic and you want to update this in the existing PA segments.

2. When you have changed your derivation logic /master data and you want this to reflect in your existing PA segments.

Realignment does not automatically get triggered if one of the above activities is done. It has to be run manually.

I have come across some customers who run realignment as part of their month end. This is wrong !! Realignment should only be run in the special cases listed above.

 

What is the use of validity date in realignment ?

I recently came across a customer who was running realignment with a future date !! This is meaningless !

In case of realignment the derivation always happens with the current date / system date. So if a validity date in the future is given no derivation / realignment will happen. However if a validity date in the past is given (<= system date) then derivation/ realignment will happen irrespective of how far the date is in the past.

The reason we have a validity date is that in case of normal derivation (without realignment) i.e. when you post a sales order or a billing doc certain characteristics need to be derived. The derivation here always happens with the document date (and not the posting date / system date). Typically the doc date will always be in the past. In this case the validity date becomes important. For example you are posting a  sales order whose date is 2 weeks in the past (July). For a characteristic wwmdm you have a derivation rule with 2 rule entries one valid upto end of July and one starting in Aug. So in this case the rule entry valid upto end of July will apply.

To summarize when derivation is carried out for purpose of realignment only those rule entries of a derivation rule are considered that are valid at current date. The validity date is basically useful in case of normal derivation that happens when you post data from SD, FI etc to COPA.

Can realignment be done based on posting period or date ?

I have come across customers who want to do realignment based on posting period. This basically means they don’t undertand the concept of profitability segments !

PA segments are time-independant.

To explain this let us take a very simple example. Let us say you have only 2 characteristics product and customer. Assume you have only 2 products P1 and P2 and 2 customers C1 and C2. So you have 4 possible combinations ( 4 entries in CE4XXXX)

PA segment no     combination

1                              P1C1

2                              P1C2

3                              P2C1

4                              P2C2

 

Now whenever you post say an invoice the system will check the customer and product and choose the PA segment. This is irrespective of the period or fiscal year.

So the above PA segments could be used for example 10 years.

However when the posting is done to the CO-PA line items table CE1XXXX the posting date is filled since line items are time dependant.

Hence it is not possible to do realignment based on posting date or period.

Is it possible to schedule periodic KEND jobs ?

This is not possible because it’s not allowed to execute the same realignment run a second time since each realignment run creates entries in table CE4XXXX_KENC with the realignment run number in field CHGRUN so that there would be duplicate records in this table if the same segment number PAOBJNR was changed twice by the SAME realignment run (instead of using a different realignment run at second time what would be the correct procedure). In other words: each realignment run can be executed only ONCE !
Note 399997 usually prevents a realignment run from being executed twice (by checking whether the realignment run was already executed) but this check fails if of the status of this realignment run is ‘Running’. If the status would be ‘Successful’ there would be an error message stating that the realignment run can’t be executed anymore.
Since you really shouldn’t execute the same realignment run twice you should create a new realignment run for next execution of the same realignment (by copying the old realignment run within transaction KEND)
This is the proper way to iterate a realignment. Periodic scheduling is not possible.

Can realignments be reversed ?

When you do a realignment the system stores the old PA segments in table CE4XXXX_KENC, so it is possible to reverse the realignment if the definition of the realignment run has been preserved (transaction KEND: Run/request   > restore).
Realignment does not change the PA segment no. The restore of a realignment run does nothing else than changing the content of CE4XXXX segment numbers back to their original values.

How to get the history of a realignment run ?

If you double-click on a realignment run at the first KEND screen you get more details about it. Clicking on the magnifying glass behind the ‘update run’ entry in the ‘Change history’ list will tell you who executed this realignment.

What is the effect of realignment on summarization levels ?

Customers are confused when they find summarization levels deactivated and want to know the reason. Realignment could be one of the reasons.

When you do realignment only those summarization levels which contain a characteristic which was changed during realignment are deactivated

i.e. status is set to ‘active without data’. These summarization levels have to be rebuilt. Not all the summarization levels have to be rebuilt; only those which are deactivated due to realignment.

 

KE24

Transaction KE24 can be run in two modes: ‘read as posted’ or ‘read according to current structure’. If you select ‘read as posted’ the system simply reads the CE1XXXX line items. If you select ‘read according to current structure’ then there is a join on CE4XXXX and CE1XXXX so that realignment is taken into consideration.

In case you open a costing based CO-PA document from the original application i.e. VF03/FB03/MB03 –> Accounting Documents –> Profitability Analysis then it will always be read in ‘read as posted’ mode. If you want to see the effect of realignment then you need to use transaction KE24 to view the document.

Realignment in SFIN

Realignment is available from S/4 HANA OP 1610. Realignment can be implemented in S/4 HANA Finance OP 1605 via notes 2344759 and 2350123. The realignment functionality is not supported for account based CO-PA in SFIN for the lower releases. If only costing based CO-PA is active then realignment is possible.

Realignment in S/4 HANA is explained in my Expert Webinar which is recorded in KBA                  2444746 [Expert Webinar] S/4 HANA Finance: Controlling and Profitability Analysis (CO-PA)

Realignment of characteristics in ACDOCA of attributed PA segments can be achieved using the flag ‘Rederivation of ACDOCA Characteristics for Attributed Line Items’ in KEND.  The option ‘Rederivation of ACDOCA Characteristics for Attributed Line Items’ in KEND only affects line items in table ACDOCA. It does not affect the attributed profitability segments in table CE4XXXX. This logic prevents undesirable side effects as the profitability segment might be used in another process which would then show an incorrect attribute.

 

I hope the above info helps to clear some misconceptions on realignment. I will update this blog whenever i come across some new experiences on this topic

Assigned Tags

      20 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Murali Babu Nallamothu
      Murali Babu Nallamothu

      Dear Waman,

      Thanks for your efforts.

      Author's profile photo Prasad Bollineni
      Prasad Bollineni

      Thanks for clarification.

      Author's profile photo Former Member
      Former Member

      Thank you very much waman for your valuable inputs.

      Author's profile photo Miya Wang
      Miya Wang

      This is really helpful!

      Author's profile photo veenu gulati
      veenu gulati

      It was helpgful....

      Author's profile photo Former Member
      Former Member

      Thanks a lot. That clears many things. 🙂

      Author's profile photo Hrusikesh Dalai
      Hrusikesh Dalai

      Waman I can say you are one of the finest contributor in SCN, By looking at your replies and sharing of high quality content is very helpful.

      Author's profile photo Former Member
      Former Member

      Hello Waman,

      Thanks for this superb information.

      The information is very well explained and is very informative.

      Author's profile photo Former Member
      Former Member

      Thanks a lot Warman.

      Author's profile photo Srinivas Salpala
      Srinivas Salpala

      Hi waman,

      Given a very good clarity on usage of Realignment.

      Thanks for sharing!!

      BR, Srinivas Salpala

      Author's profile photo Former Member
      Former Member

      Hi Waman - Is it possible to do a realignment WITHOUT realigning the PLAN values?  We only want to realign the actual values.

      Thanks

      Author's profile photo Waman Shirwaicar
      Waman Shirwaicar
      Blog Post Author

      Hi Michael,

         
           No this is not possible. Realignment only works on the PA segments stored in table CE4XXXX. PA segments are not created separately for actual or plan data.

      regards

      Waman

      Author's profile photo Former Member
      Former Member

      Is COPA on HANA would require CE4xxxx (side car method) ? Would it accelerate KE28 distributions?

      Author's profile photo Waman Shirwaicar
      Waman Shirwaicar
      Blog Post Author

      Hi,

          Answer to both questions is YES.

          The CE4XXXX table has to be replicated in HANA. Also COPA on HANA will accelerate KE28

      regards

      Waman

      Author's profile photo Bushair Thayyil
      Bushair Thayyil

      Hi Waman,

      I have added two new characteristics in the COPA and trying to Re-align to get the Ke30 updated. Most of the line items got the new characteristics but some are still not getting changed through the KEND despite the selection finds the line. the change is Zero. What can be the reason for not changing the line items. How can I force to get them updated.

      Author's profile photo Waman Shirwaicar
      Waman Shirwaicar
      Blog Post Author

      Hi Bushair,

           Firstly the realignment only changes the PA segment (CE4XXXX) and not line items (CE1XXXX). KEND will be only able to change the PA segments via derivation. So the source fields for the derivation rule should be available in CE4XXXX and the derivation rule should be able to find the target fields. Please check if that is possible

      regards

      Waman

      Author's profile photo Pawan Patil
      Pawan Patil

      Hi Waman,

      First of all thanks for such a detailed explanation.
      For me, Regular / Clearing indicator derived incorrectly in COPA.

      Issue: In Sales order, the business segment for clearance sales was recorded correctly as C, but when it was released to COPA it got recorded as Regular sales (R).

      Fix: the issue got fixed at user exit level.

      My question:
      To fix the COPA documents in mass to correct the business segment (R to C) for already posted cases.

      Please note that KE4S cannot be used because it cancels and rebooks documents in CLOSED accounting periods. Therefore we would change historic data. Is there anyway, where we can book COPA in the current period?

      Thank you!

      Author's profile photo Adimallaiah Thumula
      Adimallaiah Thumula

      Hi Warman,

      Is it possible to change the Functional Area for the Historical Data (Already posted data in SAP)?

      In one of the blog & SAP Note 638097 describes it is not possible.

      https://s4hanablog.com/2017/03/02/realignments-in-account-based-co-pa/

      Thanks for your inputs.

      Author's profile photo Waman Shirwaicar
      Waman Shirwaicar
      Blog Post Author

      Hi,

      Functional area can be changed by realignment in CE4XXXX / CE4XXXX_ACCT but not in ACDOCA.

       

      regards

      Waman

      Author's profile photo Adimallaiah Thumula
      Adimallaiah Thumula

      Hi Waman,

      Thanks for your quick reply.

      BR,

      ADI