MM17 versus BAPI_MATERIAL_SAVEDATA

[Former Member]

We have a problem with a structure that we added to table MARC. The structure includes two fields, defined in the MRP view, which we occasionally update using MM17, and some other fields. If all the fields are defined in table T130F, MM17 overwrites the other fields with garbage, even though they are defined in a different view. However, if we delete the other fields from T130F, we can no longer update them using BAPI_MATERIAL_SAVEDATA - which we also want to do.

Can anyone suggest a solution?

[Former Member]

We have a problem with a structure that we added to table MARC. The structure includes two fields, defined in the MRP view, which we occasionally update using MM17, and some other fields. If all the fields are defined in table T130F, MM17 overwrites the other fields with garbage, even though they are defined in a different view. However, if we delete the other fields from T130F, we can no longer update them using BAPI_MATERIAL_SAVEDATA - which we also want to do.

Can anyone suggest a solution?

[Former Member]

Hi Edith,

Maybe you can go to SM30 and go to the view MASSFLDLST.

There you can maintain the fields used in the MASS transaction.

MM17 is just a call of the MASS transaction with the BUS1001 Object.

Greetings Fred

[Former Member]

Hi Fred,

>

> Maybe you can go to SM30 and go to the view

> MASSFLDLST.

No. Only the two fields that we want to update appear there.

Maybe I can narrow down the problem: the catalog items that need the extra fields do not have the MRP view, where the first two fields of the structure - the ones that we update via MM17 - are needed. But if we run MM17 to insert default values in all the records where those fields are blank, it pushes irrelevant junk into two other fields instead.

Do you have any other ideas?