Problem posting events with weight information

[Former Member]

Dear all (esp. SAP experts ^^),

I have copied and extended the standard FM sending event message contents to TM to submit quantity values (the fields are available in the standard interface structure but are not filled by default). I also implemented the BAdI on TM side, changing ct_modify-data to post the weights to the respective TOR object EXECUTIONINFORMATION (I am talking about messages for a freight order here, Appobject/EH is a derivation of Z_ODT30_TO). What I would expect is that nodes of type EXECUTIONINFORMATION are added having the fields GRO_WEI_VAL and GRO_WEI_UNI filled (these are the only ones for which I transfer values at the moment).

However, this is not what happens. During testing and debugging, there were a few cases where the node appeared suddenly with the values filled, but don't ask me how that happened... The transfer of the values works fine, if I induce a dump by putting ASSERT 0 = 1 in the BAdI, I can see the values populated. What fails is the actual modification of the BOPF object afterwards. Interestingly, if I omit the weight value when sending the event message (and still using the same custom coding), everything works well - respective EXECUTIONINFORMATION node is created/updated.

Obviously, the BOPF performs some logic here if the GRO_WEI_VAL field is populated which prevents saving of the node. But as you might know, it is not very funny to debug the whole srv_mgr->modify method... 🙂 Do you know what happens here and how this was thought of at SAP (if thought of at all? ^^)

This might be connected to the "Discrepancy" functionality, which is (to my understanding) just the posting of an event called REPORT_QUANTITY which is possible by some UI fields in the TOR item view... Maybe the quantity fields in EXECUTIONINFORMATION structure should only be used for this purpose and the corresponding logic prevents the things I am trying to do.

[Former Member · Accepted solution]

Hi Michael,

here are my comments to some of your points:

1) Since some weeks there is a note available, which brings the fix regarding the missing taking over of the quantities: 2168242. So if you implement the note, your enhancement should not be required anymore

2) However, regarding the BAdI /scmtms/tor_event_proc: In which work mode did you use it? I would normally recommend 'M' (Modify standard results), in which first the standard coding is executed and afterwards you can do additional stuff like changing the values of the EXECUTIONINFORMATION node that will be created/updated. Inside the BAdI method PROCESS_EVENT you then should change the LT_MODIFY data, in which you will find the current EXECUTIONINFORMATION node data. All the BOPF handling will then again be done in the standard.

3) You are right that the discrepancy functionality is partially based on 'REPORT_QUANTITY' events. But if other event codes are used, this will have no impact - even if the quantity fields are populated. For any other events than 'REPORT_QUANTITY' there will be no automatic impact when the quantity fields are populated in an EXECUTIONINFORMATION node.

I hope that helps! If not, let us know.

Best regards, Daniel

[Former Member · Accepted solution]

Hi Daniel,

thanks for the note which I implemented immediately. But the newly introduced coding is basically the same I used in the BAdI (using change mode "M" exactly like you mentioned). Therefore, the problem still persists. This is my test scenario:

I have an event called "Z_WEIGH_EMPTY" which is an expected event for a TOR EH and is reported from the EM Web UI. You can pass three values: Location, gross weight, and gross weight unit. If I take a "virgin" freight order, this is what happens:

1) I report the event with all the fields filled. This is persisted in EM but not propagated to TM (TM just reads the information from EM).

2) I report the event again leaving the weight and unit field empty (leaving only the value field empty also works). The event is propagated properly to TM.

3) I report the event again with a different location and the weight fields empty. The event is propagated to TM correctly (though the field EXT_LOC_UUID is not reset/redetermined which results in a hard to interpret UI display (but this is rather cosmetic):

4) I report the event again with a different location and the weight fields filled. Nothing happens in TM.

As I already mentioned, the TM function module is called in each of the cases and the values are carried over correctly (checked by inducing a dump). So I guess that there must be something in the srvmgr->modify routine saying "If you give me quantity values, I won't process you" 🙂

Maybe I will give it a try if I have time and use the BAdI to generate an additional REPORT_QUANTITY event (i.e. discrepancy) in case quantities are reported and see what happens then.

[Former Member · Accepted solution]

Hi Michael,

which UOM you are using?

Best regards, Daniel

[Former Member · Accepted solution]

For testing, I always specified kg. Configured field for the parameter looks like this:

[Former Member · Accepted solution]

Hi MIchael,

I guess that is the isse: You have to use 'KG' with uppercase letters, otherwise the check for the dimension in SAP TM is not successfull, which raises an exception -> this then prevents the successfull processing of the new EXECUTIONINFORMATION node. This check is done with FM 'DIMENSION_GET_FOR_UNIT' - so you can always check if your UOM will raise this exception or not.

Please try it with 'KG' and let us know if it worked.

Best regards, Daniel

[Former Member · Accepted solution]

Ouch. It's always annoying to realize that such "basic" things are the reason for unnecessary days of frustration and meaningless debugging... But at least it works now 🙂 Thank you very much for your support!!!