Chen Wang

Some warehouses store the same items, and there are cases where one warehouse holds higher inventory with more on-hand days compared to others. Whether future CoPilot features will be able to suggest or even assist in moving inventory with higher on-hand days to a warehouse with lower on-hand quantity and days, ultimately improving efficiency and reducing the average on-hand days across warehouses.

When posting a purchase order with price and charge differences compared to the base price and charge settings for the item, there should be a specific place or account set up to log these differences for each order. This allows the management team to compare each order against the set baseline and conduct a year-end review accordingly.

When the user adds items with different serial numbers (serial number-controlled items) to a production order—especially if these items have been returned to the manufacturer for repair or refurbishment—the production order may involve various layout costs or additional charges. Currently, the system allows applying only one unique cost to a single item within a production order, and this cost applies only to that item. The user is seeking a future feature or improvement that would enable:

• The ability to apply different costs (e.g., layout costs, additional charges) to each item within a single production order.
• The option for each item in the production order to have its own final cost, including item-specific and labor costs.

The goal is to allow multiple lines in a single production order to have different cost amounts, resulting in each item having its own calculated final cost.

When using the hover feature for the CoPilot summary, the access level for the summary, which can be pulled out, should have the ability to be modified by an admin user. Currently, the access level is based on the table level, and there is information, such as sales and purchase prices, that not all users should be able to see in the summary. It’s recommended that the CoPilot summary feature has a separate access level control based on individual users, allowing more granular management of what information is visible to specific users.

When the user is setting up the pick work and selects the load ID as the system grouping, it is because they want to control the process by the load ID. In the current configuration, when determining how the warehouse worker is directed, the system grouping field is the only available option. This is the standard design as of now, where the system decides the workflow for the warehouse worker.

However, the warehouse workers may have their own preferences regarding which load they want to process first. If the setup is changed to allow user direction, the system grouping field becomes unavailable. The user is inquiring whether, in future updates, the system will provide the ability to retain the system grouping field setup while still allowing workers the flexibility to choose their own workflow. This would add flexibility and align better with real-world warehouse working scenarios.

Currently, in the design of production orders, when different financial dimensions are set for both the BOM item and the finished good, the system automatically overrides the financial dimension of the BOM item to match the primary item (finished good). If the user wants to use separate financial dimensions for these, they must manually adjust the dimensions before the estimation stage.

If the user forgets to make these changes, it can lead to discrepancies at the financial level and within the production order setup. This results in a mismatch between the financial dimension set up for the items and the actual postings for the BOM item, potentially causing misleading financial information.



To address this, it is suggested to introduce functionality that allows users to decide whether the primary financial dimension should override the secondary financial dimension. This feature would enable users to maintain separate financial dimensions for primary and secondary items when needed, offering greater flexibility and control over their financial setups.

It is proposed to add a "Delete All Planned Orders" functionality to Planning Optimization, similar to the feature available in the old MRP. This enhancement would address business scenarios where users create planned orders for one item and subsequently need to generate new planned orders for another item.

Currently, users must manually select and delete the old planned orders, which is time-consuming, particularly when dealing with a large volume of planned orders. Additionally, manual deletions may increase the risk of conflicts or errors in situations where no relationships exist between the planned orders.

The old MRP's "Delete All Planned Orders" feature was highly efficient and time-saving in such scenarios. Bringing this functionality to Planning Optimization would provide users with a practical and streamlined solution, reducing manual effort and improving overall efficiency.

Currently, when generating a sales order confirmation, the system query only includes sales order lines with an open status (SalesStatus = 1). This behavior aligns with the standard design logic. However, this can cause issues when users want to share the confirmation with end customers, as it may result in misleading information. Lines with statuses such as "delivered" or "invoiced" are excluded from the confirmation, which can lead to confusion.

To address this, it is recommended to introduce a new functionality that allows users to include all sales order lines, regardless of their status, when generating the sales order confirmation. OR Allow users to print all sales order lines, regardless of status, for external reference or sharing purposes.