Skip to content
PRSINDIA

Vishwa Precision Components

Off Tally, onto a real ledger: a 3-plant manufacturing ERP

A multi-plant manufacturing ERP built on an append-only inventory ledger — 2.4M Tally vouchers migrated with zero balance drift, and heat-lot traceability cut from two days to four minutes.

Client
Vishwa Precision Components
Industry
Manufacturing & Automotive
Location
Bhiwadi, Pune & Coimbatore, India
Duration
11 months (incl. 2 parallel quarters)

0 days

Days to close the month, down from 14

0%

Stock accuracy against cycle counts, up from 91.4%

0M

Tally vouchers migrated with zero balance drift

0 min

Heat-lot traceability query, down from 2 days

01

The challenge

Vishwa Precision Components machines and heat-treats safety-critical parts for automotive tier-1 buyers, out of three plants — Bhiwadi, Pune and Coimbatore. ₹180 crore turnover, nine years of history, and a system of record consisting of Tally ERP 9 plus roughly forty Excel workbooks with names like Stock_Master_FINAL_v3_USE_THIS.xlsx.

The problem was not that Tally was bad. It was that Tally was being asked to be an ERP.

Tally is excellent accounting software. It is not a manufacturing execution system, and it was never going to answer the four questions that were actually hurting this business:

  • Where is my work-in-progress? Material issued to the shop floor left the books and reappeared, days later, as finished goods. In between, ₹6–8 crore of inventory was invisible. Plant heads estimated WIP. The word they used was "estimate".
  • Which parts came from which heat lot? Their IATF 16949 obligations to OEM customers require lot-level traceability — if a batch of steel turns out to be bad, they must identify every part made from it. Answering that question took two people about two days of digging through paper job cards. In a live recall, two days is not an answer.
  • What did we own on 31 March? Stock quantities lived in mutable Excel cells. There was no way to reconstruct a historical position, which meant every year-end valuation was an argument with the auditors.
  • What is at the subcontractor? Job-work challans and the ITC-04 return were assembled by hand each quarter from a folder of paper. Material sitting at a job-worker was, functionally, material that had left the universe.

Month-end close took fourteen days. By the time the numbers were ready, they described a month that had stopped being actionable a fortnight ago.

02

What we built

Inventory as a ledger, not a column

The single most consequential decision on this project: we did not store current quantity anywhere. Stock is an append-only ledger of stock_moves — every receipt, issue, transfer, scrap, rework and return is an immutable row with a quantity, a lot, a location, a timestamp and a reason. Current stock is a projection. Historical stock is the same projection with a different cut-off date.

Systems that keep a mutable qty_on_hand column always feel simpler on day one, and they always end the same way: a bad update, a lost history, and a valuation nobody can defend to an auditor. Weighted-average costing is computed from the move ledger, which means the March 31 valuation is not a snapshot anyone has to trust — it is a replay anyone can verify.

We refused the big-bang cutover

They wanted to switch off Tally on 1 April. We said no, and it was the right call. Instead we ran parallel for two quarters: the new system took operational ownership immediately (production, inventory, purchase, job-work), while Tally remained the statutory book of record. A nightly reconciliation job diffed ledger balances across the two systems and raised an alert on any drift over ₹1.

For six weeks that job screamed at us daily, and every scream was a real defect in our understanding of their business — a rounding rule, a rejection-handling convention, a way of treating free-issue material that nobody had written down anywhere. Finding those in parallel-run is cheap. Finding them after cutover, with no book to check against, is a crisis.

Migration you can rehearse

2.4M vouchers across nine years came out of Tally by XML export into a fully idempotent, replayable ETL with a per-voucher-type checksum manifest. Because it was replayable, we could run it as many times as we liked. We ran it eleven times. The eleventh rehearsal produced zero balance drift, and that was the one we shipped.

Multi-plant without multi-database

We scoped by plant_id inside one database with row-level policies, rather than standing up a database per plant. A plant-per-database looks tidy until you need a stock transfer from Bhiwadi to Pune, at which point it becomes a distributed transaction across two systems that must never lose a lakh of steel. In a single ledger, an inter-plant transfer is two rows. That is the entire feature.

The shop floor gets a scanner, not a keyboard

Every heat lot gets a QR label at goods-receipt. Operators scan at each stage on rugged Android devices. The scanner app tolerates a dead network — a machine bay behind three feet of concrete has no Wi-Fi, and blaming the operator for that is not a strategy. Traceability queries walk the move ledger, so "which parts came from heat lot HL-2291" is a graph traversal, not an archaeology project.

03

The outcome

Cutover was on 1 October, at the end of the second parallel quarter. It was uneventful, which is the highest praise an ERP cutover can receive.

The numbers

  • Month-end close: 14 days → 3 days. The finance team did not become faster typists. The data stopped needing to be assembled, because it was already a ledger.
  • Stock accuracy: 91.4% → 99.2%, measured by cycle-count variance against the system position. The remaining 0.8% is almost entirely a known shrinkage pattern at one plant, which they now know about because they can finally see it.
  • Heat-lot traceability: 2 days → under 4 minutes. This one was tested for real, seven months after go-live, when an OEM customer raised a material query. They answered the same afternoon. Their quality head told us it was the first time in nine years that a traceability request had not ruined a week.
  • 2.4M vouchers migrated with zero balance drift, verified against Tally across two full quarters of parallel running before anyone was allowed to switch anything off.

What it unlocked

WIP is now visible in near-real time, and the ₹6–8 crore that used to disappear between issue and finished-goods is a number on a dashboard. The ITC-04 job-work return, which used to be a quarterly two-person ordeal, is generated from the move ledger in one click, because material at a subcontractor is just a location in the ledger like any other.

The plant heads stopped estimating. That is the whole project, in three words.

Under the hood

How it's built.

Technology

  • Laravel
  • MySQL 8
  • Redis
  • Laravel Horizon
  • Filament
  • Android (Kotlin)
  • Tally XML ETL
  • GST APIs (ITC-04, e-Invoice)
  • Docker
  • AWS RDS

Services used

  • ERP Development
  • Custom Software Development
  • Data Migration
  • Mobile App Development
  • Cloud & DevOps

We told them we wanted to switch Tally off on the first of April. They told us that was how ERP projects die, and made us run parallel for six months instead. Every week of that felt slow. Not one week of it was wasted.

Ramesh Iyer Managing Director, Vishwa Precision Components

Same problem?

Let's build something that ships.