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.


Requirement

 

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.


Solution

 

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.

 

1.JPG

 

 

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

 

2.JPG

 

    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.


4.JPG


3.JPG

 

    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.


5.jpg


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.

Picture1.png

    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.

       1.png

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

          2.png

         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.

PUR.JPG

 

 

 

    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


SRM.jpg


MM.png


 

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.

 

 

 

 

 

 

 

 

 


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:


 

screen1.gif


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

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:

dev.jpg

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

dev.jpg

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:

dev.jpg

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

dev.jpg

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.

dev.jpg

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
not?

 

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:

   
    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.

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.

Stock.jpg

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


OSPX.jpg

 

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.

Issue.jpg

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

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

1.png

 

 

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.

2.png

 

 

Tolerance Key

RBKP

RBKP_BLOCKED

RSEG

Auto release

KW

No blocking indicator update (ZLSPR)

A- Auto block

RSEG- SPGRP = X

(Price block for Delivery cost line)

NO


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.

3.png

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.

4.png

 

Tolerance Key

RBKP

RBKP_BLOCKED

RSEG

Auto release

LA

No blocking indicator update (ZLSPR)

A- Auto block

RSEG- SPGRP = X

  1. Yes. If we adjust the PO overall limit


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.

5.png

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 .

6.png

Tolerance Key

RBKP

RBKP_BLOCKED

RSEG

Auto release

LD

No blocking indicator update (ZLSPR)

A- Auto block

RSEG- SPGRT = X

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

 

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

1.png

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.

2.png

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

  3.png

Tolerance Key

RBKP

RBKP_BLOCKED

RSEG

Auto release

PP

No blocking indicator update (ZLSPR)

A- Auto block

RSEG- SPGRP = X

  1. Yes. If we adjust the PO Price

 



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

4.png

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

 

Tolerance Key

RBKP

RBKP_BLOCKED

RSEG

Auto release

PS

No blocking indicator update (ZLSPR)

A- Auto block

RSEG- SPGRP = X

  1. Yes. If we adjust the PO 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

   5.pngjavascript:;

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

RBKP

RBKP_BLOCKED

RSEG

Auto release

ST

No blocking indicator update (ZLSPR)

A- Auto block

RSEG- SPGRT = X

  1. Yes.

 



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.

6.png

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.

   7.png

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.



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

1.PNG

 

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;

2.PNG

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

3.PNG

We are again prompted to select the desired condition,

4.PNG

now we see a screen with no mandatory fields

5.PNG

and on execution of the same.. TaDa !

6.PNG

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.

7.PNG


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

Actions

Filter Blog

By author:
By date:
By tag: