Dynamics 365 Supply Chain Management

When using the “Exclude canceled lines from totals” parameter in purchase orders, the system currently excludes only the purchase line amount but not the associated markups. This leads to incorrect total calculations, since markups are part of the purchase order line and should be excluded as well when that line is canceled.

This behavior creates significant issues for customers using approval workflows based on spending and signing limits, as the incorrect totals cause purchase orders to be routed to the wrong approvers or require unnecessary manual approvals. This adds extra administrative effort and delays in the procurement process.

We suggest improving the design so that when a purchase order line is canceled, both the line amount and any related markups are excluded from the totals calculation. This change would ensure accurate totals, smoother workflow automation, and better alignment with real-world business expectations.

In D365 SCM, Item substitution functionality allows Master planning to substitute a component or ingredient item on a production order. When you set up item substitution, you assign BOM or Formula lines to a specific Plan group. An item can be substituted for a different item with the same Plan group. Items within the same Plan group are assigned a priority, and the highest priority item is the item that is normally consumed.

When Master planning runs, it uses the highest priority item if it's available. If the highest priority item isn't available, Master planning looks for the next highest priority item with available inventory. If no substitute items are available, Master planning creates a planned order for the highest priority item.

I believe a relatively simply change would allow Plan group functionality to support Item supersession.

Item supersession is a scenario where a component item or ingredient is permanently superseded by a different item. In Item supersession scenarios, it is a common requirement to consume all inventory of the 'old' item before switching to the 'new' item.

If Plan group logic supported the following behaviour, it would be possible for Plan groups to support Item supersession scenarios:

When Master planning runs, it uses the highest priority item if it's available. If the highest priority item isn't available, Master planning looks for the next highest priority item with available inventory. If no substitute items are available, Master planning creates a planned order for the lowest priority item.

If Plan groups supported this logic, the 'old' item could be configured as the highest priority item, and the 'new' item could be configured as the lowest priority. This logic would also support supersession chains.... where ItemA is replaced by ItemB is replaced by ItemC etc.

Later, when inventory of the 'old' item is exhausted, a manual task for the production planners could be to update the BOMs/Formulas to remove lines for the 'old' item, and remove the Plan group settings if appropriate.

It is particularly important that this idea be addressed by Microsoft, because the relevant logic sits inside Planning Optimisation, and cannot be changed by Partners or End Users.

Hello Team,

Customer have been suggesting the below set up:

The customer is seeking best practices for configuring access so that different users can access specific features based on their business processes. Below are the details provided:

• Access Scope: Users should only have access to parts of the IVS functionality, specifically the on-hand inventory query, not the full PowerApp.
• Compliance Requirements: The customer has rules and dependencies to prevent elevated access for users without the appropriate knowledge or role.
• Business Impact of Delay: If this setup is delayed, there is a risk of users causing issues in the IVS service by having full access, as well as potential troubleshooting challenges if users cannot access the UI.

Could you please advise on the recommended best practices for implementing this setup?

Looking forward to your response.

Thank you for your support.

F&O currently has the ability to list alternative/substitution items on formulas by using the Plan group and Priority to identify the preferred item. A limitation to this functionality is that it is assumed the alternative/substitute item will have the same quantity as the preferred item it is a substitute for.

This limits functional use cases, as the assumption that the alternative/substitution item will follow the same quantity as the preferred item, is not always true. For instance, in terms of a packaging item like film, this is inventoried and tracked on formulas in terms of the weight. For films that have a different density, the weight of the material used is different.

Due to this, I am not able to reduce the number of formulas that my current company is maintaining as we need to have a formula version for each of the different film options we use as packaging for specific Finished Goods.

Another use case limitation would be in our meats. Depending on what meat item we are using in production, determines the weight of that item in our formulas.

This is the second food manufacturing company I have worked for that will have to maintain different formula versions due to the limitations of this functionality.

I believe it is fair to assume that if users are going through the additional formula line data to add a Plan group and Priority to their formula line, that they are aware they are using it for substitution purposes. I have already seen a company add a Substitutions form that is unique to each formula line to make up for this limitation.

The query responsible for calculating the summation is only triggered when the user changes the view, and not when simply opening the form, regardless of which view is set as default.

In Product information management we can setup Regional product lists of type Exclusive or Inclusive. If the list type is Exclusive, when the list is applied to a product, users are blocked from creating sales orders lines for this product to the specific country. If you try setup use the list type of Inclusive, then this allows the product to be sold into that country/region/state, but unfortunately it does not restrict sales to any other countries where you haven't also setup an Exclusive list. So in affect only the Exclusive option is useful.

Scenario - I need the ability to restrict sales of some items to only a few countries. I could setup a Regional products list of type Inclusive for those countries and link to my product, But for it to be effective I would have to also setup an Exclusive list for every other country in the world (however many there are in D365). Now if I have lots of products that can only be sold into specific countries, it quickly becomes unworkable and I have to consider a different solution or custom development. Really the solution as provided is only good when the restriction type is Exclusive, and even then the setup is not efficient.

What we need is an option to indicate a product can only be sold to specific countries, and all others are excluded without have to select every one as Excluded on the Restricted products form.

The concept of Restricted products regional lists should also be improved so we can easily create a list, of Exclusive or Inclusive type, then select which countries it applies to, then which products it applies. For now, the Restricted products regional lists feature is not very good because the user has to first create a new record on the Restricted products regional lists page for every country to be considered (with Exclusive or Inclusive list type). Then they have to link each Restricted products regional lists record (remember each record is specific to one country at a time) to each product. So it's not an efficient process.

Example scenario - I want to restrict products that can or can't be sold in the EU. I would have to setup minimum 27 records in the Regional product list form to achieve this (for each EU member country) and link each of those 27 records to every affected product. I would rather setup 1 list, link to 27 countries, then link the list to the relevant products.

Description

In intercompany setups, customers often need to map multiple external Modes of Delivery (MODs) from the buying legal entity to a single internal MOD in the selling legal entity. This is especially relevant for retail operations where franchise stores use various MODs, but fulfilment is centralised through one legal entity.

Currently, the system enforces uniqueness per external code combination in the ExtCodeValueTable. This prevents multiple external MODs from being mapped to the same internal MOD, resulting in the error:

• Cannot create a record in External code value (ExtCodeValueTable). Code: 10, Hentes. The record already exists.

The issue was raised to to the Product Group team in issue 1070641 

Idea

We’d like to suggest making it possible to map multiple external Modes of Delivery (MODs) to one internal MOD in intercompany setups. Right now, the system only allows one-to-one mapping, which causes issues when trying to simplify delivery processes across legal entities.

This change would help customers who need more flexibility, especially in retail, and would make intercompany setups easier to manage without needing workarounds.

1. Improved Order Visibility

Having the header reflect the earliest or latest delivery date gives users a single point of reference. They no longer need to check each line individually, which makes it easier for customer service teams to provide accurate delivery commitments at the order level.

2. Better Planning and Coordination

This feature would help logistics teams decide whether to consolidate shipments or split deliveries. It also makes it easier for production and procurement teams to prioritize work based on the earliest or latest required date.

3. Less Manual Work

Right now, users often have to review every line and calculate the earliest or latest date themselves. Automating this process saves time and reduces the risk of errors.

4. Improved Customer Experience

Customers would receive clearer, more reliable delivery dates for their orders. This reduces confusion around partial deliveries and helps avoid disputes.

5. Alignment with Business Practices

Many companies promise delivery based on either the earliest possible date (ship as soon as possible) or the latest date (ship complete). Reflecting this at the header level supports these common strategies.

6. Foundation for Future Enhancements

Once in place, this functionality could enable automated alerts when header dates change, integration with EDI or customer portals for accurate order status, and better reporting on KPIs like OTIF (On Time In Full).

Current Process (5 Steps):

1. Tap "Change Shipment" button
2. View Details
3. Tap Edit
4. Enter or scan new shipment number
5. Confirm

Proposed Improvement (2 Steps):

1. Tap "Change Shipment" button
2. Enter or scan new shipment number

Benefits:

• Faster Workflow: Reduces steps by 60%, saving time per operation.
• Improved Usability: Simplifies the user experience, especially for high-volume environments.

User Story:

As a warehouse worker, when I perform Inventory status change from Item inquiry, I must choose a valid “To inventory status” before submitting so that I never see a first‑attempt error and I always confirm the correct status.

Problem / Business Need:

Warehouse workers use Item inquiry → Inventory status change in the Warehouse Management mobile app (WMA). To force workers to consciously choose the correct target status every time, customers configure the menu item’s default “To inventory status” to an empty value (“”).

• With this setup, the first attempt to change status errors (“status \"\" does not exist”), the second attempt succeeds, the third fails again, and so on—alternating behavior that wastes time and confuses users.
• Not defining any default “To inventory status” is not acceptable, because the app then auto-fills a real status and the worker might proceed without verifying it—making the process error‑prone.

Proposed Solution:

Add a “Require explicit selection” mode for the target inventory status in the Inventory status change flow. When enabled:

1. The To inventory status field renders with a placeholder (no default value submitted).
2. Submit is disabled until the user picks a valid status (via list or scan).
3. The app does not reuse the previous (invalid) cached value when the user returns to the step (fixing the alternating success/failure pattern often seen in detour navigation).

.