Skip to main content

April 2026 Release Notes

April 2026 Release Notes — Logiwa IO

Updated today

NEW FEATURE HIGHLIGHTS

Mandatory Adjustment Reason for Inventory Operations

Warehouses can now require users to enter an adjustment reason whenever inventory quantities are manually updated, including cycle count approvals, inventory by location adjustments, and Excel import additions.

The requirement is activated through a new set of configuration flags in the Warehouse Setup screen and, once enabled, applies consistently across the web interface, mobile workflows, and the Open API, to be visible on the Transaction History Report. When a required reason is not provided, the system displays a validation prompt before allowing the inventory update to proceed. This ensures a complete audit trail for all inventory changes and supports tighter operational controls.


Count Plan Enhancements & New Order by Logic for Count Job Types

The Count Plan screens have been updated with a range of improvements to enhance visibility and control during cycle counting. New columns — including Counted Location, Counted Product, Recounted Location, and Recount Line — are now available in the Count Plan, Location Details, and SKU Details grids and are included in the More Details Excel export. Contextual tooltips and validation modals have been added to the Update Inventory action across all three count screens, clearly communicating the expected outcome before changes are applied.

Additionally, count job types now allow more options to define count task creation & batching priority order other than the walking path priority, under Order By section. On the mobile side, count tasks are now delivered to pickers in the order configured on the Job Type, aligning mobile counting sequences with the warehouse’s location strategy.

For more information, see articles on the Count Section


Job Cancellation Safety Logic

The system now includes a multi-layer validation framework for job cancellation workflows. Before a job is cancelled, the system identifies shipment orders classified as “At Risk” based on their order type and evaluates each order’s allocation eligibility — proceeding only with orders that can be safely reallocated, or applying a force cancel when the configuration requires it. Dynamic warning modals are displayed throughout the process to give operators clear visibility into what will be affected before any cancellation is committed. These improvements prevent accidental fulfillment disruptions and give warehouse supervisors greater control over high-stakes cancellation decisions.


Patch API Endpoints

Two new PATCH Open API endpoints are now available, allowing integration users to perform partial updates on key resources without submitting a full payload. Both new Patch Endpoints support single and bulk partial updates on products and shipment orders, with a maximum of 50 products per bulk request. Both endpoints are available under v3.1 and are documented in the Swagger/Developer portal.


iDriveLogistics Partner Integration

Logiwa IO now supports iDriveLogistics as a native carrier integration partner. Warehouses using iDrive as their fulfillment and delivery provider can connect directly through the carrier setup, enabling automated label generation and shipment tracking within the standard Logiwa IO packing and shipping workflows without requiring custom configuration.


EasyPost Multi-Piece Shipment Support

The EasyPost integration now supports multi-package shipment processing using the EasyPost Orders API. When a shipment order contains multiple packages and is routed through DHL Express, UPS, or FedEx via EasyPost, the system automatically uses the Orders endpoint to request consolidated rates and purchase all labels in a single transaction — replacing the previous single-package flow. Individual tracking numbers for each package are stored in Logiwa IO, and labels are merged and returned to the packing station in a single response.


Operational Analytics – BETA

Starting April 16, 2026, the new Operational Analytics module will be available as a BETA.

Please note that this new module is designed to replace the current Logiwa Analytics, which will be deprecated soon. This transition marks a significant upgrade in how you interact with your warehouse data, offering faster performance and deeper insights.

As part of this BETA release, you can now analyze your warehouse operations with unprecedented depth. The module empowers you to optimize inbound processes, fulfillment speed, and overall warehouse health through four dedicated dashboards:

🟦 Inbound & Inventory Dashboard

🟦 Fulfillment Dashboard

🟦 Management Dashboard

🟦 Productivity Dashboard

Setup & Details

As part of the Beta, you have 5 User licenses.

Access the setup details and module insights via the documentation below:


WHAT'S NEW & IMPROVED

  • Added configurable Order By support to Location Count job types, allowing warehouses to define multi-level location sorting rules that control the sequence in which count tasks are delivered to pickers. (50032, 50038)

  • Introduced verification logic to the One-by-One receiving flow, prompting users with a warning or blocking the scan when a received item does not match the configured verification rules before it is counted. (49197)

  • Added the ability to edit a product’s physical attributes (dimensions, weight, and volume) directly from the quantity entry screen during standard receiving, ensuring accurate inventory master data can be captured at the point of receipt. (49204)

  • Added Channel Order Code as a searchable field in the Return Station Shipment Order selection screen, allowing warehouse staff to locate return orders using the original sales channel reference. (45012)

  • Extended Channel Order Code search and display to both the SO and RMA card views in the Return Station, making the sales channel reference visible across all return workflow touch points. (45018)

  • Added PO Type, LP Type, and SKU Details Updated columns and filters to the Receiving History Report grid and Excel export; the same fields are available through the Receiving History Open API endpoint. (49614, 49628, 36521)

  • Added a “Pick/Pack Short Issue Label” print icon to the Shipment Order screen, renaming the previous “Issue Label” button for clarity and adding validation logic to check the shortage status of selected orders before triggering the label print flow. (47390)

  • Added Job Code to the Pick Short and Pack Short label data sources, allowing warehouse operators to identify the associated job on shortage labels and improve tracking in high-volume environments. (49985)

  • Introduced “Pick Short” reporting logic for single-order packing flows with tote or location grouping, enabling packers to trigger a pick short report by scanning a tote or location code and automatically close the session for any items remaining in that container. (50474)

  • Extended the Report Issue popup to support LPN scanning in the Hospital Location field, allowing operators to scan a tote (LPN) directly when reporting a pick short or pack short; the system resolves the tote to its current location and allows the user to confirm or modify the destination. (50181, 50427)

  • Introduced a client-level parameter to control whether License Plate Numbers are updated to match Carrier Tracking Numbers when fulfilling multi-box orders with attached labels, and added matching logic to align tracking number and LP number assignment at the packing station. (46997, 46990)

  • Added Retailer, Kit SKU Name, and Package Weight as selectable columns in the Shipment History Report grid and Excel export. (37514)

  • Added an IsRetain column and filter to the Missing Log Report grid and Excel export, allowing users to distinguish between standard missing actions and retain-type missing operations. (50851)

  • Added Priority and Rule Name as filterable fields on the Job Management screen, enabling warehouse supervisors to isolate high-priority jobs or jobs triggered by specific automation rules. (49809)

  • Added actualReturnDateTime as a filterable parameter to the Return Order list endpoints in v3.2 and v3.3, allowing integration partners to query and sync return records based on the Actual Return Date. (50610)

  • Extended the Shopify product download service to capture HS Tariff Codes and Country of Origin from the product’s customs declaration data, automatically populating these fields in the Logiwa IO product master when products are downloaded from Shopify via GraphQL for the first time. (50380)

  • Added validation to prevent deletion of a channel setup when there are active orders in the order backlog linked to it, protecting data integrity and preventing orphaned backlog records in native channel integrations. (18037)

  • Resolved a processing failure caused by Shopify Tax ID values exceeding the 18-character database field limit — the system now handles oversized Tax ID strings gracefully without failing the entire order download batch. (46166)

  • Introduced parallel label generation for multi-package orders processed through ShipStation, EasyPost, and Stamps, replacing the previous sequential request model; carrier label requests for each package in an order are now sent concurrently, significantly reducing total wait time at the packing station during high-volume fulfillment. (49278)

  • Added exception handling and orphaned label reconciliation to the single-order packing process; when an unexpected error occurs after a carrier label has been generated but before the WMS packing transaction is committed, the system now detects the orphaned label, voids it with the carrier, and allows the packer to retry cleanly without generating duplicate tracking numbers. (49272)

  • Extended the custom carrier request model to include channelOrderLineId in the internationalOptions and requestedPackageLineItems product arrays, enabling carriers to receive line-level channel identifiers required for international compliance and detailed packing verification on orders downloaded from integrated sales channels. (50757)

  • Extended the FedEx and EasyPost label generation services to capture and store the shipping zone value returned in the carrier API response, making zone data available for reporting and shipping cost analysis. (46106)

  • Updated the UPS address line mapping logic to preserve the original addressline1 and addressline2 values when both fields individually fit within the 35-character UPS API limit, preventing the previous forced merge-and-split behavior from breaking naturally formatted addresses on shipping labels. (45324)

  • Updated the Detailed Billing Report to display the actual physical receiving date as the Activity Date for PO transactions, ensuring better alignment with warehouse operations. (49230)

  • The User Management grid now includes an API User column and filter, allowing admins to quickly identify and filter API-only integration accounts. (50405)

  • DateTime fields in Excel exports now display seconds, showing the full hh:mm:ss format instead of hh:mm. Date-only fields remain unchanged. (49339)


PERFORMANCE IMPROVEMENTS

  • Improved the loading performance of the Consolidated Inventory Report for warehouses with large inventory volumes, reducing query execution times and preventing report timeouts. (50633)

  • Improved Purchase Order and PO Line data operations by migrating reads and writes to a single database exclusively, eliminating data consistency risks associated with the previous dual-database path, such as PO Status discrepancies. (50560)

  • Improved memory consumption and response times in the Amazon integration service by applying targeted optimizations to the Amazon API call layer, reducing resource overhead during high-volume order and inventory operations. (47554)


WHAT'S FIXED

  • Resolved an issue where the Transaction History Report was not displaying Location Group information correctly due to data being retrieved from a cached source rather than the SQL location tables. (50717)

  • Fixed an issue where the IsUsableAsParentLP flag was not applied to LP numbers created via Excel import, causing those LPs to be incorrectly rejected during receiving, picking, and transfer workflows. (50566)

  • Fixed an issue in the Work Order Kitting screen where component inventory was consumed from incorrect inventory lines when creating a kit, causing the wrong stock to be decremented. (50462)

  • Resolved a double scan validation issue in the mobile Directed Putaway flow where an additional location identification call was unnecessarily triggered when the location barcode differed from the location code, causing slow or inconsistent scan responses. (50457)

  • Fixed an incorrect LP Type assignment during Excel LP import caused by a missing warehouse filter in the License Plate Type lookup, which could result in LPs being assigned the wrong type when multiple warehouses share LP Type codes. (50193)

  • Resolved an issue in the Return Order screen where order lines were being displayed with multiplied quantities, causing the line count and amounts to mismatch the actual receiving history. (50187)

  • Fixed an inventory duplication issue during cycle count approval where stale inventory rows with a receiving date were incorrectly split into duplicate records instead of being consolidated. (50047)

  • Resolved a server error during Count Plan Excel import and Open API creation when the Count Plan Name exceeded the maximum allowed character length; the system now returns a clear validation message. (37316)

  • Fixed a conflict in the LP Type mapping logic during Purchase Order import and receiving where two LP Types sharing the same code were resolved incorrectly, causing PO lines and mobile receiving flows to reference the wrong LP Type. (16470)

  • Fixed an issue in the allocation engine where picking tasks were unnecessarily split across multiple license plates even when a single LP had sufficient quantity; the system now uses the initial free inventory snapshot to prevent LP fragmentation during allocation. (49306)

  • Resolved a backend logic failure at the packing station for orders configured with Allow Partial Allocation = Yes, Allow Partial Shipment = No, and Enable Partial Packing = No, where partial packing was incorrectly permitted in violation of the shipment order type settings. (49068)

  • Added backend validation to prevent shipment order lines from being updated with a negative or out-of-range UOM quantity, blocking data integrity errors that could affect downstream allocation, picking, and invoicing. (41595)

  • Fixed an incorrect expiry date format mapping in the mobile sorting flow where the app was reading the format from the client list level of the API response instead of the product-level attribute, causing date display and validation errors during sorting. (50747)

  • Resolved an email validation error in the Shipment Order creation endpoint that incorrectly rejected email addresses containing an apostrophe character; the validation logic has been updated to accept this as a valid email format. (36400)

  • Resolved an issue where a shipment order remained stuck in “Picking Started” status after the last pending picking task was reported as missing on an order with Allow Partial Allocation enabled; the order now correctly transitions to “Ready to Pack.” (50784)

  • Fixed a validation error that prevented warehouse operators from loading the remaining license plates of a partially shipped order into a new shipment plan when a prior plan for the same order was already in Shipped or Loading Completed status. (50676)

  • Fixed a race condition that allowed duplicate serial numbers to be generated for the same SKU when processed simultaneously, causing packing task status corruption and preventing affected orders from transitioning to Shipped. (49979)

  • Resolved an internal server error that occurred when a picker attempted to report a product as missing during picking, caused by an incorrect backend control triggering an error during back order creation when a quantity discrepancy was detected. (49951)

  • Fixed an incorrect sorting task quantity calculation where the system generated tasks for a full pack unit instead of the actual picked unit count when the One-by-Sorting parameter was enabled and a partial quantity was picked from a hierarchical pack type. (49765)

  • Fixed the print sequence for batch carrier labels and packing slips, which were previously sorted by internal Order ID; the system now sorts by Order Code, aligning with external printing workflows and invoice matching. (49706)

  • Resolved an inconsistency in how Job Type advanced filters were applied between manual and wave allocation, where Client and Country filter combinations correctly restricted manual allocation but failed to allocate any orders during wave allocation runs. (45091)

  • Fixed an order-of-operations error in the Pick & Sort mobile flow where a mobile cart was assigned to a job before client authorization was validated; a failed authorization check now correctly leaves the cart unassigned, preventing jobs from being locked for authorized pickers. (43871)

  • Fixed a misleading error message in the packing station that returned “Shipment Order does not exist” when a user without client access attempted to pack a serialized order; the system now returns a clear permission error instead. (41192)

  • Extended the channel-order deletion restriction to the bulk delete operation, which previously bypassed the validation that prevents deletion of orders originating from integrated sales channels. (40838)

  • Fixed an issue on the End of the Day screen where the “Print End Of The Day Report” button was incorrectly disabled when a Custom Carrier shipment group was selected; the button is now enabled for Custom Carriers, allowing warehouse managers to trigger the end-of-day manifest using the URL configured in the custom carrier setup. (50884)

  • Resolved a database deadlock issue in the billing engine to ensure Value-Added Service (VAS) calculations are completed reliably without data gaps. (50691)

  • Resolved inconsistent custom branding on the Login, Forgot Password, and Reset Password pages. The Logiwa logo no longer briefly flickers on page load, and when a customer activates Custom Branding without uploading a logo or favicon, the Logiwa defaults are now suppressed to maintain a white-label experience. (49770)


OPEN API UPDATES

  • Extended mandatory adjustment reason enforcement to the Cycle Count inventory update endpoint (/v3.1/WarehouseCountPlan/update/inventory), ensuring API-driven count approvals require a reason when the warehouse configuration mandates it. (49551)

  • Added configurable adjustment reason requirement flags to the Warehouse entity through both the Warehouse Setup UI and the Open API, to control when adjustment reasons are required for manual updates, cycle count approvals, and Excel imports. (49513)

  • Extended the Receiving History Report endpoint (/v3.1/Report/ReceivingHistory) to include PO Type, LP Type, and SKU Details Updated as filterable response fields. (49614)

  • Fixed an issue where the Count Plan creation endpoint (/v3.1/WarehouseCountPlan/create) returned a server error when the Count Plan Name exceeded the maximum character length; the API now returns a validation error. (37316)

  • Fixed an issue where the Cycle Count approval endpoint (/v3.1/WarehouseCountPlan/task/approve/count/by/sku) could generate duplicate inventory records for locations with stale inventory rows containing a receiving date. (50047)

  • Fixed an issue where the Work Order Create Kit endpoint (/v3.1/WorkOrder/create-kit) consumed component inventory from incorrect inventory lines when processing a kitting operation. (50462)

  • Added two new PATCH endpoints — /v3.1/ShipmentOrder/patch, /v3.1/ShipmentOrder/patch/bulk and /v3.1/Product/patch, /v3.1/Product/patch/bulk — enabling users to partially update shipment orders and product records without submitting a full payload. (41936, 45516)

  • Added field name mappings between the Update Shipment Order endpoints and the Get Shipment Order endpoint in the documentation. Users can now cross-check and match field names from the Get response to the corresponding fields in the Update request. (50741)

Did this answer your question?