Marine Procurement & Approval System (Odoo 19)
A custom Odoo 19 module pitched as a working prototype to a Malaysian offshore marine operator, closing the four gaps standard Odoo left in their project-to-payment workflow: purchase requisitions that turn into orders line by line (with no vendor field, so the requester states the need and procurement picks the supplier), a limits-of-authority approval matrix that routes each requisition and purchase order to the right approvers by amount and OPEX/CAPEX, service acceptance so services like hull-cleaning dives can only be billed once confirmed as performed, and a vessel register with per-vessel and per-project cost tracking on a custom dashboard. Every step of the workflow was tested end to end, logged in as each role. Shown here with fictional demo data.
- Client
- Pitch prototype for offshore marine operator
- Duration
- 1 week
Built with
- Odoo 19
- Python
- PostgreSQL
- Docker
- OWL (Odoo Web Library)
- JavaScript
The problem it solves
Standard Odoo 19 already handled most of this operator's purchasing, so the first step was a full purchase cycle and thirteen structured tests on plain Odoo. They showed four real gaps. There was no purchase requisition: Odoo's own form demands a vendor before anyone can ask for anything. Approval was a single amount threshold, so a RM 7,700 order could be self-approved in one click, with no difference between operating and capital spend. Services could be billed and paid with nothing confirming the work was done: an RM 8,500 service showed 'received 0, billed 1'. And there was no register of vessels to cost spending against.
Who it's for
Built for offshore and marine operators, but it fits any company where purchases need sign-off by amount, several people touch one purchase (requester, department head, finance, buyer, store), and services such as dives, inspections or repairs are bought and billed alongside goods.
What it does
Purchase requisitions
Staff ask for what they need, quantity, project and vessel, without having to pick a supplier. Procurement chooses the vendor, and each requisition line turns into a request for quotation and purchase order line by line.
Approval by amount and spend type
A limits-of-authority matrix routes every requisition and purchase order to the right approvers in order, based on the amount and whether it is operating (OPEX) or capital (CAPEX) spend. Small requests need one signature, bigger ones also wait for Finance.
Approval queues and a full trail
Each approver sees only what is waiting on them. Every approval, rejection and change is logged on the document with who did it and when.
Orders can't skip approval
A purchase order can't be confirmed until its own approvals are complete, so a buyer can't place an order the matrix hasn't cleared.
Service acceptance
A service can only be billed once someone confirms it was actually performed, and only for the amount accepted: accept one of two dives and only one can be billed.
Partial deliveries
When only part of an order arrives, the store receives what came and the rest stays open as a backorder.
Bills that match reality
A vendor bill is checked against what was received or accepted, for goods and services alike, so you only pay for what you got.
Cost per vessel and project
A vessel register and a dashboard show committed spend (ordered but not yet billed) and actual cost for each vessel and project, kept up to date as orders, receipts and bills move.
How it works
8 steps, each one in the walkthrough video above
01Spend per project and vessel at a glance
The procurement dashboard: open requisitions and orders, what is waiting for approval, and spending broken down by project and by vessel.
02Two-step approval, every decision logged
A requester asks for two diving services and 100 m of rope, RM 18,750 in total. At that amount the matrix requires two approvals: the department head signs first, and each decision is written to the record's history.
03Bigger requests wait for Finance
The request then waits in Finance's own queue next to other requests that need them. Finance approves, and the requisition is cleared for buying.
04Purchase order raised from the request
The buyer turns the requisition into a request for quotation and picks the supplier. Confirming the order is blocked until it goes through its own approvals; once they are done the purchase order is confirmed.
05Partial delivery, backorder for the rest
Only 60 of the 100 m of rope arrives. The storekeeper receives the 60 m and the remaining 40 m stays open as a backorder.
06Services accepted only for work done
One of the two dives has been done, so the buyer accepts one. Only that one dive can now be billed.
07Bill matches what was received
Finance enters the supplier's bill. It can only cover what was received and accepted, one dive and 60 m of rope (RM 10,825), and it is posted.
08Running cost per vessel
The vessel's cost to date updates by itself: what is committed on open orders, and what has actually been billed.
How it's built
- A custom Odoo 19 module in Python, with OWL (Odoo's own JavaScript framework) for the dashboard, on PostgreSQL, running in Docker. It targets Odoo.sh, Odoo's hosting that accepts custom modules.
- Scope was set by testing, not assumptions: anything standard Odoo already did well (committed cost against budget, partial deliveries, matching bills for goods, costing by project) was left alone, so the module only adds what was missing.
- Service acceptance plugs into Odoo's own 'received quantity' mechanism instead of building a separate check, so Odoo's existing bill matching and 'should be paid' signals start working for services too. It can be switched on per product.
- The approval matrix is configuration, not code: the bands can be changed to the company's real limits without touching the module.
- Tested end to end, logged in as each role, on fictional demo data. Testing also caught a cost-report bug where goods with a draft bill briefly dropped out of actual cost; it was fixed and re-tested.
What this shows I can build
Web apps and systems
Built for how your business runs, like inventory, booking and reporting, usable from any device.
Custom software
Software built around your workflow, from planning and design to testing and support after launch.
More projects
- Credit Tracking & Usage Monitoring SystemA working prototype pitched to the DXP Digital Acceleration Program for a consulting firm that buys prepaid assessment credits from a third-party platform with no API, and tracked them manually in Excel. It replaces the spreadsheet with a tamper-proof credit ledger (corrections are new entries, never edits), assessment status tracking, an Excel/CSV import wizard with a dry-run preview, monthly reconciliation against the provider's statement with automatic matching and a dispute queue, burn-rate forecasting with reorder suggestions, low-balance alerts and weekly digests, role-based access, a full audit log, and Excel/PDF usage reports. Built solo.
- ICT Inventory & Reporting SystemWeb-based inventory management and reporting system with a custom report page, built with PHP/MySQL and deployed via XAMPP with LAN access for multi-device use. Full-stack inventory system with barcode/QR lookup, custom item categories, and automated status-history reporting for IT assets.
Want something like this built?
Tell me what your business needs and I'll suggest the simplest way to build it.