Stephen Smith's Blog

Musings on Machine Learning…

Posts Tagged ‘xml

Customizing the Order Details in Quote to Orders

with 4 comments

The new Order and Quote Entry screens in the Sage ERP Accpac 6 Quote to Order feature are the first real accounting document entry web based screens produced in the new “Orion” technology. As these go to final release there is a lot of interest in how to customize these screens. In the previous blog posting we started to talk about how to customize these screens. We discussed the declarative layout XML file that describes the layout and performed some simple edits to these screens. In this blog posting we are going to continue customizing these screens, this time customizing the Order Detail Line Table/Grid controls. In this blog posting, we will look at the XML that defines this table along with a couple of customizations.

For more background on Accpac’s new customization model and the XML Declarative layout files see: and

Definition of a SwtTable

The XML file is: C:\”Program Files (x86)\Common Files\Sage\Sage Accpac”\Tomcat6\portal\swtServices\uiDefinitions\oe60a\eng\sagecrmorderui\SageCRMOrderUIUIDefinition.xml. Below is part of the definition of the table control (a widget of type SwtTable) from the declarative layout (many columns omitted):

 <widget type=”swt:SwtTable” id=”orders_DETAILS” datasourceID=”oeorderdetails” preferencestoreID=”DetailTableSettings” height=”250″ width=”980″ autoLoad=”false” showRecordNumber=”true” showCustomFields=”true”>
       <item propertyBinding=”LINETYPE” dataType=”Int” width=”100″>
               <transText text=”xType” textID=”oe60a_sagecrmorderui_colType”/>
      <item propertyBinding=”CALC_ITEMNO_MISCCHARGE” dataType=”Char” width=”160″ formatPattern=”[:printupper:]{0,24}”>
              <transText text=”xItem No./Misc. Charge” textID=”oe60a_sagecrmorderui_colItemMisc”/>
   <item propertyBinding=”DESC” dataType=”Char” width=”200″>
                <transText text=”xDescription” textID=”oe60a_sagecrmorderui_colDesc”/>


The “<widget type=”swt:SwtTable” …” tag defines the SwtTable, sets its initial size along with some other global attributes. You can change these, but might not want to, for instance setting autoLoad to true would cause the table to load when it’s initialized, but the program will load it programmatically so the end effect will be to load it twice.  The main thing you will want to customize is the collection of columnHeaders which define all the columns that are displayed in the SwtTable.

Between the <columnHeaders> and </columnHeaders> tags are a number of <item> tags which each define a column in the table. Each item has a number of attributes, the possible attributes are:

  • propertyBinding: field in the SData feed that the column is bound to.
  • dataType: type of the column possible values are: string, Bool, Byte, Char, Date, Decimal, Int, Long, Real, Time and Object.
  • Width: default width of the column.
  • readOnly: set to true or false whether the column is read only (versus editable).
  • hyperlink: set to true or false whether the column is a hyperlink.
  • Sorting: set to true or false whether you can sort of this column.
  • formatPattern: format pattern for the column.
  • fractionDigits: number of decimals.
  • totalDigits: total number of decimal digits.

Some attributes are only valid for certain data types, for instance fractionDigits only makes sense for Decimal and Real types.

Then there is a <text> sub-element inside the <item> tag where you can specify either the text for the column heading or the textID of a string identifier in the uiContent table on the server. The textID will get the appropriate text for the language the user signed in on as. Make sure you set the textID to “” (empty string) if you want to hard code the string in the declarative layout. Editing the strings in the uiContent table in the Portal database is also a good way to customize strings, or to even specify new strings.

Adding a Column

To add a column to the SwtTable we need to add another <item> to the <columnHeaders> collection. For instance if we wanted to add the “Non-stock Clearing Account” to the table then we would add the following to the collection of <columnHeaders> just before the </columnHeaders> tag:

 <item propertyBinding=”GLNONSTKCR” dataType=”Char” width=”80″ readOnly=”true” visible=”true”>
               <transText text=”Non-stock Clearing Account” textID=””/>

Even though we’ve now added the field GLNONSTKCR to the SwtTable it wouldn’t display since it isn’t in the O/E Orders SData feed. So we need to add it to the SData feed. To do this we need to edit another XML file, namely: C:\Program Files (x86)\Common Files\Sage\Sage Accpac\Tomcat6\portal\sageERP\oe60a\resourceMap\OEOrderViewMapping.xml. This file among other things defines which Order fields to include in the SData feed. In the <includedFields> section for the detail, add the line:

    <resourceViewField viewFieldName=” GLNONSTKCR”       />

This will add the GLNONSTKCR feed to the detail. Make sure you add this to the includeFields for the detail and not one of the header. The field names used in the SData feeds is exactly the same as the field names specified in the Accpac Object Model (AOM) located at:

Whenever you change one of the SData definition files, you need to restart Tomcat to have it take effect.  To do this: run the Service applet from the Administrative Tools icon in the Control Panel and restart the “Sage Accpac Tomcat 6” service. Or do it from the “Configure Tomcat Service” icon under “Sage Accpac” under the start menu.

Note that is you are using sample data then there are a lot of optional fields defined for the Order details. With this new screen all the optional fields appear in columns of the table rather than from a popup form. This means that when we added our new field it won’t appear as the last column in the table, but somewhere in the middle since all the optional fields will come after it.

When the user customizes the column widths, order and visibility of table columns, these customizations are stored in the PreferenceStore table in the Portal database. If you have played with the columns in the table previously and the new column doesn’t show up, you might want to delete the SageCRMOrderUIUIDefinition-DetailTableSettings row from this table to clear the preferences. This table stores what we used to store in the *_p.ism files from our VB UIs.

Also make sure you have a backup of your customized declarative XML file, since you wouldn’t want future product updates to overwrite your one copy.

Below we see a screen shot of the table with our new column added between the Instructions and the Backorder optional field:


Hopefully this gives an idea of a few things you can do with the SwtTable that displays and edits the Order/Quote Detail Lines in the new Quotes to Orders. This article showed how to do this by editing the XML directly; but, if you have the SDK then you can use the SwtUIDesigner to do this visually.

Written by smist08

December 11, 2010 at 6:41 pm

Customizing Quotes to Orders

with 9 comments

With Sage ERP Accpac 6.0A we have incorporated Web based versions of the Accpac Order and Quote entry screens into SageCRM. These are the first accounting document entry screens in the new Accpac Sage Web Toolkit (SWT)  technology. A common question I get asked is how to customize these screens. Certainly the regular current Accpac Order Entry screen is one of the most customized screens in the Accpac system. However it is very hard to customize the current screen when it’s run from SageCRM because of the way it is packaged and run from a CAB file. The new screens are regular Accpac screens and run inside SageCRM just like they would run from Accpac. This means all the regular customization techniques for the new web based technology can be used on them.

As a starting point the screen definitions are now stored in a separate XML screen definition files. You can accomplish a lot just by editing these files. In this blog posting we will look at a collection of simple but powerful customizations you can perform here. In this blog posting we will just be looking at the XML for the controls and manipulating those. Actually in addition to that you can add JavaScript processing code to the events that get fired, this is a bit more sophisticated and we will look at that in a following blog posting.

The XML file is located in the folder: C:\”Program Files (x86)\Common Files\Sage\Sage Accpac\Tomcat6\portal\swtServices\uiDefinitions\oe60a\eng\sagecrmorderui”. The file we will look at is SageCRMOrderUIUIDefinition.xml. The XML files for a couple of popup forms are here also and you can customize these also. You can edit these files in any text or XML editor. If you have the SDK you can edit these files in a visual SWT UI designer, however for the purposes of this blog posting we will assume you don’t have the SDK and edit this file directly as a text file. One nice thing about the new web based technologies is that they are entirely configured by XML files, which being text files can easily be edited for customization purposes.

Introduction to XML

First just a few notes about XML. It’s worth your while to check out a site like to learn the basics of XML. But for what we’re doing here you really don’t need to know very much, just how to find things, cut and paste things, and make minor changes.

The key point is that all data is contained between a starting tag and a closing tag like:

<caption>This is a caption</caption>

Where the closing tag is the opening tag with a / in front of it.

Sometimes you can express attributes for a tag like:

<caption font=”Sans Serif”>This is a caption</caption>

Also if there is no general data then you can end the tag with a /> like:

<caption font=”Sans Serif” text=”This is a caption”/>

Generally most of the other stuff you find in the XML file, you would leave alone, like the version and encoding and such.

Form Layout

We talked a bit on how to layout forms in So we won’t talk too much about how to control the layout here, but we may look at this more in depth in a future posting. But beware that there are two types of widgets in a screen definition file, there are layout widgets that control how things look and then data widgets for displaying/editing data.

Widget Elements

Here a technical description of widgets in the layout XML files taken from the reference XSD file. An XSD file defines what is correct in a corresponding XML file

A widget element must contain a “type” attribute (corresponding to the namespace-qualified class name of the widget).  It may contain other attributes such as an ID as well as other attributes corresponding to simple properties (such as “enabled”).

A widget element may also contain other elements that correspond to compound properties. These compound properties include action (for predefined actions associated with button-like widgets), translatable display string properties such as caption, column headers (for tables), images (which include the URLs to the normal, normal, mouseover, and disabled images for a widget), search fields (for finders) and selectable items (for list boxes).

A widget element may also contain a “handlers” element for JavaScript and default actions widget event handling. That “handlers” element in turn contains a list of “handler” elements.  Each “handler” element has an event  and action attribute that refers to the name of the event and the name of the action that will be executed when the event is triggered.  The “handler” element may also contain a “params” element, which in turn contains a list of “param” elements.  Each “param” element has an id and value attribute that refers to the name and value of a parameter that will be passed in as an additional parameter to the action that is executed when the event is triggered.  Parameters will be passed to the action in the same order in which they are specified in the XML (which is important if it is a java script function being executed by the action).

A “regular” container (“HasWidgets”) widget’s element contains a “children” element.  That “children” element in turn contains a list of widget elements for child widgets.

A grid-type container (“HasWidgetsInGrid”) widget’s element contains a “rows” element.  That “rows” element in turn contains a list of “row” elements, each of which contains a list of “cell” elements.  Each cell is either empty or contains one (child) widget element.

A dock panel widget’s element contains a “dockedWidgets” element.  That “dockedWidgets” element in turn contains a set of docking position elements (e.g. “northWidget” element) for north, south, east, west, and center (in that order).  Each docking position element is either empty or contains one (child) widget element.

A menu bar or menu button widget’s element contains a “menuItemList” element. That “menuItemList” element in turn contains a list of “menuitem” elements, which in turn may contain other “menuItemList” elements (representing submenus).


Below is a screen shot of the Order Entry screen in CRM as it ships un-modified in the product:

Editing the Layout

Within the layout XML files are widget definitions of the form:

 <widget type=”swt:SwtTextBox” id=”orders_ORDNUMBER” enabled=”true” datasourceID=”oeorders” propertyBinding=”ORDNUMBER” width=”170″ style=”swt-TextBox-nohint-noBackground”/>

This is the contents for the base structure of a widget element.  These are the elements we customize.

Changing a Caption

Suppose we want to change the Document Number caption in this form. We can find the XML tag for this widget in the XML file:

<widget type=”swt:SwtLabel” style=”swt-Label documentDetails-LeftRow”>
          <transText text=”xDocument Number:” textID=”oe60a_sagecrmorderui_lblDocNumber”/>

This references a nice translatable string that exists in the Portal database, but we want to change this to a hard coded string specific for our customer. If we blank out the textID field, then it will use the text specified in the text field, so we can change the above to:

<widget type=”swt:SwtLabel” style=”swt-Label documentDetails-LeftRow”>
          <transText text=”Customer Specific Reference:” textID=””/>

Once we save this change, then running the Q2O Order Entry screen will show this caption instead of the one from the Portal database.

Adding a Field

The Quote to Order screen is optimized to make it easy for salespeople to enter orders quickly. However suppose the form is too simple and you require your sales people to enter another field that isn’t already on this screen. In the Q2O screen there is the order description field, but no order reference field. So let’s add the reference field to the Document Details tab.

To do this, find the SwtSingleTabPanel with transText: oe60a_sagecrmorderui_pnlDocDetails. A couple of lines below this is a SwtGridPanel with a rowCount of 4, change this rowCount to 6 (since we are adding one row with the label and one with the textbox.

Then add a new <row> at the end of the grid, this will be just before the </rows> tag:

                <widget type=”swt:SwtLabel”>
                          <text>   <transText text=”Reference:” textID=””/>    </text>
                   <widget type=”swt:SwtTextBox” id=”orders_REFERENCE” datasourceID=”oeorders”
                           propertyBinding=”REFERENCE” width=”400″/>

This will add the controls to the layout. However it won’t work quite yet. This is because the REFERENCE field for the Order Header isn’t provided in the SData feed. However we can add it. To do this we need to edit another XML file, namely: C:\Program Files (x86)\Common Files\Sage\Sage Accpac\Tomcat6\portal\sageERP\oe60a\resourceMap\OEOrderViewMapping.xml. This file among other things defines which Order fields to include in the SData feed. In the <includedFields> section for the header, add the line:

    <resourceViewField viewFieldName=”REFERENCE”       />

This will add the REFERENCE feed to the header. Make sure you add this to the includeFields for the header and not one of the details.

Whenever you change one of the SData definition files, you need to restart Tomcat to have it take effect. After you do this you should see the new field on the form and be able to set and edit it.


Here is the screen shot with these two customizations:


Hopefully this starts to give some idea of how to customize the new screens. If you have the SDK then you can use the SwtUIDesigner to edit these forms; but, hopefully in future versions the visual screen designer will be included in the main product making this process much easier for non-SDK partners to customize.

But at least for now, once you get used to XML you can do a lot of customizations to the current Web based version 6.0A screens.

Written by smist08

November 28, 2010 at 3:00 am

Posted in sage 300

Tagged with , , ,

Client Logic for an Accpac 6 Web Form

with 6 comments

Last week we talked about creating Accpac 6 Web UIs ( Part of the process is creating the XML representation of the Web Form which we discussed previously: Now suppose you have an XML form designed either in an XML editor or using our SwtUIDesigner and you want functionality beyond that which is given to you by default. By default you have record navigation, save and delete. From last week’s article you will now have a simple runnable project. So where do you put your client side code? Within the client files is a file which contains:

 * Copyright 2010 Sage Software Inc. All rights reserverd.
package com.sage.accpac.SS60A.ss1005.client;
import com.sage.swt.client.ui.builder.AbstractSynchronousFeatureModule;
import com.sage.swt.client.ui.builder.InstanceContext; 
public class SS1005FeatureModule extends AbstractSynchronousFeatureModule
   public String getDebugName()
      return "SS1005 Feature Module";
   protected boolean handleInstanceLoaded(InstanceContext context)
      // TODO: Handle what happens when an instance context is loaded.
      // Return true if the handling was successful; false otherwise.
      return true;

This is where you put your code. The handleInstanceLoaded routine is provided for you to hook your code in. Basically this is called once the UI has initialized and the XML form has been processed and everything has been created. At this point you can hook into any UI controls, data sources or do any other initialization you require. The context that is passed into this routine is the object from which you can get to everything else in the UI. It contains the collection of controls on the form, collection of datasources , etc. Below is a snippet of code for a simple handleInstanceLoaded routine that retrieves a button from the context by calling its getWidgets() method. Then it calls addClickListener() to add a listener that will be called whenever the button is clicked.

   protected boolean handleInstanceLoaded(InstanceContext context)
      DefaultAllClickListener defaultAllListener = new DefaultAllClickListener(context); 
      SwtButton btnDefaultAll = (SwtButton) context.getWidgets().get
          ( UIConstants.WidgetIDs.CONFIG_BTN_DEFAULTALL );
      if (null != btnDefaultAll)
      return true;
   private class DefaultAllClickListener implements ClickListener
      public DefaultAllClickListener(InstanceContext context)
      public void onClick(Widget sender)
               SwtMessageDialog.MessageType.CONFIRM, "",
               new MessageDialogListener[] {new ConfirmDefaultAllListener()});
   private class ConfirmDefaultAllListener implements MessageDialogListener
      public void onRespond(MessageDialogEvent evt)
         SwtMessageDialog.ResponseButtonType response = evt.getResponse();
         if (response == SwtMessageDialog.ResponseButtonType.YES)

Notice that we defined a new class DefaultAllClickListener which implements ClickListener. Basically this is defining the class for the object that will be called whenever a button is pressed. So in handleInstanceLoaded we call “new DefaultAllClickListener(context)” to create a new object in the DefaultAllClickListener class. This object will now be called whenever the button is pressed. In Java this is the typically way you get event notifications. There is nothing like a COM Event special type of method. Event handlers are just regular methods in regular classes. You hook them up by passing them to the object that does the notifying, usually by some sort of addXXXListener() type method call. It’s up to each routine that does notifications to keep a list of all the objects they need to notify and to call each one in turn whenever anything happens.

This is true for all UI events, notice that even the confirmation dialog displayed has a ConfirmDefaultAllListener() that will be called when the button is pressed on this dialog. All notifications are asynchronous like this. You can’t call a UI action and expect to wait (in the code) for a response. If VB we could just do answer = MsgBox () and our code would wait for the user to choose Yes or No. In the browser, everything is asynchronous, nothing waits, everything is via notifications. This is a different metaphor than people are used to. In languages like VB some things are asynchronous and work via event notifications and some things are synchronous. The big difference is that calls to the server are asynchronous, so whenever you make an SData call, you are notified via this mechanism when something arrives. Contrast this to VB where you make a server call, your code waits for the response and no more code is executed until you get it. In the web world this could take quite a long time and the browser would be completely unresponsive if no code executed until you got this response. This is the world of AJAX (Asynchronous JavaScript and XML ). AJAX is the key to creating rich internet applications in the Browser. If we didn’t use this, then the input forms would be quite boring lists of titles and edit boxes followed by a submit button, where nothing happens until you hit submit. This is another reason that you want to put groups of View calls in your server module, where everything works synchronously as normal. Generally you only want to make one server call at a time, since then you don’t need to chain together a number of responses, plus you get the performance benefit of only making one server call over the Internet.

Here we’ve been putting the code in the file, but unlike VB, there are no restrictions on how many source files you have and no rules that certain things have to be in certain files. So you can freely create as many class files as you like and organize your code in whatever manner you like. The nice thing is that you can follow industry best practices and aren’t under constraints like an event listener has to be in a special file in order to be called. So the expectation would be that you can create common Java libraries to share over UI projects and that you can keep your class files small and maintainable without putting everything including the kitchen sink into the file.

One aspect of Java that trips up VB (and C) programmers is the use of inheritance. When using an API or framework in C or VB, basically you look for all the functions, properties and events you can use. If you take this approach with Java, you will probably find that you are having trouble finding what you are looking for. This is because Java supports inheritance in a proper object oriented manner. So often the paradigm isn’t to do something by calling API functions, rather what you do is extend a class that does much of what you want and then just add the code that’s needed to make the difference. People new to Java often take a bit of time getting used to this. If you are stuck and aren’t finding an API that you are sure must be provided, instead look for a class that is along the lines of what you need that you can extend.

This code is Java and definitely not JavaScript. Yet this is what we are writing to run in the Browser. To produce the final runnable code we have to feed this through the GWT Compiler to get it compiled into JavaScript. The GWT Compiler will produce 6 versions of JavaScript from this code, one optimized for each major Browser family including WebKit (Safari and Chrome), Gekko (Firefox) and separate versions for IE 6 and 8. This then is the final code that you would deploy to your customer’s web servers to run.

In the meantime while you are developing, you keep working in Java. You can run this code as a Java application inside the Eclipse IDE. You can use the Eclipse Java debugger to single step through the code, set breakpoints and examine variables. You can also use all sorts of other Java tools to make yourself more productive like JUnit (, Emma ( or TPTP ( Plus you can use all the plug-ins that are available for Eclipse such as say SubVersion for source control (

All the methods are documented in the HTML JavaDoc which is generated from the comments in the source code. This is included as part of the SDK. Below is a sample of the beginning of the page that documents the InstanceContext. This page documents all the methods in this object.



Generally you can do quite a bit of customization just with the screen XML file. But at some point you are going to have to write some code to do the more deep customizations. To customize such UIs with code, you basically want to get hold of the context object, so you can access the collections of widgets and datasources. Then you can add your own listeners, or change the properties of the various objects. Basically you extend the main entry point class of the UI and extend the xxFeatureModule class. Add your functionality and then feed everything back through the GWT compiler to generate a new set of web pages to deploy.


Hopefully this gives a flavor for how the Browser part of a UI control is coded in the new Accpac SWT framework. Most of the basic functionality is automatic from the XML screen definition, but UIs are more complex than just CRUD (Create/Read/Update/Delete) and this is how you add that extra complexity to handle sophisticated UI needs.

Written by smist08

August 21, 2010 at 4:31 pm

Posted in sage 300

Tagged with , , , ,

Migrating Customizations to Sage ERP Accpac 6

with 12 comments

As Accpac makes the transformation from being a Windows Desktop Application to becoming a true Web Based Application, people often ask: how will we migrate our current customizations to the new platform? I talked about how to customize the new Web Based screens in:; but, didn’t really discuss a strategy for migrating existing customization to this new model.

Ultimately, the new customization model is far more powerful than the current model and this will allow far more complex customizations. It will also be much easier to perform some customizations that currently require quite a bit of code. However it took the channel quite a bit of time to master the current model. It took quite a while for everyone to learn the complexities of VBA programming and our UI customization model. Now we will be starting over.

Care will have to be taken when scheduling and estimating conversion projects. Perhaps starting with easier ones first, to learn from and become experienced in the new technologies before tackling the bigger more complex jobs.

Customization that Remain Largely Unchanged

For report customizations we are still using Crystal Reports and so all current Crystal customizations can still be used. There are fewer database changes for version 6 than we have had in the last few versions, so most customized Crystal Reports should work with no changes whatsoever. We will be moving to the newer Crystal 2008 reporting engine which means you can now use any features introduced in Crystal 2008. In the same way your Accpac Financial Reports will continue to work fine as will anything you have created with Accpac Intelligence or Accpac Insights. Additionally we now have the new “Accpac Inquiry” ( which you might want to construct some custom queries for.

Any customizations that talk to the Accpac COM API or the Accpac .Net interface will also remain mostly unchanged and should continue to work. Basically just following the usual upgrade procedures that you follow for any new version.

Any customizations that use View subclassing will continue to work. The View layer is largely unchanged. You should re-instantiate your Views with the View template in the Accpac 6.0 SDK, but this is the same procedure you should do with any new version.

For these API type customizations, it usually involves running a VB EXE program or VBA macro. These can be run from any workstation that has workstation setup installed, but as we run workstation setup on fewer and fewer workstations, you might want to think about running these on the Web Server.

Customizations of the new Web Based UI model

First a couple of caveats:

  1. We will continue to ship the current VB based UI forms for many versions. This means you can continue to use your current screen customizations for quite some time.
  2. We will continue to ship the current Accpac Desktop to allow you to run things exactly as you do today.
  3. Version 6.0A will only have new screens running inside SageCRM. Most other screens will move to the new Web Based technology for 6.1A.

However you will want to consider a strategy for moving your customer’s VB based customization to the new Web Based forms.

If the customizations only involved changes to the form design or changing text, then the customization in 6.x will be very simple and won’t require any coding. All the screen definitions and strings are stored in simple text XML files that can be edited either with special purpose tools (like a visual screen designer) or with a simple text editor like Notepad.

If the customization requires quite a bit of extra processing logic, then this code will need to be written in Java. The programming model is similar to that for the VB UIs. You subclass the UI and add your logic. There are collections of data sources and controls that you can tap into to get events to trigger your logic and allow your logic to manipulate the forms.

Expect a learning curve, to learn the new technologies. To become familiar with Java programming. To understand the programming and customization model used in our new Web Based UIs and how to deploy your updated UI controls on the server.

Although you can customize the current UIs just like you could customize the VB UIs, there is also a new alternative that lets you extend/customize the Accpac SData feeds. With this you can customize the code on the server that generates the data for the UIs. Sometimes this will be a better place to apply customizations. And is a new option you have available.

Like when we introduced VBA, it was a while before people were using it to extensively customize our screens. It took time to learn it and it took time to figure out what could be done. Like then, we will need to provide quite a bit of training, either live at our various conferences or via on-line training on Sage University. The good news is that the new customization model is more powerful than the current model and once you do master it, you will be able to more easily customize the look and feel for the product than ever before.

If the customization involves communications with programs running on the client’s workstation or involves saving files on the client’s workstation, these sort of operations may not be allowed from a Browser based application. There are definite restrictions on what you can do, in order to maintain workstation security. There are some things that you might do right now on the workstation that you might consider moving to the server or might need to find another approach, perhaps by communicating with a cloud service using web service calls. These will be dependent on what exactly you are trying to do and what is allowed.

The main points of customization are:

  • Various text files such as XML Screen definition files, XML string resource files and configuration files.
  • Cascading Style Sheets (CSS) that control the overall look and feel of the web pages.
  • Using Java to programmatically enhance the UIs.
  • Using Java on the server to programmatically enhance the Accpac SData feeds.

Older Web Technologies are Being Dropped

The Accpac SOAP Web Services are being removed in version 6.0A, so you will need to move any customizations using these to either the Accpac COM API, the Accpac .Net interface or to the new REST based SData Web Services being introduced in version 6.0A.

The Web Desktop is being removed. We will only be including CAB files for screens used by the SageCRM integration. All other Web Based VB screens are being removed. Any customizations that require the old Web Desktop will need to be moved to the new Web Desktop/Portal.


Any customizations that involve only the database, reporting or the business logic will continue to work or only require minor tweaks similar to the past few versions.

For screen customizations, you can continue to use your current VB customization for quite some time. However you should start to plan how to move these customizations over to the new Web base model.

Any customizations based on our older Web Technologies need to be moved over the new sooner than later.

Written by smist08

July 3, 2010 at 5:15 pm

Posted in sage 300

Tagged with , , , ,