Transflo Mobile+ and TMW Integrations

As a customer already invested in TMW Systems, a market-leading provider of software to transportation and logistics operations, you can also take advantage of the powerful integration between the Transflo Mobile+ app and TMWSuite, one of the industry’s most widely-used transportation management systems (TMS). Carriers that use TMWSuite are able to use a progressive task management format and two-way messaging capabilities from the TMS directly in Transflo Mobile.

In this article, you will learn about the latest Core TMWSuite and TMW Fuel Dispatch integration options.

Prerequisites

The following business and technical requirements must be met by the customer for a successful integration.

Business Prerequisites

Supported TMW Transportation Management Systems: Two options (core and fuel) are supported:

Core: Core TMWSuite integration
Fuel: TMW Fuel Dispatch integration

Driver-based: The TMW integrations for both core and fuel dispatch are driver-based. The load must have a driver assigned for the integration to function. This is a hard business requirement and cannot be changed. If the customer does Truck-based dispatch they would still need to assign a driver.

Totalmail: Totalmail is only supported insofar as we can process messages to and from drivers sent by Totalmail. No other Totalmail functionality is supported. The integrations also support two-way messaging in Command Center.

Full Mobilecomm: This is supported by the TMW integration. In the core integration, the tractorprofile.trc_commethod must be set equal to TFLO for all trucks dispatched in the integration.

Complimentary Accept or Decline (No Load Workflow): A complimentary accept or decline feature (no load workflow) is supported by the TMW integration but has never been implemented for a customer.

Workflow Override: Workflow override is supported but there are nuances to the setup and configuration, and it will often extend implementation timelines. This typically requires developers or Professional Services resources. For fuel integrations, to automatically dispatch loads to your drivers, you must be doing shift-based dispatch. This includes all necessary configuration of shifts, assets, and companies in TMW Fuel Dispatch.

TMW Integration Breadcrumb and Checkcall Process

When discussing Transflo breadcrumbs, it is important to remember the different vocabulary between Transflo, TMW, and Geotab:

Breadcrumbs: GPS records used by Transflo.

LogRecords: GPS records from the ELD used by Geotab.

Checkcalls: GPS records used by TMW.

The TMW core and fuel integrations can use either of the two (2) available processes for breadcrumbs:

Transflo Breadcrumbs: Transflo breadcrumbs are pulled by the mobile app (mobile device location) using the Transflo API.
Geotab Breadcrumbs: Geotab breadcrumbs are pulled by the ELD using the Geotab API. Geotab breadcrumbs can only be used if the customer has purchased a Transflo-approved ELD solution (typically purchased by Full Mobile Comm customers and not complimentary).

The following table summarizes the different processes used by each option:

Transflo Breadcrumbs:	Geotab Breadcrumbs:
Pulled by the Transflo API and pushed into the breadcrumbs table in the Transflo database on the customer side.	LogRecords from the ELD are pulled by the Geotab API and pushed into a staging breadcrumbs table in the Transflo database on the customer side. Another process takes the ELD breadcrumbs from the staging breadcrumbs table and then grabs the following: One LogRecord within a 10-minute grouping per vehicle. This prevents the integration from spamming the check calls table with the huge amount of data we get from Geotab. The closest DutyStatusLog (hours of service operation pulled from the Geotab API in a separate process and pushed into the duty status log table) to the LogRecord date time, to determine which driver is currently associated with the vehicle. The closest inbound load event for the driver

Transflo Breadcrumbs:

Geotab Breadcrumbs:

Pulled by the Transflo API and pushed into the breadcrumbs table in the Transflo database on the customer side.

LogRecords from the ELD are pulled by the Geotab API and pushed into a staging breadcrumbs table in the Transflo database on the customer side.
Another process takes the ELD breadcrumbs from the staging breadcrumbs table and then grabs the following:
1. One LogRecord within a 10-minute grouping per vehicle. This prevents the integration from spamming the check calls table with the huge amount of data we get from Geotab.
2. The closest DutyStatusLog (hours of service operation pulled from the Geotab API in a separate process and pushed into the duty status log table) to the LogRecord date time, to determine which driver is currently associated with the vehicle.
3. The closest inbound load event for the driver

Core Integrations

Supported features and functionality are broken down below based on the TMW Order Lifecycle:

Booking Orders
Assigning Assets to Orders
Dispatch Orders
Actualizing Stops
Completing Orders
Back Office (Not Supported)
1. Rating
2. Billing
3. Settlements

CORE 01: Booking Orders

The integration does not see TMW Fuel orders until they have been assigned to a driver and that driver has logged in for the day.

TMW Retain and Runout Times:

The core integration uses the concatenated values from TMW stops.stp_schdtearlierst stops.stp_schdtlatest of the first pickup stop as the Shipping Date in Transflo.
The core integration uses the concatenated values from TMW stops.stp_schedtearliest for the first Delivery (stop record where stp_type ='DRP') and stops.stp_schedtlatest for the last Delivery (stop record where stp_type ='DRP') as the Delivery Date in Transflo.

Load Details:

Core integrations include the following TMW data as Load Details metadata in Transflo:

Total empty miles
Total loaded miles
Orderheader level reference numbers up to 500 characters
Trailer Notes for the Trailer 1 assigned on the legheader (lgh_primary_trailer) up to 500 characters
Trip Notes up to 500 characters

Stop Details:

Core integrations include the following TMW data as Stop Details metadata in Transflo:

Company Notes for the companies on each stop up to a maximum of 450 characters per stop
Stop Scheduled Earliest and Stop Scheduled Latest window for each stop
Directions (cmp_directions) for the company on each stop
Stop level reference numbers up to 500 characters
Commodity notes for the commodities on the stop

CORE 02: Assigning Assets

Orders should be assigned through the Planning Worksheet or the Trip Folder screen within the TMW Dispatch module.
Dispatchers can un-assign orders from drivers and the Integration will remove the load from the Driver's mobile app.
Dispatchers will need to un-actualize any actualized stops prior to unassigning the load.
- Changing the orderheader status on a load from DSP or STD to any of the following statuses will result in load removal:
  - CAN
  - PLN
  - AVL
  - PND
  - QTE
- Changing a legheader status from DSP or STD to any of the following statuses will result in load removal:
  - CAN
  - AVL
  - PLN

CORE 03: Dispatching Orders

TMW loads can be dispatched by either setting the status of the load to DSP (Dispatched) or by hitting the 'TM Dispatch' button in Planning Worksheet.
Upon arrival at the final delivery stop the Integration will look for the next order assigned to the driver and automatically dispatch that order out.
- Only orders which are in a PLN or DSP status and have a legheader.lgh_startdate of X number of hours before or after the current time will be automatically dispatched. X is configurable based on a Transflo TFM setting and has a default value of 8.
- If the order does not have a delivery (e.g., a split trip) then the Core Integration uses the arrival at the final stop on the current leg.
Transflo TMW Integrations are leg-based from the perspective of TMW data structures. Meaning that a TMW Leg = Transflo Load. This distinction is usually only relevant when discussing Split trips and Consolidated Orders within TMW. Transflo's integration handles both scenarios.
Loads which are cancelled in TMW will be removed from the driver's app.

CORE 04: Actualizing Stops

If the dispatcher actualizes the entire order manually within the TMS, the integration will set the load status to Completed within the Transflo mobile app. However, if the dispatcher actualizes only specific stops, but not the entire order, the integration does not update the driver load workflow to catch up the driver. The stop arrival and departure times will be overwritten as the driver completes their workflow on the mobile device.
The Driver will actualize the stops within TMW as they complete their Transflo Load Workflow.
The Integration can only update existing TMW data, it cannot insert new records within the TMW database. This means that to support updating freight or reference number information inside TMW based on Driver inputs from the Transflo mobile app, the TMW order must have placeholder values specified for those fields. As a customer, you can accomplish this by inserting a custom SQL script into your UpdateMovePostProcessing or UpdateMovePostProcessingLight stored procedures.
If a dispatcher un-actualizes a stop which had already been actualized by a driver, and the driver actualizes a departure stop which takes place after the un-actualized stop, the Integration will re-actualize any and all prior stops which are currently un-actualized. This is a data cleanup action by the Integration. As a general rule, the dispatchers should not be un-actualizing completed stops unless they are completely un-assigning the load from the driver.
If the driver rapidly actualizes stops, the Integration will space out the arrivals and departures by 60 seconds into the future. This is to prevent date/time conflicts within TMW as a result of a driver not completing their workflow in real time.

Note: The core and fuel integrations do not perform any TMW backoffice process functions related to rating, billing, or settlements in TMW. After the TMW leg is complete, the integration no longer interacts with that leg. This is true even if the leg has been marked completed but a user manually sets it back to AVL using SQL. The integration keeps track of the legs which have been completed and ignores any and all updates to the leg after that point.

Fuel Integrations

Supported features and functionality are broken down below based on the TMW Order Lifecycle:

Booking Orders
Assigning Assets to Orders
Dispatch Orders
Actualizing Stops
Completing Orders
Back Office (Not Supported)
1. Rating
2. Billing
3. Settlements

FUEL 01: Booking Orders

The Integration does not see TMW Fuel orders until they have been assigned to a driver and that driver has logged in for the day.

TMW Retain and Runout Times:

The Fuel integration uses the value from TMW legheader.lgh_startdate as the Shipping Date in Transflo.
The Fuel integration uses the concatenated values from TMW stops.stp_schedtearliest and stops.stp_schedtlatest for the first Delivery (stop record where stp_type ='DRP') as the Delivery Date in Transflo.

Load Details:

The Fuel Integration will include the following data as Load Details meta data in Transflo:

Total empty miles
Total loaded miles
Orderheader level reference numbers up to 500 characters
Trip Notes up to 500 characters

TMW Commodity Pin Codes, Account Of, and Supplier

The fuel integration supports sending out Pin Codes, Account Of company IDs, and Supplier Company IDs from TMW as long as the values are being stored in the standard columns on the order in one or more freightdetail records.

fgt_pincode
fgt_accountof
fgt_supplier

Stop Details:

The Fuel Integration will include the following additional data as Stop Details meta data in Transflo:

Stop Scheduled Earliest and Stop Scheduled Latest window for each stop.
Directions (cmp_directions) for the company on each stop.
Stop level reference numbers up to 500 characters.

FUEL 02: Assigning Orders

Orders should be assigned on the Card Planner as is SOP for shift-based dispatch.
The first load of a driver shift must be assigned prior to that driver logging in for their shift or it will not be automatically dispatched to the driver. The dispatcher is still able to manually dispatch the load in this scenario.
Dispatchers can un-assign orders from drivers and the Integration will remove the load from the Driver's mobile app.
Dispatchers will need to un-actualize any actualized stops prior to unassigning the load.
Changing the orderheader status on a load from DSP or STD to any of the following statuses will result in load removal:
- CAN
- PLN
- AVL
- PND
- QTE

Changing a legheader status from DSP or STD to any of the following statuses will result in load removal:
- CAN
- AVL
- PLN

FUEL 03: Dispatching Orders

The driver must have at least one assigned order on a given shift for the Integration to be able to process the shift login.
Dispatcher will need to manually login the driver or the driver will need to re-send their login once loads have been assigned by the dispatcher.
When the driver logs in for their shift the Integration will look for a valid shift:
- Driver must be assigned to a shift for that date
- Shift status must be set to On Duty
- Driver shift login must occur within the window of the shift +/- 2 hours.
  
  For example, if the scheduled shift is from 10am-10pm, the driver can log in from 8am -12pm on the same date.
- Subsequent shift logins against the same shift will cause the integration to set the shift logout to NULL.
  
  For example, if the driver logs in, logs out, and then logs back in again, the integration sets their original logout date and time to null.
- Once the integration processes a valid shift login, it automatically dispatches the first planned order to the driver.
Upon arrival at the final billable stop the Integration will look for the next order assigned to the driver for the current shift and automatically dispatch that order out.
Transflo TMW integrations are leg-based from the perspective of TMW data structures (meaning that a TMW leg = a Transflo load. This distinction is usually only relevant when discussing split trips and consolidated orders within TMW. The Transflo integration handles both scenarios.
Loads which are canceled in TMW will be removed from the mobile app so the driver does not see them.

FUEL 04: Actualizing Stops

If a dispatcher actualizes an entire order manually within the TMS, the integration sets the load status to Completed in the Transflo mobile app. If a dispatcher actualizes only specific stops, but not the entire order, the integration does not update the driver load workflow to catch up the driver. The stop arrival and departure times will be overwritten as the driver completes their workflow on the mobile device.
The driver will actualize the stops within TMW as they complete their Transflo Load Workflow.
The integration can only update existing TMW data, it cannot insert new records within the TMW database. This means that in order to support updating freight or reference number information inside TMW based on driver input from the Transflo mobile app, the TMW order must have placeholder values specified for those fields. This can be accomplished with a custom SQL script inserted into the customer's UpdateMovePostProcessing or UpdateMovePostProcessingLight stored procedures.
If a dispatcher un-actualizes a stop which had already been actualized by a driver, and the driver actualizes a departure stop which takes place after the un-actualized stop, the Integration will re-actualize any and all prior stops which are currently un-actualized. This is a data cleanup action by the integration. As a general rule, the dispatchers should not be un-actualizing completed stops unless they are completely un-assigning the load from the driver.
If the driver rapidly actualizes stops, the integration will space out the arrivals and departures by 60 seconds into the future to prevent date and time conflicts in TMW as a result of a driver not completing their workflow in real time.

Transflo would love your feedback on our solutions and the support we provide to you!

All rights reserved. Transflo believes the information in this publication is accurate as published; however, information is subject to change without notice. Use, copying, and distribution of any TRANSFLO software described in this publication requires an applicable software license. THE INFORMATION IN THIS PUBLICATION IS PROVIDED “AS IS.” TRANSFLO, LLC MAKES NO REPRESENTATIONS OR WARRANTIES OF ANY KIND WITH RESPECT TO THE INFORMATION IN THIS PUBLICATION, AND SPECIFICALLY DISCLAIMS IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Transflo content appearing in third-party AI chat bots and other third-party sites might not be accurate. For the latest updates about Transflo products, visit transflo.com and knowledge.transflo.com.