Comments
I'd like to second the original idea and all other comments made here. I have just recently encountered all of the limitations outlined here while configuring a proof of concept solution for our customer. Simply put, we need to be able to specify the exchange rate and currency code for all Job Planning Lines so that resulting Sales Invoices and related Purchase Invoices calculate correctly.
The Job Planning Line does have a "Currency Date" field but even this does not seem to accomplish one would expect (derive an exchange rate based on a date other than the posting/document date of the resulting invoice. Nor does it allow you to specify different rates for different Jobs (as mentioned in several comments above).
This is a highly valuable suggestion. Acknowledging the inevitability of SQL disconnections in a SaaS environment, as outlined in the Dynamics 365 documentation, it's clear that the current behavior of batch jobs failing upon brief connection losses to Microsoft SQL Server significantly disrupts business operations. The introduction of a system that notifies administrators of such disconnections, along with their duration, represents a critical improvement. It would not only enhance transparency but also mitigate confusion and frustration by providing clear explanations for the errors users encounter. Implementing this feature would significantly improve the user experience and operational efficiency, supporting our continuous commitment to service excellence.
That's unfortunate that it was declined but I'm not surprised.
That said, I think Microsoft needs to re-think how extensions are synched and upgraded.
Currently if you successfully sync-navapp but start-navappdataupgrade fails, it leaves the app in an unusable state!
I think there should be a way to somehow batch both sync-navapp and start-navappdataupgrade into a single transaction.
If sync-navapp succeeds but start-navappdataupgrade fails, everything should be rolled back including the schema sync.
Unfortunately that doesn't happen currently and because it this, it leaves the app in a useless uninstalled + unupgraded state.
This can be configured but not using standard methods. Neil Parkhurst has a blog article here https://neilparkhurst.com/2023/11/11/omnichannel-for-customer-service-identify-customers/ where he outlines the steps to patch your Workstream with the revised conditional logic. These are the same steps you are given if you go through support.