Portfolio Projects
Reading about ERP teaches you vocabulary. Building teaches you the domain. These projects are ordered by difficulty and each one produces something you can show an interviewer.
Everything here can be done for free on Odoo Community or ERPNext.
Project 1 — Configure a fictional company end to end
Effort: 2–4 weeks · Teaches: the whole domain · Shows: you understand ERP, not just code
Pick a real-ish business and build it properly. A good example: a Dhaka-based garment manufacturer with an export arm.
□ Company setup: legal entity, currency (BDT), fiscal year (Jul–Jun),
chart of accounts, tax codes (VAT 15%, AIT withholding)
□ Second company in a different currency for intercompany practice
□ Org structure: 2 warehouses, 4 cost centres, 2 profit centres
□ Master data: 40 customers (domestic + export), 25 vendors,
120 items across raw material / WIP / finished goods, with UoM conversions
□ Pricing: a domestic price list, an export price list in USD,
a volume discount, one customer-specific negotiated price
□ Payment terms, credit limits
□ Full O2C cycle: quotation → order → delivery → invoice → payment → clearing
□ Full P2P cycle: requisition → PO → receipt → bill → payment
□ A BOM and a manufacturing order
□ A month-end close: reconcile, run reports, produce a trial balance,
balance sheet, and P&L
□ Screenshots and a written walkthrough of every step
The deliverable: a written document walking through each cycle, with the resulting journal entries explained. “When I posted the goods receipt, the system debited inventory 6,000, credited GR/IR 6,250, and posted a 250 price variance because the material uses standard costing.”
This single project is more persuasive in an interview than any amount of code, because it proves the thing that’s hardest to teach.
Project 2 — A custom report
Effort: 3–5 days · Teaches: the data model, reporting tools
Build the aged stock provision report from Requirements and Fit-Gap:
□ Selection screen: company, plant (multi), material group, key date
□ Logic: last issue date per material/plant, ageing buckets,
provision percentages from a configuration table (not hardcoded)
□ Output: grouped, subtotalled, exportable
□ Authorisation check
□ Performance: tested with 50,000+ material/plant combinations
□ Documented technical spec
Why this one: it exercises the item master, movement history, valuation, configuration-as-data, authorisation, and performance — most of the skills a reporting request needs.
Project 3 — A custom document type with a full lifecycle
Effort: 1–2 weeks · Teaches: the document pattern, workflow, posting
Build a Customer Deduction / Dispute object:
□ Header + line items
□ Links to the original invoice (document flow)
□ Draft → submitted → approved → resolved status machine
□ Approval workflow with a value threshold
□ Reason code catalogue
□ On approval: generates a credit memo, or writes off, per resolution type
□ Reporting: open disputes by reason, by age, by customer
□ Full audit trail
Why this one: it’s a real gap in most ERPs, it’s a genuine business need (see Accounts Receivable), and it forces you to implement the header/item, document flow, workflow, and posting patterns together.
Project 4 — An integration
Effort: 1–2 weeks · Teaches: the work you’ll actually do
Pick one:
Option A — E-commerce → ERP
□ Poll or webhook from a store platform (or a mock API you write)
□ Map customer, items, addresses; create a customer if new
□ Create a sales order with correct pricing and tax
□ Idempotency key derived from the store's order ID
□ Error queue with retry and a dead letter path
□ Daily reconciliation report: orders received vs orders created, with values
Option B — Bank statement import
□ Parse CAMT.053 XML or MT940 (both are documented and sample files exist)
□ Validate opening/closing balance continuity
□ Auto-match to open AR items by reference, then by amount
□ Post matched items; queue unmatched for manual handling
□ Reconciliation: statement closing balance = GL bank balance
Option C — ERP → external warehouse
□ Push outbound deliveries as JSON to a mock WMS
□ Receive pick confirmations with partial quantities
□ Post goods issue for confirmed quantities
□ Handle partial confirmation and cancellation
□ Daily quantity reconciliation
The differentiator is the non-happy path. Anyone can write the integration. Showing idempotency, retry, dead-lettering, and reconciliation shows you’ve thought about production.
Project 5 — A posting-assertion test suite
Effort: 1 week · Teaches: the discipline that separates ERP developers
For each business event, assert the EXACT journal entries:
□ Goods receipt (standard cost, with variance)
□ Goods receipt (moving average)
□ Vendor invoice with a price difference
□ Goods issue for a sales delivery
□ Customer invoice with tax
□ Customer payment with partial clearing
□ Credit memo with restocking
□ Production order confirmation and settlement
□ Foreign currency invoice and payment with FX gain
□ Reversal of each of the above
Why this is a strong portfolio piece: almost nobody does it, and any experienced ERP person will immediately recognise that you understand what matters. It also happens to be genuinely useful work — a regression suite like this is valuable to any real project.
Project 6 — A vertical mini-ERP
Effort: 2–3 months · Teaches: everything · Shows: you can build, not just configure
Build a narrow ERP for one industry. Scope it ruthlessly — see Building Your Own ERP.
Good candidates:
- A tailoring/boutique shop: measurements, orders, fabric inventory, payments
- A small pharmacy: batch and expiry tracking, FEFO, purchase, sale, VAT
- A restaurant: recipes (BOM), ingredient inventory, waste, daily sales
- A freight forwarder: shipments, containers, charges, invoicing
- A small manufacturer: BOM, production orders, costing, stock
Non-negotiable design requirements:
□ Double-entry ledger, append-only, enforced sum-to-zero
□ NUMERIC amounts with currency
□ Document flow table
□ Audit log on every change
□ A single posting service
□ Number ranges as a real object
□ Idempotency on write APIs
□ Multi-tenant from day one (tenant_id first column everywhere)
□ A property test that asserts the invariants after random operation sequences
This is a serious project. Done well it’s a portfolio centrepiece; done badly it’s a demonstration that you don’t understand the domain. Only attempt it after projects 1–5.
Project 7 — Read and document a real ERP’s core
Effort: 2 weeks · Teaches: more than any tutorial
□ Clone ERPNext
□ Read erpnext/accounts/general_ledger.py
□ Read erpnext/stock/stock_ledger.py
□ Read erpnext/controllers/accounts_controller.py
□ Trace one complete flow: what happens when a Sales Invoice is submitted?
□ Write it up: a sequence diagram, the tables touched, the entries created,
the validations performed, the edge cases handled
Publish the write-up. It demonstrates that you can read unfamiliar production code and explain a complex system — which is most of what a senior developer does.
Presenting the portfolio
A GitHub repo per project, each with:
README.md
- What it is, in two sentences
- The business problem it solves
- Screenshots or a short screen recording
- Design decisions and trade-offs
- What you'd do differently
- How to run it
A single index repo linking them all, with a short narrative of what you learned in what order.
Write about it. A blog post or a LinkedIn article explaining, say, “why ERPs use reversals instead of deletions” — written clearly, with an example — does more for your credibility than the code itself. It shows you can explain the domain, which is exactly what a techno-functional role needs.
What employers actually look for
Ranked:
- Do you understand the domain? (Project 1 proves this)
- Can you build on the platform? (Projects 2–3)
- Do you think about production? (Projects 4–5: errors, idempotency, reconciliation)
- Can you communicate? (Documentation and writing)
- Can you learn independently? (The whole portfolio proves this)
Not on the list: algorithm puzzles. ERP interviews are about domain understanding and practical judgement.