Installing a Dolix module

The procedure is the same for all 12 modules. It is described here once, and each module page links to it rather than repeating it in its own way. Allow three minutes.

To upgrade Dolibarr itself, rather than a module, see the guides : Upgrading Dolibarr without breaking anything,Upgrading Dolibarr from the command line.

Dolibarr: 19.0 minimum
PHP: 7.4 minimum
Location: htdocs/custom/
Licence: GPL v3+

Requirements

A Dolibarr installation, version 19.0 or later. The version is shown under HomeAbout, and at the bottom of every page.
PHP 7.4 or later, the minimum version declared by all 12 descriptors.
The external modules folder, htdocs/custom/, present and writable if you use the interface.
The Dolibarr module that the installed module depends on — Commercial proposals or Third parties, depending on the case. Each module page states it.
An administrator account, for the time it takes to activate the module.

Installing through the interface

This is the shortest route, and the one to try first.

Download the module’s zip file from the DoliStore to your computer.
In Dolibarr, open HomeSetupModules/Applications.
Open the “Deploy/install external app/module” tab, choose the zip and upload it. Dolibarr unpacks it into htdocs/custom/ itself.
The module appears in the list. Enable it with the switch on its row.

If this tab is missing or the upload fails, module uploads have been disabled on this installation, or the custom folder is not writable. Use the file method instead.

Installing by file

For shared hosting where uploading through the interface is blocked, or for a server you access over SSH.

Unzip the file on your computer.
Upload the resulting folder to htdocs/custom/, without renaming it. You should end up with, for example, htdocs/custom/dolixmasse/core/modules/…, and not htdocs/custom/dolixmasse/dolixmasse/….
Check that the files can be read by the web server’s account. After an FTP upload, this is the check that settles most cases.
Reload HomeSetupModules/Applications: the module is in the list. Enable it.

Enabling the module and granting permissions

Activation creates what the module needs to create — its history table when it has one, its complementary attribute when it adds one. It deletes nothing.

Permissions are then granted under HomeUsers & Groups, on the Permissions tab of the user or group concerned.

Permissions added by each module
Module	Dedicated permission	Where the module appears
Margin per day	None	No menu entry. The module shows up on the quote card and in the quote list.
Email domain changer	Yes	Third parties menu“Change an email domain”.
Bulk field update	Yes	Third parties menu“Bulk update”.
Move tasks between projects	Yes	Projects menu“Move tasks”.
Duplicate finder	Yes	Third parties menu“Duplicates”.
Update prices on quotes and template invoices	Yes	One entry: Billing \| Payment › List of templates › Update template prices. The button also appears on the card of a draft quote and of a template invoice.
Landed costs	Yes	Products menuWarehouses“Landed costs”, and “Landed costs” tab on the purchase order card.
Remaining to bill	Yes	Commerce menuSales Orders“Remaining to bill”. A “Remaining to bill” tab on each sales order.
Upgrade readiness check	None	Home menuAdmin Tools“Upgrade readiness check”.
EU VAT Mentions	None	No menu. On the invoice card, a “Printed VAT statement” line and the “VAT statement” attribute. Settings: SetupModules/ApplicationsEU VAT Mentions.
Receipts in expense reports	None	No menu entry. The module acts when the expense report PDF is generated; its settings are in SetupModules/Applications.
TakePOS wallet	Yes	No menu entry. “Wallet” tab on the third-party card and on the member card; “Wallet” button on the TakePOS payment screen.

Upgrading a module

Get the new version from the DoliStore.
Disable the module in the module list. Disabling deletes no data: not the tables, not the settings, not the values entered.
Replace the module’s folder in htdocs/custom/ with the new one, or upload the zip again through the deployment tab.
Enable the module again. The settings and the history are found exactly as they were.

The version history on each module page is taken from the ChangeLog.md file shipped with the module: there cannot be two different stories.
On each module page, “Version history” section

Uninstalling, and what stays in the database

Disabling a module removes its screens and its columns. What it wrote to the database stays — that is deliberate, so that disabling by mistake destroys nothing. Here is what that covers, module by module.

What each module leaves in the database after being disabled
Module	What it writes to your database
Margin per day	No table. The module folder does not contain a sql/ directory. On activation, the module creates a “Planned days” complementary attribute (code mpj_journees) on commercial proposals: the value is stored in the quotes' complementary attributes table, already present in Dolibarr.
Email domain changer	One table: llx_dolixdomaine_log. It records the history of operations (date, user, old domain, new domain, number of third parties, contacts and members changed, entity). No business data is stored in it.
Bulk field update	One table: llx_dolixmasse_log. It records the history of operations (date, user, object, field, filter applied, new value, number of records changed, entity). No business data is stored in it.
Move tasks between projects	One table: llx_dolixtaches_log. It records the move history (date, user, task identifier, its reference and label at the time of the move, source project, target project, flag for whether the documents were moved, entity). No business data is stored in it.
Duplicate finder	One table: llx_dolixdoublons_log. It records the merge history (date, user, object type, kept record, merged record, names of both records, entity).
Update prices on quotes and template invoices	No table, no complementary attribute. The module folder does not contain a sql/ directory. The module only stores two settings in the Dolibarr constants.
Landed costs	Four tables: llx_dolixapproche_dossier (shipment files: reference, label, arrival date, status, note), llx_dolixapproche_order (purchase orders attached to each file), llx_dolixapproche_frais (costs: label, type, amount excluding tax, spread key, linked supplier invoice) and llx_dolixapproche_journal (every changed value, with the old and new value, quantity, stock and amount, so it can be undone).
Remaining to bill	No table. The module reads orders, invoices and the links between documents; it writes nothing to the database. Its two settings are stored as Dolibarr constants: DOLIXRAF_INCLUDE_DRAFTS and DOLIXRAF_INCLUDE_SHIPMENTS.
Upgrade readiness check	No table. The module creates no table, no setting and no file: the report is computed on each request and downloads are generated on the fly.
EU VAT Mentions	No table. On activation, the module adds a “VAT statement” complementary attribute to invoices (field dolixtva_case, so a column of llx_facture_extrafields) and stores its settings as constants. If you turn on the correction of the French statement, the corrected text is stored in Dolibarr's overwritten translations (table llx_overwrite_trans), as SetupTranslation would do.
Receipts in expense reports	No table. The module folder contains no sql/ directory. On activation, the module stores three settings in Dolibarr's constants. If a receipt is set aside, a record is kept in a small file, documents/dolixjustif/quarantaine_.json, not in the database.
TakePOS wallet	One table: llx_dolixpm_recharge. It keeps one row per top-up (third party, down payment invoice, amount, date, user, note, entity). The balance is not stored there: it is the sum of the Dolibarr available credits coming from those down payment invoices.

If the module does not appear

Five checks, in this order. They cover most cases.

Is the folder in the right place? The module folder must sit directly in htdocs/custom/ and bear exactly its technical name — the one given on its page. A folder nested twice (custom/dolixmasse/dolixmasse) is the most common cause.
Can the web server read the files? After unpacking over FTP or SSH, the files sometimes belong to an account other than the web server’s. The module then stays invisible in the list.
Is the Dolibarr version recent enough? All 12 modules require Dolibarr 19.0 or later and PHP 7.4 or later. The Dolibarr version is shown under HomeAbout.
Is the module it depends on enabled? Each module page states the Dolibarr module to enable first — Commercial proposals or Third parties, depending on the case. Without it, the expected screen does not appear.
Have the permissions been granted? A module that is enabled but has no permission granted stays invisible to the user. Permissions are granted under HomeUsers & Groups, on the Permissions tab.

None of the above?

Write to support@dolix.fr with your Dolibarr version, the module concerned and its version, and the error message copied exactly.

Support page