Yasmine Hesham Hassan Zaki (Convergys International Europe B V)

It isn't feasible to link a purchase order to a sales order in any setup except for the direct delivery setup. The linkage appears on the "Item Reference" and "Reference Number" tabs found in the sales order lines and this linkage is done automatically by the system once a sales order is created. This forces the clients to always choose the direct delivery set up in order to have the leverage to link a purchase order to a sales order. Moreover, if the customer then tries to remove an already linked purchase order and choose a different one, the system will not allow this action. In case of high sales demands, this process can be very labor intensive as the customer is then tied to cancel the sales orders all together and re-link them to new purchase orders.

I am requesting a parameter that enables the direct approval of partial delivery of purchase orders under change management in the 10.0.41 version update.

Currently, the system throws an error message: "Changes to the document are only allowed in state Draft, because change management is activated." However, in previous versions ex. 10.0.39, this wasn't an issue.

The functionality could work similar as the existing parameter called "request change" which exists in the purchase order tab. Then, adding the number of the received POs on the PO lines, and finally restarting the workflow.

The workaround is a labor-intensive time-consuming process that users didn't have to go through in previous versions and could do without now.

In vendor collaboration, if the customer canceled a purchase order, the status of the sales order at the vendor's end will remain as an "open order" even though it is reflected as "canceled" on the customer's end.

We hope that the PG will take this idea into consideration in the upcoming version updates as this asynchronization is causing an issue for the customers.

The consumption per lot size amount of a finished good with multilevel BOM lines isn’t correctly rounded when choosing the “multilevel” explosion mode while viewing the calculations. However, the rounding is correctly calculated in the “make-to-order” explosion mode. This leads to discrepancies in the cost calculation. 

The BOM calculation is used daily for quotation purposes and considering the fact that the customer's BOMs are designed with high series numbers (1000 in most cases) (Default pallet size) the rounding issue leads to wrong cost calculation hence wrong pricing that impacts the company's profitability.

Ideally, the customer would like to unify the calculation outcomes, however, when it comes to using the BOM calculation form it shows different figures even compared to another screen like max reported as a finished form that is widely used by the production team.

So, in simple words, if the customer performs a BOM calculation on a multi-level, it shows an estimated consumption of a wrong rounded value, then when it comes to calculating the maximum possible reported as finished Qty it shows the correctly rounded value.

The workaround of changing the BOM line type to “pegged supply” instead of “item” is not feasible at all, changing the lines to pegged supply means, either the customer is always purchasing or producing this item which is not the case. These items are consumed from the on-hand normally.

This is a feature gap that denies the customer from supporting his business scenario. He wants to the "Requester" to be the "First Approver" in the purchase order workflow. Currently, it is only allowed to choose the requester as the starting point for the hierarchy's approval, but he is unable to approve the workflow.

For example, in the Dynamics 365 Finance update from April 2024, there is a feature that allows the purchase order's requester to be added as the invoice approver in 10.0.33. This means that the requester can be involved in the approval process right from the beginning, ensuring that any discrepancies or issues are addressed promptly.

This is a feature gap that denies the customer from supporting his business scenario. He wants to the "Requester" to be the "First Approver" in the purchase order workflow. Currently, it is only allowed to choose the requester as the starting point for the hierarchy's approval, but he is unable to approve the workflow.

For example, in the Dynamics 365 Finance update from April 2024, there is a feature that allows the purchase order's requester to be added as the invoice approver in 10.0.39. This means that the requester can be involved in the approval process right from the beginning, ensuring that any discrepancies or issues are addressed promptly.

Go to Inventory management > Periodic Tasks > Quality management > Quality orders, the Quality order type "Quality order" reflects a line with its respective Work ID, however, the Quality item sampling does reflect a Work ID, however it doesn't reflect a Quality order number.

One the other hand, if one searches in the Warehouse management > Work > All work form, they will be able to see the missing Quality order number assigned to the "Quality item sampling" with its correct Work ID.

The route auto operation number is generated in descending order with different rounding sometimes every “-1”, “-5” or “-10” RANDOMLY. However, when a new operation is added, it is expected that the number generation will follow an ascending order. For instance, when the first operation is created with a value of 10, the second one should be 20, and so on. However, the system is currently functioning oppositely, assigning 0 to the second operation and -10 to the third.

If there's been any modification done to a "received" transfer order like removing a line, the status is changed to "created" and the line is removed. The customer doesn't want to apply security to the "remove" button as this is a labor intensive and time-consuming path for the registered user to apply the modifications for every time a modification has to be done. The customer wishes to have a "finalize" feature similar to the one available for purchase orders for transfer orders to keep them locked after the "received" status.

Customer is unable to re-approve a PO when the re-approval rule in purchasing polices is activated for POs. Issue is that purchase order reapproval rule is created and activated for some fields but still when any change happens it goes for workflow.

This issue was previously raised in many other bugs as follows:

1- BUG 478498

2- BUG 969102

3- BUG 868849

Please prioritize this issue as it's been requested by multiple other customers with thanks!