How Online Orders Update Your POS Stock

Most shops that sell online end up running two inventories. There is the one in the till, which is right, and the one in the webshop, which was right on the day somebody typed it in. Then a customer orders the last of something that sold in the shop an hour earlier, and you are calling them back to apologise.

The fix is not discipline. It is that the two systems should have been one system. Here is what that actually requires.

One catalogue, not two that sync

The word “sync” is doing a lot of hiding. Two separate product lists that periodically copy each other will always have a window where they disagree — and that window is exactly when a busy Saturday causes the problem. Every sync also has to decide who wins when both sides changed, and that decision is invisible until it goes wrong.

A shop and a till that share one catalogue have no window and no conflict, because there is nothing to reconcile. The product a customer sees online is the product row the cashier is selling from. Change a price once and both are correct, because there is only one price.

Stock has to move at the moment of sale

Whichever side the sale happens on — barcode scanned at the counter, or checkout completed on a phone at midnight — the count has to drop then, not in a nightly job. Anything slower means the number is a forecast rather than a fact.

This matters more than it sounds for the last unit of something. Two people can want it at once, one in the shop and one online. Only a single shared count decides that correctly.

The order has to arrive somewhere a person will see it

An online order that lands in an inbox nobody has open is not much better than a missed phone call. It needs to reach the till the staff are already looking at, and the owner's phone, at the moment it happens.

That also settles a question most shops hit early: who is responsible for the web order? If it appears on the same screen as every other order, the answer is whoever is on shift — no separate process, no separate person.

And it has to survive the internet dropping

In Lebanon this is not an edge case. If the connection goes while the shop is open, counter sales have to keep working and queue locally, then reconcile when the line returns. The web side is unavailable during that window by definition — nobody can reach it — so the ordering matters: counter sales that happened offline still have to be applied before the shop is trusted again.

This is the part a bolted-together setup almost never handles, because the two systems each assume the other was online.

What to ask a vendor

Three questions separate one system from two systems wearing a costume. Do the shop and the till read the same product records, or does something copy between them? When a sale happens on one side, when exactly does the other side's count change? And what happens to both if the internet drops mid-day?

If the answers involve an interval, a plugin, or an export, you are buying two inventories and the job of keeping them agreeing.