BAPI_MATERIAL_SAVEDATA. Update JUST the Unit of measure details.

[gary_king2]

I have the BAPI_MATERIAL_SAVEDATA working just fine when a material/Plant is being either created or extended, or at least I thought it was working fine. I now find myself having to update just the UOM data and try as I have I just can't get it to update the materials UOM values. No matter what I do it just says 'No data changed'. Firstly, the headdata structure has all the relavent data, material type, industry sector and material number. There are no views set as I have reduced the update to just the UOM data for now, just to get this to work, but I can't even get this simple update to work. The uom table is populated with data, as is the associated x table, with the two keys , alt_unit and alt_unit_iso set and all the filled in fields in the UOM table have an associated 'X' set in the UOMX table, so both are populated correctly. The data in the UOM table is different to what's in the MARM table for that material, so it should be updated, but isn't..

My code looks like this, but I still get the same message back, which is just infuruiating. Does anyone know what I am doing wrong?. I have tried it supplying the clientdata and seting the basic_view = 'X' in the headdata structure, but again did the same message.

There is a CALL FUNCTION 'BAPI_TRANSACTION_COMMIT' afterwards, which is called as the returntype is 'S' (Success) which it clearly isn't. However, the returnmessages are shown before any commit/rollback.

[Added this later] I have also tried to update a materials UOM value using BAPI_MATERIAL_SAVEDATA via SE37, entering the values manually. Ensuring that all data has been entered and that the denominator for the particular UOM (EA) being used has a different value than that shown in table MARM, so that it should update. Still, the same message is displayed, "No data changed". Arrrrhhhhh

Can anyone save my sanity.

 CALL FUNCTION 'BAPI_MATERIAL_SAVEDATA'
   EXPORTING
     HEADDATA = tab_headdata
     FLAG_ONLINE = ' '
     FLAG_CAD_CALL = ' '
     NO_DEQUEUE = ' '
     NO_ROLLBACK_WORK = ' '
   IMPORTING
     RETURN = tab_return
   TABLES
     UNITSOFMEASURE = lt_uom
     UNITSOFMEASUREX = lt_uomx
     RETURNMESSAGES = lt_returnmess.

[raymond_giuseppi]

Did you try to pass CLIENTDATA field BASE_UOM (with current value)

[gary_king2]

Yes, clientdata has a base unit of measure of 'EA', and that uom measure exists in the UOM's that I am trying to adjust. In fact it's only the UPC_EAN field that has changed against the 'EA' UOM, and the UOMX table has an 'X' against that field as well, so I can't work out why it's refusing to update. In my example I removed the clientdata and clientdatax from the BAPI call, as an experiment, which did not work, but have put it back in now, Still does not work though.

As I have put back the clientdata and clientdatax into the BAPI I have also ensured that the basic_view = 'X' in the headdata structure as well. But no joy still.

[raymond_giuseppi]

Which fields did you fill in UNITSOFMEASURE[X]?

[gary_king2]

Here are the contents of my unit of measure table and related X table. They seem to be completed ok.

When calling the BAPI I can manually edit the clientdata and can see that it does update the MARA table once the COMMIT has executed. If I don't change anything in the clientdata structure then it reports there is nothing to change, even though the UOM data is different to what is in the MARM table for the same material. Even if I edit the UOM table and manually change the data it still does not recognise that any data has changed, unless something in the cleintdata structure has changed. So, it seems to be just ignoring the UOM data, regardless. I have looked at some examples and noticed that whenever the UOM data was updated the example program also set the sales_view in the headdata structure. I have also tried this, but again, the UOM data does not update, it just says 'No changes made' in the returnmessages table.

[JL23]

If the EAN does not exist yet in your system then you have to also add an entry in structure INTERNATIONALARTNOS

[gary_king2]

Thank you Jurgen, that could well be it. I'm processing data actually extracted from our Test system but running the load in our Dev system, so that could well be possible. I will go away and check.

Many thanks

[gary_king2]

Well, as a test, I edited the EAN number, removing it, and adjusted the denominator value (while debugging). So I should no longer have an issue with the EAN. However the update still did not work, with it saying 'No changes made' in the return messages table. So, back to the start again. I'm pretty sure you're right though, where there is an EAN I would have to populate the internationalartnos struct/table. But when I don't have an EAN I would expect it to update the MARM table with the new values, but it's not. It simple believes there are no changes to make.

I confirmed this by executing BAPI_MATERIAL_SAVEDATA, manually via SE37, and entered details, just adding the material into the headdata area, entering a single UOM with values (no EAN though) and then updated the X version of UOM to identify what had been updated, after the ALT_UNIT fields, I simple entered 'X' in all fields. When executing it simple said 'No data changed', even though I had changed the demoniotator value so that it was diiferent to what is currently in the MARM table for that material. So it this does not work via SE37 then how am I supposed to get it working in a program. I'm sure I'm missing something, but having read the FM documentation several times I have no idea what I'm missing.

Much appreciation for your suggestion though.

[JL23]

I would try it again with setting the basic view in HEADDATA

If you just think how you process MM02 then you could never reach the button to get to the alternative units if you have not been in one of the views first.

[gary_king2]

I feel like a fool. I finally resolved the issue.

I have a Enhancement implementation

IF_EX_BADI_MAT_F_SPEC_SEL~FIELD_SELECTION

in place that protects certain fields for certain materials, when processing transaction MM02. This is in place to protect material data when the material is maintained OUTSIDE of SAP. PIM's (Product Information Management) are becoming more popular and we have such a tool to maintain material data which is then imported into SAP. So we have a given range of materials that need to protected from editing using MM02.

It was this code that was interfering with the BAPI_MATERIAL_SAVEDATA against the program that was supposed to be importing the data from the PIM.

Got around this by using a certain batch USER ID and placing an exception in the enhancement code to bypass the logic if this user ID is being used.