Skip to end of metadata
Go to start of metadata


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


  1. Check if there is a real inconsistency in the involved tables
  2. according to the symptom search for a correction report from the below list.
  3. make sure the correction reports are available in the system.
  4. 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:

SymptomCorrection Reportfrom NoteAdditional info
Incorrect DABMG (MRP reduced quantity) values in tables EKET, EKESZCORRDABMG202875This is the most commonly helpful and used report
636853In case if update within EKES table was incorrect
EKES-DABMG updated incorrectly for inbound deliveryZCORR_EKES_PO1247578Inbound delivery is posted and has movement status 'C'.

Incorrect EKET-DABMG and / or
(with "GR assignment" confirmation)


Usually this inconsistency (or below) cause M7 328 error
also (for example by document reversing, MIGO, VL09).
You cannot use it if you switched between 'No GR assignment' and 'GR assignment'.
Use it if return deliveries for inbound deliveries are handled via delivery.
Make sure EKES/EKBE-ETENS numbering are correct, if not go down to "Incorrect EKES-ETENS numbering" entry and use correction report.

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'
Make sure EKES/EKBE-ETENS numbering are correct, if not go down to "Incorrect EKES-ETENS numbering" entry and use correction report.

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:

SymptomCorrection Reportfrom Note

Additional symptom which solvable with the report 


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)



usable when scheduled quantity is not equal to GI/GR quantity

EKET-WEMNG <> EKBE-MENGE (incorrect EKET-WEMNG)ZKORWEM2The report was changed to include the new schedule line processing also (see Note 885177)!
EKET-WEMNG <> EKBE-MENGE (incorrect EKET-WEMNG)ZKORWEMN3Problems with delivery also
EKET-WEMNG <> EKBE-MENGE (incorrect EKET-WEMNG for RETURN ITEMS)ZKORWEMN4Reverse, or return not possible
Inconsistency in EKET-GLMNG, EKET-WEMNG and in EKET-WAMNG togetherZZ_CORR_EKET_WEMNG_WAMNG_GLMNGTip: 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)

from Note

Additional info

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
items do not exist see the note’s solution part for action to do

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

(correct from entered ETENS value)


In case of overflow in EKES-ETENS field or
BIT_OFFSET_NOT_POSITIVE dump, see this Troubleshooting guide.

(Correction for '0000' value records)

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.

See also
BIT_OFFSET_NOT_POSITIVE in Schedule Agreement BAPI's due to EKET-ETENR overflow (06 859)

If you observe further problems with deliveries, probably due to an inconsistency, checkout note 2006809 - Composite SAP note: How to fix delivery-related inconsistencies  

Additional Info:


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, 19411461960756, 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.


1 Comment

  1. you mentioned that SNOTE 407371 will also fix wrong EKET-ETENR ... unfortunatley it does not

    so you should correct this comment - the SNOTE will fix only EKES and EBKE-ETENS (wink)
    [ Make sure EKES/EKET-ETENS numbering are correct, if not go to entry "Incorrect EKES-ETENS numbering" and use the correction report. ]