Loading
Industry — Diamond & Jewellery
Bhavnagar sits inside Gujarat's diamond and jewellery corridor. The operational problems here are not the ones generic ERP vendors design for: goods move by weight and by trust, half your inventory is with somebody else at any moment, and the difference between profit and loss is measured in fractions of a carat.
What we hear
Four problems that come up in almost every conversation in this sector. If none of these sound familiar, the rest of this page probably is not for you.
Problem 01
At any given hour a meaningful share of goods is with a karigar, at a certification lab, on memo with a retailer, or in transit for an assortment. Most stock systems assume inventory sits on a shelf. Yours does not, so the register in the office and the goods in reality drift apart within days.
Problem 02
A parcel is a count and a weight. After sawing, bruting, polishing and boiling it is a different count and a lower weight, split across grades. If issue weight and receipt weight are recorded on separate sheets by separate people, nobody can tell whether a shortfall is normal loss, a grading disagreement or something worse.
Problem 03
Karigar rates vary by operation, by shape, by size range and often by individual. Advances, rejections, rework and deductions accumulate across weeks. When settlement day arrives, the numbers are assembled from handwritten slips, and a dispute costs more in relationship than in rupees.
Problem 04
Purchase describes it by parcel, manufacturing by lot, the certificate by report number, and the retail counter by SKU. Without one identity that carries through, provenance queries, memo returns and repeat orders all become manual detective work.
The other side of it
A stable internal identifier attached at intake and carried through every split, merge, issue and return, so a finished item can be traced back to the parcel it came from and forward to the invoice it left on.
Issue and receipt weights captured at the point of transaction, with tolerance bands per operation. Variance is flagged the same day rather than discovered at stock take.
Job-work statements generated from recorded transactions, showing operation, rate, quantity, rejections, advances and net payable. The conversation moves from whose slip is right to whether the rate card is right.
Certificate-backed listings with photographs, current availability and buyer-specific pricing, so a B2B enquiry does not start with a WhatsApp image and end with a phone call about whether the stone is still free.
What we build
Every system below is built around one idea: a unit of goods has an identity, a location, an owner and a weight, and every one of those four can change independently. Get that model right and the reports write themselves. Get it wrong and no amount of reporting will fix it.
Intake creates a parcel with a count, a weight and a cost. Splitting into lots and packets preserves the link upward, so a packet always knows which parcel funded it. Merges are recorded rather than overwritten, because an assortment that combines goods from three parcels still has to be costed correctly when it sells.
Grading results, whether from an external laboratory or an in-house assortment table, attach to the stone or packet rather than to a spreadsheet row. Report numbers, issue dates, laboratory identity and the scanned certificate are stored together, and the stone's internal identifier stays constant even when the report is reissued.
Each operation (sawing, bruting, polishing, boiling) is an issue and a receipt with weights on both sides. Yield is calculated per operation and per lot, expressed both as a percentage and as absolute loss, with tolerance bands per operation and size range. Variance outside the band raises a flag on the same day, not at stock take.
Rate lists are versioned with effective dates. Quotations are generated against the list version current at the time, with per-buyer discount structures applied as rules rather than as remembered courtesies. A quotation that becomes an order carries its pricing basis with it, so margin can be explained afterwards.
Memo is modelled as an ownership and location state, never as an early sale. Positions age, overdue returns prompt, and conversion from memo to invoice happens without re-keying. Multi-location stock is handled the same way: a location is a place goods can be, including a karigar's bench and a laboratory's intake desk.
A buyer-facing catalogue driven by live availability, with certificate details, photographs and buyer-specific pricing. Enquiries land as structured records against the specific packet rather than as an image in a chat thread, and a hold placed by a buyer reflects immediately in what other buyers can see.
Counter billing that understands making charges, wastage percentages, metal rate of the day, stone value and the split between them, because that split determines the tax treatment. Documents are generated from the transaction type, so a job-work challan, a memo note and a tax invoice come from one model rather than three templates.
Transaction level
This is the loop that most generic ERP implementations get wrong, so it is worth setting out precisely. Goods leave your possession, work is performed by somebody paid per operation, and goods come back lighter and in a different form. Six recorded events make the whole cycle reconcilable. Miss any one and the settlement becomes a negotiation.
A lot leaves against a job card naming the karigar, the operation and the expected return date. The scale reading is captured at the point of issue, not written down for entry later.
Recorded here
The lot's location is the karigar's bench. It remains in your stock valuation and out of your building, which is exactly the state that paper systems cannot represent.
Recorded here
Returned goods are weighed and counted against the same job card. Yield and absolute loss are computed immediately and compared with the tolerance band for that operation and size range.
Recorded here
Accepted, rejected and rework quantities are recorded separately. Rework re-enters the loop as a new issue against the same job, so the cost of doing a piece twice is visible rather than absorbed.
Recorded here
The amount due is computed from accepted quantity, the rate card version recorded at issue, and any agreed deduction for variance beyond tolerance. Nothing here is typed in by hand.
Recorded here
A statement is generated covering the period, listing every job, its operation, rate, quantity and adjustment, with advances netted off. Both parties read the same document.
Recorded here
Because the rate card is versioned and the issue transaction records which version applied, a settlement from eight months ago can be regenerated today and will produce the same figure. That property, more than any dashboard, is what turns a job-work dispute into a five-minute check.
Constraints
Compliance in this trade is not a module you add at the end. It changes the shape of the transaction model, so it belongs in the first design conversation. The following are the constraints we design around and confirm with the client's own advisors before building.
Where to go next
The services below are the ones this sector draws on most. Case studies are published only with written client permission, and none are published for this sector yet. Ask us in a call and we will tell you plainly what we have and have not done.
Service
Service
Service
Solution
Solution
Solution
Solution
Questions
Yes, provided capture happens where the weighing already happens rather than in an office afterwards. The practical approach is a tablet or phone screen at the issue and receipt point, tied to the scale reading and the operation being performed, taking a few seconds per transaction. Tolerance bands are configured per operation and per size range, so the system only interrupts when the variance is outside what that operation normally produces. Anything that requires a second data-entry pass at the end of the day will be abandoned within a month.
With a rate card that is a first-class part of the data model rather than a spreadsheet on someone's desktop. Rates can be defined by operation, shape, sieve or size band, and overridden per karigar, with an effective-from date so historical settlements stay reproducible. Issues, receipts, rejections, rework and advances all post against the job, and the settlement statement is generated from those postings. Because the rate card is versioned, a settlement can be re-run months later and produce the same figure.
Memo is a separate ownership state, not a sale, and it needs to be modelled that way. Goods on memo stay in your stock valuation but sit at a different location with a party, an issue date and an expected return date. The system should age memo positions, prompt on overdue returns, and convert a memo line into an invoice line without re-keying when the buyer confirms. Treating memo as an early sale is one of the more expensive modelling mistakes in this trade.
Hallmarking obligations mean an article-level record: purity, the HUID against the piece, the assaying and hallmarking centre, and the dates. That record needs to survive stock transfers between showrooms and be retrievable on demand rather than reconstructed. On the export side, invoice, packing list and the supporting documentation should be generated from the same order data that produced the dispatch, so the commercial documents and the physical consignment cannot disagree. We build to the rules the client's compliance advisor confirms in writing; we do not interpret regulation for you.
They affect it structurally. HSN treatment differs between rough, polished, gold and finished jewellery, job-work movements are not sales and must be documented as such, and thresholds for e-way bills depend on movement type and value. The design implication is that the document layer has to be driven by the transaction type rather than bolted on at invoice time. Integration with a GSP or the e-invoice APIs is straightforward once the transaction model is right, and painful when it is not.
We publish case studies only with written client permission, and we do not describe sector experience we cannot evidence. Ask us directly about what we have delivered and we will answer plainly, including where the answer is that a piece of this is new to us. What is described on this page is capability and problem understanding, and we are glad to be tested on both in a technical conversation before any commitment.
The most useful first conversation is not about scope or budget. It is walking through one process end to end with somebody who does it every day, and finding out where the data stops being trustworthy.
What happens next
