ForgeERP

About ForgeERP

What this system is, what it does, and why it's built the way it is — in plain language.

ForgeERP runs a manufacturing business from end to end. Selling, buying, making, storing, and accounting all live in one system instead of a stack of separate spreadsheets and tools. Because everything lives in one place, doing something in one spot updates everywhere else on its own — and the right person signs off at each step.

“ERP” stands for Enterprise Resource Planning — industry shorthand for the single system a company uses to run its day-to-day operations.

Single company8 core modulesManufacturing-focused182 API endpoints

Developer & API reference

The full REST API, documented endpoint by endpoint.

Every screen in this app is built on the same REST API — 182 endpoints across all modules, described by an OpenAPI 3.1 specification. Authentication is JWT bearer tokens, errors follow RFC 7807, and every list is paginated and sorted the same way.

Open full screen

Data model

The database schema, as one diagram.

The full schema as an entity-relationship diagram — every table across all modules and how they relate, owned by versioned Flyway migrations (V1–V42) and validated at boot. Open it full screen to pan and zoom.

Open full screen
8
Business modules
56
Database tables
182
API endpoints
400+
Automated tests
19
User roles

What it replaces

The difference an ERP makes, in a sentence each.

The usual way

Sales in one spreadsheet, stock in another, accounts in a third. People re-type the same numbers between them and chase approvals over email. Mistakes creep in, and no one is quite sure which number is the right one.

With ForgeERP

One system. Enter something once and it flows everywhere — stock, production, and the accounts update themselves. Every change is tracked, and the right person signs off at each step, so the numbers stay trustworthy.

Follow one order through the business

The whole system is one connected flow. Here it is, start to finish.

Customer orders
Plan production
Buy & receive materials
Make & quality-check
Deliver
Invoice & collect
Books post themselves
  1. 1

    A customer places an order

    A salesperson records an order for, say, 10 finished units. The system immediately sets aside — reserves — 10 units of stock so they can't be promised to anyone else.

  2. 2

    Short on stock? Make more

    If there aren't 10 in the warehouse, the system flags the gap and a planner schedules a production run to build the rest.

  3. 3

    Production follows the recipe

    Each product has a recipe — its bill of materials. Starting a run automatically takes the exact parts it needs out of the store, so stock stays accurate without anyone re-typing it.

  4. 4

    Quality gets the last word

    Finished units go into a quality hold — not sellable yet. Only after an inspector passes them do they become stock you can ship.

  5. 5

    Buy what's missing

    If raw materials run low, a buyer raises a purchase order and a manager approves it. When the goods arrive they're received into the store and stock goes up.

  6. 6

    Ship it

    When the units are ready, they're dispatched to the customer and the reserved stock leaves the warehouse.

  7. 7

    Invoice, collect, and the books update themselves

    An invoice goes out with the right tax worked out. When the customer pays, that's recorded too — and the matching accounting entries are written automatically, always in balance.

The big ideas

Four things that make it an ERP, not five separate apps.

It's one system, not many

Do something once and it shows up everywhere. No copying numbers between a sales sheet, a stock sheet, and an accounts sheet.

Everyone has their lane

People can only see and do what their job allows — a buyer raises orders, a manager approves them. Like keys that open only certain doors.

Nothing is ever erased

Stock and money changes are recorded like a bank statement: you add a new line, you never rub one out. So you can always trace exactly what happened.

The books always balance

Every amount is recorded on two sides at once — where it came from and where it went — so the accounts can never quietly drift out of balance.

The modules

Each area of the business, and what lives inside it.

Master data

The shared catalogue everything else points back to — what you sell, what you build with, and where you keep it.

Products · Materials · Categories · Units · Warehouses

Design & engineering

The drawings and the recipe for each product. A design is reviewed and released before anything can be built from it.

Design documents · Bills of materials (BOM)

Procurement

Buying materials from suppliers: raise a purchase order, a manager approves it, then receive the goods into stock with a printable receipt.

Suppliers · Purchase orders · Goods receipts

Inventory

Live stock per warehouse, kept as a full history of every movement in and out — so a number can always be traced and is never quietly overwritten.

Stock levels · Stock movements

Manufacturing

Turning materials into finished goods. A production run uses up its materials, the output waits on a quality hold, and only a pass becomes sellable stock.

Production orders · Work centers · Quality checks · Maintenance

Sales & CRM

Winning and fulfilling customer demand. Confirming an order reserves the stock for it; dispatching a delivery ships from that reservation.

Customers · Quotations · Sales orders · Deliveries

Finance

Accounting that writes itself from the work above, so the books always balance — including Indian GST and TDS on invoices and payments.

Chart of accounts · Journal entries · Invoices · Payments · Tax

HR

The light people-and-org layer: who works here and which team they sit in.

Departments · Employees

Security & access

Foundation

Every action is permission-checked. Roles bundle up permissions, and sensitive steps are split between people — whoever raises a document can't approve their own.

Users · Roles · 33 permissions

Attachments

Foundation

Files attach to any record — drawings, supplier documents, inspection photos. The files live in secure storage; the database just remembers where they are.

Drawings · PO documents · Inspection photos

Who uses it

Different jobs see and do different things — the permission system, in everyday terms.

Salesperson

Quotes customers and takes their orders.

Buyer & procurement manager

Buys materials; the manager approves the spend.

Production planner

Decides what gets made, and when.

Machine operator

Runs the jobs on the shop floor.

Quality inspector

Passes or fails what's been made.

Storekeeper & warehouse manager

Receives goods and keeps stock right.

Accountant & finance manager

Handle invoices, payments, and the books.

HR staff

Manage people and departments.

Administrator

Sets up users and who is allowed to do what.

Words you'll hear

A quick plain-English guide to the jargon.

Bill of materials (BOM)
The recipe for a product: the list of parts and quantities needed to make one.
Stock ledger
A running record of everything that moves in and out of the warehouse — like a bank statement for goods.
Reserved stock
Stock set aside for a confirmed order so it can't be sold to anyone else.
Quality hold
Newly made goods parked to one side until an inspector approves them for sale.
Double-entry
The accounting method where every amount is recorded on two sides, so the books always balance.
GST / TDS
Indian taxes the system works out automatically on invoices and payments.
Maker-checker
One person creates a document and a different person approves it — a built-in second pair of eyes.
Purchase order (PO)
A formal request to a supplier to buy materials at agreed prices.

Under the hood

The engineering that keeps it correct — for the technically curious.

Permission-based access

Every endpoint requires a specific permission, enforced on the server — the UI only mirrors it.

Nothing is silently overwritten

Stock and accounting are append-only ledgers: you record a movement, you never rewrite a number.

The books always balance

Double-entry with the debits-equal-credits rule enforced both in the service and by a database constraint.

Safe under concurrency

Optimistic locking and atomic no-negative-stock guards, so two people acting at once can't corrupt a total.

Schema you can trust

The database schema is owned by versioned migrations and validated at boot — it never drifts.

Consistent REST

Uniform pagination, sorting, and RFC 7807 error responses across every one of the modules.

Built withJava 21Spring Boot 4.1PostgreSQL 18FlywayNext.js 16React 19TypeScriptTailwind CSS