BAPI_GOODSMVT_CREATE behaving differently in development and quality

[Former Member]

My program is behaving correctly in development system -

1. The program is run

2. Changes are made to material in MM02 transaction

3. In the program, a button is executed where I am calling a BAPI_GOODSMVT_CREATE, which returns values correctly, as per the material status (be it error or success)

-

---

In the Quality system it behaves incorrectly-

1. The program in run

2. Changes are made to material in MM02 transaction

3. In the program when the button is executed the BAPI_GOODSMVT_CREATE, seems to retain the earlier status. Recent changes to material are not reflected in the return parameter, no matter how many times I try.

4. When I restart the program, the BAPI_GOODSMVT_CREATE shows up the correct return values of the changes made in step 2.

-

---

Steps taken -

1. I have compared the versions of the code in both the systems and they are identical.

2. To be sure I once again transported the changes to the quality system, yet the problem remains.

3. I tried with a different data thinking it to be a problem with the data rather than the code, but the problem remains

Edited by: GhoshA on Mar 8, 2012 8:06 AM

[dev_parbutteea]

hi,

did you commit your changes after BAPI_GOODSMVT_CREATE ?

Dev.

[Former Member]

Hi Ghosh,

Just to get more clarity, after you make changes to MM02 do you call BAPI_GOODSMVT_CREATE in a separate program or is the BAPI called from within MM02 ?

Regards

[Former Member]

Hello Ravi,

The BAPI is being called in my custom program.

I am making the changes to the material in MM02 and subsequently, testing my code.

Please let me know if it clarifies your query.

[Former Member]

Hi Ghosh,

I am just guessing here. But just check.

I think that in your development system the updates are happening immediately and when you run your program with BAPI, the updated values in MM02 is correctly picked.

For some reason there must be a delay in updates in quality system. After doing changes in MM02 check in transaction SM13 to see if any update requests are pending. If update requests are pending from MM02, the updates still has not happened.

Wait for the update to complete and then execute your program and see if the BAPI picks up the updated value

Regards

[Former Member]

1. I executed my program.

2. I looked for 'All' requests in SM13 under my user id.

3. Made changes to material in MM02

4. Refreshed the SM13 list

5. Executed 'Repeat Update'.

6. Switched back to my program, executed the button. The problem persists.

Did I miss any step?

[Former Member]

Hi Ghosh,

In step 5 you said "Executed 'Repeat Update'". So some entry related to MM02 is present in SM13 ? In that case don't press "Repeat update"

Let us know what status it shows. Also refresh till no update records are present. Then you run your program.

Regards

[Former Member]

So some entry related to MM02 is present in SM13 ?

In the quality system in SM13 -

Update module ID Module name (function) Type Update return code

1 MCB_STATISTICS_UPD_V2 V2 Processed

2 MCEX_UPDATE_03 Collective run Initial

3 AC_DOCUMENT_MM_UPDATE V2 Processed

4 LIEFERUNG_WRITE_DOCUMENT V2 Processed

5 SLIM_CNT_INCREASE_COUNTER V2 Processed

6 MCF_STATISTICS_UPD_V2 V2 Processed

Double clicking every entry gave - ' Status: Not yet updated'

-

---

Interestingly, in the Quality system, even after continuous refresh, the record does not get removed. However, the records in the Development system for the same situation, get removed, after four or five times refresh.

In Quality even after I restart the transaction, the records do not get removed from SM13, but again the code works correctly for the newly executed instance.

-

---

What is your opinion ?

[eduardo_hinojosa]

Hi

Check how you update your LIS tables in both systems. Check with tcode SM50 how type of work process UP2 works.

Regards

Eduardo

[Former Member]

Thanks for responding.

Yes, I have added logic for COMMIT / ROLLBACK according as the return parameter is a success or a error. In this case however, the problem seems to be during the call to the BAPI (not after), as the program seems to be using the earlier material status, during the processing of the BAPI.

[eduardo_hinojosa]

Hi

Run traces with ST05 in both systems. Maybe the performance is different. Check also the data for material and for customizing settings (tcode OMJJ for movements, OBYC for accounting settings, OB52, see also if there buffering for number ranges (FI and MM),..)

I hope this helps you

Regards

Eduardo