A fish farm runs on biology, not on bills of materials. Your real cost drivers are feed conversion ratio, standing biomass, mortality and the number of days a cohort sits in the water — and none of those exist in ERPNext out of the box. Farms end up running ponds in spreadsheets: one workbook for stocking and mortality, one for feed bags issued from the store, one for sampling weights, and a painful reconciliation at harvest when nobody can explain why 100,000 fingerlings became 78,000 fish at an average weight well below plan. ERPNext already has excellent Item, Batch, Stock Entry, Warehouse and Purchase/Sales flows, but it has no concept of a pond as a production unit, no biomass that grows between transactions, and no way to tie a feed issue to the cohort that ate it.

ECOSIRE builds a proper Frappe application — its own app in the bench, its own module, versioned in git — that adds the aquaculture layer on top of ERPNext instead of bolting fields onto Stock Entry. New DocTypes model the farm the way your team already talks about it: Culture Unit (pond, tank, cage or raceway with area, volume, depth and a linked Warehouse), Stocking Record (species, strain, hatchery source, fingerling count, average stocking weight, date in water), Feeding Log, Sampling Record, Mortality Record, Water Quality Reading, Transfer / Grading Entry and Harvest Entry. A Fish Batch document is the cohort that carries traceability from hatchery to dispatch, linked one-to-one with a native ERPNext Batch so the standard stock ledger, valuation and Sales Invoice paths keep working untouched.

The calculations live in server-side Python, not in client formulas. Doc events registered in hooks.py on Feeding Log and Harvest Entry post the matching Stock Entry (Material Issue for feed out of the feed store, receipt of graded fish on harvest) inside the same transaction, so feed inventory and fish valuation move together and never drift. Standing biomass is recalculated from stocked count minus cumulative mortality, multiplied by the latest sampled average weight; cumulative and period FCR are total feed issued to the batch over biomass gain, exposed on the Fish Batch form and through whitelisted methods so dashboards, field tablets and IoT loggers can read and post over the Frappe REST API. Scheduler events run the nightly roll-up — daily biomass snapshot, growth curve versus the stocked plan, feed-days remaining, and alerts when a unit crosses your dissolved-oxygen or mortality thresholds. Client scripts keep pond-side entry fast: one screen to log today's feed across every active unit, ration defaulted from the feed table for the current average weight and water temperature. Role profiles and permission rules separate Pond Technician (log feed, mortality, samples), Farm Manager (approve transfers, harvests, write-offs) and Accounts (valuation and costing), with workflow states enforced server-side.

Because this is build-to-order, nothing is downloaded and hoped for. We start with a scoping call, confirm your species, unit types, feeding regime, sampling protocol, grading rules and the traceability documents your buyers or auditors demand, then write the app against your ERPNext version — v15 or v16 — and your actual chart of accounts and warehouse structure. You receive the source, we install on a staging bench first, you run UAT against real pond data, and we go live with a documented rollback plan. Typical delivery is one working week from confirmed scope. There is no instant download, and no pretence that a generic marketplace app already fits your farm.