Material document duplication is an usual issue faced by many customers when posting goods issues at SAP System. In particular, I faced this case many times.
In a case where you have duplicate material documents you can create and run the report ZZWASTOR of note 424414.
You must first check the effects of the report in a test system or with "test mode = X" if it is in production system.
Usually, the root cause is related to unforeseen events like:
- Inconsistencies caused by hardware defects, user handling and customizing changes
- Closely related time wise (seconds apart) of MM postings in conjuncture w/ ENQUEUE/DEQUEUE settings
- Customer reports without consistent updates on the database (user exits or custom programs)
- Manipulation on the database
- Data quality after migration
- Database update errors
The most common reason for the duplication of material document are lock issues. I mean, for example, the end-user opens a session and tries to post a goods movement, if the system is facing poor performance for the moment, the same end-user (or another one) opens a new session and post the goods movement again and then later the first movement is completed. This lock issue will allow the creation of two goods movements. It happens a lot with several customers. In case, OMJI should be set as exclusive lock to avoid new cases.
By the way, report ZZWASTOR will delete duplicate material documents and follow on documents.
If you are facing similar case, please follow the below steps for resolution:
- run report ZZWASTOR (contained in note 424414) which enables you to reverse one of the material documents. Please note as stated in this note it is best to check this report in a test environment first
- you might possibly get error message 'M7 310' which means that negative stock is not allowed. If so, need to be able to allow neg. stock by changing the setting in transaction OMJ1 to allow negative stocks and set messages 'M7 310' and 'M7 309' as 'no message' in transaction OMCQ
- so, run ZZWASTOR
- change OMJ1 back to not allow negative stocks and set messages 'M7 310' and 'M7 309' back to error message in transaction OMCQ
- if delivery appears in status in process and not complete, run RVDELSTA (note 506510) which will reset the status of the delivery.
Regarding to OMJI, waiting time '10 seconds' is usually set for 'late block' and this is correct. But keep in mind that there are advantages and disadvantages of each option. Using 'late block' duplications can happen again.
EXCLUSIVE BLOCK DURING GOODS MOVEMENTS
When material master data is read for the first time during a goods movement, this indicator specifies that tables MARC (plant data) and MBEW (accounting data) are locked exclusively until the goods movement has been fully posted. Another user cannot maintain the material during this time. The disadvantage is the long period of time for which the lock is set (from the time the material master data is first read when the goods movement is entered through to completion of the update posting).
LATE BLOCK FOR GOODS MOVEMENTS
Specifies that a material:
- is not always blocked exclusively, but only if data is actually to be saved.
- is blocked exclusively as late as possible to keep the lock time to a minimum
The advantage is that several users can enter goods movements at the same time because only one shared lock is set for the material when the movement is entered. The disadvantage is that the material master record is read several times and, in the case of an outward stock movement, that the lock entries of other users on the ATP server also have to be considered. These additional accesses have a negative effect on performance.
The late blocking works on the material level, if the material is being updated, all in relation to that material will be blocked until the posting is complete. The block works for any type of goods movement.
Check the following notes for further information on this topic:
70865 - Material block during goods movements
See additional info of note 322989.
Cause and prerequisites
"Late block" does not mean "No block". It is required for sending exclusive blocks. This is carried out online for a short time and then only when entering the hot phase of the update preparation so that several movements can be entered at the same time. This creates situations where a process requests this block, however the exclusive block is held by another process which is currently in update. In this case, the waiting process tries several times to request the
block by itself. When a certain number of attempts have been made, it then abandons this and generates the error message.
I hope this info could be useful to SCN Community!
Fábio Almeida - MM Support Consultant