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:
http://wiki.scn.sap.com/wiki/display/ERPSCM/Unexpected+changes+in+the+Moving+Average+Price

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,
Peter

Overview

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.

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.

Net PPV

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.

http://scn.sap.com/docs/DOC-50821

http://scn.sap.com/docs/DOC-50822

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

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;

CASE 1:

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.

CASE 2:

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.

CASE 3:

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;

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

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 OX10for SAP recommended standard process of Plant creation.

Auf Wiedersehen

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.

Regards,

Prasoon

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:

• COMMIT WORK
• FROM MEMORY
• 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)
• ROLLBACK WORK
• MESSAGE TYPE 'A'
• 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.

   Considering sequence below:

• Material document:

          Call function 'A' in update task.

          Call function 'B' in update task.

      
          BAdI  MB_DOCUMENT_BADI (method MB_DOCUMENT_BEFORE_UPDATE)
          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.

      
        BAdI  MB_DOCUMENT_BADI (method MB_DOCUMENT_BEFORE_UPDATE) ROLLBACK is triggered
        -> 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,

Objective:

    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 messageis  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.

        endif.

  endloop.

      
  endif.

endloop.

endmethod.

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.

=========================================================================================================

Testing:

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.

Hi

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.

SAP KBAs

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

SAP HELP LIBRARY

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

Thankx to all

Kaushal Sharma

More than a few times the analysis of issues regarding conditions in documents like POs, SOs, etc have me checking their Condition Record as the first step. Be it Message Output Type or Pricing Conditions or Tax Conditions. Also, for request like View Condition records through Table from my Master Data team or colleague  so that they can take dumps of the same or check if the request for maintaining a certain value in the Condition Record, recently I have the best possible answer for them. I owe this discovery to a senior Technical Consultant who showed me what i consider a trick !

First we go to the display transaction of the corresponding condition record MN06, VK13, FV13, MN03, MN09, MN15, MRM3, etc

Since I am an MM consultant will go with MN06 here for illustration purpose;

On the first screen we can select any Key combination for the desired output message, here we have 0003

Then we are prompted to choose the key combination, we will choose any as our objective is a complete list of values maintained irrespective of a particular Key combination chosen now;

The trick now is to fill the mandatory field (with anything, giberrish will do as shown below ) and hit the Condition Info button.

We are again prompted to select the desired condition,

now we see a screen with no mandatory fields

and on execution of the same.. TaDa !

We have the list of all the values maintained in the condition record. For further beautification click the ALV button on top and we have options to search and extract this data.

Hope you find this as useful as I do. Would love to hear back from you on this and all else

Wishing you a good life !

Archit

Finally here is the part 2 of Invoice Tolerance keys which is the continuation of part 1  .

KW: Variance from condition value

Definition:

The system calculates the amount by which each delivery costs item varies from the product of quantity invoiced * planned delivery costs/ planned quantity. It compares the variance with the upper and lower limits defined (absolute limits and percentage limits).

System Behavior:

PO Qty = 100 EA

FRB1 = 100 SGD

GRN Qty = 100 EA

IR Qty = 100 EA

Planned delivery cost = 110 SGD

Variance (KW) = 100 * (110/100) = 110 which is 10 SGD more than PO but within the tolerance hence No warning message.

If planned delivery cost is 111 SGD

Variance (KW) = 100 * (111/100) = 111 which is 11 SGD more than PO value above the tolerance hence below warning message will be issued and invoice will be blocked for payment.

LA: Amount of blanket purchase order

Definition:

The system calculates the sum of the value invoiced so far for the order item and the value of the current invoice and compares it with the value limit of the purchase order. It then compares the difference with the upper percentage and absolute tolerances defined.

System Behavior:

PO Limit = 1000 SGD

GR not applicable

IR1 Value = 500 SGD

IR2 Value = 510 SGD system allows without any warning message as the variance = (500 +510)=1010 is compared with PO limit 1000 SGD which is within the tolerance.

If we try to post the invoice for 511 then system would throw below pop-up message. Still we can post the invoice which will be blocked for payment.

LD: Blanket purchase order time limit exceeded

Definition:

The system determines the number of days by which the invoice is outside the planned time interval. If the posting date of the invoice is before the validity period, the system calculates the number of days between the posting date and the start of the validity period. If the posting date of the invoice is after the validity period, the system calculates the number of days between the posting date and the end of the validity period. The system compares the number of days with the absolute upper limit defined.

System behavior:

Scenario 1:

PO Validity end date: 03/12/2015

Posting date : 13/12/2015

No warning message because (13-03)= 10 days is within tolerance

Scenario 2:

PO Validity end date: 03/12/2015

Posting date : 14/12/2015

Warning message as below since variance is above tolerance (14-3) = 11 days. It will be blocked for payment .

PP: Price Variance

Definition:

The system determines by how much each invoice item varies from the product of quantity invoiced * order price. It then compares the variance with the upper and lower limits defined (absolute limits and percentage limits).

When posting a subsequent debit/credit, the system first checks if a price check has been defined for subsequent debits/credits. If so, the system calculates the difference between (value of subsequent debit/credit + value invoiced so far) / quantity invoiced so far * quantity to be debited/credited and the product of the quantity to be debited/credited * order price and compares this with the upper and lower tolerance limits (absolute limits and percentage limits).

System behavior:

Scenario 1:

PO Price :100 SGD / Item

PO Qty  -:100 EA

PO Total value : 10000 SGD

IR Total amount: 10010 SGD

IR Qty  - 100 EA

System would allow without any message. Since the variance is (10010 – 10000) = 10 SGD which is within the tolerance.

Scenario 2:

PO Price :100 SGD / Item

PO Qty  -:100 EA

PO Total value : 10000 SGD

IR Total amount: 10011 SGD

IR Qty  - 100 EA

System would pop-up below message. Since the variance is (10010 – 10000) = 11 SGD which is above the tolerance and it will be blocked for payment.

Scenario 3:

Invoice & Subsequent debit:

For the same PO Qty & amount if we do invoice as

IR Qty = 100 EA

IR Value = 10000 SGD

Then

Subsequent debit as

Qty = 100 EA

Value = 10 SGD

No warning message since the variance (already invoiced value+ current subquent debit value – PO amount ) = ( 10000+ 10 – 10000) = 10 is within tolerance.

If the value is 11 SGD then system would pop-up below message

PS: Price variance: estimated price

Definition:

If the price in an order item is marked as an estimated price, for this item, the system calculates the difference between the invoice value and the product of quantity invoiced * order price and compares the variance with the upper and lower tolerance limits defined (absolute limits and percentage limits).

When posting a subsequent debit/credit, the system first checks whether a price check has been defined for subsequent debits/credits, If so, the system calculates the difference between (value of subsequent debit/credit + value invoiced so far) / quantity invoiced so far * quantity to be debited/credited and the product quantity to be debited/credited * order price. It then compares the variance with the upper and lower tolerance limits defined (absolute limits and percentage limits).

                           This works same as ‘PP’ tolerance key when the PO price is flagged as Estimate price.

ST: Date variance (value x days)

Definition:

The system calculates for each item the product of amount * (scheduled delivery date - date invoice entered) and compares this product with the absolute upper limit defined. This allows relatively high schedule variances for invoice items for small amounts, but only small schedule variances for invoice items for large amounts

   javascript:;

System behavior:

Scenario 1:

PO item value: 100 SGD Per item

PO Qty = 10 EA

PO Value = 1000 SGD

PO Delivery date: 03/12/2015

IR Value = 1000 SGD

IR Qty = 10 EA

Invoice entering date = 02/12/2015

Variance = PO item amount * ( PO delivery date –Invoice entry date)

               = 100 (3- 2) = 100 *1 = 100 SGD

This is within tolerance hence no warning message.

If we post the invoice on 01/12/2015 then variance would be

            = 100(3-1) = 100(2) = 200 SGD

This is above the tolerance limit hence invoice would get blocked for payment.

                          There won’t be any warning message for date discrepancies before posting the invoice

VP: Moving average price variance

Definition:

When a stock posting line is created as a result of an invoice item, the system calculates the new moving average price that results from the posting. It compares the percentage variance of the new moving average price to the old price using the percentage tolerance limits defined.

System behavior:

Material master MAP price: 100 SGD

PO Price = 100 SGD , Quantity = 10 EA and Value = 1000 SGD

Invoice value = 1060 SGD

New MAP after invoice posting = 1060/10= 106 SGD

Variance = (106 – 100 )/100 = 6%

Within PP tolerance limit but above the VP tolerance limit.

Below information message will pop-up and Invoice will not be blocked for payment. Based on this tolerance key we can make the below info message as Warning or error before posting.

With this I have completed all the tolerance keys relevant for Invoice Posting.

P.S: There is one more tolerance key PC which is used for invoice with reference to Contract which is not covered in this article due to technical reasons.

Very often, when working in SAP support, we receive incidents of users asking us to find out the root-cause of an issue that happened in the past but that is not happening anymore. The answer for this kind of inquiry is usually "please provide a reproducible example of the issue on your system" and frequently the person who opened the incident cannot provide this example, but insists to know the root cause of the issue.

Let me explain what is our troubleshooting line on an application issue, in order to show how important is this reproducible example. When an incident is received by SAP Support, the following steps are carried out by the person assigned to solve the incident:

1 - General research on the documentation: In order to understand if the issue described is according to the system standard design or if there is a customizing to change the system behavior, the first step is to research on the documentation for a better understanding of the scenario. This research may include SAP Help, wikis, SCN or internal documentation and this step may be skipped if the scenario is already known.

2 - Notes search: If the research on the documentation points that the behavior described by the user is not planned, the second steps is to search for notes that may fix the issue or explain the scenario from a technical point of view. This notes search includes notes with code correction, modification notes, consulting notes, FAQ notes and KBAs.

3 - Search for similar problems: If there are no reference on the documentation or on notes, the next steps is to make a research in an internal database for similar issues described in the past. This is a very useful source of information, and we can find details about the analysis already made on a similar issue by another support engineers or developers.

If none of the above mentioned alternatives bring a solution, then the next steps is to analyze the issue directly on the system where it is happening. In this case, the best way to do it is to reproduce the scenario in the SAP internal test systems and then compare with the scenario on the system where the issue is happening.

When there is no master data or customizing setting difference that could explain the cause of the issue, there is only one option

we must run a detailed investigation using the debugger, to analyze the program execution and to understand why there is a difference between the SAP internal test systems and the system where the issue happens. In most cases, it is necessary to debug both systems in parallel, in order to understand where is such difference.

Below there are some very common issues, that it is generally only possible to find out the cause of the issue analyzing a reproducible example in debug:

1 - Database inconsistencies: Generally, a database inconsistency is only identified after it already happened. In this case, SAP can generally provide a correction report to fix the inconsistency. Analyzing the inconsistent data on the database tables is not enough to find the root cause of the issue, because the same table can be update by many different programs or transactions. Running the transaction without being able to recreate the inconsistency it is also not enough, since it will be only possible to observe the standard program flow.

2 - Issues caused by user-exits, BAdIs, modifications or customer enhancements: Very frequently, the issue is caused by a custom code implemented on an exit, BAdI, modification or enhancement. In this case, it is also necessary to analyze a reproducible example in debug, since the custom code implemented is not known to SAP. By running a reproducible example on the customer system, it is possible to jump the custom code in debug, in order to identify if the issue lies on the standard SAP code or on the custom code.

3 - A short dump or any issue that happens randomly: It is very common that an issue, such as a short dump, happens randomly on the system and the user cannot track exactly the steps to recreate this short dump. In some cases, the short dump provides useful information that helps to identify what is causing it, but this is not always true. Sometimes, the short dump does not provide enough information and it is necessary to reproduce the issue, so that it is possible to see the values of the internal variables and how they are calculated.

4 - A problem that happened in the past and it does not happen anymore: It is usual that an issue is observed on a system once and then it never happens again. Considering my area of expertise, I usually hear that the MRP results are incorrect, but when I try to run MRP again for the same material, everything is perfect. Unfortunately, it is not feasible to keep logs of everything on the system, as it would increase the database size and lead to performance issues. Therefore, sometimes it is not possible to interpret the results of an MRP run that happened in the past. The same is valid for all the areas.

If you take a look on the SAP 9, it explains that the when the issue is not reproducible, it may not be always possible to find out the root cause of the issue.

Therefore, before opening an OSS incident to SAP, please try by all the means to track the steps to reproduce the issue on your system. If this is not possible, please be comprehensive if you are asked for a reproducible example and try to understand if it is not possible to find out the root cause of the issue without this example.

Storage Location Determination Rule by Qty & then Storage Location Priority.

This concept is used in most of the Industry where stock of a material is available in multiple storage loaction & there is a requirement that during Receipt or Issue system should consider the Qty as well as Storage location based on the business requirement.

In the below Screen Shot we can see the stock of a raw material available at 4 different Storage Location.

As in this case we are determining the stock based on Qty first & then Storage Location

Step01:-Firstly we create a Stock Determination Group with T code OSPX,

Step02:-Assign the Stock determination group to material master

Step03:-Create a Stock Determination Rule & do the assignment of Plant, Stock Determination group & stock determination rule T-code OSPX

We define the Priority of Storage Location as shown below.

Based on this priority of storage location will be determined.

Step04:-Now we assign the Stock determination rule to the respective Movement type

1. Path:-SPROàMaterials ManagementàInventory management & Physical InventoryàStock DeterminationàAssign Stock Determination Rule in the ApplicationsàInventory Management

This completes the configuration Part.

Now for example we issue this Raw material to check how system determines the storage location priority.

As we press Enter system determines the stock based on Qty & then storage location as below

This is how we can manage the stock of material based on Qty, Storage Location for all respective Movement types (i.e. receipt & issue).

Working as a FICO consultant on a number of different projects, I noticed that nearly all of my clients had a common issue: The GR/IR (goods received/invoice received) account. In theory, you raise a purchase order, the goods arrive, and you post a goods receipt. This acts as an accrual posting between costs or stock and the GR/IR account. If the quantity on the invoice equals the quantity posted in the goods receipt, the GR/IR should clear down to zero. Regardless of whether the quantities match, if the price doesn’t match the invoice could be blocked for payment.

On occasion, users couldn’t understand why a balance remained on their GR/IR account or why an invoice continued to be blocked for payment when they thought that the process had completed correctly. Often at the year end their GR/IR account had accumulated a large balance, which the accountants struggled to analyse for the resolution of any errors.

Somehow I always ended up involved not only in helping tidy up the account, but also explaining quite a lot about the process. I thought it would be a good idea to put everything I knew about it down in one place; an SAP PRESS E-Bite.

My E-Bite (link below), explains how the whole invoice verification process works and gives tips on how to optimise the flow. It begins by outlining the key settings in the vendor, material, and GL account master data, and the effect that they have on the behaviour of the purchase order and goods receipt, and therefore the way the matching takes place with the invoice and credit notes.

I noticed many users were either unaware of the different document types or unclear on which to use when. For example, when to use a credit memo and when to use a subsequent credit. Using the wrong document type may inadvertently create a balance on the GR/IR, where one did not exist before, or not clear one that should be cleared.

One chapter of the E-Bite explains the financial postings of all the documents and another goes through various reports and gives tips on how best to analyse the GR/IR account.  Just because there is a balance on the GR/IR account doesn’t necessarily mean that the invoice is blocked for payment; nor does a payment block mean that there is a related balance on the GR/IR account.

I firmly believe that, where possible,  you should correct errors at the source, so, if for example, a purchase order price is incorrect, it’s usually best to proactively make the corrections to the purchase order and/or the material/purchase info record. If a goods receipt or invoice is incorrect, simply removing the payment block risks having the incorrect stock, leaving a balance on the GR/IR and affecting the moving average price etc.

There are a number of scenarios where it may not be possible to correct the error at the source, but the good news is there are various transactions in SAP that you can use instead. I explain in my E-Bite which ones to use when.

My (non-SAP) sister was very excited when she heard that I had a publication with my own ISBN number.  I don’t know if she was expecting the next JK Rowling, but when I explained what it was about, she looked blankly at me and said “err -that’s not exactly going to fly off the shelves!” However; I do hope it is useful to some people, (other than for bed-time reading), and that there may be helpful information inside that not everyone is aware of.

https://www.sap-press.com/invoice-verification-with-sap-payment-blocks-in-grir-accounts_4052/

When you create an STO, do you know it is one-step or two-steps transport? When you

create delivery for the STO, can you judge if the movement type system determined is correct or
not?

In this blog, let me introduce my way to check these points.

★Whether the STO is considered as 1-step?
   

As you can see in the picture above, system check table T161W with supplying plant+ recieving plant +
document category. The document type of the STO is not a key for determination at all. You can check

table T161W to see if this STO is considered as one-step or not.

★How system determines the movement type?

    Afterwards, system checked the delivery item category, in T-code VL03N you can see it,

    for example the delivery item category is NLRN. Then in the following customizing:

   
    IMG->

         Sales and Distribution ->
               Sales -> Sales documents ->
                      Schedule lines -> Assign schedule line categories

system founds the schedule line category, for example it is NR. At last, in T-code VOV6, for Sched.line cat NR,
you can see there is setting: 

    ******************

    Movement Type             671

    Movement Type 1-Step   677

    ******************

Therefore if the STO is one-step transport, then the movement type will be 677 in the delivery. Otherwise it will
be 671.

Hope this can be helpful. You may also want to read KBA 1774717 - Table T161W - document type not taken into account.

Have you ever wondered why planners tend to rather use a safety stock with MRP Type 'PD' to buffer variability, as opposed to a reorder procedure? Oftentimes PD is used across the board and no one wants to bother with another MRP type. However, with SAPs standard configuration the safety stock doesn't serve as a planning buffer and the additional inventory ends up being dead stock.

Consider the following scenario: a safety stock of 30 pieces is set and a production order asks for 10 pieces on April 15. A deterministic planned material (PD) would replenish the inventory up to 40 pieces just before April 15. If, for some reason, the production order would increase the required quantity to 15 pieces two or three weeks before its start date, the MRP run (which excludes safety stock in the net requirements calculation) would generate an additional order proposal for 5 pieces. In that case, the inventory on April 14 would be 45 pieces... even though 40 would be plenty (25 more than needed). Simply speaking: safety stock is taken out of the planning efforts and the entire safety stock remains unused (...becomes dead stock).

A far better solution, in my opinion, is the use of a reorder point method. If we're taking the same example, we'd set the reorder point to 30 pieces and thge MRP run would only replenish if the inventory level is lower than 30. During the replenishment lead time these 30 pieces serve as a true buffer and are consumed by regular consumption. Any safety stock that is set, is only used as a signal (exceptional message) when inventory gets really low. As you can see in below graphic, this method is a true buffering strategy.

Switching your policy from a PD with safety stock to a reorder point procedure will instantly reduce your dead stock and bring average inventory holdings down. If you're concerned about stock-outs, increase the reorder point. That is much better than never dipping into safety stock.

(note: if you're adamant about using PD. you can customize SAP so that at least a portion of the safety stock is considered as a buffer for planning)

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.

Regards,

Prasoon

Recently I am on a project. In this project, we had a challenge.

In their business, they have 61 plants (for three company codes) and they are using stock transport order from 5 manufacturing plants to all those 56 plants (basically called Depots).

They are using a transfer price for each stock transport order. Transfer price is nothing just a condition type is added into schema and amount will be fetched automatically from condition record.

They have over 20k material and they have 7 different price as per different locations. Multiple plants is exist for one location. They have categorized all plants into 7 different price lists.

First we have tried to map condition record by using combination Receiving plant and Material. But then we realized that condition record has to be maintained 56 times for all 20k materials. It’s really a tough job for user to maintain price for 56 times for 20k materials.

Basically, their requirement was to categorized plant with regards to price list. So we did need to find a field which can be assigned to multiple plants (with same value) and this field can be used for price determination. Unfortunately we did not find any such field.

Then we found an option to map their requirement. A customer (plant as customer) need to be assigned to plant in case of stock transport order. We take the field Price list (PLTYP) from customer master as a category of those customers which are assigned to certain plants.

Note: They were not using that field (Price list) in SAP system.

Price list is available in field catalogue for MM pricing. If not, then you can add it from OLME-Conditions-Define Price Determination Process-Extend Field Catalog for Condition Tables.

Then create a new condition table from M/03:

Then add this condition table to certain access sequence from M/07. Then use this access sequence for that certain condition type.

These were the configuration done from functional side (for clear information, you can check this blog post Pricing procedure Steps and Details in SAP MM). Now one enhancement has to be done from technical side.

We need to pass the price list value to KOMK and KOMP structure by using enhancement LMEKO001 - Extend communications structure KOMK for pricing and LMEKO002 - Extend communications structure KOMP for pricing.

Coding part is:

DATA: lv_kunnr TYPE kna1-kunnr.
IF i_ekko-bsart = 'ZUB'.

   SELECT SINGLE kunnr FROM t001w
     INTO lv_kunnr
     WHERE werks EQ i_ekpo-werks.
   IF sy-subrc EQ 0.
     SELECT SINGLE pltyp FROM knvv
       INTO e_komp-pltyp_p
       WHERE kunnr EQ lv_kunnr
       AND   vkorg EQ i_komk-vkorg
       AND   vtweg EQ i_komk-vtweg
       AND   spart EQ i_komk-spart.
   ENDIF.


ENDIF.

We have made it for ZUB document type only (you can do it for UB document type also), so that it wont take effect for any other process (like Inter company STO). In that coding you can see we have taken KUNNR from T001W table and take the price list (PLTYP) value from KNVV table with certain selection criteria (like Sales organization, Distribution channel and Division) and pass the value to certain structure.

Note: You have to do this coding for both enhancement (LMEKO001 and LMEKO002).

Now take those assigned customers from T001W table and categorized these customers (plant as customers) with certain value in Price list. E.g. S1 - Sales Price_West Bengal, S2 - Sales Price_Delhi, S3 - Sales Price_Mumbai etc. You can find it in sales view of customer master record:

Now create condition record by using this condition table from MEK1:

Now create stock transport order where be sure you are using correct receiving plant, as customer (plant as customer) will be fetched from shipping data of particular receiving plant.

Here, you can see Transfer price has come automatically with correct price which we have maintained in condition record. In shipping tab, you can find the same customer code.

Now they are happy with that. They just need to maintain condition record for 7 price list and it will be effected for all 56 plants.

I have given an example to use the field Price List (PLTYP), you can use any other field. Just remember, that field has to be exist in price field catalog.

All of you who heard about Lean Manufacturing also are probably familiar with KANBAN concept. It is not new anymore but surprisingly not that popular around production facilities using SAP, even though SAP ERP has the KANBAN submodule sitting there in Production Planning section (though often the actual process is much more present in internal and external logistics area the production).

If you are one of those who knew about SAP KANBAN and managed to get the customer to use some of internal, external or in house manufacturing scenarios of KANBAN, you might find topic of this post quite interesting. As the solution itself offers some very well thought, flexible and diverse standard customizing options, the problem is with maintaining of implemented KANBAN cycles.

If you take an example of automotive company using a lot of KANBAN cycles with a lot of small parts used for manufacturing, you will see the problem of managing these hundreds of records in the system. How to massively change status sequence if you decided to do it? How to follow the lifecycle of particular cycle? This is not easy in SAP… unless you know the add-on Kanban Enhancements for Lean Manufacturing.

This is the add-on that you can activate via Switch Framework in t-code SFW5. Technical name is LOG_PP_LMAN_02 located in DIMP Business Function Set. What is very good also is that the activation is reversible so if it clashes with some of your other settings or custom development, you can go back anytime.

There are several functions delivered with this add-on, I wanted to mention ones most useful from maintenance point of view:

Mass-Processing for Control Cycles - that, by adding ALV view for PKMC transaction (KANBAN control cycle maintenance), enables you to process several control cycles centrally and quickly gain an overview of the consistency of the control cycle data.

Lifecycle for Control Cycles - you get four new statuses to represent the state of your control cycles plus ability to turn on change documents for control cycles and trace all changes in the control cycle data

Authorization Concept for Status Changes - you can grant authorization for status changes on a targeted basis and restrict the steps in the Kanban process to certain user groups or individuals (only desired groups can trigger particular KANBAN statuses).

The full description of this add-on, together with some further customizing needed to make it work is available in SAP help portal under:

http://help.sap.com/erp2005_ehp_05/helpdata/EN/2E/E99624B22D4BA9862FBF1D9AE7792A/frameset.htm

Have you experienced the issue that the commitment was not generated for Purchase Requisition and Purchase Order? Or the commitment value was not reduced or displayed as you expected? Now a new tool has been released with SAP KBA 2272940.

By running this tool, you will get the information about which customizing setting is requested for generating the commitment, and whether the commitment value is correct. In case of there is data inconsistency in the commitment table, it will provide you the resolution for fixing it.

You can find more detailed instruction in SAP Wiki page Commitment checking tool and the troubleshooting guide Commitments in Material Management.

Years ago, a friend of mine, gave me a gift that represented this expression ‘Old is Gold’. It is a Hindi proverb and, if I understood properly, it means that ‘we should not neglect our elders just because they are old but take care of them like they are precious as gold’.

This year, I am leading a project to reshape the layout of ERP Materials Management Wiki in our SAP Community Network (SCN), and during all projects phases this Hindi expression was coming to mind in a different perspective. I was trying to figure out how to bring a ‘21^st century look’ to our MM Wiki Space without losing the precious content produced along the years. ‘Old is Gold’ and we could not destroy everything just trying to achieve an innovative concept. The key factor to deal with this point was to use a ‘bottom up’ perspective, involving SAP Consultants worldwide (Seniors and Millennials). We created several prototypes in different SAP locations and, building on top of other’s idea, we reached our final prototype.

Therefore, I would like to announce that our new ERP MM Wiki Space is live.

ERP MM Wiki Space is divided in the following areas:

• ERP Materials Management (main page)
• Inventory Management
• Invoice Verification
• Purchasing
• Service Procurement
• Cross-topics (MM)

In this space, you can find all SAP Product Support Media Channels and relevant links (Troubleshooting Guides, FAQ Notes, SAP Help, etc). It is also possible to submit your own content in our Staging Area and suggest a new content to be created by SAP Support.

Feel free to go through this channel and please share to your peers.

Kind Regards,

Fábio Almeida - MM Support Consultant/Project Manager

We were once handling a high profile Customer who implemented SRM Central Contracts and replicated them to ECC. They faced many issues related to data consistency between the 2 systems particularly in the MM-Services module. This is one such case where the added  services in SRM went missing in ECC.

Basically when you create a contract and change it by adding an outline and some services under it from SRM , the services under the new outline went missing. Initially it started off that only bigger contracts with many outlines were causing the issue but also for very simple structures also this occured like,

Main Outline

• First Outline  ==> with services
• Second Outline

           -->Sub outline

We could not reproduce by blocking the queue and re-running it (or) via SPROXY debugging, it happened when the outbound and inbound queue processing was really fast i.e., when we execute the end-end process from SRM.

But luckily we found a pattern and we tried to re-create it whilr debugging and it indeed reproduced the same issue.

Root Cause

In all working scenarios in table ESLL , SUB_PACKNOs are generated in ascending order,

PACKNO INTROW     EXTROW     DEL SRVPOS RANG EXTGROUP PACKAGE SUB_PACKNO

0031843468   0000000001 0000000000                     0     0000000000

0031843468   0000000002 0000000001                     1     13.13                X 0031843469

0031843468   0000000011 0000000001                     1      90000                  0000000000

0031843468   0000000012 0000000011                     2      70000              X  0031843475   >> sub_packno is generated in ascending…

0031843469   0000000007 0000000010   13019828 0 0000000000

0031843469   0000000008 0000000020   13019829 0 0000000000

0031843469   0000000009 0000000030   13019830 0 0000000000

0031843469   0000000010 0000000040   13019831 0 0000000000

0031843475   0000000013 0000000010   13019742 0 0000000000

In all NOT working cases , SUB_PACKNO were generated in descending order…  

1. Table: ESLL

PACKNO INTROW     EXTROW SRVPOS EXTGROUP PACKAGE SUB_PACKNO   SRVMAPKEY

0031844534   0000000001 0000000000 0000000000                     0000000001

0031844534   0000000002 0000000001 13.13                X              0031844535   0000000137

0031844534   0000000011 0000000001 98765               X              0031844499   0000000142 > sub_packno in descending order

0031844535   0000000007 0000000010 000000000013019828     0000000000   0000000138

0031844535   0000000008 0000000020 000000000013019829     0000000000   0000000139

0031844535   0000000009 0000000030 000000000013019830     0000000000   0000000140

0031844535   0000000010 0000000040 000000000013019831     0000000000   0000000141

Debugging Analysis:

After create, 

PACKNO       INTROW     EXTROW DEL SRVPOS               RANG EXTGROUP PACKAGE SUB_PACKNO

0031844634 0000000001 0000000000                                         0                                             0000000000

0031844634 0000000002 0000000001                                         1         13.13             X             0031844635

0031844635 0000000007 0000000010   000000000013019828       0                                             0000000000

0031844635 0000000008 0000000020   000000000013019829       0                                             0000000000

0031844635 0000000009 0000000030   000000000013019830       0                                             0000000000

0031844635   0000000010 0000000040     000000000013019831   0                                             0000000000

During change New PACKNO is generated from below FUNCTION,

SAPLSNR3              FUNCTION              NUMBER_GET_NEXT

CL_PUR_PC_MAPPING_XI_TO_ERP===CP      METHOD                MAP_PC_ITEM_XI_2_ERP_WITH_HIER

CL_SE_PUR_PCSRMRPLCTNRQ=======CP     METHOD                MAPPING_IN

CL_SE_PUR_PCSRMRPLCTNRQ=======CP     METHOD                PROCESS_IN

CL_SE_PUR_PCSRMRPLCTNRQ=======CP     METHOD                EXECUTE

CL_PUR_PURGCONTRTSRMRPLCTNRQ==CP   METHOD                II_PUR_PURGCONTRTSRMRPLCTNRQ~PURCHASING_CONTRACT_SRMREPLICA

CL_PROXY_INBOUND_AGENT========CP    METHOD                IF_PROXY_INBOUND_AGENT~EXECUTE

Since I suspected that if the generated number from the FM is not in ascending order from the previously generated service package then the following thing happens, I changed the number to ‘0031844633’, one number prior to the first outline '0031844634.'.

So the programs came to the below flow,

SAPLMLSP             FORM     UPDATE_IX_CONTR

SAPLMLSP             FORM     ROW_IN_CONTR

SAPLMLSP             FUNCTION              MS_CHANGE_SERVICE_PACKAGE_CONT

SAPL2014              METHOD                CHANGE_PACKAGE

SAPL2014              METHOD                IF_BAPI_MEOUT~SET_ATTRIBUTE

SAPL2014              METHOD                POST_PROCESS

SAPL2014              METHOD                SET_OBJECT_ATTRIBUTES

SAPL2014              METHOD                PROCESS

SAPL2014              METHOD                IF_PURCHASE_OUT_BAPI~PROCESS

There is a READ table with Binary search

  READ TABLE ix_esll WITH KEY packno = esll-packno

                              introw = esll-introw

                              BINARY SEARCH.

Internal table    ix_esll[]

0031844634|0000000001|000000000<                  |0031844635    |U |

0031844634|0000000000|000000000<                  |0000000000    | |

0031844634|0000000001|000000000<                  |0031844635    |U |

0031844634|0000000001|000000001<                  |0031844633    |I |

0031844635|0000000010|000000000<000000000013019828|0000000000    | |

0031844635|0000000020|000000000<000000000013019829|0000000000    | |

0031844635|0000000030|000000000<000000000013019830|0000000000    | |

0031844635|0000000040|000000001<000000000013019831|0000000000    | |

0031844633|0000000010|000000001<000000000013014792|0000000000    |I |

Since IX_ESLL is not in sorted order the read table failed with SY-SUBRC = 4. But since there was no SY-SUBRC check, the next statement where ESLL held the new service line Information got overwritten to IX_ESLL structure

  MOVE-CORRESPONDING esll TO ix_esll.

MANDT  C              3 100

PACKNO N             10 0031844633

INTROW N             10 0000000012

EXTROW N             10 0000000010

DEL         C              1

SRVPOS  C              18 000000000013014792

, and later the content is updated into IX_ESLL internal table but the KZ flag is ‘U’ because it has the flag of the previous read outline.

We had a discussion with Development and came up with a logic in the calling subroutine and created note 2110200 for this rare case.

Hope the above information would be useful in such kind of weird cases where blocking queues would not reproduce the issue but only when queue processing is very fast.