Skip to Content
Author's profile photo Marcus Zahn

Monday Knowledge Snippet (MKS) – 21 Distance buffering performance settings

When using an SAP TM external GIS to determine distances and duration between locations (see here: http://scn.sap.com/community/scm/transportation-management/blog/2012/10/08/monday-knowledge-snippet-mks–01-can-i-use-different-distances-for-planning-and-charge-calculation). it is recommended to use the SAP TM internal buffering by adding the standard buffering methods to your distance determination strategy.

There are 2 interesting settings which can influence the performance of this function in the customizing under SAP Transportation Management -> SCM Basis -> Master Data -> Transportation Lane -> Distance and Duration Determination -> Maintain Global Settings for Buffering of DDD

MKS21_DDD_path.jpg

IMG path to DDD buffer settings

MKS21_DDD_settings.jpg

DDD buffer settings

Direction Irrelevant: With this setting you can tell the system that the distance/duration from Location A to Location B equals the distance/duration from Location B to Location A. This might not always be the case (for example inner city transports can vary), but i guess for most of the TM scenarios it is fine. And it save a lot of external calls, buffer entries and runtime when checking the DDD buffer. Its not set by default, but I would recommend to use it.

Last Access Update: When you set this flag, the system enables the automatic deletion of out-dated buffer entries. For example you have a scenario, where you rely on really accurate data (which might be updated week by week), you can trigger this here. The system will use the buffered entries until they are out-dated. As soon as this happens, it will call the external GIS for an updated value when it is next requested. From my perspective this is really rarely the case and I would rather not set it. I requires a timestamp check each time the buffer is accessed and slows down the distance determination. As said in the beginning, it is in general recommended to keep the buffer up-to-date. So I would go for a weekly (maybe on Sunday) buffer update using the report /SCMB/DDD_BUFFER_MAINT. Here you can determine for example only missing buffer entries, or overwrite existing ones with quite a lot of options.

By the way, there are two other reports of interest in this area:

With report /SCMB/DDD_BUFFER_CLEANUP you can clear the buffer tables or check for inconsistencies. Be very careful when clearing the table: Depending on your scenario it can take quite a whle to fill it again completely.

You can use report /SCMB/DDD_BUFFER_TRANSFER to transfer the distance buffer your one system to the other. The distance buffer is based on coordinates, which are of course not system dependend. To enable a transfer, you need the same DDD strategy in both systems. The report is capable of creating the required speed profile (which matches the buffer entries to means of transports).

Assigned Tags

      2 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Marcus Zahn
      Marcus Zahn
      Blog Post Author
      Author's profile photo Former Member
      Former Member

      Hi Marcus,

      The article is very helpful.  Thank you. Can I ask if there is any report we need to run so that speed profiles get created in the system after doing the required config ?

      Regards

      Sanjeev