Petrol and fuel stations lose margin in the gaps that generic accounting cannot see: the difference between what the nozzle meters counted, what the dip stick and density say is in the tank, and what actually hit the cash drawer at shift change. Stock-native ERPNext models fuel as an Item with a Stock Ledger Entry, but it has no concept of a nozzle totalizer that only ever counts up, no shift-wise cash-vs-volume reconciliation, no dip/density conversion at the tank, and no way to book evaporation or temperature variance as a controlled loss instead of an unexplained inventory adjustment. Owners end up running the forecourt on spreadsheets bolted to the side of ERPNext, and the two never agree.

ECOSIRE builds a dedicated Frappe application that sits inside your ERPNext instance and models the forecourt properly. We add DocTypes for Fuel Tank, Dispenser, Nozzle, Shift, and Nozzle Reading, each linked to standard ERPNext Item, Warehouse, Company, and POS Profile records so stock and accounting stay canonical. A Shift Closing DocType captures opening and closing totalizer readings per nozzle; a hooks.py on_submit doc event runs a server-side controller that computes litres sold (close - open, guarding for meter rollover and pump replacement), values them at the shift's rate, and posts the matching Sales Invoice/POS Invoice and Stock Ledger Entry. Dip readings and density are entered against the tank, converted to volume through calibration tables you provide, and reconciled against metered sales so that book stock, physical dip, and sold volume are compared in one place with the variance split into measured evaporation, temperature/density adjustment, and true shortage.

Technically it is a real Frappe app, not a pile of customizations: versioned in its own git repository, installed with bench install-app, and upgraded through bench migrate. Business rules live in Python controller methods and hooks.py doc events (validate, on_submit, on_cancel) so they can never be bypassed by a direct edit; forecourt data-entry ergonomics (totalizer keypad, live litres-sold and cash-expected calculations, rollover warnings) are delivered as Client Scripts and a lightweight custom page. Scheduler events (scheduler_events in hooks.py) run the nightly stock-vs-dip reconciliation and flag tanks whose loss exceeds a configurable tolerance. Everything is exposed over the Frappe REST API and whitelisted methods (@frappe.whitelist()) so tank-gauge hardware, controller consoles, or a fleet-card portal can post readings in; access is governed by ERPNext Role Profiles and permission rules (Pump Operator, Shift Supervisor, Station Manager, Accounts) with row-level and field-level control. Credit customers and fleet cards are handled as standard ERPNext Customer accounts with per-card credit limits and statements, so receivables and driver-level fuel history reconcile against General Ledger without a second system.

Because this is build-to-order, nothing ships until we agree on scope. A short scoping call establishes your tank/nozzle layout, product slate (petrol grades, HSD, lubricants), calibration and density conventions, credit/fleet-card rules, and target ERPNext version (v15 or v16). We then build against your requirements, prove it on a staging instance through UAT, and only then install on production with a rollback plan. Typical delivery is one working week from confirmed scope, and you receive the full source repository so you are never locked in.