Areej Elhusseini Mohamed

Description:

In Dynamics 365 Finance and Operations, when confirming a sales quotation, users are prompted to enter a reason code. Currently, the system allows entry of any value—even if it does not exist in the predefined reason code table. This behavior results in inconsistent data being stored, as invalid or unintended reason codes can be saved.

Expected Behavior: The system should validate the entered reason code against the master reason code table and reject any value that is not listed. This ensures data integrity and aligns with standard validation practices across other modules.

Actual Behavior: The system accepts any input as a reason code during quotation confirmation, even if it is not defined in the reason code table. This leads to potential reporting inaccuracies and undermines the purpose of having a controlled list of reason codes.

Business Impact:

• Data Integrity: Prevents invalid entries and ensures consistency across sales documents.
• Reporting Accuracy: Enables reliable reporting and analytics based on standardized reason codes.
• User Experience: Reduces confusion and minimizes manual corrections or audits.
• Process Control: Aligns with best practices for controlled data entry in enterprise systems.

Justification:

Although the issue has been classified as low impact with a possible workaround, many organizations rely heavily on reason codes for audit trails, performance analysis, and compliance. Enforcing validation at the point of entry would enhance the robustness of the sales process and reduce downstream data issues.

When changes are made at the line level of a purchase order—such as adjustments to the unit, warehouse quantity, or site—the system recalculates the line's Requested ship date and Requested receipt date based on the current system date, rather than retaining the original header date.

In this case, the customer initially created a sales order for 90 units, specifying a requested ship date of November 30, 2025 and a requested receipt date of December 1, 2025. After running Master Planning, the system generated a planned purchase order dated November 28, 2025, which aligned with the sales order requirements.

Later, the customer increased the sales order quantity to 100 units and re-ran Master Planning. The system once again generated a planned purchase order dated November 28, 2025, correctly reflecting the updated quantity.

However, after applying the Apply Actions function and firming the planned purchase order, the resulting firmed purchase order unexpectedly displayed a Requested ship date and Requested receipt date of the creation date for example October 1, 2025 .

We’re encountering an issue in Dynamics 365 Warehouse Management during the Release to Warehouse process for sales orders.

When attempting to partially release a line item (e.g., 'Quantity available': 10, 'Released quantity': 5), our standard approach is to first add the relevant sales order lines to the Release to Warehouse form. Before releasing, we manually adjust the 'Released quantity' field to reflect the required amount.

In cases where we have over 100 lines—which is quite common—we prepare the required quantities in a separate Excel sheet, sorted by Lot ID. All rows are matched 100%, and we then copy and paste the calculated 'Released quantity' values into the form.

However, despite the Lot ID sort order in Excel matching the form exactly, the pasted quantities are not being applied in the expected sequence. This results in errors such as: "Released quantity cannot be greater than 10" — even though we’ve pasted 5 for the first line.

While we understand that manual entry is possible, it becomes highly time-consuming and inefficient when dealing with such a large volume of lines.