A fish farm does not run on products and quantities — it runs on biomass that grows, eats and dies every single day. Your 180,000 tilapia in Pond B-4 are not a stock quantity; they are a stocking event, minus daily mortality, times an average weight you only learn by netting a sample twice a month. Feed is your biggest cost line and your only real growth lever, yet feed conversion ratio is normally reconstructed in a spreadsheet weeks after harvest, when it is far too late to change the feeding table. Odoo out of the box has no concept of any of this. stock.quant holds a static number, a manufacturing order assumes a fixed bill of materials that consumes and produces in one step, and stock.lot gives you a lot number but nothing that models a 200-day grow-out cycle with daily feed events and fortnightly weight samples. Teams that try to force it end up with the ponds in Excel and an ERP that only sees the fish on the day they are sold.

What ECOSIRE builds is a proper aquaculture production layer inside Odoo. The core is a stocking batch model — a models.Model for each pond, cage, raceway or tank as a physical site, and a production cycle record that owns the stocking event (fingerlings received, count, average stocking weight, source hatchery, species and strain). From there, daily operational records post against the cycle: feed events linked to real Odoo products so consumption creates stock.move records and your feed inventory actually decrements; mortality records that reduce the standing population; water quality readings (dissolved oxygen, temperature, pH, ammonia, salinity) captured against the site with configurable threshold bands; and treatment events that carry a withdrawal period. Sampling records store sample count and total sample weight, and compute methods with @api.depends derive mean body weight, standing biomass, specific growth rate, survival percentage and both biological and economic FCR live on the cycle form — so the farm manager sees FCR drifting on day 90, not in a post-mortem. Feeding tables are configurable per species and size class so the system proposes a daily ration as a percentage of standing biomass, and automated actions (ir.cron plus server actions) flag cycles where issued feed has diverged from the plan or where a water-quality reading has breached its band.

Harvest is modelled as a real event rather than an inventory adjustment. A harvest record captures partial or full harvests, splits the catch into grade lines by size band with count and weight per grade, reconciles harvested biomass against the last computed standing biomass so you get an explicit variance instead of a silent one, and produces graded stock into Odoo inventory under lots that back-reference the cycle. That is where traceability closes: a QWeb report gives you a per-lot certificate showing site, species, stocking date and origin, the full feed and treatment history with withdrawal compliance, the water-quality record and the harvest data — the document a processor, a buyer or a BAP/ASC/GlobalG.A.P. reviewer actually asks for. Because everything is a native Odoo model, it is all reachable over XML-RPC and JSON-RPC, so pond-side probes, feed barge software or a mobile capture app can post feed and mortality events straight into the cycle without anyone rekeying a paper logbook.

Security and deployment follow Odoo conventions rather than shortcuts. Access is defined in ir.model.access.csv with dedicated Farm Operator, Farm Manager and Read-only groups, and record rules scope data per farm site and per company so a multi-site or multi-country operator can share one database safely. Views are standard XML — list, form, a kanban of ponds coloured by alert state, a calendar for sampling and harvest planning, and pivot/graph views for FCR, survival and cost-per-kilo — with OWL components used only where a genuinely custom interaction earns them. The module is written to install cleanly on Odoo 17.0, 18.0 or 19.0 (you tell us which, and whether Community or Enterprise) with a __manifest__.py declaring only the dependencies your build actually needs. Everything core runs on Community; on Enterprise we can additionally wire cycle costing into analytic accounting and surface the operational dashboards through the Enterprise reporting widgets.

This is a build-to-order product, not a download. You request a quotation, we run a scoping call, and we write down exactly what your farm does — species, systems (pond, cage, RAS, raceway), feeding regime, sampling protocol, grading bands, whether hatchery and nursery stages are in scope, which certification scheme you report against, and what has to integrate. That scope becomes a fixed quotation and a written specification. Typical delivery is one working week from confirmed scope, depending on complexity and integration surface. We build against your Odoo version on a staging database, you run UAT on your own data, and only then do we deploy to production with a rollback plan. You receive the full source, the git repository, technical and user documentation, a training session and a post-go-live support window — and because you own the code, nothing about your farm's operating model is locked behind a vendor.