Automatic Document Adjustment is a popular functionality widely used in Materials Management and in Retail environment as well being able to update documents based on condition changes in mass - and roughly automated!
Current blog puts focus on Purchase Order related issues, related frequently asked questions and misconception with Automatic Document Adjustment (ADA).
The whole functionality with those few transactions belonging to it is not really complicated at all, so I could share here in 2-3 steps how the whole should work in a daily usage.
But this would exactly lead to the most issues our customers are facing with. Even this simple functionality needs to be understood first to make the most out of it and having a reliable process in place. So, dear Reader, please give those 15-20 minutes to read this blog carefully, (also highly recommended to go through on [2] beforehand - another 10 minutes) and most probably you will know everything you ever needed for Automatic Document Adjustment.
The process can be setup quite easily, and Mohamed in [2] has shared a guide about it few years ago. I won't repeat the same here again, but as per my experience few steps need some clarification:
Current blog puts focus on Purchase Order related issues, related frequently asked questions and misconception with Automatic Document Adjustment (ADA).
Pre-read
- https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/9905622a5c1f49ba84e9076fc83a9c2c/e24dc4530b29b44ce10... [1]
- https://blogs.sap.com/2019/05/31/purchasing-document-adjustment/ [2]
- https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/af9ef57f504840d2b81be8667206d485/db22b853dcfcb44ce10... [3]
- Frequently mentioned DB tables:
- WIND: for Worklist, storing recent changes
- S111: Document Index, storing Purchase Orders referencing to their ADA related price conditions - as per customizing
Quick guide for usage
The whole functionality with those few transactions belonging to it is not really complicated at all, so I could share here in 2-3 steps how the whole should work in a daily usage.
But this would exactly lead to the most issues our customers are facing with. Even this simple functionality needs to be understood first to make the most out of it and having a reliable process in place. So, dear Reader, please give those 15-20 minutes to read this blog carefully, (also highly recommended to go through on [2] beforehand - another 10 minutes) and most probably you will know everything you ever needed for Automatic Document Adjustment.
Customizing
The process can be setup quite easily, and Mohamed in [2] has shared a guide about it few years ago. I won't repeat the same here again, but as per my experience few steps need some clarification:
The Direct Entry dilemma (WIND)
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 [1] 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.
The reference conditions
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.
Vendor Master setting vs. MEI3
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 [2]) 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.
Operational topics
Understanding the options in MEI1
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!
- Price Determination Type: Although the field seems to be non-editable (grayed-out), you can choose here among few price determination types (see F1 help for details). They correspond mainly to the options available in ME22N when Updating conditions for an item.
Example for usage and it's background: you can do two type price changes e.g.in an info record. In case you open an existing price there, and edit it, so simply change the price, then Price Determination type “Redetermine the changed components” can be simply used. This is just re-reading the stored condition record from DB and updating the value as desired. However, if you have made a price change in your info record for example by adding a new validity period (so not overwriting simply the existing, but adding a new one), it will create a new condition record in the DB. Therefore, simply redetermining the changed price might have no effect. In such case the second option seems to be feasible: “New price determination”. This will perform a completely new price determination in the PO, according to the customized Pricing Procedure, including the price condition types, and their values as well!
Why not to use always then the New Price determination? Well, in most cases this seems to be OK. Probably takes a bit longer time though. But in some cases it is not desired: in case you have added e.g. new price condition type to your procedure, that was not there when creating the PO originally, and you do not want to get this condition type applied, it will appear and bring it's value, even if the condition type itself is not maintained in the customizing for Automatic Document Adjustment (!) Please note, this is not a bug, but the way you are going to update your PO conditions is triggering a completely new pricing, that cannot consider such customizing.
This SAP Help site explains each Price Determination Types a bit detailed (MEI1 can use A, B, C or D from these).
REMARK: read SAP KBA 2998137 regarding details on manual conditions. In nutshell: do not apply manual conditions where ADA usage is relevant - Manual Selection of Worklist (Documents) to be processed: this option makes sense only for exceptional cases or mainly during tests. Productive usage for mass update do not assume manual selection. Normally can left unchecked.
- Delete worklist after processing: You can restrict the selection of worklist entries by specifying a validity interval for the conditions on which the worklist entries are based. During processing, the system takes into account WIND entries for conditions whose validity falls entirely or partially within this validity period.
If you want the system to delete the entire worklist during processing, including change pointers that were NOT taken into account during processing, set the "Delete entire worklist" indicator.
When you set this indicator, note when you restrict the documents at the same time, you may not adjust all the documents that are actually affected by the selected change pointers. An adjustment after deleting the worklist entries is then usually no longer possible. See later section: Lost Worklist entries (WIND)
Using MEI1 regularly without this indicator (or the next one) might also result to longer runtime. Yes, partially due to growing number of Worklist entries, but also because corresponding POs are attempted to be updated again and again based on the same old change - since the changes seem to be still unprocessed! Of course, PO condition changes will not occur, if they are already updated, but you can imagine doing this re-adjustment in mass again and again will lead runtime increase by all means. - Delete entire worklist: See previous option! Difference: the previous option considers the Condition interval restriction from the selection screen of MEI1, if there is any. In case no restriction entered, both will delete all worklist entries, regardless of PO restriction! See later section: Lost Worklist entries (WIND)
- Create change messages for purchasing documents: By setting this flag, change documents will be written into CDHDR and CDPOS table whenever a PO is getting updated. This might also trigger Message output in PO, as per settings.
- Direct Database Changes per Purchasing Document (Synchronous Update): Setting this flag will influence only whether the process will wait until each single PO is saved, or just starting the update tasks to save them and the process is allowed to continue running in the meanwhile (to start other PO updates for example).
- Price Determination Type: Although the field seems to be non-editable (grayed-out), you can choose here among few price determination types (see F1 help for details). They correspond mainly to the options available in ME22N when Updating conditions for an item.
Performance issue in MEI1
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.
Deletion of outdated WIND entries
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:
- By MEI1: apply the checkbox "Delete worklist after processing" --> see details on impacts in above section of my blog: "Understanding the options in MEI1"
- By MEI5: Simple report to delete WIND entries explicitly as per few selection criteria
- By report RWVKP03D: I would call this as an enhanced version of MEI5. The aim is the same but provides a bit more option to have control over which WIND entries can be deleted. Most of the selection screen elements are self-explanatory, I would detail here only two of them:
- Check against doc.indexes (table S111): by having this flagged, only those WIND entries will be deleted, which have no matching entry in S111. This does not mean at all, that all the rest of the WIND entries are still necessary, but rather gives a safety net.
- Delete selected change pointers from the database: this could be considered as TEST flag. Without having this flag set the report will collect all the data and show it in the log, but no entry will be deleted from WIND actually. Thus, can be used to measure from how many WIND entries can we get rid of with current selection criteria.
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.
Lost Worklist entries (WIND)
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?
- First and foremost, by standard a new WIND entry will be created automatically when a new change is saved on the same condition. So, the "inconsistency" is not permanent, but the "pointer" to current changes might get lost. (See following points!)
- Doing a dummy change (and save) on the price value and changing back immediately to the desired one is an option also, which is going to generate WIND (or change pointers first in BDCP2, which can be converted into WIND later), but in unlucky situation the temporary dummy price might be picked by someone, if you are not fast enough...
- If you haven't activated the Direct worklist entry creation, you still might have a chance to re-create the lost WIND entries. Namely, when using MEI4 - although the processed BDCP2 change pointers will be marked for reorganization (BDCP2-PROCESS) - you can use them for worklist creation until these BDCP2 entries are not deleted physically from the DB table. You only have to set the flag "Process change pointers flagged for reorganization"
- Last but not least there is always a workaround to update the POs manually by starting ME22N and using the Update button on Conditions tab. This might require low or high effort depending on the volume, but the situation is not hopeless.
Most complained: PO XXXXXXXXXX was not adjusted by MEI1
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:
- Follow-on documents exist for the Purchase Order. As corresponding SAP help documentation [3] also highlights, updating the conditions with ADA is expected only (and shouldn't occur otherwise) as long as no invoices have been received or labels printed. If a goods receipt has been posted, the movement data is corrected during Invoice Verification! This is also the case for conditions requiring subsequent settlement. So please, always check the PO History first.
- Customizing related root cause. Incomplete condition maintenance for ADA (see [2]) or using references (see corresponding section), etc.
- Missing WIND entry, which is not re-created anymore in normal process flow, if corresponding BDCP2 entries have the PROCESS flag set already (see corresponding section)
- Missing S111 entry: This does not necessarily mean, that no S111 can be found at all for the desired PO (MEI3 run could help then if customizing is OK), but most of the time the specific entry for the desired condition table (S111-KOTABNR) or the key (depending on access sequence) stored in S111-VARKEY does not match with the WIND-VAKEY.
To find out the reason for mismatching VARKEY and VAKEY of these two tables is unique each time, so I cannot provide you a guide on how to resolve it, but usually points to pricing related customizing issues. - Any inconsistency between A* condition table, KONH, KONP etc.
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:
- Won't do any adjustment in the system, only analyzing data.
- Checking customizing and providing the user with details in the log, where possible.
- Providing details on PO/item level whether adjustment is expected to occur by an MEI1 run and if not, why.
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!
Further useful resources
- SAP KBA 3233063: MEI1 FAQ
- SAP note 2267742 & 2215169: when doing S/4 conversion
- SAP KBA 3066148: when getting message NI014 (this is covering only one case, but might help)
- SAP KBA 2477327: about adjustment of deleted PO items
- SAP note 3217778: if you observe no WIND entries are created when doing changes in info record
- list might be extended later...
- SAP Managed Tags:
11 Comments
