A dairy does not buy milk the way Business Central buys inventory. A farmer arrives at a collection center twice a day with an unmeasured quantity of a product whose value is not known until a lactometer and a milk analyser report Fat and SNF; the rate is a function of those two readings against a published slab or a Kg-Fat formula; the farmer is not invoiced but settled on a cycle — weekly, ten-day, or fortnightly — net of cattle feed advances, veterinary charges and loan recoveries. Standard Business Central has no concept of a quality-derived purchase price. Purchase Order and Purchase Invoice want a Direct Unit Cost at line entry, item charges cannot express a two-variable rate matrix, and the farmer is modelled as a plain Vendor with no place to store a shift-wise intake history. Teams end up running collection in spreadsheets or a standalone dairy package and keying summarised journals into Business Central weeks later, which means the payable to farmers, the milk solids on hand, and the plant's yield never reconcile to the same source.

ECOSIRE builds an AL extension that puts the whole collection-to-dispatch chain inside Business Central. New tables carry Collection Center, Farmer (a table extension on Vendor with a shift-wise ledger), Milk Collection Entry and Rate Chart Line, with page extensions on the Vendor Card and Item Card so nothing lives in a parallel silo. Intake is captured on a purpose-built collection journal page — center, shift, farmer, weight or volume, Fat %, SNF % (or CLR, converted by a configurable formula) — and a pricing codeunit resolves the rate at posting time against the effective rate chart, whether that chart is a two-dimensional Fat/SNF slab grid, a Kg-Fat rate, or a base-plus-incentive formula. Posting writes a real Vendor Ledger Entry and an Item Ledger Entry for raw milk, so the farmer payable and the milk-solids valuation are Business Central data from the first second, not a month-end import.

Payment cycles run as a settlement document: the extension aggregates every collection entry in the period per farmer, applies deduction lines sourced from feed sales and advance ledgers, and produces a payment slip plus a Payment Journal batch ready for the standard Suggest Vendor Payments and electronic payment flow. Processing is modelled on Business Central's own Production Order, consumption and output journals with Item Tracking — input milk with its Fat/SNF is consumed, standardised into pasteurised milk, cream, ghee, curd or powder, and the extension records actual versus standard yield per batch, flagging solids loss beyond a tolerance you set per routing. Dispatch builds route-wise loading sheets from Sales Orders, tracks crates and returnables per route with the driver, and posts route returns back as a credit against the day's sale.

Technically this is a normal, upgrade-safe extension: table and page extensions rather than base-object modification, business logic in codeunits, and event subscribers on the posting routines rather than copied base code. Job Queue Entries handle unattended work — overnight rate-chart activation, settlement generation, and the milk-analyser import if your centers run automatic collection units writing to a shared file or endpoint. API pages published on the standard REST API v2.0 / OData v4 surface expose collection entries, rate charts and farmer balances so a village-level Power App, a Power BI dairy dashboard, or a Dataverse-linked field app reads live data without a middleware layer. Dedicated permission sets separate the collection-center operator from the plant accountant. The extension targets current Business Central release waves and is delivered for either Business Central online (per-tenant extension, or prepared for AppSource submission if you intend to resell) or on-premises.

Delivery is build-to-order, not a download. We start with a scoping call, then produce a written functional specification covering your rate chart mathematics, shift definitions, deduction types, settlement calendar and dispatch model — that document is what we build against and what UAT is graded on. Typical delivery is one working week from confirmed scope, deployed first to your sandbox for user acceptance testing on real collection data, then to production with a documented rollback. You receive the AL source code, the git repository, and a support window after go-live.