2024.1 User Date Format Culture ignored for AutoPrint BPM Reports

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.

Has anyone else encountered this?

Incorrect via BPM:

Correct (manual print):

2 Likes

Can you look at the SubmitToAgent method and see if this is set properly in the DD?

Great question @Mark_Wonsil, in both 2022.2 and 2024.1 both the Currency and Culture are blank if coming from a AutoPrint (but it worked in 2022.2).

In the SysTaskParam table I can see that the CUR-LangID/Language ID param is correctly passed in all cases. (ena for Australia)

PS This also happens other reports, it’s not limited to the PO Form.

1 Like

Interesting…I wonder what changed. Task Agent maybe? :thinking:

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?

image

2 Likes

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

this.Session.Company and others to work

image

See Idea: KIN-I-3804 - Scheduled Function Execution should Include Related CallContext and TaskNum

4 Likes

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.

1 Like

For anyone following along support confirmed an issue in PRB0283609.
“Creating a temporary session does not change the value of CallContext.CurrentUser”

1 Like

I found this issue for a couple of customers. The solution that worked for my use cases was to set the Format Culture on the Report Style itself.

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.

3 Likes

We found that too, but we do want it to follow user culture so the same style can be used in all companies.

1 Like