Poultry economics live and die on numbers Odoo does not natively model. A flock is not a stock lot and not a manufacturing order: it is a living cohort placed on a given date, in a given house, that eats a feed ration daily, loses birds to mortality and culls, converts that feed into eggs or body weight, and must be costed as one unit from placement to depletion. Farms running plain Odoo end up with feed purchases in purchase.order, bird sales in sale.order, and the thing that actually matters — cost per dozen eggs, cost per live kilo, FCR, mortality percentage against a breed standard — living in a spreadsheet that nobody reconciles until the flock is already gone.

The gaps are structural, not cosmetic. Odoo core has no concept of a depleting cohort: stock.quant cannot lose 0.4% of itself per week to mortality, and mrp assumes a bill of materials consumed in one shot rather than a ration fed daily over a 40-week lay cycle or a 42-day broiler grow-out. There is no age-in-days field to drive standard curves, no place to record a vaccination with a withdrawal period that must block sales, and no way to ask "what did house 3 cost me last cycle" without exporting to Excel. Analytic accounting can carry the cost, but nothing on the operations side posts to it in the shape a farm manager recognises.

What we build is a batch-centric layer that sits on top of the Odoo you already run. A poultry.flock model carries breed, house, placement date, opening bird count, and a computed age_days that drives everything downstream; daily entries against it record feed issued by product, mortality and cull counts with a reason code, eggs collected by grade, water, temperature, and medication with its withdrawal window. Computed fields with proper @api.depends chains derive closing bird count, cumulative mortality percentage, feed conversion ratio, hen-day production percentage and cost per unit produced, so the numbers are always live rather than batch-recalculated. Feed issues move real stock through stock.move against the flock's analytic account, so the P&L and the operational report cannot drift apart. Egg and bird output can be received into inventory as graded products, ready for sale.order and delivery, and a nightly ir.cron or automated action can raise alerts when mortality crosses a threshold you set per breed.

Technically it ships as a proper Odoo addon, not a patch: a clean __manifest__.py declaring dependencies on stock, account and (where relevant) mrp, models under models/, list, form, kanban and graph views in XML with OWL components only where a plain view genuinely cannot do the job, QWeb reports for the daily production sheet and the end-of-cycle batch closing report, and access control through ir.model.access.csv plus record rules so a house supervisor sees only their own flocks while the owner sees the whole farm and every company in a multi-company setup stays isolated. Everything is reachable over XML-RPC and JSON-RPC, so scale readings, egg counters or a mobile data-capture app can post daily entries without a human typing them. It runs on Community — nothing in the core design needs Enterprise — though if you are on Enterprise we will wire the batch dashboards into the Enterprise reporting views and the mobile-friendly layouts you have already paid for.

Because this is built to order rather than downloaded, the shape is yours. We start with a scoping call to map your species and cycle (layer, broiler, breeder, or a mix), your house and shed structure, which standards you benchmark against, and which of your existing Odoo customisations the module must respect. You get a written scope with a fixed price before a line of code is written. Typical delivery is one working week from confirmed scope, delivered as installable source for your exact Odoo version, deployed first to a staging database for your own user acceptance testing, then cut over to production with a rollback plan in hand.