TMS problems 2011

From UG

Revision as of 15:39, 31 March 2011 (edit) Alex (Talk | contribs) ← Older edit		Revision as of 15:40, 31 March 2011 (edit) (undo) Alex (Talk | contribs) (→Unsolved LOW priority) Newer edit →
Line 90:		Line 90:
-	=== Problems related to Earliest and Latest Pick Up Dates ===
-	'''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?)
-
-	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
-
-	<pre>
-
-	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
-
-	</pre>
	==== Fuel surcharge (FSC) problems ====		==== Fuel surcharge (FSC) problems ====

---

Revision as of 15:40, 31 March 2011

Contents 1 Intro 2 Unsolved HIGH priority 2.1 Duplicate Addresses P1 2.2 CT2 to TMS transfer fails sometimes P1 3 Unsolved MED priority 4 Unsolved LOW priority 4.1 Limitation of 50 shipments per load 4.1.1 Fuel surcharge (FSC) problems 4.2 Pool point problem 4.3 Various tariff problems 4.3.1 Different types of mileage calculators converters 4.3.2 Express Air complex logic of plts vs weight is not supported 4.4 001 problem 4.5 Many outdated shipments are present in TMS 4.6 Training and knowledge transfer is far behind 4.7 Problem of constant change 5 Solved Problems 5.1 Weight discrepancy btwn KGS & LBS 6 CTMS (Cybertrax TMS next generation)

Intro

This wiki contains description of all TMS/Portal integration problems.

Started: march 2011.

Unsolved HIGH priority

Duplicate Addresses P1

Descr:

2 or more addresses in Addressbook 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)
• b) Prevent forming duplicates in the future (to be discussed)

Note: Descartes quick fix

Note 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.

CT2 to TMS transfer fails sometimes P1

Descr:

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

Reason is unknown

Solution and Notes:

0002750 Bug: Not all approved shipments have Shipment Import file sent to TM

0002835	new	mihail 	a. Dev 	[EDI TMS ph2] Add "fail" status to the list of TMS statuses

Unsolved MED priority

Unsolved LOW priority

Limitation of 50 shipments per load

Descr:

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

Solution and Notes:

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

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

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

Pool point problem

TMS has a serious limitation in Pool Point design.

Because of that EADom team using workaround that is cumbersome.

Details TBD.

Various tariff problems

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

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

Different types of mileage calculators 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.

Express Air complex logic of plts vs weight is not supported

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:

001 problem

If shipper enters plts and loose qty then TMS creates 2 line items - one for plts count and one for 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.

In this case when operator edits the shipment system complains about 0.01 number and it must be changed to say .01

Another related problem: shipper sometimes enters "pkgs/plts" value in addition into loose field incorrectly due to misunderstanding.

Solutions

Many outdated shipments are present in TMS

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.

Training and knowledge transfer is far behind

Problem

Solution

Problem of constant change

Problem

Solution

Solved Problems

Weight discrepancy btwn KGS & LBS

Descr:

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 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

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