Stephen Smith's Blog

Musings on Machine Learning…

Posts Tagged ‘declarative layout

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

Declarative Programming in Sage ERP Accpac 6.0A

with 7 comments

In the Sage ERP Accpac 5.x series of product, all screen definitions were part of the Visual Basic programs that made up each user screen. The only way to get at these screen definitions was to embed the OCX for that screen in a VB program or VBA macro and then manipulate the screen programatically. With Accpac 6.0, we wanted to make many screen customizations way easier. The solution was to separate the screen definition from the User Interface program. In Accpac 6.0 each screen is defined in an XML file that contains all the layout information. This screen can be edited in a Visual Screen Designer that is part of the product, or since XML is just a text file, it can be edited in a standard text or XML editor. For that matter the screen can be generated from another program. The definition of the screen layout file (xsd file) is available and the format is completely open.

In Accpac 5.x, we saved a lot of programming time by binding the individual UI elements to datasources. This meant that an edit control was actually attached to a View field via its properties in the VB form designer. Then the control would be data aware and handle setting its data into the view and retrieving updated data from the View. In this way, no programming was required for most of the forms on the screen. We have exactly the same concept in Sage ERP Accpac 6.x. Only each control is bound to a field with in an SData feed and that SData feed could theoretically come from any Sage application that provides SData feeds or from any other application that has adopted the open SData format. Thus again no programming is required for most fields on the form.

Then we have gone one step further and provided standard actions that can be attached to controls in the layout. In Accpac 5.x you had to code all the logic that happened when a button was pressed. In Accpac 6.x we provide standard actions, so for instance you can attach a save action to the save button which will perform the save operation on the configured SData feed. This way we can develop simple forms with navigation, save, new and delete operations, with no programming. The declarative layout actually produces a complete running program can run with no additional code. Many of the Accpac setup and other simple screens can be developed this way, greatly speeding the development of Accpac 6.x.

The layouts for Accpac 6 are quite different from the screens in Accpac 5.x. For one thing all controls were placed on 5.x screens at specific x,y co-ordinates. In Accpac 6, all layout is handled by browser document object model layout nodes. Nothing is specified in x,y coordinates, you just specify which controls line up and how and then the process is dynamic depending on the length and size of the text. This is a great benefit when translating into languages that take more space like Spanish since the form will automatically adjust to the longer text. When running a right to left language like Arabic, it’s even smart enough to be able to re-arrange all the controls into a right to left ordering. All this is just functionality built into every browser and something we gladly don’t have to worry about.

These are just some of the new things that declarative layouts are bringing to Sage ERP Accpac 6.0A. This will really be a strong and flexible foundation to develop on.

Written by smist08

November 19, 2009 at 3:38 am