Trip level tenders can be manually generated once all attached loads have reached Planned operational status. Transportation Manager also supports a Global Setting that will automatically trigger a trip level tender once all attached loads are in Planned status. See the Auto Tender field in "Global Settings – Auto Tendering fields".
If a load is added to a trip after a trip level tender has been issued, the tender for the additional load will be generated at load level. A maximum of one trip level tender will exist for each trip.
Tenders generated at both load and trip level will cause a row to be created in the tender requests table. The "List of Tender Requests (Carrier)" presents a consolidated view of load and trip level tenders. Carriers can respond to open tenders at both load and trip level using this function.
The tender contacts for a trip level tender will be computed using the attributes of the first load on the trip's itinerary. Tender contact information will be persisted only at load level, with the same data being assigned to all loads assigned to the trip.
When Tender Update is performed for a trip, all tender requests associated with the trip (at trip or load level) will be updated so that the carrier receives a full description of the trip.
Loads assigned to a trip can be tendered and tender accepted at load level. Following this approach, loads must be tendered individually in ascending order based on the trip sequence and tender rejected or tender canceled at load level individually in descending order of the trip sequence.
Tender activity has no impact on trip status. However, when operations are performed for a trip level tender request, the operational status of loads assigned to the trip will be affected. For example, when a tender is issued for a trip, the operational status for each assigned load will be advanced from Planned to Tendered.
Tender requests have the follow statuses:
When the last load that is part of a trip level tender request (not necessarily the last load on trip) reaches Confirming operational status, the tender request will progress from Tender Accepted to Closed status.
Tender requests in Closed, Tender Rejected and Tender Canceled status are eligible to be purged using "Supplementary Purge (Employee)". Tender requests in Tender Rejected and Tender Canceled status can deleted individually from the List of Tender Requests. Data in the tender requests table can be purged before or after the corresponding load or trip is purged.
Carrier sequential tendering (CST) is not supported for trips, or for loads attached to trips. Trips can be automatically tendered to the assigned carrier but will not be tendered to secondary or tertiary carriers if the tender to the first carrier is canceled or rejected. It will be up to the logistics planner to decide if a trip should be offered to a different carrier as a trip, or split into distinct loads. Since automatic cancelation of tenders is only available for loads being processed by CST, trip level tenders will not be automatically cancelled if the carrier does not respond to the tender prior to the Tender Response Required By Date/Time.
A single tender report format is used for both load and trip level tenders. Trip level data is presented for trip level tenders and for load level tenders for loads attached to a trip.
The following trip level event notifications are supported:
When a trip level tender operation is triggered, the applicable trip level events will be used, if configured. Otherwise, if the equivalent load level event has been configured, the load level event will be triggered for each affected load on the trip.
The "Load Tender Cancelled or Rejected" event notification message is used when a load in Tender Accepted operational status is tender canceled or tender rejected. When a load is in Tender Accepted status, some preparation/execution may have been taking place in the warehouse or plant. Many TM customers rely on this event to trigger certain reversal activities in their ERP. There is no trip level equivalent for this event. When applicable, it will be triggered for each load regardless how the load was tendered or accepted.
The audit infrastructure in TM does not support trip level activity. When tender events occur at trip level, audit data will be captured for each associated load.
Spot rates cannot be assigned at trip level. Furthermore, spot rates cannot be defined for loads attached to a trip. Loads with spot rates are not eligible for optimization. When a load with a spot rate is manually assigned to a trip, the spot rate will be cleared.
When trip composition is changed for a trip, the corresponding trip level tender requests will be synchronized to reflect the complete trip, not only the loads originally associated to the tender request. If some loads on the trip have not yet been tendered, values on the trip level tender request will not match the loads formally associated with the tender request.
The following scenarios will cause tender requests to become "invalid":
It would still be possible to trigger the Tender Reject operation for this load from the List of Load Tenders.