Condition changes with mekp mekr and mekl

Condition changes 19-05-10

Condition changes
(Purchasing)
Version 1.10
(4. March-2002)

1


Condition changes..............................................................................................................3
Remarks............................................................................................................................10
Batch-Input.................................................................................................................................................10
Absolute amount.........................................................................................................................................10
Condition tables..........................................................................................................................................11
The program-flow............................................................................................................13
Problems...........................................................................................................................13
Currency conversions......................................................................................................14
MEKP, MEKR, MEKL..............................................................................................................................14
MEKPE, MEKRE, MEKLE.......................................................................................................................16
Notes..................................................................................................................................16
Data inconsistencies.........................................................................................................17
The link between inforecords and their conditions.....................................................................................17
Creating new validity periods.....................................................................................................................18
Problems in customer systems....................................................................................................................18
Analysis......................................................................................................................................................19

2


Condition changes
In purchasing there are three different transactions to change the conditions related to outline-agreements
and purchasing info records.
1. MEKP (RM06K050) for info records
2. MEKR (RM06K051) for contracts
3. MEKL (RM06K052) for scheduling agreements

These programs mainly contain the selection criteria, as the whole functionality is located in the module
pool SAPFM06K.

The selection masks are quite simple and similar:

3

For an example:

U9B:
Vendor SIEDLER
Material HOLZ
Purch.Org. 0001
Plant 0001

The following conditions are in the system:

Validity period Condition type Scale Value
18.Jan 2000 – 12.Apr 2000 PB00 3
13.Apr 2000 – 30.Apr 2000 PB00 1 5
100 4,5
1000 4
1.May 2000 – 31.May 2000 PB00 1 5
100 4,5
1000 4
1.June 2000 – 30.June 2000 PB00 1 5,2
100 4,7
1000 4,3
1.July 2000 – 31.July 2000 PB00 6
RB00 1-
FRA1 10%
1.Jan 2002 – 31.Dec 2900 PB00 3

4


With the time given as a period, the condition valid at the start of this period is taken, changed and all the
following conditions within the period are overwritten. A new validity period is created.

5


If only one date is given, only the condition valid at that date is changed. The validity date stays the same
and all the other conditions are not affected.

6


All the prices within the scale are changed and also the validity period is changed.

7


Only the base-price is changed.

8


The system searches for the first calculation in which the condition FRA1 is present, changes that and
changes the validity date of the whole price.

9


Remarks

Batch-Input
The transactions cannot be used with Batch-Input. Instead of this, the underlying reports should be called
via “submit report”. An example for this is the report SAPREWU5.

Absolute amount
No currency can be entered here, so conditions in different currencies may lead to different results:

For plant 0001, PB00 is increased by 1 DM, for plant 0002 by 1 USD.

10


Condition tables
Only the standard condition tables are taken into account. Self-defined condition tables are not affected.

Outline Agreements:
A016 Contract Item
A019 Contract Header
A068 Outline Agreement Item: Plant-Dependent
A081 Contract Conditions at Plant Level (Service !)
A082 Contract Conditions without Plant (Service !)

Info Records:
A017 Material Info Record (Plant-Specific)
A018 Material Info Record
A025 Info Record for Non-Stock Item (Plant-Specific)
A028 Info Record for Non-Stock Item
A066 Info record per order unit
A067 Plant Info Record per Order Unit
A0160 Plant Info Record: Variants
A0161 Info Record: Variants

11


KNUM H+ KO NM
EKKO KO PO S Q u a n tity - s c a le

O u t lin e KO NH KO NP
E B E L N :V A K E Y C o n d it io n s KNUM H C o n d it io n s
a g re e m e n t (H e a d e r) ( P o s it io n s )
KNUM H KNUM H+ K O N W V a lu e -
E B E L N :E V R T N A019
KO PO S s c a le

K A P P L = 'M '
EBELN

EKPO
EBELN +EBELP: KNUM H+ KO NM
O u tl.a g r .
VAKEY KO PO S Q u a n tity - s c a le
p o s it io n

EBELN+EBELP: KO NH KNUM H KO NP
EVRTN+EVRTP
KNUM H KNUM H+ K O N W V a lu e -
KO PO S s c a le
K A P P L = 'M ' A016
EBELN+EBELP:
EVRTN+EVRTP

KNUM H

K A P P L = 'M ' A068

W E R K S = '? '

E IN A
P u r.In f.-
re c o rd

IN F N R

: KNU M H+ KO N M
E IN E
VAKEY KO PO S Q u a n tity - s c a le
EKO RG +ESO KZ
KN UM H KO N H KNU M H KO N P

KNU M H+ K O N W V a lu e -
L IF N R + M A T N R
KO PO S s c a le
A018, A066,
L IF N R + M A T N R
K A P P L = 'M ' A161

KN UM H
EKO R G +W ERKS+ESO KZ

A017, A067,
L IF N R + M A T K L K A P P L = 'M '
A160

EKO R G +W ERKS+ESO KZ

K A P P L = 'M ' A025

EKO R G +ESO KZ
K A P P L = 'M ' A028
L IF N R + M A T K L

12


The program-flow
All the transactions use the routine START_OF_SELECTION_P(SAPFM06K) to perform their work. For
the routines performed, two things are important:
1. Is the transaction called online or running in the background ?
2. Does the transaction have to change validity periods or not (was there a time period given or
only a single date) ? According to this, a variable named V_VORGA is set to P1 (one date) or
P2 (a time period).

Single date Time period
Online START_OF_SELECTION_P: START_OF_SELECTION_P:
KONDITIONEN_SELEKTIEREN KONDITIONEN_SELEKTIEREN
CHANGE_CONDITIONS CHANGE_CONDITIONS
CTAB_FUELLEN COPY_CONDITIONS
AUSGABE_P1

AT_USER_COMMAND: AT_USER_COMMAND:
UPDATE_CONDITIONS COPY_CONDITIONS

Background START_OF_SELECTION_P: START_OF_SELECTION_P:
KONDITIONEN_SELEKTIEREN KONDITIONEN_SELEKTIEREN
CHANGE_CONDITIONS CHANGE_CONDITIONS
CTAB_FUELLEN COPY_CONDITIONS
AUSGABE_P1
BUCHEN = ‘X’
BUCHEN = ‘X’
COPY_CONDITIONS
UPDATE_CONDITIONS

Problems
Most of the problems that occurred in the last year were caused by data inconsistencies:
Overlapping validity-periods
Multiple entries in a condition table for the info-record/contract but with different material groups (not
reproducible, but I have the suspect that they somehow mixed data from two different systems)

13


Currency conversions

MEKP, MEKR, MEKL
Within the transaction MEKP, MEKR and MEKL it is possible to change the currency of conditions. This
will only work if the value of the conditions is changed also.

Please notice, that for the second info-record with currency USD only the value is changed.

14


If we have two different currencies within the conditions of one info-record

Even though there is no condition ZOC1, the currency of the second info-record is changed. At the moment
when it is decided if the currency conversion is to be done, it is only checked if there is a value-change at
all, it is not checked if the current info-record is affected.

15

MEKPE, MEKRE, MEKLE
If no values are to be changed in the conditions but only the currency, the transactions MEKPE
(RM06K080), MEKRE (RM06K081) and MEKLE (RM06K082) are to be used.

Notes
• 458384
FAQ for currency changes in purchasing
• 456690
FAQ for conditions in purchasing
• 498553
Correction reports for conditions in purchasing
• 482565
A dump occurs in transaction MEKP or MEKPE. If it is a data inconsistency, this note
contains a modification that can be used to determine the inforecords that cause the
dump.
• 355670
Dumps in MEKP, MEKR, MEKL are often caused by data inconsistencies. Report
Z_CORR_PURCOND can detect some inconsistencies and repair a few.
• 444587
Wrong conversion factors after condition-change due to missing CLEAR-commands.
• 428669
Price and currency of a future validity-period are written into the inforecord.
• 410886
No change-documents were written. No change-messages were created for contracts or
scheduling agreements.
• 377182
Program dumps with DBIF_RSQL_INVALID_RSQL if a lot of conditions are selected.
It is also possible that inforecords on the Purchasing Organisation level are not converted
correctly (4.6).
• 394426
Inforecords on the Purchasing Organisation level are not converted correctly (4.0 – 4.5).
• 398067
Program dumps with SAPSQL_ARRAY_INSERT_DUPREC for tables KONM or
KONW (scales). Attention: This note did contain an error in a previous version.
• 442549
Contains a report and a modification to fix the problems caused by earlier version of note
398067 (modification has to be removed after fixing the problems).
• 209720
Message V1 280 appeared when trying to change the conditions of an outline agreement
that had been created for a Purch.Org. which was not assigned to any company code. If
this case appears now, the company code will be read directly from the outline
agreement.
• 195266 (only for 3.1I)
A short dump appeared when the reports RM06K050/051/052 were called from self-
written programs via submit report.
• 179495
When running the condition changes for multiple outline agreements at one time, the
position price in the first selected outline agreement was set wrong even the conditions
were changed correctly.
• 170344
Rounding problems when changing conditions of an outline agreement
• 164772
Changing one condition (RA01) with MEKR deleted other conditions (PBxx) for the
given time-period. In 4.0B (and higher releases) a percentage could was changed to an
absolute value.

16

• 213721
Rounding problems when changing conditions of an info-record.
• 180242
When running MEKP with only a change of currency but no change in the value for a
gross price, the gross price stayed unchanged, but the currency of the other conditions
was changed.

• 392988
Report RM06INP0 can be used to update the price/currency in an inforecord from the
conditions.
• 410331
When creating a PO and conditions are copied from the last PO, this note contains a
modification to change the currency of these conditions.

Data inconsistencies

The link between inforecords and their conditions
As an example the pictures demonstrate the link between the inforecord and its conditions (for material
with and without plant)

EINA EINE A017 KONH

LIFNR KAPPL='M' KNUMH

MATNR KSCHL KVEWE='A'

INFNR INFNR LIFNR KOTABNR='017'

EKORG MATNR KAPPL

ESOKZ EKORG KSCHL

WERKS ESOKZ VAKEY

WERKS DATAB

DATBI DATBI

DATAB

KNUMH

17


EINA EINE A018 KONH

LIFNR KAPPL='M' KNUMH

MATNR KSCHL KVEWE='A'

INFNR INFNR LIFNR KOTABNR='018'

EKORG MATNR KAPPL

ESOKZ EKORG KSCHL

WERKS=' ' ESOKZ VAKEY

DATBI DATAB

DATAB DATBI

KNUMH

The KNUMH is the unique key of the table KONH.
The VAKEY in the KONH is build from the key-fields of the Axyz-table except MANDT, KAPPL,
KSCHL and DATBI.

Creating new validity periods
When creating new validity periods, two possibilities exist:
• We create conditions for a time period for which until now no conditions existed
• We overwrite existing conditions

1.1.2001 1.1.2002 31.12.2002

Inforecord

A018

KONH

create a new validity period create a new validity period
from 1.10.2001 - 1.4.2002 from 1.7.2001 - 1.10.2001

A018 A018

KONH KONH

there can be multiple
validity periods in
Axyz-records pointing to
KONH may overlap
the same KONH record
(they are irrelevant)
(but not the other way
around)

Problems in customer systems
We already encountered different situations in customer systems.

18


The ‘easiest’ is when there is one KONH-record for one Axyz-record and simply the VAKEY does not
correspond to the content of the key-fields of the Axyz-record.
This one can be determined and solved with report Z_CORR_PURCOND from note 355670.

Other situations are the cases 2 and 3 from the following picture:

1 2 3
A018
KAPPL='M' A018 A018 A018
KSCHL M M M
LIFNR PB00 PB00 PB00
MATNR SIEDLER SIEDLER SIEDLER
EKORG WOOD WOOD WOOD
ESOKZ 0001 0001 0001
DATBI 0 0 0
DATAB 1.1.2002 1.1.2002 1.1.2002
KNUMH 1.1.2000 1.1.2000 1.1.2000
1000456 1000456 1000456

A017
KAPPL='M' A018 A018 A017
KSCHL M M M
LIFNR PB00 PB00 PB00
MATNR SIEDLER SIEDLER SIEDLER
EKORG WOOD WOOD WOOD
WERKS 0001 0002 0001
ESOKZ 0 0 0001
DATBI 31.12.9999 1.1.2002 0
DATAB 10.3.2002 1.1.2000 1.1.2002
KNUMH 1000456 1000456 1.1.2000
1000456

1 is ok, because: 2 is not ok, because: 3 is not ok, because:
validity-periods are not the fields that are the fields that are used to
overlapping and the fields that used to construct construct the VAKEY do
are used to construct the the VAKEY do not not have the same content
VAKEY have the same have the same (A017 has WERKS as
content content additional field)
and
different condition tables
need different entries in
field KOTABNR in KONH

same KNUMH for different
same KNUMH and same same KNUMH in different
(non-overlapping) validity
validity period condition tables
periods

Analysis
The general approach when encountering a dump in one of the transactions MEKP, MEKR or MEKL is to
identify if the dump is caused by single inforecords/agreements or not.
If the dump occurs even if the transaction is called for only one inforecord/agreement, it is necessary to find
out which condition tables are used and manually check the consistency of the entries.
If a problem (dump or other) only occurs if transaction is called for multiple records but works fine for
single records, the following notes could be checked:
• 444587
• 377182
• 394426
• 398067
• 179495

19


20

Condition changes with mekp mekr and mekl

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

More from armindajack

More from armindajack (7)

Recently uploaded

Recently uploaded (20)

Condition changes with mekp mekr and mekl