Dynamics 365 Supply Chain Management

Below issue is dicsussed as high prio with Microsoft and it was forwarded after several discussions to the idea portal.

During production report as finished it is possibile to scan a quantiy with more then 15 digits and with some specific item cost resulting in a extensive inventory transaction. This amount of this transaction is to big for the system to calculate. This resulting in a imbalance of the general ledger. The system creates an debit transaction different then the credit transaction. which causes the imbalance.

This imbalance of the general ledger resulting in a corrupt general ledger which can not be fixed by Microsoft. Resulting in the only solution to execute a restore back in time on a go live environment. This to make sure that the system integrity is

Our proposal is that all transactions causing an inventory imbalance should be avoided at all possibile ways. Meaning a blocking error should be triggered in cases an imbalance is occuring.

It's a common practice for the maintenance engineer to capture and attach images of the asset to the work orders as evidence of certain actions.

Right now, it's only possible to view attached images on the app with no option to create a new attachment, it would be great to add such an option like what we currently have in the maintenance request.

Currently, warehouse workers can initiate the putaway process on clusters that are still in an 'Open' status without closing them first. This leads to a recurring issue where clusters remain locked to a user even after all associated work is completed, preventing their reuse for future receipts.

This behavior stems from the system allowing putaway to begin without enforcing cluster closure. To improve operational efficiency and prevent unnecessary locking, we propose a validation check that restricts the putaway process unless the cluster is explicitly closed.

The current behavior is that when "Count non-discountable items towards threshold" is enabled, it will include those items towards threshold qualification which are added to the discount line section as "Include", but have been either marked as "Prevent all discounts" (Under Commerce tab of Released products) or have another Exclusive or Best price discount applied.

The above behavior is according to Issue 449997 that can be found in LCS.

Proposed behavior: this parameter should allow for items that aren't included to count towards the threshold as well. (or a separate parameter) To allow for more scenarios to be applied in the system.

Using the Inventory Visibility Service (IVS) API's, we would like to be able to request a view of the stock quantities in a different unit than the default 'Inventory unit'.

In Dynamics, you're able to view stock information in any desired unit (through i.e.: mi=InventOnHandItem), but this functionality is missing in the IVS.

Further context:

We sell items as separate pieces as well as by the box and each item has an item specific conversion 'Pcs' <-> 'Box'.

For our web shop we want to be able to give an indication of the stock ("Plenty of stock", "Limited availability", "Out of Stock", ...) depending on the chosen sales unit. As such, we would like to be able to retrieve the stock through IVS in the "Box" unit when the customers selects x boxes:

• ... > 100 boxes : Plenty of Stock
• 100 >= ... >= 1 boxes : Limited availability
• 0 boxes : Out of stock

At the moment we need to do 2 API calls to get the stock information and then another to get the unit conversions and finally do the calculation ourselves. So having this functionality would eliminate the need of the second API call and the calculations.

Enabling the "Select voyage cost" functionality from Pending vendor invoices in D365 F&O would streamline workflows by allowing users to allocate voyage costs earlier in the process, reducing manual steps and rework. It would enhance cost allocation accuracy, improve invoice matching and validation, and provide more timely financial visibility. This early integration supports better inventory valuation, budgeting, and decision-making, while also aligning more effectively with the Landed Cost module for comprehensive cost tracking.

Currently Microsoft introduced new functionality related to multisourcing products.

When sourcing items by multiple vendors, it happens often that clients must be able to define different default order settings. Within the current solution this is not possibile.

For example:

Vendor A delivers in Tank of 591 KG

Vendor B delivers in Tank of 788 KG

Possible idea, add vendor to the Default order settings. And a parameter that it only applies for some items.

1. PurchLineType and method CalcDimensionsSpecificPurchQty()

Other solution might be adding extra fields to multisourcing policy



1. Extend multisourcing policy

Microsoft decided to cancel the preview feature Rename item number.

https://learn.microsoft.com/en-us/dynamics365/supply-chain/get-started/removed-deprecated-features-scm-updates#rename-item-number-preview

Reason:

"The item number field is a primary key that is used across multiple systems. The (Preview) Rename item number feature allowed users to edit the item number field, but we found that the feature could cause data inconsistencies in multi-system and apps-integration scenarios, leading to data integrity and data corruption issues. The feature was previously in preview and was never made generally available for use in production environments."

Proposed idea:

Do not cancel this feature, because the reason above certainly does not apply to all customers. The existing preview was fine for many customers.

Instead of cancelling the feature, 1) add a clear warning message with the reason above, and 2) add a clear authorization or parameter on the user that grants the rename function only to users that know what they are doing.

In the new Pricing management, it is possible to Recalculate prices (etc.) on open sales orders, but job does not appear to have any log file to review the updates that have been performed.  

The Recalculate prices batch job should be updated with a log file containing

- What has been updated (i.e., which lines on which sales order have been updated)

- Any errors from update (e.g., no active prices found)

That way it is possible for users to follow-up on the updated sales orders to verify if update is as expected or to understand why an update has been performed. 

It's quite frequent in certain industries with high volume/low unit prices, to have a rebate agreement based on quantities. The rebate management amount needs to be precise (up to 4 digits) - 0.1255$ per unit sold for exemple.

This new features would allow to setup a rounding precisions in the Rebate Management Parameters, where we can define how many decimals places we'd like to have in the Rebate Management amount field.