I am a small business owner and I need to link my current store inventory to that of my website.  I need every sale, whether it is in the store or on the website, to be recorded in both places (in the store's computer and on the website).  PLEASE HELP!!!

Hello, I've merged together your two threads into one since they are both pretty much about the same topic.  Please make sure you only post one thread per topic - as it makes the job easier on the folks that are trying to find and answer for you.   Thanks!

Not familiar with any shopping cart software that might do that, but I am sure somebody here might have a suggestion for you.

I have no idea how to do what you mentioned... I'm not even sure I understand what you mean.  I am very new at this and apologize for my inexperience.

OK, so you've got a brick-and-mortar store (bStore) and an online store (eStore), both drawing upon the same inventory. You mentioned a "store computer" -- do you have a Point Of Sale system (POS, which instantly updates the computerized inventory), or is it manually updated on a batch basis once a day or something?

You have two choices: keep separate databases for the bStore and eStore, or try to make them work off the same inventory database. If separate, to keep the bStore and eStore in sync, you'll have to set up a peer-to-peer system. The bStore's inventory database will be updated from the POS (or manually) and will send queries to the eStore's inventory database to draw down stock due to bStore sales and increase stock due to merchandise purchases. Likewise, the eStore's inventory database will have to periodically send queries to the bStore's, to report eStore sales (draw down inventory). Note that as the two systems are likely to be quite different, and may not both use the same database system, you'll have to write code to generate queries to update the other database.

It should be possible to keep only one inventory database (at the website or at the store), but you'll have problems when you temporarily lose access to the eStore. If the database is at the website (eStore), you'll have to write code to have a remote computer (at the bStore) periodically update the eStore's inventory list. I think it's possible to grant access permissions to a remote computer to get at a MySQL database on LP, but I haven't tried it myself. Conversely, you should be able to have one inventory database at the bStore that the eStore works against -- I don't think you have to have your eStore databases at LP. The problem is that if you temporarily lose your connection between your bStore and LP, either your bStore computer will be down, or your eStore will be down. Also, a POS system and your eStore shopping cart will very likely have completely different databases, and it will take quite a bit of tweaking to get one to run off the other's database.

Either way, unless you have constant (live) POS updating of the inventory database, you run the risk of being unable to fulfill an eStore order (you're actually out of stock) or you lose a sale because the eStore thinks it's out of stock when in fact you just got a truckload of merchandise in. Do you restock quickly enough that an eStore sale of something that was actually out of stock wouldn't be a big problem, or would you have to cancel an order? How frequently would the database(s) need to be updated? Unless you've got a fairly big operation, I wouldn't think that a small DB query every 5 or 10 minutes would kill your bandwidth quota or CPU limit. If the consequences of selling when out of stock are severe, I'd make sure that it's the eStore that shuts down (use one database, at the bStore).

If all of this is too much to deal with (it will be a considerable amount of programming needed either way), consider just keeping separate inventories for bStore and eStore. Just label some of your shelves "eStore merchandise" and don't move them into your bStore displays. If you run low on stock on one or the other side, draw down the inventory on one side, move that amount to the other side, and update the receiving side's inventory. That way you should never end up selling against empty inventory on either side, but can move merchandise back and forth as needed (just make sure it the move gets properly entered into the inventory databases).

Just some random, quasi-disorganized thoughts that hopefully will be of help. Perhaps you could tell us the nature of the *Store and how the bStore's inventory is kept updated?


Can a moderator or administrator please move this thread to Ecommerce Hosting, where it belongs?

I currently use Microsoft POS to track my inventory, it is constant live updating.  How exactly do I have my eStore check in with my bStore's inventory?  If one has to be down I would definitely want it to be the eStore, not the bStore.  Do most people just have seperate inventories for their bStore and eStore?   

So just what does "POS" stand for in the context of a Microsoft product?    Somewhere in the MSPOS there will have to be a database. Once someone has figured out its structure (I'll bet it's not documented), or has partnered with MS and promised their eternal soul to Bill Gates, they would know what kind of queries to run against the MSPOS database. Something would have to be done on the eStore end (probably in the customer checkout code) to generate the appropriate queries to draw down the bStore inventory (MSPOS). You'll probably pay big money for that kind of knowledge.


For smaller businesses, I would suggest starting out with separate inventory databases. You can always go into the storeroom and shift inventory from bStore to eStore (or vice versa), depending on what's selling well at the moment. Just be religious about updating both inventory databases -- first draw down one store, physically move or tag the inventory as being "the other store's", and finally increase the stock in the moved-to store. That way you should never find yourself in the situation of having sold inventory that doesn't exist.