Country code column for p_country

wolfganguhr

In order to run the internationalization properly we have to get a look to the the information required by windows. Standardly you can use the following routine to get a country customized value of a number or a date.

try
{
numberFormatInfo =
new System.Globalization.CultureInfo(
strCountryCode, false).NumberFormat;
}
catch (System.NotSupportedException)
{
numberFormatInfo =
new System.Globalization.CultureInfo(
String.Empty, false).NumberFormat;
}

In this case we need a specific value for strCountryCode. A value of "DE" for example does not work because Windows distinguishes in different cultures. In Germany this is "de-DE". This is important because "en-GB" for example has the short-date-format dd/mm/yyyy and "en-US" mm/dd/yyyy. So we have no other choice than to store this value somwhere.

Of course in a very first version of openpetra you can use the standard user settings of the windows where the openpetra client is runnig. But in this case the system has no international client compliance.

In the catch fork you will find String.Empty as a value of the country code which means that we have to select the "international invariant culture" - whatever "international invariant" means.

Acually I think it may be better to use the local user settings only and to skip the international client compliance until a decision has been made to add a column to p_country.

Best regards
Wolfgang

christiankatict

Hi Wolfgang,

I understand what you mean, but I am not sure what we would use this information from the new DB column in p_country for. Can you give an example?

NOTE:
openPETRA's culture can be set per user. Each user can adjust it in the 'Settings' section in the main menu and I think it defaults either to the Windows OS default culture setting that the user has stored with his user profile in Windows if the user hasn't chosen something different, or to the 'Invariant Culture'. Timo would more about the defaulting business as he implemented the culture selection feature.

wolfganguhr

Hello Christian

The example is relative easy. OpenPetra is installed on a client pc and there the accounting of two offices is done. It is the accounting of a German office in one ledger and a English office in the other. If we refer to the culture settings of the client, then one dialog produces incorrect results. And in case of a dialog this migt be acceptable but not in case of a report.

Ok in Europe that may never be a problem but in Afrika or Asia?

Best regards
Wolfgang

christiankatict

Thanks for the example.

While I agree that the situation you describe could happen, it isn't that likely - according to Rob it either hasn't happened in OM, or people didn't mind that the reports for different ledgers representing different countries used the same thousands separator character and decimal separator character. In Petra 2.x these two characters are specified site-wide in a configuration file (the '.pf file') and they affect data entry and reports alike.

If we would want to make things work in your example, a Ledger would need to be tied to a Country, which it currently isn't. Although a Ledger is tied to a Unit, and that Unit could have an address, which could point to a Country, this connection would not be transparent to Finance users and there could be circumstances where the Unit's address doesn't match the Country for which the Ledger is used for. Also, there are Ledgers that aren't tied to Countries - although they are tied to a Unit, this Unit doesn't represent a Country and will probably not even have an address because it won't make sense.
The only solution that could overcome those limitations would be to introduce a new setting in the 'a_ledger_init_flag' table which could specify the Ledger's connection to a Country. Through that the Ledger's Country could be either not set or set to some specific country, and the Country of the Unit's best address would not need to be inquired.

Timo would need to give input at this stage if the user's chosen Culture setting in openPETRA affects the openPETRA reports, as the reports are calculated entirely on the server and therefore would use the Culture of the PetraServer's OS, unless Timo has thought of that and makes the report calculations pick up the user's UserDefault for the Culture and set the PetraServer's report calculation Thread to that Culture.
But the question is whether it would even be desireble for the reports to pick up the user's Culture setting, because if they do, one could end up with the situtation in which two different openPETRA Finance Module users of an openPETRA site would have two different Culture settings and when they produce the same report it could well have different thousands separator character and decimal separator character, depending on which user printed it. That result might not be what is wanted, to say the least, because some reports need to be filed away in folders and therefore these reports need to be consistent in how they use the culture setting, I suppose.

Anyways, I can't imagine that the implementation of a Culture setting for a Ledger would be a high priority as this wasn't a problem so far in such a complex and diverse organisation as OM...