Dynamics 365 Supply Chain Management

When going to the replacement order creation if the product has no transactions in the system / legal entity, it does not appear in the "all items" tab, even if the product is released on that legal entity.

This is an issue, for example, for new Go Lives when we need to create a replacement for an order created in a previous system

As is: when Generate statistical baseline forecast, the results displays in the global table Adjusted demand forecast. This means that if a customer has multiple legal entities that they will need to plan their forecast as a whole. Which in real life is usually not the case.

And becasue the forecast results sit in the global table, every time you run the job "Generate statistical baseline forecast", it changes for all legal entities.

To be: should be able to generate statistical baseline forecast for each legal entity and they can play with their own data without worrying about overriding eachothers'.

Hi,

Dynamics determines delivery dates for sales order lines based on the requested or confirmed shipping date.

If there is a confirmed date, Dynamics use the confirmed date.

New sales order lines are usually unconfirmed, so does only have a requested date when calculation a delivery date.

With the new planning optimization, all sales order lines are considered, requested and confirmed. All lines with only a requested date get a confirmed date - the earlies possible date. The issue is, that dynamics does not differentiate between requested and confirmed dates. There should be a parameter where you can decide to prefer confirmed dates over requested dates.It would be great if it were possible to define a period in which confirmed lines win over requested lines.

Thanks,

Benjamin

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.

Currently, when a user starts a job and then declares an indirect activity (e.g., attending a meeting), the job is interrupted, and feedback is prompted. Once the indirect activity ends, the original job is no longer immediately accessible or resumable. This forces users to manually search for and restart the job, which introduces delays and inefficiencies.

Implementing the feature would:

• Eliminate manual job tracking, reducing reliance on pen-and-paper workarounds.
• Enable automatic job resumption, allowing users to return to their previous task seamlessly.
• Reduce downtime between activities, improving overall throughput in warehouse operations.
• Businesses could see faster order fulfillment.
• Labor utilization would improve.
• Support costs might decrease due to fewer user errors and escalations.

This consistency would:

• Simplify training for new users.
• Encourage adoption of the new blue screen interface.
• Avoid system waiting states, which currently occur between stopping and restarting jobs.

Currently, when a Product Group acknowledges a bug and confirms that no ETA is available, the LCS issue is marked as "Resolved" even though the underlying issue is not actually fixed. This causes confusion and frustration for customers, as the "Follow" option is no longer available once the status is marked as resolved.

I suggest adding a distinct status for such cases (for example, "Acknowledged – Fix Pending") and keeping the "Follow" functionality active until the issue is fully fixed and deployed. This would give customers clear visibility that Microsoft is still working on the problem and allow them to continue tracking progress automatically, avoiding the impression that the issue is closed prematurely.

Currently, the “Archive with Dataverse long-term retention” feature in Dynamics 365 Supply Chain Management archives all sales orders that match the filter criteria provided by the user (e.g., date range, legal entity). There is no built-in way to automatically exclude intercompany sales orders.

In some environments, like the customer’s, nearly all sales orders are intercompany orders. As a result, running an archive job could inadvertently archive records that are part of intercompany chains, which can break transactional relationships across legal entities.

Proposed Idea:

Introduce an option in the archive job to exclude intercompany sales orders automatically or provide a dedicated filter/flag that identifies intercompany orders, so admins can safely archive non-intercompany sales orders without risking data integrity.

This enhancement would align the system behavior with the documented guidance that intercompany orders should not be archived, making the feature safer and more flexible for customers with a high volume of intercompany transactions.

We have engaged extensively with Microsoft over the last few months in an effort to understand and conquer some of the substantial performance issues we have been experiencing.

One of the things to come out of our journey is that the DAMS utility that sits behind D365 carrying out automated maintenance tasks (new indexes, optimising indexes / query plans) is extremely opaque.

It would be very helpful if:

1. Output of its activity (both successful and unsuccessful) was available for inspection
2. The parameters that are integral to DAMS routines kicking off were made available so we could have better understanding of the process.
3. The parameters are not blanket set across an environment. There should be flexibility to change these values per table / index. Even if this action is not available to the end user, it should be readily accessible by a mechanism such as logging a support ticket.

Currently, when a Contact is added to a Sales Quotation, the system does not display the Contact’s details (e.g., phone number, email, job title) directly on the quotation header or form. Customers expect that when a Contact is selected, the relevant details should be visible to improve usability and reduce manual lookups.

Proposed Enhancement:

When a Contact is linked to a Sales Quotation, the system should automatically display the Contact’s key information when hovering over the Contact (Email, and phone) in the Sales Quotation form.

I have recently tried to use Explosion reservation on Sales orders in a company that uses Planning Optimization and was surprised to find that it is incompatible, despite not being reported by the Planning optimization fit analysis.

The Learn page only reports it as Future wave.

This is important functionality that is not covered by Delivery Date Control and leaves us with only the options of Automatic or Manual reservations on Sales orders.