2007 Mar 26 2:24 PM
Hi,
We are trying to update material data (tables MARA, MARC, MVKE, MPOP) with function module BAPI_MATERIAL_MAINTAINDATA_RT in a retail environment. When we have many material deviations, the update of only one field (for example RAUBE, storage conditions) of one generic material (with 7 variants), goes in time-out. Note that we recently upgraded to patch level SAPKH47026.
Does anyone know any other function with which it is possible to respectively update these tables (especially MARA and MVKE) that could perform better?
Many thanks in advance,
John De Coninck.
Message was edited by:
John De Coninck
2007 Mar 27 7:40 AM
Hi John!
The BAPI should be faster than the BDC or transaction (because of missing screen handling). Okay, generic materials aren't fast anyway.
The BAPI will spend some time checking the reference values. You can make this part a little faster by adding all reference levels (header materials with the used logistic views) yourself for the call.
Manual maintainence or BDC only seems to be faster, because booking is done asynchron in background (for minutes - just check the lock on the material).
You can also call the BAPI starting a background task -> no time outs any longer (but of course not faster).
Regards,
Christian
2007 Mar 26 3:18 PM
Hi,
Write a BDC for TCODE MM02. I think that will reduce time compare to BAPI if u have only 1 material to change at a time.
DARSHAN.
2007 Mar 26 3:29 PM
Thank you Darshan.
Batch input indeed reduces time for 1 material at a time, but the customer would like to opt for it as a last resort, since is it still too slow.
Kind regards,
John.
2007 Mar 27 7:40 AM
Hi John!
The BAPI should be faster than the BDC or transaction (because of missing screen handling). Okay, generic materials aren't fast anyway.
The BAPI will spend some time checking the reference values. You can make this part a little faster by adding all reference levels (header materials with the used logistic views) yourself for the call.
Manual maintainence or BDC only seems to be faster, because booking is done asynchron in background (for minutes - just check the lock on the material).
You can also call the BAPI starting a background task -> no time outs any longer (but of course not faster).
Regards,
Christian
2007 Mar 28 2:57 PM
Dear Christian,
Thanks a lot for your helpful answer.
It seems our main problem of performance lies in the fact that we have too many deviations on the articles (sometimes more than 2000 per article). The table MABW seems not to be cleaned when a variant gets the same value as its father material. We're searching now for ways to clean this table. By any chance, do you know any?
Thanks and kind regards,
John.
2007 Mar 28 4:14 PM
Hi John!
I know this situation from an other customer. It's a hell lot of work, I myself was not luckily not involved in the clean up.
As far as I remember: there is no technical (mass) way to do this. It's either deactivation of the reference handling or re-change of the deviations to the source values of the reference.
Have a look at note 161875 for a report to display the differences. If you do not want to have copy logic for some fields, check note 142897. Then MABW would be deleted.
Otherwise the field content has to be set to the same value of the reference level again - which is quite a work to do.
If you are only interested in an update of logistic data, use FM MATERIAL_UPDATE_LOGISTIC_DATA (note 381942) - this should be faster.
Regards,
Christian