From UG

Current revision as of 14:33, 13 September 2011

[edit] Intro

This wiki contains description of all TMS/Portal integration problems, including the TMS tariff problems.

Started: march 2011.

see also weekly update attached to mantis http://ct.jaguarfreight.com/mantis/view.php?id=2363

ETA: = Estimated resolution date

Related wiki: TMS tariff problems 2011

[edit] TM/CT2 Problems

[edit] Unsolved HIGH priority

[edit] Unsolved MED priority

[edit] Fed-Ex Small Package does not handle/accommodate for EDI msgs (ETA: Earliest, now Aug release)

Descr:

Small Package carriers do not transfer their tracking #'s through the TMS. FEDEX is NOT willing to pay for transmission of data. As well, both Stacy & I have continued to reach out to them with NO answers received whatsoever!!!

Solution and Notes:

Suggestions made by Arden's Fed-Ex rep mark Johnson is to contact 800GoFedex directly and ask them about automation to see how this can be handled. I never got anywhere with Fed-Ex and all has been done manually and will continue until this can resolved.

Marc made a suggestion to add a new field for this tracking # and then have some type of automated tracking in CT to check the Fed-Ex.com site for the status, and then have the system update automatically.

10-May Denise sent a message to edihelp@fedex.com for further assistance, who referred us back to EA's account executive Mark Johnson. Now awaiting his replies to my e-mail below, as well as investigation of CT2 being able to do this automatically. - See mantis: 2957

06-June, going to continue looking into Marc's idea of auto tracking/updates from CT for Fed-Ex.

[edit] Unsolved LOW priority

[edit] Pool point problem (ETA: End of yr 2011, now looks like March 2012 per Descartes on 6/15/11)

TMS has a serious limitation in Pool Point design.

Because of that EADom team using workaround that is cumbersome.

Comments:

Descartes advised this will not be a part of their next release 11.1 which will be sometime this summer and expect earliest to be is their next release 11.2 which is in the later part of this year/early next year. Chad to provide Marc with a better time frame.

6/15/11 Marc made mention again about having CT accommodate the lack of the TMS's PP capabilities, but after I reminded Marc that we worked on this and the ideas were killed, he commented that he'll further discuss with Simon and let us know.

[edit] Tariff problems

• tariffs updated with a delay
• only IT can update tariffs
• discrepancy due mileage calculators
• tariffs are incomplete
• what else?

[edit] Unsolved High

[edit] Albert Farms: Temp solution provided, and is w/in the 5% range

Per John at Albert Farms, their system is set to bill EA for moves ex Madawaska, ME to Roanoke, VA at 1141 miles, while the TM calculates it at 1114. When speaking with John & asking about the mileage calculator used, he confirmed it is PC Miler - but v.15. As well, settings they apply are also the same as TM - Practical & Heavy but have a border option set as closed (being they are on the US Canadian line). As the TM calculates with PC Miler, I asked John to check the mileage via their PC Miler program and he came up with 1138, but again this was using the same settings (Practical, Heavy & closed borders).

Temporary solution - I added the flat rate of $ 1776.50 for the move from Madawaska to Roanoke to the Albert Farms tariff, but it still does not resolve the differences in mileage calculations. Plus Descartes set consolidation settings to "Closed borders" to allow for the mileage calculator to consider not to suggest a route from ME, via CA, back into the US.

  From: Denise Guastella 
  Sent: Wednesday, April 06, 2011 1:14 PM
  To: Denise Guastella; eadom
  Cc: Robert Link; Marc Selter; Alex Dobrovolsky
  Subject: RE: Re: Albert Farm tariff
  All,
  I’m sorry please disregard the below e-mail and note the following:
  I successfully added the rate of $ 1776.50, from Madawaska to Roanoke, to the existing Albert Farm tariff in the TMS.   Please 
  let me know if this rate does not apply to any load you route with them ex Madawaska to Roanoke.
  Thanks,
  Denise

Update Provided after running test in pre-production with setting of disable closed borders checked

 From: Denise Guastella 
 Sent: Tuesday, May 17, 2011 12:45 PM
 To: Robert Link
 Cc: Stacy Weber
 Subject: Re: Albert Farms ex ME to VA
 Importance: High
 
 Rob, Stacy,
 
 Just an FYI with regards to the consolidation settings of – Disable borders, no re-entry and Albert Farms tariff with mileage.  I   
 checked in the pre-prod environment to see what the mileage calculations would be and see that it’s better from original mileage 
 calc  of 911 miles to now get 1114.8; as Albert Farms does not use this # of miles to bill Arden, per John they bill at 1141 miles,  
 I guess the best way to solve the mileage issue and the TMS mileage calc is to continue with this flat rate from Madawaska to 
 Roanoke at $ 1776.50.
 
 I’m sorry but there appears to be no other solution we can offer/think of, unless you might want to get Arden involved to have 
 Albert Farms re-run their mileage calc for this route (with borders closed & practical settings) to see what is the mileage they  
 come up with, but if I remember correctly it was still off though by quite a few miles.
 
 Let me know if you have any questions and/or have any other ideas.
 
 Thanks,
 Denise

[edit] Fuel surcharge (FSC) problems

Descr:

“Allocated shipment costs”/”Load costs” report is incorrect due to FSC problems.

This is because Fuel surcharge (FSC) on Loads calculates incorrectly due to using wrong week on “Fuel price” weekly table.

Because it is a function of “Latest Available Date(LAD)” which is set incorrectly by Portal (to created on date)

Solution and Notes:

Quick fix: 0002797: [EDI to TMS] (Shipment_Import) Change Mapping of the Earliest & Latest Available Date and/or add a delivery appointment to the load before tendering to carrier

Note from Denise:

1. As there are issues with the dates, the TM currently applies the FSC incorrectly for every load, as it is based upon the Earliest & Latest Available dates set by the TM’s logic it is not an accurate way of rating the FSC as not all loads are picked up according the latest available date set by the TM.

Therefore the following workaround was set:

A. Change every shipment records earliest & latest pickup date to the date in which the load will be picked up and this is to ensure proper application of that weeks FSC.

B. As well, Descartes advised to add the delivery appointment date to each load prior to tendering.

[edit] Unsolved Medium

[edit] Express Air: Complex logic of plts vs weight is not supported (and it is too high?)

ETA: ? This is something that needs to be negotiated between Arden/JFS/Express Air

Problem: This tariff compares total cost based on weight and on plts and selects higher amount. Descartes can not accommodate this type of tariff. As a result 2 tariffs should be maintained and operators must switch manually between the two in many cases.

Solution:

option 1) re-negotiation - pndg confirmation as to who will manage these contracts, if JFS, then we'll need to set a standard for rates

option 2) restructure of tariff ratings, request a standard weight rate (?)

[edit] ALL: Some accessorial charges are unknown to JFS at the time of tendering

Examples: p/u and del same day charge; hazardous surcharge (it seems common enough when shipper users create a record in the portal, they do not select Haz Y, so then when the trucker goes in for pickup the shipper provides them with a BOL where it states goods are hazardous); team drivers.

[edit] ALL: Hazmat fees has to be applied manually if shipper does not correctly note this at time of record creation

Descr:

Example: hazmat 35.00 - These charges will automatically apply, as long as the shipper who creates the record notes the shipment as hazardous.

Also Jag operators cannot update Haz Y/N from the CT record and/or portal once an action is set.

Solution & Notes:

• Display the haz box on gen tab

[edit] Unsolved Low

[edit] All: Different types of mileage calculators converters (No solution found)

ETA: Unknown, this is something that EA would need to request of their carriers as Descartes cannot accommodate all different mileage converters.

Descr:

Mileage being off is due to different carriers/ truckers using different types of mileage calculators/converters. This is affecting rates for a few different carriers.

Solution and Notes:

Denise: Mileage calculations are off in the TM as Descartes uses PC Miler WW v23 with upgrading to the latest version 24 within the next month. The reason for mileage being off is due to different carriers/ truckers using different types of mileage calculators/converters. This is affecting rates for a few different carriers – namely Lawrence Transportation, Landstar, Harris & Albert Farms. We’ve asked Descartes about the ability to apply a different mileage converter per trucking company basis, but have no feedback. Yet after further discussion with Descartes about the mileage calc they use, it would appear that there are settings within a carrier’s contract that will take into consideration other settings to be able to get a more accurate mileage count.

Descartes comments re the variations in the mileage calculators: At this time, the options available within TM include:

• PC*Miler Worldwide (a 3rd party engine licensed for use by Jaguar. To my knowledge, all but one of our TM customers use this.)
• Q&D Miler (an option provided by Descartes but it’s only for high-level distance estimates)
• Rand McNalley (another 3rd party engine but Jaguar is not licensed to use this option)

Integrating other distance calculation engines and/or exposing additional settings/parameters within the TM UI for the existing engines may be feasible but I’m not aware of any plans to do so.

6/15/11 Eric with Descartes was in our office and the PC Miler mileage calculator was discussed. Eric is still looking into the costs for EA’s request for licensing of multiple versions of PC Miler, as well as other mileage calculators. He said it’s on the road map and code changes for Descartes to be able to apply on a per carrier/mileage calc basis. BUT he’s unsure if the OLD versions of PC Miler are going to be supported by them as they are up to v 26 and for IE Albert Farms are only using v15.

[edit] Solved Problems

[edit] High Solved

[edit] CT2 Weight discrepancy btwn KGS & LBS (ETA: May 19 release)

Mantis: 2816

Desc:

Solution and Notes:

Denise: Weight discrepancy was mentioned, btwn KGS & LBS and I was able to confirm the following:

a. Record created by shipper in portal as LBS, it is saved in the portal as LBS, upon approval it is recorded in the CT record as LBS, the client role lists the weight in LBS & it is passed to TMS on the shipments line item as LBS, as well as it is recorded in LBS under shipments Total Calculated Weight

b. Record created by shipper in portal as KGS, it is saved in the portal as LBS, upon approval it is recorded in the CT record as KGS, the client role lists the weight in LBS & it is passed to TMS on the shipments line item as KGS, but it is recorded in LBS under the shipments Total Calculated Weight  this is used for rating purposes, but am not 100% sure if it also used for reporting purposes in the TM

There is 1 report that is used for the EA dom project, it is being effected with this weight discrepancy’s and it is the In Transit report. It’s for both the client & int apps, as this report has hard coding for MOT Truck to list weight in KGS, even though it is mostly recorded/entered in LBS, but to confirm all calculations done by the system are correct.

Solution:

Change In transit reports hard coded conditions to give user choice for reports weight.

Mantis: 0002816: (In Transit) Discovered this report has hard coded column for weight in kgs but client needs choice to generate in lbs &/or kgs

[edit] Duplicate Addresses (ETA: 26-May release, Sasha & Ari completed mid June)

Mantis: 2853

Descr:

2 or more addresses in Address book are identical except Company Name. They are duplicates and cause numerous problems.

This is not exclusively TMS problem. This is a general problem. But:

• TMS solution helped create duplicates (famous NPA feature)

• It is a serious problem for TMS because:
  • duplicates "create" Extra “dummy” stop which leads to no updates on one of the CT in such load in CT2 DB
  • when running a report for a location one must select all duplicate items that relate to same address

Solution and Notes:

• a) Eliminate address duplicates in CT2 that already exist (Sasha's idea)
  • Sasha has already resolved this under mantis 2853, as well as provided us with a word document containing full instructions on how to clean up see: (2853)
  • Ari is done cleaning this up all NON archived addresses & will clean up archived addresses upon next release.
• b) Prevent forming duplicates in the future (to be discussed & suggest to keep Sasha's instructions in mind)

Note: Descartes quick fix under Notes From Denise:

1. Due to CT address book issues IE – multiple addresses for the same company – when a user selects 2 or more shipments that have the same street address, yet has a variation in the company name, the TM creates 2 separate delivery stops for the load. When that happens, the TM does not set an estimated delivery time for the 2nd stop and leave that xml attribute blank, therefore these xml files are incomplete/corrupt and CT does not accept the update of pickup trucker, delivery trucker & est. pickup & delivery dates. Descartes feels this is a design bug on their end and will correct it, but in the interim as we clean up our address book, they have mapped the 1st stops estimated delivery date to the 2nd stops estimated delivery date, making their xml files complete & when we receive them, they will continue to update each CT record the same.

[edit] Problems related to Earliest and Latest Pick Up Dates (resolved partial in April release & May 19th release)

Mantis: 2797 & 2949

Descr:

CT2 to TMS mapping is incorrect for these dates, also the way we use these dates is not well thought through.

This leads to several sub-problems:

A] no overlap in pick up windows for shipments in the load so load can’t be created (or is created with problems - "corrupt XML")

B] "Corrupt XML" files were sending multiple e-mails to shipper users every 5 mins (FIXED? good fix?)

• • Descartes copied the first DocLoadStop

C] status messages info is not updating

Solution and Notes:

Workaround#1 (through UI, very time consuming): To set up Appointment on the load before tendering

Quick programming fix: 0002797: [EDI to TMS] (Shipment_Import) (Earliest & Latest Available Date problem) Approved On/Approved On+X days quickfix

Notes from Denise:

1. Earliest & Latest Pickup Date is set in the shipment, which is currently mapped to the created on date &/or the date that the planner put on hold for approval with a 9am to 5pm window. Mantis 2797 was created to allow for CT admin users to set the amount of time between the Earliest & Latest Pickup dates that will pass on our shipment import into the TM. This solution was provided to cut down on current manually workarounds for dates.

2. Corrupt XML files were sending multiple e-mails to shipper users every 5 mins, this was due to users creating a load with 1 shipment, then selecting other shipment records, adding them to this already created load but these shipments have a variation of earliest & latest pickup dates. Then the TM takes all of the dates into consideration, automatically sets the earliest and latest available date for the load and being the dates were so out of range, their system was unable to understand how to handle.

Therefore Descartes provided a workaround for this and for the users to:

a. No longer use the create load option & select to select the consolidate option

b. Set a pickup appointment to the date of when the load will be picked up

c. Use the resequence option, which will have the TM re-order the dates for the TM to suggest a better window for the loads earliest and latest available date

From: Mauricio Ruiz [mailto:mruiz@descartes.com] 
Sent: Thursday, March 10, 2011 4:02 PM
To: Alex Dobrovolsky
Cc: Denise Guastella
Subject: RE: LD 6107

Hi Alex,
The process is the next one:
Tm use the “Latest Available Date” on the shipment or load to see when that date fits into the “Effective Date Start” and “Effective Date End”, once it finds which fuel price is extracted between those dates it goes to the fuel surcharge matrix and see in which bracket the fuel price will fit, once it finds the bracket it extract the “cents per mile” or “percentage” to calculate the FSC.

If for example you have a shipment or a load that has “Latest Available Date” in the future and you don’t have a fuel price that match those dates, then the system will use the most proximate fuel date to calculate the FSC.
Hope this helps, if you need more detail or will like to have a Webex for this please let me know.

Regards,
Mauricio


From: Alex Dobrovolsky [mailto:alex@jaguarfreight.com] 
Sent: Thursday, March 10, 2011 3:50 PM
To: Mauricio Ruiz
Cc: Denise Guastella; Alex Dobrovolsky
Subject: RE: LD 6107

Mauricio,
Could you please explain what logic do you have for pulling “Fuel price” from weekly table.
Denise told me that “Effective Date Start” there gets associated with average of “Latest Pickup” dates.
But could you please be very  specific? What biz rule is?
We are trying to resolve the problem of system pulling the wrong “Fuel price” from weekly table because of incorrect Earliest & Latest Available Date mapping.
Thanks!
Best Regards,
Alex Dobrovolsky
IT Manager

[edit] CT2 to TMS transfer fails sometimes P1 (ETA: 19-May release)

Mantis: 2750, 2835 & 2831

Descr:

Not all approved shipments have Shipment Import file sent to TM.

Reason is still unknown

Solution and Notes:

0002750 Bug: Not all approved shipments have Shipment Import file sent to TM - Solution was added for script to periodically send 
all approved shipments with statuses "yet" or "failed" (in case of connection fail). This was coded, passed QA & UAT  

0002835 Add "fail" status to the list of TMS statuses This was coded, passed QA & UAT

[edit] Express Air request to add SKU # to Descartes Highway Portal (ETA: May 11th)

Descr:

Express Air is using Descartes highway portal as a means for EDI and needs to have the SKU # on every load tender received but Descartes highway portal does not have this currently, it only has PO #.

Solution and Notes:

Chad's requested and hopes to have this added no later than 11.1 release (Summer 2011). Rob f/u with Chad about replacing the PO for the SKU and here are their replies:

From: Mauricio Ruiz [mailto:mruiz@descartes.com] 
Sent: Tuesday, May 10, 2011 3:01 PM
To: Robert Link; Chad Murphy
Cc: Denise Guastella; Stacy Weber
Subject: RE: Express Air "EDI" issue

Hi Robert,

Instead of switching we are going to concatenate both #’s

Something like PO – SKU

So you still have both #’s on the screen, we plan to have this change by the end of the week.

Regards,
Mauricio

[edit] Estimated Pickup Dates & Delivery Dates are in the past (ETA: Descartes: Wed May 18th & JFS: Th May 19 release)

Mantis: 2949

Descr:

Estimated Pickup Dates on Load Plan sent to CT is in the past & the Estimated Delivery Date is the same date as the estimated pickup.

Solution and Notes:

1. Descartes to map the Estimated Pickup Date sent on their xml load plans to the Pickup Appointment Date the operator sets in the TM, as this date is not sent on their load plan. The pickup appointment date is set for EDI carriers purposes to ensure the pickup does not expire in their system. Original date was 12-May but was unsuccessful in making change, new date is Wed 18-May.

2. Appears that Jaguar has a mapping bug for the estimated delivery dates. Incorrect mapping of the 2nd doc load stop start time date and not the 2nd doc load stop end time date.

[edit] For EDI carriers, the Pickup Appointments set by JFS operators are not being sent (ETA: 16-May resolved)

Descr:

YRC advised they do not receive the Pickup Appointment date/time set for the load from the TMS on their load tender requests.

Lawrence advised they do not receive the Pickup Appointment date/time set for the load from the TMS on their load tender requests.

Solution and Notes:

Stacy followed up with Descartes about this (see note below), Mauricio believes he found the issue and is working on the fix for this. He advised that the new map will be in place tomorrow morning, so all the tenders tomorrow morning will reflect the appointment dates, can you confirm with your carriers tomorrow and let me know if you are still having the issue.

From: Stacy Weber 
Sent: Tuesday, May 10, 2011 3:14 PM
To: Mauricio Ruiz
Cc: Denise Guastella; Stacy Weber
Subject: Appointment Dates transferring to Carrier

Good afternoon Mauricio.
I was following up with some of the carriers in regards to their EDI transmissions and if the appointment dates are coming through to them.
YRC and Lawrence have advised that on their EDI transmissions, they do not see an appointment date and the only date that comes through for them is the current day of tender. Express air has advised the same is true in terms of their view for the highway portal. Can you please look into and advise. Thank you. 

Stacy Weber
Operations Executive

Original date was 11-May morning, but was only fixed/implemented on late Friday 13-May and confirmed ok by Stacy Monday 16-May all was good.

[edit] Med Solved

[edit] 001 problem (ETA: April release)

Mantis: 2693

If shipper enters plts and loose qty for 1 CT, TMS creates 2 line items - one for the plt count and one for the loose count. Since we collect only combined weight we put real weight on line with pallets and dummy weight of 0.01 on second line.

So in this case when operator edits the shipment in TM, they system complains about 0.01 number and it must be changed to say .01 or delete the line if irrelevant.

Another related problem is that shippers sometime enter BOTH "pkgs/plts" value and loose field incorrectly due to misunderstanding.

Solution and Notes

April release:

• Pass 3 different types of item lines as follows:
  • If loose, pass only loose & weight total
  • If plts, pass only plts & weight total
  • If both loose & plts, pass as 2 line items containing plts with weight less .01 lb & loose with weight at .01 lb

[edit] Limitation of 50 shipments per load (ETA: Resolved in March by Descartes to truck their msgs at 50 shipment)

Descr:

Descartes has a limit of 50 shipments per load for EDI with truckers.

Solution and Notes:

If this is continues to be be an issue than only suggestion is for each trucker to check with their EDI provider to see if they can accommodate + 50 shipments as this is standard for EDI transmissions to include up to 50.

From: Denise Guastella 
Sent: Monday, March 14, 2011 5:03 PM
To: Stacy Weber
Cc: Alex Dobrovolsky; Robert Link; Marc Selter
Subject: RE: load 6672 - EDI To Lawrence

Importance: High

Hi Stacy, 

I spoke with Chad from Descartes about this and why it happens.  He explained that this happens because EDI messaging has a limitation of 50 shipments for such exchanges.  That Alexis created a way to send such large edi transmission to the carrier but it only contains the first 50 shipment records… so he had to cut out the remaining 10 records from the message.    So since it is only the first 50 shipments worth of information, when Lawrence pickups at the shippers facility, as long as they issue a BOL, that will provide the total # of CT records, pcs & weight for that load.  

To advise, the load plan is not affected by this which means that it will update each of the CT records that were a part of that load with Lawrence as the pickup & delivery trucker, as well as set the estimated pickup & delivery dates. 

Now as a far as receiving status updates from Lawrence as to when they confirm the pickup date and/or delivery date, this is something that Chad has to look further into as he is unsure if we will receive the update for all CT records, meaning based upon the entire load?   Or if it’s only going to be received for the first 50 that were originally sent on their 204 transmission.   
He should advise us further tomorrow and I will confirm to all once more is known/received.

Thank you,
Denise

[edit] YRC needs ALL shippers to add the TMS load # onto their BOL for YRC to update the TMS with their pro # (ETA: 26-May release)

Descr:

Carrier YRC cannot match up their Pro # for every load tender received from TM and they've requested ALL shippers to include this on their paperwork.

see notes from Stacy:

From: Stacy Weber 
Sent: Thursday, May 05, 2011 3:50 PM
To: Marc Selter; Robert Link
Cc: Denise Guastella; Montira Renfrew; Alex Dobrovolsky; Stacy Weber
Subject: RE: YRC EDI Transmission of Pro #'s

Marc, Rob, after speaking with our contact David at YRC, he has informed me that the shippers need to start including the LOAD # 
on their BOL’s in order for YRC to properly update the EDI Transmissions with the pro # and thus have it show up in cybertrax. 
Their default way of doing that now is via po# however this doesn’t work if a po# isn’t listed on the paperwork or in an instance 
where shipments within the same week have different po #’s. The best way to ensure that cybertrax gets updated with the YRC Pro#
is to have the shippers put the Load # on the bol. Perhaps we can have this stated on the email dispatches 
that get sent out automatically from cybertrax?

Stacy Weber
Operations Executive

Solution and Notes:

Add clause to confirmation dispatch e-mail notification to also include the Load # on their BOL.

[edit] Cannot report on Load #, Carrier Pro # (ETA: 07-Jul release)

Mantis: 2806 & 2934 & 2935

Descr:

Elizabeth Arden is requesting the load #, carrier's pro # and total value for each domestic truck record to be on their scheduled in transit report.

Solution and Notes:

1. Add on CT General Tab, for MOT Truck Domestic, 2 new DB fields - Pro Number & Load Number (Mantis 2806). Completed 26-May release

2. Change Mapping of Load & Pro # from Pick-up Comments to New DB Fields (Mantis 2935). Completed 26-May release

3. For Internal In Transit & Main reports, Add Pro Number, Load Number & TTL Shipment Value to list of Output (Mantis 2934)

[edit] Low Solved

[edit] Many outdated shipments are present in TMS / Clean up of old shipments in TMS (EA Dom Team, eta: End of June/Beginning Jul)

Problem

There are many shipments in TMS that are not relevant anymore.

Solution

• Marc suggested to delete all shipments that are older than 3 months - but this will not work as some of these older shipments were just recently approved.

• EA Dom is now working on this by checking each old CT # inside CT2 to confirm that its a delivered shipment and then are canceling it in the TMS. They hope to resolve/cleanup by the end of May, but they might need more time.

[edit] Training and knowledge transfer is somewhat behind (Resolved completely mid/late May 2011)

Problems

IT Support weighing me down.

Stacy involved in day to day operations.

Descartes to assist in setup of pre-prod consolidation engine for us to run/test optimization functionality.

Solutions & Notes

Resolved IT support, I transferred to Tracie Friday, 06-May.

Set up training w/ Descartes for Stacy & I to become more familiar with consolidation functionalities and to set up the pre-prod environment with our rules/specs.

[edit] CTMS (Cybertrax TMS next generation)

Another way of addressing these problems is to make features fond in TMS available in CT2:

• create loads in CT2 and push loads, not shipments to TM (per Stacy 99% of time they make decision about groupping CTs into loads on CT2 side)

• create routing guides / assign trucker on CT2 side

• process pooling on CT2 side

In this case potentially operator would not need to go into TMs side that much if at all. After Load is pushed system would auto tender.

Also even more extreme approach would be to pass loads through EDI avoiding altogether TMS UI.

• create tariffs DB on CT2 side

• provide Web forms to carriers / or EDI