Skip to Content

Monday Knowledge Snippet (MKS) – 10 One-Time Locations

Maintaining master data can be annoying or even not possible manually. On the other hand many automatic functions are relying on it. One example is entering an order (or receiving it from ERP) having just the customer address. This customer may or may not be already stored in the system. All required information like cost, times and stuff are covered by the Transportation Network or TM specific settings being based on master data. So we faced the challenge bringing this together and enabling a smooth process.

I would like to explain a few important things to know about this function.

1. One-Time Location Creation: Depending on the business requirement, there are basically 2 options for creating one-time locations. The question is do I need to know if this customer defined by an address is already in the system and want to reuse this location? Or do I not care? In the first case, the system needs to search all existing locations using a quite performance expensive address query. In case something matching is found, the master data location is re-used and I can link different orders together. If nothing is found, a new One-Time location is created. Which is also the case if I do not care for the check.

– The setting if the address search is required can be done within the TM customizing under TM->Basic Functions->General Settings->Define General Settings for SAP TM. Check the documentation for details.

– The Location ID is defined by a number range, which can be found under Master Data->Transportation Network->Location->Define Number Range Intervals for One-time Locations.

– For the adjustment of the to-be-created One-Time Location a BAdI exists under BAdIs for Transportation Management->Master Data->General Settings->One-Time Locations. There you can pretty much change anything starting from location type to any other data.

– Geo-Coding runs automatically to determine geo coordinates using the address.

2. One-Time Location Usage: Well, after creating the One-Time Location it is used like any other master data Location. You see it in the order with its ID, it can be changed in the location maintenance and is integrated into the Transportation Network to determine for example distances, planning cost and other information. The network integration is done using Transportation Zones defining certain address areas. The only difference is the set OTL indicator on db level in table /SAPAPO/LOC (field OSTA_FLAG).

3. One-Time Location Deletion: To not mess up the system with obsolete objects, One-Time Locations are deleted after no relevant document any longer points to it. For this function the standard location deletion report can be used checking via the Wher-Used Framework all relevant TM documents.

As this is a very central component, I guess it is good to know how it works. Get back to me in case you want more details.

You must be Logged on to comment or reply to a post.
    • Hello Marcus, I don't understand why I created a delivery in ECC with a destination location, but in SAP TM, that delivery has another destination location that does not exist in SAP ECC. What can I do to see the correct destination location in SAP TM. The destination location has previously been sent from ECC via CIF.  Thanks for your help. Regards, Ginny D'Alessio

  • Thank you a lot for good description! Would you be so kind to explain some points:

    1) after one-time location deleted, could we have full analytics in TM about transactions with this location and information about coordinates and address data (such as name, phone, mail etc)?

    2) What if we have created one-time location for customer, then deleted it, then (after some months) created new one-time location again (because of new order), then auto-deleted it. Could we have a report about all transactions with that address somehow?

    • Hi Anton,


      Well, there is no analytics in TM itself. The data is replicated into SAP BI and during this all of your requested data should also be included. Note that as long as there is a tour or any other document referencing the OTL, you can not delete it anyway.

      Same for the second question: The replicated data includes the address, which would be the same for both OTLs. So it should be possible to find all documents matching this.

      Hope this helps.

  • Hi Marcus,

    Could you explain where the address data for one-time location should be entered to run search matching? Is it possible to create one-time location without BAdi implementation?

    Thanks and regards,


    • Hi,

      not sure what you mean by where the address data should be entered. OTL logic is applied automatically when entering this data during order creation (manually or automatically, for example during ERP integration). There is no seperate UI to check this.

      And of course OTL does not require a BAdI implementation.



    • One Time locations are processed using Transportation Zones including them via address fields. Transportation Lanes maintained for those zones are picked up for requests including the OTL.

  • Hi Marcus,

    could debug this, but maybe you are faster 🙂 If I activate the address check in General Settings, is it always carried out when transferring orders from ERP? The background of my question is: ERP orders always have a consignee which has to be maintained as master data. Normally, this master data should have been CIFed and location will be found using the partner ID. Now we have two special cases:

    1) We have special customers for which only a dummy address is maintained in ERP, which are used for one-time consignees.

    2) Sometimes, the address for a regular consignee is changed in the order, so it differs from the one maintained in master data.

    For case 1), we could simply not CIF those customers, so the system would not find a corresponding location and performs address search anyways - everything ok.

    For case 2), if the system would pick the CIFed location corresponding to the consignee ID that would be wrong. Only if an address check is also carried out in this case, TM would recognize that locations do not match and create a one-time location instead, for example.

    Thanks, Michael

      • Hello Marcus

        We just recently upgraded our TM system 9.1 to 9.3 with HANA data base, some times when send DTR to TM, the destination location is picking as OTL even though we have customer CIFed and created. The source is showing correctly but problem is with only destination location.

        We have verified the mappings in PI system and looks all fine. we also activated the address search still having issue.

        Could you please suggest what could be the wrong, will it be any inconsistency due to HANA migration in address search?



        • Unless you are asking for clarification/correction of some part of the Document, please create a new Discussion marked as a Question.  The Comments section of a Blog (or Document) is not the right vehicle for asking questions as the results are not easily searchable.  Once your issue is solved, a Discussion with the solution (and marked with Correct Answer) makes the results visible to others experiencing a similar problem.  If a blog or document is related, put in a link.  Read the Getting Started documents (link at the top right) including the Rules of Engagement. 

          NOTE: Getting the link is easy enough for both the author and Blog.  Simply MouseOver the item, Right Click, and select Copy Shortcut.  Paste it into your Discussion.  You can also click on the url after pasting.  Click on the A to expand the options and select T (on the right) to Auto-Title the url.

          Thanks, Mike (Moderator)

          SAP Technology RIG

  • Dear Colleagues, Considering the act that One Time Locations are being creating "on the fly" during for example a DTR document creation, and assuming the OTL will be part automaticall of an existing "Transportation Zone"; how the DDD (Distance Duration Determination) should be managed in this case. This considering that at the time a new OTL is being creating no DDD redetermination will be ran since it is not tecnically feasible ? This is considering also that the DDD need to be determined for every Locations combination included on the involved Transportation Zone. Thanks Gustavo

    • Hi,

      distance determination happens on location (coordinate) level. If you want to pre-fill the distance buffer, this needs to be triggered either manually or on a regular base using the report /SCMB/DDD_BUFFER_MAINT.


      • Thanks MArkus for your feedback.

        Considering the SAP Hana processing capabilities, it would be helpful whether SAP could evaluate in the future try develop functionality in order "pre-fill" the DDD buffer on the fly every time a new One Time Location is being created.



        • I don't actually see the relation to SAP HANA. The distance determination is done by the external GIS connected and this is typically the bottleneck. In case it would just be a calculation this would happen either automatically or not even buffered dynamically when requiring the distance.

          • Marcus,

            It is clear the situation when the DDD is being calculated by using and external GIS application.

            I tried to refer those situations when no external GIS software is being used and the approach "Straight line DDD" calculation is executed internally on SAP TM abap stack.

            In this case, the power SAP Hana capabilities could be leverage in order try execute the DDD calculation on the fly every time a new on time lication is being created.



          • We don't suggest to buffer the straight line DDD as this calculation is quick enough anyway. When using this, actually nothing needs to be done at all.

  • HI Marcus ,

    First of all thanks for sharing all thing . I as per the forum discussion we are facing an Issue related to  One time customer. There has been all the setting done in SAP TM , the sample orders which is the correct example for the One time customer, when the FO is getting drop to ECC In-from of Idocs it's goes into the Error saying the XXXX Zone doesn't exist for US. Here the Business is changing the Address of the Ship to Party in the Sample Order. Foe example the Order is been dispatched from US to DE ( One time customer ) . Then main Sold to party is having Zone as US , while Ship to party which is  One time Customer , user is changing at order level , before the OTR get created in TM . So when Inbound Idoc comes to ECC with Time Zone as DE the Idoc's is getting failed as XXXX zone doesnot exist for CA country .

    Can you help on this issue


    Yagnesh Acharya

  • Hi Marcus,

    we are facing an issue with OTL was created in TM and same number range is being used when ever the another one time location sent over for the same BP with changing the address in ERP. After creation of FO, the FUs was unassigned from FO  and again available for planning after the shipment created in ERP. We have used external number range for creating the OTL but still it was using same number range with different address sent from ERP to TM for same Consignee. Do you have any advice on this.

  • Hi Marcus,

    Thanks for useful information!

    I have one query related to number range used to create OTL.

    Number range is used to assign location ID to OTL.

    Could we use BADI to make the Location ID more meaningful instead of just numbers?

    i.e. If OTL belongs to Italy, then prefix "IT" with the number.