One Catalogue, Two Channels: How We Think About Sharing Stock Between the Counter and the Website

A garment shop in Surat has one maroon kurti left in size M. At 7:40 pm a customer at the counter picks it up. At 7:41 pm someone on the shop's website orders the same kurti, same size, same colour. (This is a composite example, not a real shop.)

If the counter and the website keep separate stock counts, both sales go through. Someone has to phone the online customer the next morning and apologise. Do that a few times during Diwali and people stop trusting the website.

We build VyaparNext by Smart Byte Labs, garment shop billing software made in Surat. This post isn't a tour of our code. It's how we think about one catalogue serving two channels, and the questions we'd ask of any system that claims to do it.

Two shops, one shelf

Most shops that go online start with two systems: billing software at the counter and a separate e-commerce site. Each has its own product list and its own stock count. Someone reconciles them by hand, usually late at night, usually from memory.

The idea behind sharing stock is simple to say: there is one shelf, so there should be one stock count. A sale at the counter and an order on the website should both draw from the same number for that exact size and colour.

It's harder than it sounds, for three reasons.

1. The catalogue has to be the same catalogue

Sharing stock only works if both channels agree on what a "thing" is. In the previous post in this series we argued that stock lives on the variant (one size in one colour), never on the design.

That matters twice as much here. If the website sells "Kurti A, M, Maroon" and the counter scans a barcode that means "Kurti A (assorted)", there's nothing to share. The two channels have to point at the same variant rows, with the same sizes, colours and barcodes.

A rough way to picture it (illustrative only, not VyaparNext's schema):

// Illustrative only: a way to think about it, not our code.
type Variant = {
  sku: string;        // "KURTI-A-M-MAROON"
  size: string;       // "M"
  colour: string;     // "Maroon"
  barcode: string;    // printed on the tag
  stock: number;      // ONE number, used by both channels
};

type StockMovement = {
  sku: string;
  qty: number;        // -1 for a sale, +n for a purchase or return
  channel: "counter" | "website";
  reference: string;  // bill number or order number
};

Both channels write movements against the same variant. Neither one owns the stock.

2. Movements beat overwrites

The easy way to "sync" is to copy a number: the counter says M maroon is 3, so set the website to 3. That breaks the moment both sides sell between copies. One sale quietly overwrites the other and stock comes out wrong.

We think about stock as a history of movements instead. A purchase adds pieces, a bill removes one, a website order removes one, a return adds one back. The current count is the result of all of them. When two channels sell close together, both movements are kept, so the count stays honest even if it goes to zero (or briefly below it, which tells you exactly which sale needs attention).

The same thinking runs through VyaparNext's Cloud Sync for counters: stock is recalculated from sales and purchases across devices rather than copied blindly, and when the same product is edited on two devices, the conflict is flagged so a person chooses what to keep.

3. The counter can go offline. The website can't wait.

A garment shop counter has to keep billing when the internet drops. That's the whole point of offline billing software with cloud backup. But a website keeps taking orders all night, whether the counter is online or not.

So there's always a window where the two channels can't see each other. Good design admits that window instead of pretending it doesn't exist. The questions we keep asking:

• What happens to the last piece? For fast-moving sizes, some shops keep a small buffer off the website during the festive rush, so the last one or two pieces are sold at the counter only. It's a business choice, not a technical one, but the system should make it easy.
• Who gets told when both sides sold the last piece? A clear list of oversold orders beats a stock count that silently goes negative.
• Does the counter catch up on its own? When the connection comes back, bills made offline should flow in as movements, not as a pile of numbers to type in again.

We'd rather be plain about this than promise "instant" anything. Sync takes time, and a shop owner who knows how long it takes can plan around it.

Where VyaparNext's plans fit

This is how it maps to what we sell today, from the live pricing page:

• POS Lite is free to start on one counter. Billing, purchases and stock stay on that device, and there's no automatic cloud sync.
• Cloud Sync (₹299/month + GST) keeps counters in step about every hour.
• Store (₹25,000 setup + GST, then ₹1,200/month + GST) is a managed online store. It doesn't include the counter POS.
• Commerce (₹35,000 setup + GST, then ₹1,800/month + GST) is the plan where the counter and the website share inventory, orders and customers. A sale at the counter and an order on the website draw from the same stock.

If a shop only needs the counter for now, POS Lite is enough. The shared-stock question only starts to matter once a website is actually selling the same pieces.

Three questions to ask any "one stock" system

Whether you're building this or choosing a POS software for garment shops:

1. Do the counter and the website sell the same variant rows, down to size and colour?
2. Is stock kept as movements (sales, purchases, returns) or copied as a number?
3. What happens, and who is told, when both channels sell the last piece?

Start free with POS Lite on one counter, or book a free demo on WhatsApp: [phone]. More at vyaparnext.com.

Previously in this series: Modelling Clothing Variants: Why a Kurti Isn't One Product.