Your process does not fit standard Dolibarr. Now it does.
Dolibarr Custom Module Development
When standard modules only half-cover your workflow, teams fall back on workarounds and risky core edits that the next update breaks. Anexum builds Dolibarr custom modules on documented extension points, with tests and upgrade compatibility. Your process lives in the ERP and survives the next upgrade.
Discuss a custom moduleWhat is Dolibarr Custom Module Development?
Dolibarr custom module development extends ERP and CRM with business objects, roles, workflows, triggers, hooks, documents, dashboards, REST APIs, and webhooks. Anexum first evaluates standard features and existing modules, avoids unnecessary core patches, and documents versions, migrations, tests, and operation.
Service scope
- Module scaffolding and architecture
- Objects, permissions, menus, and workflows
- Triggers, hooks, scheduled jobs, and document templates
- REST APIs, webhooks, and third-party systems
- Data migrations and upgrade tests
- Git, documentation, and maintenance
Updates do not break your customization
We build through the custom directory and documented extension points. Compatible versions, migrations, and regression tests are recorded, so the next Dolibarr update does not take your module offline.
Upgrade-aware
Compatible Dolibarr versions, migrations, dependencies, and regression tests are documented.
Operable
Deployment, permissions, monitoring, backup, and support are considered from the start.
When does a company need a custom module?
A custom module can be appropriate when standard configuration, workflows, and established third-party modules cannot represent an important process adequately. Expected value must justify development and maintenance effort.
What is checked before development?
Anexum reviews Dolibarr standard modules, settings, dictionaries, extra fields, existing Dolistore modules, APIs, and possible process changes. Custom development is not automatically the best first solution.
Which functions can be implemented?
Options include custom objects, cards, lists, permissions, menus, numbering, state models, triggers, hooks, scheduled jobs, PDF and ODT documents, dashboards, imports, exports, REST endpoints, and webhooks.
How does requirements analysis work?
The process is described through roles, triggers, data, rules, exceptions, permissions, and acceptance criteria. Open decisions are made visible before estimation.
How is the technical architecture defined?
Architecture decisions document module structure, data model, extension points, integrations, error handling, migration, security boundaries, and supported Dolibarr and PHP versions.
How is the module tested?
Testing covers installation, activation, permissions, core workflow, error cases, data migration, documents, APIs, scheduled jobs, deactivation, and upgrades. Customer acceptance uses the agreed acceptance criteria.
How are updates and maintenance handled?
Supported versions, maintenance scope, response path, and the procedure for Dolibarr updates are agreed for each module. Dependencies on third-party modules are documented explicitly.
Case study: a construction ERP for an Austrian contractor
For an Austrian construction company we built DoliConstruct, a construction-industry solution on top of Dolibarr. It connects ÖNORM B 2061 K3 cost calculation, the bill of quantities under ÖNORM A 2063, the offer, the project, and post-calculation in one continuous data flow. Time tracking with Austrian allowances, material consumption per bill-of-quantities position, equipment, and per-site stock all run in the same system. A bmdimport submodule pulls employees and cost centres from BMD accounting, and the BMD payroll export returns the recorded hours. This removes the duplicate data entry between site, office, and payroll.
Case study: mobile stock handling with a barcode scanner
The same company also runs MobileUI, a mobile PWA for warehouse and site work. Stock staff scan items with the device camera, view stock levels with movement history, and place material requests through a cart with warehouse selection directly on a phone. The interface is built for large touch targets and offline use, so it stays reliable on site and in the warehouse. Both modules are built through the custom directory, tested, and maintained for version compatibility.