Chain Labs

A maintenance-store system for a textile dyeing mill

DyCot's maintenance store ran on paper slips keyed into an old system. We built the system it runs on now, with stock, repairs, alerts and the director's approvals in one place. It went live in September 2026.

Client
DyCot, a textile dyeing mill in India
Services
Business Process Automation, Data
When
March to September 2026
Team
Mihir, Pratham Chudasama
Status
Live

The problem

DyCot is a textile dyeing mill in India with US$10M a year in revenue. Its maintenance store holds the spares and supplies that keep the machines running.

The store ran on paper. The store manager wrote the daily issue slips by hand. The slips record the parts handed out to the floor. Gate passes for parts leaving the mill and vendor invoices were on paper too. One operator keyed all of it into an old system. Workers on the floor could not use devices at all.

The old system could not follow a part sent out for repair. It could not charge spending to a department or flag a part running low. A change to a posted entry left no trail.

The mill already metered its raw material, labor and power. The maintenance store was the cost the mill left unmeasured. In a store like that, unused stock, rising prices and repeat repairs stay hidden.

What we built

We built on ERPNext, an open-source ERP, and Frappe, the framework under it. ERPNext keeps the stock ledger and values stock first in, first out, so we did not write inventory valuation ourselves. Our app on top of ERPNext holds the store's rules. Each action, such as a purchase or an issue with all its lines, saves in one database transaction or not at all.

An issue is stock handed out from the store to a person and a machine. The operator works in a front end built for the keyboard. A day's issues go into one grid: item, quantity, person and machine, with the department filled in from the machine. A test in the repo enters a five-item issue and fails if the entry takes longer than 90 seconds.

The daily issue grid: four lines, each with an item, the stock it draws from, a quantity, the person and the machine it went to, with the balance left after the issue and the last issue on that machine.

The slips stay on paper. The floor has chemicals, water and heavy gloves, and no place for a tablet. We made the operator's entry fast instead of putting devices where they would not last.

An alert engine watches for low stock, overdue gate passes, approvals left waiting and purchase prices that jump. The director edits the rules. Alerts arrive in the app, by email and as phone notifications.

The alerts list: open low-stock warnings for named items and overdue gate-pass warnings, each with the document it refers to, its status and a Resolve button.

A change to a posted entry, or its cancellation, waits for the director. The director's app is the same web app as the store's, laid out for a phone and installable on it. We built it that way instead of as a separate native app, so there is one codebase and one login. The app shows each change line by line, with the old quantity struck through, and Approve and Reject at the bottom. The director's app works online only, by design. An approval changes stock, so the director never makes one against an offline copy.

The director's approval on a phone: an amendment to an issue, with one line's quantity changed from 22 to 21 and the Approve and Reject buttons below.

A read-only MCP server lets an AI assistant read the same reports: spending, stock, ledgers and alerts. The server answers as the signed-in user and can change nothing.

What was hard

ERPNext keeps each purchase line as its own batch, so every lot of stock carries its own cost. The first version corrected an entry by canceling the original, then posting the new one. Once part of a delivery had been issued, the cancel took its batch below zero, and ERPNext refused the cancel. Our probes showed the fault was ours. Each corrected draft made new batch names, which left the original batch to go negative.

The rebuilt engine keeps the original batches on the corrected entry. For a purchase, it posts the correction first and cancels the original after. For an issue, it reverses the original first. No batch dips below zero. ERPNext's own checks now reject a correction that would strand stock already used. The engine also points every return, receipt and link at the replacement. It refuses to correct an entry made before a posted stock count. None of these changes needed a change to ERPNext.

The result

The store went live on the new system in September 2026. Before go-live, we loaded the mill's past records from its old system. Every value either matched the old system's own stock valuation or was booked as a labeled adjustment.

The store now has one place for purchases, issues, repairs and gate passes. Every correction to a posted entry waits for the director. The month-end stock summary shows each item's opening stock and what came in and went out, in quantity and value.

The month-end stock summary for one month: each item's opening quantity, then purchases, repair inward, issue returns, issues and purchase returns, each in quantity and value.

Built with

BackendERPNext and Frappe, in Python
DatabaseMariaDB, Redis
Front endNext.js, React, Tailwind CSS
Tables and dataTanStack Table, TanStack Query
Director's appProgressive web app with Web Push
AI accessRead-only MCP server
TestsPlaywright, Vitest, pytest
HostingDocker, Railway
BuildingClaude Code