Archive for the ‘CRM’ Category
From the Sage 300 ERP to Sage CRM integration there is the ability to run a number of Sage 300 ERP screens. These are the older VB screens being run as ActiveX controls from the IE browser. Not to be confused with the newer Quote to Order web based screens. A common request is how to customize these screens to you run the customized screen from Sage CRM rather than the base screen.
This blog posting covers how to run customized screens from Sage CRM. As a bonus, as part of this it also shows how to wrap a Sage 300 screen, so that it handles version updates seamlessly and doesn’t require you to re-compile your solution when we release a new version of the base screen. As a result this mechanism requires you use VB to wrap the base control for deployment. The ideas presented here probably can be ported to other programming systems, but it may not be easy.
A sample project that wraps Order Entry is located on Google Drive here. This project will be used for most of the examples in the document, so feel free to load it up and follow along. In order to view the wrapper, simply unzip the file, and open up the CRMOEOrderUI.vbp.
Create the Wrapper
The following instructions will show the basic steps on how to create a Sage 300 UI Browser Wrapper. The wrapper can then be referenced by an ASP page. There should be a constant interaction between the UI, the wrapper, and the ASP page (ie. UI calls UI_OnUIAppOpened in the wrapper, the wrapper raises the UIWasUnLoaded event to the ASP page, and the ASP page in turn catches the event, and closes the window containing the wrapper (and attached Accpac UI).
1. Open up Visual Basic and select a new Active X Control. Click Open.
2. Go to Project/ References, and select ACCPAC COM API Object, ACCPAC Data Source Control, ACCPAC Signon Manager, VB IObjectSafety Interface, ACCPAC Application Installer, and ACCPAC Session Manager.
3. The project name determines the name of the wrapper (OCX). In this case, the wrapper name will be “eCRMOEOrderUI”.
4. The name that you give the UserControl should be descriptive of what is contained on it. In this case, give the UserControl the same name as the Accpac UI that is wrapped (in this case, OEOrderUI).
5. When you are coding refer to the Accpac UI as “UserControl” (ie. UserControl.Width, UserControl.height).
6. We use the VBControlExtender to wrap the Order Entry OCX control dynamically when UserControl_Show is called (see code for UserControl_Show accompanied with this document). When referencing elements and methods within the Order Entry OCX control you would use ctlDynamic.object. The control is installed and opened using the AccpacOcxRegHelper.CLS which makes entries in to the registry that allows the VBControlExtender to reference the control by name as opposed to CLSID which is returned from Roto.
7. Now you are ready to begin writing the code that will catch the events thrown by the Accpac UI, and raise your own events to the ASP that will contain your wrapper.
8. Go into your code view and begin instantiating your events, objects, and variables.
9. Begin by declaring your objects that are going to handle events thrown by the AccpacDataSource controls in the related Accpac OCX controls. In this case, event handlers of the AccpacOE1100 class are being declared so that they can detect the events thrown by the class.
10. Next, declare the events that you will want to raise to the ASP page.
11. Declare your public variables
12. Declare your remaining variables. In this case, mSignonMgr is going to be used to sign on the Accpac UI with the signon manager so that the signon screen does not keep popping up every time that the UI is loaded. mlSignonID is going to be the signon ID.
13. Outline your functions that will be called by the ASP Page. In this case, the ASP page will give the values that are to be used to populate the UI, or to insert the customer ID into the UI’s customer field for a new customer quote.
14. Next, list out the events that can be called by the UI AccpacDataSources. In the screenshot below, you can see that the wrapper is checking the eReason variable being passed, and depending on what eReason is being passed, a different event will be raised to the ASP page (AddNew, Delete etc) in the RaiseEventEX sub.
15. Other functions are also called by the Accpac UI. The wrapper will be notified of these events through ctlDynamic_ObjectEvent (see below). Once the UI has opened ctlDynamic_ObjectEvent is called with an event name of “OnUIAppOpened” and a private sub UI_OnUIAppOpened is called and objects in the wrapper are initialized, and the UIWasLoaded event is raised to the ASP page notifying it that the UI has been opened.
16. Finally, define the Get properties that are available to the ASP page so that it can resize its windows when the UI has been loaded onto the ASP page. In this case, the ASP page will resize its windows to be the same width, height, and unit of measurement as the UI.
17. Now, you have successfully entered all the code that the wrapper will use to receive the function calls from the UI, as well as raise the events to the ASP page.
Customize the Sage CRM ASP Page
You now have a wrapped OCX now you can follow the ASP page in Sage CRM (for example, OE_OrderUI.asp as follows) to call your customized OCX.
Then it will open the OE Order Entry screen for order ORD000000000076.
In OE_OrderUI.asp file, it has following code:
eCRMOEOrderUI raises the following events:
UIWasLoaded(), UIWasUnLoaded(), AddNew(), Delete(), Update(), FieldChange(), Init(), Read(), Fetch()
eCRMOEOrderUI exposes the following Properties:
UIWidth(Read Only), UIHeight(Read Only), TwipsPerPixelX(Read Only), TwipsPerPixelX(Read Only)
eCRMOEOrderUI exposes the following Functions:
PopulateUI(OrderID As String, CustomerID As String);
CreateNewQuote(CustomerID As String);
<SCRIPT for=”eCRMOEOrderUI” Event=”UIWasLoaded()”>
var width = eCRMOEOrderUI.UIWidth / eCRMOEOrderUI.TwipsPerPixelX;
var height = eCRMOEOrderUI.UIHeight / eCRMOEOrderUI.TwipsPerPixelY;
if ((BrowserDetect.browser==”Explorer”) && (BrowserDetect.version >= 7))
width += 35;
height += 130;
width += 35;
height += 100;
var left = (screen.width – width) / 2;
var top = (screen.height – height) / 2;
width = eCRMOEOrderUI.UIWidth / eCRMOEOrderUI.TwipsPerPixelX;
height = eCRMOEOrderUI.UIHeight / eCRMOEOrderUI.TwipsPerPixelY;
BorderWidth = ClientWidth() – width;
BorderHeight = ClientHeight() – height;
bLoaded = true;
Hopefully you find this helpful in customizing Sage 300 ERP screens. Even if you don’t run them from Sage CRM, not having to re-build them for each Product Update can save you some time.
With the forthcoming release of Sage 300 ERP 2012 we will be including a number of enhancements to our Sage CRM integration. This blog posting goes into the main improvements you will see with this release.
New Version of Sage CRM
With this release we will be bundling the newest Sage CRM 7.1 SP2. This service pack includes a number of nice improvements over the last release, including document attachment enhancements, mail merge enhancements and library management. You can read about these at the Sage CRM blog here.
Of course the nicest thing is getting a nice new re-mastered Sage CRM install image with all the various Service Packs and Hotfixes integrated along with the newest Sage 300 ERP integration components, so you only need to run one install to get to the new latest release.
Cross Browser Support
But for us, the biggest change is the support of browsers other than Internet Explorer. Sage CRM now supports Mozilla Firefox, Google Chrome and Apple Safari. So for all the poor people out there struggling using IE 8 on Windows XP, you can now switch to Firefox or Chrome, and greatly improve your life. Similarly if you prefer using a computer not running Microsoft Windows you can now use that device/computer to access your Sage CRM.
As part of this, the Quote to Order feature in Sage 300 ERP 2012, now also supports running in these Browsers. The only thing you can’t do is drill down and run ActiveX screens from the older parts of our integration.
No More Crystal Enterprise, RAS or Sage Web Reporting by Crystal
When we ran Sage 300 ERP web deployed (the old way with ActiveX controls) we required the Sage Web Reporting by Crystal Server to print Crystal reports through the browser. We have now removed that requirement and you no longer need to install this component.
Installing and getting this running has always been a major trouble spot, especially on Windows Server 2008. Now you no longer need to install it, it is gone from the Web Deployment Wizard and hopefully your reporting will run much easier.
Since this has been such a problem for people installing on Windows 2008 Server we are also providing this particular feature as a hotfix for 6.0A.
Sales splits in Quotes to Orders
We released the new fully Web based Quote to Order integration into Sage CRM with version 6.0A. The intent of this screen was to fit seamlessly into Sage CRM and to provide the functionality required by salespeople entering orders. The goal was to make this screen far easier to use than the full regular Order Entry screen. As a result it had a subset of the functionality that we felt was required by salespeople.
However salespeople are extremely concerned about commissions and to them the glaring omission in the first release was the lack of the ability to enter sales splits for Orders. So for this release we are adding the sales split functionality into the header (as a collapsible frame). Below is a screenshot with the sales split parts visible. The functionality here is exactly the same as in the full Order Entry screen, since all the validations (like percentages adding to 100%) are done in the business logic which is shared by the two screens. Also note that everything is running in Firefox to highlight the cross browser capability.
Better Dashboard Integration
I talked about the improvements we are making to our SData support here. Just mentioning it again here since it does enhance our integration with the Sage CRM dashboard, making it easier to add Sage 300 ERP data to the Sage CRM dashboards via its SData widgets. We will be leveraging SData more and more in our integrations to seamlessly server up data from any application wherever it is required.
With each version we update to the newest version of Sage CRM and add a few enhancements to our integration. This blog posting just highlights the enhancements Sage CRM users will see when they upgrade to Sage 300 ERP 2012 and Sage CRM 7.1 SP2.
Sage has standardized on a REST based Web Services protocol called SData. This protocol is documented at http://sdata.sage.com/. As a first step this will standardize the technology that you use to communicate with Sage applications. You will be able to issue SData requests to multiple Sage products such as Accpac, Abra and SageCRM. As opposed to using a different technology to talk to each, such as COM, .Net, Java, Soap, DLL, etc. All the products will still maintain their existing APIs, but they will all add SData to their repertoire. Even if you are a reporting type application, crossing multiple Sage products can be difficult as they tend to use different databases or have very different schemas. SData is a nice way to hide these differences and to provide a single consistent programming interface.
The next step is to standardize the actual data that is exchanged via SData. Towards this end, Sage is releasing a number of “contracts” that can be used to interface to a given application. For instance the Sage Global CRM (GCRM) Contract (http://sdata.sage.com/sdatacust_GCRM.html) is a standard contract supported by all Sage CRM products including Act!, SalesLogix and SageCRM. If someone integrates to one of these products using SData and the GCRM Contract, then it will be very easy to integrate to any of the other CRM products.
The GCRM contract was created by Sage for mostly selfish reasons. Sage owns dozens of ERP packages in dozens of regions around the world. Having each of these create a point to point integration with one of our CRM packages was proving to be a huge amount of development effort. Plus the results weren’t consistent, some of the integrations were better than others. This started as an attempt to standardize what was being done repeatedly over Sage again and again. However as the work progressed we realized there are a lot of other benefits. Not only does this save Sage some development time and money but it will:
- Provide a standard interface for others to do similar integrations. For instance an ISV could integrate another CRM package to multiple Sage ERP’s by taking advantage of the GCRM contract.
- ISVs will be able to integrate to multiple Sage applications at once (usually part of a suite of products) using only 1 technology.
- The various application contracts are well documented at http://sdata.sage.com/sdatacust.html making life a bit easier.
- Using REST based web services is an efficient way to produce a nice lightly coupled integrations.
Each application will still have a native SData interface where you can get at the full functionality of that product. But these standard contract interfaces will make it far easier for ISV’s to integrate their vertical solutions to multiple Sage products.
Many applications have a component of their data that is shared and needs to be synchronized. For instance much of the data that CRM maintains for its companies is shared by the ERP package in its customer’s information. In most CRM to ERP integrations a large part of the integration is keeping this company/customer data synchronized in the two applications. Similarly for an HR application to ERP integration, typically the employee database tables need to be synchronized in the two applications. SData provides a standardized protocol to allow multiple applications to synchronize data in a uniform manner (http://sdata.sage.com/sdatasync.html).
At the core of the GCRM Contract is the specification of how to synchronize the tradingAccount (company/customer), contact, postalAddress, phoneNumber and email tables. The GCRM contract specifies the fields that make up these standard contract definitions (how CRM and ERP expose their native tables) and what the applications need to do to provide the synchronization. In this case the hard part is handled by the CRM application which hosts the synchronization engine. The ERP package just needs to provide an SData feed for each of these tables in the correct format. Then CRM will periodically ask ERP if anything has changed and if so to provide the updated records. The protocol then has the details of how to handle conflicts and how to catch up if one application was unavailable for a period of time.
The GCRM Contract really consists of three parts:
- The base customer/company tables that need to be synchronized and the protocol to handle that.
- A number of real time data SData feeds in a standard format to access much of the data in the CRM product.
- A set of SData feed definitions that allow CRM to provide a basic Order Entry screen, to query pricing information from the ERP and feed orders into the ERP package.
These three parts can be used independently. For instance Accpac could use the GCRM contract synchronization contract to replace the current method and start incorporating CRM data into its own UIs that is retrieved by the real time SData feeds, but then rather than using the CRM Order Entry screen, surface the Accpac Order Entry screen inside of CRM (the quote-to-order feature: https://smist08.wordpress.com/2009/12/17/sage-erp-accpac-6-0-quote-to-orders/).
As Sage moves ahead with adopting our REST based Web Services, SData, you will be seeing more and more new technologies based on this. Generally Sage is looking to develop many SData based technologies that can be shared across all Sage products and can be utilized by all Sage development partners.
Sage ERP Accpac and SageCRM have a very tight integration. But the current generation of Accpac is a Windows desktop application and SageCRM is a Web Browser based application. SageCRM will display a fair amount of Accpac data in its web pages, but at some point you drill down into the Accpac application and an Accpac screen will be run. This causes a disconnect for the customer as they switch from the SageCRM Web application to the Accpac Desktop application. There are also performance problems with this context switch and some installation difficulties getting the “Web” based version of the current Accpac installed and configured properly since it uses ActiveX controls.
The styling and screen aren’t fully developed yet, but below is an early prototype of the start of a Quote screen running as part of the CRM web page.
The key points are that the screen lives inside CRM, it does not pop out of the application and when it’s finished it will be styled to look like all the other screens.
This way a sales person running SageCRM, won’t know he’s running multiple Sage applications as he manages his contacts, leads and opportunities as well as entering quotes and orders. To him it is all one application.
There is a fair bit of extra work going on behind the scenes to ensure that the workflow is continuous, data is automatically transferred from one step to the next (like opportunity to quote to order), and data is automatically synchronized in both directions with Accpac. If some one edits an Order in Accpac, then the opportunity and other data is kept in sync in CRM. We are also smoothing out some of the supporting workflows, like how a lead is promoted to a customer.
There are a couple of other screens like an Order Summary screen that are being added to our SageCRM integration using the new Web Based UI framework. But many of the other screen like if you drill down into A/R or PJC will still result in the VB screen being run in 6.0. We will be looking to fix up these in Sage ERP Accpac 6.1.
Hopefully this is a step to making the End-to-End application experience much more seamless for customers. Combining this with the SData initiative, we should start seeing much closer integrations between Sage products as they incorporate all these new and exciting technologies.