What is Cluster ERP

Cluster ERP is a modular enterprise resource planning system written in Python. This page describes its scope as the code defines it: the server, the three ways to reach it, and the 28 backend modules with one line each. It does not explain how the parts work together; see the architecture overview for that.

In short¶

• The package is named cluster-erp, describes itself as a "Modular Enterprise Resource Planning System", and declares a proprietary license (pyproject.toml:5-10, LICENSE).
• The server is a FastAPI application built by the factory create_app (src/cluster_erp/server/app.py:1287).
• Business features live in 28 modules under src/cluster_erp/modules/. Each one subclasses ModuleBase (src/cluster_erp/core/module_base.py:14).
• There are three clients: the web app in webapp/, the PySide6 desktop client, and the HTTP API itself (src/cluster_erp/server/app.py:1633-1644, pyproject.toml:86-88).
• The project rules aim at all countries and many languages.

How it works¶

The server process starts from python -m cluster_erp.server.main, which runs uvicorn with the create_app factory (src/cluster_erp/server/main.py:39-41). At start-up the module registry loads every enabled module, and each module adds its routes, EventBus handlers, and screen metadata (src/cluster_erp/core/module_registry.py:32-56). The details are on server startup and app factory and module lifecycle.

The three clients¶

Both clients draw their screens from the module metadata served at GET /api/v1/_meta (src/cluster_erp/server/app.py:1518-1556). The web app section and the desktop section document the clients.

The 28 backend modules¶

The table lists every folder in src/cluster_erp/modules/ (28 folders, counted with ls, excluding __pycache__). The description column quotes the module's own description property. The default value of enabled_modules lists the same 28 names (src/cluster_erp/config/settings.py:535-564).

Some descriptions are lightly edited in the table: punctuation dashes are replaced by commas, "&" is written as "and", and the sales_orders text omits the words "(assets)" and "with packages, transport". Each module has its own page in the modules section.

Why it is built this way¶

The project's written engineering rules state the intent: the product targets all countries. Language, currency, date format, address structure, and tax system must work independently of the country. A new language is a new JSON file with no code change. Reference data such as countries, address levels, and currencies is kept in the database, not in code.

The code reflects parts of this intent:

• The web app reads its language list from webapp/i18n/languages.json, which lists tr and en.
• Currencies are rows of core_currencies, seeded from the ISO 4217 set (src/cluster_erp/core/currencies.py:57-89, src/cluster_erp/core/currencies.py:1811-1852).
• Countries are rows of parties_countries, seeded at start-up by the parties module (src/cluster_erp/modules/parties/settings/models.py:12-13, src/cluster_erp/modules/parties/module.py:41-42).

See reference data and core i18n for the details.

Rules and boundaries¶

The project's written engineering rules list binding rules: no guessing, no hardcoding, no direct module-to-module calls, Decimal money, no hard delete, the mandatory product, model, and version breakdown, and a metadata-driven web app. The platform section shows the code that enforces each rule, and the decisions section records them.

Interaction with other parts¶

The server, the clients, and the modules meet in three places: the HTTP API, the metadata document, and the EventBus. The architecture overview draws this as one diagram.

Limits and open points¶

• The FastAPI application reports version 0.1.0 (src/cluster_erp/server/app.py:1296-1298), and pyproject.toml:7 declares the same. Release tags such as v0.1.37 appear in the git history. How the two version numbers relate is not determined from code.
• Which countries a deployment serves is runtime data. It is not determined from code.

Terms introduced¶

Related pages¶

• Overview
• Architecture overview
• Repository map
• Module lifecycle

Verified against commit 92f8051 on 2026-11-13.