Features
New Delivery Report – React Migration with Postgres-Based Reporting
Grasshopper 3.26.02 Release Notes
Overview
The existing Delivery Report experience is composed of two related views: an aggregated report at the shipper level and a detailed report at the single-shipper level. To improve performance, scalability, and long-term maintainability, this enhancement introduces a new React-based Delivery Report.
The new report will run in parallel to the existing version for a period of time, allowing teams to validate parity while benefiting from improved responsiveness, richer controls, and better support for invoicing workflows.
Key Enhancements
1. New Delivery Report in Analytics
● Added a new report under Analytics → New Delivery Report.
● Runs in parallel to the legacy Angular report during the transition period.
2. First Page – Shipper Summary View
The first page provides an aggregated shipper-level overview.
Summary Boxes
● Total Orders
● Total Charges
Filters
● Date Picker
○ Similar behavior to On Time Performance reports ○ Date selection limited up to yesterday
● Shipper Name
○ Search-as-you-type
● Terms
● Pending Invoice
● Undated
Grid Columns
● Checkbox
● Shipper Name
● Terms
● Delivered
● Rejected
● Damaged
● Failed
● Returned
● Disposed
● Total (orders & amount)
● Avg Per Order
Additional Behavior
● Summary line that totals every column
● Last Updated timestamp displayed at the report level
Actions
● Refresh whole page
● Pre-Invoice
● Copy
● Export
● Create Invoice
3. Second Page – Single Shipper / Carrier Detailed View The second page provides detailed order-level reporting and invoice management. Performance & Page Handling
● Increased rows per page support
● Allows up to 500 rows per page
● Supports pagination with page size options:
○ 25
○ 50
○ 100
○ 500
● Resolved timeout scenarios when creating one invoice for many orders
General Enhancements
● All columns can be:
○ Shifted / reordered
○ Sorted
● Users can save their view
● Last Updated timestamp displayed at the report level
Summary Boxes
● Total Orders
● Total Charges
● Total Invoiced (orders and amounts)
● Pending Invoice (orders and amount)
Filters
● Date Picker
● Include Undated Deliveries
○ The undated delivered are the ones updated in the last 365 days
● Status
● Terms
● Pending Invoice
● Billing Subtypes
● Zero Price (Revenue = 0)
4. Detailed Grid Structure Main Columns
Default visible columns include:
● Checkbox
● Order ID
● Invoice
● PO / Ref
● Delivered
● Status
● Items
● Service Level
● Revenue
● Manifest ID
● Manifest Name
● Carrier Name
Additional Columns (Under “More”)
● Parent ID
● Linked
● Terms
● Customer Name
● Origination
● Region
● Weight
● Value
● Cube
● Payment Status
● Order Stop
Interactive Behavior
● Order ID opens the Order Drawer
● Linked column opens the link tree (subject to final UX implementation)
5. Actions on Detailed View
Supported actions include:
Single-Order Actions
● Add Payment Notes
● Transaction Details
Bulk / Report Actions
● Refresh whole page
● Pre-Invoice
● Mark as Paid
● Reprice Orders
● Reprice Orders and overwrite current pricing
● Export
● Create Invoice
6. Transaction Details Popup
● Added a new popup frame for Transaction Details
● Displays transaction information in a clear and simplified layout
● Improves visibility into billing and payment-related details
API Enhancement – Support Receiving Hours on Order Creation
Overview
Some customers require the ability to specify receiving hours when creating orders, particularly for delivery and pickup-return scenarios. While this capability already exists on the Tracking Page, it was not previously available via API integrations.
This enhancement extends the Order Creation API to support optional receiving hours, enabling partners to define preferred time windows directly at order creation while maintaining full backward compatibility.
Key Enhancements
1. Optional Receiving Hours in Order API
● Added support for two optional fields:
○ requested_hours_from
○ requested_hours_to
● Fields can be provided:
○ Individually (from only or to only), or
○ Together (from + to)
This ensures flexible input aligned with real-world customer requirements.
2. Backward-Compatible API Extension
● The API schema is extended without breaking existing integrations.
● Orders can still be created without providing receiving hours, with no impact on current workflows.
3. Validation Rules for Receiving Hours
The API validates receiving hours to ensure data integrity:
● Valid time format required (e.g., rejects invalid values like 25:00)
● “From” must not be later than “To”
● Time range must not exceed the daily 24 hours
● If the provided range is less than 60 minutes, it is automatically adjusted to 60 minutes
If validation fails, the order is rejected with:
“Invalid input fields – receiving hours are invalid”
4. Timezone Handling
● Receiving hours are interpreted based on the timezone of the delivery address.
● Ensures consistency with routing and scheduling logic.
5. Business Hours Independence
● Receiving hours outside standard business hours (08:00–18:00) are still accepted.
● These values are stored as requested hours, with no automatic restriction or override.
6. Scope of Application
● Receiving hours apply only to:
○ Delivery orders
○ Pickup return orders
● Supported at the requested level only (required hours are out of scope).
7. UI Integration
● Provided receiving hours are displayed on the Tracking Page under Requested Hours. ● Ensures visibility for both customers and operational teams.
Feature Enhancements
Warehouse Dashboard – User Activity Page Overview
To improve operational visibility and performance tracking at the warehouse level, a new User Activity page has been introduced.
This page provides a centralized, hub-level view of user activity, aggregating key warehouse actions such as picks, loads, unloads, counts, and more—enabling supervisors and admins to monitor productivity and identify trends in real time.
Key Enhancements
1. New User Activity Page in Warehouse Dashboard
● Added a new navigation entry:
○ Warehouse Dashboard → User Activity
○ URL: warehouse/user-activity
● Page is accessible to the following roles:
○ Super Admin
○ Grasshopper Admin
○ Supervisor
○ Inventory
2. User Activity Grid
The page displays a per-user activity summary with the following columns:
● User Name
● Picks – total pick scans
● Loads – total load scans
● Unloads – total unload scans
● Counts – cycle count and allocation scans
● Relocates – relocate scans
● Inspections – inspect scans
● Assembly – assembly-related scans
● Issue Handling – includes:
○ Failed Deluxe
○ Dispose
○ Repairs
○ Repair Quote
○ (Tooltip added to explain scope)
● Total Scans – sum of all user actions
Sorting:
● Default sort by User Name (A–Z)
3. Advanced Filtering
Available Filters:
● Date
○ Date picker (default: Today, real-time data)
○ Restrictions:
■ Cannot select future dates
■ Cannot select dates older than 4 months
○ If selecting a range that includes today and multiple days → show warning
● Hub
○ Single-select, searchable
○ Cannot be cleared
○ Follows same logic as Location Report
● User Name
○ Multi-select dropdown with search
○ Automatically resets when Hub selection changes
4. CSV Export
● Users can export the current grid view to CSV
● Export respects:
○ Active filters
○ Current dataset
5. Last Updated Indicator
● Displays the last update time in hh:mm AM/PM format
Logic:
● If Today is selected → show current time (“Now”)
● Otherwise → show latest update timestamp from Postgres
● Includes a Refresh button to fetch the latest data
Scope
Not Included:
● User performance scoring or KPIs
● Drill-down to individual scan events
● Cross-hub aggregation
Lasso – Improved Handling for Return Orders and Tag-Along Followers
Overview
Recent production issues revealed incorrect lasso behavior for return orders, particularly in scenarios where items are rejected during delivery or when return orders are part of tag-along relationships.
In some cases, return orders were automatically lassoed (triggering customer communications) even though the driver was already on-site collecting items, or when the order was a tag-along follower that should inherit scheduling from its parent.
This enhancement introduces stricter controls to ensure that lasso and scheduling actions are applied only when appropriate, reducing unnecessary communication and preventing incorrect operational flows.
Key Enhancements
1. Block Lasso for Tag-Along Followers
● Auto Lasso is disabled for tag-along follower orders.
● Followers now inherit scheduling directly from their parent order, ensuring consistent behavior.
2. Block Manual Lasso on Tag-Along Followers
● Users are prevented from manually triggering lasso on follower orders. ● The lasso icon is disabled or removed where applicable.
● Users attempting the action receive the message:
“Lasso can not be ordered for tag-along follower”
3. Block Manual Scheduling on Tag-Along Followers
● Manual scheduling actions are also blocked for follower orders.
● The same validation message is displayed to ensure clarity and consistency.
4. Refined Auto Lasso Behavior for Return Orders
● Auto lasso is no longer triggered immediately when return orders are created (e.g., Return to Vendor or Return and Dispatch scenarios).
● Instead, Auto Lasso for return orders is handled exclusively by the plugin.
This ensures that:
● When items are rejected and picked up on-site, they are already in Transit Return status
● Unnecessary lasso communication (email/SMS) is avoided
Shipper Portal – Disable Retailer Edit Permissions After Order Receipt
Overview
Previously, shippers (retailers) with edit permissions could modify order and item details in the Shipper Portal at any stage of the order lifecycle—including after the order had already been received at the hub.
Post-receipt edits created operational risks such as mismatched manifests, delivery inconsistencies, and data integrity issues.
This enhancement introduces a read-only guardrail that prevents shipper-side edits once the order progresses beyond early inbound stages, ensuring data consistency and protecting downstream operations. In case of locked order the shipper may contact the retailer for order editing.
Key Enhancements
1. Status-Based Read-Only Enforcement
● Shippers can edit orders only when the order is in:
○ Pending Arrival
○ Pending Pickup
● When the order transitions to any other status:
○ The order becomes read-only in the Shipper Portal.
2. Order-Level Field Restrictions
When the order is no longer editable, the following fields are locked:
● Customer Address Information
○ Street Address
○ Apt / Unit
○ Zip Code
This prevents post-receipt changes that could impact routing, labeling, and delivery execution.
3. Item-Level Editing Disabled
● All fields in the Item (Line Item) modal become read-only.
● The Save button is hidden.
● An informational message is displayed:
“This order has been received at the hub and can no longer be edited. Contact your licensee to change order details.”
4. Return Orders Are Fully Non-Editable
● For Return to Vendor and Disposition orders:
○ No editing is allowed at any stage from the Shipper Portal.
● These orders represent items already in consignee possession and must be managed by the carrier.
5. Reserved Status Handling
● Items in Reserved status behave as read-only, consistent with other in-warehouse states.
● Prevents modification of items already allocated or processed within warehouse workflows.
Feature Enhancements
Inventory – SKU View Enhancements (PO Search & Retail Value Visibility)
Overview
To improve usability and visibility in the Unallocated Items → SKU View, several enhancements have been introduced based on customer feedback.
These updates enable users to search by PO number and gain better financial insight through retail value calculations, aligning the new React experience with—and improving upon—the legacy Angular capabilities.
Key Enhancements
1. PO-Based Search in SKU View
● Enhanced the SKU search functionality to support PO number search.
● Search behavior:
○ Supports “starts with” matching for PO values
○ Integrated into the existing search field (no additional filters added)
UI Improvements
● Updated search placeholder text to:
“Search by SKU or PO”
Search Logic Update
● Replaced Regex-based search with text-based search:
○ Improves performance
○ Simplifies behavior
○ Reduces technical debt
2. Total Retail Value in SKU View
● Added a new column: “Total Retail Value”
● Position: To the right of the Shipper column (last column)
Calculation
● Represents the sum of retail value across all items within a SKU
Export Support
● Included in SKU View CSV export
3. Retail Value in Item View
● Added a new column: “Retail Value” in the Items View grid
● Position: To the right of the Condition column
Export Support
● Included in Items View CSV export
Warehouse Outbound Report – Total Route Time Visibility Overview
Previously, the Warehouse Outbound Report provided visibility into Route Time, which represented only the driving portion of a route.
Customers requested the ability to understand the full route duration, including both driving and service time, to gain a more accurate view of operational timelines.
This enhancement introduces a new Total Route Time metric while clarifying the existing metric as Total Driving Time, improving reporting accuracy and transparency.
Key Enhancements
1. Clarified Existing Metric
● Renamed existing Route Time to:
○ Total Driving Time
● Continues to represent drive time only (no change in calculation).
2. New Column: Total Route Time
● Added a new column:
○ Total Route Time
● Represents the full duration of the route, including:
○ Driving time
○ Service time at stops
Defect Fixes
Bug Fix: Improved Unload Performance in Warehouse Mobile App
Overview
Warehouse associates reported severe performance issues during the Unload workflow in the Warehouse Mobile app when scanning items belonging to large orders (more than 50 items). In these cases, each scan could take 30–45 seconds to process, especially when the order contained dozens of items, causing major operational delays and a poor warehouse experience.
This fix focuses on server-side optimization of the Unload API, significantly reducing scan latency and restoring a fast, responsive unload flow even for heavy manifests and large orders.
Key Fixes
1. Unload API Performance Optimization
● Optimized the server-side logic behind the Unload action to reduce processing time per scan.
● Improved response handling for orders with a high number of associated items.
2. Reduced Scan Latency for Large Orders
● End-to-end unload scan time was reduced from 30–45 seconds per scan to a target of 2–3 seconds maximum.
● Applies specifically to heavy manifests and large-order scenarios that previously caused the greatest delays.
3. Preserved Performance for Standard Workflows
● Ensured there is no regression for normal orders and standard unload scenarios.
● Existing fast scan behavior remains intact and may also benefit from the backend improvements.
4. Improved Warehouse User Experience
● Warehouse users now receive near-immediate feedback after scanning.
● Reduces bottlenecks during unload operations and improves productivity in high-volume environments.
Bug Fix: Prevent Duplicate Zip Code Assignment Within the Same Region
Overview
Grasshopper supports multi-region zip code assignment, allowing the same zip code to be associated with different regions (hubs). However, within a single region, a zip code must remain unique and can be assigned to only one sub-region.
Production investigation revealed cases where the same zip code had been mistakenly assigned to multiple sub-regions within the same region, creating invalid configurations and operational inconsistencies.
This fix introduces both data cleanup and system enforcement to ensure zip codes remain unique within a region while preserving valid multi-region behavior across different hubs.
Key Fixes
1. Production Data Cleanup
● Identified all existing cases where the same zip code appeared more than once within the same region.
● Prepared a review list of corrupted assignments, including the duplicated Canadian zip code cases.
● The Cleanup process now supports removal of invalid duplicate records after business review.
2. UI Validation Before Save
● Added validation in the UI to block users from saving a zip code that is already assigned to the selected region.
● Validation is performed before persistence, reducing user confusion and preventing invalid data entry.
4. Preserved Multi-Region Behavior
● The fix applies only within the same region.
● Zip codes can still be assigned to different regions, maintaining the intended multi-region capability.
Bug Fix: RTBS Orders Incorrectly Populated “Offered At” and “First Available Manifest” Without Communication
Overview
In certain scenarios, orders marked as RTBS (Ready to Be Scheduled) were automatically populated with “Offered At” and “First Available Manifest” values—even when no communication (SMS/email) was sent to the consignee.
This created misleading data in the Other tab, suggesting that scheduling communication had occurred when, in fact, it had not.
The issue commonly occurred when consignee contact details were missing (e.g., no phone or email), or when communication was otherwise suppressed due to configuration or timing constraints.
Key Fixes
1. Conditional Update Based on Communication Execution
● The system now updates “Offered At” and “First Available Manifest” fields only when communication is successfully triggered.
● If no communication is sent, these fields remain empty.
2. Accurate Representation of RTBS State
● Orders can still be correctly marked as RTBS even when communication is not sent.
● However, scheduling-related metadata is no longer populated unless a valid communication event occurs.
3. Covers Multiple No-Communication Scenarios
The fix applies to all cases where communication is not sent, including:
● Missing consignee contact details (phone/email)
● Shipper configuration disabling communication
● Communication outside allowed working hours
Bug Fix: Unable to Access All Linked Orders Due to Missing Scroll in Linking UI
Overview
Users reported that in the Linked Orders UI, it was not possible to scroll through the full list of linked orders.
When an order had multiple relationships (e.g., 7+ Tag-Along orders), users were unable to view or access all linked entries, limiting visibility and preventing further actions such as adding or managing links.
This issue impacted multiple relationship tabs and reduced the usability of the newly introduced Linked Orders experience.
Key Fixes
1. Added Vertical Scrolling Across All Tabs
● Implemented vertical scrolling support in the Linked Orders UI.
● Users can now scroll through all linked orders regardless of list size.
2. Full Access to Tag-Along Relationships
● Verified that orders with 7+ Tag-Along followers can now:
○ Be fully viewed
○ Be accessed
○ Support adding additional links
3. Consistent Behavior Across All Relationship Tabs
Scrolling is now fully supported in:
● Tag-Along Orders
● Source / Derived Orders
● Related Orders
Ensures consistent usability across all linkage types.
Bug Fix: Enforced Pickup Information Validation for Return Orders (API & Import)
Overview
Orders of type Return / Pickup were being created without required pickup information, resulting in incomplete and invalid orders.
In some cases, these orders were incorrectly treated as FOB or routed as standard last-mile deliveries, leading to scheduling errors, routing issues, and data inconsistencies.
This fix introduces strict validation to ensure all required pickup details are provided during order creation via both API and Import flows.
Key Fixes
1. Mandatory Pickup Information for Return Orders
When creating an order with Return / Pickup type, the following fields are now required:
● Pickup Zip
● Pickup Address1
● Vendor
If any of these fields are missing, the order creation is blocked.
2. Import Validation & Error Handling
● During Import Preview:
○ Missing required pickup fields are clearly marked as “Missing” in the relevant cells.
● On submission:
○ Orders with missing pickup information are rejected.
○ No invalid orders are created.
● Users receive a clear validation message, such as:
“Pickup Address is required for Stop Type 2.”
3. API Validation
● In the Create Order API:
○ Requests missing required pickup information for return orders are rejected. ○ The specific order is not created.
● Ensures consistent validation across all integration paths.
4. Prevent Incorrect Order Classification
● Eliminates cases where incomplete return orders were:
○ Misclassified as FOB
○ Routed incorrectly in last-mile workflows
● Ensures proper scheduling and routing behavior from creation.
Bug Fix: Batch BOL Single Document Missing Shipper, Ship To, and Consignee Information
Overview
Users reported that when downloading a Bill of Lading (BOL) for multiple orders as a Single Document, several key fields were incorrectly displayed as N/A.
Specifically, the generated document did not properly populate the Shipper, Ship To, and Consignee sections, reducing document quality and creating confusion for operational and customer-facing workflows.
Key Fixes
1. Corrected Data Mapping in Batch BOL Single Document Generation
● Updated the single-document BOL generation flow to correctly populate:
○ Shipper
○ Ship To
○ Consignee
● Eliminated the incorrect fallback to N/A when the required order data exists.
2. Fixed Multi-Order Merge Logic
● Corrected the logic used when combining multiple orders into a single BOL document. ● Ensures order-level party information is carried into the final output consistently.
3. Preserved Behavior Across Standard Download Flows
● Fix applies specifically to:
○ Orders Grid
○ Multi-order selection
○ Download BOL → Single Document
● Existing BOL generation flows outside this path remain unchanged.
Bug Fix: Rescheduling Reason Prompt Appeared for Freight Manifests
Overview
Users reported that when removing an order from a Freight Manifest, the system incorrectly prompted for a rescheduling reason.
This behavior is intended only for Last Mile Manifests, but was being triggered for Freight flows when the advanced setting “Require a reason for rescheduling” was enabled. This caused confusion and unnecessary friction in freight operations, where rescheduling justification is not required.
Key Fixes
1. Restricted Rescheduling Prompt to Last Mile Only
● The rescheduling reason popup is now triggered only for Last Mile manifests.
● Freight manifest workflows no longer invoke this requirement.
2. Correct Handling of Advanced Setting
● The setting “Require a reason for rescheduling” now applies strictly to:
○ Last Mile manifests
● It is ignored for:
○ Freight manifests
3. Improved Workflow Consistency
● Removing stops from Freight manifests now behaves as expected:
○ No additional prompts
○ No unnecessary user input required
Bug Fix: Receiving Items Without Location Selection in Web App
Overview
Users were able to mark items and orders as Received in a selected Region/Hub without specifying a Location.
This resulted in inventory being marked as received but not physically locatable, leading to inaccuracies in warehouse operations such as picking, putaway, and audits.
The issue affected multiple receiving entry points in the web application, including both item-level and order-level (“Received in Terminal”) workflows.
Key Fixes
1. Enforced Location Selection on Receive
● The Location field is now mandatory when marking items or orders as received.
● Users cannot complete the receive action without selecting a valid location.
2. UI Enhancements for Location Input
● Added a Location selector to all receiving dialogs.
● Behavior:
○ Disabled until a Region/Hub is selected
○ Once enabled:
■ Displays locations for the selected region
■ Sorted A → Z
■ Supports autocomplete search
■ Single selection only
● The Confirm / Next button remains disabled until a valid location is selected.
3. Applied Across All Receiving Entry Points
The fix applies consistently to:
● Item-level receive (Items tab)
● Order-level receive (Received in Terminal)
● Item edit → mark as received
4. API Validation & Enforcement
● Receiving API now requires location_id:
○ If missing → request is rejected with:
“Location is required”
○ If location does not belong to selected region → rejected with: “Location does not exist in selected region”
5. Correct Data Persistence
● On successful receive:
○ Items are assigned to the selected location_id
● Ensures accurate tracking and warehouse visibility.
6. UI Error Handling
● User-friendly error messages are displayed when API validation fails.
● Prevents silent failures and improves user clarity.
Bug Fix: Incorrect Display and Handling of Tag-Along Return and Service Orders in Manifest Content
Overview
A production issue was identified where Tag-Along combinations of pickup-return and service orders were incorrectly displayed and handled in the Manifest Content tab. Mixed stops (e.g., pickup + service) were treated purely as pickup stops, causing the routing engine to derive the address incorrectly and leading to scheduling and linking failures.
This issue impacted complex stop scenarios and resulted in incorrect routing behavior and confusion in manifest representation.
Key Fixes
1. Correct Handling of Mixed Stop Types
● Updated logic to properly support mixed order types within a single stop, mainly: ○ Pickup + Service
2. Parent Order Determination
● For pickup-return + service combinations:
○ The pickup-return order is now enforced as the parent
○ The stop type is correctly identified based on the parent
3. Accurate Manifest Entry Type
● Mixed pickup-return and service stops are now displayed as:
○ “P&S” (Pickup & Service)
● Ensures clear and accurate representation in the Manifest Content tab.
4. Correct Address Resolution for Routing
● The routing engine now derives the stop address from the parent order (pickup).
● Prevents incorrect address selection when multiple order types exist in a single stop.
5. Validation of Customer Address Consistency
● Tag-Along linking for pickup-return and service orders now verifies that: ○ Both orders share the same customer address
● Prevents invalid or mismatched link scenarios.
6. Improved Entry Details Visibility
● Manifest entry details now correctly display:
○ All items associated with the stop
○ Including both parent and follower orders
● Supports both existing service orders and newly added service items.
Bug Fix: Tag-Along Unlink Not Properly Synced with VC and Partner Systems
Overview
A production issue was identified where unlinking Tag-Along orders did not correctly propagate to Virtual Carrier (VC) and partner systems.
As a result, unlinked orders could remain scheduled on manifests or retain outdated pickup scheduling information, creating inconsistencies between Grasshopper, VC, and partner systems.
Key Fixes
1. Manifest Update on Unlink
● When a scheduled follower order is unlinked:
○ The order is now automatically removed from the manifest
● Ensures the manifest accurately reflects the current order relationships.
2. Pickup Schedule Cleanup for Return Orders
● For pickup-return orders:
○ Unlinking now removes the scheduled pickup date from the pickup address
● Prevents residual scheduling data after unlinking.
3. VC Synchronization
● The unlink action now correctly publishes an event to VC.
● Ensures VC receives the updated linking and scheduling state.
4. Partner System Synchronization
● VC now properly propagates the unlink event to partner systems.
● Partner environments reflect:
○ Updated linking status
○ Updated scheduling state
5. End-to-End Data Consistency
● After unlinking:
○ Grasshopper (GH), VC, and partner systems all display consistent order relationships and scheduling status
● Eliminates mismatches between systems.