Waste collection is a business where the invoice is assembled from field events, not from sales orders. A round leaves the depot with forty stops on it, some lifted, some blocked by a parked car, some contaminated and rejected. A 12-yard skip goes out on Tuesday, sits on a driveway for nine days and comes back the following Thursday — and the hire clock, the exchange, and the disposal weight are three separate billable things. A tipper crosses the weighbridge at 14:20 with a gross of 18.4 tonnes and a tare from this morning, and the net becomes a disposal cost at a transfer station or a revenue line for a load of baled OCC. Dynamics 365 Business Central handles the accounting end of all this perfectly well — customers, dimensions, posting groups, recurring sales lines, VAT, service items — but it has no concept of a round, a container on hire, a weighbridge ticket, a material grade with a contamination deduction, or a gate fee that flips sign depending on whether the material is a cost or a commodity. Operators bridge that gap with a weighbridge package that exports a CSV, a route sheet in Excel, and a monthly billing run that someone reconciles by hand for three days.

What ECOSIRE builds is an AL extension for your Business Central tenant that closes that gap inside the system of record. The core is a small set of new tables — Container, Container Movement, Collection Round, Round Stop, Weighbridge Ticket, Material Grade, Service Agreement Line — each with its own list and card pages, its own permission sets, and full Dimension Set integration so every movement, ticket and lift carries Route, Vehicle, Site and Material dimensions into the G/L. Containers are registered with a serial or barcode/RFID identifier, a type and capacity, an owning depot, and a status that only ever changes through a posted Container Movement — delivered, exchanged, collected, returned to yard, written off — so the on-hire register is a derived, auditable position rather than a spreadsheet someone maintains. Round planning works from service agreements: a codeunit expands each agreement's frequency pattern (weekly, fortnightly, every fourth Tuesday, on-call) into dated Round Stop records, sequences them, and publishes the round to drivers.

Technically it is a proper extension, not a modification of the base app. Weighbridge integration is the part that decides whether the whole thing works, so we build it against how your bridge actually behaves: an API page exposed over the standard REST API v2.0 / OData v4 endpoint for indicators that can POST, a job queue entry polling a watched folder or SFTP drop for indicators that can only write a text file, or a small serial-to-HTTP gateway where the bridge is genuinely offline. Every inbound ticket lands in a staging table, is matched to a vehicle, container, customer and material grade, and is either auto-accepted or held for a weighbridge operator to resolve — first-weight and second-weight tickets are paired, tares are validated against the vehicle's registered tare with a tolerance, and duplicate ticket numbers are rejected outright. Billing is a codeunit that walks completed stops and accepted tickets for a period and produces sales invoice lines under the pricing model on the agreement: per lift, per tonne with banded or stepped rates, minimum charge, container rental per day or per week with part-period proration, excess-weight surcharge, contamination charge, and a rebate line where a recycled grade is worth money to the customer rather than costing them. Event subscribers on the base sales posting codeunits stamp every generated line back to its source event, so an invoice query can always answer "which ticket and which stop is this line?". Everything compiles against the current Business Central release wave and runs on both SaaS (per-tenant extension or AppSource-track app) and on-premises; where you already run Power BI or Power Apps, the API pages are the surface a driver app or a route-profitability dashboard consumes through Dataverse or a direct connector.

This is a build-to-order product, not an AppSource download — you do not buy it and install it this afternoon. It starts with a scoping call where we go through your rounds, your container fleet, your weighbridge make and how it talks, your material grades and who they are sold to, and the exact pricing clauses in your two or three most awkward contracts, because the contract that makes billing hard is always the one left out of the requirement document. We write that up as a signed scope, build the extension against your Business Central version, and hand you a UAT build on a sandbox loaded with a slice of your real agreements and a week of real weighbridge tickets so you can run a parallel billing period and compare invoices line by line against what you produced manually. Typical delivery is two to four weeks from confirmed scope, longer only where the weighbridge integration needs on-site work or the contract model has more exotic clauses than scoping surfaced. You receive the full AL source, the git repository, the deployment and configuration documentation, and a post-go-live support window — you are never locked out of the code that produces your invoices.