Background: We’re rolling out our Configurator to Europe where the numbers are represented as 1.000.000,00. We have some PC Lookup Tables that contain numbers. When we return the row, it’s a tilde delimited string then we convert out numbers to decimal. In standard C#, the ConvertToDecimal has an overloaded signature that allows for culture parameter.
Challenges:
Returning the user’s cutlure setting. I cannot get the server side UD function to declare the Erp.Tables.UserFile or Ice.Tables.UserFile. So I cannot get the culture from there.
Assuming I could, I would be able to swap the decimal and commas and then call the regular Convert.ToDecimal function.
Also, if I could new up a class of the IFormatProvider, I might be able to pass that into the function but would have to be able to declare a CultureInfo (in System.Globalization)
Any International Configurator Gurus have a thought?
They are values used in calculations. We have a US rate, a Euro rate, etc. So we need to do math on it, not just display it properly. Technically speaking, when Epicor is creating the string, the culture should be respected there in the PCLookUp routine because this is the place the decimal is being put into a string and it’s just assuming a period for the fractional units and not a comma despite the user’s culture setting.
I kind of wish the context variables held the user’s culture. If I can get to the UserFile in a Server UD Method then I think I can do the rest but I am not sure how to reference it. It doesn’t appear in the Erp.Tables nor Ice.Tables collection.
Yes, I was wondering if you consider this a bug?
i.e. if the string building is native to E10 and the users format culture should be honored at that point?
Not that knowing it is/isn’t a bug would help in the short term…