Stephen Smith's Blog

Musings on Machine Learning…

Posts Tagged ‘international

International Support in Sage 300c

with 6 comments


Sage 300 has always been an international product that is used in many countries around the world. This includes releasing the product in multiple languages, supporting multi-currency, supporting regional settings for things like dates and having flexible configurations for things like sales taxes. As part of the new Web UIs we’ve also carried through all these features into the world of the Web browser. This article describes how some this works, since the browser is a bit different than setting regional settings in Windows.

Generally if you are in a given location, all your computers and users will all be set to use the correct location, so there is nothing for you to do. But if you do want to change things, need to troubleshoot a problem or experiment then these details could be helpful.

Languages and Locales

In the desktop version of Sage 300 you set the language used with the Sage 300 User. Then when you log in as that user, Sage 300 will load the appropriate language files for that user and display in that language. For things like date formats, the desktop product will get them from the Windows regional settings (i.e. the registry) and use that format. In the browser you select a combined language region locale code which determines both the language and the regional settings (like date format). Below is a table for some of these. For the complete list, check out this website.

Sage 300 Language Code Browser Locale Code Description
ENG en English
  en-AU English (Australia) (date format dd/mm/yy)
  en-US English (US) (date format mm/dd/yy)
FRA fr-CA French (Canadian)
ESN es Spanish (not support in Web UIs until Feb release)
CHN zh-Hans Chinese (Simplified)
CHT zh_Hant Chinese (Traditional)


I didn’t include South Africa which is en-ZA because the date format for that is yyyy/mm/dd. When I Googled en-ZA, all I got was complaints that it should be dd/mm/yy. So if you are South African and like yyyy/mm/dd as your date format then by all means select en-ZA. However is you prefer dd/mm/yy then you might want to pretend you are Australian and select en-AU. We won’t change our English as a result, so hopefully we can avoid any conflicts about shrimp on the braai vs barbie.

You can set this for any of the Browsers by going into their settings and adding languages and setting which is the current one. For Chrome and Firefox there is a really handy add-on that puts the list in a convenient menu at the top so you can easily toggle between these. In Chrome this is the “Quick Language Switcher”. In Firefox this is the “Quick Locale Switcher”.

Below is G/L Journal Entry in various languages and date formats. Note that data in the database is not translated, which is why there is English text in some of the data fields.

G/L Journal Entry displayed in English (Australian)

G/L Journal Entry displayed in English (Australian)

G/L Journal Entry displayed in French (Canadian)

G/L Journal Entry displayed in French (Canadian)

G/L Journal Entry displayed in Chinese (Traditional)

G/L Journal Entry displayed in Chinese (Traditional)

Configuring the Business Logic

Using the Browser settings affects most things, but some language strings and locale settings come from the Business Logic layer. The Business Logic does get some of its settings from Windows, so to get these in sync with the Browser you should set the Sage 300 application pool in IIS to run as a user that is set to the regional settings that you wish. You also have to change the user that the Sage.CNA.WindowsService Service runs under. By default the application pool and the Sage.CNA.WindowsService service will run as “Local System” which works, but has a few problems:

  1. Local system is very high in security settings, so it’s safer to set this to be a regular user (we don’t require admin rights).
  2. Local system can’t access network resources, so if the shared data folder is on another server you need to change this to a user that can access the shared data folder.
  3. It’s easier to login as a regular user and set their settings to what you need.

You should also ensure that the Sage 300 User has the correct language set since any messages generated by the Business Logic will be in the language of the Sage 300 User.

Hybrid Usage

Most people will still be using the VB screens either due to customizations or modules that we haven’t moved to the web yet. Generally if the Browser, Windows users and Sage 300 users are all set to the same thing then you will get consistent languages and regional settings across everything.


As Sage 300 moves into the Browser we want to move our international heritage as well. In the web world there is much better support for many of these things and you will see this in our new Web screens.

Written by smist08

September 26, 2015 at 5:25 pm

International Support in Accpac

with 10 comments


Sage ERP Accpac has installations in hundreds of countries. Accpac has traditionally had strong sales in Canada, the US, the Caribbean, South-East Asia, Africa, the Middle East and Australia/New Zealand. Additionally we have scattered sales in many other regions. How does Accpac address the varied needs of so many legislative jurisdictions, locations and cultures?

Everything in this article applies to both Accpac 5.6A as well as the forthcoming Accpac 6.0A. However as we move to becoming a web based application, we inherit all the good work performed by the WWW standards bodies, which are very good at ensuring the Web is accessible to all. One such standards body is: For instance in I talk about how our new screens will automatically adjust to string lengths as well as how they can automatically lay themselves out in right-to-left format.


First off Accpac is multi-lingual. Accpac supports installing more than one language at a time and languages are associated with users. There is not a French version of Accpac nor a Spanish version; instead you can add French or Spanish as installed languages. Then you can have some users running French, some Spanish and some English. This is especially important for International companies with branches or divisions in several countries. Of course the data in the database only has one version of each string, so if a French user enters say a batch description in French then a Spanish user will see this description in French. But all the forms, reports and messages will be in the correct language for each user. Out of the box we support English, French, Spanish and Chinese (Simplified and Traditional).

Regional Settings

At the next level we have to take care to honor regional settings. These include things like date formats (mm/dd/yy versus dd/mm/yy, etc.), number formatting characters (whether a comma or period is a thousands separator or decimal point), money symbols and such. Generally we just have to be careful to use the values set in the host Browser or Operating System and use them; along with a number of settings we configure in Common Services.


Accpac has always had multi-currency ability. Generally you set your company with a “home” currency, and then all incoming/outgoing monetary amounts are in a “source” currency. We always report amounts in source and home currencies. You have to be careful in reports that you add up amounts in the same currency or the totals won’t make any sense. Most reports provide a table of the totals of each source currency and then a grand total in home currency. We support currencies with 0, 1, 2 or 3 decimal places. We also support money amounts with 18 significant digits (15 before the decimal and 3 after). This is more than the 16 digits that double precision floating supports (a method used by many competing Accounting Packages). When converting currencies we support either multiplying or dividing the exchange rates. We maintain centralized tables of all exchange rates, but you can override these at any point.

We also support some additional amounts in third currencies. For instance in Singapore, by law if a company does over 50% of their revenue in a given currency, say USD, then they have to use that currency as their home currency. However they still need to report all sales tax in Singapore Dollars. So maybe they mostly sell to the US, but make a sale to Thailand. So they are paid in Thai Baht, convert the amount to USD for their sales totals and report the sales tax in Singapore Dollars. This is the reason for our “tax reporting currency” feature that allows you to report your sales taxes in a different currency than your home currency.

In version 5.5A we overhauled the currency revaluation process. This was to comply with the new international standard FRS 21. Although this won’t be required in North America for some time, it was required much sooner in other jurisdictions, such as South-East Asia where multi-currency transactions are very prevalent. This new method is quite a bit more complicated than what Accpac was previously using, but this shows our commitment to addressing International concerns and maintaining International standards.


We don’t produce localized versions of Accpac, there is only one version and we add general support for all jurisdictions there. Rather than shipping an Australian version that supports Australian sales tax and an American version that supports US sales tax, we ship one version with a powerful enough sales tax engine that can support all the sales taxes we have encountered. This then easily allows International companies to use the same Accpac programs and databases for all their transactions.

The reason we added surtaxes to our sales tax module a few versions ago was to support sales taxes in India. In India there are 5 sales taxes and two of them are surtaxes (taxes on tax). So rather than just adding a customization for India we added a general feature, so if any other regions have surtaxes like India, then they are already set. Our hope being that we have a strong enough general support to handle whatever is thrown at us.

Fortunately GAAP (Generally Accepted Accounting Practices) are applied fairly universally. As more countries compete globally and look for global investment, more and more countries are insisting on GAAP. Generally all countries are adopting standards that are agreed on internationally, just that the adoption times can be quite different.

This isn’t to say we wouldn’t produce localized modules. The nice thing about Accpac is that you can add program modules without requiring changes to the base product. Hence we can offer an XBRL Financial Reporting module in Singapore to meet Singapore government reporting requirements. In a similar way Sage regions can develop custom modules for their market, perhaps such as an import/export tax module for India.

Market Differences

A big difference in each geographic market is also the definition of an SMB (Small to Medium Sized Business, Our typical sales in Africa and Asia are to much larger companies than we usually sell to in North America. This leads to quite a difference in the feature requests our Product Management team receives from around the world. For instance we might receive requests from Africa for much more sophisticated Inventory processing, whereas from North America they are often looking for product simplification and ease of use.

This is a bigger cause of regional differences than local regulatory requirements. Often the requests we get from one region for one type of industry would be valuable all over the world for that sized company and that particular industry. It’s just that we seem to sell to different industries and different sized companies in different regions.


Certainly being an International product has its challenges; but, there are lots of rewards as well. I really enjoy traveling to the International Sage Insights and Visions conferences in Australia, Africa and Asia. I find the challenges and accomplishments of the partners in each region have a lot in common. I’m always amazed at the way Accpac is customized and deployed to handle very diverse needs.

Written by smist08

July 17, 2010 at 7:51 pm