Comments
Peter's idea would be great or adding a new Price List Line Type of “Price List”, allowing one price list to reference another (similar to how Production BOMs can reference other BOMs). Base logic would still work properly where the system finds the "best price".We maintain a base price list assigned to 'All Customers' as a catch-all, then apply multiple discount layers based on the volume of business with each customer. While the current combination of base price list, customer price group, and item discount group covers most scenarios, it falls short for some of our larger customers.
For CPA Australia, we raised this issue because running the Accounts Payable Foreign Currency Revaluation process updated the vendor balances which triggered an update in the payment status details on the underlying expense reports. This is not the correct behaviour because no payment has been made to the employee.Additionally, because of the initial update to the Expense Reports, when the real vendor payment was made and posted, the Expense Report details would not display the correct payment date and voucher because the system is recognising multiple payment/settlement transactions linked to the expense report/s.Our organisation operates in a multi-national / multi-currency environment with revaluations occurring for both local accounting currency ledgers and reporting currency ledgers as well, so the impact is widespread for us when there are un-paid expense reports at the end of the month.It would be of great benefit for us to not have to compromise our accounting policies for how and when we run revaluations in order to get around this issue.
Thanks for this idea Maria! We and a lot of other implementation partners and customers all still have the same issue and I had created the following post in Viva Engage lately and was told to create an idea, which, as I found out, is already existing. Therefore I create this comment with the detailed info from my Viva Engage post.Weber, Jürgen on Viva Engage: "Multiple usage of the same operation in one route" Posted in Manufacturing on Jan 7, 2026Multiple usage of the same operation in one routeWe have again the issue that we can not use one and the same operation multiple times within one route, because if we do that fields and setups like the run time and the resource are always the same for each of the operations.This restriction however only applies when we setup the route under "All Routes" or directly from the released product. Here the following underlying tables are involved - Route, RouteOpr, ProdRoute, Once we have the production order created the behavior for the individual route of the production orders is different! We can e.g. enter further new operations with the same operation ID and indicate different run times and resources. Now we would like to get rid of this limitation already with the setup of the base data. The workaround to name the operation IDs with a pre- or suffix Number is suboptimal. Are there any other workarounds that we are not aware of or have any of you customized that behavior already? Or is perhaps MSFT thinking about improving this behavior in a future release?Thank you very much!