Condition changes with mekp mekr and mekl

Condition changes 12-04-23

Condition changes

(Purchasing)

Version 1.10(4. March-2002)

1


Condition changes..............................................................................................................3Remarks..............................................................................................................................5

Batch-Input...................................................................................................................................................5Absolute amount...........................................................................................................................................5Condition tables............................................................................................................................................5

The program-flow..............................................................................................................5Problems.............................................................................................................................5Currency conversions........................................................................................................5

MEKP, MEKR, MEKL................................................................................................................................5MEKPE, MEKRE, MEKLE.........................................................................................................................5

Notes....................................................................................................................................5Data inconsistencies...........................................................................................................5

The link between inforecords and their conditions......................................................................................5Creating new validity periods.......................................................................................................................5Problems in customer systems......................................................................................................................5Analysis........................................................................................................................................................5

2


Condition changesIn purchasing there are three different transactions to change the conditions related to outline-agreements and purchasing info records.1. MEKP (RM06K050) for info records2. MEKR (RM06K051) for contracts3. 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 SIEDLERMaterial HOLZPurch.Org. 0001Plant 0001

The following conditions are in the system:

Validity period Condition type Scale Value18.Jan 2000 – 12.Apr 2000 PB00 313.Apr 2000 – 30.Apr 2000 PB00 1 5

100 4,51000 4

1.May 2000 – 31.May 2000 PB00 1 5100 4,51000 4

1.June 2000 – 30.June 2000 PB00 1 5,2\ 100 4,7

1000 4,31.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-InputThe 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 amountNo 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 tablesOnly the standard condition tables are taken into account. Self-defined condition tables are not affected.

Outline Agreements:A016 Contract ItemA019 Contract HeaderA068 Outline Agreement Item: Plant-DependentA081 Contract Conditions at Plant Level (Service !)A082 Contract Conditions without Plant (Service !)

Info Records:A017 Material Info Record (Plant-Specific)A018 Material Info RecordA025 Info Record for Non-Stock Item (Plant-Specific)A028 Info Record for Non-Stock ItemA066 Info record per order unitA067 Plant Info Record per Order UnitA0160 Plant Info Record: VariantsA0161 Info Record: Variants

11


12


The program-flowAll 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 periodOnline START_OF_SELECTION_P:

KONDITIONEN_SELEKTIERENCHANGE_CONDITIONSCTAB_FUELLENAUSGABE_P1

AT_USER_COMMAND:UPDATE_CONDITIONS

START_OF_SELECTION_P:KONDITIONEN_SELEKTIERENCHANGE_CONDITIONSCOPY_CONDITIONS

AT_USER_COMMAND:COPY_CONDITIONS

Background START_OF_SELECTION_P:KONDITIONEN_SELEKTIERENCHANGE_CONDITIONSCTAB_FUELLENAUSGABE_P1

BUCHEN = ‘X’

UPDATE_CONDITIONS

START_OF_SELECTION_P:KONDITIONEN_SELEKTIERENCHANGE_CONDITIONSCOPY_CONDITIONS

BUCHEN = ‘X’

COPY_CONDITIONS

ProblemsMost of the problems that occurred in the last year were caused by data inconsistencies:Overlapping validity-periodsMultiple 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, MEKLWithin 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, MEKLEIf 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.

355670Dumps in MEKP, MEKR, MEKL are often caused by data inconsistencies. Report Z_CORR_PURCOND can detect some inconsistencies and repair a few.

444587Wrong conversion factors after condition-change due to missing CLEAR-commands.

428669Price and currency of a future validity-period are written into the inforecord.

410886No change-documents were written. No change-messages were created for contracts or scheduling agreements.

377182Program 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).

394426Inforecords on the Purchasing Organisation level are not converted correctly (4.0 – 4.5).

398067Program dumps with SAPSQL_ARRAY_INSERT_DUPREC for tables KONM or KONW (scales). Attention: This note did contain an error in a previous version.

442549Contains 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).

209720Message 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.

179495When 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.

170344Rounding problems when changing conditions of an outline agreement

164772Changing 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.

213721

16


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.

392988Report RM06INP0 can be used to update the price/currency in an inforecord from the conditions.

410331When 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 conditionsAs an example the pictures demonstrate the link between the inforecord and its conditions (for material with and without plant)

17


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 periodsWhen 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

Problems in customer systemsWe 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:

AnalysisThe 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

Education

Transcript of Condition changes with mekp mekr and mekl