Hi @GISANCAR,

In IFS Cloud, when you set a user's language and locale in their profile settings, all reports should default to these settings. However, this behavior can be overridden by using a report rule. If no report rule is set, the language and locale settings should pass through from the application side. 

Language- English-British
 

Auto select Date/Number Formatting: en-GB

Alternate way:
Instead of ordering the report through the application's product functionality, you can try using the Order Report wizard, inputting the required parameters directly. This should result in the report being printed as expected.
 

Best Regards,
Dharmendra
Follow: linkedin.com/in/dharmendaribc

Note that SOME buttons to print will retrieve a default language based not on the client, but on the entity details of what’s being printed, if language code is part of that entity

Here’s an example, for Customer Orders, you get the Language Code as a field on the Misc Order Details. It is defaulted from the Customer defaults when the Order is created, but can be changed.

When you print the order confirmation, this WILL take preference over the Language of the user in the pop up window.

For instance, my current language in the Application is English, and yet when I click on Print Order Confirmation, the pop up looks like the following:

Shipment is one such entity that has the Language Code too, and therefore it should default to whatever is recorded in the Language Code Field.

If your customer default language/country is properly set, it should properly populate those fields when you create the Customer Order through defaults, and then when the user chooses to print the document it should default the language based on the what the record is.

Thank you for the information. It clarifies some of my questions. 

But this is mainly related to date/number format. I think that we have the language that we want, but not the correct date/number formatting.

To be honest, I don’t really understand the problem, as for me it absolutely does not override to my locale language in the Date/Number Formatting (either the browser language or the Windows Language).

You can see that when I print the report, both the language code AND Number/Date formatting are set to Spanish (es-ES) and yet neither my machine nor my browser are set to Spanish, this is all inherited from the language code set on the Customer Order.

Do you by chance have active report rules ? Report Rules CAN override the Date/Number formatting locales from the default behavior on the application.

Also, Do you see this behavior for any operational report, or is it limited to some specific ones ?

For sales related reports connected to the customer order, sales quotation, customer invoice and RMA the session language is never passed to the print dialog. The language on the print dialog is retrived from the Customer connected to the objects mentioned before. The default language can be setup on the Customer/General tab. This will then be passed on to the objects customer order, RMA etc which in turn will be passed to the print dialog of the relevant object. 
 

I don’t think it’s retrieved from the Customer Connected to the object, but from the language code of the Object itself. I’ve just tested this and if my Customer is set to English but I change the Customer Order language code to Spanish, the print dialog defaults to Spanish, not English.

What DOES default to English would be creating a new customer order for that customer, but that can always be changed at any time.

What about Shipment Delivery Notes, is that considered part of the Sales Report? I ask because Shipments also have the language code set up against them.

In apps 10 (haven’t checked in Cloud), Shipment Delivery Notes also automatically default me to whatever language code and locale is based on the Shipment itself:

Trust me, neither this customer, nor my local machine, nor my application are set to Norwegian, but it defaults just fine just based on me setting Norwegian as the Language code for the shipment itself.

This is also applicable for 'shipment delivery notes' as it comes under Sales Report. Thank you.

Experience from a different system, the date/numbering format wasn’t connected to the language of the customer but rather the country of the customer - the address. And you could override it on the customer/supplier if you wanted, but by default it looked at the address country.

But in this case it seems that if both are connected to the language. Would mean that you need to create quite a few variations of ‘English’ and then know which one to select on each customer?

English GB, English US, English generic et cetera - to be able to control also the date/numbering…

Currently we only have ‘English’ and it is connected to ‘en-US’ which gives the date/numbering formatting as far as I can see.

I mean, you probably don’t want to create new languages.

You set the default language of the customer.

From your comment here, am I understanding the use case right, which is that you may have a Customer that is say, Swedish (their default language), but they also have an address in say, France, and you want that the Sales Documents for those Orders (Confirmation, Quotation, Delivery Note, Invoice, etc) get printed in French ?

If that’s the case, rather than creating languages, just create an event that’ll set the Language Code of those entities to the equivalent countries, that way when you print, it’ll default to French with French Date formats and French Numering system.

Am I getting what you want to do wrong ?

If I’m honest I don’t know how you managed to get “this” combination when clicking print, from your first message:

“Language ‘en’ and Date/Numbering Formatting = ‘sv-SE’. “

This should not happen unless you’ve modified the en language code to use a completely different RFC-3066 Code.

Printing a Shipment delivery note should really not ever default to en + sv-SE, if the language code on the shipment is set to en, it should default to en + en-US

Almost 

I have 3 different customers that all use ‘English’ but they are located in three different countries, with three different date formats (mm/dd/yy, dd/mm/yy and yyyy/mm/dd).

All documents are printed in English, but the date format is wrong -  reason is that English is connected to ‘en-US’ so all documents are printed with mm/dd/yy.

I get en+sv-SE because of a report rule that was connected to the specific document I was testing on - the rule has now been inactivated and removed. I guess that a previous employee, at this company, tried to solve this specific problem, and did an ugly quick fix instead of trying to solve the main issue.

Ok that explains it for the sv-SE.

What countries are we talking about? Is English the main language in those countries ?

enUS will go mm/dd/yyyy, while enGB (language code gb) will go dd/mm/yyyy, but i’m not sure of a country where the “normal” way of doing dates is yyyy/mm/dd

We have customers in India who want to have the date printed as yyyy/mm/dd, even though I think that their normal format is dd/mm/yyyy.

We also have Swedish customers, where the document language is English and the date format is yyyy/mm/dd. yyyy/mm/dd format is also used in China and Japan (and other countries)

It’s going to be tough to get both english language but also different NLS formats.

Like if you have Swedish customers, you’d expect the language to be Swedish with Swedish date formats, which probably explains why someone at your company had set up the Report rule in the first place to force the en / svSE combination.

In that case, I actually think Report Rules might make the most sense, although you might need to make them a bit more complex than they were to choose the right locale, basing it on Country which hopefully should be available the Report Result Keys

The fact you want a language but a non matching locale for Date/Numbering means you can’t just default a language code (through event or manually) as the language code will be associated to their own local territory formats.