Archive for November 2015
Sage 300 has always provided an SDK to allow ISVs to create accounting applications in the same way that we create our own applications like General Ledger or Order Entry. In the past our internal application developers have usually only had the SDK installed for doing their own work.
Further these ISVs can install their applications into a working Sage 300 installation by just copying a specific set of folders. We then will see these folders and allow that module to be activated and used.
The new Web Screens will have the same ability to create custom accounting applications and to easily add them to one of our installations.
We will be starting the beta program for this SDK shortly, so this should start to give people a preview of what is coming.
This overview assumes you have an existing SDK program. That you have Sage 300 Views and VB UIs. That you have an activation UI and can activate your module, making it known to Sage 300. This is just how to create the actual Web UI components.
The Module Creation Wizard
We are first going to create a Visual Studio solution for your Accounting module. Then we will use another wizard to add the screens to this solution. The solution will contain several projects that correspond to the parts of a UI screen. This is different than each screen having its own project. This stays in tune with how the ASP.Net MVC tools create solutions and allows us to leverage everything built into Visual Studio.
Create a Visual Studio project. We provide a project wizard to create your solution. Let’s pretend we are going to create the Project and Job Costing module:
The wizard will then ask you some questions about your module.
And then create a solution with the correct project structure for your application.
This solution now has the correct structure to add screens to, plus it has all the module level compents and references. This will compile, but there isn’t anything to run yet.
The UI Wizard
Now you create your separate UIs by running our Code Generation Wizard. You get this by right clicking on the solution and choosing it from the context menu.
This then brings up a wizard that you can step through.
Depending on what you choose for the Code Type, you will get a relevant screen for the details. If you choose Flat you will get the following:
The View ID will be used to generate the model and business repository for this screen. Basically it will use the View meta-data to generate C# classes that will provide most of the functionality to perform standard CRUD type operations.
Next you get a screen to specify which resource file to use for your stirngs:
Like all our previous SDKs there is full support for producing a multi-language product. Of course as in the past its up to you whether you leverage this or not.
Now you get to select some options of features to include:
With in the Sage accounting modules the I/C, O/E and P/O Views contain more functionality for determining if a fields is editable or not than do the G/L, A/R or A/P screens. The “Generate Dynamic Enablement” indicates whether all the checking editbable is done by your UIs or by your Views.
Now its time to confirm to generate the code:
And finally you get the list of files that it generated for you:
The wizard has used the meta-data from the Sage 300 Business Logic View, in this case the PJC Cost Types view to generate the code for a Business Reposity to use and an empty HTML screen.
Running these wizards is quite quick and hopefully they give you a good start. The solution will compile and run, but all you get is a blank screen, since the generated Razor View just contains a TODO to add some controls. Now the real work begins adding controls to your Razor Views, adding custom processing logic and generally wiring things up.
You can now use the code-debug-fix cycle within Visual Studio and hopefully find it a productive way to create your Sage 300 screens.
In future articles I’ll talk about creating the Razor Views, using the extension functions we supply to help make this process easier and the CSS that is used to give the screens a standard look and feel. Then we will need to go into how to wire up finders, perform custom processing and all the other things required to make a Sage 300 screen.
This was a very quick look at the SDK for our Web Screens. We haven’t covered any coding yet, but we will. All the functionality used is built into the DLLs installed with Sage 300, so the actual SDK component is quite small. Besides the wizard, there is a lot of framework support to help you with common components and abstractions to hide some of the details.
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.
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.
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 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.
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.
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.