One style, forty SKUs, one number
Systems that track the style rather than the variant cannot tell you that you are out of M navy but drowning in XXL beige — which is the only fact that matters for reordering.
Size × colour × season, without the spreadsheet.
Fashion inventory multiplies: one style becomes forty SKUs once you count sizes and colours. VAP treats every size-colour-fit combination as a real SKU with its own stock, price and history, so sell-through is measurable, inter-store transfers are recorded, and a sold-out size disappears from your webstore at the same moment it leaves the rack.
What gets in the way
Systems that track the style rather than the variant cannot tell you that you are out of M navy but drowning in XXL beige — which is the only fact that matters for reordering.
The size that will not move in one store is the size another store is asking for, but without per-site stock nobody can see it in time to transfer.
When the webstore keeps its own inventory, the last piece sells twice on a sale weekend and somebody gets a refund instead of a parcel.
What you get
Size, colour and fit are variant options. Every combination tracks its own stock, price, barcode and history.
See exactly which styles move and which need marking down, per store, before the season ends rather than after.
Move slow stock to the outlet where it sells, recorded as a movement — including cross-GSTIN branch transfers that raise a proper tax invoice.
Barcode POS per terminal with every tender type, exchanges and credit notes tied back to the original invoice.
Buy by style and size ratio, receive against the PO, and post landed cost straight into stock.
Your webstore sells from the same per-site stock as the shop floor, so a sold-out size disappears everywhere at once.
One party record across counter and online — sizes bought, returns made, campaigns they respond to.
Invoices, exchanges and credit notes with a full lifecycle, and GST reports from the same records.
In practice
Rank every variant by sell-through and days on hand. Discount what is stuck, transfer what will move elsewhere, and reorder what sold out early.
Store A is out of M, Store B has eight. Raise a transfer, and the stock, the tax invoice and the ledger all follow.
The same stock feeds the rack and the webstore, so a discount weekend does not turn into a refund queue on Monday.
The apps behind it
Online
Vritti builds the storefront and deploys it on Vritti Cloud, on your own domain. Connecting it to VAP is optional — but when it is connected, there is one catalogue and one inventory instead of two.
Vritti builds and deploys your store on Next.js and Payload CMS. Variants, images and prices come from VAP, so the site is never a second catalogue to maintain.
Marketplace orders draw down the same stock as the counter, so no channel gets to promise a piece you no longer have.
FAQ
Yes. Size, colour and fit are variant options, and each combination is a real SKU with its own stock level, price, barcode and sales history. Reordering and markdown decisions work at the variant level, not the style level.
Yes. Inter-site transfers are recorded inventory movements. If the two stores sit under different GST registrations, the transfer raises a proper branch-transfer tax invoice rather than silently moving stock.
Yes. Vritti builds your storefront to read the same per-site stock as the counter, so a size that sells out on the rack becomes unavailable online immediately.
Returns flow through credit notes tied to the original invoice, so the stock comes back into the ledger and the books stay clean. Invoices carry a full status lifecycle rather than being a single event.
Yes. Because every variant is tracked individually per outlet, sell-through is measurable per style, size and store — which is what drives markdown and reorder decisions mid-season.
Get started
Tell us what you sell, how many outlets and registered firms you run and where you sell. We will walk you through a real system set up like yours — not a generic demo.