Product Information
Deviating delivery address in purchase order creates one time location in TM integration
Dear friends of SAP TM,
When you order goods from your supplier, you might have the use case that the delivery address differs from the default address of your plant. May be the recipient is in another building as usual or whatsoever.
The question is then, how TM deals with that deviating address from the purchase order as transportation planning in TM always needs a respective location. But in our case, the actual destination location differs from the location of the plant. The answer are the so-called one time locations. In the following, it’s explained what that means in detail.
At first we need to deal with the basic question, how the destination location is derived when the purchase order is integrated with TM.
And the logic is as follows:
- If a shipping point is maintained for the provided plant and storage location, take the location of this shipping point.
- Otherwise, the location of the plant is taken
But let’s bring now a deviating address into the play:
In this exemplary purchase order, the house number has changed. And as the delivery address now deviates from the regular address of plant and/or shipping point, the above logic is overruled. In that case, we always create a new location with this address during TM integration, the so-called one time location:
This is a ‘regular’ location with location type 1021 (business partner) which is always the default type for one time locations. The only difference to a ‘manually created location’ is one tiny flag in database table /SAPAPO/LOC:
(If you search this flag in transaction /SCMTMS/LOC3…you won’t find it.)
But apart from that, this location can from now on be used for any process within SAP TM or i.e. be maintained with additional data. And so do we use it here when planning the transport for the example above:
You might wonder about this strange name ‘821’. This is because the name is derived from an internal number range. You have the possibility to adjust the name to your needs in a BAdI as explained in this blog post.
As the name implies, many of those one time locations might be used only one single time for a special purpose. Means, it surely makes sense to consider some kind of house-keeping to clean up the location master data regularly. This has to be done manually by setting the deletion flag and running the report /SAPAPO/DELETE_LOCATIONS as the system can never now, whether those locations are actually not used any longer, of course.
Hope this is a piece of useful information for you. I appreciate any comments!
Best regards,
Michael
Is it possible to create in a similar manner one time locations for Sales Orders?
example could be in the building industry we deliver concrete to one time locations and prefer not to create thousands one time ship to parties, but just use delivery address as one time .
Hello Adi,
Yes, of course. This works similarly when integrating SD documents with SAP TM.
Best regards,
Michael
Michael
Thank you for your note.
Could you please amend your blog with Sales Order example?
I am not sure which Sales Order fields to be used to transfer the one time locations to the Transportation Management module?
I assumed this is the Ship to party address, but in my case I have thousands one time drop locations so I assume I should not create these locations as Ship Parties.
So which address fields are integrated to the TM to be used in Sales Order?
TIA
Adi
Hello Adi,
For the sales order, it just works the same. If TM recognizes that the delivery address deviates, the one time location is created. So they don't get transferred. TM creates them during integration and you don't have to consider or provide anything in the sales order.
Best regards,
Michael
Hello Michael,
thanks for sharing.
Actually I have a problem with these one time locations, in my examples a one time location is being created which is fine, but after GI (update from EWM) my Freight Unit will be deleted and and a new FU with a new One time location will be created.
Adress et ceterat stays the same (only number of Adress Number (ADRNUMMER) is different)
What is the logic behind creating a new one time location?
Best regards,
Jens
Hello Jens,
Thanks for your comment!
Without knowing details, the different address number could be the reason. We don't store the address data itself at the location. This is stored in central address table and the reference to this is the address number, being stored then at the location.
So just from that description, I would rather check why the new freight unit is created with a different address number, which can have multiple reasons.
Best regards,
Michael