One or more of the following commonly occurring symptom(s) affecting purchase order(s) and/or scheduling agreement(s) or their follow-on documents in your system, due to inconsistency in EKES, EKET or EKBE table(s):
- More than one line appears for a purchasing document in MD04
- Confirmation's MRP relevant quantity was not reduced, hence MRP still calculates with it
- Not correct values appearing at reporting, in purchase order history or at schedule lines overview
- MRP element ’POitem’ still visible in MD04 after posting Inbound Delivery
- MRP element ’ShpgNt’ still visible in MD04 after posting GR
- Negative quantity in MD04 even after goods receipt is posted
- The receipt quantity in MD04 is inconsistent from PO History
- Editing (Inbound or Outbound) Delivery is not possible, also may dump happens
- Incorrect stock in transit quantity in MB5T based on PO history
- Reversing/cancelling of a GR (goods receipt) or a GI (goods issue) or a delivery is not possible, error message M7 328 (Deficit of Delivered quantity...) also may raised
- Check if there is a real inconsistency in the involved tables
- according to the symptom search for a correction report from the below list.
- make sure the correction reports are available in the system.
- start the report(s) in Test mode first, then in update mode to correct false entries.
Symptoms and correction reports to solve them:
Inconsistency in "MRP reduced" values in confirmation and schedule lines:
|Symptom||Correction Report||from Note||Additional info|
|Incorrect DABMG (MRP reduced quantity) values in tables EKET, EKES||ZCORRDABMG||202875||This is the most commonly helpful and used report|
|EKES-MENGE <> EKES-DABMG||ZZ_COMPLETE_ASN|
|636853||In case if update within EKES table was incorrect|
|EKES-DABMG updated incorrectly for inbound delivery||ZCORR_EKES_PO||1247578||Inbound delivery is posted and has movement status 'C'.|
Incorrect EKET-DABMG and / or
Usually this inconsistency (or below) cause M7 328 error
The report won't work for confirmation controls in which the corresponding confirmation category is not have the "GR assignment" (WEZUO) checkbox in customizing
You cannot use it if you switched between 'No GR assignment' and 'GR assignment'
Above reports work only if the EKPO-ELIKZ (delivery completed) indicator is NOT ticked, and if the "GR-assignment" checkbox is ticked for the used confirmation type in the used confirmation control customizing!
Inconsistency between or within scheduling lines and PO History:
|Symptom||Correction Report||from Note|
Additional symptom which solvable with the report
|EKBE-MENGE <> EKET-GLMNG (incorrect EKET-GLMNG)||ZKOGLMNG||100690|
Cannot delete delivery, mainly for STO / SA problems. Used in case when the delivered quantity at the schedule line level is not equal to the actual quantity delivered (in history tables)
it is created to handle issues with STO’s having old scheduling logic! (not the one described in Note 885177)
|EKET-WEMNG > EKET-WAMNG (incorrect EKET-WEMNG)||ZKOWEMNG|
|EKET-MENGE < EKET-WAMNG or EKET-MENGE < EKET-GLMNG (incorrect EKET-MENGE)||ZKOMENGE|
SAPSQL_ARRAY_INSERT_DUPREC dump at insert to EKPO, EKET
usable when scheduled quantity is not equal to GI/GR quantity
|EKET-WEMNG <> EKBE-MENGE (incorrect EKET-WEMNG)||ZKORWEM2||The report was changed to include the new schedule line processing also (see Note 885177)!|
|EKET-WAMNG <> EKBE-MENGE (incorrect EKET-WAMNG)||ZKOWAMNG||Could solve MESSAGE_TYPE_X, TABLE_INVALID_INDEX dumps|
|EKET-WEMNG <> EKBE-MENGE (incorrect EKET-WEMNG)||ZKORWEMN3||Problems with delivery also|
|EKET-WEMNG <> EKBE-MENGE (incorrect EKET-WEMNG for RETURN ITEMS)||ZKORWEMN4||Reverse, or return not possible|
|Inconsistency in EKET-GLMNG, EKET-WEMNG and in EKET-WAMNG together||ZZ_CORR_EKET_WEMNG_WAMNG_GLMNG||Tip: run this also, if none of the above (from note 100690) helps|
If the report doesn't correct the document, or you would like to know more about the application logic of the reports, refer to the debugging guides in the following Wiki page: Debugging Guides for correction reports.
Additionally helpful reports for missing or incorrect table entries:
Correction Report (3)
History for the delivery contains incorrect quantity
Order history for delivery does not exist
EKES-MENGE after reversal of goods is incorrect
EKES entry exists but delivery (item) already deleted
If the inbound delivery exists but individual delivery
Missing EKES entry for the inbound delivery
Incorrect ETENS numbering in EKBE
Ensure that ETENS numbering is passing to EKES entries
|The outbound delivery already deleted (from table LIKP) |
but still remained in the PO History (table EKBE)
|it can correct cases where the entire delivery, is deleted, not just its item(s)|
Correction report for completing open inbound deliveries in case the GR already exists
Incorrect EKES-ETENS numbering
In case of overflow in EKES-ETENS field or
If you observe further problems with Deliveries probably due to inconsistency, checkout KBA 2006809 - Composite SAP note: How to fix delivery-related inconsistencies
If the correction report not solved the observed problem, contact SAP Support, by describing the steps you did, and explaining the observed inconsistency.
Please keep the correction reports also available in your system after own checking.
Additional symptoms and resolution:
Dump MESSAGE_TYPE_X LIS_VERTEILUNG_LF while editing delivery (deleting, canceling, etc.):
- Firstly please try to run the correction report ZZ_CORR_EKET_WEMNG_WAMNG_GLMNG from SAP Note 100690 for this dump. If that not helps, please continue with belows:
- The dump is possibly caused by inconsistency, please see the solution of note 431145:
"Use correction report ZKOEKBE to get an overview of the number of incorrect updates. and to have a consistent status for the replenishment delivery again.
Then use report ZKOGLMNG from note 100690 in order also to correct the quantity delivered of the purchase order delivery schedule line."
- If these reports not helped, please read note 167242 and use the two mentioned 2 correction reports:
- The first report (ZKOEKB1) checks for inconsistencies on table EKBE and fixes them.
- The second report (ZKORWEMN3) fixes inconsistencies between tables EKBE and EKET.
Dump BIT_OFFSET_NOT_POSITIVE could be caused by incorrect EKES-ETENS numbering or SAPSQL_ARRAY_INSERT_DUPREC dump due to that an EKES record with the value '0000' in the field ETENS is created or other specific system problem occurs related to incorrect numbering of schedule lines:
- Check out this TSG for solution suggestion.
If you observe further problems with deliveries, probably due to an inconsistency, checkout note 2006809 - Composite SAP note: How to fix delivery-related inconsistencies
The root cause of the above inconsistencies are not known. According to SAP-Support knowledge, from SAPKH60610 SAP-APPL Support Package level with also implemented notes: 1860803, 1911909, 1941146, 1960756, 1967549, 1979068, (2086182 also in case you use IS-AFS - Apparel and Footwear) the system is more reliable and less inconsistencies occur.
Please be aware that the above stated reports are not in the standard SAP system by default. You need to open the corresponding note and copy the reports' program code manually from the note's correction instructions - then you need to create the report in SAP System with SE38 transaction and activate them - or implement it via SNOTE.
All of the mentioned reports can be run in all of the currently supported SAP ERP and SAP S/4Hana systems.