Dynamics 365 Supply Chain Management

The "Safety Level of Invoiced Order" parameter, when locked in Company X, is inadvertently affecting the creation of intercompany (IC) orders and sales orders in Company Y. This results in orders in Company Y being locked as well, preventing necessary changes and updates.

Unable to import line in returned order for purchase by using data entity

Go to Accounts payable > ALL purchase order > Create a Return order

Use data entity to import multiple for the PO with Return oder (header) created at previous step

Expected result:

System should be able to import return order line

Issue:

Currently none of the data entity is supported to import or export Purchase return order.

Sales order processing and inquiry tiles are not updating correctly, leading to confusion in order visibility.

The issue arises from mixing up delayed orders, based on customer-requested shipping dates, with backorders, based on the confirmed delivery dates.

The only fix for this is to create a separate tile for backorder lines, though this solution is time-consuming

.

Users can currently change local settings like font size and button scale in the WHS App at any time. Some set the font size to 400%, making the app unusable, then run to IT or key users for help. This causes unnecessary support overhead and breaks UI consistency.

Request:

Add a system setting to lock or disable the local Settings menu in the app per user or device. This would enforce centrally defined settings from the “Mobile Device User Settings” in D365.

Impact:

• Less support burden
• Standardized UI across devices
• Fewer user-induced issues

During a reduction period, master planning considers sales orders that have been delivered or invoiced in the past, but it does not take into account forecast lines that lie in the past. This leads to incorrect demand calculations during the reduction period. The following example illustrates this issue more clearly:

The forecast period is set to one month, while the reduction period is configured to three months. If the forecast for the first month lies in the past, the forecasted demand for that month is no longer considered in the planning. However, sales orders that previously reduced this forecast are still active in the second month and now reduce the forecast of that month — as if the forecast for the first month had never existed.

In my opinion, forecast lines in the past that still fall within the reduction period should be considered for reduction.

After making a line change due to invalid data, the item number field loses focus when creating a new sales order line using the down arrow key, even if it is the first column in the grid.

As a workaround, we can use the Shift+Tab key combination, which allows us to move back in the row and return to the first column without having to use the mouse.

But it is very convenient to do this for every line when you have many and many lin to create for a same sales order.

Should be nice to correct this behavior.

Thanks a lot

Currently API for the price engine is based on the Commerce CSU-API, meaning customers needs to deploy the CSU-based API. This requires customers to buy the expensive commerce CSU license, which has no added value to the customer other than getting their calculated prices to an external service.

I have lost a very promising client because of this and I expect others have similar experiences, based on some comments I have read in the community.

For sales orders, there's a well-known parameter called "Update delivery date on order lines" that controls whether changes to the header delivery date should cascade to the lines. However, transfer orders do not have an equivalent out-of-the-box parameter to control this behavior.

Could you add it please?

There is a discrepancy between the system's calculation and manual calculation due to the discount being displayed with only two decimal places. This can be confusing for users who are manually calculating the net amount.

Since the system automatically rounds the discount to two decimal places, it can result in inaccurate values when manually computing the total.

In our scenario, we apply a 25% discount on an item priced at 13.26 per unit. The actual discount calculation is 13.26 * 0.25 = 3.315. However, the front-end displays this as 3.32 due to automatic rounding to two decimal places.

This rounding causes a discrepancy between the system-calculated discount and the manually computed amount, which can confuse users who try to verify the net amount manually.

Example:

System calculation: Manual Calculation:

Unit price 13.26 Unit price 13.26

Disc Amount = 3.315 Disc Amount = 3.32 (rounded off that is displayed in

the discount field)

Quantity = 12 Quantity = 12

Base Net price = Unit price * Quantity Base Net price = Unit price * Quantity

13.26 * 12 = 152.12 13.26 * 12 = 152.12

Discount net = Disc Amount * Quantity Discount net = Disc Amount * Quantity

3.315 * 12 = 39.78 3.32 * 12 = 39.84

Total net Amt = 159.12 - 39.79 = 119.34 Total net Amt = 159.12 - 39.84 = 119.28

Today, D365 doesn't permit different items in the product master to have the same UPC, but many items share UPCs, particularly for companies selling goods in the club channel, A carton that sells in a 6-pack to retail accounts can also be sold in a 9-count to club accounts. Still other retailers carry display-ready versions that contain the same carton in a tray or other bulk format. In each case, the SCC or case GTIN would be unique, but the UPC for all of those formats would be the same because the inner consumer unit is shared/not distinct. D365 needs to reflect this reality and permit the entry of shared carton/inner unit GTINs.