If you have Microsoft Dynamics GP, or how it was known in the past – Great Plains Dynamics, implemented as your Corporate ERP system and thinking about the next phase – ecommerce integration, this small publication is for you
In our paper we favor the approach,
where you do not have to trash your existing, often programmed in-house, ecommerce web application , including shopping cart, acquired on ecommerce plug-ins software market (Magento/PHP/MySQL, ASP.Net Storefront or similar) and implement just connection between the external web application and shopping cart and Microsoft Dynamics GP. We’ll try to balance in being relatively technical in terminology, where on the other hand this paper should be readable for managerial personnel. Let’s move on to the paragraphs:
1. Ecommerce shopping cart image in Great Plains. The most natural and flexible way is to transform shopping cart into Sales Order Processing Order or Invoice with Customer deposit (especially in Business-to-Customer/B2C scenario). SOP transaction in Great Plains has all the required info about the customer, default warehouse, taxes, shipping and billing addresses, sales person, trade discount, shipping method, payment term, etc. on the document header level. And you can have unlimited number of Sales Items (document lines) with Item Number, Description, Price (with very flexible pricing engine, where price might be associated even with individual customer, when you are selling in B2B model). In some, but rather rare cases, you may decide that you do not care about inventory items, and all you need is to create flat document, where all the description is in one line and in one record (especially when you are selling service and itemization is not required), you may consider to send shopping cart (or better to say very primitive version of the cart) to GP RM Invoice. And in really exotic cases (when ecommerce integration programming was done at least five or more years ago) you might be sending shopping cart into Great Plains Invoicing module transaction (historically GP had cheaper scaled down Invoicing module and “luxury” Sales Order Processing module, where you have such additional functionality as Quote, Sales Order, Invoice, Return, Fulfillment Order, Back Order, and Invoicing module has just Invoice). We do not recommend Invoicing module as shopping cart target, as it is not covered in Dynamics GP SDK – eConnect
2. Integration Implementation. You do not even have to do custom programming in most of the cases, as we recommend Alba Spectrum eCommerce Integration module, where the integration could be set up in wizard driven manner. The module is open for custom programming, which could be done in Microsoft Visual Studio.Net C#, VB where you include eConnect libraries. Also, in some cases you may decide to do direct SQL update or insert statements (if required packed into SQL stored procedures) – this method is only recommended for advanced SQL programmers, familiar and experienced in dealing with Dynamics GP tables structure and data flow (for the rest of us, let’s stick to eConnect, where data integrity could not be compromised). Couple of comments about ecommerce integration module. It is efficient and probably required when you need real-time (instantly) or quasi real-time (every ten minutes or maybe every hour) shopping cart move to Great Plains. If your situation is tolerant to the integration time lag (let’s say – you are OK to do overnight integration or you may decide to have one specific GP user to trigger integration at the end of the shift), we recommend you to consider more budget friendly approaches, keep reading…
3. Quasi real-time and scheduled integration. Even large companies, even members of Fortune 500 could have ecommerce terms, where you can read that order fulfillment and shipping is done on the next business day. If this is fine with your rules and policies, then consider Dynamics GP Integration Manager SOP Transaction integration setup (if you have large scale of ecommerce shopping carts integration activity, we recommend you eConnect IM connectors, they should be faster, comparing to traditional OLE Server technology). Most of Dynamics GP/Great Plains consultants are familiar with Integration Manager and know how to setup integration from text files (CSV or Tab delimited) to SOP Entry. However IM is not limited to text files only. If your ecommerce shopping cart is resigned in ODBC compliant database (Oracle, MySQL, Ingress, DBII, MS Access, Btrieve/Pervasive SQL, Ctree, MS SQL Server, XML. Excel, FoxPro, Borland Paradox, etc.) – you can pull it from their directly to GP via Integration Manager integration based on Advanced ODBC query
4. Microsoft Dexterity (formerly known as Great Plains Dexterity) programming in ecommerce environment. Dexterity might be chosen as software development tool, when you would like your integration to be called from the screen, available to the user via Dynamics GP user interface. Dex is really almighty and you can do magic with Great Plains user workstation and GP database, however there is the cost. Dexterity is semi-proprietary tool and it is not possible for generic programmer to turn around and begin coding in Dexterity overnight, over weekend, over month…
5. Modifier with VBA. We know the cases, where Great Plains customer had ecommerce integration implemented in VBA scripting, called from Modifier fields. This was sort of typical in older Great Plains versions, such as 7.0, 6.0, 5.5, 5.0, 4.0. In VBA scripts you should be able to deploy pre.Net constructions, such as ADO (not ADO.Net, please be aware that Modifier with VBA are not compatible with Microsoft .Net technologies). VBA scripting is probably easier, comparing to Great Plains Dexterity, ADO is a bit low level DB access and manipulation technology, but it should do the job, especially for old versions, where you were on Pervasive SQL 2000/Btrieve or Ctree DB platforms
6. Prerequisites to launch Dynamics GP ecommerce integration project. In the best case, you should be on the current Dynamics GP version (it is 2010/11.0 as we write these lines in November 2010, or at least version 10.0). If you are on older version: 9.0, 8.0, 7.5 (and earlier), we do not recommend you to do custom programming, the only recommended approach is Integration Manager (with text file or Advanced ODBC). Please, note that ecommerce integration typically requires more time and dollar investment, comparing to bringing you to the current version of Microsoft Dynamics GP
7. Ecommerce B2B versus B2C scenarios. Business-to-Business requires more custom features, especially customer name linked price list, at the same time it is more tolerant to such requirements as barcode scanning (it is OK to enter customer order by phone, keying in the order lines in Dynamics GP SOP transaction screen). B2C scenarios require more POS features, such as coupons, sales promotion campaigns, credit card based prepayments. Our editor tells us that we are at the point to wrap up our publication
8. To request further support, please call us 1-866-528-0577, help@albaspectrum.com We need to discuss your cards in order to recommend you the best solutions, which is not contingent to our preferences. We serve you USA/Canada nationwide via remote support (web sessions and phone/Skype conferences). Local service is available in Western Michigan, Chicagoland, Southern California (LA, Orange County, San Diego), Houston area of the state of Texas
