A build-to-order Odoo module that turns pump-and-nozzle meter readings, staff shifts, tank stock and vehicle credit sales into reconciled daily accounting. ECOSIRE scopes, builds, installs and supports it on Odoo 17, 18 or 19. Built to order by ECOSIRE for Odoo 17, 18, 19 — indicative price from $399.00 USD; request a quote for a scoped proposal.

A build-to-order Odoo module that turns pump-and-nozzle meter readings, staff shifts, tank stock and vehicle credit sales into reconciled daily accounting. ECOSIRE scopes, builds, installs and supports it on Odoo 17, 18 or 19.
لا حاجة للدفع الآن. يؤدي هذا إلى إرسال طلب عرض سعر إلى فريقنا — وسنتواصل معك عبر البريد الإلكتروني بالأسعار والخطوات التالية.
Petrol and gas stations run on a rhythm Odoo core was never shaped for: every shift a nozzle meter is read, litres are converted to cash-plus-credit, a dip stick or ATG reading confirms what's left in the tank, and the attendant's drawer has to balance against the meters before the next shift takes over. Out of the box, Odoo gives you sale.order, stock.picking and POS sessions — none of which understand a nozzle's opening and closing totalizer, temperature/density-corrected fuel volume, or a credit customer identified by vehicle number rather than a formal sale.order. Owners end up reconciling meters in spreadsheets and re-keying totals into accounting, which is exactly where shortages hide.
Dedicated `fuel.tank`, `fuel.dispenser`, `fuel.nozzle` and `fuel.shift` models linked to standard `product.product` fuel grades so dispensing moves real `stock` quantities
Per-shift nozzle meter capture (opening/closing totalizer) with a `@api.depends` compute that derives litres sold, gross sales and expected cash
Shift cash reconciliation: expected-vs-counted across cash, card, wallet and credit tenders, with an auto-flagged variance line
Staff shift management with attendant assignment, handover, and record rules so an attendant sees only their own open shift
Credit sales against a `res.partner` plus tracked `vehicle_no`, posting receivables without forcing a full `sale.order` quotation flow
Daily fuel-collection sheet aggregating all nozzles, grades and tenders into one reconciled QWeb report
We build a dedicated fuel-retail layer as a proper Odoo module. New models — fuel.tank, fuel.dispenser, fuel.nozzle, fuel.shift and fuel.meter.reading — sit alongside standard product.product (each fuel grade) and stock so litres dispensed decrement tank stock through real inventory moves, not a parallel ledger. A fuel.shift collects every nozzle's opening and closing reading; a computed field (@api.depends on the reading pairs and unit price) derives litres sold, gross sales, and the expected cash the attendant must hand in. Cash, card, wallet and credit tenders are captured against the shift so the reconciliation line shows expected-vs-counted and flags the variance the moment it's non-zero.
Credit sales are modelled the way a station actually issues them — against a res.partner (fleet or account customer) and a tracked vehicle_no, so a driver fuels on account and the receivable posts to the customer's ledger without forcing a full quotation flow. Tank management covers deliveries (a fuel purchase increments tank stock and can post the supplier bill), density and dip adjustments (variance between book stock and measured dip, recorded with a reason), and low-level alerts via Odoo automated actions. Everything is permissioned through ir.model.access.csv plus record rules so a pump attendant sees only their own open shift while the manager sees the station, and QWeb reports produce the shift-closing slip, daily fuel-collection sheet and credit-outstanding statement your accountant already expects.
Because this is build-to-order, you are not downloading a generic app and hoping it fits. We start from a short scoping call, confirm your grades, tank/pump/nozzle layout, tender types, credit-customer rules and whether you need density correction or ATG integration, then build against your exact Odoo edition. Delivery is typically 2-4 weeks from confirmed scope. You receive the installable source for your version, install and configuration on your server or Odoo.sh, technical and user documentation, a training session, and a post-go-live support window — with the git repository handed over so the module is yours, not locked behind a vendor. The same models are reachable over Odoo's XML-RPC/JSON-RPC API, so downstream dashboards or a forecourt controller feed can be wired in later without touching the UI.
Runs one or two forecourts and needs shift meters, cash reconciliation and tank stock to tie back to Odoo accounting so shortages stop hiding in spreadsheets.
Manages multiple stations under one Odoo database and needs per-station tanks, pumps and pricing plus roll-up reporting over the RPC API for a central dashboard.
Owns the daily close — needs the shift-closing slip, expected-vs-counted variance flags and a credit-outstanding statement to settle attendants and chase fleet accounts.
Handles account customers who fuel on credit by vehicle number and needs receivables posted to the right partner ledger with an ageing statement, not loose IOUs.
قم بشراء الترخيص من موقع ecosire.com وقم بتنزيل وحدة Fuel Station / Petrol Pump Management ZIP من لوحة تحكم حسابك.
قم باستخراج ملف ZIP إلى مجلد إضافات Odoo المخصصة على الخادم (أو تحميله عبر التطبيقات > التثبيت من ملف على Odoo.sh / runbot).
قم بتنشيط وضع المطور، وافتح التطبيقات، وانقر فوق تحديث قائمة التطبيقات، وابحث عن Fuel Station / Petrol Pump Management، ثم اضغط على تثبيت.
افتح القائمة الجديدة، والصق مفتاح ترخيص ECOSIRE الخاص بك، وقم بتوصيل أي بيانات اعتماد خارجية (Shopify، وAmazon، وStripe، وما إلى ذلك)، ثم احفظها.
قم بتشغيل اختبار الاتصال المدمج، وقم بمزامنة أول 10 سجلات لديك، وقم بجدولة عملية cron المتكررة. اتصل بالدعم إذا فشل أي شيء.
| المعيار | ECOSIRE | بناء مخصص | منافس | أودو الأصلي |
|---|---|---|---|---|
| Fit to your forecourt | Built to your grades, tank/pump/nozzle layout and tender rules | Fully bespoke but you specify and manage everything | Generic feature set, bend your process to fit | |
| Shift meter reconciliation | Opening/closing readings with computed expected-vs-counted variance | Possible if you build the compute logic yourself | Varies; often basic totals, weak variance handling | |
| Credit sale by vehicle | Partner ledger + tracked `vehicle_no`, ageing statement | Buildable to spec at your cost | Sometimes present, rarely with ageing | |
| Tank stock & dip/density | Real stock moves plus dip/ATG variance with reasons | You design the variance model | Basic stock, limited density correction | |
| Delivery time | Typically 2-4 weeks from confirmed scope | Weeks to months depending on your team | Instant download but integration effort after | |
| Ownership & lock-in | Git repo handed over — source is yours | You own it; you also maintain it alone | Licensed, vendor-controlled updates | |
| Support & upgrades | Post-go-live window + optional version upgrades | Your responsibility unless separately contracted | Depends on publisher SLA | |
| Reports & compliance | Tailored QWeb shift slip, collection sheet, credit statement | Built to order at extra effort | Fixed templates, limited tailoring |
Because this is build-to-order, we build it for your exact Odoo edition after we agree scope — typically 2-4 weeks from confirmed scope. Simple single-station setups land at the shorter end; multi-station, density-correction or forecourt-controller integrations at the longer end. There is no instant download; a firm timeline is confirmed on the scoping call.
Yes. We build against Odoo 17.0, 18.0 or 19.0, Community or Enterprise. The core fuel-retail models work on Community; where your workflow depends on Enterprise features (for example certain accounting or studio-generated views) we account for that during scoping so the build matches what you run.
A credit sale is captured against a `res.partner` (the fleet or account customer) with the `vehicle_no` recorded on the transaction. The receivable posts to that partner's ledger, so you get a proper credit-outstanding statement with ageing instead of paper slips — without forcing every fuelling through a full `sale.order` quotation.
Each shift stores opening and closing nozzle readings. A computed field (`@api.depends` on the reading pairs and the grade's unit price) derives litres sold and expected cash. The attendant's counted cash, card, wallet and credit tenders are entered, and the shift shows expected-vs-counted with the variance auto-flagged the moment it's non-zero.
Every build includes a post-go-live support window for defect fixes and configuration tweaks. Because we hand over the git repository, you own the source and can maintain it in-house or engage us for future enhancements, version upgrades (for example 18 to 19) or new stations under a separate agreement.
The models are exposed over Odoo's XML-RPC/JSON-RPC API, so BI dashboards, multi-station roll-ups or a forecourt-controller feed can read and write shift and tank data. Direct pump-hardware/ATG integration is scoped case by case depending on your controller and available protocol.
We install and configure the module on your server or Odoo.sh, set up your tanks, pumps, nozzles, grades and tenders, run UAT on a staging database with a rollback plan, and deliver a training session for attendants, cashiers and managers plus written documentation. You are not left to deploy raw source.
A build-to-order Odoo module that turns pump-and-nozzle meter readings, staff shifts, tank stock and vehicle credit sales into reconciled daily accounting. ECOSIRE scopes, builds, installs and supports it on Odoo 17, 18 or 19.