Consistency Checks during Profile Value Import

Consistency checks are used to check the validity of the profile values imported into the system. SAP provides 2 standard checks: Overlap (to check if values are imported for the same period again) and Status (to check if the status of profile values for import is valid or not).

The checks can be grouped together in consistency check groups and given priority in execution. We have 3 different actions based on the execution of the check. These are as below:

• Profile values not saved.
• Profile values not saved. Cancel import.
• Profile values saved despite errors.

Consistency Check groups is defined at the profile header and is not a mandatory parameter to be filled during creation of profile header. So it can changed at any point of time.
Here I have defined a consistency check group named ‘flatline’ which logs a message if there are continuous 3 “same” readings.

Below I will show the execution for all the 3 actions for this custom check group.

Above is the new consistency check and have allocated the custom function module. This module holds the logic for capturing ‘flatlining’.
Here for the custom check, the action has been defined as ‘profile values saved despite errors’.

Below I have assigned the consistency check group at the header level.

Now the profile import has been done and we can see the values have been imported successfully. The screenshot below shows 902 imported more than 3 times for continuous periods. So basically my code for ‘flatline’ should have captured this.

If I check the logs I can see logs for the same in warning. The profile values were still imported as the action was to save the profile values despite errors.

Now the action has been changed to ‘profile values not saved. Cancel import’. As we can see the profile values were not imported and the log shows the same.

Now the action has been changed to ‘profile values not saved.’ As we can see the profile values were not imported and the log shows the same.

Now below I have executed the standard check of ‘overlap’. The profile import has been done, the action defined was Profile values are saved despite errors.

The log captures the warning messages.

Now below I have executed the standard check of ‘status’. The profile import has not been done, even though the action defined was Profile values are saved despite errors. This happened because the error code describing such an event was not defined.

The standard function module for the consistency check provided by SAP are below:
ISU_EDM_CONS_CHECK_STATUS
ISU_EDM_CONS_CHECK_OVERLAP

That’s it. A primer on how consistency check group works. 🙂

Analysis of Variant COMPUT25

COMPUT25 variant program helps to calculate the weighted quantity based average price.
The Input parameters are
> QPRICE Price
> USERDEF Start date for the calculation of an average (YYYYMMDD)

The Output parameters are
> QPRICE Time portion weighted average of all prices in the period

The standard function module for this variant is ISU_COMPUT25

Now let’s try to analyze the effect of using COMPUT25 in a schema.
Standard documentation on the Variant and the line item types generated can be found by executing TCode EA99.

A price is multiplied by a factor. This new price is updated (operand update). Prorations of the factor are taken into account.
Let’s start by creating a Rate:

Rate Header

For convenience of understanding only two line items.

Rate steps

Facts values:

Rate Facts

ZQPRICE is a Quantity Based Standard Price

ZQPRICE is Quantity Standard Price

ZAVGPRICE is an Average price Without History.

ZAVGPRICE is Average price Without History.

Average is calculated during the rate period. In this case, the value of the second operand (USERDEF) is not included. However, we still need to define a value for this operand in the facts.

Test Cases:
(A).

Controls for Variant COMPUT25

1. No Price Change
Billing Period: From – 01.01.2011 to 30.01.2011

Test Case A 1

This is in case there is no price change in the current billing period.
Avg. Price = (No. of Days in each weighed time portion * corresponding price in time portion) / Total no of days in billing period
In this case: Avg Price = (30 * 5) / 30 = 5.

2. One Price Change between the Billing Periods
Price Change on 15.01.2011

Test Case A 2

Prorated periods: 01.01.2011 – 14.01.2011 & 15.01.2011 – 31.01.2011
Avg. Price == ((14 * 5) + (16 * 6)) / 30 == 5.53333333

3.  Two Price Changes in the Billing Period
Price Change on 15.01.2011 & 20.01.2011

Test Case A 3

Prorated periods: 01.01.2011 – 14.01.2011, 15.01.2011 – 19.01.2011, 20.01.2011 – 31.01.2011
Avg. Price == ((14 * 4) + (5 * 6) + (11 * 6)) / 30 == 4.7Average is calculated during the period USERDEF, end of billing period. The average price is calculated by simulating the corresponding period. The simulation is a customer-specific simulation. You can use an IF12 variant to control which schema steps are executed during the simulation.

(B). 

Controls for variant COMPUT25 II

1.Two Price Changes in the Billing Period
Here we can see that in spite of two price changes in the same billing period system has updated the Average Price Key for the last prorated time portion only i.e., 20.01.2011 – 31.01.2011.

Test Case B 1

This is because we have maintained the Variant Control as USERDEF operand, for which value is maintained as 2011.01.20 (YYYY.MM.DD).So system will consider only those price changes which happened after the date maintained at USERDEF operand ,in this case i.e., 20.01.2011
Avg. Price = (10 * 5) / 10 = 5

2. Two Price Changes in the Billing Period
In this case, USERDEF has the value 2011.01.15.

Test Case B 2

So two price changes fall after this date and within the Billing Period. Therefore the Average Price Key is updated for the period between 15.01.2011 – 31.01.2011.
Avg Price == ((5*6) + (11*5)) / (5 + 11) == 5.3125

NB : If the checkbox is checked in the Control option.

Control variants for COMPUT25 III

An info line is written about the calculation method. The following fields are filled:
ZAHL1  :  Number of days in the period of average calculation
ZAHL2  :  Calculated average price
MASS2  :  Unit of measurement for the average price
ZAHL3  :  Quantity base of the average price
There are some test cases left like:

• Average Price updating in case of Block & Scale Type Quantity Based Price.
• Average Price Key with History.

These cases will be dealt in future posts.

Hope this helps. 🙂

This document is created by Tathagta Chakroborty.He is reachable at tatha.chako119@gmail.com