2021.1

This section contains the following for the latest version:

  • System requirements

  • Enhancements (new or updated features)

  • Resolved issues (application improvements)

Before upgrading your production environment, Trimble Transportation recommends that you read the system requirements and install the latest version in a test environment. If you have questions, please contact your Trimble customer representative.

Requirements

Before you begin installing LTL Operations Module version 2020.4, check that these requirements are met:

  • TMWSuite®

    You must be using TMWSuite V.2018.18_01.0192 or later.

  • Microsoft® .NET Framework

    NET Framework 4.6.2 or later (full package not client)

    The framework must be installed on the LTL Operations Module server, client, and administrator systems before you install LTL Operations Module. If it is not present, the system displays an advisory message during the installation. Install the framework before running the application.

  • Internet Information Services (IIS) for Microsoft® Windows Server®

    IIS Microsoft Windows Server 2008 R2 or later

  • Microsoft® SQL Server®

    Microsoft SQL Server 2012 or later

    Note: SQL Server 2014, SQL Server 2016, SQL Server 2017, and SQL Server 2019 are supported. Trimble Transportation recommends using the latest service pack of whichever version you use.

  • You must be logged into the system where you want to install LTL Operations Module, and have administrator rights for that system.

    Like most applications, LTL Operations Module can be installed locally on a user’s system. It is also possible to install LTL Operations Module on a network drive. To do so, you must be logged into the system where the drive is physically located, and have administrator rights for that system.

  • SQL Server System Administrator rights are necessary.

    The installation of LTL Operations Module includes the manual application of a SQL script to the TMWSuite database. You must have a SQL Server administrator login and password to apply it.

Enhancements

Appian DirectRoute integration

Route Response has new dwell rate fields (NSUITE-210676)

Send to Appian: The Route Response window now shows new dwell rate fields, when you set up a company to use a Dwell rate. You create a dwell record by specifying the Dwell ID in the Terminal Companies window and the Rate in the LTL Setup window’s Dwell grid.

The system uses these fields to calculate the dwell time at a stop. For example, if the rate is 100 pounds an hour and you deliver 50 pounds at a stop, the dwell time is 30 minutes.

  • Weight Rate
    Pounds per hour

  • Volume Rate
    Cubes per hour

  • Pieces Rate
    Boxes or pallets per hour

If you use a Tiered Flat rate basis, the rate shows in the existing Unload Time field in the grid.

When you make changes to any of the dwell rates and click Accept Routes, the system opens a pop-up message. It asks, "Save changes to dwell data?" Selecting Yes, saves the dwell data to the LTL Setup window’s Dwell grid.

Adding new fields to view company name and frequency information (NSUITE-210677)

You can now add the RevType 3 and Frequency fields to the Route Response grid. Expand the route row to the stops level to view the fields. You access the fields in the Field Chooser.

  • RevType 3
    Company name

  • Frequency
    The number of times a company is scheduled to be stopped at in a week

Adding new fields to view total route time information (NSUITE-210679)

You can now add the new DispatchLoc and TotalRouteTime fields to the Route Response grid. They allow you to view a route’s start location and total route time calculation. These fields are read-only. You access them in the Field Chooser.

  • DispatchLoc
    Start location

  • TotalRouteTime
    Calculation for the last stop’s departure time minus the first stop’s arrival time (Gate-to-Gate time)

LTLBaseGrid drag and drop auto scrolling (NSUITE-210841)

When using Send to Appian for multiple manifests, you may need to use a scroll bar to view all stops. Now, the drag action in the LTLAppianRouteResponseControl.gRoutes grid follows the movement of your pointer. This provides an added visual tool when you want to rearrange rows within the grid.

Currently by default, this functionality is not available for other grids. The reason is that many grids rely on the drag action to move rows between grids.

Accept Routes new progress bar shows processing status (NSUITE-210948)

Send to Appian: Now, when you click Accept Routes, a Progress pop-up window opens.

image1

Its progress bar updates you on the status of the routing process. The window’s messaging provides information on routing activities, such as:

  • Removing order (number) from Manifest (number)

  • Removing stop (number) from Manifest (number)

  • Assigning Order (number) to Manifest: (number)

  • Resequencing Manifest (number)

  • Resequencing Manifest (number). Updating stop appointment (number).

  • Updating details for Manifest (number)

Route Response: New Buttons for auto-adjusting Earliest and Latest Dates (NSUITE-210962)

New buttons in the Route Response window allow you to adjust earliest and latest field value dates. They include:

  • Fix Dates
    Sets the earliest date values to the Arrive Time
    Sets the latest date values to the Depart Time

  • Clear Dates
    Set all earliest date values to the LTLGlobal.Genesis.Date (01/01/1950)
    Set all latest date values to the LTLGlobal.Apocalypse.Date (12/31/2049)

Dispatch

Driver changing tractors between loads caused an assignment error (NSUITE-210755)

Logging out of a shift shuts down a driver’s shift for that day. When this occurred, you had to reopen the shift manually to assign the driver to another load in the same day.

Now, you can use the LTLShiftAutomaticReopen General Info Table setting to determine whether to reopen a driver’s shift automatically. When you assign a driver to a new load for the same day, the shift is open and available for assignment.

FleetConneX integration

Stop sequencing: Process an arrival stop before a prior departure stop (NSUITE-210779)

LTL Operations did not allow a driver to depart one stop and arrive at the next stop in the same minute. The timing issue could happen when stores were next door to each other. The issue was related to the way FleetConneX handled transaction sequencing. Now, for example, the system can process an arrival transaction (Stop 3) before the departure transaction (Stop 2). It does not issue an exception error.

Integration requires the ability to arrive at a stop prior to previous stop departure (NSUITE-210837)

LTL Operations did not allow a driver to depart one stop and arrive at the next stop in the same minute. The timing issue could happen when stores were next door to each other. The issue was related to the way FleetConneX handled transaction sequencing. Now, for example, the system can process a departure transaction (Stop 3) before an arrival transaction (Stop 3). It does not issue an exception error.

Miscellaneous

Trip’s leg start date (NSUITE-210785)

  • Leg start date: Pre Trip Time
    The Terminal Deliveries' Trips grid did not factor in the Pre Trip Time correctly when calculating a leg’s start date. This issue also occurred in the Route Response grid when using Send to Appian.

    The system now sets the leg’s start time to the Planned Depart Time minus the Pre Trip Time. For example, if a route has a depart time of 22:30 with a 30-minute pre-trip, the leg start time should show:

    • The stop arrival as 22:00

    • The planned depart time as 22:30

  • Leg start date: Driver shift validation
    LTL Dispatch limits a driver’s shift duration to a maximum of 24 hours. This limitation can cause issues with a leg that spans several days. When assigning a driver to a leg, the system validates whether a leg’s start and end times fall within a driver’s shift. If the times occur outside the driver’s shift, it issues a confirmation message asking you to do one of the following:

    • Change the leg’s start or end time to fall within the shift

    • Abort the assignment

    Now, you can use the LTLDriverShiftValidateLegEnd General Info Table setting to determine whether the system verifies that:

    • A leg’s start and end times fall within the driver’s shift

    • Just a leg’s start time falls within the driver’s shift (default)
      Validation does not consider the leg’s end time.

The UpdateLTLStop API updates the evt_hubmiles column for a stop (NSUITE-210927)

When the system calls the UpdateLTLStop API during the trip status update, it sends the odometer value to the API by way of the existing LTLStop model. This allows the API to update the evt_hubmiles column on the primary event for the stop with the value, evt_sequence = 1.

Master Schedule History table change (NSUITE-210958)

The Terminal Route History SQL table now shows Add, Update, and Delete activity type changes for master schedules.

MobileComm integration

Checksum change causes a dispatch issue (NSUITE-210757)

When a stop’s Scheduled Arrival Early or Scheduled Arrival Latest date was modified, the MobileComm solution sent the update to the driver’s handheld unit as a re-dispatch. Typically, a driver does not need this information. The change was made by the integration between TruETA and LTL Operations, not a dispatcher.

Now, you can use the LTLShiftCheckSumStopApmts General Info Table setting to determine whether a change to a stop’s scheduled appointment time should cause a re-dispatch on MobileComm.

No Load Assignment Message (NSUITE-210805)

When completing a manifest for a trip, the system sends a second planned trip to the driver. Now, when a second trip does not exist, the system sends a message indicating that there is no load assignment. You can view the LTL text messages in the Terminal Mobile Messages window.

SystemsLink integration

Asset data missing for the driver message (NSUITE-210879)

Previously, you were unable to send a message to a driver because the data collection process did not include required asset information. For example, if it omitted a Truck ID, you could not send a text message. The process now includes collecting this required data:

  • A Driver ID

  • A Tractor ID

  • Driver shift login and logout values
    You will not be able to send a message to a driver until the driver logs into a shift.

Message communication between SystemsLink and DispatchBroker (NSUITE-210913)

A new method in the MobileMessages code file improves the message communication between SystemsLink and DispatchBroker.

Terminal Profile

Using the Routes Only view in the Terminal Profile (NSUITE-210713)

The Terminal Profile’s Routes tab now includes the View command in the Routes grid. It shows in the upper left corner of the Header section. Now you have the option to view routes by the Routes Only or Routes/Schedules radio buttons.

You can toggle between the buttons.

  • Routes Only
    This view shows columns from the SQL terminalroute table only. It is the view available in earlier versions of the application.

  • Routes/Schedules
    This view shows routes based on an actual SQL Server view that combines and displays columns from both the terminalroute and terminaltripschedule tables.

    In this view, you can:

    • View and edit fields from both tables in the same grid

    • Use the Group By Box to group routes based on Schedule Groupings

Now, you can use the LTLDefaultTerminalRoutesView General Info Table setting in your TTS50 to determine which route view to open by default.

Tools

Viewing Dwell field information (NSUITE-210629)

In previous versions, the Dwell tab’s Section Criteria grid listed all of its 28 column names in one row. You had to scroll far to the right of the grid to view all of the column names and field values.

Now, you can view all of a row’s data at once in a window. You open the window by clicking the row’s image2 Expand icon. The window groups the fields in these sections:

  • ID/Type

  • Basis – Tiered Flat

  • Basis – Rate Per UOM

Resolved Issues

Appian DirectRoute integration

  • NSUITE-210747
    Import Route Book: When importing a route that had a stop in a time zone that was different from the terminal time zone, the system did not recalculate the stop’s ETADay and ETATime values correctly. The recalculation showed the wrong day with the correct time.

    This issue caused a serious problem with stop sequencing. For example, on a West to East route:

    • The original arrival date was Monday 11:30 PM Pacific (23:00)

    • After the time zone calculation to Mountain (+1 hour), the arrival date should have shown Tuesday 12:30 AM Mountain (00:30)

    • The calculation showed Monday 12:30 AM - the wrong day with the correct time

    The arrival ETADay and ETATime values show in the company Hours of Operation Overrides table and the Terminal Companies Hours tab grids.

  • NSUITE-210787
    When a route was Sent to Appian and accepted, the times in the Deliveries tab’s Stops grid did not include the routed times.

  • NSUITE-210794
    Send to Appian: A problem occurred with companies that had Operational Hours set as only one, 24-hour period. This information appears on the Operational Hours tab in the company profile. The Route Response grid showed the Open and Close field values as 00:00. The values should show Open 00:00 and Close 23:59.

  • NSUITE-210811
    Send to Appian: The system did not recalculate a stop’s Unload Time when an order’s quantities changed. The Route Response grid showed the unload times from the original stop values.

  • NSUITE-210825
    Send to Appian: When accepting routes, field values in the Trips and Stops grids were not updated to match those in the Appian data. The fields affected include:

    • Stops grid

      • Arrive Time

      • Cumulative Work Time

      • Depart Time

      • Distance

      • Drive Time

      • Service Time

      • Unload Time

      • Work Time

    • Trips grid

      • Miles

      • Work Time

  • NSUITE-210880
    Send to Appian: When accepting routes, the Open and Close times in the Terminal Routes window were not accurate. They did not match the Start Time and End Time values in the Company Hours of Operation Overrides grid.

  • NSUITE-210882
    Import Route Book: When importing a Route Book, the Drive Time field value did not show the correct times.

  • NSUITE-210895
    Send to Appian: When you removed an order from a manifest, you could not move it to another manifest before the LTL Dispatch Background Service slotted it back onto the original manifest. This caused a database concurrency violation.

  • NSUITE-210896
    The Route Response grid allows you to enter HH:MM values in fields, such as, Truck Early Start and Truck Late Start. When you modified an HH:MM value for one manifest, the value changed temporarily. When you modified an HH:MM value in a second manifest, the first manifest’s HH:MM value changed back to its original value.

  • NSUITE-210905
    Send to Appian: When you clicked Accept Routes in the Route Response Dialog, the validation process did not account for arrival and departure, time zone changes.

  • NSUITE-210906
    Import Route Book: The system could not use a schedule with multiple stops at the same hotel location (Diversion stop or DIV event) to generate a manifest with the same number of stops. Instead, it generated the manifest with one stop only at that location.

  • NSUITE-210907
    Send to Appian: The drag behavior for duplicate hotel stops in the Route Response grid did not function properly. When you tried dragging the stops, they did not fall into position correctly.

  • NSUITE-210921
    Import Route Book: When importing a Route Book, the system adjusts a stop’s ETA to account for Time Zone differences between the Terminal and the stops. When the adjustment pushed an ETA outside of the Company Profile’s Operational Hours, the system logged an error and did not import the stop.

  • NSUITE-210946
    Send to Appian: When dragging stops in the Route Response window, the system did not respond properly.

    • When modify a stop with multiple orders, the system updated only one of the orders. It split the modified stop into two or more stops.

    • When dragging a stop with multiple orders, the system moved only one of the orders.

    • When the system split a stop into two stops, you could only drag one stop and not move or edit the other stop.

  • NSUITE-210947
    Send to Appian: When dragging stops in the Route Response grids, the system did not respond properly. This happened when:

    • There were multiple DIV (Diversion) events at the same company

    • You modified a company’s Hours of Operation information in these fields:

      • Open

      • Close

      • Pattern

  • NSUITE-210949
    Send to Appian: When you sent multiple manifests to Appian at the same time, the Original Arrive and Original Depart values in the Route Response grids were incorrect. They all had the same value as the last manifest to be processed. This issue only had an effect on Accept Routes when you used the Keep Times check box option.

  • NSUITE-211075
    Send to Appian: The system did not sequence the stops correctly in the Manifest Stops grid. This happened when you clicked Accept Routes to process a manifest with duplicate hotel stops.

  • NSUITE-211130
    Send to Appian: The auto slot flag was not disabled for manifested orders. When working in the Route Response window, this issue caused concurrency problems with the slotting procedure.

Appointments

  • NSUITE-210728
    When processing an appointment with multiple orders that are scheduled outside of a company’s Hours of Operation, the system opens a pop-up window. It prompts you to accept or reject charges due to the hours exception. Typically, the system opens the window once for the appointment. Instead, it opened the window for each order on the appointment.

    This happened when:

    1. You booked an appointment with five orders.

    2. You booked the appointment outside of the company’s Hours of Operation.

    3. You clicked Yes in the Appointment tab’s Confirm pop-up window.

    4. The system required you to acknowledge charges by clicking OK or Cancel for each order.

  • NSUITE-210763
    The system requires that you enter reason codes for each delivery appointment that is scheduled later than the order’s Delivery Service date. An issue occurred that changed the requirement to enter these codes on the initial late delivery appointment.

    When saving the appointment, you were not required to enter reason codes based on parameters set up in the Bill To profile. Reason code fields show in the Stop Appointments window. They include:

    • The Appointment tab’s Reason Code field

    • The Change Reason tab’s Reason field

  • NSUITE-210939
    When saving an appointment, the system issued an error message.

    This happened when:

    1. You created a new order.

    2. You tried to book the initial appointment for the order.

    3. The system auto-populated the Initial Appt default reason code.

    4. The system set the appointment time to a value earlier than required.

    5. You saved the appointment.
      At this time, the system issued an error message stating, "Reason Code Change required!"
      It should require a reason code only if the appointment time is later than the Mn.Serv/Req date.

  • NSUITE-210983, NSUITE-211074
    When you booked a late appointment, you could save the appointment without entering a company-specific Reason code in the Appointment Dialog’s Bill To Change Reason tab. The error message that existed previously did not open. This happened for initial delivery appointments only.

FreightOrder Import

  • NSUITE-210938
    A change to the LTL Background Service allowed it to slot orders one time only. The service did not account for slotting failures. After one attempt to slot an order, the service set the order’s slotting status to Auto Slotting order_services. This prohibited the service from slotting the order again to achieve a successful result. Now, the service sets the Auto Slotting order_services flag to False only after an order slots successfully.

  • NSUITE-210945
    When updating a slotted LTL order from a Freight Order, the LTL Dispatch Background Service reset the Auto slotting flag to True. The system should not reset the flag for slotted orders.

    The Service Selected check box in the Order window’s Special Handling tab identifies the Auto slotting True and False values.

    • True
      Selected check box

    • False
      Cleared check box

Manifest

  • NSUITE-210618
    The system set a manifest’s final stop event to End Empty instead of End Bobtail. This happened when:

    • A delivery manifest was set up with a spot loaded trailer stop.

    • The stop was a consolidation with more than one order.

    • One order was removed from the stop while the balance of orders remained.

    • The first trailer was assigned.

    The stop should have shown the End Bobtail status since the trailer was to be dropped at the Spot Loaded location.

  • NSUITE-210626
    The Event Description values and the stop sequence were incorrect in the Manifest window’s Stops grid.

    This occurred when you:

    1. Created a rail manifest

    2. Assigned a container

    3. Set the manifest to a Loaded to Go status

    4. Assigned a reservation

    5. Assigned a chassis

    As a result:

    • The chassis assignment, which should have shown for the first leg only, showed for the subsequent legs.

    • The system prevented you from dispatching the manifest.

  • NSUITE-210771
    The system did not populate the Stops grid’s stp_activitystart_dt and stp_activityend_dt field values. This occurred when you created a manifest from a master schedule with preset stops.

  • NSUITE-210775
    The system factored in break time when calculating a stop’s dwell and departure times. The departure time should not include the break time. For example, if a stop’s arrival time is 10:00 AM, the unloading time is 20 minutes, and the break time is 30 minutes, the departure time should show 10:20 AM.

  • NSUITE-210780
    The Drive Time, Work Time, and Cumulative Work Time fields in the Stops grid showed incorrect values. This occurred when you completed these steps:

    1. Created a new trip from a schedule

    2. Created a new On Dock Order for Stop 3 or greater on the manifest

    3. Assigned this order to the manifest

    4. Edited the order, added a freight detail, and then saved the order

  • NSUITE-210796
    The Add and Remove commands in the Third Party tab were disabled. The issue affected the tab in these windows:

    • Manifest

    • Manifest Editor

    • Terminal Crossdock

  • NSUITE-210847
    The Terminal Deliveries Customer Pickup Date and Customer Delivery Date in the Manifest Stops grid did not update correctly. This happened when a trip’s status was Loaded To Go.

Miscellaneous

  • NSUITE-210270
    The LTL Billing and Billing Consolidation Queues experienced performance issues. For example, the queues would time out. This happened only when you loaded data into the queues.

  • NSUITE-210852
    The system did not calculate stop dates accurately when a westward route crossed time zones like Mountain to Pacific. This happened when the ETA for the current stop was earlier than the departure date for the previous stop.

  • NSUITE-210877 The TerminalEquipment.view.sql script returned multiple rows for tractors. This happened when two records existed in the asset_ltl_info table for a tractor. As a result, the ltl_manifeststops procedure returned multiple rows in the join. This caused the work time and cumulative work time values to be overstated. The work time values show in the Manifest Trips grid. The cumulative work time values show in the Manifest Stops grid. These grids show in the Terminal Pickups and Deliveries windows.

  • NSUITE-210993
    For LTLRuleSets, there were performance issues with the checks to verify if any rules existed for an object. The process validates dozens of different DAL objects. When a database had no ruleset for an ObjectName/RuleSetType combination, the same SQL executed repeatedly.

  • NSUITE-211057
    When you selected multiple invoices in the Invoice Queue and clicked Process Imaging, the system did not check whether a G-Invoice required a master bill number. This caused errors later in the process when a master bill number was required but not provided. When you tried to process these invoices, the system generated an error message. As a result, in error, the system set the Invoice Status for each invoice to Printed.

MobileComm integration

  • NSUITE-210304
    The system did not process multiple manifest assignments correctly.

    This happened when:

    • Multiple manifests were assigned to a driver’s shift and the stops were sent to the driver’s handheld device.

    • The driver completed the first stop or manifest and then logged out of the shift.

    • The driver logged back into the shift.

Order Entry

  • NSUITE-210610
    By default, you could not modify the Split Number, Group By Box in the Split Order pop-up window. This prevented you from changing the contents of each split. Therefore, you were unable to split orders.

  • NSUITE-211080
    An order’s DRP (Delivery) events were set to None when you inserted a stop SUL (Schedule Unload) event manually.

    This happened when you:

    • Created a Drop at Dock order

    • Created a new empty manifest (not from a schedule)

    • Manually added a stop SUL event and delivery company to the order

    • Assigned the order to a new manifest

    • Assigned a driver, tractor, and trailer to the order

    • Clicked Mass Status Change to set the order’s status to Loaded to Go

Schedules

  • NSUITE-210881
    When you generated a trip from a schedule, the work time and drive time field values in the Manifest Trips grid were incorrect. They did not match closely to the values in the Terminal Schedule Legs grid that generates the manifest.

Terminal Deliveries

  • NSUITE-210941
    When creating trips from a schedule, the ETA field values in the Manifest Stops tab showed the time in hours and minutes but not seconds. This can cause issues when generating a manifest from a schedule with stops at the same physical location.

Terminal Pickups

  • NSUITE-210944
    The Terminal Pickups window experienced poor performance. It called the LTL_pickups stored procedure, which at times, caused the window to time out and go blank. You were not able to work in the window.

    Modifications to the stored procedure allow it to move data to a temporary table earlier in the query. It then joins to that table later in the query. This improves the memory grant and the number of reads the procedure has to complete to return the same data.

Terminal Profile

  • NSUITE-210680
    You were unable to edit the Company ID field value for a scheduled stop. The field shows in the Routes tab in the Terminal Profile window.

TransX integration

  • NSUITE-210608
    The system sent an EDI 214 record with the wrong custom status code for a pickup order. It used a delivery status code instead of a pickup status code. This happened when:

    • LUL (Live Unload) and LLD (Live Load) events occurred at the same stop

    • Both orders were included on the same appointment

  • NSUITE-210640
    The Route grid’s Map window in the Terminal Pickups and Deliveries windows did not function properly. This happened when it tried to show a company location that did not have latitude and longitude values populated in the company profile.

    When mapping the location of a spotted trailer (trailer that was left at a company) the window often used the terminal location on the map instead of the actual company location.

  • NSUITE-210764
    The EDI 214 button in the Order window’s Routing tab did not work properly. The button’s purpose is to re-process EDI 214 transactions for a stop.

  • NSUITE-210765
    When an HPL (Hook PreLoad) event had a late arrival, the EDI 214 did not route to the Hold Queue. You could not enter a reason code. The system sent the 214 outbound without a late reason code.

  • NSUITE-210767
    The TransX process to transfer a credit memo with tax details from LTL Operations to Great Plains failed.

  • NSUITE-210924

    • Appointment reason code
      When a delivery appointment arrives late, the system prompts you to provide a late reason code. This process did not work as expected. For example, the system required a late reason code when an appointment was not late.

    • Shipper earliest date
      When a shipper company was assigned to an LTL order, the shipper’s Pickup earliest date was incorrect. It matched the Pickup latest date. The earliest and latest date values should match the Open (earliest) and Close (latest) times from a Company Profile’s Operational Hours. In this case, the Pickup earliest date did not match the Open date.