Stephen Smith's Blog

All things Sage 300…

Posts Tagged ‘sage 300 erp

Adding a Grid to Your Sage 300 Web UI

with one comment

Introduction

The grid or table control is a key element for data entry in any Accounting application. With Sage 300 we use the grid control to enter things like Order or Invoice details. Interactions with a grid control tend to be quite complex. The data has to be managed so it is loaded only a page at a time (often called virtual scrolling), since there could be thousands of detail lines and loading them all at once would be quite slow. There is the ability to edit, delete and add lines. Tabbing has to be handled well to enhance data entry. People also have the ability to re-arrange the grid columns, hide columns and then expect these changes to be remembered.

icreceipts

This blog article will talk about the key elements to adding a grid control to your Sage 300 Web UI and what sort of support you need in your UI to support all the desired functionality. A fair bit is handled for you in the Sage 300 Web UI Framework, however you have to handle various events and there is a lot of power to add your own programming.

Configuration

There is a lot of support for standard grid operations in the Sage 300 Web UI framework. Much of this is controlled by a config JSON object which is passed to our @Html.KoKendoGrid function that defines the grid in the Razor View. This file defines a number of properties of the grid along with a number of standard callout functions you can define to add your custom processing. The good news is we have a utility to generate much of this from the ASP.Net MVC Model.

JavaScript Generation Utility

To generate this code we provide a utility which will generate the Razor View code and a lot of the standard JavaScript code that you need. So for instance the code for the Razor View might be:

jsgen1

And then some of the JavaScript code for the config object might be:

jsgen2

Server Side Pagination

In our VB UIs, we had virtual scrolling in our grids, which would basically bring in a page or two at a time. It supported scrolling one page ahead or one page back, go to the top or bottom but you couldn’t go to an arbitrary point in the file without searching (in fact the scroll bar would always be at the top, bottom or right in the middle). In the Web UIs we use the Kendo UI Grid control and try to keep the scrolling mechanism standard for the Web, which means the control tells you how many pages there are and lets you go to any page you like as well as going to the next or previous one.

We provide a lot of the support for doing this in our business repository base classes which expose a get method which takes the page number, page size, filter and order as parameters. Then as long as you match and set the configuration data in the grid’s JavaScript config JSON object, you get the pagination support. There are a couple of things to keep in mind, one is that we rely on our filterCount API call, which translates directly to a SQL statement, which means it can only count based on database fields and not calculated fields, so you can’t restrict the records in your grid based on any calculated fields or the count will be wrong (if you really need this then you need to disable the ability to go to a specific page). You also need to have a hidden SerialNumber column in the grid which contains the record number.

ViewListControl vs AccpacGrid

In our VB UIs, we actually had two grid controls. One was the ViewListControl which would show a separate View record in each line and supported virtual scrolling. Then we had the AccpacGrid control which would usually show an array of fields from a single record (like tax information, or perhaps item structure information).

In the Web UIs we only have one Grid control. It naturally works more like VB’s ViewListControl. So how do we handle the other case of the AccpacGrid? We do this in our controller by translating the array of fields into what looks like a list of details. This way to the Grid control, it doesn’t really see a difference. Usually you don’t need to enable virtual scrolling in this case since there is typically 5 or 10 records and you just provide them all at once. So typically your ViewModel will have a list of records which the controller will populate and then this is set as the Grid’s data source.

Editing

Like VB, the intent of editing cells is to place the correct edit control over the grid cell to perform the edit. There is a lot of framework support for this as well as lots of callouts for you to do your own custom processing. The same is true for adding a new line and deleting a set of lines (note that the Web UI grid supports multiple selection). Also note that the add line, delete line, edit columns buttons aren’t part of the Grid, these are separate buttons styled to look like part of the grid in a region just above the Grid. This means you can easily add your own buttons and controls to this area if you wish.

Saving Preferences

We have API support to help with loading and saving grid column preferences. In VB these are stored in the *_p.ism files, in the Web UIs these are stored in the SQL database in the new USRPROP table. So emptying USRPROP is the Web UI equivalent of deleting the *_p.ism files. Generally, we want to move everything into the database and remove our reliance on the shared data folder over time.

Summary

This article was just a quick introduction to adding a Grid control to a Web UI. Similar to the VB UIs, the grid control is potentially quite complicated as it supports a lot of diverse functionality. But, if you are doing fairly standard functionality, look for a lot of support in the Web UI framework to help you get the job done.

Written by smist08

February 3, 2016 at 6:29 pm

Sage 300 Web UI SDK – Adding UI Controls

with 9 comments

Introduction

In my last posting I showed how to quickly create an empty Sage 300 Web UI by running our two new wizards from Visual Studio. In this article we’ll look at how to add some visual controls to this project and talk a bit about some of the issues with doing this, namely about using our provided HTML helper functions and CSS styling.

We’re basically going to continue on and add the visual elements for the PJC Cost Types setup screen. We won’t write any JavaScript yet, so the only functionality will be that provided by the code generator and the default data binding support. This still give quite a bit as you can navigate, use the finder, delete records and save updates.

The UI Wizard discussed last week produces a simple starting page with the standard heading controls, the key field and the Save and Delete buttons. These are all wired up to Javascript and working. This makes our life much easier when adding the rest of the controls.

The only thing you need to do manually is change the Starting Page to: “/OnPremise/PM/CostType” on the Web tab of the Web project’s properties. Then it will compile and run yielding:

costtype1

Adding the Parts

ASP.Net MVC Razor Views are a technique to dynamically generate our HTML by embedding C# code in an HTML template. When the HTML needs to go to the browser the C# code is executed and it usually generates more HTML into the template, so that pure dynamically generated HTML is transmitted to the Browser. The Razor View system is very extensible and it allows a lot of extensibility which we do by adding a large set of helper functions.

Below is the screen once we add some more controls. I showed with a record loaded since that part works with the generated code. The dates and bottom combo box aren’t working yet since we need to add some JavaScript code to help them out.

costtype2

The source code for this screens Razor View (the partial view part) is:

(That didn’t work so well. Apparently WordPress ate all the div’s, I’ll do a bit of research to see if I can fix this, so a bit is missing from the below code. I also added some line breaks so the code doesn’t go off the right of the page).

@* Copyright © 2015 Sage *@
@model Sage.Web.Areas.PM.Models.CostTypeViewModel<Sage.PM.Models.CostType>
@using Sage.PM.Resources.Forms

@using Sage.CA.SBS.ERP.Sage300.Common.Web.AreaConstants
@using Sage.CA.SBS.ERP.Sage300.Common.Resources
@using Sage.CA.SBS.ERP.Sage300.Common.Web.HtmlHelperExtension
@using Sage.CA.SBS.ERP.Sage300.Common.Models.Enums
@using AnnotationsResx = Sage.CA.SBS.ERP.Sage300.Common.Resources.AnnotationsResx

@Html.ConvertToJsVariableUsingNewtonSoft("CostTypeViewModel", Model)

@Html.Partial("~/Areas/PM/Views/CostType/Partials/_Localization.cshtml")
<section class="header-group">
    @Html.SageHeader3Label("CostTypeHeader", CostTypeResx.Entity)
    @if (Model.UserAccess.SecurityType.HasFlag(SecurityType.Modify))
    {
        @Html.KoSageButton("btnNew", null, new { @value = CommonResx.CreateNew, @id = "btnNew",
             @class = "btn-primary" })
    }
    @Html.Partial(Core.Menu, Model.UserAccess)
</section>

<section class="required-group">
    @Html.SageLabel(CommonResx.RequiredLegend, new { @class = "required" })
</section>


  @Html.SageLabel("CostTypeCode", CostTypeResx.CostTypeCode, new { @class = "required" })
  @Html.KoSageTextBoxFor(model => model.Data.CostTypeCode, new { @sagevalue = "Data.CostTypeCode",
      @valueUpdate = "'input'" }, new { @id = "txtCostTypeCode", @class = "default txt-upper",
      @formatTextbox = "alphaNumeric" })
  @Html.KoSageButton("btnLoadCostTypeCode", null, new { @id = "btnLoad", @class = "icon btn-go",
      @tabindex = "-1" })
  @Html.KoSageButton("btnFinderCostTypeCode", null, new { @class = "icon btn-search",
      @id = "btnFinderCostTypeCode", @tabindex = "-1" })
  @Html.ValidationMessageFor(model => model.Data.CostTypeCode)
            
</div>

@* End of generated header, next is code I wrote. *@



    @Html.SageLabelFor(model => model.Data.Description)
    @Html.KoSageTextBoxFor(model => model.Data.Description, new { @value = "Data.Description",
        @valueUpdate = "'input'" }, new { @id = "tbDescription", @class = "large" })
    @Html.ValidationMessageFor(model => model.Data.Description, null)
            
 </div>



   @Html.SageLabelFor(model => model.Data.LastMaintained)
   @Html.KoSageTextBoxFor(model => model.Data.LastMaintained, new {
       @value = "Data.ComputedLastMaintainedDate" }, new { @disabled = "true", @class = "default" })
            


    @Html.KoSageCheckBox("chkStatus", false, new { @sagechecked = "Data.Status" },
         new { @id = "chkStatus" })
    @Html.SageLabel(CommonResx.InactiveAsOfDate, null, new { @for = "chkStatus", @class = "" })
                
    @Html.KoSageTextBox("txInactiveDate", new { @value = "Data.ComputedInactiveDate" },
         new { @disabled = true, @class = "default " })
   </div>
</div>



    @Html.SageLabelFor(m => m.Data.CostClass, new { @id = "lblCostClass", @class = "" })
    @Html.KoSageDropDownList("Data_CostClass", new { @options = "CostClass", @sagevalue =
          "Data.CostClass", @optionsText = "'Text'", @optionsValue = "'Value'" },
          new { @class = "w188" })
            
</div>

@* End of my code, next is the generated footer. *@


<section class="footer-group">
   @if (Model.UserAccess.SecurityType.HasFlag(SecurityType.Modify))
   {
      @Html.KoSageButton("btnSave", new { }, new { @value = CommonResx.Save, @id = "btnSave",
            @class = "btn-primary" })
      @Html.KoSageButton("btnDelete", new { }, new { @value = CommonResx.Delete, @id = "btnDelete",
            @class = "btn-primary" })
   }
</section>
</div>

 

I put comments around the code I wrote so you can see what is generated by the code generation wizard versus the code you add later. Basically this is a mixture of C# code (each line starts with @) and HTML which is in the angle brackets.

There isn’t much layout in this file because this is handled by the CSS. For simple screens like this one there are sufficient styles in the provided Sage standard CSS file that we don’t need to add any CSS. As a result, the HTML is actually fairly simple and really just used to logically group things.

Notice that we use Sage provided extension functions to create all the controls. This provides us with the hooks to provide quite a bit of standard functionality. For instance, we don’t want any hard coded strings in our HTML, otherwise we would force our translators to produce a different copy of the HTML for each language and then we would have to maintain all these files. Here we just use the helper function and it will look up the correct string from the language resource appropriate for the user’s language setting. This also gives us the ability to change the underlying control without changing all the HTMLs. So we can use a different date picker control for instance by changing the code our helper function emits rather than editing each HTML individually. Basically giving us a lot of global control over the behavior of the product.

These helper functions also can setup databinding. Any helper that start with ko will bind the data to the model (more precisely the viewmodel). We used ko since we use knockout.js for databinding which perhaps isn’t the best choice of function naming since again we can change the mechanism in the background without effecting the application code.

Notice there is a partial view called _Localization.cshtml that is included. This provides any localized strings that are needed by JavaScript. So anything referenced in here will be generated in the correct language when the page is loaded.

There is a strange call to “ConvertToJsVariableUsingNewtonSoft” near the top of the file. This is to load a copy of the model into JavaScript during page loading. This means we don’t need to do an initialization RPC call to get the model (Sage 300 View) meta data. Basically the usual empty screen then has the default data and meta data as a starting point.

Summary

This was a quick look at the Razor View part of our Web UIs. This is where the controls and layout are specified. Layout is handled by CSS and data binding is provided to greatly reduce required coding. Next we’ll start to look at the JavaScript that runs behind the scenes in the Browser.

 

Written by smist08

December 5, 2015 at 12:11 am

Introducing the SDK for the Sage 300 Web UIs

with 12 comments

Introduction

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:

solnwizard1

The wizard will then ask you some questions about your module.

solnwizard2

And then create a solution with the correct project structure for your application.

solnwizard3

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.

uiwiz1

This then brings up a wizard that you can step through.

uiwiz2

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:

uiwiz25

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:

uiwiz3

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:

uiwiz4

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:

uiwiz45

And finally you get the list of files that it generated for you:

uiwiz5

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.

Real Work

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.

Summary

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.

Written by smist08

November 27, 2015 at 6:19 pm

Sage 300 2016 Operations Beta

with 3 comments

Introduction

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.

operationkpis

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.

oe1100new

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.

poentry

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.

icreceipts

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.

schedules

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

fiscalsetcomp

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.

Summary

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

Introduction

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.

cna2arch

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.

Models

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.

Controllers

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.

Services

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.

Views

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.

Sage.CNA.Windows.Service

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

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.

Web API

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.

Printing

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.

Summary

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 8 comments

Introduction

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.

cs2000

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.

bk1000

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.

tx1000

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.

py1000

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.

gl1000

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.

arreceipt

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.

appayments

Summary

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: http://help.sage300.com.

 

 

Sage 300 2016 RTM

with 4 comments

Introduction

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.

bankrecon

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.

Miscellaneous

  • 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.

gl2100

Integrations

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.

Summary

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

Follow

Get every new post delivered to your Inbox.

Join 340 other followers