Help Center

Grasshopper 3.24.31.9 Release Notes

Features:

Accessorial definition by region

Overview

This enhancement introduces the ability for carriers to define region-specific accessorial rates, enabling more accurate and flexible pricing across markets with different operational costs.

Until now, accessorials were priced only at the shipper level, using a single global rate. With this enhancement, shippers can optionally define unique rates per region while still maintaining a default rate.

This also supports business cases where a shipper offers an accessorial service in one region but not another.

Key Enhancements

The existing ‘Rate’ field in the accessorial table is now renamed to ‘Default Rate.’ A new optional region-level pricing section is added, supporting:

• Region 1 + rate
• Region 2 + rate
• …any number of additional regions
• Regional rates apply per shipper only (not global). For every accessorial, the default rate always exists, ensuring a fallback when no regional rate is defined.

UI Enhancements (Accessorial Page)

• The “Region” column now displays chips indicating how many regions have custom pricing (e.g., “+2”).
• Hovering over the chip displays the full list of region-specific rates.
• Users can:
  
  • Add region-specific rates
  • Delete region-specific rates
  • Delete the entire accessorial (existing behavior)
    
    

Order-Level Behavior

• When adding accessorials to an order:
  
  • The system evaluates the delivery address region and displays the correct price:
    
    • If a regional rate exists → show that rate
    • If not → show the default rate
      
• The same logic applies to pickup/return-from-customer workflows.
  

Address Change Recalculation

• When the delivery or pickup address is changed to a new region:
  
  
  • The existing pricing recalculation process is expanded to include regional accessorial selection.
    
  • Accessorial pricing is automatically refreshed based on the newly assigned region.

Early RTBS Based on Inbound ETA

Overview

This enhancement introduces the ability for carriers and partners to schedule home deliveries before items physically arrive at the final hub, using the inbound manifest’s Estimated Time of Arrival (ETA).

The feature accelerates scheduling workflows, reduces delivery lead time, and enables partners to plan ahead when inbound shipments are predictable and reliable.

An optional advanced setting controls this capability, ensuring it is only enabled for shippers who want to support early RTBS workflows.

This enhancement follows the functional flow shown in the design reference.

Key Enhancements / What’s New

New Advanced Setting: “Allow early RTBS”

• Located under: Advanced Settings → Orders → Scheduling
  
• Boolean flag: true/false (default: false)
  
• Tooltip:
  “Allows the carrier to schedule a home delivery before the order is received at the final hub, based on the estimated arrival time (ETA). This helps save time and accelerate the overall delivery process.”
  
• When enabled, GH allows RTBS earlier in the process based on inbound ETA.

Early RTBS Logic Based on Inbound ETA

Early RTBS becomes allowed when ALL of the following conditions are met:

1. The order is in the last leg, AND
   
2. The inbound manifest has a valid ETA, AND
   
3. The manifest destination matches the order.region.
   

If these conditions hold:

• GH automatically enables the RTBS flag.
  
• Auto Lasso becomes eligible regardless of the current order status.
  
• Supported statuses for early RTBS include:
  
  • In transit
    
  • Pending arrival
    
  • Consolidate

Scheduling Behavior

Manual Lasso + Auto Lasso

• Both scheduling methods support early RTBS.
  
• Both use:
  ETA date + buffer days (defined in Advanced Settings)
  as the earliest selectable date.
  

Manual Scheduling Through the Calendar

• Users may select any date, even before ETA-based constraints.
  
• This maintains flexibility for operations teams who understand the implications.

Configuration / Flags

• New advanced configuration flag: allow_early_rtbs
  
• Default value: false
  
• Additional configurable value: buffer days
  (applies to earliest scheduling date based on ETA)