In 2024.1 we have noticed that reports printed via a AutoPrint BPM data directive ignore the format culture of the user and always default to the USA date format. This only happens via a data directive, if you print the report normally everything is correct.
So to make matters even more complex if you instead use one of @klincecum’s great functions to generate and send a SSRS report it will give you different results if it is processed Synchronously or Asynchronously. Maybe this is a task agent issue and not a BPM issue?
We’ve had issues with Task Agent for a long time because task agent doesn’t carry “CallContext” or “ClientContext” or any of those which a lot of times affect things like Language, Culture etc It has been quite the nightmare.
I’d be curious if you can use one of Kevin’s Functions but use the Temporary Session Creator to “force” a change of Culture or Language if it would fix it. It is what we had to do when running “scheduled” functions to grab Company etc. We had to basically pass in the Company / Plant etc identifier as function parameters and then using the TemporarySession we had to activelly “switch into” that for global variables like
I know @JeffLeBert revamped it, I wonder if there is anything to it, or if it was just missed. Might be on the Epicor side, sending the right data to the SysParam tables.
For anyone following along support confirmed an issue in PRB0283609.
“Creating a temporary session does not change the value of CallContext.CurrentUser”
The use case was that the report style represented a US layout for an AR Invoice - the customer wanted it so that whether it was printed here in the UK or natively in the USA it would always have the US date format, and not follow the user culture.