Dynamics 365 Supply Chain Management

PURPOSE of the needed feature implementation is to:

1. Accurate Production Sequencing

The feature would ensure that SFG operations are completed before FG operations begin, aligning system behavior with real-world manufacturing logic. This is especially critical in industries like paint manufacturing, where bulk production and unpacking are tightly coupled.

2. Improved Resource Utilization

Correct sequencing allows planners to:

• Avoid resource conflicts.
• Minimize idle time.
• Optimize machine and labor usage.

This leads to better throughput and reduces operational costs.

3. Enhanced Planning Visibility

With proper Gantt chart sequencing:

• Planners can visually track dependencies between SFG and FG operations.
• Adjustments become easier and more intuitive.
• The risk of scheduling errors is reduced.

4. Reduced Manual Intervention

Currently, users must manually adjust dispatching sequences and scheduling parameters. Automating this logic would:

• Save time.
• Reduce human error.
• Improve user experience and confidence in the system.

5. Support for Industry-Specific Workflows

Paint manufacturing and similar industries rely on bulk-to-unpack transitions. This feature would:

• Make D365 F&O more adaptable to specialized workflows.
• Increase its value proposition for manufacturing clients.

6. Alignment with Best Practices

The workaround currently recommended involves:

• Dispatching sequence: SFG2 → FG → SFG1.
• Scheduling methods:
• SFG2: Forward from scheduling date.
• FG: Forward from previous job.
• SFG1: Backward from previous job.
• Avoiding “schedule/synchronize references” and “reschedule single job”.

While effective, this workaround is manual and error prone. A built-in feature would eliminate the need for such complexity.

Item Coverage values getting lost when toggle OFF and then toggle back to ON

Issue Summary:

In Data Management Export, the exported data does not match the current configuration in Dynamics 365 (D365) under Item Coverage. Specifically:

• When the Lead Time option is disabled and then re-enabled, any previously modified data entered by the customer is lost.
• The Planned Order Type reverts to default in the UI, but the exported data still shows the previous value, causing a mismatch.

Expected Behavior

The system should keep modification in Item Coverage even after disabling and re-enabling options.

Steps to Reproduce:

1. Navigate to:
2. Product information management > Products > Released products

1. Select a released product (e.g., Item D0001 in Company DEMF)
2. Go to: Plan > Coverage > Item coverage

1. On the General tab, toggle Change Planned Order Type to ON
2. Set Planned Order Type to Production
3. Save changes

1. Export the Item Coverage V2 entity

• ISPLANNEDORDERTYPEOVERRIDDEN = Yes
• PLANNEDORDERTYPE = Production
• ✅ Correctly reflects D365 configuration

1. In D365, toggle 
2. Change Planned Order Type to OFF
3. Save and refresh the screen

• UI shows Planned Order Type = Purchase Order

1. Export the Item Coverage V2 entity again

• ISPLANNEDORDERTYPEOVERRIDDEN = No
• PLANNEDORDERTYPE = Still shows "Production"
• ❌ Does not reflect current D365 configuration

1. Similar issue with 
2. Lead Time
3. :

• Enable Purchase, change time to 17, save

• Disable Purchase, refresh
• Value reverts to default (23)

• But when exporting in DFM the value shows 17

• ❌ Does not reflect current D365 configuration

Business Impact:

• Critical for customer’s demand planning: Item coverage settings drive decisions on product availability.
• Discrepancy between UI and exported data causes confusion and risk of incorrect orders.
• Override status and values should persist correctly when toggled.
• Customer relies on DMF for export/import of item coverage settings.
• Undermines confidence in system reliability.

Monetary Impact:

• Errors may lead to:
• Over/under purchasing
• Over/under production
• Incorrect transfer orders
• Consequences:
• Missed delivery commitments
• Increased operational costs
• Lost revenue due to customer dissatisfaction

Request:

Keep previously edited data in Item Coverage when toggle options to OFF and back to ON.

Benefits of Allowing Direct Registration Without Quarantine

1. Streamlined Receiving Process

Allowing direct registration bypasses the need to route items through a quarantine warehouse, which:

• Reduces the number of steps in the receiving workflow.
• Speeds up inventory availability for downstream processes like picking and shipping.
• Minimizes delays caused by misconfigured quarantine zones or missing associations.

2. Improved Warehouse Space Utilization

• Avoid unnecessary use of quarantine space for items that don’t truly require it.
• Consolidate inventory more efficiently by directly placing items in their final storage locations.

3. Enhanced Flexibility for Quality Management

The current setup enforces strict routing through quarantine zones. Relaxing this:

• Allows for more dynamic quality control strategies, such as inline inspections or post-receipt audits.
• Supports hybrid models where QC is performed at the receiving dock or staging area, as described in 2024 Supply Chain- Warehouse and Inventory management.

4. Reduced Configuration Complexity

Avoids the need to:

• Create and maintain separate quarantine warehouses and zones.
• Configure item model groups and quality associations with quarantine flags. This simplifies setup and reduces the risk of errors like the one you're encountering.

5. Cost Efficiency

By eliminating the need for additional warehouse infrastructure and reducing manual handling:

• Labor costs and operational overhead can be lowered.
• Device licensing can be optimized.

In many organizations, vendor records must undergo internal reviews (e.g., due diligence, tax ID verification, or approval from Procurement and Compliance) before they can be used in financial transactions. Currently, when a vendor is created in D365FO, it is immediately available for posting purchase orders or invoices unless manually placed on hold. This creates a risk that unverified or unapproved vendors may be used prematurely.

The requirement is to automatically place all newly created vendors on hold until they are reviewed and explicitly released by authorized personnel.

Proposed System Behavior: When a new vendor record is created in D365FO, the vendor hold status should default to “All”.

ATP and the MRP will consider the confirmed ship date - are the items available at the time of shipping. But the reservation, when you release to Warehouse, considers the confirmed receipt date, based on Transportdays and Sellable days.

This will conflict, as an Item can be OK, based on Best before date when shipping - but have exceeded Best before when it arrives at the customer.

I suggest a parameter, where you can Release to warehouse based on either Shipdate or Receivedate - That would solve the problem.

When the Default values (e.g., Automatic BOM and route consumption) are set in the General section, they are only applied to the active line (the order you are positioned on). The other selected order does not get the updated values in case of “Report as

Finished” and “Start”. If you create a new production order after this, the default values are applied correctly to the new order.

Users expect that the Default values (e.g., automatic BOM and route consumption) should apply to all selected production orders.

The system’s batch processing for “Report as Finished” does not propagate default values (e.g., automatic BOM and route consumption) to all selected production orders. Instead, it only updates the order that is currently active in the UI.

This is likely due to how the UI or underlying logic handles default value application—default values are set per active record, not per batch selection.

This may require a change in the UI logic or backend processing to iterate over all selected records and apply the chosen defaults.

After selecting multiple production orders, manually updating the default values (e.g., automatic BOM and route consumption) for each order before running the batch “Report as Finished", this ensures consistency but is time-consuming.

Currently, auto charges configured using "From amount" and "To amount" at the header level are only evaluated at the Sales Order stage, and not during Sales Quotation creation. This limitation results in charges not being automatically visible on the quotation, which can lead to discrepancies between Quote and Sales Order amounts.

Proposed Idea:

Enhance the auto charges functionality to allow tiered charges based on transaction amount ranges to be applied and visible during Sales Quotation creation, not just at the Sales Order stage.

Title: Missing TOTALDISCOUNTPERCENTAGE field in Dynamics 365 Sales order headers for Dual-write mapping

Description:

I am currently setting up Dual-write integration between Dynamics 365 Finance & Supply Chain Management (F&SCM) and Dynamics 365 Sales. During the setup, I noticed the following issue:

• The field TOTALDISCOUNTPERCENTAGE is included in the Dynamics 365 Sales quotation header entity.
• However, this same field is not included in the Dynamics 365 Sales order headers (salesorders) entity, and therefore it is not even available for mapping in Dual-write.

This creates an inconsistency between quotations and sales orders. Logically, the discount percentage should also be available on the order header, since quotations and orders share the same business process flow and similar integration requirements.

Issue:

• Field: TOTALDISCOUNTPERCENTAGE
• Exists in: Dynamics 365 Sales quotation header
• Missing from: Dynamics 365 Sales order headers (salesorders)
• Impact: Prevents mapping of header-level discounts between F&SCM and Sales for orders, which seems to be a gap in the current standard schema.

Request:

I kindly request that this field be added to Dynamics 365 Sales order headers to ensure parity with quotation headers and enable proper Dual-write mapping.

As of now, D365 F&O does not support automatic transfer of comments made during the purchase order (PO) workflow to the individual PO lines workflow. This creates a disconnect between high-level approval context and line-level execution details.

Potential Benefits of Implementing This Feature

1. Improved Traceability and Auditability

Transferring comments ensures that approver rationale and instructions are preserved at the line level. This is especially useful when:

Multiple approvers are involved.

Specific line items require justification or special handling.

Auditors or reviewers need to understand the decision-making trail.

2. Enhanced Collaboration Across Teams

Procurement, finance, and operations teams often work on different parts of the PO lifecycle. Line-level visibility into workflow comments would:

Reduce back-and-forth communication.

Clarify expectations for each line item.

Help downstream users (e.g., receiving or invoicing teams) understand context without needing to access the full workflow history.

3. Better Exception Handling

If a PO line is flagged for special treatment (e.g., expedited delivery, vendor negotiation), having the comment visible directly on the line:

Alerts the responsible team immediately.

Reduces the risk of overlooking critical instructions.

Supports faster resolution of issues.

4. Support for Custom Workflows and Automation

For organizations using Power Automate or custom workflow logic, transferring comments could:

Enable automated routing based on comment content.

Trigger conditional logic (e.g., flagging lines with specific keywords).

Improve integration with external systems or reporting tools.

5. Consistency Between Header and Line-Level Decisions

In cases where PO lines are processed or approved separately, having the original workflow comments ensures:

Decisions made at the header level are consistently applied.

Reduces misalignment between what was approved and what is executed.

The module Rebate management is 100% legal entity shared.

There are company constellations where this makes no sense at all. Even worse, it is a big security issue.

In the standard, a user from legal entity A (who has only permissions for legal entity A) can view in the rebate management module e.g. customer information and sales data / rebate transactions of customers in other legal entities.

In a company group with numerous legal entities and almost only B2B customers, this indeed can be a big issue. This "feature" of legal entity shared data can be the reason which makes the module unusable.

It would be great to have a parameter implemented in the Rebate management parameters which controlls, if the data in the module should be legal entity shared in the company group or not.