Means-of-transport type issue in SD delivery in case of EWM integration

[meszarosb]

Hi,

We have a 1909 embedded EWM in our S4 system, and it seems that in case of an EWM-integrated outbound scenario, the "Means-of-Transport type" field in the SD Outbound delivery (LIKP-TRATY) is updated with a wrong value from the EWM Transportation Unit.

LIKP-TRATY is supposed to be the "Packaging Material Type" from the EWM Transportation Unit's Packaging Material (in this case TRE), but it is filled with the "Means of Transport Category, coded" field (031), which is the UN/EDIFACT standard code for the means of transport (this case ROAD).

Has anyone else run into this same issue?

"Means of Transport Category, coded" on the EWM outbound delivery:

"Means-of-Transport type" on the SD outbound delivery:

F1 help for LIKP-TRATY:

The correct field that should be used is 'TRE'. Packaging material of the EWM TU:

Packagin material type:

This is also on of the permissible values for LIKP-TRATY. F4 help on SD Delivery:

[JuergenPitz]

Hi,

I think the problem is the other way around...

You are right, the field is the packaging material type (even if the field is called differently on the screen) from the packaging material. But while you define this table in ERP completely by you own, the corresponding table in EWM has this "standard code" meaning and you have to harmonize these. I know the same issue happens when you try it from ERP: you can enter in the delivery a packaging material for transport. This must be connected to a means of transport in EWM. And the system checks if the standard code assigned to this means of transport is the same as the packaging material type assigned to the packaging material, otherwise you get errors (at least what I remember).

Brgds

Juergen

---
Want to learn EWM?
Check for EWM courses @ https://training.sap.com/trainingpath/Applications-Logistics+Execution+%26+Warehouse+Management-SAP+...
Get a SAP Learning Hub Subscription: https://training.sap.com/shop/learninghub

And it is EWM. NOT eWM - Duh!
And if your question includes the word "transfer order" - do NOT tag the question with Extended Warehouse Management!

[meszarosb]

Thank you so much for the answer Jürgen!

I'm afraid I have to disagree though. These two things, the packaging material type and the standard code of the means of transport are two completely different things, I just don't see why the system is mapping the latter into the former, and why they should be harmonized. In EWM, the TU has a packaging material assigned to it (determined by /SCWM/PM_MTR), which has a packaging material type. Why doesn't the system use that in the EWM-ERP integration, how does the standard code come into the picture at all?

Furthermore, in our setup we have a passive means of transport Z001 (w/o capacity), which is the truck itself and corresponds to a vehicle in EWM, and an active means of transport Z002, which is the trailer and corresponds to a TU in EWM. The deliveries are assigned to Z002 obviously, however the system is only using Z001 when filling the Means of Transport type (LIKP-TRATY), Means of Transport ID (LIKP-TRAID) and Means of Transport (LIKP-TRMTYP).

Do you have an opinion on whether this is a correct system behavior this way?

Thanks!

Bálint

[former_member823368]

Hello Juergen

I think the problem here is why EWM return the "standard code" to ERP, in this "packaging material type" field. If EWM return nothing, it's not a problem. However now it is causing confusion.

[JVasconcellos]

uuuuu5uu

Thank you for sharing the SAP answer given to your OSS.

But I agree with lakshmipathi.ganesan about his suggestion. Because in case of TM Integration the Transportation planning type is C - Obligatory external planning in TM.

Thanks

Besta Regards and Hugs.

[Lakshmipathi]

Check whether OSS note 2840377 helps you

[meszarosb]

Thanks for the suggestion, but I don't think it helps, since in case of TM integration the 'Transportation planning type' is C - Obligatory external planning in TM. The issue isn't that the TU doesn't send back some data, the issue is that a particular data is mapped incorrectly

[JVasconcellos]

Balint Meszaros,

Hay?

Did you get solve this problem? Was it opened SAP Incident? If yes, what did they say?

We find the same case here in S/4HANA 2020

thanks. Jony

[meszarosb]

Hi,

We did open an OSS Incident and I will copy the exact answer below. It is pretty crazy to me, but it turns out that this is a know issue with no easy solution. A workaround could be to leave the Standard code for means of transport empty on the EWM side, or to create a packaging material type with the same code as the Standard code for means of transport (eg. 031).

Here is the answer from SAP:

The issue is already known by EWM development, but so far I did not get any resolution from them.

For issues I have found 3 kind of solution:

- In case you change the configuration table /sapapo/trtype to have empty MOTSCODE, EWM will not send the value to ERP

- Some customers have implemented BAdIes either on inbound or outbound message processing side to handle

- Some other customers have created the code on ERP side table TVTY

The issue here is that ERP uses TVTY-TRATY, while EWM uses /SAPAPO/TRTYPE-MOTSCODE. So whenever EWM sends a message with the information, EWM will send the MOTSCODE (Standard Code for Means of Transport), while ERP is expecting the Means of Transport.

As far as I understand this issue persists since the beginning and there is no simple solution. The means of transport on ERP side has a data type CHAR 4, on EWM side (SCMB) the means of transport is CHAR 10. So we shall not send over the Means of transport as this would get truncated during the process.

On the other hand, in case ERP sends the means of transport to us, we try to map it both with /SAPAPO/TRTYPE-TTYPE and MOTSCODE.

So could you check if any of the workarounds would fit you? In case the MOTSCODE is not set in the table, EWM will not send the update to ERP, so whatever was set before will be kept there.