Reversal of Invoice (Credit Memo) hit Price difference account in case of multiple Invoice booked against a Purchase order and logic, how system is calculating GR/IR clearing account at the time of Credit Memo.

When the account movements are determined, the following items are taken into account:

-Credit Memo Quantity

-Credit Memo Amount

Invoice Quantity Greater than Goods Receipt Quantity

Invoice Surplus and Remaining Credit Memo Quantity

Calculation for posting in FI document for

Excess Invoice Quantity = IR reversal Qty  * (Total GR Amount  - Total LIV Amount ) / (total GR Qty - total IR Qty )

Remaining Credit Memo Quantity = IR reversal Qty  * (Total GR Amount) / (Total GR Qty)

The sum of these values is posted to the GR/IR clearing account. The credit memo amount is posted to the vendor account.

Tables to be refered for calculation

Total GR Qty = EKBE-MENGE with VGABE = 1

Total GR Amount  = EKBE-DMBTR with VGABE = 1

Total LIV Amount = EKBE-AREWR with VGABE =2

Total LIV Qty = EKBE-MENGE with VGABE = 2

In case of Delivery cost refer EKBZ table.

Note: The system will not necessarily reverse the exact amounts, It depends on several factors: goods-receipt-based invoice verification, service based, any changes to the fields, etc.When you cancel an invoice, the system posts a credit memo for the data in the invoice. The postings are made in accordance with the creditmemo posting logic. This means that the postings in the invoice are not necessarily reversed. This is especially the case when an invoice is to be cancelled for a purchase order for which several invoices have already been posted. GR-Based IV does not play a role in case of delivery cost.

Invoice Quantity Smaller than Goods Receipt Quantity

If the invoice quantity is smaller than the goods receipt quantity, the following values are calculated for the credit memo quantity.

This value is posted to the GR/IR clearing account.

The credit memo amount is posted to the vendor account.

Note: If the credit memo amount is different to the posting to the GR/IR clearing account, the difference is posted to the stock account or a price difference account, depending on the price control defined for the material.

Example: Material with MAP


Purchase Order with 100 Pc @ $11.00/Pc. (PO Based Invoice Verification)


Goods Receipt 80 Pc.

Accounting Entries

Stock Dr. - $800

GR/IR Cr. - $800


(Off setting entry posted to GR/IR Clearing Account)

GR/IR to be cleared can be viewed in MB5S.


First Invoice

Invoice amount $720 for 60 Pc & New Price Per Pc. $12.


Vendor Cr.  -  $720

GR/IR Dr.  -  $600

Stock Dr.  -  $120 (If enough stock coverage) OR

Price Difference Dr. - $120

Here GR/IR Account is cleared for 60 Pc and amount $600. Remaining GR/IR to be cleared is $200.

Note: The invoice is different to the purchase order price. The difference between the purchase order value and the invoice value is posted to the stock account if there is sufficient stock coverage.


Second Invoice

Invoice Amount $548 for remaining 40 Pc. & New Price Per Pc. $13.70


Vendor Cr.  - $ 548

GR/IR Dr.  - $ 494

Stock Dr.  - $ 54 (If enough stock coverage) OR

Price Difference Dr.  - $54


Another Goods Receipt


Goods receipt Qty * Invoice Price

10 Pc. X $13.70 pc = $137.00

Off setting posted to GR/IR Clearing Account

Credit Memo

Calculation for GR/IR Clearing Account

Note: The total of the excess invoice quantity and the remaining credit memo quantity is posted to the GR/IR clearing account. The credit memo amount is posted to the vendor account. The credit memo amount is different to the posting to the GR/IR clearing account. The system posts the difference to the stock account if there is sufficient stock coverage.

Second example (GR Based Invoice Verification)

PO Qty = 100 Pc & $10/Pc

GRN = 50 Pc

Accounting Entries

Stock Dr. - $500

GR/IR Cr. - $500

First Invoice = 50 Pc

Accounting Entries

Vendor Cr.  - $500

GR/IR Dr. - $500

Second Invoice = 10 Pc with $11/Pc

Accounting Entries

Vendor Cr.  - $110

GR/IR Dr. - $110


Third Invoice = 10 Pc with $12/Pc

Accounting Entries

Vendor Cr.  - $120

GR/IR Dr. - $120


Credit Memo for Third Invoice Qty = 10 Pc

Accounting Entries

Vendor Cr.  - $120

GR/IR Dr. - $115

Price Difference Account Dr. - $5.0 (System will hit PRD account even if there is sufficient stock coverage)

Service PO

Service PO for 10 Qty with $100 Net Price per Qty

Service Entry Sheet for 8 Qty = $800

Accounting entries in GRN

Service Account Dr. - $800

GR/IR Clearing account Cr. - $800


Invoice for amount $500

Accounting entries

Vendor Cr. - $500

GR/IR Clearing account Dr. - $800

Service Account Cr. - $300


Credit Memo

Accounting entries

Vendor Dr. - $500

GR/IR Clearing account Cr. - $500


Service Entry sheet reversed with Qty 8 = $800

Accounting entries in GRN

Service Account Cr. - $500

GR/IR Clearing account Dr. - $500


Note: When you see Purchase order history, it will show you wrong amount for Goods receipt.





1609927 - MR8M / Credit Memo postings


46564 - Cancelling/reversing an invoice/credit memo: Posting logic


127832 - Invoice verifcation: Price differnces w/ credt memo


323607 - Invoice reversal for services




Postings for Credit Memos - Logistics Invoice Verification (MM-IV-LIV) - SAP Library


Thankx to all


Kaushal Sharma




    Recently I have implemented BAdI(ME_PROCESS_REQ_CUST) for ‘Direct purchase Requisition   creation Restriction against the Work Order(WO) with order category ‘30’ (Maintenance order )’.

   If user tries to create PR (Me51n) with Accountassignment Category ‘F’ with WO which has order category ‘30’ (Maintenance Order = ‘30’) then system will throw error message.


The Error message is  Sorry you cannot create direct PR with order category 30(mainta.Order).

How to do this?

You can use transaction SE18 to implement it.


  1. Go to transaction SE18.



2. Press 'Display'.


3. From the menu Implementation->Create



4. Give your implementation name as below (starts with
Z...). Here I have given as zme_process_Req_cust




5. Then give implementation short text as you like.


6. Then click 'Interface'  tab and select method 'PROCESS_ ITEM' (BY DOUBLE CLICKING).



7. In this method,please add the following coding.



method if_ex_me_process_req_cust~process_item.


include mm_messages_mac . "useful macros for message handling


data:   it_items_ref             type  mmpur_requisition_items,


        wa_items_ref             type  mmpur_requisition_item,


        ls_item_ref              type  ref to if_purchase_requisition_item,


        ls_item                  type  mereq_item,


        ls_acc_ref               type  ref to if_accounting_model_mm,


        wa                       type  mmpur_accounting_type,


        ls_accounting            type  exkn,


        ls_mmpur_accounting_list type  mmpur_accounting_list,


        ls_mereq_header          type  ref to if_purchase_requisition.


  data: lv_aufnr type aufk-aufnr.


ls_mereq_header   =   im_item->get_requisition( ).

it_items_ref      =   ls_mereq_header->get_items( ).



loop at it_items_ref into wa_items_ref.

         ls_item_ref   = wa_items_ref-item.

         ls_item       = ls_item_ref->get_data( ).


   if ls_item-knttp = 'F' and ls_item-estkz = 'R'.


   ls_mmpur_accounting_list = ls_item_ref->if_acct_container_mm~get_items( ).



loop at ls_mmpur_accounting_list into wa .

           ls_acc_ref    = wa-model.

                  ls_accounting = ls_acc_ref->get_exkn( ).


       select single aufnr  from aufk into lv_aufnr  where aufnr = ls_accounting-aufnr and autyp = '30'.


           if sy-subrc eq 0.


          message e026(zq) with ls_item-bnfpo.










8. Finally 'SAVE' and 'ACTIVATE'.



How to create error message?


Here in the above coding, my error message is E026 with message class ZQ.You can use transction code SE91, you can createyour own message.







9. Now try to create PR(me51n) with Account assignment category ‘F’ with WO (WO has order
category =’30’(Maintenance order),then you will get error message
Sorry   you cannot create direct PR with order category 30(mainta.Order). So , you cannot complete your PR..





I welcome your  suggestion, please. Thank you.

As we all know if we post material document which is relevant to valuation, an FI document will be created subsequently.
A typical MM/FI inconsistency would be the material document is generally while the FI document is however missing.
If ML(material ledger) is activated system will issue error C+048 and no more goods movement is possible for the material.
In the worst situation, period closing activity will be affected and even causing auditing issue.
(This is the same content moved from Chinese forum as per quest from peers)


Here will give a detailed explanation, possible reason and the way to prevent it:

  •   The important user-exit and BAdI

    • material document missing FI document
    • FI document missing material document
    • check mechanism to prevent it
  •    Relevant SAP notes


The important user-exit and BAdI

During goods movement, there're many requirements to implement customer specific checking logic, so BAdI


MB_DOCUMENT_BADI and User-exit  EXIT_SAPLMBMB_001(include ZXMBCU01 / enhancement component MB_CF001)

are the ones to be often used. If there're inappropriate command(from note 92550) below implemented in the BAdI or user exit,

MM missing FI could happen:

  • Remote Function Call (CALL FUNCTION .. DESTINATION)
  • Own updates on the document or stock tables (for example, an update on the table MBEW, MARD, MSEG)
  • Unlocking data (for example, by DEQUEUE_ALL)
  • Calling a dialog box (POPUP_TO_CONFIRM, for example)


  • material document missing FI document

        Here I'd like to introduce the concept of SAP LUW. LUW is "Unit Logical Unit of Work" and usually there're
        Database LUWs and SAP LUWs. SAP LUW is used to keep consistency of application programs that are executed

        across different work processes, and the updates are first registered and then executed by a single work process.

        One of the techniques is known as update task(via update function modules: CALL FUNCTION...IN UPDATE TASK).


        BAdI MB_DOCUMENT_BADI is called after the update function module MB_UPDATE_TASK, so if there is COMMIT WORK

        in MB_DOCUMENT_BADI method MB_DOCUMENT_BEFORE_UPDATE, SAP LUW will be destroyed.

8-18-2015 1-17-30 PM.png


   Considering sequence below:

  • Material document:

          Call function 'A' in update task.

          Call function 'B' in update task.

          COMMIT WORK -> update of material document is triggered and database MKPF/MSEG will be updated.


  • FI document:

          Call function 'C' in update task.

          Call function 'D' in update task.
         ->If there's any error happens at this stage, system can only rollback C and D while material document
            cannot be rolled back any more as it has been already written into database.


You may still have concern, why the issue does not always happen. Sometimes twice or three times in a month?
As shown in above flow, you could understand it only happens when LUW is destroyed i.e. there's error afterwards however
system can no longer roll back the whole transaction completely. If there's no error then with 2 times of COMMT WORK,
you can still see both material document and FI document are created.


  • FI document missing material document

        Similarly, if there's inappropriate ROLLBACK in user-exit, FI document missing MM could happen as well

  • Material document

         Call function 'A' in update task.

         Call function 'B' in update task.

        -> material document update is cancelled


  • FI document

        Call function 'C' in update task.

        Call function 'D' in update task.


        Standard COMMIT WORK is executed, and only FI document is updated into database


  • check mechanism to prevent it

        We've got lots of customer incidents reported with this kind of inconsistency. The correction can only be carried out
        by SAP authorized engineer with debugging so we implement the checking mechanism in note 1776835

        to prevent such inconsistency. This note implement the coding to catch and track the inappropriate COMMIT

        or ROLLBACK in customer coding, and once it's detected system throws short dump to terminate the process.
        In transaction ST22 call stack, you can see in which user-exit or BAdI COMMIT/ROLLBACK is triggered, and then

        you have to review the coding with your ABAPers and correct it accordingly. So we highly recommend you to
        implement the note to prevent MM missing FI inconsistency. It's always necessary that customer development obey
        the rules and keep the completeness of SAP LUW.


SAP notes      
Regarding the MM/FI inconsistency topic, you can also refer to SAP note below for details:

  • Note 968812 MM-FI Differences caused by ROLLBACK or COMMIT
  • Note 92550  Stock inconsistency due to customer enhancement (exit, BAdI)
  • Note 1284654  Caution with implementations of the BAdI: MB_DOCUMENT_BADI

Hi Friends,


    I would like to share a situation which I faced recently in a trading company and how the issue was resolved.

Issue Description:


  •     In Material master, the negative stock is not allowed for the material.
  •     In customizing in OMJ1, the negative stock is not allowed for the plant and storage location.


    With the above condition, there should not be any negative stock for the material in the plant. But business came up with  a situation as there is negative stock for the material!!!



    We started analyzing the details and the reason for the inconsistency. While checking the material document table, we identified that two material documents (delivery for sales order) has been posted within a time difference of 88 seconds with "Total Valuated Stock Before Posting" as same quantity.


     We checked the material document and found its a PGI document for sales order. The document flow for the sales order showed as below:


         Now, we have one sales order, one delivery, 2 PGI documents against the same delivery and one invoice document!!!!


    Since the material document was posted wrongly, we suggested to cancel the PGI in VL09. But there starts the next issue - system was not allowing!!!



    In fact, system was issuing the same message for any goods movement for the material! This was very critical since the material was a fast moving material and business can not stop due to inconsistency in SAP!  Since PGI was done, initially we defended by another question: We need to understand from the business, how the stock got issued physically to the customer if there was not enough stock!!!!


     But the the situation was strange and difficult to convince the business. Customer even started doubting the credibility of SAP!!  On further analysis, its found that the issue has been explained in the SAP Note: 935755 - Negative stock even though this is not permitted in Customizing !!. The note was a turning point!


      The note clearly explained the reason for the situation - It could be due to late update or due to custom procedure for goods movement. But in our case, the goods movements are posted through standard only. So the reason was assumed as "late update", which was easy to convince the users since the time difference for the posting was 88 seconds.


       Now users started asking for the solution. Customer was not ready to move any configuration change to PRD, since it may create another inconsistency for any other material.


       We again depended on the note. As per the note, the situation can be resolved only by passing another goods movement for the material. So we tried the following:


1. Goods receipt with 202 movement in MB1A  - System didnt allow - error message (M7 314)!

2. Physical Inventory to correct the stock in MI09 - System didnt allow - error message (M7 310)!


       Now there was no option other than moving a configuration change to PRD. The were 2 options:


1. Allow negative stock for the plant, storage location and material  and cancel the PGI. - The option can be done only after business hours and after locking all users for the plant, since the system will generally allow negative stock for the material and if any users post goods movement, it may create another inconsistency!

2. Suppress the message M7 314 and M7 310 temperorly: This was the most suitable solution, since the message can be suppressed only for a specific user through message version and then post a goods movement.


      We proposed option 2 and convinced the customer. Now, question came - which goods movement has to be posted - cancel the PGI or 202 with cost center or physical inventory with MI09.

      But since there was two material documents against the same delivery, we were not sure which material document will be posted if the PGI is canceled. If only one is cancelled, again it will be an inconsistency!  At last, we proposed to process 202 against cost center in MB1A and the issue resolved.


       In short, the issue was resolved with following steps:


1. Suppress the message M7 310, M7 314 in the path: OLMB - Define Attributes of System Messages, with a different version:


2. Maintain the parameter ID: MSV with value as the message version number in SU3 for the user who is supposed to do the goods movement.


3. Goods receipt against cost center with 202 movement in MB1A for the quantity issued wrongly.


4. Once the 202 movement was posted, material stock shown correct quantity and value in stock reports.


5. Remove the parameter ID : MSV from the user master.


     This resolved the critical issue! Hope it will be useful for others who faces similar issues.


     Thanks for going through the blog and thanks for your time.




Hello Everyone,


In this blog I would like to point out a system behaviour which was noticed while Plant creation/copy. As this is a forum of experts, would love to hear your thoughts on the observation explained below;



For the first case we create a new plant afresh.

T-code  OX10/SPRO is used for defining the plant and then all the required assignments and configurations are made in the system with respect to this plant. When we define the Plant, Plant master table T001W is updated with the corresponding entries. When configurations like Company code and Purchasing Organisation assignment,Storage locations creation for this Plant, Valuation grouping code assignment to Plant; Tables T001W, T001K, T001L, etc are updated.


Here if we check the table T001W before assigning Valuation grouping code to the New Plant, the Valuation area column value will be missing. The same will appear after this assignment. Similarly, table T001K will have no values for the New Plant code created until a Valuation grouping code is assigned to this Plant.



Here we create Plant by the SAP recommended technique of Organisational object copy Plant.

T-code EC02 is used to copy a Plant from an existing Plant. Here multiple tables are copied all at once, 142 in all, in my case of copy (which takes awhile). And yes i checked ! .The FROM Plant is the reference plant in business terms and the TO Plant is the new Plant you want created in the system (new Plant code required obviously).

In this case too the table T001W is updated appropriately, the created Plant code also appears as the Valuation Area in Table T001W and T001K.



Now, this is the case that has caught my interest.

Here the Plant is created in T-code OX10 (New entry or Copy available in OX10) or the respective SPRO path, wherein only the Plant code, Names and respective address details are entered and saved in the transport.

Now, unlike CASE 1 instead of manual configurations, we go and copy this Plant object using t-code EC02.

Observations in this case;

Table T001W has all entries copied except for the columns Valuation Area, Purchasing Organisation and Sales Organisation, as observed below;

Plant copy.JPG

Whereas, in table T001K the created Plant is visible as a Valuation Area.

valuation area.JPG

Additional observations are a Plant created in such a way may or may-not appear as a Valuation Area in transaction OMWD (Group together Valuation Areas).

Also, other Org unit assignments like: Purchasing Organisation to Plant assignment, is also not conventional as the status column has text missing which existed in the reference Plant. Also, the Material Type Valuation and Quantity update settings are not copied in this scenario.

Well, the solution to all these inconsistencies is really simple, but not an easy one if the Plant is live in production and has transactions made against it.


When you have a requirement to create a Plant with reference to an existing Plant, copy the Plant object first using t-code EC02 and the edit the details for the same in OX10.

And cases where you have created Plant as in CASE 3, inconsistencies can be removed by deleting the Plant object in transaction EC02 and creating it again in the SAP recommended process as described in CASE 2.

Refer to SAP KBA 1754880 - Some configurations are missing when copying/creating plant master in T-code OX10 for SAP recommended standard process of Plant creation.

Would love to hear your thoughts on this topic and all else !!

Auf Wiedersehen



Aim of this document is to show how price variance is calculated in a context of standard cost.


Standard cost, is a agreement between Engineering and Finance areas, regarding the price of raw materials and operative supplies, this estimated price is a key input to calculate gross margins.


PPV impact on Gross Margin


The Purchasing Price Variance or PPV is a warning flag that says that the gross margin will have variance, taking care about the situation, on a nimble way, enable the organization to keep margins going forward.



Our scenario is built it to buy 1,000 LB of raw material, where:


  • Standard Cost is 10 USD per LB
  • Order Price is 11 USD per LB
  • Actual Price is 12 USD per LB

Standard Price


First of all, we have our raw material master data created:



Purchase Order Price


Then, we create an order; price is above our estimated standard price:



PPV at Goods Receipt


Now, lets assume that we had received the material before the invoice, so a difference is calculated:

PPV during GR = Standard Price – PO Price




The journal entry for this GR is:


Inventory Account DR 10,000 USD Standard Price
GR/IR Account CR 11,000 USD PO Price
PPV Account DR 1,000 USD Balance

PPV at Invoice Receipt


Now, when invoice is received, we realize that market change and now, the actual price is different than the PO price

PPV during IR = PO Price – IR Price



Journal entry is:


Vendor CR 12,000 USD Actual Price
GR/IR Account DR 11,000 USD PO Price
PPV Account DR 1,000 USD Balance


This means that the net PPV is:

Net PPV = Standard Price – IR Price = 10 – 12 = -2 USD per LB


This is an unfavorable Purchasing Price Variance.



Now, on SAP there is a report that can be customized (configured) to get this Net PPV, this is:




You can use transaction MC$G, to get the report with data related to PPV.  This is infostructucture S012 that can be enhanced to take advantage of Logistics Information System features, or a simple query using structure S012 can be created.


How to enhance LIS for MM.




Note: This note was originally posted on my personal blog at angelreyes [dot] wordpress [dot] com

Dear Community,


Do you have queries from your business users around inventory management valuations regarding the changes of the moving average price of certain materials? If so you may have already noticed that the moving average price of materials can be changed by several different documents in ERP systems, for example: material documents, price change documents, invoice documents, production settlements or even credit memos or material ledger documents. Due to the complex cross-application knowledge required to find all these documents it can be quite complicated to access and review all relevant documents.

Our new pilot supportability tool provides a new report to help the analysis of such scenarios. I would like to invite everyone to check out our new initiative as in the end our partners' and customers' feedback will decide the future of this tool. If the community supports our initiative this new solution may be released in a standard note in the near future.

You can download the pilot version and find a detailed explanation of how the new report works in the MM Trouble Shooting Guides here:


Please let us know in the comment section how you find the tool and whether you would like to see something similar in the standard software!


Kind Regards,






    Recently I have implemeted Badi(ME_PROCESS_PO_CUST)  for 'Not allowing create PO(with dcoument type NBPJ and CRPJ) without PR.


If user tries to create PO(PO document type PJCR or NBPJ) with out PR,then system will throw error message.The Error message is "There is NO Purchase Requisition for this PO !".


How to do this?


You can use transaction SE18 to Implement it.

1.Go to transaction SE18.


2.Press 'Display'.


3.From the menu Implementation->Create



4.Give your implemenation name as below(starts with Z..) Here I have given as  zme_process_po_cust.


5.Then give implementation  short text as you like.


6. Then click 'Interface ' tab and select   method 'PROCESS ITEM' (BY DOUBLE CLICKING)




7.In this method,please add the following coding.



method if_ex_me_process_po_cust~process_item.

  include mm_messages_mac . "useful macros for message handling





  IF ( LS_MEPOHEADER-BSART = 'NBPJ' OR LS_MEPOHEADER-BSART = 'PJCR' ) .  "here I am checking my document type





     MESSAGE E025(ZQ).











How to create error message?

Here my error message  is E025 with message class ZQ.You can use transction code SE91,you can create your own message.



8.Finally 'SAVE' and  'ACTIVATE'.


9.Now try to create PO with your own PO document type without PR,then you will get error message and without rcreating PR,you can not complete your PO..However you can 'HOLD' your PO.



I welcome your suggestion,please.Thank you.

......Press Here to See More......


     It is from note 1707638, to put a given date into scheduling dates that are initial and need

   to be corrected.


     It is contained in note 1102280, and in order to correct the inconsistencies in table A016.


     It is in note 1839366, to reset several fields in table EKPO which contains unexpected value

     when publishing a contract with a material group line item (item category W/8) from SAP Sourcing.


     You can use this report from note 1370784 to detect inconsistency when an inbound delivery

     is displayed in transaction MD04 despite goods receipt, or goods receipts are assigned incorrectly.


     It is from note 164004, and subjects the relevant items to a GR reassignment over the schedule

     line quantities.


     You can find it in note 369732 and use it to generate the missing entries in index table EKUB again.


     You can run it from note 383042, to update the change in the SA when there are changes in the

     material master assignment of MRP areas.


     You can run it from note 1059195 to solve the termination DYNPRO_FIELD_CONVERSION "FLAB_

     HEAD-LWEMG" When you display or change the scheduling agreement release (SAR).


     This is from note 953281 and used to correct the entries for purchase orders which are missing from

     table RSDB or for deleted purchase orders or enquiries.


     You can use it from note 160525 to set EKPO-ELIKZ for PO so that "Issued quantity", "Goods receipt

     quantity" and "Quantity delivered (stock transfer)" are the same.


     It is from note 304671, 92083 and 444557, to find the items which lead to update termination on table

     EKKI. Then the unnecessary entries in table EKKI are deleted from the database using test = ''.


     It is from note 951328, to fill EKET-BEDAT fields which are missing from purchase orders.



    They are from note 100690, to correct inconsistencies with EKET-GLMNG, EKET-WAMNG, and



     It is contained in note 339267, to correct the redetermination of the conversion factors (EKPO-UMREZ

     and EKPO-UMREN) between the base unit of measure (EKPO-LMEIN) and the order unit (EKPO-



     You can find it in note 104475, to subsequently set the "delivery completed" indicator in purchase

     order that have already been fully delivered, in order to prevent performance problems during ATP check

     or running MD04.


     You can find it in note 167242. It shows you which records of the purchase order history are linked

     incorrectly, and corrects the purchase order history.


     You can find them in note 61148, to set up or delete the table VETVG (Delivery Due Intex) for an

     individual purchase order.


     It is from note 197012, to delete the entire settings of a user to solve termination TSV_TNEW_PAGE_



     It is from note 670262, to insert in RSDBS all missing entries for a selected network.


     It is contained in note 864839, to clean up the EKAB table and solve the update termination because

     of a duplicate table entry in the EKAB table.


     You can run it from note 527995, to correct existing purchase orders that haven't indicator EKPO-

     STAPO set, although the deletion indicator is set.


     You can find it in note 171331, when the quantity ordered in PR is not correspond to the quantity of

     the purchase order to which it belongs.


     It is from note 769394, to change the logical system in the "old" source list records after you transfer

     the source list maintenance into a central system.


     You can find them in note 836917, when there are info records with different info record numbers but

     with the same material number etc.


     You can find it in note 451114, to set the initial value of EINA-URZDT to '00000000', if the value is ' '.


     This is contained in note 359469, to initialize some EINE fields with the help of SAP development



     It is from note 208976, and to archive the purchasing organization data/plant data (EINE).

     They are from note 636853, to do correction of MRP relevance of inbound deliveries.


     You can find it in Note 431145, to reestablish consistency between the purchase order history (table

     EKBE) and the replenishment delivery.


     You can use if from note 433505, to reinsert the missing EKBE records.


I would suggest you



-Read the corresponding SAP note carefully before running the report, pay attention to any

special statement in the note.

-Run the report in Test mode firstly if possible, and check the result before running it in Update mode.

-Run the report in non-production system firstly.

In this blog, I will summarize the useful reports in MM-PUR area. I would suggest you


-Read the corresponding SAP note carefully before running the report, pay attention to any
  special statement in the note.
-Run the report in Test mode firstly if possible, and check the result before running it in Update mode.
-Run the report in non-production system firstly.


    It is described in Note 175178, to load the standard variant SAP&STANDARD delivered by SAP.
    This report has to be run in client 000 since the SAP standard variants only exist in this client.
    It is introduced by Note 202875, to create one batch input folder for purchase orders and one for
    delivery schedules. It analyzes the documents selected and only puts the FAULTY documents
    into the batch input folders.

3. RM06ME59
    It allows the user to enter a certain purchase requisition or to enter a range of purchase requisitions
    to be checked with it/they cannot be converted to PO due to error ME261 in ME59(N).
    This report is introduced by Note 786303.
    You can find this report in Note 91001, it is to remove the address number from the document item
    when termination message AM010 shows for delivery address error.
    It carries out several checks for a certain interval or an interval from purchase orders or scheduling
    agreements, when user cannot post goods receipt for them due to error M7064.
    You can find it in Note 886735.
    It is contained in ERP 6.0 Enhancement Package 4. It provides additional selection parameters to
    search messages based on PR number, PO number and (SRM) Central Contract Number.

    It is from note 821981, after running it, the Purchasing Document address and Vendor address
    linkage is removed.
    It is from note 451605, to set the Deletion Indicator (EKAB-LOEKZ) value to 'L', if the value is 'X'.

    It is from Note 422589, to set the deletion indicator in Table EKAB, if a document does not exist

    in EKKO.

     It is attached to note 1025024, to correct the inconsistency of the tables FPLA and FPLT for the   
     old data.

     You can find it in note 304541, it is to adjust Customizing and to change existing links with the  
     EKKO business object to BUS2012 (purchase orders) and BUS2010 (requests for quotation).


     They are introduced by note 407371, for the reorganization of the ETENS numbers.


     It is from note 536190, and it corrects the MRP reduced quantities (EKES-DABMG) of confirmations

     with GR assignment and the MRP reduced quantities of the corresponding schedule lines.


     It is from note 521164, to set field EKES-MENGE to the same value as EKES-DABMG with the

     result that the shipping notification is no longer displayed in the requirements and stock management.


    They are introduced by note 544896. You can use them when the inbound delivery exists but

    individual delivery items do not exist, or when the inbound delivery was archived but entries

    still exist in the purchase order history (table EKBE),


     This is contained in note 1725906, to recreate the missing link in the Purchase order based on

     inbound delivery documents.


     They are from note 423416. In the error long text of the respective error message in workflow, you

     can replace the call of transaction ME22 by the call of report ZDIME23N (as of Release 4.6), 


     It is contained in note 574494, to explode a large number of aggregated purchase order histories.


     You can find it in note 1508153. It is to be used when central contracts are distributed from SAP

     SRM to SAP ECC but delivery tolerances are not adopted from Material Master.


     They are contained in note 703450, they read all purchase documents which contain a reference

     to a configuration. If the configuration no longer exists, the reference will be deleted.


     You can find it in note 1618369, for resetting the deletion indicator on header level of schedule

     agreement or contract.


     This is from note 205723, to display the incorrect conditions when there are inconsistencies between

     database table EKPO and KONV.


     You can find it in note 456261, when you got error message VD346 in any transactions like ME21N.


     It is from note 1570035, to set the CO Production order to completed so that the follow on documents

     can be archived.


     It is from note 115899, to identify and correct inconsistencies for dependent requirements for

     subcontracting purchase order proposals. You can only use this report when the inconsistencies

     can be traced back to errors that are already known.


     You can find it in note 892748. After upgrading to Rel 4.7 or higher, old cross company STOs need  
     to be adapted to correct "Posting Logic in the Case of Stock Transfers" at the item level.


     It is contained in note 1899151, to deletes the "GR-Based Invoice Verification" indicator for the

     affected purchasing document item.


     It is contained in note 496577, in order to delete the incorrect text which is stored in database without

     a document number.


     You can run it from note 941299, when you got error WY 017 or WY 026 in ME65.


     You can find it in note 702205 in order to determine and correct incorrect purchase orders and RFQ,

     when runtime error SAPSQL_ARRAY_INSERT_DUPREC happens.

......To Be Continued...

The Trouble Shooting Guide(TSG) wiki page of Inconsistency in Inventory Management contains information that enables you to cope with different kinds of inconsistencies in inventory management. As many of these inconsistencies are not real database level inconsistencies,  this TSG wiki page intends to provide fundamentals of most common inconsistency cases in inventory management. With this information you should be enabled to

  • Detect the inconsistencies
  • Understand the reason why inconsistency happens
  • Resolve the inconsistencies by yourself


The TSG wiki page is available in link below, and you can navigate it using error message i.e. M7314 or M7308:



It also provides the list of hot news note which you need to apply in the system to avoid future inconsistencies.


Check out the link for more details, and please don't hesitate to let us know if you have any suggestion.


Best regards,

During a purchasing document creation or a goods movement posting, you may can face some performance issue like any kind of short dump or it may can take long time to execute a transaction. Generally, a performance issue can occur because of a huge data. Sometime system can't able to read information from table and execute a dump message. That's because may company prefer the archiving process after some time (even some year). There can be many more different reasons when a performance issue occurs. Normally a performance issue can be resolve by archiving process, but many of cases, you need to do some program correction with the help of some OSS note(s). You can also improve performance by creating index with correspond table. Such as, you have performance issue regarding the table EBAN, then create a database index from transaction SE11 on table EBAN as per your requirement, then save and activate the index, then run your transaction, you can see the performance improvement.

In general, when you create a purchasing document, system checks many function which may not need for you but to avoid any kind of inconsistent, system will check and generate all information into all related tables. Some functions are most important which should be executed when you create a purchasing document like as Price determination, create or update purchase info records, release procedure, partner determination, text determination etc etc. This information should be executed when you will create a purchasing document according to your requirement and IMG configuration. If you read the OSS note 188837 - Purchase order generation performance , you can find how many functions are executed during a purchase order creation. This OSS note has given the information how you can optimize or control these all functions during creation of purchase order. However, it could not be possible to delete some functions which are required as per your business process. Read the OSS note and deactivate the listed functions as per your requirement and be sure that you do not need this function to be executed during purchase order creation. Please read this KBA document 1942976 - Performance issue when using transactions ME21N, ME22N, ME23N , here you can find some more options to avoid the performance issue during purchase order transactions. System can perform a slow performance while creating a account assigned document or even a service document (like service purchase order, service contract, service requisition etc.). It is because of the extra table EKKN, system need to reread the table EKKN for account assignment document, that's because system can take long time to read data from table.

During a goods movement (like as goods receipt, goods issue, transfer posting), system can take long time to execute. For a general performance issue (or even a runtime error) during goods receipt, use the OSS note 1738158 - Long runtime for goods receipt for purchase order. There can be different different reason as per the transaction. Like when you will post a goods receipt, system can take long time due to the purchase order or schedule agreement's line item, while you post a goods receipt for many item for purchase order or many purchase order into one goods receipt. System will take long time to fetch data from various purchasing tables (like EKPO, EKKN). You can improve the performance by splitting this into multiple. Slow performance can occur when you will use the price determination process during goods receipt. System will try to fetch many records from various tables for the price determination process during goods receipt. Another reason for slow performance during goods receipt of purchase order or goods issue for a stock transport order is unnecessary copy data for group condition (from GKOMV to TKOMV). Transaction code ST12 has been developed by SAP to trace the performance issue and any kind of ABAP dump.

Let me explain some issues with details explanation (with view from OSS notes), why a performance issue occurs during various purchasing transaction execution or goods movement and how you can improve performance while executing a transaction.

When you set a deletion flag or archiving process for purchasing document, you may face performance issue. The performance issue may can raise at the time accessing table EKKN or EBAN (according to document). The OSS note  1411343 - Setting the deletion flag: Performance problems says there could be performance issue occurs after implementing the OSS note 418988, and if there are no reference of purchasing document, system will try to access all records from table EKKN or EKBN. However, this OSS note 1411343 has given a modification to avoid the same. Read the OSS note accordingly, additionally read the OSS note 673290 - Setting the deletion flag: Performance problems also.

A large number purchase item or purchase order history item can also causes of performance issue. When you call a transaction (like ME2* reports, transaction MIGO, MB01, MIRO, MIR7, MRRL etc) which is fetching data from purchase order item (EKKO) or purchase order history item (EKBE), system can return you a dump message or can take a long time during execution of these t-codes. To improve performance you can use the aggregation facility for purchase order history by using the transaction ME87, which can remove (reversibly) old data from your purchase order history. Read the OSS note for more details 311089 - Performance problems because of long PO history and 574494 - Explosion the aggregated purchase order history via report . However, there are some cautions for the aggregation feature. The caution can be found on the OSS note 311089. This aggregation can remove your purchase order history which are old more than two months (however it is possible to change the period according to the OSS note  756293 - ME87 Aggregation duration purchase order history).

During creation of purchase order from transaction ME57, you may can face performance issue. System read the table EBAN, to fetch information during execution of the transaction ME57. Because of a huge data on EBAN table, system can take long time (or even fail to execute with dump) to create a purchase order. The solution is provided in this KBA  2108907, that you should archive the all old requisition along with give some selection parameter in ME57. Read the KBA document for more information.

You have some issue regarding purchase requisition creation, some performance issue can occur after implement the OSS note 1836886. SAP has given another OSS note to improve the performance after implemented the OSS note. You can find more information in this OSS note 1910134 - Performance Improvement in Purchase Requisition (note: this OSS note is only relevant for Brazil localization).

Some performance issue can occur when you will go for release a purchase requisition from transaction code ME54N, SAP has given an OSS note for a program correction 1377556 - Performance issue during release of PR-ME54N

When you will go for purchase requisition list from ME5A, system can take long time to execute or even can fail to show result. Performance issue can occur also after giving some selection field(s). As per the report logic, system is fetching data from EBAN, during the data fetching, system can take long time to execute. You can implement OSS note 942106 - Performance of ME5A: List display of purchase requisitions to improve the performance. Also by indexing the table EBAN, you can reduce the performance issue, read the KBA document for performance issue during ME5A transaction 2111467 - Performance issues in ME5A

At the time of mass maintenance of purchase requisition from transaction code MEMASSRQ, you can have some performance issue. Its because of as per the logic of mass maintenance, system will call the record twice for a document while it should be called only once per document, this can causes of the performance issue. You can implement the OSS note 1448621 - Performance problems when changing PReqs (transaction MASS) to avoid the performance issue during the mass maintenance transaction.

You may can face some performance issue at the time of converting purchase order from a service purchase requisition. There is an OSS note 1658177 - Performance: Creation of purchase orders , by implementing the OSS note, you can reduce the performance issue.

At the time of using BAPI for purchase order create or change, you can face some performance issue. The reason of this performance issue can be long text. As per the OSS note 917290 - Performance: Long texts in EnjoySAP order BAPI , system can take long time to process the text during execution of BAPI. Read the OSS note for more details and implement the correction to avoid the performance issue. Also please have a look into the OSS note 1355577 - BAPI_PO_CREATE1: Runtime problems when calling RTTS, it also explains about the performance issue regarding the bapi BAPI_PO_CREATE1 or BAPI_PO_CHANGE

There can be poor performance during creating or changing a contract or a schedule agreement via BAPI. With release 600, 602 and 603, SAP has found program error which can causes of the poor performance. By implementing the OSS note 1475971 - BAPI: Performance for contract and scheduling agreements , you can improve the performance for this selected EHP release. Not only performance issue, you can read the OSS note for some additional issue during calling BAPI_CONTRACT_CHANGE and BAPI_SAG_CHANGE.

System can take huge memory during running BAPI_PR_CREATE or BAPI_PR_CHANGE, this can cause of slow performance. This performance can occur for a program coding. You can use this OSS note 1571867 - Performance issue when executing Purchase Requisition BAPI , here a program correction suggested by SAP.

For a higher release (from 605), you can face performance issue during creating a request for quotation from ME41 with multiple items as text item. The causes of the slow performance can be the multiple item for one RFQ document. Either you should divide the RFQ document to multiple or you can try by applying the OSS note 2086200 - ME41: Performance optimization when using item texts to improve the performance while perform multiple line item in one document. Another reason system can take long time to execute the transaction, it is time dependent condition (specially the case of batch input). When you will use time dependent condition for many items in one document, system can take some time to find and execute the supplementary conditions with regards to the time dependent condition.

You may can face a performance issue during goods receipt against outbound delivery for a inter company stock transport order. This slow performance can occur because of a lots of line item in the purchase order (EKPO entry) or a lots of purchase order history line item (EKBE entry). You can implement this OSS note 1328939 - Performance issue when posting Goods Receipt against STO , it includes a program change, which can improve the performance during goods receipt.

Some performance issue can occur after activate SAP HANA during goods receipt from MIGO. It is for enhancement package 6.04 along with the business function LOG_MM_OM_1. In that case, use the OSS note 1729650 - HANA Performance issue when creating Goods Receipt for a program correction.

During posting or reversing a goods receipt with regards to a production order, you may can face some performance issue. This performance issue can occurs due to the volume of large order history, instead of fetching the single order history, system is trying to fetch the total record. To improve the performance issue SAP has given a feature to fetch the data record as summarized. You need to add an entry in the table CKMLMVADMIN as 'CKMO_READ_MLAUF = S'. A details explanation can be found in this OSS note 1759860 - Incorrect GR reversal for production orders and performance improvement , along with consider this OSS note 1611053 - Performance: Production Order history compression for a manual steps details for production order history compression.

For any goods movement from MIGO, system can perform slow performance. This slow performance can be occurred due to a number of storage locations are assigned to the plant. During the determination of storage location with regards to the transaction, system is copying the number of storage location into an internal table from table T001L and then reads all data from that internal table. After implement the OSS note 1016033 - MIGO: Performance improvement when reading table T001L system has changed the logic not to use the internal table, system will fetch the data directly from table T001L table. This can improve performance during goods movement in MIGO.

During posting a goods receipt from MIGO with regards to a purchase order with multiple account assignment, system can occur slow performance. The main reason of this performance issue is huge data of purchase order history item. Along with at the time of goods receipt for a multiple account assigned PO, system will run the source code of the business function LOG_MM_MAA_1 although this business function is not active. Use this OSS note 1605930 - MAA: MIGO: Poor performance as a source code correction.

At last, there can be some performance issue due to your own custom development / enhancement. Due to poor coding from an ABAPer, you system can issue short dump or even take a long time to execute the function. In that case, you need to consult with your abaper to improve the quality of coding. By using a Badi or user exit, system can take long time to execute the function.

In above, I have given some example of OSS notes with brief explanation about the performance issue. There are many more OSS notes are given in service market place for any kind of performance issue. Most of all performance issues will get improved by implementing correspond OSS note. So, whenever you will face any kind of performance issue, first search in service market place for some OSS notes.

Hello Folks,


From time to time I see customers raising incidents regarding error SE508 when trying to create a Service Entry Sheet based on some PO.


Last year I wrote KBA 1680030 explaining how to fix the problem and I realized that some times the solution proposed in the KBA does not work.


I have updated the KBA with another solution that should cover the cases where the previous proposal would not help, so in case you face this error just check how to fix it in the KBA.



Eduardo Junior

SAP Active Global Support - ERP MM

Hi,I would like to share with you one of Procurement Scenario which involved replacing of Purchase Order by Scheduling agreements.


Business Scenario : Business involved in manufacturing standard products,raw material required for producing these product are on continuous basis,each raw material is having fixed vendor.requirement for standard products generated base on re-order level planning.requirement generate for raw materials generate in system after MRP run.purchase order is created for open purchase requisition and sent to vendors.vendors delivering goods as per communication with buyers.every new Purchase requisition generated later included in old PO with new line item,message sent to fix vendor through telecommunication,on receipt of material at shop,goods receipt not possible at stores because of reasons like PO was not created,PO was not released this result in delay in goods receipt at stored in system.due to urgency at production line goods issue to shop without entry in system.later this result in mismatch of inventory etc.


Major Issues :

1.Component not available for production on time.

2.Continuous amendments in same PO frequently,this affect vendor evaluation process

3.PO approval required frequently due changes in PO,Buyer has to do follow up with Purchasing Manager for PO release.

4.Delay in PO release result in delay to communication to vendors and delay in Material delivery.

5.Vendors not having formal document with right quantity,for future planning.


Solution :

To Overcome such issues scheduling agreement are use as replacement of purchase orders for standard components which are required frequently.

steps follows in process:

1.Scheduling agreements created with validity period of 6 months with maximum possible quantity for all vendors.(ME31L)


2.All Open PO for vendors identified and closed.(TCODE-MEMASSPO)

PO Mass Change.PNG

3.All Scheduling agreements released by Purchasing Manager ( TCODE-ME35 )

SA Release.PNG

4.Source list created for components with Scheduling agreement and MRP usage 2 ( Record relevant to MRP. Sched. lines generated automatically )


5.After MRP run,system generate schedule lines for requirements.

6.To avoid over-written of schedule line orders trade-off-zone updated with more than Planned delivery time.(TCODE-ME32L )

SA item.PNG

5.These schedule are email to vendors.

6.Vendors deliver goods as per delivery dates.stores takes goods receipt against SA for open schedule line quantity.

7.Invoice receipt will be done against SA for GR Quantity.



1.Reduction in vendor follow-up time of buyers.

2.Saving of buyer time which was spent for amendment of POs.

3.No follow up for order approval required,Once SA is released it will be valid for validity period mention in it.

4.Accuracy in vendor evaluation process.

5.Timely availability of components at production line.

Material document duplication is an usual issue faced by many customers when posting goods issues at SAP System. In particular, I faced this case many times.


In a case where you have duplicate material documents you can create and run the report ZZWASTOR of note 424414.


You must first check the effects of the report in a test system or with "test mode = X" if it is in production system.


Usually, the root cause is related to unforeseen events like:

  • Inconsistencies caused by hardware defects, user handling and customizing changes
  • Closely related time wise (seconds apart) of MM postings in conjuncture w/ ENQUEUE/DEQUEUE settings
  • Customer reports without consistent updates on the database (user exits or custom programs)
  • Manipulation on the database
  • Data quality after migration
  • Database update errors


The most common reason for the duplication of material document are lock issues. I mean, for example, the end-user opens a session and tries to post a goods movement, if the system is facing poor performance for the moment, the same end-user (or another one) opens a new session and post the goods movement again and then later the first movement is completed. This lock issue will allow the creation of two goods movements. It happens a lot with several customers. In case, OMJI should be set as exclusive lock to avoid new cases.


By the way, report ZZWASTOR will delete duplicate material documents and follow on documents.


If you are facing similar case, please follow the below steps for resolution:


  1. run report ZZWASTOR (contained in note 424414) which enables you to reverse one of the material documents. Please note as stated in this note it is best to check this report in a test environment first
  2. you might possibly get error message 'M7 310' which means that negative stock is not allowed. If so, need to be able to allow neg. stock by changing the setting in transaction OMJ1 to allow negative stocks and set messages 'M7 310' and 'M7 309' as 'no message' in transaction OMCQ
  3. so, run ZZWASTOR
  4. change OMJ1 back to not allow negative stocks and set messages 'M7 310' and 'M7 309' back to error message in transaction OMCQ
  5. if delivery appears in status in process and not complete, run RVDELSTA (note 506510) which will reset the status of the delivery.



Regarding to OMJI, waiting time '10 seconds' is usually set for 'late block' and this is correct. But keep in mind that there are advantages and disadvantages of each option. Using 'late block' duplications can happen again.




When material master data is read for the first time during a goods movement, this indicator specifies that tables MARC (plant data) and MBEW (accounting data) are locked exclusively until the goods movement has been fully posted. Another user cannot maintain the material during this time. The disadvantage is the long period of time for which the lock is set (from the time the material master data is first read when the  goods movement is entered through to  completion of the update posting).


Specifies that a material:

  • is not always blocked exclusively, but only if data is actually to be saved.
  • is blocked exclusively as late as possible to keep the lock time to a minimum


The advantage is that several users can enter goods movements at the same time because only one shared lock is set for the material when the movement is entered. The disadvantage is that the material master record is read several times and, in the case of an outward stock movement, that the lock entries of other users on the ATP server also have to be considered. These additional accesses have a negative effect on performance.


The late blocking works on the material level, if the material is being updated, all in relation to that material will be blocked until the posting is complete. The block works for any type of goods movement.


Check the following notes for further information on this topic:


70865   - Material block during goods movements

322989 - Late block: Number of blocking attempts
521945 - FAQ: Material block



See additional info of note 322989.
Cause and prerequisites
"Late block" does not mean "No block". It is required for sending exclusive blocks. This is carried out online for a short time and then only when entering the hot phase of the update preparation so that several movements can be entered at the same time. This creates situations where a process requests this block, however the exclusive block is held by another process which is currently in update. In this case, the waiting process tries several times to request the
block by itself. When a certain number of attempts have been made, it then abandons this and generates the error message.


I hope this info could be useful to SCN Community!


Kind Regards,

Fábio Almeida - MM Support Consultant


Filter Blog

By author:
By date:
By tag: