Mohamed Radwan

ISSUE

The Load planning workbench page has been split Inbound load planning workbench and Outbound load planning workbench. the new Outbound load Planning Workbench design, sales order lines are no longer broken down by inventory dimensions. This was changed to improve overall performance, as breaking down by inventory dimension required caused performance degradation in the previous design.

However, some customers rely on seeing inventory dimension details at the sales order line level. Without this breakdown, it becomes an issue to manage complex orders and scenarios that require inventory dimension-level detail in the Load Planning Workbench.

This has been raised to product group team to be addressed in issue number 825871 as a system limitation that If the specific case or scenario requires showing of inventory transactions and at the same time, the amount of order lines does not cause performance issues with this, then the can create a customization on the new form to break down the grid by inventory dimensions.

SUGGESTED IDEA

• Provide an optional feature or parameter in the Load Planning Workbench that, when enabled, displays and allows planning by inventory dimensions at the sales order line level. 
• This option would be disabled by default for general use cases to preserve performance.  
• When enabled, the system would reintroduce dimension breakdown in the grid, with the necessary queries and filtering, allowing customers who need dimension-level visibility to access it without managing a custom build.

#Summary:

Reduce the number of clicks and pop-ups required to delete sales orders in the Sales and Marketing module, while still preserving an option for batch processing and safe data handling.Summary:

Reduce the number of clicks and pop-ups required to delete sales orders in the Sales and Marketing module, while still preserving an option for batch processing and safe data handling.

#Description:

Currently, the process for deleting sales orders in Sales and Marketing → Period tasks → Cleanup → Delete sales orders involves several steps:

1. Selecting the relevant sales order(s) based on search criteria or filters.  
2. Clicking “Batch” and enabling batch processing.  
3. Clicking “Confirm deletion.”  
4. Responding to an additional pop-up confirmation.

This multiple-step approach can be time-consuming, especially for users performing frequent or large-scale cleanups.

#Proposed Idea:

• Combine the “Batch” and “Confirm deletion” steps into a single prompt that clearly explains the potential impact of deleting the selected sales orders.  
• Where an extra confirmation pop-up exists, consider merging it into this single prompt or making it optional, based on user or administrator preferences.

#Summary:

Reduce the number of clicks and pop-ups required to delete sales orders in the Sales and Marketing module, while still preserving an option for batch processing and safe data handling.

#Description:

Currently, the process for deleting sales orders in Sales and Marketing → Period tasks → Cleanup → Delete sales orders involves several steps:

1. Selecting the relevant sales order(s) based on search criteria or filters.  
2. Clicking “Batch” and enabling batch processing.  
3. Clicking “Confirm deletion.”  
4. Responding to an additional pop-up confirmation.

This multiple-step approach can be time-consuming, especially for users performing frequent or large-scale cleanups.

#Proposed Idea:

• Combine the “Batch” and “Confirm deletion” steps into a single prompt that clearly explains the potential impact of deleting the selected sales orders.  
• Where an extra confirmation pop-up exists, consider merging it into this single prompt or making it optional, based on user or administrator preferences.

────────────────────────────────────────────────────────

ENGLISH VERSION

────────────────────────────────────────────────────────

DESCRIPTION  

In a direct delivery scenario, once the intercompany order has been delivered, the original sales order’s Confirmed ship and receipt dates are removed and the fields become grayed out. This issue is tracked under LCS 1034919, where the Product Group determined it requires a significant design change and will not be fixed at this time.

IDEA  

Enable the intercompany original sales order to retain and synchronize its Confirmed ship and receipt dates—even after delivery—so that dates remain accurate and editable. This is especially critical in markets like Italy that enforce a strict chronological number sequence and rely on consistent date information across all intercompany transactions.

────────────────────────────────────────────────────────

ITALIAN VERSION

────────────────────────────────────────────────────────

DESCRIZIONE  

Nel caso di consegna diretta (direct delivery), una volta che l’ordine intercompany è consegnato, le date di spedizione e ricevimento confermate dell’ordine di vendita originale vengono rimosse e i campi risultano disabilitati. Questo problema è registrato con il numero LCS 1034919, per il quale il Product Group ha stabilito che necessita di una modifica progettuale importante e non verrà risolto al momento.

IDEA  

Abilitare la conservazione e la sincronizzazione delle date di spedizione e ricevimento confermate nell’ordine di vendita intercompany originale, anche dopo la consegna, così da mantenere le date corrette e modificabili. Ciò è particolarmente importante nei mercati come l’Italia, in cui esiste l’obbligo di garantire una numerazione cronologica rigorosa e di mantenere coerenza delle informazioni sulle date in tutte le transazioni intercompany.

Description:

When changing the “requested ship date” on individual sales order lines, no prompt appears in the system to warn or confirm that these changes may affect item pricing. Currently, the “Update ship and receipt date” functionality only triggers at the header level of the sales order. This behavior can be especially impractical for businesses managing large orders with extensive line items, where each line may need different ship and receipt dates.

This has been addressed by the product group team in issue number 1035364 that the system functioning as intended and raise an idea to track the progress.

Proposed Idea:

Enhance the existing functionality so that whenever a “requested ship date” is altered at the line level, a prompt (or similar user confirmation mechanism) is displayed. This prompt would alert the user that pricing or other relevant calculations may be impacted by the change, allowing them to confirm or revise before finalizing. This improvement would help ensure consistency, reduce errors, and streamline the user experience for organizations working with complex or large sales orders.

Description of the Issue:

When approving a price-based, invoice-attached deduction from the Deduction Workbench, the Item Sales Tax Group is not populated on the resulting free text invoice—only the Sales Tax Group is. This occurs specifically when an invoice is attached during deduction creation and does not happen if no invoice is attached. 

According to feedback on issue 1036561, the underlying reason is that Free Text Invoices are not inherently tied to the item-level data that Sales Orders use. Therefore, attaching an invoice during deduction creation does not carry over the item tax metadata to the Free Text Invoice. The deduction logic treats this scenario as a financial claim, not a product or item-based transaction, so it bypasses Item Sales Tax Group population.

Idea:

It would be valuable to reintroduce or provide the capability to select and maintain the Item Sales Tax Group on the Free Text Invoice even when an invoice is attached during the deduction approval process. This could be implemented as a dropdown or selection option that becomes available (or remains available) in the deduction approval process, ensuring the Item Sales Tax Group is not lost and avoid manual entry of the sales tax group.

Issue Description:

When changing the currency at the header level for a sale order with a Sales Agreement linked via Product Value Commitments, the system will removes the link to the Sales Agreement and retains the discount. Afterward, it is not possible to re-establish the link to the Sales Agreement. In comparison, Product Quantity Commitments are unaffected by a currency change because they are based on units, not monetary value. The current behavior seems to be a design limitation in how Product Value Commitments handle currency changes as per product group feedback on issue number 1037192.

Idea:

Provide an option or enhancement to retain the Sales Agreement link even if the currency changes, or allow re-linking the order to the Sales Agreement after the currency change. This enhancement would accommodate real-world scenarios where exchanging the currency or making corrections should not permanently invalidate the monetary commitments in the system.

After checking out items from a PunchOut site, an error occurs if the items do not include a unit price. In Issue #1039223, the product group determined this behavior is currently by design: the external vendor’s catalog is expected to provide a valid item price when returning the cart. If the external system does not supply a price, the checkout process fails with error Failed to parse cXML with exception Object reference not set to an instance of an object.

Idea:

Implement a mechanism that gracefully handles missing or null unit prices during the PunchOut checkout process. This could involve:  

• Setting a default or placeholder price when a null value is returned.  
• Prompting users to manually input a price if none is provided by the external vendor.  
• Providing an informative error message or validation step to ensure a better user experience.  

Enhance the standard Purchase Requisition workflow in Dynamics, which currently has “Draft,” “In Review,” and “Approved” stages, by adding an intermediate “In Approval” stage. This new stage would provide clearer visibility into the exact phase of the workflow, distinguishing requests that are under review from those awaiting final approval.

Idea:  

Implement an additional status called “In Approval” after “In Review.” This distinct stage will help users quickly identify whether a PR is still being evaluated or has moved on to final sign-off. It would reduce the need for manual checks in workflow history, offering better transparency for teams involved in the purchase process.