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 ?
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
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 ?
- 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.
- 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
- SAP Managed Tags:
20 Comments
