I've got HQ up and running and am getting a feel for how it works in relation to Store Ops. I'm ready to connect a second store, and have more questions than answers. The manual is not always as explicit as I'd like...
I need to create the Store Two DB and connect to HQ. I have the customer and inventory data in Excel, so I can import into HQ, SO or both fairly easily. I have both QSimport and EMS Data Import.
I am using global customers everywhere. This does create some serious limitations, as every little change (add a shipping address, change address/phone/name) has to be done at HQ and isn't reflected immediately. OTOH, the downside of using local customers everywhere is too great. We'll learn to live with the limitations.
Can I simply import the customers into my HQ DB? Will the store receive all of the customer data when I run the 101? Or is it better to import the customers into SO?
Store Two has quite a few items that Store One didn't have when the HQ DB was created. What do I need to do about this? Do I import the items (sans qty) into HQ and then import the items (with qty) into SO? Is it possible to imort the items with qty into HQ and keep the qty data store-specific?
What about POS custom buttons and macros? Is there a way to import this data from one SO DB to another? Is this info stored in the HQ DB at all?
With regard to this 'master' database... Isn't this the same DB I imported into the existing HQ DB?
Maybe I missed something when I first deployed HQ. Let's say I create a new master SO DB with customers and items from all of my four stores. Should I have any inventory quantity data in there? The actual store inventories vary dramatically. The differences in items stocked is significant, and the difference in quantities for commonly stocked items could be 10:1 or more. On top of all that, only one store is running RMS at present.
Tell me if this is correct: the master DB should contain all items from all stores with reorder info, etc. but with no quantity data. Additionally, it should contain all of the customers with outstanding balances from all stores. New customers will be added by the stores and brought to HQ (and distributed to the other stores) with the regularly scheduled 401s. Store inventory qty info will be established with a physical count when the store is brought online and tehn maintained with the aforementioned 401 worksheets.
When I bring a new store online, will the data I export from HQ to the new Store Ops DB contain qty data? Do I just do my physical count and commit it, ignoring the starting data from HQ?
Another hypothetical: what if we add another store? All of our stores were acquisitions of existing/competing stores. Any new store would definitely have lots of new items and probably more than a few customers--even if we were only interested in the folks with outstanding balances. How would I get this info into my existing HQ and SO databases? Would I be looking at importing into the 'master' SO DB then re-importing into HQ then re-exporting to all stores then performing a physical count (or simply taking the existing SO data), issuing a 501 for all stores then running a 190 for all stores?
The above hypothetical isn't all that hypothetical. Our most recently acquired store has no inventory DB at all. It's all on paper. I'd prefer not to have to add all of that data to my master DB now, only to have that info change substantially before I'm ready to bring that store online.
Jeff, you have been a tremendous resource to me over the last few months and I *really* appreciate it.
With regard to this 'master' database... Isn't this the same DB I imported into the existing HQ DB?
Similar except that info the HQ will now become the "master" It contains all "Centrally Maintained" data, meaning stuff that's common to all stores. HQ actually then calls it a store "template" database. Again, looking at the HQ Admin Help screen, search for "template database". Read and its important to make sure you understand that entire page.
Maybe I missed something when I first deployed HQ. Let's say I create a new master SO DB with customers and items from all of my four stores. Should I have any inventory quantity data in there?
When you create a new store, the items will transfer, but not the quantites. After you create the store, you should do an physical inventory count at the store, then create a 501 worksheet at HQ and then do a 190 wizard again at HQ. The 501 requests from the store their quantities on hand and the 190 will then update the HQ database with the info.
The actual store inventories vary dramatically. The differences in items stocked is significant, and the difference in quantities for commonly stocked items could be 10:1 or more. On top of all that, only one store is running RMS at present.
When you create the store, it will also ask for mins and maxs. You can set them at a fixed number or leave it at zero and change them later using a 303 worksheet in HQ.
Tell me if this is correct: the master DB should contain all items from all stores with reorder info, etc. but with no quantity data.
If possible, yes, but I doubt you can do it. Just add the items in HQ as you run into them, probably while taking inventory, described above. The template will set all quantities set to 0.
Additionally, it should contain all of the customers with outstanding balances from all stores. New customers will be added by the stores and brought to HQ (and distributed to the other stores) with the regularly scheduled 401s.
Customers will transfer when creating the new store. Whatever info is in there will transfer and will contiunlly be updated with 401s.
Store inventory qty info will be established with a physical count when the store is brought online and tehn maintained with the aforementioned 401 worksheets.
When I bring a new store online, will the data I export from HQ to the new Store Ops DB contain qty data? Do I just do my physical count and commit it, ignoring the starting data from HQ?
No, a Physical at the store, then a 501 Request, then 190 Update. 401s along with others will keep the inventory updated.
Another hypothetical: what if we add another store? All of our stores were acquisitions of existing/competing stores. Any new store would definitely have lots of new items and probably more than a few customers--even if we were only interested in the folks with outstanding balances. How would I get this info into my existing HQ and SO databases? Would I be looking at importing into the 'master' SO DB then re-importing into HQ then re-exporting to all stores then performing a physical count (or simply taking the existing SO data), issuing a 501 for all stores then running a 190 for all stores?
Either enter the customers into HQ before the creation of the store and the customers will transfer to it or after you setup the store, enter them into SO and they will be uploaded to HQ.
The above hypothetical isn't all that hypothetical. Our most recently acquired store has no inventory DB at all. It's all on paper. I'd prefer not to have to add all of that data to my master DB now, only to have that info change substantially before I'm ready to bring that store online.
Bummer, but then again that's why you got it so cheap!! ;-) Again, you will have to add the items into HQ and then the store template will contain those items.
One more thing to remember. After you create and install the store, you need to manually create the first 401 and 101 at HQ, after that the HQ client schedule takes over.
Sidenote; I was wrong, the POS buttons don't move between stores. Sorry ;-(
Jeff, you have been a tremendous resource to me over the last few months and I *really* appreciate it.
UPDATE: I found an old thread from 2004 on the Google archive of this group where Glenn Adams received this reply to a question similar to mine:
"You will need to create a master database with all items from all stores, use this database to build the HQ database and then create your stores, when you do your first 401 all the movement will be brought into HQ, then do a 501 to pull in store inventory levels, then do a Task
190 from the HQ inventory wizard and accept the store inventories. This is a simplification of the process with lots of possible errors coming from the same item existing at multiple stores with different Item numbers, store inventories that aren't correct & etc."
Is that an accurate summary? If so, I feel confident that I can do this fairly easily.
I'm getting the impression that customer data is not really a part of the 'master' DB. It's really the inventory items I'm after, and that the quantities in the SO database used to create the 'master' are also unimportant.
With regard to this 'master' database... Isn't this the same DB I imported into the existing HQ DB?
Similar except that info the HQ will now become the "master" It contains all "Centrally Maintained" data, meaning stuff that's common to all stores. HQ actually then calls it a store "template" database. Again, looking at the HQ Admin Help screen, search for "template database". Read and its important to make sure you understand that entire page. The only part of that page that's even slightly confusing is Part 6, 'Export Store Operations Databases'. Here's what I did (you tell me how messed up it was): I made a backup of my one and only active SO DB. I used it as my 'master' and imported it into my newly created blank HQ DB to create my active HQ DB. I continued to use the original SO DB. I ran the 101 and 401, set up schedules, etc. Everything seemed to be working. I ran a 501 and a 190. Inventory seems to match. New customers can be created but existing customers can no longer be modified in SO (at least not after the next 401 runs). It appears that customer statements need to be generated from HQ Mgr. I have set security so that a lot of functions that used to be performed in SO are now blocked and will have to be performed in HQ--for example, without Administrator Rights and the proper security level (nobody has it) you cannot create new items, copy existing items or delete existing items from SO. You cannot create new POs, delete existing POs, change a PO recipient or ship-to, or add/delete lines on a PO. All of these functions will now have to be done at HQ.
Regarding the 'master' and 'template' databases. These are two separate things (or can/should be). I have a 'master' DB that I'm not really using. I have an active HQ DB that is no longer the same as the 'master' DB. Is my active HQ DB now my 'master'? Can I use an existing SO DB as the 'template' and the existing HQ DB as the 'master' or is that a recipe for disaster? When I add an item to my active HQ DB, my original 'master' DB is no longer up-to-date.
[snipped for brevity] Another hypothetical: what if we add another store? All of our stores were acquisitions of existing/competing stores. Any new store would definitely have lots of new items and probably more than a few customers--even if we were only interested in the folks with outstanding balances. How would I get this info into my existing HQ and SO databases? Would I be looking at importing into the 'master' SO DB then re-importing into HQ then re-exporting to all stores then performing a physical count (or simply taking the existing SO data), issuing a 501 for all stores then running a 190 for all stores?
Either enter the customers into HQ before the creation of the store and the customers will transfer to it or after you setup the store, enter them into SO and they will be uploaded to HQ. So I can create the store database (from HQ, creating all those items in the process), then import the customers into the new SO DB using QSimport and the customers will automatically be added to the HQ DB with that first 401? Then I do my physical, 501, 190, etc. The above hypothetical isn't all that hypothetical. Our most recently acquired store has no inventory DB at all. It's all on paper. I'd prefer not to have to add all of that data to my master DB now, only to have that info change substantially before I'm ready to bring that store online.
Bummer, but then again that's why you got it so cheap!! ;-) Again, you will have to add the items into HQ and then the store template will contain those items. Is there any reason why I cannot import these items into my HQ DB? Creating them by hand would be a huge task. One more thing to remember. After you create and install the store, you need to manually create the first 401 and 101 at HQ, after that the HQ client schedule takes over.
Sidenote; I was wrong, the POS buttons don't move between stores. Sorry ;-( The HQ Admin 'template database' screen implies that the buttons can be imported if the 'template' DB is an SO DB. I sure hope that part works.
I'm getting there. I have resigned to the fact that I probably need to bring in my reseller on this one, so hopefully he'll be available next week and I won't be pestering you folks so much...
With regard to this 'master' database... Isn't this the same DB I imported into the existing HQ DB?
Similar except that info the HQ will now become the "master" It contains all "Centrally Maintained" data, meaning stuff that's common to all stores. HQ actually then calls it a store "template" database. Again, looking at the HQ Admin Help screen, search for "template database". Read and its important to make sure you understand that entire page. The only part of that page that's even slightly confusing is Part 6, 'Export Store Operations Databases'. Here's what I did (you tell me how messed up it was): I made a backup of my one and only active SO DB. I used it as my 'master' and imported it into my newly created blank HQ DB to create my active HQ DB. I continued to use the original SO DB. I ran the 101 and 401, set up schedules, etc. Everything seemed to be working. I ran a 501 and a 190. Inventory seems to match. New customers can be created but existing customers can no longer be modified in SO (at least not after the next 401 runs). It appears that customer statements need to be generated from HQ Mgr. I have set security so that a lot of functions that used to be performed in SO are now blocked and will have to be performed in HQ--for example, without Administrator Rights and the proper security level (nobody has it) you cannot create new items, copy existing items or delete existing items from SO. You cannot create new POs, delete existing POs, change a PO recipient or ship-to, or add/delete lines on a PO. All of these functions will now have to be done at HQ.
Regarding the 'master' and 'template' databases. These are two separate things (or can/should be). I have a 'master' DB that I'm not really using. I have an active HQ DB that is no longer the same as the 'master' DB. Is my active HQ DB now my 'master'? Can I use an existing SO DB as the 'template' and the existing HQ DB as the 'master' or is that a recipe for disaster? When I add an item to my active HQ DB, my original 'master' DB is no longer up-to-date.
The "master" is _only_ used to create the HQ database, after that, when you create a new store, HQ is used to create the "template" store database.
[snipped for brevity] Another hypothetical: what if we add another store? All of our stores were acquisitions of existing/competing stores. Any new store would definitely have lots of new items and probably more than a few customers--even if we were only interested in the folks with outstanding balances. How would I get this info into my existing HQ and SO databases? Would I be looking at importing into the 'master' SO DB then re-importing into HQ then re-exporting to all stores then performing a physical count (or simply taking the existing SO data), issuing a 501 for all stores then running a 190 for all stores?
Either enter the customers into HQ before the creation of the store and the customers will transfer to it or after you setup the store, enter them into SO and they will be uploaded to HQ. So I can create the store database (from HQ, creating all those items in the process), then import the customers into the new SO DB using QSimport and the customers will automatically be added to the HQ DB with that first 401? Then I do my physical, 501, 190, etc.
I don't know if QSImport sets the proper flag for global customers. You may have to do it manually. The above hypothetical isn't all that hypothetical. Our most recently acquired store has no inventory DB at all. It's all on paper. I'd prefer not to have to add all of that data to my master DB now, only to have that info change substantially before I'm ready to bring that store online.
Bummer, but then again that's why you got it so cheap!! ;-) Again, you will have to add the items into HQ and then the store template will contain those items. Is there any reason why I cannot import these items into my HQ DB? Creating them by hand would be a huge task.
I haven't tried to import anything into HQ. My suspicion is that its tougher to do because of the multi-store issues. Maybe someone else can answer that one. Or maybe look at Retail Realm's Imprt program.
One more thing to remember. After you create and install the store, you need to manually create the first 401 and 101 at HQ, after that the HQ client schedule takes over.
Sidenote; I was wrong, the POS buttons don't move between stores. Sorry ;-( The HQ Admin 'template database' screen implies that the buttons can be imported if the 'template' DB is an SO DB. I sure hope that part works.
I'm getting there. I have resigned to the fact that I probably need to bring in my reseller on this one, so hopefully he'll be available next week and I won't be pestering you folks so much...
Probably a good idea! While at lot of things can be done via e-mail, there are little things one forgets about instead of actually doing it live.
BeanSmart website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.