Microsoft Great Plains and Microsoft Retail Management System (Microsoft RMS) are originally developed by different software vendors, who had no idea that in the remote future (now) these two applications will be owned by Microsoft and will need to be tightly integrated.
Current integration between the two is not an easy thing. At this time MBS has RMS integration on the General Ledger and Purchase Order level into Great Plains out of the box. This integration has some advancements in comparison to old product: QuickSell, but it is still GL and PO only. We do understand the need for midsize and large retail companies, structured as clubs and selling on account to their members to have more adequate integration when you can synchronize your Sales information and have robust Great Plains reporting.
There is the product on the market, which is integration on the Receivables Management and Purchase Order Processing level from RMS to Great Plains, written by Daniel Sionov and Andrew Karasev and maintained by the alliance between LightEdge Solutions (www.lightedge.com) and Alba Spectrum Technologies (www.albaspectrum.com). In Alba Spectrum Technologies we actually do coding and product tuning for specific client needs. This product allows you to map multiple RMS stores to one or multiple Great Plains companies. We usually have to tune it for specific needs of the customer, but in general words – it is based on SQL insert into statement and so can handle hundred thousands transactions per day – maximum of what RMS can handle. Integration is usually setup on RMS Headquarters database. However we can set it for Store Operations database.
Overview of out-of-the-box Microsoft RMS integration. This integration is currently available for Great Plains version 7.5 and Microsoft RMS 1.2. MBS is in process of subcontracting Nodus Technologies to write new integration for version 8.0. The weak points of the out-of-the-box 7.5 integration are:
1. It is for integration into one Great Plains company only. If you have multiple stores as multiple companies in Great Plains – then you have to remember which batch should be posted into which Great Plains company.
2. It is on GL and Purchasing level only. So, if you have to reconcile checkbooks / Bank Reconciliation module in Great Plains – you can not do it with standard integration
If you are developer you can end up with your own custom solution, we would like to give you directions.
1. Great Plains Integration Manager – if the sales volume is very low, say 100 transactions per day – then you can do data export from RMS and import it into Great Plains via Integration Manager. This is rather end-user tool – it is very intuitive, it validates 100% of business logic, brings in/updates master records (accounts, employees, customers, vendors. etc.) brings in transactions into work tables. The limitation of Integration Manager – it does use GP windows behind the scenes without showing them – so it is relatively slow – you can bring 100 records – but when you are talking about thousands – it is not a good option. By the way you can program Integration Manager with VBA.
2. eConnect – You can create VB.Net application which will be pulling info from RMS and then uses eConnect to move it to Great Plains. eConnect is kind of Software Development Kit with samples in VB.Net. Obviously the development environment should be Visual Studio.Net. eConnect will allow you to integrate master records – such as new customers, vendors, employees, etc., plus you can bring transactions into so called Great Plains work tables (eConnect doesn’t allow you to bring open or historical records – you need to post work records in Great Plains, the same limitation applies to Integration Manager above) eConnect is rather for ongoing integration. It was initially created for eCommerce application integration to Great Plains.
3. SQL Stored Procedures. The product we’ve mentioned above is collection of stored procs. Obviously you have unlimited control and possibilities with SQL queries. You need to know Retail Management System Headquarters and Great Plains tables structure and data flow. Launch Great Plains and go to Tools->Resource Description->Tables. Find the table in the proper series. If you are looking for the customers – it should be RM00101 – customer master file. If you need historical Sales Order Processing documents – they are in SOP30200 – Sales History Header file, etc. Do not change existing tables – do not create new fields, etc. Also you need to realize that each GP table has DEX_ROW_ID – identity column. Sometimes it is good idea to use inbound/outbound XML in the parameters – then you can deploy web service as a middle party between two systems. RMS tables structure is self explanatory.
4. Data Transformation Services (DTS) – Good tool for importing your third party data into staging tables in GP – then you can pull them in using either stored procs of Integration Manager. You can also deploy this tool for EDI export/import.
5. Great Plains Dexterity Custom Screens. You can create the window, which will have integration settings in it – RMS store ID matching GP Company database, etc. Sometimes users prefer to have seamlessly integrated into GP interface custom screens – for parameters settings and initiating integration. Dexterity is a good option, however remember – it is always better to create new custom screen versus customizing existing one – due to the future upgrade issues. Also – Dexterity is in phasing our by Microsoft Business Solutions.
6. Modifier/VBA custom buttons on the existing screens – alternative to Dexterity is you are comfortable with VBA and ADO.
Andrew Karasev is Chief Technology Officer in Alba Spectrum Technologies USA nationwide Microsoft CRM, Microsoft Great Plains customization company, based in Chicago, California, Texas, New York, Georgia and Florida and having locations in multiple states and internationally (www.albaspectrum.com), he is Dexterity, SQL, C#.Net, Crystal Reports and Microsoft CRM SDK developer.
