Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
Showing results for 
Search instead for 
Did you mean: 

Duplicate delivery numbers

Former Member
0 Kudos

Hi All,

We have an idoc interface that creates a delivery document. We are noticing some severe inconsistencies in the idoc processing wherein 2 idocs create a delivery each, but both deliveries are assigned the same delivery document number.

I am trying to search for an SAP note which will help us with the problem, but I'm not able to find much help. Has anyone come across this problem or any note that describes this scenario?

We notice this when there are 2 idocs processed one after the other, and the first one is huge in size (like 400 line items) and the second one is pretty small (2 to 4 lines). We noticed this because we have a duplicate check logic (using ext. del. no) to error out a duplicate idoc message. But when 2 huge idocs (2nd one duplicate), are processed one after the other, the first idoc creates a delivery and commits it, but when the second idoc checks the database, the data is still not in the table.

This is in a standard interface with some customization in user exits. The std. interface performs only a PGI on the delivery. Prior to the PGI, in a user exit, we create the delivery document and update the idoc with the delivery number.

There is also a commit work statement in our userexit (which was supposedly required as the PGI failed to find the delivery in the db otherwise) which we suspected as the culprit for causing inconsistencies. But we are not able to find much evidence for that.

Any pointers will be much appreciated. Thanks in advance.





Former Member
0 Kudos


Use COMMIT WORK AND WAIT statement.This ensures that Control returns to your program after all high priority (V1) function modules have run successfully.

Please let me know if this helps you out.


Karun M

Active Contributor
0 Kudos

Hi Salai!

As far as I understand your description, you create a delivery in a user exit and make a commit work.

This corrupts clearly the <a href="">transaction logic</a>. SAP has <a href="">SAP-LUWs</a>, which you cut in two by your user-exit. A rollback by SAP standard will leave half booked documents, which is extremly unpleasant in case of a split between logistics and financial bookings.

Besides this you just struggle with a little bit slower update task, so the booking last document (delivery?) isn't ready when you try to check during creation of next document.

Neither commit or commit work will help, as long as the two IDOCs are processed in different sessions, but even with serial booking in one session not all update tasks (V2) need to be ready before next step (after commit work and wait) is executed.

Maybe in addition to your DB-check you can use export / import from memory. This should be immediately available, so no booking has to be waited for. Of course this can only check for the very last creations, so you can't skip the DB-check. Make sure you use the right memory; in case of parallel booking you need to use shared memory (on application server level).



P.S.: SAP's opionion (in BADI help) about commit work in a user-exit:

" If this business add-in is not set up properly, it may result in an

inconsistency between the documents and the stocks and between the

material documents and the accounting documents. Inconsistencies like

these may be caused by the following elements in the business add-in:


o Remote function call (CALL FUNCTION ... DESTINATION)

o Own updates in document tables or stock tables (for example, update

in tables MBEW, MARD, MSEG)

o The unlocking of data (for example, via DEQUEUE_ALL)

Before the two business add-ins are called up, data is already flagged

for the UPDATE. If a COMMIT WORK or a Remote Function Call is

transmitted in the enhancement, these are written in the database. If

another error occurs after the business add-ins are processed, you

cannot carry out a complete ROLL BACK, as the data up to the COMMIT or

Remote Function Call has already been written in the database. This can

result in an inconsistent status (for example, material document without

accounting document), which can only be repaired with considerable cost and effort"