A fish farm's real inventory is alive, it eats every day, and it changes weight between the moment you count it and the moment you sell it. Dynamics 365 Business Central handles the purchase of feed, the sale of graded fish, the bank and the ledgers perfectly well — but it has no concept of a pond or a cage as a stocking location with a live population, no way to record that 180,000 fingerlings went into Cage 4 in March and 173,400 fish came out in October, and no field anywhere for average weight, feed conversion ratio, mortality or a sampling event. Farms bridge that gap with a spreadsheet per site, and the result is the familiar one: the biomass number the farm manager quotes and the inventory value in Business Central are two different stories, harvest yields get reconciled weeks after the fact, and when a buyer or an auditor asks which feed lots and which treatments touched a specific batch of harvested fish, the answer takes days to assemble from paper.

We build an AL extension that adds the aquaculture layer directly into Business Central rather than beside it. New tables model the production unit (pond, cage, tank, raceway) with its volume and site hierarchy, and the stocking batch that occupies it — species, strain, hatchery source, stocking date, count, initial average weight and cost. Feeding is captured as feed events posted through item journal lines, so feed actually leaves inventory and lands on the batch's cost, which is what makes a feed conversion ratio real instead of estimated. A sampling page records sample count and weight, and a codeunit recalculates the batch's estimated average weight, standing biomass, specific growth rate, cumulative FCR and survival rate from stocking to date. Mortality entries reduce the population and carry a cause code. Harvest posts a partial or full drawdown of the batch into graded item variants — one harvest event splits into size grades and yields the sales-ready lines, while the batch keeps the full history behind each lot.

Technically it is a standard, upgrade-safe AL app for current Business Central release waves, on SaaS or on-premises. We use table extensions and page extensions rather than modified base objects, event subscribers into the item journal and posting routines so nothing in your existing posting flow is replaced, and item tracking with lot numbers so traceability rides Business Central's own mechanism instead of a parallel one. Job queue entries recalculate biomass and growth projections on a schedule and can raise a feeding-plan variance or a mortality-threshold notification. API pages published on the REST API v2.0 / OData v4 surface make batches, feed events and sampling readings available to feed-barge telemetry, water-quality sensors, a Power BI biomass dashboard or a Power Apps mobile form for the crew on the pontoon; Dataverse virtual tables are an option where the farm already runs Power Platform. Dedicated permission sets separate a farm technician who records feeding and mortality from a production manager who approves harvests and closes batches.

Because this is built to order, nothing here is generic. Marine cage salmon, inland tilapia ponds, RAS shrimp and hatchery nursery stages all count, feed and grade differently, and the extension is shaped to how your farm actually runs — your species and grade tables, your feed table and pellet sizes, your sampling protocol, your harvest documentation and the certification records (BAP, ASC, GlobalG.A.P., health certificates) your buyers demand. We start with a scoping call, write the functional specification, and you approve it before development begins.

Typical delivery is two to four weeks from confirmed scope. We build against your exact Business Central version, deploy to a sandbox for user acceptance testing with your own data, then publish to production with a rollback plan in hand. You receive the full AL source code for your version and a git repository, so nothing about this leaves you dependent on us to keep operating.