How to model TL and LTL rates based on zip codes

[otmrookie]

Hi all,

We have TL rates from our DC's to pool centers and LTL rates from the pool centers to final destinations. Our TL rates based on destination (pool center) zip codes or state code by the mile, our LTL rates are based on destination(customer) zip codes as well. My question is how should we model the rates? After reading the online help, it looks like SIMULATION rate service type and ESTIMATE rate distance should work for us but I want a second opinion, any idea/suggestion? Thanks!

[AlejandroBarba]

Re: How to model TL and LTL rates based on zip codes

Hi OTMRookie,

About your question for the rate service; it all depends on how sensitive your requirements are for the transit times. If simulated travel times work well for you for both shipment types and do not impact your business, I would go down that path but if you need a higher level of accuracy I would use a lookup approach for each lane and type.

In simulation you can have OTM calculate the transit time based on the distance and an average speed per distance range and in my experience, it works very well with TL shipments especially when you have multi-stop shipments.

But it might not work as well for Intermodal and LTL shipments, since the location of the terminals and the service areas, and service type are other factors in the transit time and it changes depending on the carrier. To solve this we uploaded the transit time for every lane for most of our LTL carriers. But this has a cost; it is a time consuming task, it is hard to collect this information from the carriers and it needs some degree of maintenance.

About the distance, it also depends on your level of accuracy required. When you use estimated distances, OTM uses the latitude and longitude of the locations to calculate the distance and of course, the estimated distance is not going to be accurate.

Since your TL rates have a per mile basis it is very likely that you may need to use an external rating engine that matches the one used by your carriers in their ratings.

Hope this is useful,

Alejandro B.

[otmrookie]

Re: How to model TL and LTL rates based on zip codes

Thanks again Alejandro for your previous response. We have a question as to how to structure the LTL rates which are based on zip code ranges and weight breaks. I know we can attach Weight Breaks Definition at the Rate Offering level but how do we model the rates that have multiple zip code ranges for each weight break. Any suggestion? Thanks!

[AlejandroBarba]

Re: How to model TL and LTL rates based on zip codes

Hi OTMrookie,

In OTM there is usually more than one way to achieve something but the way that I have done this in the past is (at a high level):

1. For every origin, check which Zip Codes share the same weight break rates
2. Create Regions for all the Zip Codes that were identified in the previous step as sharing the same weight break
3. Create rate records from that particular origin to each region created in step 2 and using the weight break rates that they share

If you have any more questions, please let me know.

Good luck,

Alejandro B.

[otmrookie]

Re: How to model TL and LTL rates based on zip codes

Thanks again Alejandro for your help! Some of our TL rates are flat rate to the entire state, does that mean we must define the entire zip code range in the region? Or can we simply use the Destination Geo Hierarchy of Province/State i.e. AZ, CA, NY in the rate records? By the way, do you foresee any problem using the USZIP3 over the USZIP5 in the region definition? Thanks!

[AlejandroBarba]

Re: How to model TL and LTL rates based on zip codes

Hi OTMRookie,

You are correct, if the flat rate applies to the whole state you can define the rate for the same state.

In the same way if the USZIP3 covers all the USZIP5 definitions, it is better to use the more general definitions that having to go through all the hazzle of defining all the potential USZIP5 if there is no actual need to. Besides, every year new USZIP5 are created and that could cause you a maintenance issue.

Hope this helps,

Alejandro B.