Whether to create worklist entries directly depends on the customizing, and to work with or without it - well, both has pros and cons. As the SAP help in  also outlines, activating Direct Entry creation (Materials Management --> Purchasing --> Conditions --> Automatic Document Adjustment --> Direct Entry for Creating Worklist > Activation of the Direct Entry for Creating the Worklist) might slow down your system. But why and how? Who will then choose this after all?
To answer this, it is recommended to be aware of the scenario when direct creation is NOT activated, so we can make comparison:
Whenever the user changes a price condition record in a Contract, in an Info record or even directly via Condition maintenance (MEK2), change pointers are written into BDCP2 DB table with CONDBI message type, storing basically a pointer on the condition record. For making use of it in Automatic Document Adjustment (ADA) functionality, a Worklist has to be generated with MEI4, which will collect those change pointers and prepare the WIND entries roughly. Now, this last step of MEI4 usage can be spared by creating worklist directly. If you activate this, the corresponding WIND entries will be created already at the time of saving the price change --> of course can add a bit overhead to the overall processing time therefore.
At the end of the day by executing MEI4 (in case of no direct creation is activated) we also can't spare the time of WIND creation, but it is executed separately and exactly when it is scheduled, for example. So some decision makers like to have more control over it, therefore might vote for MEI4, while others experiencing not much impact on performance of condition record saving can simplify the process by activating direct creation of worklist.
Also some believe executing report RMEBEMIG is a repetitive task to be performed. In fact, RMEBEMIG needs to be executed once, when setting up the direct worklist entry creation. This is converting the existing changes stored in BDCP2 into WIND worklist entries and setting the flag in above customizing to show that migration has been done. Ideally this report could also put the flag for activating the Direct Entry creation after successful run, but it can be also flagged manually. Once this customizing is activated, WIND entries will be saved automatically, and you won't be able to execute MEI4 at all for those document types - actually also wouldn't make much sense. (Remark: When you do not prefer to set the Direct Entry creation, you will still need to execute the RMEBEMIG one time for the corresponding document type (e.g. '01' for PO), but without flagging that indicator. This action will set a flag for this document type, indicating that WIND migration took place, and further MEI4 executions will be performed as desired.)
Summarizing: activating direct WIND entry creation is not a must, but finally you will have those entries by all means.
You have setup all necessary conditions types and condition tables to be considered by ADA in the customizing (Materials Management --> Purchasing --> Conditions --> Automatic Document Adjustment --> Control Document Adjustment --> Control Purchasing Document Adjustment), but you are using reference condition types as well in your business, so question might arise how to fit it with ADA.
The SAP note 59100 details clearly, that references can be considered in ADA only by implementing BAdI WIND_ADDITIONAL_DATA and put some custom code into method MAINTAIN_ADDITIONAL_DATA. And this is so far working very well for Purchasing side (type: M) conditions. But not for SD conditions (type: V)! You cannot update your documents by referencing to SD conditions in standard.
Lot of users believe executing MEI3 (together/before MEI4) is always a mandatory step. This is again a misconception. After you've activated the Document Index in the Vendor Master (also shown in ) you must execute MEI3 ONCE to create the document indexes in S111: entries will be created for each relevant condition (considering customizing activity Control Purchasing Document Adjustment), for all POs having a vendor with active Document Index active flag. Any further PO creation in the future - with a vendor having this customizing set - will create the necessary S111 entries automatically when saving the order. That means, executing MEI3 without having customizing changes is totally pointless.
The first couple of parameters on the selections screen are both self-explanatory and serve individual business requirements, so let's discuss about the rest!
Executing MEI1 for just few Purchase Orders makes not much sense in production environment, they could have been updated then manually from ME22N, too. Still, from time- to-time users complain about long MEI1 runtime even if executing it for single PO. The purpose of the whole ADA - so MEI1 - would be to do mass(!) update of condition record changes in POs. Therefore, the design of the program is optimized for mass changes, and you might observe similar runtime for executing it with one PO or with hundreds, since processing the changes, analyzing them etc. will be executed on the same amount of data, then the to-be-adjusted POs are filtered during document index reading. Of course, performance issue might happen despite of this too, but due to high dependence on the software release and other circumstances, I do not share here specific SAP notes.
Performance issue often results from uncontrolled number of S111 and/or WIND entries.
To get rid of old S111 entries, you can either archive unnecessary POs (which will clean up the corresponding S111 entries), or as an easier alternative, MEI6 transaction is also available to delete outdated S111 entries - here the selection of to-be-deleted entries depends on the user selection.
Regarding the deletion of WIND entries, please check the next paragraph, where many details and aspects are discussed.
High number of useless WIND entries might cause performance issue, even also memory/timeout dumps. As detailed above, performance issue might occur independently of the number of POs involved in the MEI1 execution, and the reason should be found when going behind the scenes and understanding the process flow. MEI1 is selecting first the available worklist entries, analyzing them, collecting the belonging condition records from various tables, then trying to match them with the available S111 entries, then any actual condition adjustment can happen only afterwards. It is easy to remark that using PO number as filter won't help much, but the number of obsolete entries in WIND all the more!
There are various strategies to handle this:
IMPORTANT: All the three options carry some risk of loosing necessary WIND data. Why?
The case with MEI1 has been already discussed in section of "Understanding the options in MEI1". Transaction MEI5 or report RWVKP03D is a manual intervention with not much automated check by the process. This means by deletion of a recent unprocessed WIND data your POs won't be adjusted anymore by MEI1 - at least not until next condition record change, since it will create a new WIND entry directly or via MEI4 -, so adjustment will made possible again. Choose the criteria therefore wisely to make sure all relevant POs have been updated before eliminating the corresponding worklist entry. The report doesn't have any check routine built-in to verify the deletion, because it is pretty complex and also very time consuming (just think over what all data would be necessary to cross-checked). See also next section about lost WIND entries.
As detailed in some sections above due to not careful handling of WIND entries, some might get deleted accidentally (without having processed all relevant POs before). This is usually noticed by users only, when no adjustment occurs on specific POs while executing MEI1. Certainly, due to the design of this process it is mostly impossible to track back whether the WIND was deleted or never existed, but when the issue occurs, this also does not really matter anymore. What can we do now?
A situation where specific PO(s) were not updated by ADA might have dozens of origins, still in 99% of cases the below circumstances are identified as root cause:
I have released a supportability tool as well (a Z code attached to SAP KBA 3205410) which you can implement in your affected system manually. This report is doing nothing else, but more or less following the same process flow like during the execution of MEI1 with a bit different approach:
For sure, the tool is not capable to find out the root cause in all possible scenarios, and might be enhanced/corrected over the time, but still provides hint in most frequently occurring cases even for end users!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.