Stephen Smith's Blog

All things Sage 300…

Posts Tagged ‘Sage

Sage 300 2016 Operations Beta

with 2 comments


We recently released Sage 300 2016 with Web UIs for C/S, Bank, Tax, G/L, A/R and A/P. Now we have released our first beta of the operations modules I/C, O/E and P/O. Internally we are calling this our February 2016 release, I’m not sure what it will be officially called externally yet. This release will be packaged as a Service Pack to the Sage 300 2016 version, so this will need to be installed first. This will be a pretty major Service Pack with a lot of new functionality added. But as a Service Pack, the actual internal program versions won’t change and the upgrade procedures will be the same as for a regular Service Pack.

Due to various dependencies, we needed to produce the Financial Accounting screens for the Web first. Even though most users who can really benefit from Web/Mobile access need the Operations screens. So hopefully having all these Operations screens available should open up a great many possibilities for our customers. Of course you can still use the existing Windows Desktop VB screens, and you can even use a combination of both.

You need to run the “Portal…” dialog from Database Setup again to seed some data for the operations modules into the Portal database.

New KPIs

We have new KPIs for I/C, O/E and P/O. They are in the screen shot below, namely “Top Salespersons”, “Inventory Item Performance” and “Activity Trend”. Also notice the menus for I/C, O/E and P/O have been added to the main menu bar.


Order Entry

We are really pleased to have moved Order Entry to the Web. This is a module where there are often a great many users that are located in different geographic locations, or need to use the module while on the road. This module also integrates with Sage Payment Solutions (SPS) for processing credit cards. Below is a sample showing the main Order Entry UI.


Purchase Order

Purchase Order is a pretty major module that is now in the Web. Perhaps we don’t get as many users running P/O screens as O/E screens, but for a lot of companies, the P/O process is very important. Below is a screen shot of the main P/O Purchase Order Entry screen.


Inventory Control

I/C is a large module with lots of UIs that now have Web UI versions. We haven’t moved Lot Tracking or Serialized Inventory yet, but most of the other I/C functionality is now available in the Web. Below is a screen shot of the I/C Receipts screen, which is one of the major I/C document entry screens.


Other Screens

A number of the lesser used C/S, G/L, A/P and A/R screens were omitted from the first release. Quite a few of these are now in. For instance C/S Schedules has been added along with the various recurring entry screens that use Schedule Codes.


We added a number of other screens like the G/L Fiscal Set Comparison screen.


Another thing you might notice is that the Web UIs are available in Chinese now in addition to English and French.

There will be More

This is just beta 1. It is focused on the new parts of the Web Screens. It doesn’t include the new features that will be included in the Windows Desktop version, these will be appearing in a later Beta.


With the addition of the I/C, O/E and P/O screens, Sage 300 now has a very large footprint of its functionality in the Web. Hopefully we can get lots of feedback from this Beta release and have a successful launch in February.

It may seem like we are releasing the February version pretty quickly after just releasing the main Sage 300 2016 version, but we are now looking to release three fairly major updates to the product each year. This is the result of our adoption of Agile methodologies and the use of continuous delivery techniques (to release frequently, reliably and easily). Even though this isn’t a cloud release, we can still use the techniques of cloud delivery for our on-premise customers.


Written by smist08

November 14, 2015 at 5:51 pm

Sage 300 Web UI Internals

with 2 comments


At Sage Summit 2015 we introduced our new Web UIs for Sage 300. I’ve blogged a bit on the various user facing parts and a bit on the technologies used, but I haven’t had a chance yet to get into the internals of how they work. We’ve released the Web UIs for the Financial Modules and will be releasing the Operations Modules early in 2016. With these we will be releasing our SDK as well. Over time I’ll blog quite a bit about the details of all the components, but first we need to layout the major building blocks. Below is the architecture diagram I’ve shared before which is the architecture for the main Web UIs and a block for RESTful Web APIs, but there are some other components that need mentioning as well.


I’m going to start at the bottom of this diagram and work up. However there are some other components that aren’t mentioned here that we will bring in.

Within our framework we provide a lot base classes that you can inherit from, so generally the only code you need to provide is where something is different than the standard protocols or behaviors. When looking for framework components to help you, besides looking for services to call, look for classes that do 90% of what you need that you can extend (inherit from). ASP.Net MVC also makes extensive use of “convention over configuration”, so for a lot of things if you follow the standards then it saves you a lot of work and makes a number of things just work magically. Similarly we do the same things, so we can find and use your components as long as you follow the standards as outlined.

Business Logic

The Sage 300 Views are still the same. We didn’t even update the C View template for supporting this new framework. All the regular Sage 300 Business Logic (Views) is accessed through our .Net API.

Business Repositories

The Business Repositories convert our View API into something more like an ASP.Net MVC API. The Business Repositories are similar to the definitions that we generate from ViewDoc for different systems to make accessing all the various View fields more natural in the given framework. They provide support for all the usual View UI related items like presentation lists and field masks. Generally this is where all the View programming is placed that is needed by the UI. This makes all this programming available to everyone including UIs, standard components and Web APIs.


The models are true ASP.Net MVC Models. They are typically built on a given business repository. The reason for the separation between the Business Repositories and the Models is that the Business Repositories are more general use and can easily be consumed by UI elements whose Models are more generic like for Finders or Import/Export.

State-full Versus Stateless

There are two basic ways that our UIs operate, stateless and state-full. Ideally everything should be stateless, but this becomes somewhat impractical when dealing with large accounting documents. Basically in stateless operation, each RPC operation is completely independent and can be processed with no knowledge of what’s gone before. For state-full transaction a document is built up in the Sage 300 Business Logic as the user enters the document, this is more similar to how the VB UIs work. Generally only the bigger document entry UIs are state-full now. Use of the two is similar and most of the details are hidden by which base class you inherit from (whether a state-full or stateless one), but you must beware of the context as you do your programming.


The controllers mediate the translate the RPC calls from the JavaScript components running in the Browser to making calls the Models, Services and other API calls. Sounds like a lot of work, but typically these classes are quite compact.


Often in VB programming, you handle events from the user and as a result of a UI event you do a certain amount of View calls (perhaps say 20 of these). This sort of thing also happens in the Web UI, but we certainly can’t do 20 or so RPC calls to the server as a result of a single UI interaction. This is where services come in. Then when such a UI event is triggered, a single RPC call is made to the server, the controller dispatches this to the service who calls the correct method in the Business Repository which then makes the 20 or so View calls to do the real work. The service then marshals any returned data in the response. Of course this all happens asynchronously. Generally if you are wondering where to move your processing code from a VB UI it would be into one of the Business Repositories and then wire up a service to allow it to be called from the Browser. Services are also used to initiate long running processes which we’ll talk about later.


We use ASP.Net MVC Razor Views for our View components. This is a templating technology that allows us to dynamically generate the HTML using C# (which is embedded in the original HTML). For instance we allow translations to many languages, so rather than having embedded text strings, and then needing a separate copy of the HTML for each supported language, we have embedded C# functions that look up the correct language string which are processed and evaluated when we go to render the HTML. This is very handy and powerful in generating the HTML for each screen based on the various user and application contexts. There is also quite a bit of JavaScript associated with each screen to handle the various dynamic parts of the UI. Much of this is just a matter of wiring up the components like the screen UI elements to data binding or standard UI controls like the Kendo ones to our system JavaScript framework.


We don’t want to run long running processes like I/C Day End or Posting Batches directly from IIS, since even with full multi-threading support this can adversely affect the responsiveness of the UIs for other users. So we run a Windows Service and when a long running process is initiated we ask the Windows Service to run it, and just return from IIS. Then the UI can inquire periodically for meter status updates and to notify the user when it’s done. There is a lot of standard framework support for doing this and you just need to setup a service to initiate and monitor the process. Generally we do this for any Sage 300 process that pops up a progress meter.


KPIs are really just like any other UI. They just have a different size and are run in a different place on the Home Page. There are a few standards to follow to match the other KPIs and a few UI controls that aren’t used anywhere else, but are otherwise just standard UIs.


Although this component isn’t included in the original Sage 300 2016 release, there is full support for exposing RESTful Web Service APIs. These leverage your Model code to expose the model as an API. Then there is some support for hiding inappropriate methods and adding a bit more attribute information to help users.


Like previous versions of Sage 300, we use Crystal Reports to print out our reports. We basically use the same report API as we used in VB. We then have support to call this API from our UI framework and to render the report in the Crystal HTML Viewer. Then the rest of the report UI is just the same as any other UI, gathering up data from input fields. Printing might also have to initiate a process on the Windows service before printing, like generating the data for an aging report, before initiating the report.

Other System Components

There are system components for things like Finders and Import Export. These just need to be setup and wired in correctly. Then there are components like the editable grid which requires a certain amount more support in your UI. And then higher level components like the Optional Fields Control that is built on the Grid. There are a few other controls and wrappers for things like dates, fiscal year/periods, masked edit control, drop down list based on presentation strings, etc.


This article is the start of drilling down into the internals of how our new Web UIs work. Hopefully it gives a flavor of the components that combine to make a Web UI. The UIs are fully Ajax Web Applications, so there is work to do both in the Browser in HTML, CSS and JavaScript as well on the server in C#. There are quite a few frameworks involved from Sage, Microsoft, Telerik and a number of open source libraries. The trick is to not be overwhelmed, but to start with a simple empty screen and one by one learn and add the elements that you need. The good thing is that the base classes you extend (inherit from) provide much of the standard code and often you don’t need to add very much at all.


Written by smist08

October 17, 2015 at 10:20 pm

Accounting in the Web with Sage 300

with 6 comments


We are just rolling out Sage 300 2016 which includes Web versions of Common Services, Bank Services, Tax Services, General Ledger, Accounts Receivables and Accounts Payables. The focus of this release isn’t on a new flashy portal with flashy KPIs (although we do have those) or other new technology enabled functionality. The focus is on the core Financial Accounting functionality; on entering financial accounting documents into the system and providing the key reports that go along with these.

This is the first of a series of releases that will translate the Sage 300 product line to a new Web based technology platform. It will move all the functionality of Sage 300 to this platform and use this new platform to add newer technologies and functionality.

This article is meant to give a quick overview and flavor for what you will see in our new Web UIs.

Common Services

A lot of Common Services are screens that enable functionality through the rest of the product. For instance the Optional Fields setup UI is present and is used to configure Optional Fields that then appear in so many other places. There are the usual basic common setup UIs for Company Profile and Calendar Services.


Bank Services is a part of Common Services and it provides a centralized place to manage your bank accounts. Reconcile bank statements and enter various bank related items like service charges. It also provides a common check printing UI for other applications to use when printing checks.


Tax Services is another part of Common Services that lets you configure your sales taxes in a single place and then they are used everywhere that involves sales taxes. You will see the full tax services support though out many Web UIs.


Sage Payment Solutions (SPS) is also configured from Common Services. We fully support Sage Payment Services for taking credit cards in A/R as part of this first release. We integrate to the Web versions of the SPS screens to take and process credit cards. As before no credit card information is stored in the Sage 300 database, its all handled by the SPS screens and saved in the SPS vault.


Although they aren’t supported by their own screens there is a lot of common functionality that goes across all the modules like Import/Export, Finders and processing custom Crystal reports. These are all present in the new Web UIs as well.

All these screens fully support multi-currency and fully honor Sage 300 security.

General Ledger

This module offers all the standard G/L screens. From here you can define your G/L Account structure, create and maintain your G/L Accounts and enter your G/L Journal Entries. Generally everything is G/L is based on fiscal year and period (which we provide a specialized control to enter) and allows you to follow GAAP rules exactly.


Accounts Receivable

Here you have all the screens to setup and maintain you’re A/R sub-ledger. You have screens to enter and maintain Customers. There are the main document entry screens of Invoice Entry and Receipt Entry. There is integration to SPS for credit card transactions. There is retainage accounting, optional fields, sales tax calculations and all the rich functionality you are used to.


Accounts Payable

Here you have all the screens to setup and maintain you’re A/P sub-ledger. You have screens to enter and maintain Vendors. There are the main document entry screens of Invoice Entry and Payment Entry. You can track vendor account and transaction details on screen and on printed reports. Accounts Payable produces the reports you need to avoid late payment charges, secure vendor discounts, and match cash requirements to cash resources. There is tight integration to Bank for printing and tracking checks.



Hopefully you will try out our new Web technology for the Sage 300 UIs. This moves Sage 300 to a fully supported technology platform that continues to evolve quickly. This first release offers lots of functionality across all of Financial Accounting with new releases coming quickly to provide the rest.

If you remember our last UI transition from CA-Realizer to VB6, you will see that this one is happening at a much quicker pace.

Since the Business Logic is still the same as the existing product, you know that this is a very full featured and robust set of accounting functionality that has been in use at a great many companies for quite a few years now.

For more information check out the online help at:



Sage 300 2016 RTM

with 4 comments


Sage 300 2016 has now been “Released to Manufacturing”. This is a bit of an archaic term since we don’t manufacture anything anymore. It really means that R&D has handed the product over to the next step in the chain that will allow it to be installed at customer locations. This is a staged plan where it first goes to “controlled release” customers and then out to the wider audience in phases. The important thing is that the software is ready for customers to go live with in production environments.

Recently I’ve blogged quite a bit on the new Web UIs, but in this article we cover all areas of the product.

Web UIs

The marquee feature is of course the new Web UIs. You can now run Common Services, General Ledger, Accounts Payable and Accounts Receivable from Internet Explorer, Edge, Chrome, Safari or Firefox. There is a nice Home Page with KPIs, good international support and many usability enhancements. You can now easily access Sage 300 from a Mac, Linux computer or tablet.


Easier Installation

You no longer need to run Day End, post outstanding batches or complete bank reconciliation before upgrading. This should make it much easier to schedule when you perform the upgrade as you no longer need to sync with these other ongoing processes.

We now run regacc.exe during installation (full and workstation setup), so that you don’t need to do this as a separate step if you want your users to run with lower permissions (more on that later). This is also run during un-installation to clean up the registry.

Better UAC Support

The goal of this support is that regular users can run day to day without requiring power user or administrator rights and that they can leave User Account Control (UAC) turned on. This means that there won’t be any registering of controls as the user runs (this is all done at installation time) and we’ve moved where we store things in the registry so a regular user won’t be required to write to HKEY_LOCAL_MACHINE. Of course to install the software you still need to be Administrator and the usual procedures still apply.

Support Newer Microsoft Products

With this release we add support for Windows 10, Office 2016 and SQL Server 2016.

Note that we no longer support Pervasive.SQL or Oracle. Further we only support Windows 7 (SP1), Windows 8.1 and Windows 10. I.e. we do not support Windows Vista or Windows 8. We also only support the 64 bit versions of the operation systems, we no longer support the 32 bit versions.

Check the system requirements KB article for all the gory details.

Payroll 7.2

This release includes Payroll 7.2 (which is also available for Sage 300 2012 and 2014). For US Payroll this includes cost center overrides and ACA reporting. For Canadian Payroll it includes the PIER balancing report and the T4A/R2 Report.


  • The G/L Transaction Listing Report can now be run either by document date or by posting date.
  • G/L Journal Entry has an “Entered by” field.
  • A post button was added to the main document entry screens like G/L Journal Entry so you don’t need to go to the batch list to post the batch.
  • The tax tracking report can now be from/to a fiscal year/period.
  • The Tax Clear History function has been moved out of the Tax Tracking report and into a separate periodic processing function.



With every release we update the various integrations that are included with the product. Make sure you also update these integrations like Sage CRM 7.3 to get all the benefits from that update as well.


Lots of new things in Sage 300 2016. Especially check out the new Web UIs. Besides the features mentioned there are always lots of bug fixes and minor improvement under the covers that improve the stability and performance of the product.

Written by smist08

October 3, 2015 at 8:50 pm

International Support in Sage 300c

with 4 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

Skills for Developing for Sage 300c

with 4 comments


With the Web UIs in Sage 300c rolling out in a couple of weeks, there is a lot of interest in the SDK and how to develop for this platform. We are still putting together the SDK, but in the meantime you can learn the technologies that are involved in developing our new Web UIs. Generally we’ve used off the shelf components both commercial and open source to develop our new UI framework. The good thing about this is that there are lots of resources available to learn the various technologies involved, including books, web sites, samples, videos, courses, etc.


We’ve generally tried to use all these tools in very standard ways. For instance we don’t add large amount of code to custom controls to change their behavior, we’ve kept it standard and only changed their appearance using CSS. We use the ASP.Net MVC framework in a natural way, so what you learn from the various standard resources is all applicable.

Due to the nature of programming, you can often do quite a few creative things. There is nothing to stop you using other libraries or tools than mentioned here. However one of the points of listing these is to let you know which we use, which means if you ask DPP support, these are the tools and libraries that we know about and can help answer questions about. You are welcome to use other tools, but we may not be able to provide much help on them.


C#: All server side programming above the Sage 300 .Net API is written in C#. This is a very powerful object oriented extension to C which is quite similar to Java. It has an extensive standard class library. The tools and environments that support C# are really powerful and productive.

JavaScript: All client/browser programming is in JavaScript. We support newer browsers which all now support fairly standard implementations. The main pitfall of JavaScript is that it’s an interpreted language that will process almost anything, often with surprising results.


ASP.Net MVC: Do not confuse this with ASP.Net (no MVC). This is a completely different framework which is much more powerful and gives a really solid framework for web development.


HTML: HTML controls the general layout of web pages in the browser, however it isn’t as important as it used to be. Our HTML is generated from Microsoft Razor Views, so a good portion of the HTML is actually represented as C# code. Then layout is largely controlled by CSS and not by HTML elements.

CSS: Cascading Style Sheets (CSS) control the layout and look of all the elements on the HTML page. We provide a global stylesheet which has most of what you need. However many screens need to define custom elements for their own fine grained control. We will provide a style catalog and samples of all the main UI elements.


Visual Studio 2013: This is the main IDE where we develop and debug our code. This is a very powerful and productive environment to write, build and debug code. Chances are we will be on to VS 2015 by the time the SDK ships, but for now this is what we developed our 2016 release in. We use the premium edition because that is what comes with our particular MSDN subscription, but any edition will probably be fine.

ReSharper: This is an optional tool that we’ve licensed for all our developers. We’ve found it very helpful to improve the quality of our code and to help with refactoring.

GitHub: Although using a source code control system is optional, you should be using one. Using any of Git, Subversion, TFS, etc. is fine, but you should really be using one. We use GitHub because it is very fast and reliable. The real benefit is that it’s fast for everyone when you have large internationally dispersed teams.

TeamCity: This is another optional component. You can just build out of Visual Studio. We use TeamCity, but you can also use other automated build systems like Jenkins. Its generally a good practice to have a continuous build/integration system that is always building things as they are developed, deploying them and running automated tests to ensure that things aren’t broken.


Kendo UI: This is the library of UI widgets that we use like the editable grid and date control. When we started this project this was strictly a commercial product. However half way through they created the open source Kendo UI Core which has all the controls we use for creating Accounting Screens except the editable grid control. For the grid control and the graphical controls in the KPIs,  you will need to purchase a license for the professional edition.

KnockoutJS: We use knockout for data binding between the UI controls and the MVC models. When we started the project the data binding in Kendo UI didn’t meet our needs so we evaluated alternatives. We found knockout and it did everything we needed so we’ve continued to use it. In the meantime Kendo has improved and AngularJS has become popular, but we’ve stuck with Knockout (which is popular again).

JQuery: Most modern web apps use JQuery. Although its main use of insulating people from browser differences isn’t as important and most browsers have natively implemented its main features, it is still an important library and we use it extensively.

.Net Framework 4.5.1: Since all our server components are written in C# and using the ASP.Net MVC framework, of course we are using the .Net framework. For the 2016 release we are at version 4.5.1. However by the time the SDK ships this will probably be at a higher version.

Sage 300 .Net API: To integrate to the standard Sage 300 Business Logic, we use Sage 300’s .Net API. So when writing code in the MVC models to perform Sage 300 processing, you are writing code to this API.

Crystal Web Viewer: We provide a complete framework for handling Crystal Reports, so you don’t need to directly interact with Crystal. We generate reports using the same code as the desktop version, but then display the result in Crystal’s HTML viewer rather than the ActiveX one.

Unity: This is a library for doing dependency injection in .Net. You probably don’t need to use this directly, but it’s useful to understand how your DLLs are being loaded and why the startup process works like it does.


This was a quick list of the various tools and technologies we used to create our new Web UIs. Hopefully it gives you a starting point of things to start learning about, if you are interested in Sage 300c development.

Written by smist08

September 19, 2015 at 4:33 pm

Bengaluru Travel Blog Part 4

with one comment


As part of developing all the Web Screens for our upcoming Sage 300 2016 release, we worked with quite a few contractors at Sonata in Bengaluru, India. I originally visited them back in November 2014 and wrote a series of three blog articles on my experiences over there (part 1, part 2 and part 3). I then visited them again in March 2015, but didn’t blog about that visit. Now I’m in Bengaluru again and thought I’d add another posting to the series.


One change is that I’m going to try to use the proper name of the city which is now Bengaluru and not Bangalore. The name was changed just days before my first visit and was a bit confusing.

The Story of Sage 300c

We started the Sage 300c project two years ago, built on a lot of the ideas and architecture from the previous Orion project. We brought in Sonata for their expertise in Microsoft ASP.Net MVC technology which we adopted for the new Web UIs. We started work collaborating with a small team from Sonata to produce a proof of concept where we produced fully working A/P Vendors and A/P Invoice Entry screens. We chose these as reasonably complex but not so complex they would take too long to develop. We learnt a lot from this POC and used that to build a frame work for our new UIs. We then built up the team and proceeded to build the G/L screens. This was a test of building a full application to get a better idea of the work and time that would be involved when we ramped up for the whole project. This went quite well and we ramped up the team and started work on A/R, A/P, Bank, Tax and C/S. We then decided to accelerate the project and ramped up the team in Bengaluru again to simultaneously work on I/C, O/E and P/O. I blogged a bit about this process on how to organize Agile development and how to scale Agile development.

We are now code complete on Sage 300 2016 and just finishing final regression ready for release. The I/C, O/E and P/O screens are coming together nicely ready for our February Product Update. Any large software development project takes lots of hard work, many long hours and some heroic troubleshooting. This project was no different. Looking back now its amazing how much commitment to producing a first class quality product went into all the work. All the Agile Scrum teams around the world really took their work seriously and really made the effort to produce something everyone could be proud of.

Team Wrap Up

With this visit we’re wrapping up the giant accelerated project, and with the main Accounting modules completed we’re proceeding on a smaller scale. It’s interesting to see this transition while in Bengaluru at Sonata. The skills used on this project are in high demand and everyone moving off this project has a place on a new project. People are excited to both complete this project and to start their new project. Overall Sonata is expanding with a new building opening next door, next month.



This Sonata office is located in the Global Village Tech Park. There are a lot of large companies similar to Sonata located here. It is really remarkable how all these companies are continually managing ramping up and winding down so many large projects with so many people involved.


Further there are 2.97 million IT professionals in India and 35% of them are located in the Bengaluru area. This means the out of the total population of 8.52 million, 1,039,500 are IT professionals (i.e. programmers). This is an amazing number of computer pros and what is helping drive Bengaluru’s annual growth rate of 38% which has propelled it to become India’s fourth largest city.


As I leave Bengaluru, on one hand its sad to say good bye to so many people I’ve worked with over the last two years, on the other hand its exciting that they are all moving on to other projects. Hopefully I’ll run into them again in a future visit. Meanwhile with the core Accounting screens completed, Sage 300c has a solid Web technology base and can move on to really adding to the base we’ve created.

P.S.: Plus the people I was working with took me to Bannerghatta National Park where we went on a Safari and saw lots of tigers, bears, lions and elephants.


Written by smist08

September 13, 2015 at 3:42 pm


Get every new post delivered to your Inbox.

Join 331 other followers