SAP TM is capable of determining a distance between 2 locations with straight-line accuracy in standard considering curvature of the earth and some adjustment factors per means of transport. In addition, it is possible to connect to an external GIS to receive for example real-street distances. All of this is based on location coordinates, which are determined out of the address. So whenever two locations share for whatever reason the same coordinates, they will be handled like a single location during distance determination to reduce the number of external calls and entries in the distance buffer table. From my point of view the advantage is really a lean standard distance determination, but the downside is the disconnect of the distance determination from the location address.
Example: You maintain your locations having just a high level ZIP code (lets say 3 digit), but use a special location code to identify the locations. Your connected GIS is capable of using these and can give you the distance back with high accuracy. Unfortunately if you follow the standard GIS integration described in note 1685381, you notice that you receive the aggregated locations on coordinate level without location address and codes. Even if you manage to retrieve this by location ID, call the external GIS, it is hard to pass the info back into the engine (as you still have the same coordinates for the request).
So basically I see two options to solve this: The preferred option would be to improve the location coordinates. I mean you have anyway an external GIS connected working with certain location address fields / codes, and in reality these location do not share the same coordinates. Why don't you reflect that in the TM master data? So whenever a location is created, use the attribute that distinguishs two locations so they end up with different coordinates. This results in different distance determinations and enables you to work on the fields you would like.
The second option is to use the enhancement spot /SCMB/ES_DDD. It offers the method DETERMINE_DISTANCE_DURATION and is called for each request (before the coordinate aggregation). You might also require note 1769180. Before it was only possible to adjust the standard data format and not the data for the optimization run.
I prefer the first option as it improves the master data quality in general (making for example a fallback calculation possible in case you receive no result from the external GIS), can use the standard TM distance buffering and reduces the effort required in non-standard coding.
