When the WebConnector's host OS is setup with a different culture (having a different decimal symbol) than the server running the QBSync.QbXml library, the values parsed in QbSync.QbXml.Objects.FLOATYPE from string to decimal are being parsed wrong. This is the case when QBSync.Qxml is running on en-US, where the decimal symbol is point (".") and the WebConnector is running on fr-CA, where the decimal symbol is comma (","). eg, an amount sent in the original QbXml by the WebConnector as "20,00", will be parsed to "2000.00".
Looking at the code, we can see that the private method Parse in QbSync.QbXml.Objects.FLOATYPE implementation, used to parse the values from string to decimal is using the Decimal.TryParse overload that receives only the string as parameter. This overload will use the current thread culture (in the case of a web app).
private static decimal Parse(string value)
{
if (decimal.TryParse(value, out decimal output))
{
return output;
}
return 0m;
}
This issue could be solved using the Decimal.TryParse overload that receives also the number style and the culture as parameter. It means that the culture should be sent a) as parameter on every call to deserialize a FLOATYPE, or b) sent as parameter in the FLOATYPE constructor and use it in the Parse method.
This is a little example to illustrate the problem and the solution:
https://dotnetfiddle.net/V20rXq
This issue is probably also impacting the parsing from decimal to string, however, after some tests I've made with the WebConnector, looks like it is able to manage properly both decimal symbols regardless the host culture.
In my opinion, it is important that the culture will be set explicitly for each usage of the serialization logic, or at the app initialization (or both), to highlight the fact that the culture used to serialize/deserialze the QbXmls actually matters, and may impact the values of some properties.
When the WebConnector's host OS is setup with a different culture (having a different decimal symbol) than the server running the QBSync.QbXml library, the values parsed in QbSync.QbXml.Objects.FLOATYPE from string to decimal are being parsed wrong. This is the case when QBSync.Qxml is running on en-US, where the decimal symbol is point (".") and the WebConnector is running on fr-CA, where the decimal symbol is comma (","). eg, an amount sent in the original QbXml by the WebConnector as "20,00", will be parsed to "2000.00".
Looking at the code, we can see that the private method Parse in QbSync.QbXml.Objects.FLOATYPE implementation, used to parse the values from string to decimal is using the Decimal.TryParse overload that receives only the string as parameter. This overload will use the current thread culture (in the case of a web app).
This issue could be solved using the Decimal.TryParse overload that receives also the number style and the culture as parameter. It means that the culture should be sent a) as parameter on every call to deserialize a FLOATYPE, or b) sent as parameter in the FLOATYPE constructor and use it in the Parse method.
This is a little example to illustrate the problem and the solution:
https://dotnetfiddle.net/V20rXq
This issue is probably also impacting the parsing from decimal to string, however, after some tests I've made with the WebConnector, looks like it is able to manage properly both decimal symbols regardless the host culture.
In my opinion, it is important that the culture will be set explicitly for each usage of the serialization logic, or at the app initialization (or both), to highlight the fact that the culture used to serialize/deserialze the QbXmls actually matters, and may impact the values of some properties.