Ecommerce · India · Production
8 min read
The gold rate moves every morning. Twenty thousand prices used to move by hand.
Zinara sells fine jewelry direct on Shopify, where every one of roughly 20,000 variants carries a price that is a live calculation rather than a stored number. All of it ran on an Excel file and manual uploads. We replaced the process with a custom ERP that prices the whole catalogue from a single daily rate entry, tracks every physical piece individually, and runs procurement, fulfilment and the shop counter from the same system.
- Client
- Zinara
- Function
- Pricing, catalogue, inventory & fulfilment
- Geography
- India · Shopify D2C
- Delivered
- 4 phases, live
A catalogue where every price is a live calculation
Zinara sells fine jewelry direct to consumers on Shopify. The catalogue is large and structurally awkward: roughly 20,000 variants generated from combinations of metal, colour, size and stone, with a single ring design running past two hundred variants across its size range.
None of those prices is fixed. Each one is metal weight against the day's gold rate, plus diamond cost, plus making charges - so the entire catalogue moves whenever the rate does, which is every morning.
The business worked. It ran on spreadsheets and individual effort at a scale where both had stopped being viable, and the brief was not to put a tool alongside that process. It was to replace it.
Five things were breaking at once
Pricing lived in a spreadsheet. One Excel workbook of formulas held all twenty thousand variant prices. Every rate change meant regenerating the Shopify upload sheet by hand, at a scale where doing it without an error reaching a customer was not realistic.
Shopify was managed by manual upload. Products, prices and the metafields customers actually read - price breakdown, stone details, specifications - were compiled and bulk-uploaded by hand. Shopify's hundred-variant ceiling per product also blocked the largest designs from being listed at all.
There was no inventory system. No central record of what was in stock, where each piece was, or what could actually be sold. The direct consequence was overselling: items sold that the business held but could not locate, or could not confirm it still held.
Orders had no pipeline. Shopify orders were worked by hand. There was no piece-level picking, no invoice against a piece's real weight, and shipping sat in a separate system disconnected from order management entirely.
Vendors were tracked by phone call. Purchase orders to ten production vendors had no shared status, no follow-up reminders and no delivery timelines. Knowing where an order stood meant ringing the vendor.
The problem was not the jewelry.
It was a business with twenty thousand live prices, thousands of individually unique physical items and ten production vendors, held together by manual spreadsheet work and individual memory. Every rate change, every order and every delivery was a manual event waiting to go wrong.
That is not a tooling question. It is a question about what the system of record is - and there wasn't one.
How it ran before
Nine manual steps, and the first three had to happen before anything could be sold at the right price.
- 01
The gold rate changes
Daily, and it moves every price in the catalogue.
- 02
The base file is edited by hand
One Excel workbook of formulas, twenty thousand variants deep.
- 03
The Shopify upload sheet is regenerated
Rebuilt from scratch for every rate change.
- 04
Products and metafields are bulk-uploaded
Prices, images and the specification fields a customer reads.
- 05
Stock lives in no central system
No shared record of what is held, or where.
- 06
Items are oversold
Sold, then not found.
- 07
Orders are processed by hand
Picked and invoiced against the catalogue, not the piece.
- 08
Shipping is entered separately
Shiprocket, disconnected from order management.
- 09
Vendors are chased by phone
Ten of them, with no shared record of any order.
What the system took, and what stayed with people
The principle was not "automate the business". It was to automate what repeats, and give the people who exercise judgement better information to exercise it on.
The system runs
- Daily repricing across the whole catalogue
- Shopify sync - products, prices, images and metafields
- Order intake and piece reservation
- Purchase-order stage tracking and follow-up
- Invoicing against the piece that actually ships
- Shipment creation, labels and tracking
People still decide
- Whether a received piece passes QC
- Substituting one vendor for another
- How a custom order is quoted and made
- What to buy, and what to mark down
- Anything the system flags rather than resolves
What we built
One system of record, extended from ERPNext rather than written from scratch - its stock, purchasing and invoicing engines were already proven, so the custom work went where the problem is genuinely jewelry-specific.
- 01
Pricing recalculates from one entry
An admin enters the day's rate per karat. Every affected variant is rebuilt from its real formula - metal weight against the rate, plus diamond cost, plus making charges, with component- and product-level discounts - and the new prices push to Shopify alongside the compare-at price and the metafields. Designs past Shopify's hundred-variant ceiling are split into grouped products automatically, so a two-hundred-variant ring lists cleanly instead of not at all.
- 02
Every physical piece gets its own record
A piece received against a purchase order carries a serial: measured weight, HUID hallmark, barcode, QC result and location. Inventory tracks the item rather than a quantity, which is the only way to sell something that exists once.
- 03
Incoming stock passes QC before it can be sold
Weight tolerance, stone count, hallmark. A pass enters saleable stock at its real weight; a failure routes to the reject bin and raises a vendor return.
- 04
Purchase orders move on a tracked pipeline
Five stages, each timestamped, across ten vendors - and an order that stalls raises its own follow-up rather than waiting to be remembered.
- 05
An order reserves a piece, then leaves the building
A Shopify or counter order reserves one specific piece, so a unique item cannot be sold twice. Staff scan the barcode to confirm the pick, the GST invoice is generated from that piece's actual weight, and the shipment, label and tracking are created without leaving the system.
The whole catalogue, from one number
The morning routine is a single screen: enter the rate per karat, recalculate, and watch the prices go out. What used to be a spreadsheet rebuild is now a decision and a button.
Zinara ERP · daily pricing run · a representative day
- 20,000
- Variants in the catalogue
- 1
- Rate entries to reprice them
- 4
- Karats priced separately
- Automatic
- Push to Shopify
REPRICED TODAY, BY KARAT
- 14K38%
- 18K31%
- 22K19%
- 9K12%
WHERE A 14K PRICE COMES FROM
- Metal66%
- Making19%
- Diamond15%
Interface shown with representative data, not real customer records.
Every price shows its working
A price is not a number sitting in a field - it is a calculation, and the system keeps the parts. That is what makes running a rate change across twenty thousand variants at once a safe thing to do.
Variant pricing · ZNB1 bracelet · 14K yellow
| Component | Basis | Amount |
|---|---|---|
| Metal | 2.50 g × the day's gold rate | ₹23,911 |
| Making | 2.50 g × making charge | ₹6,739 |
| Diamond | 0.16 ct × diamond rate | ₹5,600 |
| Subtotal | ₹36,250 | |
| Diamond-component discount | 10% on that component | −₹560 |
| Final price | Synced to Shopify | ₹35,690 |
| Compare-at | Shopify strikethrough | ₹39,900 |
The same record generates the compare-at price and the nine metafields the product page shows - so what a customer reads about a piece and what the system charged for it come from one place.
One piece, from the vendor to the customer
Unique items cannot be managed as a stock count. Each piece carries its own record from the moment it arrives, which is what lets an invoice state the weight of the item that actually shipped.
Piece record · ZNR5-14KY-S8 · 14K yellow ring, size 8
- 01Received against a purchase orderVendor delivery, booked into the ERP
- 02QC: weight tolerance, stone count, hallmarkMandatory before it can be soldA failure routes to the reject bin and raises a vendor return.
- 03Serial, barcode and actual weight recorded3.25 g, against a 3.20 g catalogue weightThat difference is the reason the piece is tracked and not the SKU.
- 04Reserved against an orderShopify or the shop counterThe reservation is on this piece, so it cannot be sold twice.
- 05Picked by barcode scanConfirms the exact item leaving the shelf
- 06Invoiced at its own weight, then shippedin transitGST invoice · Shiprocket label and tracking
The invoice is generated from the measured weight of this piece rather than the catalogue's estimate for its design - correct for the customer, and correct in the books.
Ten vendors, one pipeline
Every purchase order sits in a stage, and the stage is a timestamp rather than a recollection. Nobody has to ring around to find out where an order is.
- PO-2026-048awaiting acknowledgmentKundan Craft · sent 2d ago
- PO-2026-047Rajmal Exports · no acknowledgment in 5 days - follow-up raised
- PO-2026-045acknowledgedMehta Jewels · due 22 Aug
- PO-2026-044Surana Gold · no production update in 8 days - follow-up raised
- PO-2026-041in productionSurana Gold · due 27 Aug
- PO-2026-039in productionMehta Jewels
- PO-2026-036in transitKundan Craft
- PO-2026-033QC in progressRajmal Exports · piece by piece
- PO-2026-031closedMehta Jewels · all pieces in stock
An order that stops moving raises its own follow-up on a rule, not on someone remembering. The two flagged here went five and eight days without an update, and neither needed a phone call to surface.
What changed
| Before | After | |
|---|---|---|
| Repricing | Hand-edit the base file, then rebuild the Shopify upload sheet | One rate entry recalculates every affected variant and pushes it |
| Catalogue | Products, prices and metafields bulk-uploaded by hand | Synced from the ERP; designs past the hundred-variant ceiling grouped automatically |
| Inventory | No central record; items sold that could not be located | Every piece tracked by weight, barcode, hallmark and location |
| Orders | Worked by hand, with shipping entered separately | Reserved, picked by scan, invoiced and shipped in one flow |
| Vendors | Ten of them, chased by phone | Every purchase order on a five-stage pipeline with automatic follow-up |
| Invoices | Generated from the catalogue weight | Generated from the actual weight of the piece that ships |
| In store | Not applicable - online only | The same system runs the counter: scan, Razorpay, GST invoice, posted back to Shopify |
What the design rules out
The system is live, so the change is structural rather than aspirational - specific failure modes the old process allowed are now designed out of it.
Overselling. An order reserves a specific physical piece rather than decrementing a count, so a unique item cannot be sold twice.
Repricing by hand. A rate change updates the catalogue and the storefront from one entry, which removes the hand-built upload sheet where the errors used to enter.
Invoices that disagree with the item. Every invoice is generated from the measured weight of the piece that ships rather than a catalogue approximation.
Orders that go quiet. A stalled vendor order surfaces itself, and an out-of-stock request becomes a tracked custom order with its own purchase order instead of an informal note.
Compliance as an afterthought. GST, HSN, e-invoicing and HUID hallmarking sit in the data model rather than bolted on afterwards, because India requires them and retrofitting them onto a live catalogue is expensive.
What the delivered system runs
These figures describe the scale and capability of the delivered system, which are factual, and not measured business outcomes. Zinara is establishing its baselines now - repricing time, overselling avoided, fulfilment throughput - and those will be published here once they are measured, rather than estimated in the meantime.
- Variants priced from one daily entry
- 20,000
- Production vendors on one pipeline
- 10
- Build phases delivered
- 4 of 4
- Systems of record for price and stock
- was Three, plus memoryOne
- What inventory tracks
- was A stock countEach piece
- Shopify catalogue and prices
- was Rebuilt by handAutomatic
Where else this applies
The industry here is jewelry. The pattern is not - it is high-SKU commerce where the price is a live formula and the unit is an individual physical item, and it fits bullion, watches, art and any catalogue whose prices move with a commodity.
A catalogue too large to reprice by hand, on inputs that move daily.
Prices that are a calculation rather than a stored number.
Stock that has to be tracked as individual items, not quantities.
A storefront kept in step with an internal system by manual upload.
Suppliers whose order status lives in phone calls.
Invoicing that has to match the specific item shipped, not its catalogue entry.
Have an operational problem worth solving?
Bring us the process that's expensive, slow, manual or difficult to scale. We'll spend 30 minutes understanding it and telling you - honestly - whether AI or automation can meaningfully improve it.