Stephen Smith's Blog

Musings on Machine Learning…

Posts Tagged ‘TCO

Accpac in the Cloud

with 8 comments

It used to be that running in the cloud ( meant using a generic SaaS based web application, but now a days technology advances have offered many choices beyond this basic option. Virtualization technologies have advanced in leaps and bounds. Hosted solutions providers now offer many innovative options based on both regular and virtualized solutions. Plus the capabilities of SaaS web applications have improved quite a bit. Today Accpac has several cloud based solutions available and in the future we will have a full spectrum of solutions. Combining Terminal Services or Citrix with Virtualization is now a very powerful method of economically hosting enterprise applications. It is at the point where you can host your Windows based Enterprise application in the cloud and access it from an iPad (by running the Citrix client application

In some ways this wealth of riches has led to some confusion. There are so many options on how to deploy an application that it gets quite difficult to wade through all the choices and all the various claims being made by various hosting and application vendors. This blog post will attempt to outline the main choices and trade-offs, along with pointing out the various places that Sage ERP Accpac plays now and will play in the future.

Cloud Categories

The cloud usually means that a client is running an application on a remote server via the Internet. There are many ways this can be achieved. Many of the options come down to who owns what (you or the vendor) and what type of application is being talked about (Windows or Web based). However the following are the 4 main categories.

  1. Hosted Server. Server is owned by customer and maintained in a central data center but accessed via the Internet.  This is usually a Windows based application and the customer owns everything (server and software), but is outsourcing the physical care of the server and often other services like backup. A typical company in this area is Rackspace (
  2. Shared Virtual Server. A server farm is owned by the data center vendor and the client owns virtual server images that run on that farm. Here the customer owns the software (usually Windows based), but the data center owns the hardware. Typical of this is the Amazon EC2 service (
  3. Single Tenant SaaS. Vendor owns servers and images. Runs each client in their own image (whether virtual or multiple processes). Here the application is usually Windows based (but often we see web based applications here also). AccpacOnline is a good example of this.
  4. Multi-tenant SaaS. Vendor owns everything, client runs within a shared image or process (usually distributed over many servers).Here the application is always a Web application.

Any of these could be running web applications or desktop applications, but we highlight the most common cases above. The costs and who pays them is different in each situation and there are pros and cons to each. The differences between these are often blurred as companies offer hybrid solutions. Also some vendors try to define a category exactly as they implement it and claim anyone that does it differently is incorrect, but like anything there are always many choices.

Customer Goals

So why are customers demanding cloud based solutions rather than just buying software and installing it on premise? Below are some of the goals that clients are trying to achieve:

  1. Save costs by not having a data center. Save on requiring extra air conditioning, backup power supplies, hard disk backup and space. Save on routine maintenance like performing backups.
  2. Save capital equipment costs by not purchasing hardware which devalues quickly and needs to be replaced often. Have fixed constant monthly expense instead.
  3. Save capital software purchase expenses. Don’t want large up-front purchase, would rather pay much smaller monthly fee. Even if this is more expensive over x years, doesn’t require initial outlay. (Some on-premise software can now be “rented” as another solution to this).
  4. Save HR expenses by not needing to hire IT staff to run and manage corporate hardware and software.
  5. Don’t have to perform software installation or maintenance.
  6. Ability to access their applications safely and securely from anywhere in the world whether through laptops or other mobile devices.
  7. Desire to use a modern web-based application which has the ease of use of Facebook or Amazon.

When considering cloud solutions there are a number of problems that are usually cited that clients try to avoid:

  1. Lack of customization in cloud offerings.
  2. Lack of ability to use/integrate other software.
  3. Lack of owner ship of data. Lack of ability to get their data. What happens if the cloud vendor goes out of business?
  4. Security concerns, how safe and private is their data?

All solutions have an answer to these; customers just have to determine if those answers are sufficient, cost effective and achievable.

Vendor Goals

To be fair, many vendors are pushing cloud solutions quite strongly, and this isn’t for purely altruistic reasons. What are the vendors trying to achieve? Below are the goals that vendors are trying to achieve:

  1. Obtain a more steady cash flow. Steady subscription revenue, rather than relying on less frequent large purchases. Easier for financial planning and more recession proof.
  2. Obtain access to a larger market by being able to server the world from a single location.
  3. Can organize so only need to support one version of the software, reducing costs. Similarly you only need to support one hardware/operating system environment.
  4. Can have more direct contact with customers since you are sharing an operating environment – more control of ECE (Extraordinary Customer Experience).
  5. For hosting only vendors that aren’t software vendors as well, then this is their entire business, so of course they are selling it as hard as they can.

Sage ERP Accpac in the Cloud

Now let’s look at the options for Accpac in the cloud. At the beginning of this article we looked at four cloud categories, now we’ll look into how Accpac serves these four categories.

  1. Anyone can do category 1. This is basically just installing an on-premise application like Sage ERP Accpac 5.6A on a terminal server and then physically moving that server to a hosting provider for care and feeding. Then clients access the server either using RDP or Citrix client.
  2. This option is very similar to category 2, except rather than install on a physical server you install your software into a virtual image either provided or specified by the hosting vendor. Then you transfer this image to the vendor who runs and maintains it. If the vendor is associated with Sage or Accpac already, they may provide a virtual environment with Accpac already installed.
  3. Both Accpac and SageCRM have operated single tenant SaaS environments for some time with and  Accpac operates the desktop version of Accpac in a SaaS manner using Citrix to manage things, but each client runs in their own separate server memory space when running. SageCRM is web based but requires a unique instance of SageCRM running for each customer. Here you pay by the month, can run VBA macros, Microsoft Office and a selection of ISV products.
  4. Sage ERP Accpac 6.x has better multi-tenancy support than the current AccpacOnline because all clients run in the same server processes and share the same server memory. The goal is that once we have moved all the accounting screens to be true web based screens (after 6.1A), then we can deploy them as a SaaS solution. As part of the development of the infrastructure of Accpac 6.x, we ensured we plumbed in the support for a multi-tenanted deployment of this type. Once we enter this world we will be a try true web based application that doesn’t require Terminal Server, Citrix or Virtualization Technologies to run. It will be a modern web based application that you can run either on-premise or as a true SaaS web application.


It used to be that a big competitive advantage of a true web based SaaS solution was a much lower cost by being able to run far more users per server. However with all the advances in Virtualization Technology and Terminal Server/Citrix a lot of this gap has been narrowed, making solutions of this type very cost competitive.

As we can see Accpac already has many options for cloud deployment that achieves many of the customer’s goals in considering a cloud application. Then in the future we go beyond this to offer a true Web Based SaaS solution. As these technologies progress the TCO (Total Cost of Ownership) will come down as we can host more users per server. For clients it becomes easier to get customized solutions in the cloud with all the attendant cost savings, including better usability and accessibility.

Written by smist08

December 4, 2010 at 6:30 pm

Sage ERP Accpac 6.0A Compelling Installed Base Value

with one comment

As we finish preparing Sage ERP Accpac 6.0A for release, much of the buzz around this release is the new Web Based technology platform. But for existing Accpac customers, what is the compelling business value? Why will existing customers want to upgrade? Will this upgrade be disruptive?

Upgrade Costs

A lot of times choosing to upgrade is a matter of balancing the costs of the upgrade versus the benefits of running the new software. This release is a little different from the past few releases where we were updating the accounting functionality. In the past few releases the costs of an upgrade were taken up by things like the time to convert the database to the new version, the time to verify and update customized reports, the time to verify and update macros and other customizations and then the time of training on any new or affected existing features. With version 6, the database conversion is much smaller than the past few releases and the changes to the database and Accpac Views is very minimal. This means that database activation should be relatively quick and painless, and that very few changes are required to existing customized reports and macros. In fact you could just install the version 6 update to the existing functionality, activate to version 6 and be done. This would reduce your upgrade cost, but not give you the full benefit of the new version (you would still get the lock fiscal periods by module functionality).

The main new features of Accpac 6 are accessed from the new Accpac Web based Portal (or in the case of the new CRM Integration, requires that this be installed). This requires a Web server to run. If you are already using SageCRM then you already have a Web Server and just need to determine if it has the spare capacity to run Accpac as well (which it might already be doing via the current CRM integration). Or you might have a file server that is only doing file serving and has plenty of spare capacity to run the Accpac web components. Otherwise you will need a new server. Installing the new Web components is largely the same as installing Accpac on a current file server, since all the new web components are installed as part of this process. For more information see:

Upgrade Benefits

When we were deciding on the roadmap for rolling in out the new Accpac 6 platform there was a lot of debate about whether to roll out modules (like G/L) ported to the new web based architecture first, or to roll out new features first. A lot of this discussion focused on who would benefit: new users versus the installed base. We do a lot of surveying of customers and a lot of visiting customers to determine what the real pain points are and what the real business needs are. From these studies it was clear that improved reporting, improved business intelligence and improved CRM integration were of a higher need than getting existing modules in the new framework. So below we’ll quickly mention each feature and its benefit to current Accpac users.

Locking Fiscal Periods by Module

One very frequently requested feature is the ability to lock fiscal periods by module. This is now incorporated into Accpac and available to all users whether you use the new web component or not. This is a top vote getter from our idea suggestion web site. This feature gives you the ability say to lock a fiscal period for AR, AP, IC, OE, PO but keep it open for GL as you finish up month end. For more information on this see:

Reporting and Business Intelligence

A very common feature request is more and better reporting and business intelligence. We made improvements here in 5.6A with the addition on Accpac Intelligence. With 6.0 we continue with the addition of the Portal Dashboards and the new Accpac Inquiry Tool. The goal of the Portal Dashboard is to give you an instant view of the state of your business in a simple graphical snapshot. For more information on the new dashboard see: The goal of the new Accpac Inquiry tool is to give you a simple way to view your data without requiring custom Crystal reports. We made the tool extremely simple so that anyone can easily use it to study their Accounting data and to use it to make informed business decisions. For more information on Accpac Inquiry (called Adhoc Query when I wrote this blog article) see:

The New Web Portal

The new Web based portal is a new launch point for doing your work in Accpac. You use it to access all the new functionality including running Accpac Inquiry and viewing the new Dashboards. Plus you can run any existing accounting screens from the Tasks menu or from the easily customized shortcuts bar. For more information on the new portal see: and for more information on running accounting screens see:

Lowering TCO

A key initiative as we move forward is to reduce the Total Cost of Ownership (TCO). This includes making installation and upgrading to new versions easier, providing better active help to prevent you getting stuck and arranging forms for maximum productivity. For all the new features we are developing we are spending a lot of time making sure they are easy to learn and once learned you can use them very efficiently. Hopefully you will see this new ease of use in the new Portal and in the new SageCRM integration components for Quotes to Orders.

The goal in the end is to have a single server install and to not require anything be installed on the workstations, so for an upgrade one simple install is all that is required.  We won’t be there until all the accounting screens are moved over to the new framework, but this is the start of that journey.

However as we do move to the new Web accounting screens we will still leave the current Windows screens in place. This allows you to go to these new versions, but to move to the web screens at your own pace. You can even run a mixture of forms since they all access Accpac through shared business logic. This means that if you have invested heavily in customizations, you can keep using these, you don’t need to invest in moving these to the new screens. You can also choose to have some users use the new screens, some the current by the individual user’s preference. Sometimes people have such good muscle memory of using the current screens they can enter data in their sleep and don’t want to lose that productivity.

For more information on TCO see: For more information on the new User Assistance (help) system see:

Quotes to Orders

SageCRM is already a nice modern Web based application. A common complaint about our CRM integration is that whenever you run an Accpac screen a Windows form leaps up out of the nice CRM web pages. This is disjointing and makes it clear you are running two applications. With Quotes to Orders we have developed web based versions of various screens to do with quote and order entry using the new framework and included them in our CRM integration. So now the Accpac screens are styled like CRM pages and make it appear as if you are staying in one application as you move between CRM pages and Accpac pages. In addition the quote and order screens have been made far easier to use by sales people so that they can be more productive taking orders. For more info on Quote to Orders see:



Sometime people just see upgrading as a cost of doing business; that they have to do it now and again to remain supported and to work properly on the newest versions of Windows, Office or other components. We do want to make upgrading have a lot more value than this. And we do want to reduce the disruption and cost that upgrading entails.

We’ve worked hard to reduce the costs of upgrading and worked hard to maximize the value by listening to what you the customer really wants. Hopefully this approach has provided sufficient ROI that people will want to upgrade and the percentage of people that do will be quite high. Hopefully this approach gives you confidence in the future of Accpac that we are actively developing useful new features and technologies while protecting the investments you have made in the present.

Written by smist08

October 16, 2010 at 4:44 pm

Posted in sage 300

Tagged with , , ,

Accpac and It’s Databases

with 15 comments

Sage ERP Accpac supports running using either Pervasive.SQL (, Microsoft SQL Server ( or Oracle ( Database Servers. This blog posting is going to talk a bit about how Accpac Accounting applications access the database, give some rationale for the way we do things and look at where we may go in the future.

Accpac Plus, the original character based product for first CP/M ( and then MS-DOS ( used a proprietary built-in database. When this product was developed there weren’t standard off the shelf packages to use. This was a simple ISAM based package that was fast and easy to install and configure. The limitations were that:

  • It didn’t support database transactions so if something failed the database was left corrupted.
  • It used record locking as its multi-user model, so once too many people were doing things, too many records would be locked and things would grind to a halt.
  • It didn’t have a server version, so relied on file system locks which were hard to support for all the different network operating system.
  • It didn’t support SQL and hence didn’t fully support ODBC or any other standard interface mechanism making it hard to use external tools like for reporting.

So when Accpac for Windows was developed, we made the decision to use standard off-the-shelf databases. We decided to base our new database support on transactions and to define a set of requirements that a database would need to support to work with Accpac.

CA-Accpac/2000 originally shipped supporting Btrieve 6.15, and then with version 2.5A we added support for Microsoft SQL Server 6. Later we added support for IBM DB2 and Oracle Databases. We can easily move Accpac data from one database to another via our Database Dump and Load utilities.

Along the way we’ve evolved our API and easily moved from database version to database version. Many third party tools integrate with Accpac through open database interfaces. We currently have a very robust and scalable solution.

Accpac Database API

Accpac is a three tier application with the business logic separated from the database. Our business logic objects (the real core of our Accounting Applications) communicate with the database via a common database API. Then we have database drivers that translate this API into calls to the database server currently being used. How the database driver accomplishes this is entirely up to the driver. Our SQL Server driver uses ODBC to communicate with the SQL Sever Native driver. Oracle uses the Oracle ODBC driver. For Pervasive we communicate with both the relational layer using SQL calls, and with the transactional layer making direct Pervasive API calls. The key point is that all this detail is invisible to the Business Logic. The application programmer creating our business logic objects, just needs to know our Accpac database API to do his job. Then all the differences in the databases are isolated to the Accpac database driver. If a new version of a database server is released and Accpac needs to be updated to support it, then its just a matter of providing a new database driver, without requiring any other application changes.

The Accpac database API includes a number of record oriented API calls, a number of meta-data calls and a number of set based operations. The record based APIs operate on one record at a time, such as read a record based on a supplied key, update that record. The meta-data calls return information about the structure of the database, things like get a list of all the tables in the database, get information on all the fields in a table. The set oriented API calls operate on a set of records at a time. Such as read all records where the description starts with A, or update all records changing any with customer number 1200 to 1400, or delete all records with status “deleted”.

Accpac Architecture Diagram


Reporting works a bit differently. We use Crystal Reports as our reporting engine and then Crystal provides the mechanisms to have database independent reports. From Accpac the same Crystal Report is used for Pervasive.SQL, Oracle and SQL Server. We just point Crystal at the correct database and provide the necessary connection information and then let Crystal do the rest. We provide an Accpac reporting API which then handles the details of talking to Crystal. Originally this API was used to talk to CA-RET the Computer Associates Reporting tools, then it was converted to talk to Crystal’s crpe32.dll interface, later to Crystal COM’s interface. With Accpac 6.0A we are upgrading to Crystal Reports 2008 and will use the .Net interface for the VB UIs and the Java interface when running Crystal from the Web. Even though the way we do reporting has changed quite a bit over the years, this has been largely invisible to the applications which just talk to Accpac System Manager’s API and then let System Manager take care of the details.

The Accpac Financial Reporter accesses the database through the Accpac Business Logic and hence the regular Accpac Database API. Accpac Intelligence and Accpac Insight work in a similar manner to Crystal and provide their own database independent mechanisms to access the various databases. Most other reporting solutions also work this way.

Database Requirements

Accpac does have a number of minimum requirements for any database it supports. This includes things like number of fields per table, number of keys supported, record length and such. One key requirement is that the database supports database transactions. As long as a database meets these minimum requirements then it is possible to write a database driver for Accpac to use that database. Note that supporting SQL is not a requirement.

Database Transactions

At the core of Accpac’s database support are database transactions. Any changes made to the database have to be done inside a transaction. A transaction is a group of database operations that are either all applied to the database, or none are applied to the database. So the application never has to worry about half of them being committed to the database. A key differentiator of database servers is how well they handle transactions. The application rule for Accpac is that when the database is changed, operations must be grouped together into a transaction so that the database always has full application integrity. This includes things like the General Ledger never being out of balance. When G/L entries are posted, each entry is a transaction and the database goes from one in balance state to another. This means that if something crashes on either the server or workstation, or an unexpected error occurs then the database will not end up in a corrupt state. Database integrity is always maintained via database transactions.

Multi-User Model

Then our multi-user model builds on the transactioning foundation. Within Accpac we use optimistic concurrency ( as our multi-user model. If two users go to edit the same record, both users bring the record up on their screen at the same time, then they make some changes to various fields, then both hit save. Now both users started with the same record and made independent changes and both want to save, what should the system do? In the most basic optimistic concurrency model, the first person to save wins, their changes are committed to the database and the second user gets an error message the “Record was modified by another user”. With optimistic concurrency we can be a little more clever than this, and for the second user, we could re-read the record and see what the first user changed and if they are unrelated fields then combine our changes and re-save the record. We do this in a number of cases, but it requires a bit of application support to define what “un-related fields” means. The alternative to optimistic concurrency is to lock the record when the first user reads it, and not let the second user read the record at all. The second user would get a message saying that someone is editing the record and they can’t access it. This saves the second user possibly losing some work. However it imposes a huge multiuser penalty since if a lot of records are locked, then it is highly likely people are going to trip over the locked records all over the place and be blocked from doing work. They won’t be able to load the record just to view it. Accpac Plus used this model of multi-user processing and it restricted Accpac Plus to pretty much only having 25 users, since after that, the number of locks would just cause too many problems. Most systems with high numbers of users use optimistic concurrency.

So what does optimistic concurrency have to do with database transactions? Most document entry in Accpac involves updating and inserting many different database tables. What happens if you are save an O/E Order and you have updated 5 tables and then on the sixth you get an error? You can either re-read the record and reconcile the two sets of changes or you have to abort saving the order. If you have to abort saving the order, you need to do a transaction rollback to undo the changes to the first 5 tables. Fortunately with database transactions this is easy, and you never have to worry about corrupting the database if you encounter an error (multiuser or otherwise). So for complicated header detail entry, you can only really do optimistic concurrency if you are based on a transactioning model.

Stored Procedures and Database Scale-out

A common question is why we don’t use stored procedures? Besides the problems with portability across databases and the attendant lock-in to one solution, there are definite problems with scalability. Since Accpac is aimed at the mid-market, like most such products we don’t support arbitrary database scale-out. This means if you have trouble with the performance of the SQL Server, you just can’t add another SQL Server to solve the bottleneck. We of course do support many configurations with multiple database servers, but there are restrictions. However you can have as many application servers as you like. If you run workstation setup type client server then every workstation is an application server and takes a share in running the business logic. If you deploy via Terminal Server or Citrix, they you can add as many of these as you like (either dedicating users to specific servers or adding a load balancer). So we want to put as little load on the database server as possible, to allow users to use one database server for as long as possible. If we ran stored procedures on the database server then this puts considerable load on the server and makes the database server become a bottleneck quite quickly. People often point out that they are getting slow, but SQL Server is only say 15% utilized, and we say add another applications server. They say why not shift more work to the database server. The problem being that once the database server is full, you’re done. Adding application servers is easy.

We support a couple of configurations with multiple database servers. One is to split a big company into multiple divisional companies within Accpac then run each divisional company on a separate database server. You then combine the data for financial reporting using G/L Consolidations. Another configuration is to add a second database server that is a replicated copy of the primary. Then if you have a number of users that only do reporting then you point them to the replicated server (and you can have as many of these as you like). However you can only have one primary server where database updates occur. But often reporting is quite a load on the database server and moving this to another server can really help.

True database scale-out means you can add database servers at will, but this requires the application be structured quite differently. For instance for Order Entry you might have one server designated the primary, it would contain a small Order header table with the order number and a link to the database that actually contains the order. So as people perform Order Entry, each order only requires one simple insert on the primary server and the actual order is placed on one of the other servers in a round robin fashion. This then allows scale-out of the Order Entry process, since you can add as many of these slave database servers as you like. The complexity comes in for reporting, since now to generate a report on a range of orders, you have to consolidate the data from a number of database servers, greatly adding to the complexity.

The Future

Originally our next database target was going to be MySQL. One reason being to reduce the TCO for our customers, as Sage as a very good deal for distributing MySQL with our applications. Another reason is to implement SaaS down the road, where to be economical, we have to ensure that we don’t have to pay all the subscription revenue to other software companies. However since Oracle bought MySQL, it’s become very questionable whether MySQL will maintain its TCO advantages or whether Oracle will invest in it sufficiently to keep it competitive. So right now we are taking a wait and see approach to MySQL.

Another approach that is becoming popular are the so-called “NoSQL” databases ( which stands for ‘Not only SQL’. These databases are all about database scale-out, but since they think about large scale scalability from the start, they tend to be very different from relational (SQL) databases. Often they load the entire database into memory, and will naturally partition the database over multiple servers in a redundant manner. Often these databases remove the “hard” parts of SQL to make data access faster and more scalable. One example of these is Google Fusion (

Along these lines the Apache foundation has been developing the Hadoop platform ( along with the HBase database ( This is a very ambitious project to provide the entire infrastructure necessary to build fully scalable large scale web based applications like a Facebook or Twitter.

Some of the ideas from the Web have a place in Accounting Applications. For instance quick natural language Google-like searches. If the database is partitioned over 5 servers then these server can each produce their part of the results in parallel and then they can be combined and returned. The key point being the parallelism employed to return possibly difficult queries quickly.

Some ideas are perhaps not going to be so popular. For instance when you refresh Facebook you often get different results each time you do it. Facebook sends out the query to a bunch of servers and then combines all the results returned in a short fixed amount of time and displays your page, but any results coming late from a slow server are ignored. Will accounting users appreciate getting most of the results quicker rather than all the results slower?

Database technology is the foundation for Accounting Applications like Sage ERP Accpac. Most Accounting Applications started life using flat file ISAM packages or home grown solutions. Then at some point made the jump to standard SQL databases. Certainly we’ve gotten a lot of mileage out of SQL, but as the amount of information in data warehouses and other corporate databases grows, where we join to data out on the internet, are we at the point where we are going to see the start of a transition to the next big thing in databases?

Written by smist08

July 10, 2010 at 4:23 pm

Sage ERP Accpac 6 User Assistance

with 6 comments

As Sage ERP Accpac makes its transition from being a traditional Windows desktop application to becoming a more modern Web based application, we are looking to greatly improve the User Assistance within the product.  We are applying the principles of User Centered Design ( to make the product far easier to use. As part of this we are adding all sorts of help and tips integrated right into the screens. For instance in the screen shot below of our Accounts Receivables – Days Receivables Outstanding snapshot, when the user hovers the mouse over the 181 days label, we popup a tooltip help box that describes what this number is and how it is calculated. This way the program is actively assisting you rather than passively waiting for you to hit the F1 key or go to the Help menu. The goal of the User Centered Design combined with this active User Assistance is that you should be able to do your work and understand what is going on without being required to go to a separate help page.

However, if you do need more detailed help or want to study the product in more detail, we have the new Accpac Learning Center. This is similar in concept to our existing Windows Help.

The new Learning Center improves on the existing help in a number of key manors. The new Learning Center is much more focused around helping you accomplish tasks rather provide an encyclopedic reference of every small field in the product. It still describes all the key fields in detail, but is more focused on providing information on the steps to accomplish tasks and providing troubleshooting tips.

The new Learning Center is fully web based like the rest of the product. The core content is installed on the customer’s web server along with the rest of the product. However the Learning Center seamlessly links to Accpac on-line content including the Knowledge Base, the Technical Support Center, User Community Forums, Blogs (like this one), Training Courses and Training Videos.

The Learning Center is available from the Help link at the top of the new Portal/Desktop.  There are numerous “?” icons through the product that link you to the appropriate help pages. There is a new “Getting Started” snapshot that is included by default in each user’s home page as shown below.

The goal to the new help system isn’t just to help new users get up and running, but also to help experienced users be more productive by providing active tips and helping to assist users use some of the more advanced or infrequently used features in the system. Then to further connect people to the Accpac online community for a richer more social user experience.

Written by smist08

June 19, 2010 at 7:00 pm

Posted in sage 300, TCO

Tagged with , , , ,

Running Classic Forms in Sage ERP Accpac 6

with 5 comments

One of the main features of Sage ERP Accpac 6.0A is a fancy new Web based desktop/portal to act as a new home page for Accpac users. This new desktop/portal includes new dashboards ( and reporting capabilities ( This is the first step in a transition for Accpac from a traditional Windows desktop application to a true Web based application. For this first release the only accounting screen that have been “webified” are the various quote and order related screens that are run inside SageCRM ( In the meantime we still want the new desktop/portal to be used by all users, so we have provided the ability to run the classic VB forms from the new desktop/portal.

The Tasks and Reports menu give you access to all the screens that are available in Accpac today.

Then when you click on “Order Entry”, the regular screen runs:

You can add any of these screens to the shortcuts bar for easy access:

When running these classic screens, they aren’t using the older Accpac Web Deployed mode, they are using Workstation Setup. This means the screens will run exactly the same as they run from the classic Accpac Desktop. The setup and configuration requirements for these screens are exactly the same as for the classic Desktop.

The classic Desktop is still included with the product and you can still use this, if you wish. Even once we have Web versions of our screens, we will still provide the classic VB screens as an option. This way you can move to the web at your own pace. You can move your customizations at your own pace and you can learn the new screens and transition over at your own pace. The new web based Accpac is still Accpac. All the business logic is exactly the same. The screens will still provide the same functionality as the classic product, but with usability improvements for learn-ability and productivity.

Of course, normally, a web page cannot run a VB ActiveX object. We also don’t want to work like the current Web Desktop where each VB screen is embedded in a web page and downloaded separately taking time and throwing up all sorts of security messages. So what we do is embed one small ActiveX control in our main web page whose responsibility is to run any of the Accpac OCX screens when requested. This way you only need to download and install one ActiveX control from IE. If you want to use this functionality you must use IE as your browser (it will simply be ignored in other browsers like Firefox). But hopefully this provides a simpler less painful mechanism to run our VB forms from IE than the current Web desktop.

Any third party ISV product written in the SDK and using VB based classic screens can provide XML configuration files, so they can run from the new desktop/portal as well. However we will only be running classic VB screens, we will not be running older CA-Realizer based screens nor general EXE programs. For these you will need to use the classic Desktop or run them directly from the Windows Start Menu. Since we are running these programs from an ActiveX control, we simply can’t open it up to run everything since this would be a huge security hole. We certainly can’t run arbitrary EXEs as this would be very exploitable by hackers.

This mechanism should provide an easy way for customers to transition from the VB world of Windows desktop applications to the newer more popular Web Based approach. Again, customers can move at their own pace. They can freely use both the new screens and old screens at once. They can keep using the VB screens and their current customizations for a long time (probably as long as Microsoft supports running them on Windows). And if some users prefer the Web screens and some prefer the VB screens, they can both happily co-exist.

Written by smist08

June 12, 2010 at 4:32 pm

Posted in sage 300, TCO

Tagged with , ,

Insights 2010

leave a comment »

I just returned from the Sage Insights 2010 conference in Denver, Colorado. The conference was really great and Denver was an excellent city to have a conference in. The good thing about Denver is that the conference center is in the center of the city and most of the downtown attractions are within walking distance. This meant we weren’t trapped in an isolated convention center at the mercy of those facilities.

The keynote addresses outlined Sage’s strategies going forwards. The main emphasis was to balance efforts between three columns:

  1. Providing value for the installed base.
  2. Providing connected “cloud” services.
  3. Developing strategic products for new customer acquisition.

These pillars aren’t just to do with R&D, they affect all aspects of our business, including marketing, programs, sales, support and services.

There tends to be a lot of confusion about what the difference is between developing for the installed base versus developing for new customers. After all both will be customers and their businesses will be very similar. Just one uses our products currently and one (hopefully) will shortly. These tend to be confused with an age old argument with-in our products of how many resources to put into developing “accounting” type application features versus “technology” features. Unfortunately anything that isn’t an accounting feature tends to be bucketed as a technology feature, even though many useful non-accounting features like better installation programs aren’t involving any new technology, just refining what we already use.

So to be clear, providing value for the installed base does not mean just adding some “accounting” type features and developing for new customer acquisition does not mean just adding “technology” type features. For instance three top requested features from the installed base are:

  1. Better reporting
  2. Better performance
  3. Lower Total Cost of Ownership (TCO)

None of these are “accounting” features. All may or may not involve new technologies to solve them. Number 2 may just be a matter of re-factoring existing code in the existing technologies. Number 1 may just mean providing more reports in the current tools, or improving the current reports. Sage ERP Accpac 6.0A is addressing numbers 1 and 3 with web based technologies. It includes a new Accpac Inquiry feature and real time dashboards to address number 1. It moves towards a true web based zero-client model to avoid having to install anything on all the client workstations to reduce TCO. Better performance is address by being able to use more advanced web based testing tools to guide code re-factoring for better performance.

By the same token, from the Win-Loss analysis it appears that we lose sales at the upper end because our operations modules don’t provide all the sophisticated features that larger companies require. So adding functionality like sophisticated re-stocking strategies is an “accounting” feature that will allow us to expand the reach of Accpac, but probably won’t benefit existing customers.

Then there is the question of meeting the competition head on. When going head to head with the competition we want our product to be the best looking and most exciting. Right now that tends to mean being the richest web based application. Many times this is categorized as a new customer acquisition strategy, since we need to impress the clients to make a new sale. But it’s also an existing customer strategy, since if we don’t do this then the competition will attack our install base and if they can convince them that our products aren’t moving forwards, then they can start converting them. So we need the new technologies to both make new sales and to protect our installed base from our competitors. We are lucky that accounting applications are very “sticky” and its hard to convert our customers, but they still can be converted and our install base does need to be tended to.

So we can see that for the existing customer and new customer pillars, each will be addressed by a combination of refining existing functionality, embracing newer technologies and adding application functionality.

The middle column above of connected “cloud” services is all about providing new services to all our customers. This includes a number of existing services like Avalara sales tax calculator and Sage Payment Services’ Exchange gateway. It also envisions many new services perhaps like a hosted software as a service (SaaS) model self service modules. For instance a web site where employees of a customer can go to enter expense reports, which are then entered into the on-premise accounting application (using Sage’s SData web services protocol). The goal of these is that they can be developed once and provide a standard interface and then be connected to every Sage accounting application. Some of these will be add-on modules, some may be complimentary.

After the keynotes, the conference was quite exciting as Sage ERP Accpac 6.0 was released to “alpha”, meaning an official installable image was released to all third party developers. The “beta” release that will be available to all business partners is scheduled to be about 7 weeks away. Accpac 6 was installed on many computers for partners to play with, there were many product demonstrations, which were very well received.

At the end of the conference we offered two days of developer training in the Accpac 6.0 SDK which went quite well.

The next year should be quite exciting as we see all these new initiatives and products rolled out.

Written by smist08

May 24, 2010 at 5:19 pm

Posted in Business, sage 300

Tagged with , , , ,

On Total Cost of Ownership

with 10 comments

Quite a bit of attention has been turned to reducing the Total Cost of Ownership (TCO) of Sage products for Sage customers. Does this mean Sage needs to reduce prices? Does this mean Business Partners need to reduce prices? Paradoxically the drive to reduce TCO has nothing to do with reducing prices. It is all about making sure that there is true value in everything the customer is paying money for. TCO also goes beyond just the price of the software, M&S and implementation costs; it is also the cost of down time, the cost of learning the software and the cost of inefficient processes. Within Sage all groups are mandated to look into ways to reduce the TCO for our customers.

This blog posting is about how this is affecting development. What problems we are looking to address. Some will be addressed quickly and some will take longer. This blog posting is specific to Accpac development, but each development team at Sage is working on these same sorts of TCO issues, just each product has a slightly different set based on their unique heritage.

The most visible area that customers complain about TCO is the cost of upgrading from version to version. There are many aspects to this and a great opportunity to reduce TCO here. To be fair, a lot of these problems were caused by development in the first place. Often to shorten development cycles we could push some work from development off to the channel. For instance requiring that all batches be posted before upgrading, saves development and QA time, since we don’t need to convert the data in the unposted batch files; but shifts the cost to the channel who now have to charge to make sure all the batches are posted as part of the pre-upgrade checklist.

Hopefully with 5.6A you can see some first steps in making the upgrade process easier. These include:

  • Shipping all modules together at one time, including all the language translations.
  • Installing all products from one single installation program.
  • Combining product updates into a single install for all the applications.
  • Allowing you to run data activation as one process to convert the database for all applications in one shot.
  • Providing free training, to help customers get up and running on the new version quickly.
  • Providing better documentation on all the changes in the new version so there are “no surprises”.
  • Bringing in a large number of customer databases to test database conversion. Plus testing database conversion as part of the controlled release program.

Going forwards in the new versions we are going to be working hard to identify problem areas and address them. Note that the following list isn’t a commitment to do all these in 6.0, but you will be seeing them over the next few versions:

  • Making reports upgrade safe. Allow you to skip the step of verifying and re-testing all your custom Crystal Reports.
  • Make screen customizations upgrade safe. When we move away from VBA for screen customization, we don’t want anything like the problems with re-adding all the references and fighting the EXD files.
  • Work hard to make database conversion from version to version as robust as possible. Work to speed up database conversion. Self-heal any problems.
  • Work with the ISV community to ensure ISV products are available quickly with the new version. Take great care that changes we make don’t break ISV products.
  • Remove workstation setup. As a web based application only the server needs to be installed/updated. No more visiting hundreds of computers to run Workstation Setup/Database Client Software.
  • Work on reducing the pre-upgrade checklist down to just performing a database backup for safety.
  • Work on reducing the post-upgrade checklist to nothing. After installing and running data activation, everything else should just work.
  • Being careful about the TCO implications of adding new features. For instance if we come up with a nifty easy to code improvement to A/R Invoices, but that change would require all custom Invoice reports to be re-created, then we probably wouldn’t do that feature. The ROI would need to be astronomically high, or besides the simple code change we would need to produce a utility to seamlessly convert all existing reports.
  • Take care in changes that require operating system, database or hardware upgrades. These are all part of TCO.

Another area of TCO being addressed is productivity and learnability of the software. We have been building a large User Centered Design (UCD) team to study customer’s usage of Accpac and develop ways to improve the software. We have an observation lab where we observe and measure real customers performing tasks. We compare the results of old ways versus new ways, so we know we have improved things. The UCD team has a great deal of skill with coming up with better ways to do tasks, but we always test these by measuring customers actually performing these tasks. The goal of the UCD process is to allow customers to:

  • Be more productive. Accomplish routine daily tasks like entering invoices quicker and more accurately.
  • Be able to accomplish a new task without requiring additional training. Make learning the software much easier.
  • Find using the software more enjoyable. Find pain points or frustration points and find ways to remove these.

Generally TCO is a definite competitive factor in our industry. It is also a key factor in providing an Extraordinary Customer Experience. We want to make sure everything we do adds real value for the customer. A lot of these things start in R&D, but hopefully you are starting to see improvements as we move forwards with each new version.

Written by smist08

March 12, 2010 at 9:35 pm

Posted in sage 300, TCO

Tagged with ,