| > | | | | RMS to GP RM invoices), plus you should consider |
| If you are at the point of decision on Microsoft | | | | moving Purchase Receipts as Inventory Assets |
| Dynamics GP, formerly known as Great Plains | | | | accounts referencing transactions from RMS to GP |
| Dynamics, implementation for Retailer with multiple retail | | | | on General Ledger transaction level only |
| stores, we would like to describe solutions, which | | | | |
| could be deployed in your organization | | | | 3. GP Integration with MS RMS. We are |
| We always recommend our customer to try to avoid | | | | offering ready for redeployment codes, however in |
| risk of ERP implementation failure and the best way to | | | | the second scenario from Paragraph 2, you could |
| do this is to avoid huge customizations, especially if | | | | consider integration from others Retail and POS |
| you or your current Dynamics GP Consultant or | | | | systems: Counterpoint, Navision Retail, POS Prophet, |
| Programmer never done something similar, in similar | | | | Retail Anywhere, mPower Retail, Retail Star, The |
| business case and in similar industry: | | | | Edge, Tylernet, or others. The key in the integration |
| | | | | design is the ability to expose Retail transactions to |
| 1. Retail and Point of Sale application. | | | | either ODBC, or Text file export scenarios to be |
| Typically this application covers Purchasing, Barcode | | | | imported to Great Plains. We have custom codes |
| labels printing, POS (Point of Sale — cash | | | | for GP and Microsoft Retail Management System, |
| registers, with credit card, cash and other payment | | | | however the same codes should do one way |
| forms capabilities, supporting POS monitors, etc.), | | | | integration to GP with minimal modification |
| Pricing (including items on sale, buy one get one/two | | | | |
| free, etc.). Usually the dilemma for IT and business | | | | 4. Retail business processes and |
| owner is this — should I keep Purchasing and | | | | requirements are often unique and maybe dictated by |
| Inventory control functionality in my Retail System or | | | | industry regulation rules: Jewelry, Food, Merchandise, |
| synchronize it with GP and have Great Plains | | | | Hardware, Restaurants, Gift Shops, Antiquities, |
| Dynamics as Master with propagating Purchasing and | | | | Consumer Electronics and Computer Parts, Online |
| Inventory counts back to Retail application? In the | | | | Services, etc. In Jewelry and Gifts we got the |
| case of Dynamics GP we saw a lot of integrations | | | | impression, that items are really unique and you have |
| with Microsoft RMS and in our opinion this system is | | | | to deploy GP Lot Number or Serialization and it should |
| very good for integration scenario, when Great Plains | | | | be propagated back to RMS as new item with the id |
| is controlling Purchasing and Inventory | | | | being the combination of GP Item Number and Lot |
| | | | | Number suffix |
| 2. Modules in GP, where integration typically | | | | |
| happens. If you plan to control Inventory and | | | | 5. Barcodes. If you are deploying |
| Purchasing in Great Plains, integration works in GP | | | | Microsoft RMS, you can print your label Crystal |
| Sales Order Processing (moving daily Sales to GP), | | | | Reports directly from RMS Enterprise Manager or |
| Purchase Order Processing (moving received items to | | | | Store Operations, or you can print them from |
| RMS and often printing barcoding labels from GP), | | | | Dynamics GP, if you are controlling purchase receipt in |
| Inventory Counts and transfers between sites (moving | | | | Great Plains. In both scenarios you will need some |
| from Great Plains back to RMS). On the other hand, | | | | custom reports design and integration into RMS or GP |
| if you do not plan to control Inventory Items flow in GP, | | | | user interface |
| then integration should only happen on Receivable | | | | |
| Management module level (moving daily sales from | | | | 6. |