Resolved Issues

When the Time Entry API was used to create a time activity with the parameters Billable = true and ProjectID = X (Non-Project Code), the API request failed with the following error message: 'Project' cannot be empty.

Workaround: Send the API request with the parameters Billable = false and ProjectID = X.

On the Unbilled Project Revenue Aging (EP408100) and Project Revenue Analysis (EP408200) forms, no projects were displayed in the reports even though all required conditions were met. The issue occurred because of an incorrect query used in the data selection criteria, which prevented eligible projects from appearing in the results.

Fix Description: The query logic has been corrected so that the reports display projects that meet the filtering conditions, such as active status, valid billing rules, and tasks of the cost and revenue type.

On the Customers (AR303000) form, the Open Order Balance box could display an incorrect negative value even when a customer had no open sales orders. The issue occurred in a drop-ship scenario after a sales order linked to a drop-ship purchase order was completed and its invoice was released. In this case, the Open Order Balance box on the Financial tab was not cleared, which incorrectly reduced the customer's available credit.

Workaround: To correct a customer's balance, open the Recalculate Customer Balances (AR509900) form, select the applicable financial period, select the customers with incorrect balances, and click Process.

When a user ran a report, the system applied the default report template even if the user had manually selected a different template. The parameter values saved in the default template were used to generate the report instead of the parameter values entered by the user. The issue could affect different reports, such as AP Balance by GL Account (AP632000) or AP Register (AP621500).

Workaround: Delete the default report template or create a new default template to run the report with the needed parameters.

On the System Events tab of the System Monitor (SM201530) form, numerous error messages related to the failure of the Cross Selling ML Generation automation schedule appeared even though the related feature was disabled. This behavior led to log flooding.

Workaround: Apply a special script. Contact your Acumatica support provider to receive the script and assistance with running it.

Publishing a customization project that contained form changes for Modern UI in a multi-tenant environment could take significantly longer than publishing the same changes for Classic UI. This issue occurred because the system recompiled Modern UI forms separately for each tenant.

Workaround: Decreasing the number of tenants—for example, deleting unnecessary test tenants—will improve performance.

If the Project-Specific Inventory and Manufacturing features were enabled on the Enable/Disable Features (CS100000) form, then clicking Release Materials on the Production Order Maintenance (AM201500) form generated an issue with the GL transaction that did not have the project ID specified for the detail line with the credited account, even though the materials were taken from the project.

When the user attempted to close a production order on the Close Production Orders (AM506000) form or regenerate inventory planning on the Regenerate Inventory Planning (AM505000) form, the system intermittently displayed the following error message and failed to close the production order or regenerate inventory planning:

Error: Updating 'Work Center Schedule' record raised at least one error. Please review the errors. The value must be greater than or equal to 0.

When a user released materials for a production order linked to a project that had the Allow Issue from Free Stock check box selected on the Projects (PM301000) form, the Select Materials to Release (AM300020) form did not display materials if the available quantity existed only in an alternate allowed source instead of the project’s default inventory source.

This issue occurred if:

• The project’s default inventory source was Project, but quantity was available only in free stock.
• The project's default inventory source was Free Stock, but quantity was available only in project stock.

As a result, users could not release materials from an alternate stock source even though issuing from that source was permitted.

Workaround: Manually create and release a material batch on the Materials (AM300000) form by selecting the production order and adding the required material lines with the available warehouse, location, and quantity.

The Shopify connector now supports Shopify GraphQL API version 2026-04. On the Shopify Stores (BC204000) form, the API Version box on the Connection Settings tab now displays the value 2026-04, which corresponds to the latest active Shopify API version. Error logging for the Shopify GraphQL client has been enhanced.

The following fields have been deprecated:

• InventoryItem.Variant
• Shop.billing address

The CompareQuantity and IgnoreCompareQuantity fields have been deprecated. Instead, the connector now uses the InventoryQuantityInput::ChangeFromQuantity field to retrieve data from Shopify.

This update ensures compatibility with the current Shopify API changes, including the deprecations and mutations introduced in version 2026-04.

The Amazon connector has been updated to support the Amazon Orders API v2026-01-01, which replaces the legacy Amazon Orders API v0 scheduled for deprecation by Amazon. This update affects synchronization of the following entities:

• Marketplace-Fulfilled Order
• Sales Order
• Seller-Fulfilled Refund
• Marketplace-Fulfilled Refund

On the Shopify Stores (BC201010) form in the Modern UI, when a user clicked Test Connection for a Shopify store, the system displayed the following error message: Instances cannot be resolved and nested lifetimes cannot be created from this LifetimeScope as it (or one of its parent scopes) has already been disposed. The same action worked correctly in the Classic UI.

Workaround: Switch to the Classic UI to test the connection successfully.

Fix Description: The connector uses a fresh, active context for the operation, allowing the connection test to complete successfully in the Modern UI. The fix ensures the system uses the correct internal context when running the background connection test.

When a user synchronized Shopify orders with the Tax Withheld by Marketplaces feature enabled through the Shopify connector, the system could not identify marketplace channels correctly. Marketplace channels such as Shop, Facebook, or TikTok were not discovered automatically, and the Tax Zones for Marketplace Taxes mapping table on the Shopify Stores (BC201010) form was not populated. As a result, marketplace orders were not imported with the expected tax mappings, and the synchronization failed.

Workaround: No workaround is available for this issue because it results from a change in the Shopify API behavior.

Fix Description: The system now detects marketplace orders based on tax liability information in the Shopify order data. If a tax line includes channelLiable=true, the order is recognized as originating from a marketplace channel. The connector adds the channel information to the Tax Zones for Marketplace Taxes mapping table on the Shopify Stores (BC201010) form and allows users to configure the corresponding tax zone and tax ID for proper marketplace tax synchronization.

When a user tried to shop for rates on the Shipments (SO302000) form using the UPS Ground Saver (ups_surepost_1_lb_or_greater) or FedEx Ground Economy (fedex_smartpost_parcel_select) service methods configured through the ShipEngine plug-in, the system displayed an error message: {null} to type 'System.Int32'. Path 'rate_response.rates[0].delivery_days', line 66, position 29. The issue occurred because the ShipEngine API could return null values for the delivery_days, estimated_delivery_date, or carrier_delivery_days fields when the carrier did not provide transit time information, but these fields were defined as non-nullable integers in the system model.

Fix Description: The fields delivery_days, estimated_delivery_date, and carrier_delivery_days have been changed to nullable types in the model so that the system can correctly process ShipEngine API responses that do not include transit time information.