Dynamics Gp In Retail Business: Implementation And Integration Notes

If you are at the point of decision on Microsoft Dynamics GP, formerly known as Great Plains Dynamics, implementation for Retailer with multiple retail stores, we would like to describe solutions, which could be deployed in your organization. We always recommend our customer to try to avoid risk of ERP implementation failure and the best way to do this is to avoid huge customizations, especially if you or your current Dynamics GP Consultant or Programmer never done something similar, in similar business case and in similar industry:

1.Retail and Point of Sale application. Typically this application covers Purchasing, Barcode labels printing, POS (Point of Sale cash registers, with credit card, cash and other payment forms capabilities, supporting POS monitors, etc.), Pricing (including items on sale, buy one get one/two free, etc.). Usually the dilemma for IT and business owner is this should I keep Purchasing and Inventory control functionality in my Retail System or synchronize it with GP and have Great Plains Dynamics as Master with propagating Purchasing and Inventory counts back to Retail application? In the case of Dynamics GP we saw a lot of integrations with Microsoft RMS and in our opinion this system is very good for integration scenario, when Great Plains is controlling Purchasing and Inventory

2.Modules in GP, where integration typically happens. If you plan to control Inventory and Purchasing in Great Plains, integration works in GP Sales Order Processing (moving daily Sales to GP), Purchase Order Processing (moving received items to RMS and often printing barcoding labels from GP), Inventory Counts and transfers between sites (moving from Great Plains back to RMS). On the other hand, if you do not plan to control Inventory Items flow in GP, then integration should only happen on Receivable Management module level (moving daily sales from RMS to GP RM invoices), plus you should consider moving Purchase Receipts as Inventory Assets accounts referencing transactions from RMS to GP on General Ledger transaction level only

3.GP Integration with MS RMS. We are offering ready for redeployment codes, however in the second scenario from Paragraph 2, you could consider integration from others Retail and POS systems: Counterpoint, Navision Retail, POS Prophet, Retail Anywhere, mPower Retail, Retail Star, The Edge, Tylernet, or others. The key in the integration design is the ability to expose Retail transactions to either ODBC, or Text file export scenarios to be imported to Great Plains. We have custom codes for GP and Microsoft Retail Management System, however the same codes should do one way integration to GP with minimal modification

4.Retail business processes and requirements are often unique and maybe dictated by industry regulation rules: Jewelry, Food, Merchandise, Hardware, Restaurants, Gift Shops, Antiquities, Consumer Electronics and Computer Parts, Online Services, etc. In Jewelry and Gifts we got the impression, that items are really unique and you have to deploy GP Lot Number or Serialization and it should be propagated back to RMS as new item with the id being the combination of GP Item Number and Lot Number suffix

5.Barcodes. If you are deploying Microsoft RMS, you can print your label Crystal Reports directly from RMS Enterprise Manager or Store Operations, or you can print them from Dynamics GP, if you are controlling purchase receipt in Great Plains. In both scenarios you will need some custom reports design and integration into RMS or GP user interface

6.We are not touching here advanced topics, instead we invite you to call us: 1-866-528-0577, or email us: help@albaspectrum.com