Grasshopper 3.24.33.2 Release Notes
Features
Mobile App – Correct Inbound Handling for Multi-Hub Manifests
Overview
For multi-hub accounts, manifests created as outbound from Hub A to Hub B were incorrectly treated as outbound at the destination hub.
When users at Hub B opened the manifest in the Mobile App, they continued to see outbound actions such as Pick & Load, and were not given the appropriate Unload action—even though, operationally, this is an inbound manifest for the receiving warehouse.
This behavior forced users to manually relabel the manifest as “Inbound” in the web application to maintain workflow consistency.
The workaround introduced unnecessary friction, training difficulties, and increased risk of operational mistakes such as picking instead of unloading.
This enhancement ensures that manifests moving between hubs of the same account are automatically recognized and treated as inbound when viewed at the destination hub.
Key Enhancements
1. Automatic Inbound Handling for Inter-Hub Manifests
● When a manifest is created from Hub A → Hub B within the same account, the destination hub now automatically treats it as Inbound.
● No manual relabeling or status adjustments are required.
2. Correct Action Set Based on Destination Workflow
● At the destination hub, the Mobile App now displays only inbound-appropriate actions, including:
- Unload
- No Pick & Load option
- No other outbound actions
This ensures clarity and prevents workflow errors.
3. Consistent Multi-Hub Behavior Across Mobile and Web
● Mobile App logic now matches inbound expectations established in the web interface. ● Ensures operational accuracy and a unified experience across tools.
4. Reduced Training Complexity and Error Risk
● Eliminates confusion for new users at the destination hub.
● Removes the possibility of mis-processing an inter-hub manifest as outbound.
Out Of Scope
● Any changes to outbound behavior at the origin hub
● Cross-account manifest handling
● Additional manifest status logic outside inbound/outbound presentation
System Audit Report for Admins
Overview
To improve governance, transparency, and administrative control, a new System Audit report has been added to the Analytics module.
This report provides super admins and admins with a centralized, searchable view of key configuration changes across regions, zip codes, sub-regions, surcharges, and other system-level entities.
The audit log displays detailed before/after values, user attribution, and related entities, enabling better oversight and operational traceability for high-impact actions.
The report follows the specification and layout defined in GRAS-6076.
Key Enhancements
1. New “Audit” Section in Analytics (Admin-Only)
- Added a dedicated Audit section visible only to:
i. Admin
ii. Super Admin
- Includes the new System Audit report.
- Ensures sensitive administrative logs are restricted to authorized users.
2. Comprehensive Audit Log Table
The new System Audit report displays the following columns:
● Date
● Activity
● Main Entity Type
● Main Entity
● Related Entity Type
● Related Entity
● Description
● User (name)
● Previous Value
● New Value
This view consolidates all configuration change events into a single, structured audit trail. 3. Advanced Filtering Capabilities
Filters include:
● Date Range
○ Filter by activity date interval.
● Activity Type
- Dropdown list including activities such as:
■ Assign Zip Code
■ Unassign Zip Code
■ (Future activities may be added)
● Entity Type
- Dropdown including values such as:
■ Zip Code
■ Region
■ Sub Region
- When selected, results include logs where the value appears in either Main Entity or Related Entity.
● Entity Value
- Enabled only when Entity Type is selected.
- Accepts a free-text search input (1–15 characters).
● User
- Free-text search to filter by admin username.
These filters enable precise log exploration and fast identification of specific changes.
4. CSV Export
- Users may export all rows and all displayed columns to CSV.
- PDF export is explicitly out of scope for this phase.
5. Previous / New Value Logic per Activity
- The system audit events will start with a baseline activities around zip code and in the future the system will expose additional ones
Not Included:
● PDF export
● Non-admin access
● Additional activity types beyond the initial list
Downstream Logistics and Designer Delivery Services requested improved visibility into the monthly Last Mile manifest calendar, specifically the ability to see manifest names for the entire month.
Last Mile Manifest – Monthly Calendar View With Manifest Names
Overview
The existing monthly view only displays truck counts and status summaries, making it difficult for operations teams to plan ahead, understand coverage areas, and coordinate routes by region or manifest group.
1. New Feature Flag for Monthly Manifest Name Visibility
This enhancement introduces an updated monthly calendar view that displays all manifest names within each date cell, providing full operational transparency for long-range planning. Functionality is configurable to ensure backward compatibility and controlled rollout.
Key Enhancements
● Added a new configuration under the feature_flag object:
feature_flag allow_monthly_view_with_names: true/false
- Default: false
- Ensures controlled enablement for accounts that want to use this feature.
2. New Advanced Setting for Last Mile Calendar
In Advanced Settings → Manifest → Last Mile → Calendar View, introduced: ● “Display manifests name” (on/off, default off)
This setting controls the visibility of manifest names in the monthly calendar cells, enabling per-account flexibility.
3. Updated Monthly View Display
When “Display manifests name” is enabled:
● Each day in the monthly calendar displays all manifest names for that date. ● No limitation on the number of rows shown per date.
● Boxes expand vertically as needed to accommodate all names.
● A single-page vertical scroll is reintroduced, similar to the legacy Angular behavior, ensuring full visibility across all days.
This provides route planners and downstream logistics teams the complete monthly manifest picture.
4. Quick Create Support
● The Quick Create manifest action remains fully functional in the updated monthly view. ● Users can continue to create manifests directly from any date cell without disruption.
Out Of Scope
● Weekly/daily calendar are not enhanced
● Any changes to manifest creation logic
● Additional filtering or grouping beyond manifest name display
Cycle Count – Enhanced UI Support for Large Warehouses (1,000+ Locations)
Overview
Cycle Count operations in large warehouses—often with hundreds or thousands of storage locations—were difficult to manage with the previous UI, which was optimized for smaller environments.
To improve usability, scalability, and performance for high-volume warehouses, this enhancement introduces a redesigned interface that separates statistics into structured tabs, adds scalable filtering and export tools, and dynamically adjusts the visual experience based on warehouse size.
These changes ensure accurate, efficient cycle-counting workflows for both Tier 1 (small/medium) and Tier 2 (large-scale) facilities.
Key Enhancements
1. New Location Statistics Tab
The Location Statistics grid has been moved into its own dedicated tab to improve clarity and performance.
Grid Columns (sortable where specified):
● Location (sortable)
● Completion Rate
● Expected Items (sortable)
● Found
● Missing
● Location Mismatch
● Unexpected
● Total Exceptions (sortable)
This structured layout gives teams a clearer, more scalable overview of cycle count progress.
2. Advanced Filtering Tools
The grid now supports enhanced filtering, designed for large datasets:
● Location: Multi-select with search
● Completion Rate:
- Greater Than
- Less Than
- Is Between
These filters allow fast and precise navigation across thousands of locations.
3. Grid Export
Users can export a CSV of the current view, preserving:
● Active filters
● Visible sorting
● Current tab data
This enables deeper external analysis and operational reporting.
4. Insights Tab – Behavior Based on Warehouse Size
Tier 1 (1–100 Locations)
● Heat map remains displayed.
● Tile width is now fixed to ensure a consistent 10-column layout, improving readability and alignment.
Tier 2 (101+ Locations)
● Heat map is hidden to avoid performance issues and visual overload.
● An info box is displayed instead, explaining that the warehouse exceeds the threshold for heat map visualization.
This dynamic adaptation ensures optimal UI performance across all warehouse sizes.
Out Of Scope
● Changes to cycle count logic
● Changes to backend scoring or reconciliation
● Multi-warehouse aggregation
Warehouse Mobile – Cycle Count Support for High Location Volumes
Overview
Cycle Count tasks in large warehouses can include hundreds or even thousands of locations, but the previous Warehouse Mobile app interface was optimized for smaller task sizes. This enhancement introduces robust support for high-volume cycle count tasks, allowing warehouse teams to efficiently navigate, search, and focus on locations that still require processing.
These improvements ensure that mobile counting workflows remain fast, accurate, and scalable, even in facilities with extensive storage layouts.
Key Enhancements
1. Support for Tasks with 1,000+ Locations
● The mobile Cycle Count module now reliably loads and manages tasks containing up to 1,000 locations and beyond.
● Performance and memory handling have been optimized to ensure smooth scrolling and fast navigation regardless of task size.
2. Text-Based Location Search
● Added a location text search filter, enabling users to quickly jump to a specific location by typing part or all of the location identifier.
● Supports partial matches, making it easy to find locations within very large task lists.
3. Filter to Show Only “Not Done” Locations
● Users can now toggle a view that displays only incomplete locations.
● This reduces clutter, allowing warehouse staff to focus immediately on what remains to be counted without scanning through completed rows.
Carrier Report – Added “Farthest Stop” Column and Transition Banners
Overview
Clients requested the return of the “Farthest Stop” metric, previously available in the legacy Contractor Billing report but missing from the new Carrier Report.
This enhancement reintroduces the metric with improved calculation logic while also adding transitional banners that guide users toward the new Carrier Report experience and away from the soon-to-retire Contractor Billing report.
The update enhances visibility into route distance, supports operational cost analysis, and ensures a smoother migration path for users accustomed to the legacy report.
Key Enhancements
1. New “Farthest Stop” Column in Carrier Report
A new column, Farthest Stop, has been added to the Carrier View:
● Location: Right side of the report, immediately after the Services column.
● Value: Displays the farthest distance (in miles) between any stop on the manifest and its associated hub.
● Sortable: Users can sort the report ascending or descending by this metric. ● Included in CSV Export: The new column is fully included in the CSV export file.
This metric helps carriers and operations teams understand delivery radius, route spread, and distance-driven workload.
2. Calculation Logic (Expanded Scope)
To match legacy behavior and reflect operational nuances:
● Pickup Orders:
Distance is calculated at the item level.
● Delivery & Service Ticket Stops:
Distance is calculated based on the order address.
This ensures “Farthest Stop” is accurate and aligned with how different stop types are measured operationally.
3. New Banners for Carrier Report Transition
A. Carrier Report Banner
Displayed at the top of both the Carrier Report and the Carrier View pages.
B. Contractors Billing Banner
Remove the “Contractor Billing” report button from Analytics.
Warehouse Inbound Report – Extended Date Range Support with Operational & Analytical Modes
Overview
The Warehouse Inbound Report previously supported date ranges of up to 7 days, which worked well for day-to-day operations but severely limited customers needing broader analytical views such as monthly trends, quarterly performance, or year-over-year comparison.
To address both needs—operational speed and analytical depth—this enhancement introduces two new execution modes: Operational Mode and Analytical Mode(a none real time mode). Together, they provide flexible and scalable reporting while maintaining system stability.
Key Enhancements
1. Two Reporting Modes Based on Date Range
Operational Mode – Real-Time
● Used for date ranges up to 1 day.
● Provides live, real-time data.
● Optimized for speed and immediate operational visibility.
Analytical Mode (none real time) – Extended Range
● Automatically used for dates ranges from 2 days up to 3 months.
● Pulls data from aggregated warehouse inbound tables in Postgres, ensuring: ○ Stable performance
○ Faster response times over long ranges
○ Safe execution without impacting live operational workloads
This dual-mode architecture balances operational responsiveness with analytical flexibility.
2. Seamless User Experience
● Users select their preferred date range as usual.
● The system automatically routes the query to the appropriate data source. ● No workflow change for users; the enhancement is fully backend-driven.
3. Support for Long-Term Analysis
The new Analytical Mode enables customers to run:
● 2–3 month inbound volume reviews
● Seasonal planning
● Vendor performance analysis
● Year-over-year comparisons (within the 3-month window)
This was previously impossible with the 7-day limit.
Inventory Creation UI – Make Cube Field Read-Only When Dimensions Are Entered
Overview
In the current Inventory Item creation UI, users can manually enter both dimensions (L × W × H) and cubes, even though the system recalculates cubes whenever dimensions are provided. This leads to confusion, unnecessary data entry, and overwritten user inputs. To improve data integrity and streamline the experience, this enhancement introduces intelligent read-only behavior for the cube field and stronger validation for dimension inputs.
Key Enhancements
1. Cube Field Becomes Read-Only When Dimensions Are Entered
● When all three dimensions (length, width, height) are populated with valid values: ○ Cubes are automatically calculated, as today.
- The cube field becomes read-only to prevent manual overrides.
● This ensures consistency, prevents calculation conflicts, and clarifies the source of the cube value.
2. Cube Field Becomes Editable When Dimensions Are Cleared
● If any dimension is removed or left blank:
- The cube field becomes editable again.
- Supports scenarios where users want to enter cube-only items.
This dynamic enables both workflows while preventing accidental data overwriting.
3. Prevent Negative Dimension Values
● Added validation to ensure only positive numbers are allowed in the dimension fields.
● Negative values are now rejected to avoid invalid cube calculations and ensure accurate volumetric data.
Linehaul & Warehouse Reports – Added “Pallets” Field Support
Overview
Some customers require the ability to record and view the number of pallets associated with inbound and outbound linehaul manifests, particularly for warehouse receiving workflows and operational reporting.
Since a Pallet object does not yet exist in the platform, this enhancement introduces a temporary but production-ready numeric field on manifests, along with corresponding visibility in Warehouse Inbound and Outbound Reports.
The feature is fully controlled through a licensee feature flag (pallet_support), enabling selective rollout.
Key Enhancements
1. New Manifest Field: pallet_count
● Added a new data field to the Manifest model:
- Name: pallet_count
- Type: integer (nullable)
- Default: null
- Applies To: Linehaul Inbound and Outbound manifests only
● This field allows customers to store the number of pallets associated with a manifest.
Validation Rules
● Accepts only positive whole integers (1, 2, …)
● Maximum 4 digits (e.g., up to 9999)
● Error copy for invalid input: “Must be positive number”
Permissions
● Editable by any user role that can edit manifests today
● Editable in all statuses except Closed
- When Closed → field becomes read-only
2. Web UI – Manifest Edit Page
The new field appears in the manifest edit screen: ● Location:
Manifest → Details tab, placed next to Tracking Number ● Label: Pallets
● Type: numeric input
● Save flow: Uses the existing “Save Manifest” button
Visibility
● Controlled by the pallet_support feature flag: ○ OFF: Field is fully hidden
- ON: Field visible as specified
3. Warehouse Inbound Report Enhancements
New Column: “Pallets”
● Placement: To the right of the Pieces column ● Value: Displays pallet_count
- If null → show N/A
● Sorting/Filtering: None added
● Export:
- Included in CSV export
Visibility
● Controlled by pallet_support flag
- OFF → hidden from UI & export
- ON → visible
4. Warehouse Outbound Report Enhancements
New “Pallets” Column for Linehaul Only
● Same behavior as Inbound Report but only for Linehaul manifests
● Hidden when report filter Type = Last Mile
● Exports:
- CSV export for Linehaul includes the column
- Column hidden in Last Mile export
- PDF export for Linehaul includes the column
Visibility
● Controlled by pallet_support
5. Feature Flag: pallet_support
● Scope: Per account
● Location: In the feature flag config section
● Behavior:
- OFF:
■ Field hidden on manifests
■ Columns hidden in Inbound/Outbound reports
■ Field absent from CSV/PDF exports
- ON:
■ Full functionality enabled
6. Global Sync
● Pallet count is not synchronized globally.
● Value is meant for local operational use only (as confirmed with business stakeholders).
API Enhancement – Expose “Add Accessorial to Order” API for Licensees
Overview
Accessorials are frequently added to orders by licensees for operational or billing purposes (e.g., fees, special handling, surcharges).
This enhancement introduces a public API that allows licensees to add accessorials directly to an order—streamlining workflows, reducing manual effort, and ensuring alignment between UI and API capabilities.
Key Enhancements
1. New API Endpoint: Add Accessorial to Order
● Provides licensees with the ability to attach an accessorial to an order through the API.
● This enhancement applies only to order-level accessorials, not service items performed by drivers.
2. Optional Amount Override
● The API accepts an optional amount field.
● If supplied:
- The provided amount overrides the default amount defined for that accessorial. ● If not supplied:
- The system uses the accessorial’s configured amount.
This offers flexibility when accessorials vary on a per-order basis.
3. Optional Notes Field
● The API accepts an optional notes field.
● If provided, the accessorial description is auto-formatted as:
[Accessorial] <name> Notes: <content>
● Notes may be up to 100 characters.
This improves auditability and gives partners context about why the accessorial was added.
4. Licensee-Only Access (Phase I)
● The API is currently enabled only for licensees, consistent with existing permissions and operational processes.
● Future expansion to other roles or partners can be addressed in later phases.
Out of Scope
● Virtual carrier addition of accessorial is out of scope and will be completed in another enhancements
Defect Fixes
ETA Discrepancy Between Grasshopper UI and API Response
Overview
A client reported a discrepancy between the ETA displayed in Grasshopper and the ETA returned via the public API.
Investigation revealed that the UI and API were using different transformation logic for the same underlying ETA. This misalignment caused confusion for customers consuming ETA via API and comparing it to what dispatchers and customers see inside GH.
Key Fixes
1. Unified ETA Calculation Logic
- Standardized the ETA calculation pipeline so that both:
■ Grasshopper UI, and
■ estimated_eta in the API response
now originate from the same canonical ETA value and apply the same
rounding rules.
2. Consistent Timezone Handling
- Corrected a mismatch in timezone conversion between the internal ETA engine and the API serializer.
- Ensured that estimated_eta is always:
■ Stored and transmitted in UTC, and
■ Derived from the same local ETA value shown in the GH UI.
API Returned HTTP 403 with HTML Instead of JSON When Canceling Orders
Overview
When integrators attempted to cancel an order via the API, the endpoint returned an HTTP 403 Forbidden status accompanied by an HTML error page, rather than the standard JSON error response used across the API.
This behavior caused failures in downstream systems, as API consumers expected a structured JSON payload that could be parsed programmatically.
The API should return a clear, machine-readable error message such as: “Order cannot be canceled because status is Rejected”, with an appropriate HTTP 4XX code. Investigation confirmed that the endpoint was inadvertently falling back to a generic HTML server error handler when encountering invalid cancellation scenarios (e.g., attempting to cancel an already rejected order).
Key Fixes
1. Standardized Error Handling for Cancel Order Endpoint
● The cancellation endpoint now correctly returns structured JSON responses for all error conditions.
● Eliminated the fallback to HTML error templates.
Phone Number Hyperlink Incorrectly Added “+” Prefix
Overview
When users clicked a phone number hyperlink in the system, the generated dial action incorrectly prepended a “+” to the number.
This caused devices—especially mobile phones—to interpret the call as an international number, leading to dialing errors or failed calls.
For U.S.-based customers, this behavior was unexpected and disrupted workflow when attempting to contact consignees directly from the system.
The expected behavior is that the hyperlink should not modify the number, or if a prefix is required, it should correctly apply the +1 U.S. country code.
Key Fixes
1. Removed Incorrect “+” Prefix
● The phone number hyperlink no longer adds a plain “+” before the number. ● Clicking a number now initiates a call exactly as stored in the order or user profile.
2. Added Correct Country Code Handling
● If a phone number explicitly requires a country code prefix:
- The system now uses +1 for U.S. numbers (where applicable).
● Prevents devices from interpreting the number as international.
3. Standardized Phone Hyperlink Formatting
● All clickable phone numbers now follow consistent formatting rules.
● Avoids device-specific misinterpretation of digits and prefixes.
4. Improved UX Across All Platforms
● Fix applies to:
- GH Web
- Mobile Web
- Mobile App (where hyperlink conversion is used)
● Ensures consistent dialing behavior across environments.
Freight Inbound Blocked by Payment Banner for Pre-Delivery / Pre-Paid Shippers
Overview
Licensee users encountered an issue where they were blocked from adding open balance orders to inbound freights when the shipper’s payment type was set to Pre-Delivery or Pre-Paid.
A payment-related banner incorrectly prevented the action, even though payment status should not restrict the creation of inbound freight shipments.
Key Fixes
1. Removed Incorrect Payment Restriction
● Licensees can now add open balance orders to inbound freights regardless of the shipper’s payment type.
● The payment banner no longer blocks the action.
2. Corrected Business Rule Enforcement
● Payment type validation (Pre-Delivery / Pre-Paid) now applies only in the appropriate order workflows, not during inbound freight creation.
● Freight assembly logic correctly ignores payment constraints.
Pickup Schedule Cannot Be Removed After Order or Item Split
Overview
Licensees reported that after splitting an order or splitting order items, the new resulting order automatically retained the pickup scheduled date and associated manifest assignment from the original order.
Because of this, users were unable to remove or clear the pickup schedule on the newly created split order, even though the split order should start with no pickup commitment. This issue impacted only local licensee orders. Vendor Carrier (VC) workflows will be addressed separately by defect fix.
Key Fixes
1. Remove Pickup Schedule & Manifest Assignment After Split
When an order or order item is split:
● The newly created order will automatically:
- Clear the scheduled pickup date, and
- Remove any associated manifest from both:
■ The order header, and
■ The individual order items
This ensures the new order does not carry over previous scheduling metadata from the original order.
2. Restore Ability to Remove Pickup Schedule on New Orders
● Users can now successfully remove the pickup schedule on any split order.
● Fix resolves all prior failures where the system prevented clearing scheduled pickup fields.
3. Local Licensee Orders Only
● Fix applies only to local licensee flows.
● Virtual Carrier order behavior will be redesigned separately.
Out of Scope
● VC split order behavior (handled separately)
Warehouse Mobile – Error Handling for Duplicate Scans During Unload
Overview
Warehouse teams reported that during the Unload workflow in the Warehouse Mobile app, users were able to scan the same item multiple times (via QR code or Serial Number). This resulted in inaccurate unload counts, confusion during reconciliation, and unnecessary rework.
To prevent duplicate scans and ensure accurate unload processing, a new validation has been added to stop repeated scans and provide a clear, immediate error message.
Key Fixes
1. Duplicate Scan Validation Added to Unload Action
● The system now checks whether an item (QR code or Serial Number) has already been scanned during the active unload session.
● If the item is found in the scanned list, the system blocks the action.
2. User-Friendly Error Message
When attempting to scan an item more than once, the user now sees:
“Item ${item_id} was already scanned”
This ensures warehouse users immediately understand the issue and prevents double-counting.
3. Applies to All Scan Methods
● QR code scans
● Serial number scans
● Manual scan inputs (if applicable)
Warehouse Mobile – Scan Mode Auto-Switch Did Not Update Scan Area in Unload
Overview
In the Unload workflow of the Warehouse Mobile app, users reported that after the scanner auto-switched between QR and barcode (serial) scan modes, the actual scanning area did not update correctly—even though the UI mode indicator changed.
As a result, when multiple barcodes were visible on screen (e.g., stacked vertically), the scanner sometimes returned the wrong item, because it remained focused on the previous scan area. This mismatch between displayed scan mode and the active scan area led to incorrect item scans and unload errors.
Key Fixes
1. Proper Sync Between Scan Mode and Scan Area
● When the app auto-switches between:
- QR code scan mode and
- Serial/barcode scan mode, the underlying scan area is now updated to match the active mode.
● Ensures that:
- QR mode uses the correct frame optimized for QR.
- Barcode/serial mode uses the correct frame optimized for linear barcodes.
2. Correct Behavior in Unload Flow
● Specifically in the Unload action:
- After scanning a QR code, the scanner may auto-switch into item (serial) scan mode.
- The scan area is now fully refreshed to match the new mode, preventing lingering focus on the previous scan region.
3. Accurate Scanning When Multiple Codes Are Visible
● When multiple barcodes or labels appear one above the other on screen: ○ The scanner now correctly targets the barcode in the intended active scan area.
- Eliminates the observed behavior where the scanner returned a different item than the one the user pointed at.