Improved location determination in SAP TM for STO enablement in ASR scenario

Dear friends of SAP TM,

In this blog post we will talk about the integration of stock transport orders (STO) with SAP TM with the special focus on the determination of the source and destination locations.

When integrating any document from SD, LE or MM, we always need respective locations for the source and destination of the transport to enable the transport planning of the created freight unit(s). And this information will obviously be derived from the predecessor document in SD, LE or MM.

For the stock transport orders, the logic for the location determination in TM integration until now was as follows:

• Source destination: Take the location of the shipping point from the shipping data of the STO (in table EKPV)
• Destination location: Take the location of the customer as maintained in the STO item. If no customer is provided in the item, take it from the shipping data

Now as our famous Advanced Shipping & Receiving (ASR) came into play, we of course also needed to offer an STO enablement for ASR scenarios. But for that, the location determination for the destination needed to be adapted to enable the ASR functionality in the inbound processing.

Process overview

Let’s explain this be looking at an example of the STO process in ASR:

In detail, the following happens:

• During creation of the STO, a freight unit is created and the freight unit is planned to a freight document
• The outbound delivery is created out of the freight document and thereby the freight unit is reassigned to the outbound delivery. Besides, warehouse processing in the outbound happens
• At next, goods issue is posted at the shipping point, which triggers the creation of the inbound delivery and the freight unit is reassigned to the inbound delivery. Finally, warehouse processing in the inbound happens

But this process can only be enabled for an ASR scenario if the location of the shipping/receiving point is considered as destination of the transport.

See here the comparison of source and destination locations between the default behavior for non-ASR scenarios (why it’s only the default is explained later) and ASR scenarios:

Examples non-ASR & ASR

To show this with examples, we create at first an STO for a non-ASR scenario with its regular location determination:

You see, we transport from a plant in St. Ingbert (and respectively a shipping point which is not ASR relevant) to a customer in Stuttgart.

The created freight unit then looks like this:

So, the destination location is the location of the business partner in Stuttgart.

At next, let’s assume an ASR scenario with an STO for transporting goods from a plant in Berlin to again a plant in Stuttgart:

The plants have respective shipping points assigned, which both are relevant for ASR.

During TM integration, the following freight unit has been created:

You see, that now the respective shipping points have been determined, also for the destination location.

And for the sake of completeness, the final document flow of this STO looks like this:

Further enhancements

Thereby it’s worth to mention that we made another improvement regarding the location determination. If the receiving storage location of a purchase order or purchasing scheduling agreement has an own address, until now we created a one time location. In the context of the ASR inbound process, we now consider also the assigned shipping point as destination location.

The above improvements are now the standard behavior in the context of ASR. As this improvement might also be interesting in non-ASR scenarios, we have added the following customizing setting to the logistics integration profile to enable this also for non-ASR:

The default here is that for non-ASR scenarios, the above functionality is switched off, staying compatible with the behavior until now, but can be switched on easily. It’s just important that existing freight units are not adapted after setting or unsetting this flag so this affects only newly created freight units.

The described functionality is available with SAP S/4HANA 2022 FPS1 and note 3261189.

Thanks for your interest in this topic! I’m happy to discuss your remarks!

Best regards,

Michael