Kareem Essam

When using the “Exclude canceled lines from totals” parameter in purchase orders, the system currently excludes only the purchase line amount but not the associated markups. This leads to incorrect total calculations, since markups are part of the purchase order line and should be excluded as well when that line is canceled.

This behavior creates significant issues for customers using approval workflows based on spending and signing limits, as the incorrect totals cause purchase orders to be routed to the wrong approvers or require unnecessary manual approvals. This adds extra administrative effort and delays in the procurement process.

We suggest improving the design so that when a purchase order line is canceled, both the line amount and any related markups are excluded from the totals calculation. This change would ensure accurate totals, smoother workflow automation, and better alignment with real-world business expectations.

Currently, the system allows users to create transactions with extremely large quantities in both the Warehouse App and On-Hand Adjustments. This can lead to data inconsistencies, calculation errors, and inventory closing issues, especially when quantities exceed the limits that D365 and Excel can handle.

This idea proposes adding validation limits to prevent users from entering excessive quantities, ensuring system integrity and reducing the risk of errors. Implementing this would help avoid the creation of “invalid” transactions and minimize the need for manual corrections or workarounds, improving operational safety and confidence for users.

When creating or editing a Product Relationship Type in Dynamics 365, entering a Friendly name with spaces directly in the main form does not persist after saving the system automatically removes spaces and reverts to the internal name. Currently, users must open the Translation form to maintain the desired text.

Business Impact:

This behavior affects usability and can slow down data entry, especially in environments with many product relationships. It also introduces inconsistency and may impact user confidence in the system, as the expected result is not achieved from the main form.

Proposed Improvement:

Allow users to enter and save Friendly names with spaces directly from the main Product Relationship Type form without needing to open the Translation form. This would improve usability, reduce extra steps, and enhance user trust in the system.

Currently in Dynamics 365 Finance & Operations, once a costing sheet node has posted transactions, it cannot be deleted or disabled. This creates challenges for companies that want to simplify or update costing sheets after going live, particularly when indirect costs are applied at a detailed level (e.g., per item).

Customers face performance issues when the costing sheet evaluates every node during production journal posting, even nodes that are no longer relevant. Existing options, such as setting the node rate to zero, do not prevent the system from processing the node, and there is no supported way to make a node “inactive” for future calculations.

The inability to deactivate or replace nodes safely leads to limited flexibility, potential performance bottlenecks, and extra complexity for ongoing projects. A solution that allows safe inactivation or expiration of costing sheet nodes would improve system performance, simplify cost management, and reduce operational overhead.

Currently, there are no standard data entities available for the Hazardous Materials configuration tables HMIMCompatibilityGroup and HMIMCompatClass in Dynamics 365 Supply Chain Management.

These tables are used to define compatibility groups and hazard classes, which are essential for managing and transporting hazardous materials safely and in compliance with regulations.

The lack of standard data entities for these tables makes it difficult to migrate HazMat configurations between environments (for example, from test to production) using the Data Management Framework. As a result, customers must rely on manual setup or build custom entities, which adds time and effort to implementation and migration processes.

Adding standard data entities for these tables would streamline environment migrations, improve data consistency, and align HazMat functionality with other configurable areas of Supply Chain Management.