Grasshopper 3.26.03 Release Notes

Features

New Manifest Drawer

Overview

A new Manifest Drawer has been introduced to provide quick, at-a-glance access to manifest information without navigating away from the current page. The drawer can be accessed directly from the Last Mile Manifests grid and presents a structured summary of the manifest, its orders, and key operational details, making it easier for users to review and act on manifests in context.

Key Enhancements

• Manifest details at a glance

The drawer opens with a header displaying the manifest ID as a direct link to the full manifest page, giving users quick access to deeper details when needed.

• General information section

Displays key manifest metadata including route name, current status, and departure date — providing an immediate operational snapshot.

• Summary section

Shows aggregate counts for the manifest including total stops, total items broken down by pickup and delivery, and total services.

• Order content list

The drawer includes a structured list of all orders on the manifest, showing order number, Tag-Along and Third Man indicators (with tooltips), service level, order type, item count, service count, and cube (cbf).

• Quick navigation

A “Plan Route” link is available directly from the drawer, allowing users to jump straight to the route planner for the manifest.

• Contextual tooltips

Tooltips have been added to the Tag-Along and Third Man icons to improve clarity for users who may be unfamiliar with these indicators.

Warehouse Services – Packaging

Overview

This release introduces end-to-end support for Warehouse Services, starting with Packaging as the first supported category. The enhancement spans the service catalog, order management, warehouse mobile app, and server-side APIs — enabling warehouse teams to manage packaging tasks directly within Grasshopper.

Key Enhancements

• New service type: Warehouse

The Service Creation Wizard now supports a Warehouse service type in addition to Driver and Accessorial. Warehouse services are surfaced as actionable tasks in the Warehouse app, while Accessorial services remain billing-only. The Warehouse Category field (Packaging in Phase 1) is required when the Warehouse type is selected.

• Price override at assignment

A new Price Override option allows authorized users to modify the service price at the time it is assigned to an order, providing flexibility for shipper-specific pricing needs.

• Service type visibility in Order Details

A new column has been added to the Services tab in Order Details to display the service type (Warehouse, Driver, or Accessorial) using distinct icons, replacing the previous “performed by driver” indicator and improving operational clarity.

• Accessorial Catalog updated

The Accessorial Catalog has been updated to support the new service types. Changes include a new Type filter (Warehouse Service, Driver Service, Accessorial), a Type column replacing the “Performed by Driver” column, name search by prefix, a fixed Name column, and a refresh button.

• Warehouse Mobile app – Packaging queue

A new Packaging section has been added to the Warehouse Mobile app, accessible from the Warehouse menu. It presents a queue of orders with pending packaging services (and completed-today orders), allowing associates to search by Order ID, review service details, and complete services directly from the app.

• Mandatory photo on service completion

When completing a packaging service via the Warehouse Mobile app, associates are required to attach one photo before marking the service as complete. The photo is stored with the asset type Packaging and linked to the service completion record.

Warehouse App – New Home Screen

Overview

A redesigned Home screen has been introduced for the Warehouse Mobile app, providing warehouse associates with a centralized, actionable view of their day’s work immediately upon opening the app.

Key Enhancements

• Personalized home screen

The home screen displays the user’s name and active region, with a gear icon for quick access to Settings. If no region is selected, a full-page prompt guides the user to choose one before loading any data.

• Four actionable sections

The home screen is organized into four sections: Outbound Last Mile, Inbound, Outbound Freight, and Assigned to Me. Each section shows a horizontally scrollable row of manifest or task cards with relevant metrics and a primary action button (e.g., Pick, Verify, Unload, Load).

• Show more navigation

Each section includes a “Show more” card at the end of the scroll row, navigating to the relevant existing page filtered to the appropriate date context.

• Redesigned bottom navigation

A new bottom navigation bar provides tabs for Home, My Tasks, Last Mile, and Freight. A center floating action button defaults to “Search by scan” on most pages, and changes to “Add manifest” on the Freight page.

• Quick actions menu

A floating bottom-right button opens a General Actions menu with shortcuts to common warehouse operations including Relocate, Pre Inspect, Cycle Count, Fulfill, Repairs, and Packaging.

Async Order Creation API

Overview

A new asynchronous API for order creation has been introduced, enabling partners to submit order creation requests without waiting for synchronous processing. This improves resilience and scalability for high-volume integrations.

Key Enhancements

• Async endpoint with webhook callback

A new POST /api/async/orders endpoint accepts order creation requests, performs basic validations, and returns immediately with a job ID. Once processing completes, the system triggers a webhook with the result (success or failure), allowing partners to handle outcomes asynchronously.

• Durable job tracking and execution

The system introduces a durable job record store to track each request through its full lifecycle (queued, processing, completed, failed). Jobs are executed in a worker thread on the same pod, with idempotency controls to prevent duplicate order creation on retry. Clear failure semantics distinguish between business failures (no retry) and system failures (with retry via BullMQ).

Percentage-Based Service Pricing

Overview

The service pricing model has been enhanced to support percentage-based charges in addition to fixed-value charges. This allows carriers to configure accessorial services that calculate their amount as a percentage of the order’s total revenue, enabling flexible, shipper-specific pricing.

Key Enhancements

• Percentage calculation type

When creating an Accessorial service, users can now select Percentage (%) as the calculation type. The service amount is calculated as a percentage of the order’s total revenue at the time the service is created.

• Static calculation behavior

Once created, the calculated service value is static and does not automatically update if the underlying order cost changes. Users can remove and re-add the service to recalculate based on the current order cost.

• New switchable rate input component

A new UI component allows users to switch between currency and percentage input modes when defining service rates. Switching modes resets the rate values, and the rate type cannot be changed after the service is created.

Enhanced System Audit Messages

Overview

System audit logging has been expanded to cover two additional areas: pricing set management and user lifecycle actions. These enhancements improve traceability and operational transparency across the platform.

Key Enhancements

• Pricing Set audit logs

Audit events are now generated when pricing sets are created, updated, or deleted, with context linking each event to its scope (Public, Retailer, or Partner). Bulk imports generate individual audit entries per pricing set row processed.

• User management audit logs

Five new audit events have been added to track user lifecycle actions: Create User, Update User Permissions, Disable User, Enable User, and Delete User. Permission change logs capture scope and region changes only.

Driver Verification – Separated Warehouse and Driver States

Overview

Previously, warehouse verification and driver verification updated the same status field, causing manifests to appear fully verified by the driver even when only warehouse scanning had occurred. This release separates the two verification states at the data level, ensuring the outbound_verified flag on a manifest accurately reflects driver-only verification.

Key Enhancements

• Separate verification states

Warehouse and driver verification now maintain distinct status fields. Warehouse verification no longer marks items as driver-verified, and the is_manifest_fully_verified calculation is now based exclusively on driver verification state.

• Verification linked to line items

Each driver verification record is now linked to a specific line item. Removing a driver verification in the web app reverts the corresponding line item’s driver verification state and triggers recalculation of the manifest’s outbound_verified flag.

• Resolved bypass and regression issues

This fix resolves several related bugs where drivers could bypass route verification by refreshing the app, or where the verification state was incorrectly shown as complete after a single item scan.

Outbound Report – Average Expense & Revenue Metrics

Overview

The Warehouse Outbound Report now includes four new financial insight metrics, giving operations and finance teams a clearer picture of per-manifest and per-stop performance without requiring external calculations.

Key Enhancements

• Four new metrics added

The Insights section of the Outbound Report now displays: Average Expense per Manifest, Average Expense per Stop, Average Revenue per Manifest, and Average Revenue per Stop. All values are calculated server-side and support up to two decimal places.

Delivery Window Visibility Control

Overview

A new advanced setting allows carriers to control when delivery time windows are displayed on the order page. When enabled, the delivery window is shown only after it has been broadcast to the customer, preventing premature visibility of unconfirmed time windows.

Key Enhancements

• New advanced setting under Scheduling

A new toggle — “Display Delivery Window only after it’s broadcast to the customer” — has been added under Advanced Settings → Scheduling. When off (default), the delivery window is shown as soon as it is saved to the stop, matching existing behavior.

• Post-broadcast only visibility

When the setting is enabled, the delivery window is hidden from the order page unless the specific stop or order has been broadcasted to the customer with that time window. If the time is later changed without re-broadcasting, the window is hidden again until the next broadcast.

Coverage Map – Secondary Region Visualization

Overview

The Coverage Map has been enhanced to display secondary region assignments in addition to primary regions, giving operations teams full visibility into shared zip code coverage directly within the map interface.

Key Enhancements

• Secondary region coloring

A new toggle allows users to switch between viewing primary zip codes only, secondary zip codes only, or both. Secondary zip code coverage is displayed using a striped pattern to visually differentiate it from primary coverage.

• Enhanced zip code tooltips

Zip code tooltips on the map now display all associated regions — both primary and secondary — providing full context for shared zip codes without leaving the map.

• Segmented data loading

Coverage data is now loaded in segments to prevent server strain when all regions are selected, with a progress indicator showing sub-region loading status.

Enhance “Assign Region” to Reconcile Item Statuses

Overview

The Assign Region bulk order action has been enhanced to optionally reconcile item statuses when a region reassignment occurs. This resolves cases where items were marked as Consolidated due to wrong-hub receiving but remained in that state after the order’s destination region was corrected.

Key Enhancements

• Optional item status update

A new “Update Status” checkbox in the Assign Region modal allows users to trigger item status reconciliation alongside the region change. For example, Consolidated items at hub B will transition to Received when the order is reassigned to hub B. The checkbox is unchecked by default.

• Locally owned orders only

The item status update applies only to locally sourced orders. If any selected order is not locally owned, the checkbox is disabled and a tooltip explains why. The region assignment itself still completes normally.

• Sub-region made optional

The Sub-region field in the Assign Region modal is now optional, reducing friction for region-level reassignments that do not require a specific sub-region.

Insight – Orders Waiting for Invoicing

Overview

A new Insight type has been introduced that highlights orders which are eligible for invoicing but have not yet been invoiced. The insight helps finance and billing users identify revenue that is ready to collect and navigate directly to the relevant delivery report.

Key Enhancements

• Automated detection

The system identifies orders that have been in a ready-to-invoice state for more than one business day within a rolling 7-day window (up to yesterday). The insight displays the total count of qualifying orders and their combined revenue amount.

• Direct navigation to invoicing

A “Move to Invoice” action button in the insight card opens the Delivery Report pre-filtered to the relevant date range, allowing users to proceed with invoicing in one click.

• Role-based visibility

The insight is visible only to authorized users such as finance, billing, and admin roles. Orders already invoiced are excluded from the count.

Manual Service Completion for Standard Orders

Overview

The ability to manually update a service’s status has been extended to standard and service-type orders. Previously, this capability was available only for return-type orders.

Key Enhancements

• Expanded order type support

Dispatchers and carriers can now manually transition service statuses for standard and service-type orders. The service status can be moved from Pending to Delivered, Cancelled, or Rejected based on user input, consistent with behavior for return orders.

Legacy Calendar Removed

Overview

The legacy Last Mile Calendar has been removed following the full migration to the React implementation. 

Key Enhancements

• Legacy calendar removed

All legacy LM Calendar code has been removed. The React calendar continues to function as expected with no change to calendar-related workflows or routes.

Defect Fixes

Bug Fix: Returns Log – Incorrect SKU / Serial Number Export

Overview

When downloading the Enhanced Returns Log report, SKU values containing commas were incorrectly split across multiple columns in the exported file. A value such as 154,730 was interpreted as two separate fields, causing exported data to be inaccurate and misaligned with what was displayed in the UI.

Key Fixes

• The Returns Log export now treats SKU values as single fields regardless of whether they contain commas.
• The exported report now accurately reflects the data shown in the UI for the corresponding order.
• Records without a serial number continue to export correctly with no impact on adjacent fields or column alignment.

Bug Fix: Public Tracking – Incorrect ETA and Premature Driver Visibility

Overview

Two related issues were identified on the Public Tracking page: the ETA shown to customers was incorrect in certain scenarios, and driver location was being surfaced prematurely. Additionally, the Expected Arrival Time was displaying the completion time of the previous stop rather than the calculated ETA for the next stop.

Key Fixes

• ETA on the Public Tracking page is now calculated from the correct route data, ensuring customers see accurate expected arrival times.
• Driver visibility on the tracking page is now triggered at the appropriate point in the route, preventing premature display.
• The Expected Arrival Time field now correctly reflects the projected ETA for the next stop rather than the last completed stop’s timestamp.

Bug Fix: Time Frame Configuration Mismatch in Planner

Overview

The shipper-specific time frame configuration was not being applied correctly during scheduling. Orders were displaying a default 3-hour duration in the Route Planner even when a shorter shipper-specific time frame had been configured.

Key Fixes

• Shipper time frame configuration is now applied at scheduling (manifest assignment) rather than at order creation.
• The system checks for a shipper-specific time frame override at scheduling time. If one exists, it is applied; otherwise the default time frame is used.
• The applied time frame is now correctly reflected in the Route Planner and all relevant views.

Bug Fix: Integration Settings Page Fails to Load

Overview

Shipper users attempting to open the Integration Settings page encountered a blank white page, making the page inaccessible. This has been resolved and the Integration Settings page now loads correctly for shipper users.

Bug Fix: Service Ticket Type Not Saving After Creation

Overview

When creating a service ticket, the selected service type was not being persisted. Upon reopening the ticket, the service type field appeared empty, requiring users to re-enter the value manually. The service type is now correctly saved and displayed when the ticket is reopened.

Bug Fix: Delivery Confirmation Texts Showing Incorrect Scheduled Date

Overview

Customers reported receiving delivery confirmation SMS messages citing an incorrect scheduled date — different from the actual date shown in the system. The text message was reflecting the scheduling timestamp rather than the correct delivery date. Delivery confirmation messages now accurately reference the scheduled delivery date for each order.

Bug Fix: Linehaul Manifest Incorrectly Displaying 3rd Man

Overview

The Linehaul Manifest was displaying the 3rd Man indicator, which is not applicable to linehaul operations. The 3rd Man flag is now correctly suppressed on Linehaul Manifests and only displayed where relevant.

Bug Fix: Failed Deluxe Inventory Email Not Sent

Overview

When an inventory item was marked as Failed Deluxe via the warehouse menu, the expected notification email to the retailer was not being sent due to a bad function reference in the server code. The reference has been corrected and the Failed Deluxe notification email is now sent as expected.

Bug Fix: Defective Condition Not Retained When Adding Items to GIMS Inventory

Overview

When adding items to GIMS inventory with a Defective condition, the condition was not correctly saved. After the item was added, the condition field appeared blank, requiring users to update it manually each time. The Defective condition is now correctly persisted when items are added to GIMS inventory.

Bug Fix: Delivery Report Display Issues

Overview

Two sets of display issues were identified in the new Delivery Report. The Value column was missing entirely, and large numeric amounts were displayed without thousand separators, impacting readability. Additionally, icon-based column headers on the second page lacked tooltips, making their purpose unclear.

Key Fixes

• The Value column has been restored to the Delivery Report.
• Thousand separators are now applied to all numeric amount fields across both pages of the report, in both summary boxes and table columns.
• Tooltips have been added to icon-based column headers on the second page: Invoice icon shows “Invoice” and the Note icon shows “Payment Note”.
• The pointer cursor now appears correctly when hovering over icon columns.
• Summary boxes now display total amounts instead of averages.

Bug Fix: Newly Added Order Items No Longer Auto-Added to Open Manifests

Overview

Items added to an existing FOB order after creation were no longer being automatically added to open freight manifests or scheduled Last Mile manifests, creating a risk of partial shipments and requiring manual intervention. This regression has been resolved.

Key Fixes

• Items added to a received FOB order are now automatically added to the relevant open inbound freight manifest.
• If the order is already scheduled on a Last Mile manifest (pre-authorized or open), the new item is also added to that manifest automatically.
• Capacity validation is performed at the time of item addition. If the Last Mile manifest has insufficient capacity, the user receives a clear error and can manually adjust capacity before retrying.