Last week I attended a design thinking workshop. Design thinking is an approach to solve challenges and accelerate innovation by combining three different interests: desirability, feasibility and viability.


Excited by what I learned there, I shared my newly acquired knowledge with a colleague. After discussing, we looked at areas where design thinking could be applied to topics we deal with every day at SAP. Currently, we work on the integration of Ariba procurement and sourcing solutions to SAP ERP applications. Could we use design thinking to accelerate innovation in even that topic? In order to answer that question, we simply applied design thinking to this particular scenario and tried to come up with an ideal solution!


So what’s important for a smooth integration to SAP Ariba apps? First, the integrators need to develop the business processes across the different applications. Wouldn’t it be great if they had already best practices and ready-to-go business process diagrams?


Our customers don’t want to waste their resources on paper work and manual processes. That’s why they decided to exchange documents with their business partners electronically on the SAP Ariba Network in the first place. This brought up our second requirement. Integrators need to properly configure the communication channels among the apps for those electronic documents to fly back and forth across the network. Wouldn’t it be great if they had best practices and ready-to-go configurations available?


Before going live with integration, you have to test it. Everybody who has done this before, would agree that developing test scripts on your own can be a pretty tedious task. Wouldn’t it be great if they had access to best practices and ready-to-go test scripts?


Obviously, it did not take long until our SAP Ariba Integration rapid deployment solution (RDS)  came to our minds. It contains best practices with business process diagrams, with configuration guides and test scripts. It already provides the necessary tools and, by the way, combines the three pillars of design thinking, namely; feasibility, desirability and viability.


Summing up our little experiment: we could have saved our resources and brain power on design thinking and just used the prepackaged SAP Ariba Integration RDS instead. The great news is that if you’re looking to simplify your own integration with SAP Ariba, you can save yourself a lot of time and effort and simply leverage the RDS!


The current limit of the MIGO Serial number screen is to accept Serial numbers in a batch of 6. This makes it difficult and incurs time to receive goods more than 6.



The functionality should allow the user performing Goods Receipt to select any number of serial numbers from the excel sheet and use the functionality of clipboard to paste the same instead of keying in each serial number one by one.



Include: LMIGODS3


Step1: created an implicit enhancement ZMIGO_SERIAL_NUM for the method tableview_serial_cursor .


Attached the clipboard functionality to the ENTER command


Step2: Get the cursor field to determine where the enter in pressed.


Step3: Use the clipboard method to get the data.


Step4: Update the structure.


Step5: Clear the clipboard.


Go to transaction MIGO


Open a purchase order


Copy some serial numbers from excel, place the cursor on the row and paste them by pressing ENTER.


Now we can enter as many as serial numbers directly without scrolling down.

    Sometimes after posting material documents, user found the G/L account for transactions in accounting
document is unexpected. But how to check the customizing of G/L account maintained for transactions?
Please let me take transaction GBB for example and introduce it:


    Firstly you need to access T-code OB62, to get the "Chart of Accounts" which is assigned to the company
code in your case.





    Secondly please goto T-code SE16 and display table T001K. Get the value of field "BWMOD" for corresponding
valuation area and company code. This is for "Valuation modification".




    If you need to know the "General modification", you can run T-code OME9 for the corresponding account
assignment in your case and get the value of "Account Modification".
Also in T-code MM03, you can get the
"Valuation class" in the 'Accounting' view for
this material.




    Finally, you can run T-code OBYC and select transaction GBB, enter the "Chart of Accounts" you got in the
first step, you can see the G/L accounts maintained for all "Valuation modification" and "Valuation class".

You can select the line according to the value you got in the steps above, and check the accounts.


Hope this is helpful and you like it


     When creating or changing a purchasing document the message determination will

be always processed to find out if an output message can be created at header level.

But sometimes, the output determination is not working well. In this blog, I will share

some tips about trouble shooting for output issue in PO.

1.  No output message was created automatically

   a. Try with standard settings

    b. Are partners correctly determined?

    c. If reproducible with standard settings, check the configuration.

2.  Wrong output message appears by default

   a. Try with standard settings

    b. If reproducible with the standard settings go to header/message, goto/determination

        analysis. You’ll see where the message is coming from. See the following example.


    c. Are partners correctly determined?

    d. Check the configuration.

3. The message is not processed, get a red cross or/and red light in header/message.

    a. Go to header/messages/ processing log, look at the error message

     b. Try with standard settings.

     c. Check that there is no release strategy. If there is one, the purchasing document

         needs to be fully release before being able to process it.

     d. If processing time is 4, try with 3.

     e. Check the configuration.

4. change message - problem to create it or to process it.

     a. A change message is created automatically if you change a field and if you have the
         following settings in place: 
For output type NEU you have Prog: FM06AEND and

         Form routine: CHANGE_FLAG.


         You should have one line with output type and the require operation for change.


         MM/Purchasing/Messages/Output control/ Message determination schema/assign

         schema to …: ‘M’ should be flagged.

    b. Two ways to repeat messages: Go to ME22N and Go to header/message,

        select the message you want to repeat and press ‘repeat output’. Then Go to

        ‘Message output’ transaction (e.g. ME9F for Pos) to output the message.

        The other way is Go to ‘Message output’ transaction (e.g. ME9F) and execute

        with ‘processing status’ = 1, Select the correct line + click on ‘message details’.

        Select the correct output message + click on ‘repeat output’. Click 'Save' and return

        to the initial ME9F screen and execute it again with ‘processing status’ = 10.

Hope these information can be helpful.

       In April, our new wiki page for "ERP Materials Management" went live. The new page is more user-friendly,
also easy to read on mobile.


wiki page.JPG


   As a member of MM wiki housekeeping project, please let me introduce the features about this new page, including
some guidance about how to use it:

  ★Main page


   1. Big button replaced the link for every sub-space. You can easily access it when using mobile.
   2. Relevant links are listed on the right hand side. For example: SCN, Hot KBA, Online Help etc.
   3. There is a box to show you the contents which are updated recently.

   4. PS social media channels are listed to provide you various ways to find out information.
   5. Provide different channels for your suggestion and your content.
   6. Quick link to other areas if a question came to your mind suddenly when you went through the MM knowledge.
   7. Highlight the Trouble Shooting Guide before introducing sub space, so that you can easily find it.



  ★Sub space


   1. List all the child page in the box. You don't need to search the right one from the whole list.
   2. The sub title is defined as per function, not the technical component of MM area. This way is more intuitive
      and easier for users to understand and find useful information.
   3. Put the common one in a single box on the right hand side.





    With less clicks, you can easily get what you want. You cannot wait to try this new wiki page ERP Materials Management - ERP SCM - SCN Wiki ? Welcome to any feedback or suggestion about this new Wiki page.

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,


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


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, 


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









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,






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




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.










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 ‘21st 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.



old is gold.png


ERP MM Wiki Space is divided in the following areas:


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

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.

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:

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.


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.

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)

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


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


★Whether the STO is considered as 1-step?
    debugging screen.jpg


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:


         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.

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,

Stock Determination Group.jpg



Step02:-Assign the Stock determination group to material master

Material master.jpg

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

Movement Type.jpg

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

Storage Loc 201.jpg


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

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.

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


KW: Variance from condition value


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.




Tolerance Key




Auto release


No blocking indicator update (ZLSPR)

A- Auto block


(Price block for Delivery cost line)


LA: Amount of blanket purchase order


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.



Tolerance Key




Auto release


No blocking indicator update (ZLSPR)

A- Auto block


  1. Yes. If we adjust the PO overall limit

LD: Blanket purchase order time limit exceeded


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 .


Tolerance Key




Auto release


No blocking indicator update (ZLSPR)

A- Auto block


  1. Yes. If we adjust the PO Validity end date


PP: Price Variance



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


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


Tolerance Key




Auto release


No blocking indicator update (ZLSPR)

A- Auto block


  1. Yes. If we adjust the PO Price


PS: Price variance: estimated price


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.


Tolerance Key




Auto release


No blocking indicator update (ZLSPR)

A- Auto block


  1. Yes. If we adjust the PO Price


ST: Date variance (value x days)


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


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


Tolerance Key




Auto release


No blocking indicator update (ZLSPR)

A- Auto block


  1. Yes.


VP: Moving average price variance


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.


Filter Blog

By author:
By date:
By tag: