Dynamics 365 Supply Chain Management

The back button is a systematic feature and cannot be manipulated in terms of placement—whether at the top or bottom of the mobile menu items. While the system allows customization for the order of custom made mobile device menu items, it does not include the ability to reorder the back button.

This can be challenging for businesses with extensive lists of mobile device menu items, as workers may need to scroll down on their PDAs to access the back button and navigate to the previous screen.

This would be a great feature to let the business decide where they want to place the default back button.

We have a specific requirement regarding the inventory aging report functionality in Dynamics 365.

Currently, the system displays the age of inventory items per warehouse. However, when an item is transferred to a different warehouse, the aging of the item gets reset.

Our requirement is that the aging of the item should not reset upon warehouse transfer. The aging should continue to be based on the original receipt date — that is, the date when the item first arrived or was purchased by the company.

We are considering using the Product Receipt Date or the Physical Receipt Date from the original purchase order as the reference for inventory aging.

When using the GIT order process merging Procurement & sourcing and Landed cost, the business process should be as the following:

1. The PO is created for a batch tracked item, approved and confirmed
2. Delivery term has the "Goods in transit management" toggle enabled
3. The voyage is created and the PO line added to the shipping container.
4. The PO invoice is posted before the goods are received, therefore the GIT order is created.
5. In the industry, the batch number is still unknown as the goods are not received yet
6. Currently, there is a error generated by d365FO when doing so therefore the invoice cannot be posted
7. The GIT order is received
8. The vendor invoice journal for the voyage is posted.

In Step number 3, D365 should allow the business to post the PO invoice without a batch order as it is still unknown for the business. The batch number will become known when the GIT order is received.

The Idea is to have D365FO handle to post the PO invoice without the batch number as per the business process of the industry is even when using the Primary stocking field on the tracking dimension group.

Currently it is not supported to post the PO invoice without a batch number when using the "Primary stocking" in the Tracking dimension group, but this should change. Please see the following issue:

Details for issue 665089

https://fix.lcs.dynamics.com/Issue/Details?bugId=665089&dbType=3&qc=b887d63067ed02496f7a950f3351e23191b586c7e41760b40afcb0b134534962

ISSUE:

When using the mobile device menu items mode indirect and activity code: data inquiry, you can make list pages (CARDS) on nearly every table ind D365F&O with filters. Enabling warehouse workers to have very intuitive approach to warehouse operations and start up of different work processes based on the lists. The list has a force since they do not give any limitations as to what fields can be displayed on the CARD - just they are on the table or method() . Adding mobile device steps and detours to the data inquiry can kick of the process of different work and later returning to the list / Cards and kick of yet other work. Unfortunately when returning to the list this is not refresh with the query that is actually saved on the mobile device menu items on entry. Meaning you need to leave the list and go back to the menu and back again to have the list refresh and see what is yet left to do.

IMPACT:

The refreshing the data inquiry list after processing work gives the user two extra keystrokes / mouse click that they need to do to manually refresh the list of Cards, sometimes even reentering parts of the filter. Thereby having an impact of workers daily productivity. There is a great deal of gain on time and cost savings of having this done automatically.

IDEA:

Making a parameter on the mobile device step on the BRING BACK step where the query can be set to be refreshed or not. Of course it should be possible even if there is no setup done on the return BRING BACK to the start menu.

Hope this will idea will be considered.

Thank you for your time.

Best regards

Tom Schrader Poulsen

Extend the Price tree, Price attributes, Discounts, Charges, Trade agreements, Base price determination etc. to the Procurement and sourcing Module for Vendors and Purchase prices.

Current setup:

Using Advanced Warehouse Management with Mobile Device

Using Quality Management

Issue: When we create a Sales Order for a part that we purchase to resell, a planned purchase order is generated. The planned purchase order is firmed to a Purchase Order. When the item is received, a quality order is generated. The user completes the quality check but cannot "Validate" the quality order because the system throws the error of unavailable inventory. This issue is due to the original sales order having the same inventory reserved ("Ordered reserved").

Microsoft said their engineering team triaged the bug and determined it was an issue but could not fix it via hotfix. It is a design limitation and will require a change in the underlying design which they cannot take on at this time.

The only way around this is to manually unreserve the inventory on the Sales Order (which quality doesn't have access to do), Validate the Quality Order and then re-reserve the inventory on the Sales Order. This is very time consuming and has to involve multiple users.

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.

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

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.