Dynamics 365 Supply Chain Management

Hello,

currently when reporting scraps in production floor execution, we can only select the cause from a predefined list of values which are:

• None,
• Material,
• Machine,
• Operator.

I think it would be interesting to be able to set up this list with user defined values.

https://learn.microsoft.com/en-us/dynamics365/supply-chain/production-control/production-floor-execution-use#reporting-scrap

If a user starts production order from all production orders and then start it again from PFE, quantities reported in BOM journal will be doubled.

PFE will show that the quantity specified for the route operations is zero, even if they are displayed in BOM in the production order form.

This leads to discrepancy in cost valuation for quantities and machinery and will also cause variance between estimated and reported quantities.

Currently, For entities that have already transitioned from MRP to Planning Optimization, there are still some features that have not yet been implemented in Planning Optimization. Therefore, MRP remains usable for those entities/customers. Customer can either choose to use MRP or Planning Optimization from this point.

However, almost all parts of old Master Planning has been optimized/implemented within Planning Optimization and product group is encouraging customer to use this new algorithm. Subsequently some entities are blocked to go back to old MRP.

My request is to gather votes from community to accelerate transition progress from classic MRP to Planning Optimization as soon as possible in near future so that our customer have the best experience using this add-in.

If a unit from the unit of measure table and a corresponding unit conversion is removed from D365, a warning message appears next time Planning optimization is executed, saying “Could not find unit of measure with id ********”. That does only happen if the unit and unit conversion we're processed before in at least one Planning optimization run. This warning message can cause confusion, as the missing unit of measure is no longer used. Planning optimization should therefore only process those units of measure and unit conversions that still actually exist in the unit of measuretable.

When you released a purchase order from a purchase agreement with the max is enforced slider to yes, the PO is automatically link to the related purchase agreement. If you modify the quantity, the link is then broken with the purchase agreement. If you re-modify the quanitty and bring it within the allowed quantity, the link is recreated and the purchase agreement is reattached to the PO. But, once the link is broken, the fulfillment is not updating anymore even tough the purchase agreement and the PO are connected to one another.

The idea is that the link needs to be recreated and the update has to be there. Now, if you broke the link and reattached it, the updates are not happening. That causes problem because the contract you have with the vendor is not updating and so is not true anymore. It needs to keep updating so the contract stays relevant.

Issue: if a preferred vendor is changed in the system, the underlying data has to be changed manually.

The data for example, are content per drum, unit conversions, quantity per box/pallet, lead time etc.

Users currently have to transfer this data to an offline spreadsheet to support changing he preferred vendor. This is a very frustrating and non-value added effort, with an additional risk of mistakes when transferring data.

Preferred solution: Maintain the data in a table that can be used to transfer to the new vendor without having to manually key all of the supporting data for the item.

For Sale Order when setting filter for net price field with zero price. After that we have created an alert for field: Net amount - is set to 0.00.

When new line with zero price is created, no alert is created. The alert rule only works if there is a price set, and the price is not set to zero.

Expected Behavior:( Setting Rule for any fields with Zero and receive alert / Notification once the rule is active)

When clicking the "New" button, if the current view the user was on had any filters or sorts, they would be removed.

This problem occurs on certain list pages, such as all purchase orders, all transfer orders, and vendors list, but not on other pages like all sales orders or production orders.

I suggest to keep the filters and sorts of the saved view when creating a new purchase order.

Dear all,

i would like to suggest, that the requested ship and receipt date in the purchase order line is calculated correctly, while using the standard direct delivery function. The business scenario requires, that the feature "Supplier requested and confirmed shipment dates" is activated and the procurement and sourcing parameter "Calculate purchase order delivery date based on lead time and working days" are collaborating correctly. Both in combination unfortunately lead to a miscalculation of the requested ship and receipt date, whenever a purchase order with an active purchase agreement is created out of the direct delivery function.

Short version of the current issue (a more detailed one can be found below):

Requested ship date and requested receipt date is calculated differently in head and line details of a purchase order, which is created by a direct delivery process. The requested receipt date will be postponed by the supplier into the feature, which shouldn't be possible. It only appears, if there is an effective purchase agreement for the supplier, purchase transport days is defined between supplier and customer and procurement and sourcing parameter "Calculate purchase order delivery date based on lead time and working days" is activated. 

Detailed Version with an case study:

We are looking at a direct delivery process between a supplier, which is located in Italy, and a customer/receiver, who is located in Germany. For international delivery we have set up purchase transport days to define the time of transport of goods between supplier and customer (e.g., 7 Days from Italy to Germany). Additionally, we have an effective purchase agreement for the supplier with a lead time of 0.

Now we starting the direct delivery process by creating a sales order, choosing the correct product (which is included in the purchase agreement), and using the direct delivery function in the action pane. In the sales order we are setting the requested ship date and the requested receipt date to 15.04.2024. We are using the supplier in Italy and activate the "Search for purchase agreements" button and as a result a purchase order is being created. With the new feature we would expect, that the requested ship date will be calculated backwards by 7 days to ensure a requested receipt date of 15.04.2024. While the header in the purchase order has calculated the requested ship date correctly to 08.04.2024, the date information in the line details are incorrect. Here, the requested ship date is set to the initial 15.04.24 and the receipt date has been calculated to 22.04.24. In our opinion the requested receipt date shouldn't be able to be changed by the supplier and there is inconsistent data between header and line details. 

After troubleshooting the incident and debugging with our developer we have figured out, that the calculation of requested ship/receipt date in the line details is influenced by a parameter of procurement and sourcing. When the parameter "Calculate purchase order delivery date based on lead time and working days" is activated, the issue described above is occurring. Being deactivated and repeating the same procedure again, the requested and receipt date are calculated correctly in the head and in the line details. 

Consequently this means, that the customer will receive their products with a big delay, only because the requested ship date is set to the feature instead of to the past. To avoid this issue, the new feature and the parameter should corrabolate smoothly, so the requested receipt date is not postponed by the supplier.

Dear everyone,

i would like to suggest, that the requested ship and receipt date in the purchase order line is calculated correctly, while using the standard direct delivery function. The business scenario requires, that the feature "Supplier requested and confirmed shipment dates" is activated and the procurement and sourcing parameter "Calculate purchase order delivery date based on lead time and working days" are collaborating correctly. Both in combination unfortunately lead to a miscalculation of the requested ship and receipt date, whenever a purchase order with an active purchase agreement is created out of the direct delivery function.

Short version of the current issue (a more detailed one can be found below):

Requested ship date and requested receipt date is calculated differently in head and line details of a purchase order, which is created by a direct delivery process. The requested receipt date will be postponed by the supplier into the feature, which shouldn't be possible. It only appears, if there is an effective purchase agreement for the supplier, purchase transport days is defined between supplier and customer and procurement and sourcing parameter "Calculate purchase order delivery date based on lead time and working days" is activated. 

Detailed Version with an case study:

We are looking at a direct delivery process between a supplier, which is located in Italy, and a customer/receiver, who is located in Germany. For international delivery we have set up purchase transport days to define the time of transport of goods between supplier and customer (e.g., 7 Days from Italy to Germany). Additionally, we have an effective purchase agreement for the supplier with a lead time of 0.

Now we starting the direct delivery process by creating a sales order, choosing the correct product (which is included in the purchase agreement), and using the direct delivery function in the action pane. In the sales order we are setting the requested ship date and the requested receipt date to 15.04.2024. We are using the supplier in Italy and activate the "Search for purchase agreements" button and as a result a purchase order is being created. With the new feature we would expect, that the requested ship date will be calculated backwards by 7 days to ensure a requested receipt date of 15.04.2024. While the header in the purchase order has calculated the requested ship date correctly to 08.04.2024, the date information in the line details are incorrect. Here, the requested ship date is set to the initial 15.04.24 and the receipt date has been calculated to 22.04.24. In our opinion the requested receipt date shouldn't be able to be changed by the supplier and there is inconsistent data between header and line details. 

After troubleshooting the incident and debugging with our developer we have figured out, that the calculation of requested ship/receipt date in the line details is influenced by a parameter of procurement and sourcing. When the parameter "Calculate purchase order delivery date based on lead time and working days" is activated, the issue described above is occurring. Being deactivated and repeating the same procedure again, the requested and receipt date are calculated correctly in the head and in the line details. 

Consequently this means, that the customer will receive their products with a big delay, only because the requested ship date is set to the feature instead of to the past. To avoid this issue, the new feature and the parameter should corrabolate smoothly, so the requested receipt date is not postponed by the supplier.