Dynamics 365 Supply Chain Management

We are Microsoft Partners working All-Star Marketing group to Implement the following: Dynamics Finance; Dynamics SCM, IOM, and Inventory Visibility. There has been a request for embedding the Inventory Visibility app into the main dashboard in Dyn 365 Fin and SCM. I tried a couple approaches. Add the Power App and Web page. Both ways did not seem to work. I would like to suggest an idea of embedding the IV App into Dyn Fin and SCM.

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.

The coverage codes in D365 determine, among other things, how the requirements from different order types are covered. A distinction must be made between three different main procedures.

Manual

Manual management is used when material management is not required. This can be, for example, external management or specially monitored components.

• Manual

Demand-oriented

Materials are reordered from various orders based on actual demand or planned requirements. → This can be extended with a safety stock.

• Period
• Requirement
• Priority (DDMRP)

Stock- oriented

Stock materials are reordered based on predefined stock levels, regardless of direct demand.

• Min./Max.
• Priority (DDMRP)

Production companies that want to evaluate and manage items according to the ABCXYZ methodology have long been limited with Dynamics (AX, F&O), especially for X items. Items with constant consumption are usually regulated and replenished exclusively via stock levels regardless of any impact of direct demand. Min./Max. management is problematic, as the reorder point could not be displayed until now. As a consequence, with the Min./Max. variant, the minimum is misused as a “reorder point” and not as what it should actually be, a minimum. Another variant is the use of Period in connection with a safety stock level (minimum). This means that a kind of sawtooth principle is achieved by means of the periodic grouping of demands. However, the timing of the safety stock is very problematic and leads to many undesirable effects in replenishment.

The hope for these problems lies in the new Priority functionality. According to Microsoft's documentation, the functionality can also be used without the direct prioritization of orders. This would allow the long-awaited sawtooth principle to be implemented. In a larger test with the new functionality, discrepancies and questions have arisen in the basic functionality of the new Reorder Point field.

Issue 1 – Requirement date vs. Planned order date

The reorder point is reached at a specific date. The expectation is that the coverage of the shortfall is set to the corresponding date the reorder point is detected on the time line. The system calculates the planned order on the principle of today + procurement time (Default PLOP). This means that regardless of when the reorder point is reached, the system sets the coverage using planned receipt to today + procurement time. The consequence is that procurement takes place too early. The expectation is that the planned receipt is set at the time when the reorder point is reached.

Issue 2 – Maximum Value

It is not uncommon for planned issues to be set far into the future based on forecast planning. Regardless of which maximum value is set, the system creates the first planned receipt according to Issue 1 with the necessary quantity to cover all future requirements. The maximum value is not taken into account. This is simply not effective. The consequence of this is that too much material is procured too early instead of allowing the planned orders to be created using the sawtooth principle. The expectation is that the first requirement will be covered by a replenishment up to the maximum value and the next replenishment at a later date when the next reorder point is reached.

To summarize, it can be said that a simple sawtooth management system is already in place. A new coverage code would have to be defined, where only the settings Min. ROP and Max. pull. The replenishment lead time must be subtracted from the ROP so that the corresponding order time can be calculated. Taking into account the maximum stock level, automated stock-oriented management can be achieved in this way. This has long been standard practice in manufacturing companies.

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. 

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

The request is to enable the vendor collaboration portal for shipping company vendors, so that it can issue invoices linked to voyages.

With reference to LCS Issue823033 

When Reporting currency and Transaction currency differ, while the postings occur on different dates, it has been observed that the 'Landed cost Goods in transit' is not correctly cleared, voucher transactions being unexpected.

The difference arises due to the exchange rate on the arrival journal date being different from the one on the date of the Purchase Order Invoice.

Dual Currency and its consistency, is highly needed in business processes, being a very common need.  

Many business processes would highly benefit from and enhancement in this area.'

When a supplementary item is provided free of charge in an intercompany scenario with direct delivery in DEMF, purchase and sales prices are automatically populated. This occurs regardless of the pricing parameters configured on the intercompany accounts.

it would be helpful to fix the issue and not populate the unit price of the supplementary item that is suppose to be free of charges

this impacting the business This behavior disrupts the intended pricing model and can lead to financial discrepancies, affecting the accuracy of cost allocations and profit margins. This impacts the efficiency of the order processing workflow and results in erroneous intercompany invoicing, ultimately affecting intercompany agreements and internal financial reporting. Since there are different items that may contain 2 to 3 supplementary items, the impact it has on all financial & reporting aspects is unneglectable. item is supposed to be provided for free as part of an intercompany transaction between different parts of the business. However, the system is incorrectly charging for this free item on both the purchase order and the sales order, even though it should not have a price. This issue disrupts the normal process, making it appear as though the business is paying for and selling the item when, in fact, it should be free of charge.

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.