Accpac Multi-Version Support
Sage ERP Accpac has the ability to dynamically add accounting applications. This means independent software vendors (ISVs) can produce Accpac modules that are just installed into an existing Accpac installation. They don’t modify any of the original Accpac files, they just install into a new directory under the Accpac program tree. Additionally when you install a new version of an Accounting Application, it installs into a new directory. You still use the old one, until you go into Data Activation and activate the database to use the new version. Until you do this you keep using the old one. This is all done on a company by company basis, so you could be running one company at G/L 5.5A and another at G/L 5.6A. This means you can activate your companies one at a time on different weekends, perhaps doing one first as a test case (a separate test system would be better), before activating everything to the new version. It also allows you to activate some applications, but leave others at older versions; until customizations get updated (there are compatibility restrictions that are enforced). This feature was put into Accpac for Windows originally due to customer feedback from Accpac Plus (on MSDOS) where people complained about having to convert/activate everything at once.
This is very different from all-in-one accounting applications. These are deployed as a single EXE, when you install a new version, either at install time or the first time you run it, it converts all the data to the new version and you must do this, you cannot continue using the old data. If you want a third party application, it has to be compiled into the main EXE making it very difficult to get a selection of third party applications.
Multi-Version support has allowed us to do things like support multiple application versions on Accpac Online, but using the same version of System Manager. This allows us to host customers running both 5.5 and 5.6 applications on the same server. Basically each Accpac Online Citrix Server runs the latest System Manager and then has all the supported application versions installed. Customers can then choose when it is convenient to move to a new version, they aren’t forced to move on the weekend that we install the new version. This is in contrast to companies like SalesForce.com where you are automatically moved to any new version whether you want to or not. This improves our TCO since we don’t need to deploy separate Terminal servers for each Accpac version.
Although, not always popular, this feature has allowed us to do staggered releases. If development has finished System Manager, G/L, A/P and A/R we can release these while development continues to finish I/C, O/E, P/O etc. Then users can immediately get the benefit from the new features and improvements in the financial modules while still using the older operations modules. We try to release everything at once, since this minimizes disruptions for installing new versions and causes less confusion. But this does give us flexibility depending on business needs. It also allows us to beta a few modules at a time allowing longer beta periods for the core modules.
If you’ve looked at the Accpac programs folder in Windows Explorer, you see a directory structure under the Accpac programs folder of a whole bunch of directories like GL56A, MI56A, TS56A, etc. Basically for each Accpac SDK application, a two character prefix is registered with a central registry. This is then owned by the ISV. There are a number of these two character application prefixes that Sage reserves such as GL, AP, AR, TX, BK, IC, OE and PO. Then the version number is of the form number, number, letter and it can be assigned any way the ISV likes (as long as it increases from version to version). Each version of each product then has its own unique directory. So nothing from GL56A will overwrite anything in GL55A; each version is fully preserved. This is similar to our multi-language support. For the French, we don’t just replace the English strings with French strings; there are ENG subdirectories that contain the English strings and FRA subdirectories that hold the French strings. This way we can install as many languages as we like, and have them all usable at once.
Database activation is something that is common in modular Accounting Packages. If you aren’t using a module, you don’t need to activate it. In this context activating means adding its database tables into the database and showing its icons on the desktop. This shouldn’t be confused with license activation where you are activating your license to show you’ve paid for the product and are free to use it. We keep track of which applications are activated and which version in the CSAPP table in the database. This table contains the list of activated applications and their versions. A separate copy of this table is in each Accpac database. When we open a company we read this table first and then use it to populate the icons on the desktop. When you run data activation, it builds its list by finding directories with names of the form AANNA under the Accpac programs folder, it then chooses any applications that aren’t in CSAPP or have a newer version to populate its list of applications to activate.
This can’t be an entire free-for-all. Generally an application like O/E will feed transactions into A/R and if it uses new features in A/R then it needs a new version of A/R. Usually the higher up the stack the application, the more other applications it requires to be at its version. The Database Activation program will ensure you activate things in a manner that will work, or it either stops you activating or disables applications until their dependencies are activated. Each application has an xx.ini file (like say AR60A\AR.INI) in its application directory; in this file is a compatibility section that looks like:[Compatibility] BK=6.0A TX=6.0A GL=6.0A,S SYSTEM=6.0A OE=6.0A,B PM=6.0A,B EW=6.0A,B
This is for A/R 6.0A and specifies that it requires Bank and Tax 6.0A. A/R doesn’t require G/L be present (if it isn’t it will export its G/L batches for import somewhere else), so GL=6.0A,S means that G/L isn’t required, but if it is present then it must be at least version 6.0A. The ones with the ,B after them are applications that we know depend on us, so Activation can automatically offer to activate them when you choose this one.
Another key enabler of this, are our Accpac Views (or Accpac Business Logic Objects). The View interface remains fixed and we make an effort to keep it compatible from version to version. This benefits us, since this is how Accpac Accounting modules communicate with each other and it benefits customers since the interface to the business logic remains compatible, protecting customer’s investments in customizations. Further we have to be careful to keep the entire programmer APIs in System Manager compatible so we don’t break older versions. This is good for Accpac and good for ISVs since they don’t have to worry as much that a new version of System Manager will break them.
Hopefully this article sheds some light on how the modular nature of Accpac allows us to support things like multiple versions, multiple languages and installable applications.