Dynamics 365 Supply Chain Management

The system should give us possibility to allocate voyage costs directly on vendor invoice journal without using "select voyage" functionality. All necessary fields to describe the voyage are on invoice journal line: Cost type code, Cost area and Reference. Thanks to this idea a user will be abble to assign voyage costs much more efficient and have all information about cost directly on vendor invoice journal lines.

Counting Reason Codes can be assigned to Adjustment and Movement journals but don't appear to be fully supported. For example:

• Offset Accounts specified against Counting Reason Code are used for Counting journals but not for Adjustment/Movement journals
• Counting Reason Code Policies (to enforce mandatory use of a code) apply to Counting journals but not to Adjustment/Movement journals
• Entities for Counting journals include Counting Reason Code field but those for Adjustment/Movement journals do not

There are no doubt other bits of functionality to which the above also applies. Since the Counting Reason Code field is available within the client for all three journal types, one would expect the functionality to be consistently supported for all three journal types.

When a purchase order is created from an approved purchase requisition line, the Approval status on the PO is set to "Approved" even when the Activate change management parameter is set to "Active" and an active Purchase order workflow configuration exists.

There was a previous Microsoft Idea that has been completed for this: https://experience.microsoftcrmportals.com/ideas/idea/?ideaid=1b8b981b-438f-e711-80c0-00155d7cd0b4

However, as confirmed by Microsoft, this is currently only active for customers that have the configuration key 'Public Sector' enabled.

Our customer in Industrial manufacturinghas has two distinct processes:

• The requisition process with an approval workflow which takes place "in the business" and where department managers can approve requisitions for their employees
• The second process takes place in the procurement department where buyers prepare the purchase orders and pricing and then submit the purchase orders for approval via a separate approval hierarchy with stepped signing limits.

The suggestion here is to open up this already developed feature outside of the Public Sector Configuration Key.

Customers reported an issue where inventory marking is automatically applied to a virtual inventory transaction when creating a PO from Purchase Requisition or manually from the All Purchase Orders page. Unlike the first scenario (creating a PO from an SO), where the marking can be manually unmarked and reassigned to another PO, this second scenario does not allow manual unmarking. Attempting to unmark results in the following error:

"Manual marking is not allowed because the inventory transaction is linked to a virtual inventory transaction."

Customer Configuration & Context:

• Project module: Not used
• Item requirement: Not used
• Setup: Customer only creates a Project ID and Contract ID
• Business Impact: Prevents users from manually managing inventory marking as needed, leading to operational inefficiencies.

Investigation Findings:

• The issue is reproducible in standard D365 FnO.
• The FIN team confirmed that this behavior is by design, but they could not provide further details on the logic behind it.
• There is limited documentation on this specific scenario, making it difficult to confirm whether this is the expected system behavior or a potential enhancement area.

Request for Clarification:

1. Can you confirm why marking is enforced automatically in this scenario and cannot be unmarked?
2. What system logic drives this behavior when no Item requirement or Project module is used?
3. Is this behavior expected, or should it be considered for improvement in a future release?

We would appreciate any insights or guidance you can provide

The user input and validate Quality order with wrong batch number and they need to back to reopen quality order and Edit test results and Validate again. But they could not validate the quality order again because of the error: “You cannot block xxxx items. Only xxxxx items are available on the inventory for item xxxxxx”.

This is “bug” from using “Reopen” function on a closed quality order. It needs to be fixed. There are too many wrong quality orders and each quality order contains many test group lines – in short, there are too many input to create a new quality order. Please reconsider your solution.

There is no Engineering Change Management (ECM) category to choose, which is odd, but this should fall under that category.

Currently engineering product categories are designed to only apply to a portion of the item master because they can only be created with a production type of BOM or Formula. The means that any co/by-product that is output on a formula cannot be engineering controlled, because they would have production types of Co-product or By-product. This means the following functionality cannot be utilized on an entire item master. (Listed on the Feature Overview from the MS documentation)

• Product versioning
• Enhanced product release functionality that lets you maintain product master data in one legal entity (the engineering company) and publish the fully configured released product to other legal entities
• Rules for validating that required information is entered before a product version is activated (readiness checks)
• Improved product lifecycle management through fine-grained control over when a released product can be used in specific business processes
• Engineering change requests that are supported by workflows
• Engineering change orders that are supported by workflows

In Bom lines, two fields InventStatusID and WMSLocationId can be edited via frontend UI but at the time of bulk update using DMF (Data Management Framework) or Excel Add-In,stops at staging, target feilds is not updated

Reason:For a new customer, during migration or bulk data upload , this causes a problem.  

In many cases we don't know which asset that is an issue. We've to create the work order and plan it to a worker. Then after some time we know which asset. Then its's of course to late.

It would be great to be able to only change the asset/location on the line.

Not change the job type, variant and trade.

Sales trade agreement prices and discounts can only be specified per product dimensions + site + warehouse. In standard D365FO pricing, all inventory dimensions can be activated to be price relevant. This includes the generic inventory dimensions InventDimension1 to InventDimension12 (https://learn.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/extensibility/inventory-dimensions).

We would like unified pricing to provide the same flexibility and allow us to specify prices/discounts per all inventory dimensions (including generic dimensions).

Regarding standard inventory dimension this might most typically be needed for batch and maybe serial numbers.

An example for generic dimensions: There are customers that use one of the generic inventory dimensions to distinguish stock by item condition (New, Used, Refurbished). For them, this dimension is pricing relevant.

Idea originates from this Yammer thread: https://www.yammer.com/dynamicsaxfeedbackprograms/#/Threads/show?threadId=3153539125051392

Currently, if two products are assigned to Serial number groups that call the same Number sequence, and Production orders are created concurrently (either manually or by Firming planned orders), the system can enter a "race" condition where non-sequential Serial numbers are issued to each order.

For example, Order A is issued Serial numbers 1, 2, 4, 6; Order B is issued Serial numbers 3, 5, 7, 8.

The race condition usually occurs on large-quantity orders due to longer processing times; large quantities also make it more challenging to identify where the non-sequential discrepancies occur.

The concern is for traceability, especially in regulated industries. Non-sequential Serial numbers for a group of products (particularly those originating from the same Prod order) could lead to labeling errors and documentation discrepancies, especially when the ERP must interface (directly or indirectly) with external systems like a lasermarker that would etch the serial number on the product.

Microsoft indicates that the limitation is due to the way the system generates transaction numbers from number sequences. A solution could be implemented via the Tracking number group module to limit the impact, as opposed to directly in the Number sequences module which has wider systemic exposure.