Dynamics 365 Supply Chain Management

Licenseplate label (re-)printing from production floor execution:

When printing a license plate label from PFE we would like to use the default label printers functionality.

We would also like to use the change printer functionality, because when a label was originally printed via PFE on a label printer then we should have the possibility to do a reprint from the newly selected printer. In the current situation this is not possible and the label will be printed on the original printer.

Proposed solution: Add a resource to printer mapping to support PFE use cases

In D365 F&O DDMRP Functionality – Planned Orders not getting generated for Full Coverage Time Fence. Instead, a single planned order is getting generated for the current time period only.

Actual Result

Only 1 Planned purchase order is generated instead of 12 different Planned purchase orders for the respective Coverage time fence of 12 months (365 days).

Expected Result

The generation of 12 separate Planned purchase orders corresponding to the setup Coverage time fence of (365 days) 12 months.

Business Need:

Currently, users can only update the "Delivery remainder" field on purchase order lines manually, one line at a time, using the "Update remaining quantity" option. There is no way to mass update this field across multiple POs using Data Management Framework (DMF) or any standard bulk process.

Impact:

For organizations that manage a large number of purchase orders, the inability to update “Delivery remainder” in bulk results in significant manual effort, increased risk of errors, and inefficiency. A standard mass update capability would streamline business processes and improve user productivity.

Request:

Please consider enabling the ability to mass update the “Delivery remainder” field on purchase order lines, either by:

• Allowing direct update of this field through the DMF “Purchase order lines” entity
• or
• Providing a standard bulk update feature (e.g., via periodic task, batch job, or additional workspace option)

Comments:

This feature would be especially valuable for large organizations or those with complex purchasing workflows. Community voting and additional use cases can be added to this idea.

Requirement not supported by system i.e.

Using D365FinOps SCM v43

Warehouse storage locations are non-LPN tracked

Batch tracked ITEM (batch below location) with unit conversion setup (Ea-Box-PL)

Sales order line is created with Qty (box as UOM)

Upon release to warehouse - I am expecting system to create single Work ID per PL qty however I am unable to get this behavior through OOTB - Work template setup.

I tried breaking down Work by -

Temporary work transaction = highest unit but it didn't work as work is not split by one PLT

Temporary work transaction = Packing Qty but it didn't work as work is not split by one PLT

Please note - config setup where Location directive (restrict by unit) and then using Directive unit in Work template does help splitting work ID by PLT however this approach has a gap, it ignores picking stock based off oldest Batch ID (expiry date) and always gives preference to location with full pallet (thus picking stock (oldest batch id) from location (less than a pallet) are skipped by system.

I am expecting system to always pick from oldest batch ID first (no matter if it is less than a pallet) but always creating Work ID header separated by one full pallet. (its okay to have multiple pick lines as far as Work header = 1 full pallet)

When utilizing production floor execution, limited visibility exists as to what the BOM / Formula along with what needs to be produced when co-products exist. Currently users must hover over the order number to view the details, which is insufficient for operators out on the shop floor. Adding two new options to production floor execution for users to launch the BOM / Formula and the Co-Product transactions would address the consistently requested feedback we here from users as they interact with the production execution tool in D365.

Many companies have requirements for step-by-step scrap of BOM usage: different production quantities may have different variable scrap;

There are currently two ways to implement this:

1. Create BOM versions with different starting quantities, and set different variable scrap for each version of the BOM line;

2. Add a new subsidiary line with the formula as "step" to the BOM line, and specify the scrap value corresponding to different production quantity intervals;

Method 1 results in the existence of many BOMs, which is difficult to maintain;

Method 2 results in the existence of many BOM lines. When running MRP according to demand, the number of demand lines increases, and the number of related operations such as production material collection also increases;

Suggestion: Microsoft officially merges the logic of the formula as "step" into the logic of the formula as "standard".

When you add a new task to the job, as you cannot give that task different criteria, as it retains the original task criteria.

When you deal with various operations that works with batch job on the recurrence part, we need the recurring batch jobs with different sets of parameters to use this single batch class. But for example, the base batch class of InventTransferMultiReceive that we tested, the parameters do not hold with multiple batch jobs.

As you can see this was already submitted but it worth to take a second look.

Issue 940513

When we want to determine the safety stock level for configured products, we go to the product information management-products - released products page. When the batch number field is added with the column add in the item coverage area of ​​the planning tab for configured products, nothing can be entered in that field. We think this is a system bug. While we can enter a value in the item coverage area for unconfigured products, we cannot determine the safety stock level because we cannot enter an item coverage value for configured products.

Title: 

Improve Overview Costing Accuracy After Changing Indirect Cost Rate for Production Orders

Description:

an issue in Dynamics 365 Finance and Operations where the overview costing becomes incorrect after changing the indirect cost rate for production orders. This issue has been acknowledged by the D365 Product group engineers and marked as "by design" (Issue 793402). The problem arises because the system recalculates costs based on the most recent price during inventory closing, and it is unable to distinguish the actual price used at the exact historical time point.

Problem:

When the indirect cost rate for production orders is changed, the overview costing does not reflect the accurate costs. This discrepancy can lead to incorrect financial reporting and decision-making, as the recalculated costs do not match the historical prices used at the time of production.

Remarks:

The current design recalculates costs based on the most recent price during inventory closing, which does not account for the actual price used at the historical time point. This limitation affects the accuracy of cost reporting and can cause confusion for users relying on precise cost data.

Proposed Solution:

propose an enhancement to the costing mechanism in Dynamics 365 Finance and Operations to ensure that the overview costing accurately reflects the historical prices used at the time of production. This could involve storing and referencing the actual prices used at specific historical points, rather than relying solely on the most recent price during inventory closing.

Benefits:

• Improved accuracy in cost reporting
• Enhanced financial decision-making based on precise cost data
• Reduced confusion and errors in financial statements

Based on LCS issue 840630. When creating a new return order, we want to be able to modify the unit price or add a discount to the return order line. This when using the 'find sales order' function.