Invalid COMMIT WORK in an update function module.

[Former Member]

Hi,Experts,

Currently We got a problem for posting PO's GR with t-code MIGO. Our requirement is that can create Delivery by automaitcly after PO's GR is saving. Then I have tailored a program for creating delivery.The program will be triggered in an output type when saving action is done.

Error info is as below

"Calling a COMMIT WORK in an update process is not allowed

because the function modules triggered in a Logical Unit

of Work cannot then be processed correctly."

Any help will be appreciated

Thanks in advance

Richard Zhou

[Former Member]

Dear friend,

"Never call COMMIT WORK in an update task"

eg:if you are calling a function module in update task..then never should you call "Commit Work" in the code...it will fail and you will get an update terminate message or short dump...

The purpose of doing code in an update task is that it should occur only if all conditions are satisfied..if you call "commit Work" there the whole idea is wasted..

Please remove the "Commit Work" statement and retest the process again..it should work now

Pls check and revert

Reward if helpful

Regards

Byju

[Former Member]

Hi,Expert

I called the FM named 'SHP_VL10_DELIVERY_CREATE_PARA' for creating delivery. It includes many

standard system programs.

But you know,The big problem is how can i remove this statement "commit work" from these progroms.

It confused me for a long time. Any solution can resolve it?

Thanks & Best Regards

Light Zhou

[Former Member]

Hi,

SHP_VL10_DELIVERY_CREATE_PARA is a remote function module not carried in update task...so it will not give an update failure if you are calling it as if you are calling in a function module normally

to check this -> go to SE37 -> SHP_VL10_DELIVERY_CREATE_PARA -> display -> click on Attributes tab -> here if the update task is selected only the scenario i have posted earlier applies...

Please check again......somewhere you have used an update task function module probably a custom function module in update task and wrote a "COMMIT WORK"

One option is to search "COMMIT WORK" in all the code by using the "Search" given..its a long shot but its worth a try...

if an error message is coming like a

MESSAGE " " TYPE E..... then it may be a different case..if you know the T-code where u get the error...best idea is to find the error message number by double clicking on the error and search for the message in all programs....Usuall y update failure comes as a message in your inbox

Please check,revert and reward if helpful

Regards

Byju

[chaouki_akir]

Hello,

i think i understand what you want to do but not how do you proceed.

What you want to do :

- create GR for PO by using the transaction MIGO,

- then create delivery.

How do you proceed for that purpose :

- In your 1st post, you are talking about a program. How this program is triggered ? In MIGO a user exit ?

- In your 2d post, you are saying that the deliveries are created by a function module. Where is it called ? In an standard abap program ?

I am currently creating a report that have to do the same thing. This report is a BATCH program. After selecting some PO (linked to a SD document), it will :

- create GR by calling a standard BAPI (BAPI_GOODSMVT_CREATE or BAPI_GOODSMVT_CREATE_OIL),

- create the delivery by a call transaction VL01N.

Cordialement,

Chaouki.

[Former Member]

Hi,All

I follow these steps as below

1.T-code: M706

Create an output type to bind the program i have tailored.It inclueded FM I mentioned before.

2.T-code: MM22

Activated the output type

3.T-code: MIGO

To create PO's GR, Meatime,Trigged the program by automaticly for creating Delivery .

By the way, The program testing is OK in SE38 mode.Just attached to output type,It don't work.

Thanks & Regards

Richard Zhou

[Former Member]

Hi,Expert,

Thanks for your reply. I know maybe it should not go this way.

Any other solutions can implement the requirement, As you know,My requirement is that can generate delivery by automaticly when PO's GR(T-code:Migo) was completed.

Just like BADI? I found a BADI "MB_DOCUMENT_BADI",Which it can create delivery against Material Document.But I have not try it before. therefore, I don't know if it be worth to do.

Could you please gime me some advices or sample code if possible?

Many thanks!!!

Best Regards

Richard Zhou

[Former Member]

Hi Richard,

First create an implementation for the BADI in se19,

then in any of the methods put break point and run MIGO

You can clearly see in the debugger what all values come

Please note that u have 2 methods

one works in update task and another as normal function module..to view the documentation of the BADI->go to se18 -> enter the name of the BADI -> Display -> click on documentation to View the purpose and use of the BADI you have mentioned,Please note that all BADIs may not have documentations.............

Also if u feel that the replies are helping you out please reward points....this way the SDN members will be willing to do a bit more homework for you and help you out...

To proceed with the BADI

Please check the documentation below

Business add-ins when creating a material document

The enhancement MB_DOCUMENT_BADI has two methods that are called up by the same interface, though at different times. All material document data from the following tables is transferred to this business add-in:

MKPF (material document header)

MSEG (material document items)

VM07M (update data)

This data can be used in other programs, but cannot be changed.

The methods differ according to the time at which they are called up:

The method MB_DOCUMENT_BEFORE_UPDATE is called up before the FI document is created. This means that it is called up even if the program is terminated by an error during the subsequent processing. The update of data in separate tables should always be contained in function modules that are called up with the addition 'in update task'. This ensures that all the data is updated consistently.

The method MB_DOCUMENT_UPDATE is not carried out until update. This means that all updates are carried out immediately in their own tables and do not have to be contained in 'update task' in function modules. For performance reasons, you should not re-read the tables or carry out any time-consuming routines at this point.

You should always call up MB_DOCUMENT_BEFORE_UPDATE before MB_DOCUMENT_UPDATE, particularly if time is a critical factor when posting the material documents. The method MB_DOCUMENT_UPDATE is processed after the FI document numbers are called. As a result, no other FI documents can be posted until this document is completely updated.

Even if the two methods are in the same class, you cannot access the same global fields, as the methods are called up at different times and are therefore carried out in another roll area.

From the business add-in display, you can go to coding examples for both methods by choosing Goto -> Example coding -> Display

Note

The enhancement does not transfer any data to the material document, that is, you cannot change material document data before it is updated.

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:

COMMIT WORK

Remote function call (CALL FUNCTION ... DESTINATION)

Own updates in document tables or stock tables (for example, update in tables MBEW, MARD, MSEG)

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.

The business add-ins are not suitable for customer-specific updates in the stock tables, as updates like these destroy the standard stock update.

Unlocking the data (for example, via DEQUEUE_ALL) is also critical, as the data that is to be updated is no longer protected from updates from external systems, and inconsistencies can result from parallel updates.

Before you activate an enhancement, check carefully that the business add-in does not contain any critical coding places.

If data inconsistencies have already occurred in your system as a result of the business add-in, remove the critical coding so that it does not cause any further inconsistencies.

Regards

Byju

[Former Member]

Dear Byju,

Thanks for your more detail explaination. I will try it first.You are really a nice guy.

Thanks a lot.

Best Regards

Richard Zhou