Petrol Pump & Fuel Station Management

Key Features

Dedicated `Fuel Tank`, `Dispenser`, and `Nozzle` DocTypes linked to native ERPNext `Item`, `Warehouse`, and `Company` so fuel stock stays in the standard Stock Ledger

Shift-wise nozzle totalizer capture with a `Shift Closing` DocType that computes litres sold as `close - open`, guarding against meter rollover and mid-shift pump replacement

Server-side `on_submit` controller in `hooks.py` that auto-generates the matching `Sales Invoice`/`POS Invoice` and `Stock Ledger Entry` from each closed shift

Shift cash reconciliation: metered volume x rate compared against declared cash, card, and credit tenders with a variance short/over posted to a control account

Dip and density entry per tank with calibration-table conversion to volume, reconciled against metered sales in one variance view

Evaporation and temperature/density variance booked as controlled, categorized losses via a dedicated Stock Reconciliation flow rather than silent adjustments

Nightly `scheduler_events` job that runs stock-vs-dip reconciliation and flags any tank exceeding a configurable loss tolerance

Credit customer and fleet-card accounts as standard ERPNext `Customer` records with per-card credit limits, driver-level fuel history, and GL-reconciled statements

Multi-grade product handling (petrol grades, HSD, lubricants) with per-shift rate changes tracked against a `Fuel Rate` DocType and full price history

Whitelisted REST methods (`@frappe.whitelist()`) for tank-gauge or forecourt-controller integration to post readings and dips programmatically

Role Profiles and permission rules for Pump Operator, Shift Supervisor, Station Manager, and Accounts with row- and field-level control

Client Scripts delivering a totalizer keypad, live litres-sold and cash-expected calculators, and rollover/negative-reading validation at data entry

Multi-tank, multi-nozzle, and multi-station support with per-`Warehouse` stock isolation for chains running several sites in one ERPNext instance

Frappe Query Reports and dashboard charts for shift variance, per-nozzle throughput, tank loss trend, and credit-customer ageing

Built to order, done for you

No DIY setup — a working app, built, installed and supported by ECOSIRE.

You order

Start with a one-time build price. We scope it with you at kickoff.

We build & install

ECOSIRE builds, configures and installs it on your ERPNext.

Go live + support

You go live in about 2–4 weeks, with a post-launch support window.

About this Product

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 2 to 4 weeks from confirmed scope, and you receive the full source repository so you are never locked in.

What you get

Installable source code for your commissioned version, delivered as a proper Frappe app installable via `bench install-app`

Installation and configuration on your ERPNext instance (v15 or v16), including DocTypes, Role Profiles, and initial tank/nozzle setup

UAT on a staging instance with sample shift, dip, and credit-card scenarios, plus a documented production rollback plan

Technical documentation: DocType schema, `hooks.py` doc events, scheduler jobs, and whitelisted REST endpoints

User guide plus a live training session for operators, shift supervisors, and accounts staff

A defined post-go-live support window for bug fixes and configuration adjustments

Handover of the private git repository with full commit history so you retain ownership and can extend it

Data-migration or opening-balance assistance for tanks, credit customers, and fleet cards where required

Who this is for

Independent petrol pump owner

Runs one or two forecourts and needs shift closings, tank dips, and cash to reconcile automatically so nightly shortages are visible instead of buried in a spreadsheet. Wants ERPNext accounting and fuel operations to finally agree.

Fuel retail chain operations manager

Oversees multiple stations in one ERPNext instance and needs per-site warehouse isolation, standardized shift and dip reconciliation, and dashboards that compare throughput and loss across the network.

Station accountant / finance controller

Owns receivables and the General Ledger and needs fleet-card and credit-customer balances, fuel-rate changes, and evaporation losses to post cleanly to GL without a second reconciliation outside ERPNext.

Shift supervisor

Closes shifts at the forecourt and needs a fast totalizer keypad with live litres-sold and cash-expected figures, plus validation that catches rollover, negative, or transposed readings before they submit.

How Petrol Pump & Fuel Station Management Compares

Criterion	ECOSIRE	Custom Build	Competitor	ERPNext Native
Fit to forecourt workflow	Built to your tank/nozzle layout and shift rules	Possible but you specify and manage every detail	Generic assumptions, rarely matches your station	No nozzle or shift concept at all
Shift & meter reconciliation	Automated litres-sold, cash, and stock posting on submit	Depends entirely on your build quality	Basic if present, often manual	Manual spreadsheets bolted onto ERPNext
Dip / density / evaporation	Calibration-table conversion with categorized loss booking	Build it yourself from scratch	Usually absent or simplistic	Only unexplained stock adjustments
ERPNext accounting integrity	Posts through native invoices, stock, and GL	Correct only if you enforce it	Varies; integration often shallow	Native but with no fuel-specific logic
Fleet card & credit accounts	Per-card limits and driver history on native Customer	Your own design and effort	Limited or add-on	Standard receivables, no fuel context
Delivery time	2-4 weeks from confirmed scope	Often months with hiring and iteration	Instant install but poor fit	Immediate but incomplete for fuel
Support & code ownership	Support window plus full git repo handover	You own and maintain everything	Vendor-locked, limited source access	Community support, no vertical app
Version upgrades	Built for v15/v16, moves with bench migrate	You handle every upgrade break	Depends on vendor release cadence	Core upgrades, no fuel features to carry

Frequently Asked Questions about Petrol Pump & Fuel Station Management

How long does delivery take?

This is a build-to-order ERPNext application, not an instant download. After a scoping call to confirm your tank/nozzle layout, products, credit rules, and target version, typical delivery is 2 to 4 weeks from confirmed scope. We prove it on staging through UAT before installing on production.

How are support and updates handled after go-live?

Every engagement includes a defined post-go-live support window for bug fixes and configuration adjustments. Because you receive the full git repository, ECOSIRE can also deliver later enhancements, version upgrades (v15 to v16), and new features under a support or retainer arrangement. You are never locked to us.

Which ERPNext versions do you support?

We build for ERPNext / Frappe v15 and v16. The app is versioned in its own git repository, installed with `bench install-app`, and upgraded through `bench migrate`, so it moves cleanly with your bench.

How does shift and stock reconciliation actually work?

Operators enter opening and closing nozzle totalizer readings in a `Shift Closing` DocType. A server-side `on_submit` controller computes litres sold, values them at the shift rate, and posts the matching invoice and Stock Ledger Entry. A nightly scheduler job compares book stock against tank dip/density and flags any loss beyond your tolerance.

Can it integrate with our tank gauges or forecourt controller?

Yes. Readings and dips can be posted through whitelisted Frappe REST methods (`@frappe.whitelist()`), so an automatic tank-gauge system or controller console can feed data directly instead of manual entry. We scope the specific hardware and protocol during requirements.

Do we own the code?

Yes. We hand over the private git repository with full commit history for your commissioned version. You keep ownership, can host it on any bench, and can extend it with your own developers if you choose.

How do you keep fuel operations consistent with ERPNext accounting?

The app builds on native ERPNext objects: fuel is a stock `Item` in a `Warehouse`, sales post as `Sales Invoice`/`POS Invoice`, and credit/fleet accounts are standard `Customer` records. Because the logic runs in doc events, stock, receivables, and the General Ledger stay reconciled rather than living in a parallel system.