Retail Management System Headquarters
Best Practices Quick Reference
We’ve created this set of best practices, tips, and tricks that can optimize your deployment, and your customers use, of Retail Management System Headquarters. Take it with you to use as a quick reference guide for set-up procedures—we’ve even included page numbers to help you find the information quickly in the Retail Management System Implementation Guide. You’ll have satisfied customers and fewer support calls.
Part 1: Deployment Considerations
Rule #1: Create a master store database for importing into the Headquarters database (page 113).
• Combine all items, customers, tenders, taxes, suppliers, etc. into one Retail Management System Store Operations database to be imported into Headquarters. • All Centrally Maintained Data should be entered/imported into this master database (page 103). • This is highly recommended when multiple stores run Store Operations prior to using Headquarters, and ensures full data synchronization between all stores and Headquarters.
Rule #2: Lock out the ability to add/delete Centrally Maintained Data from the stores (page 101).
• Use Menu and Field level security in Store Operations to disable the pertinent options (ex: disable the New button on the item list). • Otherwise, when stores add/delete local items, tenders, taxes, etc., Headquarters cannot report on or view this data, which creates a lack of audit and control at Headquarters.
Rule #3: Carefully plan and create the Store Template Database to speed new store implementation (page 115).
• Store Specific data (page 104) is copied from the template database to the new store database. • This can help speed implementation time for a new store. • For example, enable the common security settings and register options on the template database so they transfer automatically to the new store database.
Rule #4: Plan accordingly when a client has a warehouse (page 24).
• The warehouse will need to buy a Store Operations license (1 lane) in order to receive and issue inventory. • Count the warehouse as a store when buying Headquarters licenses. • Features such as Worksheet 330 and 340 help customers move inventory between stores and the warehouse in a centralized purchasing environment.
Rule #5: Headquarters Client and Headquarters Server are NOT Windows® Services (page 102).
• Place shortcuts in the Windows Start Up directory so they automatically start when a user logs on. • Logging off the machine while running these applications WILL CLOSE the application and stop communications. • Some partners make use of 3rd party tools that allow you to run any Windows application as a service.
Rule #6: Use these worksheets with caution (page 192).
• Style 51: Execute SQL Command. Exercise caution, there is no ‘undo’ button. • Style 101: Synchronize Store DB. Only needs to run one time (on the first connection). Running multiple times will only increase connection times and potentially cause bottlenecks. • Style 260: Download Items. Will overwrite ALL item attributes at the store when an existing item is sent down via this worksheet (prices, costs, reorder info, etc.). Use Style 250 to send down new items and adjust existing, static item properties. • Style 402: Request Journal Upload. This worksheet will capture ALL electronic journals from the From Date on. Keep this date to a small range to minimize data upload. • Style 601: Delete Global Customers. Doing so will remove all historical references to the customers purchases and history.
Rule #7: Deploy Headquarters for businesses that have multiple stores with similar inventory (page 23).
• Using Headquarters when multiple stores have unique inventories can be difficult. • The best fit for Headquarters is a customer who has multiple stores with mostly similar inventory among all sites.
Rule #8: Custom importing into Headquarters is not advised (page 111).
• Currently no supported import tool is available for Headquarters. • Custom import tools/queries may not adhere to table relationships, such as the relationship between Item and ItemDynamic, which can lead to data integrity issues.
Rule #9: Enable Global Customers when implementing existing stores (page 184).
• Before processing a Worksheet 101 and 401 with an existing store for the first connection, be sure to enable the Global Customer option and set all necessary customers to be Global. • You can use this Update statement to flag all customers as a Global Customer: UPDATE Customer SET GlobalCustomer = 1
Rule #10: Rethink uploading Journals to Headquarters (page 193).
• Using the configuration option in Headquarters Manager to automatically upload Sales Journals may drastically increase the connection times and bandwidth requirements. • It may also greatly increase the size of the Headquarters Database. • Consider using Worksheet 402 if a specific receipt is required for viewing at Headquarters.
Part 2: Planning Communications and Connection Schedules
Rule #1: Optimize the connection schedule to ensure optimal performance (pages 110, 186).
• Connect only as often as the client needs, not as often as they want and/or can. • Stagger store connections to keep simultaneous connections to a minimum. • Only consider frequent connections when there is: • Frequent, daily Global Customer movement and accounts receivable activity among stores. • Frequent inter-store transfers initiated and completed on the same day. • High-speed access at all stores. • Recommend that a VAR consult their RSM when engaged in pre-sale opportunities of 25 stores or more for possible TPAG evaluation.
Rule #2: If available, a Broadband connection is highly recommended (pages 106–109).
• Broadband connections will offer the greatest degree of performance, reliability, and security. • This will reduce the likelihood of bottlenecks and connection errors. • VPN connections should be considered if security is a concern.
Rule #3: Headquarters Server needs a static IP address (page 109).
• There is no need for static IP addresses at each store, only at Headquarters. • This allows for each store to always access the Headquarters Server via the same external IP address. • In rare cases where a Static IP is not possible through an ISP use an online service that can mimic a Static IP , .
Part 3: Hardware Considerations
Rule #1: Plan for ample RAM on SQL Server, Headquarters Server, and Headquarters Client machines (pages 25, 111).
• SQL Server, Headquarters Server, and Headquarters Client are all RAM intensive applications. • The more RAM available to these machines, the better performance and faster response times will be. • Recommended RAM requirements for both machines is 2 GB or higher.
Rule #2: Microsoft SQL Server™ 2000 is recommended for the Headquarters database platform (pages 27, 42).
• The increased data requirements for Headquarters make SQL Server 2000 a logical choice. • Access to Enterprise Manager and other SQL Server tools is often a valuable resource at Headquarters. • Performance governor of Microsoft SQL Server™ 2000 Desktop Engine (MSDE) may cause performance issues with Headquarters users and store connections.
Rule #3: Deploy two servers: one for the Headquarters Server and another for the Headquarters SQL Server (pages 30, 105).
• Dedicated servers ensure maximum performance and throughput for Headquarters users and store connections. • Headquarters Server application can operate on SQL Server, but for best performance two machines should be used. • Headquarters Server application doesn’t need to be on a ‘server’ class machine, provided there is ample RAM on the computer. • The Headquarters Server application machine does not need to have multiple processors as the Headquarters Server application is not multi-threaded.
Rule #4: Run Headquarters Client on a back office computer (pages 31, 106).
• While processing worksheets, Headquarters Client may affect the performance of the machine it is running on. • This makes the application better suited for a back office machine rather than a point of sale. • It is not recommended to run Headquarters Client on the same machine as the Store Operations MSDE Server.
Rule #5: Recommended disk arrangement for optimal performance on SQL Server (pages 44, 154).
• For optimal performance and disaster recovery, store the .mdf (data) and .ldf (log) files on different physical disks. • Store the data file on a RAID-5 partition (striping with parity). • Store the log file on a RAID-1 partition (mirroring). • Keep the system partition on a drive other than the data and log file partitions. Download the complete Retail Management System Implementation Guide at: https://mbs.microsoft.com/partnersource/products/rms/documentation/installationsetupguides/rmsimplementationguide.htm
MICROSOFT MAKES NO REPRESENTATIONS ABOUT THE SUITABILITY OF THE INFORMATION CONTAINED IN THIS DOCUMENT FOR ANY PURPOSE. ® 2006 Microsoft Corporation. All rights reserved. Microsoft, SQL Server, and Windows are either trademarks or registered trademarks of Microsoft Corporation in the United States and/or other countries.