Mohamed Radwan

Issue Description:

when creating a sales order line, the SalesPrice field derives its value from the InventTableModule table. This table does not store prices based on product configurations, which results in the system always pulling the latest activated price by default.  

This behavior causes challenges for businesses that manage pricing at a more granular level, such as by specific product configurations. Unlike SalesPrice, CostPrice handling references InventItemPrice, which correctly accommodates configuration-specific details.  

Additionally the issue is also effecting work breakbench structure when retriving cost price and sales price for product varients, as has been addressed in issue 1056538 and 974989

As a result, organizations face the following issues:

• Incorrect pricing applied on sales orders when multiple configurations exist.
• Extra manual effort to update pricing on sales lines.
• Inconsistent behavior between SalesPrice and CostPrice logic, leading to confusion and additional custom development.

Proposed Idea:

Introduce an option in standard functionality for the system to pull SalesPrice values from InventItemPrice table, similar to CostPrice behavior, so that product configuration-based pricing is respected out of the box.  

Alternatively, provide a configuration parameter or feature in pricing setup that allows businesses to choose the source table (InventItemPrice vs. InventTableModule) for SalesPrice retrieval in sales documents.  

Currently, when using Electronic Reporting with the “Printer” file destination, only one copy is printed by default—even if Print Management is configured to print two copies. This limitation is causing operational inefficiencies for customers who require multiple physical copies of reports (e.g., Container Content Excel report). - This also been raised and responded to the product group team in issue number:

Proposed Idea:

Enable support for printing multiple copies directly from the “Printer” destination in Electronic Reporting, respecting the number of copies set in Print Management. This would eliminate the need for manual reprinting and improve workflow efficiency.

Currently, when auto-reservation is enabled for batch-controlled items with FEFO logic, the system automatically reserves the batch with the earliest expiry date. This behaviour is expected based on the item model group setup and reservation hierarchy.

However, in real-world scenarios, warehouse workers may need to override this reservation — for example, if the reserved batch is under inspection, not ready for use, or if there's a business reason to pick a different batch. At the moment, this override can only be done via the Finance and Operations interface, which limits flexibility and slows down warehouse operations.

✅ Proposed Idea:

Allow warehouse workers using the Warehouse Mobile App (WMA) to remove the system-generated FEFO reservation and manually assign a different batch directly from the app. This would give frontline users more control, reduce dependency on back-office intervention, and improve responsiveness in time-sensitive situations.

Issue Description

Currently, when configuring Quality Associations using the “Goods in Transit” reference type, the system does not allow selecting the “Create work only” option. This limitation prevents users from generating work directly from the quality association, which is a key requirement for certain warehouse processes.

this configuration is officially supported only for the Purchase and Production reference types, as per current documentation.

Suggested Idea

Extend support for the “Create work only” option in Quality Associations to include the “Goods in Transit” reference type. This would align its behaviour with other supported types like Purchase and Production, and allow users to initiate work directly from quality associations for in-transit goods.

This enhancement would improve process consistency, reduce manual workarounds, and support more advanced warehouse quality management scenarios.

Issue Description

In the current setup of the “Automatic release of sales orders” functionality, when the release fails, the inventory reservation is not rolled back—even when the parameter “Keep reservation on release failure” is set to No. This behaviour is unexpected from a business perspective and causes operational challenges.

The issue was raised under 1064971 and 227564. The Product Group feedback that the system is working as intended,

It appears that the reason behind the feature limitation here is because In the current setup, users can configure the “Release rule failure option for auto release” to behave in two ways:

• Warn and skip line: The system retains the reservation and skips the affected line.
• Error and skip order: The system removes the reservation and skips all lines in the order.

Proposed Idea

Enhance the “Automatic release of sales orders” functionality to ensure that inventory reservations are always rolled back when release fails—if the “Keep reservation on release failure” parameter is set to No, regardless of fulfilment policy usage.

This change would:

• Align system behaviour with user expectations.
• Prevent inventory from being locked unnecessarily.
• Reduce manual intervention and improve operational efficiency.
• Increase trust in system configuration and documentation.

Description

In intercompany setups, customers often need to map multiple external Modes of Delivery (MODs) from the buying legal entity to a single internal MOD in the selling legal entity. This is especially relevant for retail operations where franchise stores use various MODs, but fulfilment is centralised through one legal entity.

Currently, the system enforces uniqueness per external code combination in the ExtCodeValueTable. This prevents multiple external MODs from being mapped to the same internal MOD, resulting in the error:

• Cannot create a record in External code value (ExtCodeValueTable). Code: 10, Hentes. The record already exists.

The issue was raised to to the Product Group team in issue 1070641 

Idea

We’d like to suggest making it possible to map multiple external Modes of Delivery (MODs) to one internal MOD in intercompany setups. Right now, the system only allows one-to-one mapping, which causes issues when trying to simplify delivery processes across legal entities.

This change would help customers who need more flexibility, especially in retail, and would make intercompany setups easier to manage without needing workarounds.

Description

When using Movement by Template on the warehouse scanner, the system requests a Target License Plate if the source is a parent license plate. This behaviour adds unnecessary steps.

Proposed Idea

Enhance the Movement by Template functionality so that when a parent license plate is moved, the entire license plate (including child LPs) is transferred without prompting for a Target License Plate.