[[Category:Complementary modules]]
[[Category:Financial]]
[[Category:Accountancy]]

{{TemplateDocDev}}
{{TemplateDocUtil}}

<div style="border:1px solid #d7e3f4; border-radius:14px; padding:22px; margin:12px 0 22px 0; background:linear-gradient(135deg,#f6faff,#ffffff); box-shadow:0 2px 10px rgba(20,60,110,0.08);">
<div style="font-size:28px; font-weight:700; color:#17365d; margin-bottom:8px;">TDHP Mizan for Dolibarr</div>
<div style="font-size:18px; color:#345; margin-bottom:14px;">Hierarchical trial balance (mizan) for the Turkish uniform chart of accounts</div>
<div style="display:flex; flex-wrap:wrap; gap:8px; margin-top:10px;">
Main / sub-account roll-up Debit · Credit balances Period types PDF printing Sayıştay CSV Free · GPLv3
</div>
</div>

==Overview==

'''TDHP Mizan''' is a free external module for '''Dolibarr ERP/CRM''' that builds a hierarchical trial balance (''mizan'') for the '''Turkish uniform chart of accounts''' (Tekdüzen Hesap Planı, TDHP) from the Dolibarr general ledger.

It only reads the ledger and the chart of accounts, has no tables of its own and does not modify any core file.

==Publisher and support==

{| class="wikitable" style="width:100%; border-collapse:collapse;"
! style="width:24%; background:#f0f6ff;" |Item
! style="background:#f0f6ff;" |Information
|-
|'''Publisher'''
|'''M. Burak Şentürk'''
|-
|'''Website'''
|https://buraksenturk.net
|-
|'''Support'''
|https://github.com/mbrksntrk/dolibarr-tdhp-mizan/issues
|-
|'''Source code'''
|https://github.com/mbrksntrk/dolibarr-tdhp-mizan
|}

==Module information==

{| class="wikitable" style="width:100%;"
! style="width:24%; background:#f7f7f7;" |Information
! style="background:#f7f7f7;" |Detail
|-
|'''Module name'''
|TDHP Mizan (<code>tdhpmizan</code>)
|-
|'''Module number'''
|194096
|-
|'''Main use'''
|Trial balance report for the Turkish uniform chart of accounts
|-
|'''Type'''
|External Dolibarr module
|-
|'''Family'''
|Financial
|-
|'''Documented version'''
|1.1.0
|-
|'''Dolibarr compatibility'''
|Dolibarr 20.0 or higher (developed and tested on 24.0)
|-
|'''PHP compatibility'''
|PHP 7.4 or higher
|-
|'''Required modules'''
|Accounting (double entry)
|-
|'''Dolibarr core modification'''
|No
|-
|'''License'''
|GNU GPL v3 or later (with an author attribution term)
|-
|'''Price'''
|Free
|-
|'''Available languages'''
|Turkish, English
|}

==Official links==

*Source code and releases: [https://github.com/mbrksntrk/dolibarr-tdhp-mizan GitHub]
*Detailed documentation (Turkish): [https://github.com/mbrksntrk/dolibarr-tdhp-mizan/wiki GitHub wiki]

==Main features==

*'''Hierarchical roll-up''': movements of every sub-account are summed up the chart's parent tree to the 3-digit main accounts (100, 102, 120…).
*Debit and credit totals and '''debit / credit balances''' on every level, with a grand total.
*'''Period types''': monthly, date range including or excluding closing entries, monthly main accounts, opening, closing, opening excluded, opening and closing excluded.
*'''Filters''': account range, code prefix, account group (PCG), currency, balance direction, amount condition, search by code or name, show/hide main and sub accounts.
*'''PDF printing''' in the classic Turkish layout: A4, framed title box with period, company name and page "x / y" on every page, repeated column headers, level-based row style, zero amounts blank.
*'''Sayıştay-style CSV''' export (UTF-8 BOM, semicolon separated).
*Configurable debit/credit balance colours on screen.

==Configuration==

From Home → Setup → Modules → TDHP Mizan: debit and credit balance colours. In the chart of accounts, each sub-account must have its parent account set (e.g. 102.10.001 → 102.10 → 102).

==User permissions==

The report is available to administrators and to users with the core permission to read accounting movements.

==Installation==

#Download <code>module_tdhpmizan-x.y.z.zip</code> from GitHub Releases.
#Home → Setup → Modules → '''Deploy/install external app/module''', or unzip into <code>htdocs/custom/</code>.
#Enable the '''Accounting''' module, then '''TDHP Mizan'''.
#Open Accounting → '''TDHP Mizan'''.

==Summary==

TDHP Mizan gives Dolibarr users in Türkiye the familiar hierarchical trial balance — on screen, as a printable PDF and as a Sayıştay-style CSV — using only the standard Dolibarr ledger.

Module TdhpMizan

2026-10-18T15:54:36Z

Eldy:

Module TdhpMizan

2026-10-18T15:54:28Z

Eldy:

Modules - Rules for community modules

2026-10-18T12:54:54Z

Eldy: /* Elligible features and Duplicate rules */

= [[File:Art.png]] Introduction =
This page contains the rules defined for all modules integrated into the community repository.
https://github.com/Dolibarr/dolibarr-community-modules

= New module integration requests / Authority =
The Dolibarr board is the owner of the community repository.

Modules integration requests must be done by doing a Pull Request. The Dolibarr foundation board will merge the first pull request if accepted and if the module is hosted on the repository itlsef, will grant the permission to merge Pull Request to the initial author of the module so he can assume its responsability of merging following Pull Requests as explained into the Maintenance chapter.

The Dolibarr foundation board should decide if a module is integrated or not according to all the following rules...

= Rules =

== Compatibility==
A module added into the community repository can have prerequisites that differs from Dolibarr. So minimum and maximum version of PHP is not necessarly the same as the one of the Dolibarr version the module is compatible with.

== Price ==
A module provided into the Dolibarr community repository must be free (as in speech but also as in beer). There is another source for opensource but non-free (as in beer) modules, so '''commercial modules''', administrated by the Dolibarr foundation, that is [https://www.doliStore.com Dolistore.com].

So modules added on the Community Repository should not be sell on any platform the Dolibarr skateholders have control on, above all on DoliStore (modules may be published on other platform, but for free).

== Maintenance and no barriers to contributions ==
The user(s) that publish initialy the module in the Community repository agrees to analyze, check and approve, on a regular basis, issues or Pull Requests related to its module. We called this user(s) as the MAINTAINER(S). Issues and Pull Requests on project can be submited by everybody, we called them the CONTRIBUTORS.

The name and github account of the maintainers (better if there is 2 or more persons per module) will be mentioned in the file MAINTAINERS (in the root of the project). The Dolibarr foundation will grant them permission to merge pull requests and manage issues. The maintainers agree to not validate Pull Request that is not related to files inside their directory module (in a future a check may be done automatically to avoid errors).
Maintainers of a module are allowed to commit directly files of their modules directory.

Note:
* When an issue is pushed in the community module, a combo list with module name is mandatory into the ticket, so the maintainers can see and filters issues related to their and only their module.
* When a PR is pushed in the community module, a CI action automatically adds a tag with the name of the module, so the maintainers can see and filters Pull Requests related to their and only their module.

The reference of all the sources and issues of the module must be the community repo. Any hosting onto another external source repository must be a mirroring only. This guarantee that the following needs for a community modules will always be met:

* Getting sources with a simple "git clone" with no need to create any account must be possible, for exemple using the "git clone" command with the http url of the repository.

* Contributing to sources must be as easy as doing a Pull or Merge Request. Registration of a user account for this on the source control platform should not request personal information (except a login, email, firstname and lastname). Registration process should also be fully automatic (so contributors can register any day at any hour and push its Pull Request few seconds after). The Dolibarr foundation keep control on the source control platform to be able to switch to another one at any time.

* Building a zip of the module and hosting the zip file in the repository become possible and easy to do, automatically, so the module can be searched and installed directly from Dolibarr application.

== Code ==
Modules must follow the same quality and coding rules than the Dolibarr project (See [[Language_and_development_rules]]), except the '''minimal and maximal PHP version''' (See chapter "Compatibility") that can be diffrent than the Dolibarr official range.

Modules are allowed to be compatible with a limited list of Dolibarr versions.

Of course, the licence of the module, as a derivative work of Dolibarr that is licensed under GPL v3+, should use the GPL license or any OSI license compatible with GPL v3+.

== Attribution and authors ==
Source files of module can (should) contains name, email of each author, however, the module should not contain any mention to the company at any other places, except into source files header or some text files (like README, COPYRIGHT, ...) or the "About page" of the module (in setup section). If a mention of the initial authoring company is made, the mention to refer to other authors must also be added with a mention "... and the Dolibarr community". Name, email and company name of authors can be mentionned inside source files but on the "About page" visible by end user, we can have one and only one mention of the initial authoring company. We can have several links to it if they link to external pages related to documentation of the module , demo or resources.

== Elligible features and Duplicate rules ==
* Features of a community module must NOT:
** provide a feature too similar to a Dolibarr existing feature. If the module just complete a Dolibarr official existing feature, it is better to try to submit a PR to enhance the official existing feature.
** be a feature for a niche market. In such a case, providing an external module, hosted on your own forge, and published on DoliStore.com is a better choice.

* A community module MUST offer a feature that is interesting for a lot of users of a given country and bring a real added-value, related to at least one of this point:
** Sovereignty or emancipation from the GAFAM
** Legal requirement
** Interface with an external system too complex to maintain in the core.
** Cyber security (safety related to accidents or IT disaster are not part, risk management is not involved either).

* Finally, we must answer the question: What is impact if suddenly the module become not availablefor end users that started to use it ? Is it a big trouble for end users or not ? If not (can be replaced easily), module is not elligible.

Note: If a can provide the same features than another Community module, the Dolibarr foundation board will decide which one to keep and which one to remove on a case per case basis, so only one module will remain for the same feature.

= Responsability of the Dolibarr foundation =
If some rules are not met,for example, if the pendings PRs are not correctly followed by the maintener (not merged and no answer), the Dolibarr foundation can revoke the permissions of the mainteners and grant then to other mainteners.

The Dolibarr foundation can also decide to remove a community module from the repository at any time for other reasons, for example:
* Module is deprecated
* CI return bad quality indicators on code
* Too many security vulnerabilities reported and not fixed
* ...

The Dolibarr foundation decision about min and max version of Dolibarr or PHP supported by a module has priority on the choice of the maintener.

= Version and validation of these rules =

More rules will be added in future, the community repository is not a commercial repository and list of modules will be restricted to few modules only.

History of all changes on this rules can be found using the tab "See historic" when logged on this wiki (creation of account is free).

Version validated by the Dolibarr foundation the 24th of march 2026, clarified on july 2026.

Modules - Rules for community modules

2026-10-18T12:51:08Z

Eldy: /* Elligible features and Duplicate rules */

= [[File:Art.png]] Introduction =
This page contains the rules defined for all modules integrated into the community repository.
https://github.com/Dolibarr/dolibarr-community-modules

= New module integration requests / Authority =
The Dolibarr board is the owner of the community repository.

Modules integration requests must be done by doing a Pull Request. The Dolibarr foundation board will merge the first pull request if accepted and if the module is hosted on the repository itlsef, will grant the permission to merge Pull Request to the initial author of the module so he can assume its responsability of merging following Pull Requests as explained into the Maintenance chapter.

The Dolibarr foundation board should decide if a module is integrated or not according to all the following rules...

= Rules =

== Compatibility==
A module added into the community repository can have prerequisites that differs from Dolibarr. So minimum and maximum version of PHP is not necessarly the same as the one of the Dolibarr version the module is compatible with.

== Price ==
A module provided into the Dolibarr community repository must be free (as in speech but also as in beer). There is another source for opensource but non-free (as in beer) modules, so '''commercial modules''', administrated by the Dolibarr foundation, that is [https://www.doliStore.com Dolistore.com].

So modules added on the Community Repository should not be sell on any platform the Dolibarr skateholders have control on, above all on DoliStore (modules may be published on other platform, but for free).

== Maintenance and no barriers to contributions ==
The user(s) that publish initialy the module in the Community repository agrees to analyze, check and approve, on a regular basis, issues or Pull Requests related to its module. We called this user(s) as the MAINTAINER(S). Issues and Pull Requests on project can be submited by everybody, we called them the CONTRIBUTORS.

The name and github account of the maintainers (better if there is 2 or more persons per module) will be mentioned in the file MAINTAINERS (in the root of the project). The Dolibarr foundation will grant them permission to merge pull requests and manage issues. The maintainers agree to not validate Pull Request that is not related to files inside their directory module (in a future a check may be done automatically to avoid errors).
Maintainers of a module are allowed to commit directly files of their modules directory.

Note:
* When an issue is pushed in the community module, a combo list with module name is mandatory into the ticket, so the maintainers can see and filters issues related to their and only their module.
* When a PR is pushed in the community module, a CI action automatically adds a tag with the name of the module, so the maintainers can see and filters Pull Requests related to their and only their module.

The reference of all the sources and issues of the module must be the community repo. Any hosting onto another external source repository must be a mirroring only. This guarantee that the following needs for a community modules will always be met:

* Getting sources with a simple "git clone" with no need to create any account must be possible, for exemple using the "git clone" command with the http url of the repository.

* Contributing to sources must be as easy as doing a Pull or Merge Request. Registration of a user account for this on the source control platform should not request personal information (except a login, email, firstname and lastname). Registration process should also be fully automatic (so contributors can register any day at any hour and push its Pull Request few seconds after). The Dolibarr foundation keep control on the source control platform to be able to switch to another one at any time.

* Building a zip of the module and hosting the zip file in the repository become possible and easy to do, automatically, so the module can be searched and installed directly from Dolibarr application.

== Code ==
Modules must follow the same quality and coding rules than the Dolibarr project (See [[Language_and_development_rules]]), except the '''minimal and maximal PHP version''' (See chapter "Compatibility") that can be diffrent than the Dolibarr official range.

Modules are allowed to be compatible with a limited list of Dolibarr versions.

Of course, the licence of the module, as a derivative work of Dolibarr that is licensed under GPL v3+, should use the GPL license or any OSI license compatible with GPL v3+.

== Attribution and authors ==
Source files of module can (should) contains name, email of each author, however, the module should not contain any mention to the company at any other places, except into source files header or some text files (like README, COPYRIGHT, ...) or the "About page" of the module (in setup section). If a mention of the initial authoring company is made, the mention to refer to other authors must also be added with a mention "... and the Dolibarr community". Name, email and company name of authors can be mentionned inside source files but on the "About page" visible by end user, we can have one and only one mention of the initial authoring company. We can have several links to it if they link to external pages related to documentation of the module , demo or resources.

== Elligible features and Duplicate rules ==
* Features of a community module must NOT:
** provide a feature too similar to a Dolibarr existing feature. If the module just complete a Dolibarr official existing feature, it is better to try to submit a PR to enhance the official existing feature.
** be a feature for a niche market. In such a case, providing an external module, hosted on your own forge, and published on DoliStore.com is a better choice.

* A community module MUST offer a feature that is interesting for a lot of users of a given country and bring a real added-value, related to at least one of this point:
** Sovereignty or emancipation from the GAFAM
** Legal requirement
** Interface with an external system too complex to maintain in the core.
** Cyber security (safety related to accidents or IT disaster are not part, risk management is not involved either).

* Finally, we must answer the question: What is impact if suddenly the module become not available ? Is it a big trouble for end users or not ? If not (can be replaced easily), module is not elligible.

Note: If a can provide the same features than another Community module, the Dolibarr foundation board will decide which one to keep and which one to remove on a case per case basis, so only one module will remain for the same feature.

= Responsability of the Dolibarr foundation =
If some rules are not met,for example, if the pendings PRs are not correctly followed by the maintener (not merged and no answer), the Dolibarr foundation can revoke the permissions of the mainteners and grant then to other mainteners.

The Dolibarr foundation can also decide to remove a community module from the repository at any time for other reasons, for example:
* Module is deprecated
* CI return bad quality indicators on code
* Too many security vulnerabilities reported and not fixed
* ...

The Dolibarr foundation decision about min and max version of Dolibarr or PHP supported by a module has priority on the choice of the maintener.

= Version and validation of these rules =

More rules will be added in future, the community repository is not a commercial repository and list of modules will be restricted to few modules only.

History of all changes on this rules can be found using the tab "See historic" when logged on this wiki (creation of account is free).

Version validated by the Dolibarr foundation the 24th of march 2026, clarified on july 2026.

Modules - Rules for community modules

2026-10-18T12:47:14Z

Eldy: /* Elligible features and Duplicate rules */

= [[File:Art.png]] Introduction =
This page contains the rules defined for all modules integrated into the community repository.
https://github.com/Dolibarr/dolibarr-community-modules

= New module integration requests / Authority =
The Dolibarr board is the owner of the community repository.

Modules integration requests must be done by doing a Pull Request. The Dolibarr foundation board will merge the first pull request if accepted and if the module is hosted on the repository itlsef, will grant the permission to merge Pull Request to the initial author of the module so he can assume its responsability of merging following Pull Requests as explained into the Maintenance chapter.

The Dolibarr foundation board should decide if a module is integrated or not according to all the following rules...

= Rules =

== Compatibility==
A module added into the community repository can have prerequisites that differs from Dolibarr. So minimum and maximum version of PHP is not necessarly the same as the one of the Dolibarr version the module is compatible with.

== Price ==
A module provided into the Dolibarr community repository must be free (as in speech but also as in beer). There is another source for opensource but non-free (as in beer) modules, so '''commercial modules''', administrated by the Dolibarr foundation, that is [https://www.doliStore.com Dolistore.com].

So modules added on the Community Repository should not be sell on any platform the Dolibarr skateholders have control on, above all on DoliStore (modules may be published on other platform, but for free).

== Maintenance and no barriers to contributions ==
The user(s) that publish initialy the module in the Community repository agrees to analyze, check and approve, on a regular basis, issues or Pull Requests related to its module. We called this user(s) as the MAINTAINER(S). Issues and Pull Requests on project can be submited by everybody, we called them the CONTRIBUTORS.

The name and github account of the maintainers (better if there is 2 or more persons per module) will be mentioned in the file MAINTAINERS (in the root of the project). The Dolibarr foundation will grant them permission to merge pull requests and manage issues. The maintainers agree to not validate Pull Request that is not related to files inside their directory module (in a future a check may be done automatically to avoid errors).
Maintainers of a module are allowed to commit directly files of their modules directory.

Note:
* When an issue is pushed in the community module, a combo list with module name is mandatory into the ticket, so the maintainers can see and filters issues related to their and only their module.
* When a PR is pushed in the community module, a CI action automatically adds a tag with the name of the module, so the maintainers can see and filters Pull Requests related to their and only their module.

The reference of all the sources and issues of the module must be the community repo. Any hosting onto another external source repository must be a mirroring only. This guarantee that the following needs for a community modules will always be met:

* Getting sources with a simple "git clone" with no need to create any account must be possible, for exemple using the "git clone" command with the http url of the repository.

* Contributing to sources must be as easy as doing a Pull or Merge Request. Registration of a user account for this on the source control platform should not request personal information (except a login, email, firstname and lastname). Registration process should also be fully automatic (so contributors can register any day at any hour and push its Pull Request few seconds after). The Dolibarr foundation keep control on the source control platform to be able to switch to another one at any time.

* Building a zip of the module and hosting the zip file in the repository become possible and easy to do, automatically, so the module can be searched and installed directly from Dolibarr application.

== Code ==
Modules must follow the same quality and coding rules than the Dolibarr project (See [[Language_and_development_rules]]), except the '''minimal and maximal PHP version''' (See chapter "Compatibility") that can be diffrent than the Dolibarr official range.

Modules are allowed to be compatible with a limited list of Dolibarr versions.

Of course, the licence of the module, as a derivative work of Dolibarr that is licensed under GPL v3+, should use the GPL license or any OSI license compatible with GPL v3+.

== Attribution and authors ==
Source files of module can (should) contains name, email of each author, however, the module should not contain any mention to the company at any other places, except into source files header or some text files (like README, COPYRIGHT, ...) or the "About page" of the module (in setup section). If a mention of the initial authoring company is made, the mention to refer to other authors must also be added with a mention "... and the Dolibarr community". Name, email and company name of authors can be mentionned inside source files but on the "About page" visible by end user, we can have one and only one mention of the initial authoring company. We can have several links to it if they link to external pages related to documentation of the module , demo or resources.

== Elligible features and Duplicate rules ==
* Features of a community module must NOT:
** provide a feature too similar to a Dolibarr existing feature. If the module just complete a Dolibarr official existing feature, it is better to try to submit a PR to enhance the official existing feature.
** be a feature for a niche market. In such a case, providing an external module, hosted on your own forge, and published on DoliStore.com is a better choice.

* A community module MUST offer a feature that is interesting for a lot of users of a given country and bring a real added-value, related to at least one of this point:
** Sustainability
** Sovereignty or emancipation from the GAFAM
** Legal requirement
** Interface with an external system too complex to maintain in the core.

* Finally, we must answer the question: What is impact if suddenly the module become not available ? Is it a big trouble for end users or not ? If not (can be replaced easily), module is not elligible.

Note: If a can provide the same features than another Community module, the Dolibarr foundation board will decide which one to keep and which one to remove on a case per case basis, so only one module will remain for the same feature.

= Responsability of the Dolibarr foundation =
If some rules are not met,for example, if the pendings PRs are not correctly followed by the maintener (not merged and no answer), the Dolibarr foundation can revoke the permissions of the mainteners and grant then to other mainteners.

The Dolibarr foundation can also decide to remove a community module from the repository at any time for other reasons, for example:
* Module is deprecated
* CI return bad quality indicators on code
* Too many security vulnerabilities reported and not fixed
* ...

The Dolibarr foundation decision about min and max version of Dolibarr or PHP supported by a module has priority on the choice of the maintener.

= Version and validation of these rules =

More rules will be added in future, the community repository is not a commercial repository and list of modules will be restricted to few modules only.

History of all changes on this rules can be found using the tab "See historic" when logged on this wiki (creation of account is free).

Version validated by the Dolibarr foundation the 24th of march 2026, clarified on july 2026.

Modules - Rules for community modules

2026-10-18T12:42:57Z

Eldy: /* Elligible features and Duplicate rules */

= [[File:Art.png]] Introduction =
This page contains the rules defined for all modules integrated into the community repository.
https://github.com/Dolibarr/dolibarr-community-modules

= New module integration requests / Authority =
The Dolibarr board is the owner of the community repository.

Modules integration requests must be done by doing a Pull Request. The Dolibarr foundation board will merge the first pull request if accepted and if the module is hosted on the repository itlsef, will grant the permission to merge Pull Request to the initial author of the module so he can assume its responsability of merging following Pull Requests as explained into the Maintenance chapter.

The Dolibarr foundation board should decide if a module is integrated or not according to all the following rules...

= Rules =

== Compatibility==
A module added into the community repository can have prerequisites that differs from Dolibarr. So minimum and maximum version of PHP is not necessarly the same as the one of the Dolibarr version the module is compatible with.

== Price ==
A module provided into the Dolibarr community repository must be free (as in speech but also as in beer). There is another source for opensource but non-free (as in beer) modules, so '''commercial modules''', administrated by the Dolibarr foundation, that is [https://www.doliStore.com Dolistore.com].

So modules added on the Community Repository should not be sell on any platform the Dolibarr skateholders have control on, above all on DoliStore (modules may be published on other platform, but for free).

== Maintenance and no barriers to contributions ==
The user(s) that publish initialy the module in the Community repository agrees to analyze, check and approve, on a regular basis, issues or Pull Requests related to its module. We called this user(s) as the MAINTAINER(S). Issues and Pull Requests on project can be submited by everybody, we called them the CONTRIBUTORS.

The name and github account of the maintainers (better if there is 2 or more persons per module) will be mentioned in the file MAINTAINERS (in the root of the project). The Dolibarr foundation will grant them permission to merge pull requests and manage issues. The maintainers agree to not validate Pull Request that is not related to files inside their directory module (in a future a check may be done automatically to avoid errors).
Maintainers of a module are allowed to commit directly files of their modules directory.

Note:
* When an issue is pushed in the community module, a combo list with module name is mandatory into the ticket, so the maintainers can see and filters issues related to their and only their module.
* When a PR is pushed in the community module, a CI action automatically adds a tag with the name of the module, so the maintainers can see and filters Pull Requests related to their and only their module.

The reference of all the sources and issues of the module must be the community repo. Any hosting onto another external source repository must be a mirroring only. This guarantee that the following needs for a community modules will always be met:

* Getting sources with a simple "git clone" with no need to create any account must be possible, for exemple using the "git clone" command with the http url of the repository.

* Contributing to sources must be as easy as doing a Pull or Merge Request. Registration of a user account for this on the source control platform should not request personal information (except a login, email, firstname and lastname). Registration process should also be fully automatic (so contributors can register any day at any hour and push its Pull Request few seconds after). The Dolibarr foundation keep control on the source control platform to be able to switch to another one at any time.

* Building a zip of the module and hosting the zip file in the repository become possible and easy to do, automatically, so the module can be searched and installed directly from Dolibarr application.

== Code ==
Modules must follow the same quality and coding rules than the Dolibarr project (See [[Language_and_development_rules]]), except the '''minimal and maximal PHP version''' (See chapter "Compatibility") that can be diffrent than the Dolibarr official range.

Modules are allowed to be compatible with a limited list of Dolibarr versions.

Of course, the licence of the module, as a derivative work of Dolibarr that is licensed under GPL v3+, should use the GPL license or any OSI license compatible with GPL v3+.

== Attribution and authors ==
Source files of module can (should) contains name, email of each author, however, the module should not contain any mention to the company at any other places, except into source files header or some text files (like README, COPYRIGHT, ...) or the "About page" of the module (in setup section). If a mention of the initial authoring company is made, the mention to refer to other authors must also be added with a mention "... and the Dolibarr community". Name, email and company name of authors can be mentionned inside source files but on the "About page" visible by end user, we can have one and only one mention of the initial authoring company. We can have several links to it if they link to external pages related to documentation of the module , demo or resources.

== Elligible features and Duplicate rules ==
* Features of a community module must NOT:
** provide a feature too similar to a Dolibarr existing feature. If the module just complete a Dolibarr official existing feature, it is better to try to submit a PR to enhance the official existing feature.
** be a feature for a niche market. In such a case, providing an external module, hosted on your own forge, and published on DoliStore.com is a better choice.

* A community module MUST offer a feature that is interesting for a lot of users of a given country and bring a real added-value, related to at least one of this point:
** Sustainability
** Sovereignty
** Legal requirement
** Interface with an external system too complex to maintain in the core.

* Finally, we must answer the question: What is impact if suddenly the module become not available ? Is it a big trouble for end users or not ? If not (can be replaced easily), module is not elligible.

Note: If a can provide the same features than another Community module, the Dolibarr foundation board will decide which one to keep and which one to remove on a case per case basis, so only one module will remain for the same feature.

= Responsability of the Dolibarr foundation =
If some rules are not met,for example, if the pendings PRs are not correctly followed by the maintener (not merged and no answer), the Dolibarr foundation can revoke the permissions of the mainteners and grant then to other mainteners.

The Dolibarr foundation can also decide to remove a community module from the repository at any time for other reasons, for example:
* Module is deprecated
* CI return bad quality indicators on code
* Too many security vulnerabilities reported and not fixed
* ...

The Dolibarr foundation decision about min and max version of Dolibarr or PHP supported by a module has priority on the choice of the maintener.

= Version and validation of these rules =

More rules will be added in future, the community repository is not a commercial repository and list of modules will be restricted to few modules only.

History of all changes on this rules can be found using the tab "See historic" when logged on this wiki (creation of account is free).

Version validated by the Dolibarr foundation the 24th of march 2026, clarified on july 2026.

Modules - Rules for community modules

2026-10-18T12:40:47Z

Eldy: /* Elligible features and Duplicate rules */

= [[File:Art.png]] Introduction =
This page contains the rules defined for all modules integrated into the community repository.
https://github.com/Dolibarr/dolibarr-community-modules

= New module integration requests / Authority =
The Dolibarr board is the owner of the community repository.

Modules integration requests must be done by doing a Pull Request. The Dolibarr foundation board will merge the first pull request if accepted and if the module is hosted on the repository itlsef, will grant the permission to merge Pull Request to the initial author of the module so he can assume its responsability of merging following Pull Requests as explained into the Maintenance chapter.

The Dolibarr foundation board should decide if a module is integrated or not according to all the following rules...

= Rules =

== Compatibility==
A module added into the community repository can have prerequisites that differs from Dolibarr. So minimum and maximum version of PHP is not necessarly the same as the one of the Dolibarr version the module is compatible with.

== Price ==
A module provided into the Dolibarr community repository must be free (as in speech but also as in beer). There is another source for opensource but non-free (as in beer) modules, so '''commercial modules''', administrated by the Dolibarr foundation, that is [https://www.doliStore.com Dolistore.com].

So modules added on the Community Repository should not be sell on any platform the Dolibarr skateholders have control on, above all on DoliStore (modules may be published on other platform, but for free).

== Maintenance and no barriers to contributions ==
The user(s) that publish initialy the module in the Community repository agrees to analyze, check and approve, on a regular basis, issues or Pull Requests related to its module. We called this user(s) as the MAINTAINER(S). Issues and Pull Requests on project can be submited by everybody, we called them the CONTRIBUTORS.

The name and github account of the maintainers (better if there is 2 or more persons per module) will be mentioned in the file MAINTAINERS (in the root of the project). The Dolibarr foundation will grant them permission to merge pull requests and manage issues. The maintainers agree to not validate Pull Request that is not related to files inside their directory module (in a future a check may be done automatically to avoid errors).
Maintainers of a module are allowed to commit directly files of their modules directory.

Note:
* When an issue is pushed in the community module, a combo list with module name is mandatory into the ticket, so the maintainers can see and filters issues related to their and only their module.
* When a PR is pushed in the community module, a CI action automatically adds a tag with the name of the module, so the maintainers can see and filters Pull Requests related to their and only their module.

The reference of all the sources and issues of the module must be the community repo. Any hosting onto another external source repository must be a mirroring only. This guarantee that the following needs for a community modules will always be met:

* Getting sources with a simple "git clone" with no need to create any account must be possible, for exemple using the "git clone" command with the http url of the repository.

* Contributing to sources must be as easy as doing a Pull or Merge Request. Registration of a user account for this on the source control platform should not request personal information (except a login, email, firstname and lastname). Registration process should also be fully automatic (so contributors can register any day at any hour and push its Pull Request few seconds after). The Dolibarr foundation keep control on the source control platform to be able to switch to another one at any time.

* Building a zip of the module and hosting the zip file in the repository become possible and easy to do, automatically, so the module can be searched and installed directly from Dolibarr application.

== Code ==
Modules must follow the same quality and coding rules than the Dolibarr project (See [[Language_and_development_rules]]), except the '''minimal and maximal PHP version''' (See chapter "Compatibility") that can be diffrent than the Dolibarr official range.

Modules are allowed to be compatible with a limited list of Dolibarr versions.

Of course, the licence of the module, as a derivative work of Dolibarr that is licensed under GPL v3+, should use the GPL license or any OSI license compatible with GPL v3+.

== Attribution and authors ==
Source files of module can (should) contains name, email of each author, however, the module should not contain any mention to the company at any other places, except into source files header or some text files (like README, COPYRIGHT, ...) or the "About page" of the module (in setup section). If a mention of the initial authoring company is made, the mention to refer to other authors must also be added with a mention "... and the Dolibarr community". Name, email and company name of authors can be mentionned inside source files but on the "About page" visible by end user, we can have one and only one mention of the initial authoring company. We can have several links to it if they link to external pages related to documentation of the module , demo or resources.

== Elligible features and Duplicate rules ==
* Features of a community module must NOT:
[] provide a feature too similar to a Dolibarr existing feature. If the module just complete a Dolibarr official existing feature, it is better to try to submit a PR to enhance the official existing feature.
[] be a feature for a niche market. In such a case, providing an external module, hosted on your own forge, and published on DoliStore.com is a better choice.

* A community module MUST offer a feature that is interesting for a lot of users of a given country and bring a real added-value, related to at least one of this point:
** Sustainability
** Sovereignty
** Legal requirement
** Interface with an external system too complex to maintain in the core.

* If a can provide the same features than another Community module, the Dolibarr foundation board will decide which one to keep and which one to remove on a case per case basis, so only one module will remain for the same feature.

= Responsability of the Dolibarr foundation =
If some rules are not met,for example, if the pendings PRs are not correctly followed by the maintener (not merged and no answer), the Dolibarr foundation can revoke the permissions of the mainteners and grant then to other mainteners.

The Dolibarr foundation can also decide to remove a community module from the repository at any time for other reasons, for example:
* Module is deprecated
* CI return bad quality indicators on code
* Too many security vulnerabilities reported and not fixed
* ...

The Dolibarr foundation decision about min and max version of Dolibarr or PHP supported by a module has priority on the choice of the maintener.

= Version and validation of these rules =

More rules will be added in future, the community repository is not a commercial repository and list of modules will be restricted to few modules only.

History of all changes on this rules can be found using the tab "See historic" when logged on this wiki (creation of account is free).

Version validated by the Dolibarr foundation the 24th of march 2026, clarified on july 2026.

Modules - Rules for community modules

2026-10-18T12:37:54Z

Eldy: /* Elligible features and Duplicate rules */

= [[File:Art.png]] Introduction =
This page contains the rules defined for all modules integrated into the community repository.
https://github.com/Dolibarr/dolibarr-community-modules

= New module integration requests / Authority =
The Dolibarr board is the owner of the community repository.

Modules integration requests must be done by doing a Pull Request. The Dolibarr foundation board will merge the first pull request if accepted and if the module is hosted on the repository itlsef, will grant the permission to merge Pull Request to the initial author of the module so he can assume its responsability of merging following Pull Requests as explained into the Maintenance chapter.

The Dolibarr foundation board should decide if a module is integrated or not according to all the following rules...

= Rules =

== Compatibility==
A module added into the community repository can have prerequisites that differs from Dolibarr. So minimum and maximum version of PHP is not necessarly the same as the one of the Dolibarr version the module is compatible with.

== Price ==
A module provided into the Dolibarr community repository must be free (as in speech but also as in beer). There is another source for opensource but non-free (as in beer) modules, so '''commercial modules''', administrated by the Dolibarr foundation, that is [https://www.doliStore.com Dolistore.com].

So modules added on the Community Repository should not be sell on any platform the Dolibarr skateholders have control on, above all on DoliStore (modules may be published on other platform, but for free).

== Maintenance and no barriers to contributions ==
The user(s) that publish initialy the module in the Community repository agrees to analyze, check and approve, on a regular basis, issues or Pull Requests related to its module. We called this user(s) as the MAINTAINER(S). Issues and Pull Requests on project can be submited by everybody, we called them the CONTRIBUTORS.

The name and github account of the maintainers (better if there is 2 or more persons per module) will be mentioned in the file MAINTAINERS (in the root of the project). The Dolibarr foundation will grant them permission to merge pull requests and manage issues. The maintainers agree to not validate Pull Request that is not related to files inside their directory module (in a future a check may be done automatically to avoid errors).
Maintainers of a module are allowed to commit directly files of their modules directory.

Note:
* When an issue is pushed in the community module, a combo list with module name is mandatory into the ticket, so the maintainers can see and filters issues related to their and only their module.
* When a PR is pushed in the community module, a CI action automatically adds a tag with the name of the module, so the maintainers can see and filters Pull Requests related to their and only their module.

The reference of all the sources and issues of the module must be the community repo. Any hosting onto another external source repository must be a mirroring only. This guarantee that the following needs for a community modules will always be met:

* Getting sources with a simple "git clone" with no need to create any account must be possible, for exemple using the "git clone" command with the http url of the repository.

* Contributing to sources must be as easy as doing a Pull or Merge Request. Registration of a user account for this on the source control platform should not request personal information (except a login, email, firstname and lastname). Registration process should also be fully automatic (so contributors can register any day at any hour and push its Pull Request few seconds after). The Dolibarr foundation keep control on the source control platform to be able to switch to another one at any time.

* Building a zip of the module and hosting the zip file in the repository become possible and easy to do, automatically, so the module can be searched and installed directly from Dolibarr application.

== Code ==
Modules must follow the same quality and coding rules than the Dolibarr project (See [[Language_and_development_rules]]), except the '''minimal and maximal PHP version''' (See chapter "Compatibility") that can be diffrent than the Dolibarr official range.

Modules are allowed to be compatible with a limited list of Dolibarr versions.

Of course, the licence of the module, as a derivative work of Dolibarr that is licensed under GPL v3+, should use the GPL license or any OSI license compatible with GPL v3+.

== Attribution and authors ==
Source files of module can (should) contains name, email of each author, however, the module should not contain any mention to the company at any other places, except into source files header or some text files (like README, COPYRIGHT, ...) or the "About page" of the module (in setup section). If a mention of the initial authoring company is made, the mention to refer to other authors must also be added with a mention "... and the Dolibarr community". Name, email and company name of authors can be mentionned inside source files but on the "About page" visible by end user, we can have one and only one mention of the initial authoring company. We can have several links to it if they link to external pages related to documentation of the module , demo or resources.

== Elligible features and Duplicate rules ==
* Features of a community module must NOT:
** provide a feature too similar to a Dolibarr existing feature. If the module just complete a Dolibarr official existing feature, it is better to try to submit a PR to enhance the official existing feature.
** be a feature for a niche market. In such a case, providing an external module, hosted on your own forge, and published on DoliStore.com is a better choice.

* A community module MUST offer a feature that is interesting for a lot of users of a given country and bring a real added-value related to one of this point:
** Sustainability
** Sovereignty
** Legal requirement
** Interface with an external system too complex to maintain in the core.

* If a module provides the same features than another Community module, the Dolibarr foundation board will decide which one to keep and which one to remove on a case per case basis, so only one module will remain for the same feature.

= Responsability of the Dolibarr foundation =
If some rules are not met,for example, if the pendings PRs are not correctly followed by the maintener (not merged and no answer), the Dolibarr foundation can revoke the permissions of the mainteners and grant then to other mainteners.

The Dolibarr foundation can also decide to remove a community module from the repository at any time for other reasons, for example:
* Module is deprecated
* CI return bad quality indicators on code
* Too many security vulnerabilities reported and not fixed
* ...

The Dolibarr foundation decision about min and max version of Dolibarr or PHP supported by a module has priority on the choice of the maintener.

= Version and validation of these rules =

More rules will be added in future, the community repository is not a commercial repository and list of modules will be restricted to few modules only.

History of all changes on this rules can be found using the tab "See historic" when logged on this wiki (creation of account is free).

Version validated by the Dolibarr foundation the 24th of march 2026, clarified on july 2026.

Language and development rules

2026-10-13T02:15:41Z

Eldy: /* Closure or anonymous function */

[[de:Sprachen_und_Programmierregeln]]
[[fr:Langages_et_normes]]
[[es:Lenguaje_y_Normas_de_Desarrollo]]
[[zh:语言和开发规则]]


{{TemplateDocDevEn}}

These are some rules on language, syntax and norm we use in the Dolibarr project:

=Versions=

*Current version of Dolibarr must work on:

#All OS (Windows, Linux, MACOS...)
#PHP {{PHPMinVersion}} (Must work with no need of complementary PHP module, except module to PHP module to access database). See [[List of releases, change log and compatibilities]] for pre-requisites for older versions.
#MySQL {{MySqlMinVersion}}

=Copyright Norms=

*All PHP files must start with a header that looks like

<syntaxhighlight lang="PHP">
<?php
/* Copyright (C) YYYY John Doe <email@email.com>
*
* Licence information
*/
...
</syntaxhighlight>
When you edit an existing file of project, you must add a Copyright line under others.

=PHP Norms=
==PHP==

*Dolibarr is written with PHP and supports all versions of PHP higher than {{PHPMinVersion}}. All files must end with extension .php

*Usage of PHP superglobals variables must use the dedicated operators $_COOKIE, $_SERVER, $_ENV but use the Dolibarr functions [[Fonctions utiles Dolibarr|GETPOST...()]] to get the contents of $_GET or $_POST..

*Other operators ($HTTP_SERVER_GET, ...) are now deprecated in PHP, so they must not be used. Code must work if option '''register_long_arrays''' is set to off. Moreover, the code must work when PHP option '''register_globals''' is off (recommended by PHP). It must also work if the option '''register_globals''' is on (by default on a lot of installations).

*Do not use '''<s>PHP_SELF</s>'''. Use instead '''$_SERVER["PHP_SELF"]'''. Also, Dolibarr framework sanitizes content of $_SERVER["PHP_SELF"] variable (into main.inc.php file, before any business code).

*When several variables must be initialized with the same value, you must use individual declarations (separated by ;)

<syntaxhighlight lang="PHP">
$var1 = 1;
$var2 = 1;
$var3 = 1;
</syntaxhighlight>
instead of
<syntaxhighlight lang="PHP">
$var1 = $var2 = $var3 = 1;
</syntaxhighlight>
which is slower.

 

====Strings====

*Strings must be have variables outside of the quote.

<syntaxhighlight lang="PHP">
print "My text show my ".$variable." !\n";
</syntaxhighlight>

====Closure or anonymous function====
If you new a function, just create a real one (or a method).
Anonymous function are just '''forbidden''' (existing one should be removed), they brings a lot of problem:
* Code readability
* $tihs can create cyclic reference.
* Broken static analytics tools that can't guess type or path of variable
* Unit test more difficult
* AI become crazy
* Coding debug trouble (no name function into stack trace)
* Impact analysis more difficult as the stack trace of code can't be guess easily when function are not named explicitely.
* Memory overload not under control.

====Comments====

*Comments must use the C syntax, ie a double slash for a comment on one line and a slash-star to open a bloc for several lines

<syntaxhighlight lang="PHP">
/* Bloc of comment
*
* End of bloc
*/

$monobjet = new MonObjet($db);
$result=$monobjet->fetch($idobject);

for ($i = 1 , $i < 2 ; $i++) {
// comment on one line
print $i;
}

function myFunction($param1, $param2)
{
// code
}
</syntaxhighlight>

 

*Functions must return a value equal or higher than 0 if successful and strictly lower than 0 if error.

*No dead code (code never used) into Dolibarr core code (code used by external modules only must be included within the external modules).

*Use "include_once" for anything with functions or class definitions in it (like *.class.php and *.lib.php files), use "include" for template-style php with files containing common part of HTML and PHP code (like *.inc.php and *.tpl.php files).

*Coding style to use is the '''PSR-12''' (https://www.php-fig.org/psr/psr-12/). Only rules tagged "MUST" are currently required. So note however the exceptions:
**Length of line: PSR-12 mention we can't go up to 120 characters on same line, this is a soft limit. It is better to have long lines instead of long page with code content that is just data declaration and does not contain any logic. However, we introduced a hard limit of '''1000''' characters (having line larger than this may return errors on Continuous Integration tests).
**Tabs are allowed: The other exception is that we don't replace systematically the tabs with spaces. Using tabs is more convenient for most editors/developers. Also using spaces breaks some auto-format features (like Eclipse autoformat feature on some Eclipse version). For the moment, the best setup is "Keep spaces/tabs as it is", however, you can activate the option "Remove spaces at end of lines".
**We allow elements of an array on same line and we do not always add a new line at end of each element.
**Note 1: The following rule are very important to follow:
***Files must be saved with Unix format (LF) and not Windows (CR/LF). Unix format is compatible on all OS such as Unix like, Windows, Mac, but the Windows text file format may not work on some PHP under Unix.
***Smart tags PHP must not be used. PHP code section must start with '''<?php''' (the "smart tags" <? or <?=, also known as the "short tags", depend on php configuration option '''short_open_tag''', even if this is no more true after php5.4. The use of <? can still have conflict with XML syntax. The smartags may not be supported by all IDE. Also, the use of <?= make easier for a hacker to make PHP injection. To fight this, some Dolibarr components, like the website PHP editor, accepts only full php tags to detect, parse and filter PHP. Finaly, using the same tag everywhere make also easier to make code scanning or impact analysis when we are sure of the tags that is used, and the best solution, to be sure of which tag is used, is to use one, only one and the same tag everywhere.
**Note 2: You can use the file '''dev/setup/codesniffer/ruleset.xml''' as rule file to control coding style with PHPCodeSniffer.
**Note 3: You can use the file '''dev/setup/eclipse/PSR-12 [built-in].xml''' as rule file to setup Eclipse syntax formater.
**Note 4: You may note that current code is not yet compliant with the PSR-12. The reason is that we must "now" follow the "MUST" rules of PSR-12, but it wasn't in the past. So feel free to change coding style to match new rules (keep in mind the 2 exceptions) if you find such cases.

==Classes and properties structures==

Some properties of classes are found in different classes. To avoid having different names, we will use the following PHP properties names:

{{TemplatePHPFields}}

=SQL and Database rules=

==DDL file format==
Files containing definition of the database structure (DDL files) must be '''2 per table''':

*The first file defines the table and its fields. The file name contains the table name, e.g. like this: <tt>llx_''mytable''.sql</tt>

A comment will be added for each field to explain its usage.

*The second file defines all foreign keys, performance indexes or other constraints and the file name will be like: <tt>llx_''mytable''.key.sql</tt>

These files must be stored in the directory '''install/mysql/tables''' for all standard files or '''mymodule/tables''' for tables provided by an external module.

Example: '''file for creating the table llx_mytable will be llx_mytable.sql''':

<syntaxhighlight lang="sql">
-- ===========================================================================
-- Copyright (C) 2013 Author <email@author.com>
--
-- This program is free software; you can redistribute it and/or modify
-- it under the terms of the GNU General Public License as published by
-- the Free Software Foundation; either version 3 of the License, or
-- (at your option) any later version.
--
-- This program is distributed in the hope that it will be useful,
-- but WITHOUT ANY WARRANTY; without even the implied warranty of
-- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-- GNU General Public License for more details.
--
-- You should have received a copy of the GNU General Public License
-- along with this program. If not, see <http://www.gnu.org/licenses/>.
-- ===========================================================================

create table llx_mytable
(
rowid integer NOT NULL AUTO_INCREMENT PRIMARY KEY,
ref varchar(30) NOT NULL, -- object reference number
entity integer DEFAULT 1 NOT NULL, -- multi company id
ref_ext varchar(255),-- reference into an external system (not used by dolibarr)
field_one integer,
field_two integer NOT NULL,
fk_field integer,
field_date datetime,
datec timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,, -- creation datetime
tms timestamp, -- update time stamp
fk_user_author integer NOT NULL, -- Author, foreign key of llx_user
fk_user_mod integer NOT NULL, -- Last updater, foreign key of llx_user
import_key varchar(14) -- Use by import process
)type=innodb;
</syntaxhighlight>

Example: '''file for creating keys/indexes for the table llx_mytable will be llx_mytable.key.sql''':

<syntaxhighlight lang="sql">
-- ===========================================================================
-- Copyright (C) 2013 Author <email@author.com>
--
-- This program is free software; you can redistribute it and/or modify
-- it under the terms of the GNU General Public License as published by
-- the Free Software Foundation; either version 3 of the License, or
-- (at your option) any later version.
--
-- This program is distributed in the hope that it will be useful,
-- but WITHOUT ANY WARRANTY; without even the implied warranty of
-- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-- GNU General Public License for more details.
--
-- You should have received a copy of the GNU General Public License
-- along with this program. If not, see <http://www.gnu.org/licenses/>.
-- ===========================================================================

ALTER TABLE llx_mytable ADD UNIQUE uk_mytable_field (field_one, field_two);

ALTER TABLE llx_mytable ADD CONSTRAINT fk_mytable_fk_field FOREIGN KEY (fk_field) REFERENCES llx_matablepere (rowid);
</syntaxhighlight>

==Table and fields structures==

*Structure of tables.

When you create a new table, it is recommended to use the same conventions as other Dolibarr tables. This means the following fields:
- rowid INTEGER AUTO_INCREMENT PRIMARY KEY that is technical id of record
- entity INTEGER default 1 that is id for the multicompany feature
- date_creation datetime that is the creation date
- tms timestamp that will contain date of last modification (the database manages this field automatically, no need to manage it by the code, just create the field)
- date_valid datetime that is the validation date (if applicable)
- import_key varchar(32) that will contain the import code YYYYMMDDHHMMSS if you make mass import
- status smallint to store a status
Optional
- fk_user_creat or fk_user_author integer that is the id of user making creation
- fk_user_modif integer that is the id of user making change
- fk_user_valid integer that is the id of user validating record (if applicable)
- fk_soc integer that is the ID of the Third party (if applicable)

Note field:
- note_private text for private comment of the object
- note_public text for public comment of the object
or
- note text if there is no need to have private and public

*Type of fields:

To be compatible with any accuracy required by any country on amounts, to be compatible with any database syntax and with the Dolibarr upgrade framework, we will use the following types for database fields:

- integer for a primary key, an integer or any of foreign key (bigint may also be accepted for very large tables)
- smallint for a small number (like for a status) or a boolean
- double(24,8) for any amount
- double(6,3) for any vat rate
- real for a quantity
- varchar for a string (also if length is 1, the type char is more and more deprecated)
- timestamp for a field date+time that is automatically updated
- datetime for a field date+time
- date for a field date
- text or medium text for large fields (no index allowed on such fields)

All business rules must be in the same place, in PHP code, not in the client or the database, that's why type enum is also not allowed.
Other types are not allowed for compatibility reasons.

*All tables have a prefix to avoid name conflicts with other projects. In the current version this prefix is fixed and can't be modified. Its value is <tt>llx_</tt>. In a future version this value should be modified during installation process.

==Primary keys==
The primary key of a table must be called <tt>rowid</tt>.

Some old tables do not use this rule and use a primary key called <tt>id</tt> (e.g. [[Table llx_c_actioncomm]]). The reason is historical and this should not happen anymore.

==Foreign keys==
The name of a foreign key must start with the prefix <tt>fk_</tt> followed by the table name (i.e. name of the referencing table) (this is required to avoid duplicate names in project that are not allowed even if in different tables by some DBMS like Postgresql) then the field name (i.e. name of the referencing field) (this is to allow to have several foreign keys in same table).

Example:
''fk_facture_fourn_fk_soc'' is a foreign key in the table llx_facture_fourn for the field fk_soc in this table (that references the rowid field in another table)

Note when using a foreing key:
- Do not add a hard foreign key (a foreign key controled bydatabase) when the link is not important. This generates more trouble than solution. For exemple, a link to a user table to follow the author of creation of an object is NOT an important link. If parent object,the user, is deleted,the child record will be orphelin but this is not a problem. Record will appear with a cretion author that is "unknown" and that is the truth if we have deleted the parent user.

- If you develop your own external module, it must have no hard foreign keys that point to Dolibarr standard tables. This will break standard dolibarr upgrades, repair, backup and restore tools and may also break standard features. Foreign keys must be soft foreign keys so managed by the code with no database contraints.

==Alternative keys==
Sometimes, we need other unique keys than primary key. When we need this, we can create an alternate unique key. Such a key should have a name that starts with <tt>uk_</tt>, then the table name (this is required to avoid duplicate names of unique keys that may create problems for some DBMS like Postgresql) and then another string to define the key (this is to allow having several unique keys on the same table).

Example:
''uk_societe_code_client'' is a unique key on table llx_societe on field code_client.

==Index performance==
Some fields are often used as search or order criteria, or for joins. In such case, we need to set a performance index on field to increase performances. Such indexes are named with a prefix <tt>idx_</tt> then the table name and then the field name.

Example:
''idx_societe_user_creat'' is a performance index on table llx_societe for field user_creat

==Denormalized field==
Fields that store a data that is result of calculation of other data already stored is a "denormalized field". It must be avoid if we can, and must be used only for performance purpose.
In such a case, to allow developper to understand that the data is not the value that rule, we must prefix the nameof fiel with '''"denormalized_"'''.

For example the field "denormalized_lower_planned_end_date" to store the ending date of the last membership of a member. We already have the information, but doing search or filter on it is difficult as it is stored into another table into another level, so we can duplicate the information into a such field.

If this happen, we must :
* check the any import profile has a function to update the denormalized value during import.
* have a task in the repair.php to recalculate the value and align the data with the original source.
* into the crud method that update any data that impact the field, we must include the update or the denormalized value.

==SQL Coding rules==

*Alias usage/Fields naming

When doing select, we can use alias to simplify writing/reading of requests:
<syntaxhighlight lang="sql">
select chp1, chpxxx2 as chp2 from table2 as t1, table2 as t2 where t1.chpx = t2.chpy
</syntaxhighlight>
However, we must not used alias for update request as they are not compatible with Mysql 3.1.

*Using SELECT * is forbidden ! When using SELECT you must define complete list of fields to get. This avoids confusion. And above all, this make reengeering of code easier and make impact analysis of change on a field possible. Example:

<syntaxhighlight lang="sql">
SELECT field_a, field_b, field_c FROM table_1 WHERE field_d = '$id'
</syntaxhighlight>

*Into SQL requests, you must quote fields except the fields that contain amounts which must be stored as double or real type. Quotes on numbers may result in saving as a different value. For example 412.62 in an insert will be saved as value 412.61999512 into database (due to implicit conversion string to numeric) if the target field has type double(24,8). Only PHP see value 412.61999512. Other tools will see 412.62 letting think that there is no problem. But it's PHP that has the good vision. There is really a wrong value into database. By removing quotes on numbers, no problem occurs.

Example:
<syntaxhighlight lang="sql">
Good: INSERT INTO table_1 (field_txt, field_num) VALUES ('txt', 412.62)
Bad: INSERT INTO table_1 (field_txt, field_num) VALUES ('txt', '412.62')
</syntaxhighlight>

Note, the problem of float numbers is the same on all languages and not only when inserting data into database. It occurs also with any language when you work on "real" numbers, so numbers must be, as soon as they are affected into variable, cleaned with function price2num with second parameter defined to :
'MU' (for unit prices), 'MT' (for total prices) or 'MS' (otherwise) depending on usage of number. (see function documentation)

*SQL Date functions NOW, SYSDATE, DATEDIFF or DATE are forbidden inside SQL requests. Other functions like (MONTH, YEAR) must also be avoided if possible. If you must use the current date into a field, value must come from the PHP and not from the database engine. This is for 3 reasons:
**better portability of code
**better management of TimeZone (reference timezone is the PHP timezone and timezone of database may differs so all dates functions must be on PHP side).
**better performance (see example and final comment)

For example, don't do:
<syntaxhighlight lang="PHP">
$sql="SELECT rowid FROM table where datefield = NOW()";
</syntaxhighlight>
but do:
<syntaxhighlight lang="PHP">
$sql="SELECT rowid FROM table where datefield = '".$this->db->idate(dol_now())."'";
</syntaxhighlight>

For example, don't do:
<syntaxhighlight lang="PHP">
$sql="SELECT rowid FROM table where DATEDIFF(table.datefield, NOW()) > 7";
</syntaxhighlight>
but do:
<syntaxhighlight lang="PHP">
$sql="SELECT rowid FROM table where datefield < '".$this->db->idate(dol_now() - (7 * 24 * 3600))."'";
</syntaxhighlight>

An other advantage of this rule, is that request benefits of index because we are making a compare of a field with a fixed value. When using datediff, you make an operation on field before comparison, this means database can't use the index on field, resulting on very bad performance compared to solution without the datediff.

*The statement WITH ROLLUP is prohibited:

This statement should not be used: it is not handled the same way by different databases.
Also, using WITH ROLLUP breaks the purity of the returned data. The intermediate subtotal generation aggregation performed by this statement can easily be done using PHP and helps keep the returned data array clean (not corrupted by artificially inserted data).

*The sql function GROUP_CONCAT can't be used. It is not portable and ask the database to make subrequests for line into main table, this can be done easier by doing a subrequest inside the PHP loop when building the output of each line.

*Use $db->ifsql for SQL IF

Do not include the IF into your forged SQL request. But use instead $db->ifsql() method to you will make a SQL IF that is compatible with all SQL databases.

*No DELETE CASCADE and ON UPDATE CASCADE

Such SQL instructions are forbidden because they bypass the business rules of the application bringing a lot of troubles out of control of the developers. For example, if there is a delete cascade between table A and B, when the application will execute the code to remove a record in A, the children into table B will also be removed (this is the goal). But if there was a Dolibarr PHP trigger (for example provided by an external module) on the deletion of record of B (for example to validate the deletion or to execute a complementary action), the DELETE CASCADE will be executed without having the Dolibarr PHP trigger on B deletion executed, missing the validation or actions of the PHP trigger of the module. All business rules must be implemented on the same side (so the server PHP side), this is the reason why business rules implemented on Database side (like with delete cascade) are not allowed (same conclusion than the next point about Database triggers).
Note that an external module can use them for links between Dolibarr tables and its module tables but a better recommended solution is to use the trigger to implement the deletion of its tables when a record of a parent official table is deleted.

==Using Database triggers / stored procedures==
Using Database triggers is not allowed into the code of Dolibarr, so you should have no troubles with Database triggers.

*Database triggers are not portable. Compatibility may be broken when upgrading your version of your database
*Database triggers are often forgotten into backup tools
*Database triggers need special permissions that you may not have (and should not have) on a common secured database
*Database triggers means also that you include some "business rules" of your application into the database where most other rules are managed by the code itself (this can create conflict or code that can't be debugged with a step by step debugger)
*Database triggers execute code using the timezone, the default language of the database instead of the reference timezone of the application that may be different (generating offset into database) and the default language setup in application ...
*There is tons of other reasons why we do not recommend to use database triggers in your own development.

Using Database triggers can save you time when you make development but is a very bad practice when quality, portability, security and sustainability are priority, so it is forbidden as it is not compatible with the high level of quality of code expected by Dolibarr team. External modules that uses Database triggers may also be refused on the market place since it won't work for more than 50% of users.

==Basic Migration Rules==

*Structure migration scripts are files of the type '''install/mysql/migration/a.b.c-x.y.z.sql'''. In a migration file from version n to n+1, a table that is no longer used in n+1 is only dropped (DROP TABLE) during the migration from version n+1 to n+2. This is to ensure that obsolete tables are always kept for the duration of a version to correct any issues in case of a migration error.

==MySQL-MariaDB specificity==

*Tables must be declared with format InnoDB.

This format supports foreign keys and their restrictions, and transactions integrity is also supported. This guarantees that Dolibarr events keep all data with correct values between tables even when transaction modify different tables.

*Dolibarr MUST work even if MySQL option '''strict''' is active.

To activate it (required when developing on Dolibarr), add the following line into the config file of your MySQL server (my.cnf or my.ini)
{{MySqlStrictMode}}

==PostgreSQL specificities==
Only MySQL files must be maintained.
Those files are converted "on the fly" by the database Dolibarr driver into the targeted database system.

There is an exception for the SQL "UPDATE FROM" of Postgres:

MySQL Syntax:
<syntaxhighlight lang="sql">
UPDATE table_target as target, table_source as source SET fieldtarget=source.fieldsource
WHERE source.rowid=target.rowid;
</syntaxhighlight>

PgSQL Syntax:
<syntaxhighlight lang="sql">
UPDATE table_target as target SET fieldtarget=source.fieldsource
FROM table_source as source WHERE source.rowid=target.rowid;
</syntaxhighlight>

There is no native SQL requests "UPDATE FROM" in all Dolibarr core (only simple "UPDATE") so this difference of syntax is not a problem. But if you need to use one in your own code of your module, you should do :
<syntaxhighlight lang="PHP">
if ($this->db->type=='pgsql') {
$sql="UPDATE table_target as target SET fieldtarget=source.fieldsource
FROM table_source as source WHERE source.rowid=target.rowid";
} else {
$sql= "UPDATE table_target as target, table_source as source SET fieldtarget=source.fieldsource
WHERE source.rowid=target.rowid";
}
</syntaxhighlight>

=HTML norms=
==Syntax rules==

*HTML used must be HTML compliant and not XHTML. All attributes of HTML tags must be in lower case and quoted with ".

*Links href must be absolute and use the function dol_buildpath() to get absolute path from a relative path and img tag must be build using function img_picto().

For example:
<syntaxhighlight lang="PHP">
print '<a href="'.dol_buildpath('/mydir/mypage.php').'">'.img_picto('Texte alt','namepictopng','').'</a>';''
</syntaxhighlight>

*HTML tables must have columns with no forced width, except for columns that contains data we know the length. For example, a column with a picto only can be forced to with="20px".

Otherwise, we must avoid forcing the column width. Reason is that, in most cases, the browser make a better works to define column width automatically than forced values, and it works whatever is the resolution.

*Javascript/ajax code and call to javascript files into php pages must be avoided. However, if you need to include javascript code, you must add a condition on "$conf->use_javascript_ajax"

<syntaxhighlight lang="PHP">
if ($conf->use_javascript_ajax) {
... // php code generating javascript here
}
</syntaxhighlight>

*Popup windows must not be used, except for tooltips (and must have a condition as explained before).

*External scripts must be written in Perl if they can't be written in PHP. Usage of another language is not forbidden but must be argued before in the development mailing-list.

==External template framework ?==
There is ton of frameworks to provide a template language of an HTML page (smarty, twig, ...). The best and faster one we know is just called "PHP", and because Dolibarr already depends on PHP, using another framework may introduce a dependency on a third language to make templates.

We must remind that template frameworks are just pre-processor, BEFORE PHP. They can't be faster than PHP alone. When we say "speed is increased because template framework use a cache", you must read in fact "the overtime spent by the framework is reduced by cache, not the speed of processing a PHP template file". We should say "any template framework has an overload over PHP, the cache of the template framework just reduces the slowing effect of using this framework", but not "the speed is increased, it is always decreased compared to pure PHP".

Above all, having a template system is completely possible by doing a "'''.tpl.php'''" file that dos not contains any logic code, but only HTML and print of variables. We get same result (but faster and easier to develop because it does not need to do all the setXXX before calling each template). All variables (known by code that include the template) are automatically known into a PHP template page. No risk to forget a set, and a lot of line of codes reduced, a lot of time and development errors are also saved.

But an external template system can keep a guarantee of 100% of isolation between code and HTML output. Yes, but this is interesting in only 1 situation: When teams building design is completely different than team building logic code, AND if you build not too sophisticated pages, AND with no need of too many Ajax features (this need to know how code works).
And this situation is surely not the Dolibarr future (team are often be same, Ajax will be more and more present, even if we hope not "too much", and screens are more and more dependent of dynamic or contextual events, difficult to have this with one simple template without transforming the template into a page with high level of code). Also design is more and more managed now in CSS side instead of PHP side.

In the past, Dolibarr has experimented a template system like Smarty. If on the paper the idea was good, we quickly realized that finding a bug become a headache, coding become a treasure hunt, maintenance and development were done so slower (compared to previous situation where output templates are into the "View" section of each PHP file) that we forgot this idea. Pragmatism won.

There is a ton of other reasons to not use an external template system and all arguments to use them are also the best argument to use HTML/PHP as our template system. We just ask to keep separation between '''Controllers''' (the first section of PHP pages juste after the "/* Action" line), and the '''Views''', the second section after the "/* View" comment that is the presentation section build with PHP).

=CSS norms=

==Syntax rules==

There is NO syntax rules or norms for CSS. During Dolibarr Devcamp 2024/06 (Montpellier) a collective proposition was made to respect classes name from tailwindcss.

The objective is not to include tailwindcss into Dolibarr but to use syntax and classes norms issued from tailwindcss.

See [[migrating to tailwindcss css norms]]

PR: (link to PR to become)

=Dolibarr norms and code skeleton=

==Skeleton code==
To standardize the code, and to speed up the development of new components in Dolibarr, you'll find skeletons of files fully prepared in the directory '''htdocs/modulebuilder/templates/'''.

For example:

*1 file that serves as an example of the module description: '''myModule.class.php'''
*1 file that serves as an example of code for creating a new class: '''skeleton_class.class.php'''
*1 file that serves as an example of code for creating a new page: '''skeleton_page.php'''
*1 file that serves as an example of code for creating a script for executing command lines: '''skeleton_script.php'''

...

Use it as an example.
Note that the skeletons are also used by the PHP Code generator ([[Module ModuleBuilder]]), which is described in the development chapter of Dolibarr modules, to speed up your development.

==Global variables==
There is some information or objects that is common and fixed for all the execution of a PHP page and need to be used nearly everywhere in the code. To avoid to propagate everywhere this
information or objects, they are stored into global variables that you can access everywhere. This global variables are initialized at the begin of each PHP call (into the master.inc.php or master.inc.php or in top of the page). These objects are instantiated only once. The list of available global variables is defined here:
{{Template:TemplateGlobalVariables}}

*$conf is the object that contains the configuration (saved into database)
*$user is the object of the current user
*$mysoc is the object with all information about the current company
*$langs is the object with the current language
*$db is the database handler of the current database connexion (inside classes, we should pass it in the constructor and we should get it with $this->db)
*$hookmanager is a factory class to manage hooks
*$extrafields is a factory class to manage extrafields

==Dates and Timezones==
Dolibarr is an application that is multi-user and multi-location. It's therefore necessary to store dates in the right format. To avoid problems with conversions, the following rules should be applied:

*A date into memory must always be stored with Timestamp GMT format.
*A date stored into database, is the GMT Timestamp of date submitted into the request usng the PHP server timezone. This does not apply to date updated automatically by the database engine (fields '''tms''' into database).

For exemple le 1st january 1970, 3 hour at Paris (TZ=+1) = 2 hour at Greenwitch (TZ=0) will be stored into memory with value integer 7200 (2 * 3600s) and will be submitted into a SQL request to database into the string '19700101030000' (PHP convert the int into its TZ hour and database will unconvert it using its timezone too that is same than PHP).

'''How to manage this for date with hours:'''

So all insert or update methods must convert, during generation of SQL request, the integer memory date into a db string by using db->idate (you may find examples into skeleton).

And all select methods should translate date fields, coming from the database as a string in TZ of server (here '19700101030000'), into a timestamp field (integer) by calling the method db->jdate(). So this stores the date into memory as a GTM Timestamp integer.

'''How to manage dates with no hours (just day):'''

For insert/update, you must convert it with db->idate(value, 'gmt') so for 0, you will get '19700101000000'.

And all select methods should translate date fields, coming from the database as a string in TZ of server (here '19700101000000') by using $db->jdate(..., 'gmt');

'''Other cases'''

*Dates that are updated automatically (field '''tms''' into database) contains a GMT Timestamp of the date when the change is done. The select will also use the db->jdate (that use PHP server TZ) to convert read data into a GMT Timestamp into memory. So if timezone of database differs from timezone of PHP server (one of them is not correctly set), you may experience differences between creation date and update date. Try to never rely on this field in Dolibarr (this autoupdate field is mostly for debug purpose).

*Manipulation date with PHP must be done using the Dolibarr date functions: '''dol_now(), dol_mktime(), dol_stringtotime(), dol_getdate(), dol_time_plus_duree()'''. You may also find other functions available into file '''date.lib.php'''.

==UTF8/ISO encoding==
Dolibarr stores data in the following way:

*In database, data is stored in UTF8 or ISO. It depends on the database's pagecode therefore these options are set at creation time. In any case, Dolibarr's database driver (in lib/database) deals with it to convert from/to UTF8 at insertion and readout.
*Memory data is stored in UTF8 (PHP object instances).
*Web pages are returned and rendered into UTF8

==Float numbers, amount and calculation==
With PHP, like other languages (Java for exemple), non integer data (float, real, double) are not reliable for calculation.
Try to make for example
<syntaxhighlight lang="PHP">
print 239.2 - 229.3 - 9.9;
</syntaxhighlight>
You wont get zero but a very small decimal number. If you get zero here, you should be able to find other examples that don't work.
Problem of float is general, so a variable that is a result of a calculation using decimal numbers must ALWAYS be cleaned using the function '''price2num()''' with the second parameter to: 'MU', 'MT' or 'MS' depending on need (see description of function).
<syntaxhighlight lang="PHP">
print price2num(239.2 - 229.3 - 9.9, 'MT');
</syntaxhighlight>
If data manipulated is not an amount, then using MU, MT, MS has no sense, and you must use the function '''round()'''.

==Creation of tables==
Do not create tables, on the fly, during execution by a standard user, we mean, during current usage of software.
If you create a module that uses its own table, not available in the default Dolibarr code, then take a look at tutorial [[Module development]]. It explains how to provide new tables with your module, so that, the tables will be created during module activation and not during module usage.

==Comparing version==
If your code need to make different things depending on Dolibarr version, you can use the following tip to detect and compare versions
<syntaxhighlight lang="PHP">
$version=preg_split('/[\.-]/',DOL_VERSION);
if (versioncompare($version,array(5,0,-4)) >= 0) { //mycode for 5.0 only; } // For dolibarr 5.0.* (the -4 means we include also alpha, beta, rc and rcX)
</syntaxhighlight>

But this solution need to include the function versioncompare. An alternative solution to test version is to do:
<syntaxhighlight lang="PHP">
if ((float) DOL_VERSION >= 5.0) { //mycode for 5.0 only; } // For dolibarr 5.0.*
</syntaxhighlight>

==Logs==
Add logs to your code using function
<syntaxhighlight lang="PHP">
dol_syslog($yourmessage, LOG_INFO|LOG_DEBUG|LOG_WARNING|LOG_ERR);
</syntaxhighlight>

==Working directory==
If you need to create a working directory for persistent data, into your code, refer to it with
'''DOL_DATA_ROOT.'/mymodule''''

The directory can be created into your code by the following function:
<syntaxhighlight lang="PHP">
$mymoduledir=DOL_DATA_ROOT.'/mymodule';
dol_mkdir($mymoduledir);
</syntaxhighlight>

If you need a directory to store temporary data, this directory must be '''DOL_DATA_ROOT.'/mymodule/temp''''

=Design patterns and Object programming=

==Creation design patterns (GoF)==
Design patterns defined by the Gang Of Four (see wikipédia on [[w:Design patterns|Design patterns]]).
No usage of such patterns is required. We found some objects next to Singletons or Factory but not completely compliant with syntax, this is to be compatible with PHP 4 that is not a pure object language.

==Structure design patterns (GoF)==
Design patterns defined by the Gang Of Four (see wikipédia on [[w:Design patterns|Design patterns]]).
No usage of such patterns is required.

==Behavior design patterns (GoF)==
Design patterns defined by the Gang Of Four (see wikipédia on [[w:Design patterns|Design patterns]]).
No usage of such patterns is required.

==Design patterns of enterprise (Martin Fowler)==

===Patterns of code organization===
[[w:Martin Fowler|Martin Fowler]] has identified 3 ways to organize code:

*The '''Transaction Script''' (The source code is linear for each user action).

This is the old school used by all procedural languages.
Inconvenient: Redundancy of code. Need to know the physical model of data to develop.

*The '''Domain Model'''

This notion is available with object languages. It is business process (to identify before) that are used for objects classes.
Inconvenient: Model very complex to maintain.

*The '''Table Module'''

This is a mix between 2 previous where we have only one unique class for each table of database.

-> As shown in code skeletons (see previous chapter), Dolibarr uses concept of '''Table Module'''.

===Communication between business logic - data (ORM)===

There are 3 ways to make links:

*The '''Table And Row Data Gateway'''

This is the most simple. You have one class per table and each class is a link to the table with CRUD methods (Create, Read, Update, Delete). A class instance is a record in the table. The class contains only code to reach lines and fields of table.

Example: This mode is used by some ORM Frameworks, like '''iBatis''' (http://ibatis.apache.org/).

*The '''Active Record'''

Same as previous, but we are allowed to add some business functions into the CRUD class, if such functions are dedicated to manipulate data into this table.
This pattern is known to be the most productive of the 3, as it is a very good compromise between the '''Table And Row Data Gateway''' and the '''Data Mapper'''.

Example: This mode is used for Dolibarr development and most PHP software that includes their own framework and best practices.

*The '''Data Mapper'''

Classes represent entities of the problem and not the data. So you have to double, triple ... these classes with Mapper classes to access the data.
More "purist" on paper (closer of business), this method also has the disadvantage of being more complex in practice.

Example: This is the choice if you use the ORM Framework '''Propel''' (https://propelorm.org/). We find this model in heavier applications, based on this ORM among others.

-> For Dolibarr development, the pattern used is the connection mode '''Active Record''', which offers the advantages of a model close to the business without having the complexity, without obfuscating technical architecture. It is by this way that the development, understanding of code and technical maintenance and / or business behavior seems the more productive (this is however an ongoing debate between the purists and the pragmatists, debate in which nobody can really be right, because it depends on the objectives).
[[Category:Development]]

==Design pattern for Graphic interfaces (MVC)==
There are several design patterns for user interfaces (MVC, MVP, MVVM).
Many confuse this design pattern with that of using a template framework. It's unrelated. A template framework (see previous point) is only linked to the "V" part of these models.

-> Dolibarr uses the '''MVC''' Design Pattern (Model - View - Controller). Part M (Model) is materialized by a DAO class containing the CRUD (Create-Read-Update-Delete) methods for accessing the table.
Many frameworks have chosen to put the C code part (Controller) and the V code part (View) in different files, or even separate directories. The maintenance seems easier on paper, in practice, you have to juggle constantly between a ton of files when your project become larger. In Dolibarr, the separation is made by a simple comment section. The part of code C (Controller) is therefore the code that follow the tag
<pre>
/*
* Actions
* /
</pre>
It is followed by the part of code V (Vue), well separated from the C by the tag
<pre>
/*
* View
* /
</pre>

This mode of separation has had a neutral effect on new developments but has made it possible to reduce the time required for maintenance and fixing bugs so significantly that it is not envisaged to switch to another type of separation (yes the findings made in real life are not always those expected by school theory). The important thing remains that there is always a separation between C and V, no matter how this separation is materialized, as long as it is (Reminder: Do not confuse the notion of separation of C and V with the notion of separation of the code to feed the data of a View and of the code to format the View, this a principle of separation relating to the Design Pattern of Vue, see next point).

==Design pattern for Views - Presentation==
There are frameworks that specialize in Vue Design Pattern, the part of formatting the screen seen by the user.
Old versions of Dolibarr used Smarty. This framework is an overlay to an already very powerful screen formatting framework called ... PHP. The benefits being much lower than the disadvantages, it has been abandoned in favor of PHP templates (.php files or .tpl.php files) which remain the simplest, the most universal, the most scalable and the most efficient, of the presentation frameworks we tried to use.

Its only flaw is that it cannot guarantee 100% the deviations of a developer who would integrate into the View, a logic unrelated to the presentation (therefore other than code intended for generation, formatting, HTML output , test or loop logic). This point is however controlled by the validation mechanism of the project managers' code.

Here again, it is the experience and the observation of a better productivity performance that has motivated the abandonment of the external Presentation frameworks in favor of the PHP framework.

=Rules to define branch target of a contribution=
The rules to decide if a contribution (Pull Request) must be pushed into an old maintenance branch or into development are not strict and are often defined by the good sense (pragmastism first).
We can find help on the graph found on this page [[:Category:RoadMap#Merging_PR_process_.28develop_or_maintenance_.3F.29]]

=About composer=
Composer is a tool to make deployment of PHP packages and dependenciess. Dolibarr is a PHP application that use dependencies that are PHP packages, so we could imagine to use composer to install Dolibarr.

This is not a good idea as it is just technically not possible for the following reasons:

*First, you must understand that composer is a tool '''to deploy a frozen image of a package'''. It is a tool to '''deploy''', not a tool to '''manage dependencies''' (event if some features exists for that). Dolibarr is an application that has a lot of dependencies, but for each of them, the Dolibarr project has to apply some patches to have the dependencies working correclty (for different reasons, mainly because of bugs or architecture error into original project. See the file '''dev/dolibarr_changes.txt''' for full list we have to do on each dependency). Each PHP dependency has at least one change to do to have it working correctly. So the image of a library L that Dolibarr needs is NOT the image provided into the composer package by the L project. After discussion with '''Nils Adermann''', the author of the composer package during the first OSFS congress (https://05f5.com) to get its point of view on this need for large projects, it appears that if a large project is in this situation, the good way to use composer is to build yourself a very large package called "dolibarr" with no composer dependencies and all external libraries embedded into the same composer project so we can deploy all in one composer command, confirming that composer is above all a good "fast deployment system" but a bad "dependency manager". The dependency system of composer project was simply designed to use an exact version of a library and not to use a patched version of this library. It is even designed to avoid this, making its use not possible in this context.
*Second point is a different problem with the composer dependencies system: Each dependency on a library has itself a high number of sub-dependency. And all this sub-dependencies have also a high number of dependencies that nobody can't control (there is always sub-dependencies on the libraries you use that are managed by a lower level dependency project). The result is that when you use composer to install the main library you need, you install (and you can't avoid it) a ton of other packages you don't need. For example, Dolibarr is a 80Mb project with all its PHP dependencies. If you install it with composer (we suppose that the first point is not a problem), then the project reach the size of 300 Mb. Size of project is multiplicated by 3.5 with no reason. Not sobriety compliant.
*Third point is also problems with the dependency system: When you install an external library this library has dependency and each of this depency of depencies are constraints with each other and with PHP version. Imagine the required library L1 is compatible with PHP x to x+n and the library L2 is compatible with PHP y to y+m, etc... To have an application working correctly, you must find a PHP version that will be common to all the required packages, so here inside the intersection of the two ranges [x - x+n] and [y - y+m]. But when you are using a large number of high level libraries, it means you are depending on a very large number of low level libraries (because each high level libraries has a lot of medium level libraries as dependencies that has a high number of low level dependencies). And when this number is very large, the number of different required ranges become so large that you reach a situation where the number of PHP versions that are common to all of them (hte intersection of all ranges) is very low, and even does not exists at all (there is no combination of version that is compatible with ALL packages you need because each sub-project depreciate its PHP version in its own roadmap without taking care of which child or parent dependency use it). But Dolibarr must works for everybody, whatever is other project roadmaps, and on the "as large as possible" number of PHP versions and not just on one or two given major version of PHP. Compatibiliy must also be guaranted during a very long term (an ERP is not a software we can change every year), when low level libraries are changing requirement very often.
*Last point is about security: As we view in the second point, when using composer, a very high number of PHP files are installed even if you don't need them. Dolibarr is a critical application that need a very strict security policy. Requirement for security is at a high level (See our page [[Security_information]]). When using composer, you install a lot of files and small sub-project and sub-project of sub-projects where security is not considered as important than what we need on the Dolibarr project. If we make an analysis on a given period, the number of vulnerability reported on the whole project Dolibarr + files of external libraries when installed by composer (that we mostly don't need) is multiplicated by 20 compared to the number of vulnerabilities that are reported only in the scope of Dolibarr + external libraries when they are embedded manually with the minimal number of files we need). Such an increase is simply not possible, and give a very bad mesage on security point of view: " yes we reduce 95% of known security vulnerabilities but we don't do it because we are using composer". Some companies (due to a strict security requirements of their business, like secnum or iso requirement) would simply not be allowed to use Dolibarr if we accept these.

As we can see, composer, even if it was largely adopted by a lot of small projects, is far away from the state of the art. For all this reasons, it is just not possible to use composer so we keep the composer.json file in the project so we can use it for some development tests or make upgrade tests of some libraries with it, but we have renamed it by adding the extension ".disabled" to be sure that end users won't try to install or update their Dolibarr with it, in which case, the application will become unstable (remind point 1) and unsecured (remind point 4)

Language and development rules

2026-10-13T02:11:54Z

Eldy: /* PHP */

[[de:Sprachen_und_Programmierregeln]]
[[fr:Langages_et_normes]]
[[es:Lenguaje_y_Normas_de_Desarrollo]]
[[zh:语言和开发规则]]


{{TemplateDocDevEn}}

These are some rules on language, syntax and norm we use in the Dolibarr project:

=Versions=

*Current version of Dolibarr must work on:

#All OS (Windows, Linux, MACOS...)
#PHP {{PHPMinVersion}} (Must work with no need of complementary PHP module, except module to PHP module to access database). See [[List of releases, change log and compatibilities]] for pre-requisites for older versions.
#MySQL {{MySqlMinVersion}}

=Copyright Norms=

*All PHP files must start with a header that looks like

<syntaxhighlight lang="PHP">
<?php
/* Copyright (C) YYYY John Doe <email@email.com>
*
* Licence information
*/
...
</syntaxhighlight>
When you edit an existing file of project, you must add a Copyright line under others.

=PHP Norms=
==PHP==

*Dolibarr is written with PHP and supports all versions of PHP higher than {{PHPMinVersion}}. All files must end with extension .php

*Usage of PHP superglobals variables must use the dedicated operators $_COOKIE, $_SERVER, $_ENV but use the Dolibarr functions [[Fonctions utiles Dolibarr|GETPOST...()]] to get the contents of $_GET or $_POST..

*Other operators ($HTTP_SERVER_GET, ...) are now deprecated in PHP, so they must not be used. Code must work if option '''register_long_arrays''' is set to off. Moreover, the code must work when PHP option '''register_globals''' is off (recommended by PHP). It must also work if the option '''register_globals''' is on (by default on a lot of installations).

*Do not use '''<s>PHP_SELF</s>'''. Use instead '''$_SERVER["PHP_SELF"]'''. Also, Dolibarr framework sanitizes content of $_SERVER["PHP_SELF"] variable (into main.inc.php file, before any business code).

*When several variables must be initialized with the same value, you must use individual declarations (separated by ;)

<syntaxhighlight lang="PHP">
$var1 = 1;
$var2 = 1;
$var3 = 1;
</syntaxhighlight>
instead of
<syntaxhighlight lang="PHP">
$var1 = $var2 = $var3 = 1;
</syntaxhighlight>
which is slower.

 

====Strings====

*Strings must be have variables outside of the quote.

<syntaxhighlight lang="PHP">
print "My text show my ".$variable." !\n";
</syntaxhighlight>

====Closure or anonymous function====
If you new a function, just create a real one (or a method).
Anonymous function are just forbidden (existing one should be removed), they brings a lot of problem:
* Code readability
* Broken static analytics tools that can't guess type or path of variable
* Function documentation
* AI become crazy
* Coding debug trouble
* Impact analysis more difficult as the stack trace of code can't be guess easily when function are not named explicitely.

====Comments====

*Comments must use the C syntax, ie a double slash for a comment on one line and a slash-star to open a bloc for several lines

<syntaxhighlight lang="PHP">
/* Bloc of comment
*
* End of bloc
*/

$monobjet = new MonObjet($db);
$result=$monobjet->fetch($idobject);

for ($i = 1 , $i < 2 ; $i++) {
// comment on one line
print $i;
}

function myFunction($param1, $param2)
{
// code
}
</syntaxhighlight>

 

*Functions must return a value equal or higher than 0 if successful and strictly lower than 0 if error.

*No dead code (code never used) into Dolibarr core code (code used by external modules only must be included within the external modules).

*Use "include_once" for anything with functions or class definitions in it (like *.class.php and *.lib.php files), use "include" for template-style php with files containing common part of HTML and PHP code (like *.inc.php and *.tpl.php files).

*Coding style to use is the '''PSR-12''' (https://www.php-fig.org/psr/psr-12/). Only rules tagged "MUST" are currently required. So note however the exceptions:
**Length of line: PSR-12 mention we can't go up to 120 characters on same line, this is a soft limit. It is better to have long lines instead of long page with code content that is just data declaration and does not contain any logic. However, we introduced a hard limit of '''1000''' characters (having line larger than this may return errors on Continuous Integration tests).
**Tabs are allowed: The other exception is that we don't replace systematically the tabs with spaces. Using tabs is more convenient for most editors/developers. Also using spaces breaks some auto-format features (like Eclipse autoformat feature on some Eclipse version). For the moment, the best setup is "Keep spaces/tabs as it is", however, you can activate the option "Remove spaces at end of lines".
**We allow elements of an array on same line and we do not always add a new line at end of each element.
**Note 1: The following rule are very important to follow:
***Files must be saved with Unix format (LF) and not Windows (CR/LF). Unix format is compatible on all OS such as Unix like, Windows, Mac, but the Windows text file format may not work on some PHP under Unix.
***Smart tags PHP must not be used. PHP code section must start with '''<?php''' (the "smart tags" <? or <?=, also known as the "short tags", depend on php configuration option '''short_open_tag''', even if this is no more true after php5.4. The use of <? can still have conflict with XML syntax. The smartags may not be supported by all IDE. Also, the use of <?= make easier for a hacker to make PHP injection. To fight this, some Dolibarr components, like the website PHP editor, accepts only full php tags to detect, parse and filter PHP. Finaly, using the same tag everywhere make also easier to make code scanning or impact analysis when we are sure of the tags that is used, and the best solution, to be sure of which tag is used, is to use one, only one and the same tag everywhere.
**Note 2: You can use the file '''dev/setup/codesniffer/ruleset.xml''' as rule file to control coding style with PHPCodeSniffer.
**Note 3: You can use the file '''dev/setup/eclipse/PSR-12 [built-in].xml''' as rule file to setup Eclipse syntax formater.
**Note 4: You may note that current code is not yet compliant with the PSR-12. The reason is that we must "now" follow the "MUST" rules of PSR-12, but it wasn't in the past. So feel free to change coding style to match new rules (keep in mind the 2 exceptions) if you find such cases.

==Classes and properties structures==

Some properties of classes are found in different classes. To avoid having different names, we will use the following PHP properties names:

{{TemplatePHPFields}}

=SQL and Database rules=

==DDL file format==
Files containing definition of the database structure (DDL files) must be '''2 per table''':

*The first file defines the table and its fields. The file name contains the table name, e.g. like this: <tt>llx_''mytable''.sql</tt>

A comment will be added for each field to explain its usage.

*The second file defines all foreign keys, performance indexes or other constraints and the file name will be like: <tt>llx_''mytable''.key.sql</tt>

These files must be stored in the directory '''install/mysql/tables''' for all standard files or '''mymodule/tables''' for tables provided by an external module.

Example: '''file for creating the table llx_mytable will be llx_mytable.sql''':

<syntaxhighlight lang="sql">
-- ===========================================================================
-- Copyright (C) 2013 Author <email@author.com>
--
-- This program is free software; you can redistribute it and/or modify
-- it under the terms of the GNU General Public License as published by
-- the Free Software Foundation; either version 3 of the License, or
-- (at your option) any later version.
--
-- This program is distributed in the hope that it will be useful,
-- but WITHOUT ANY WARRANTY; without even the implied warranty of
-- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-- GNU General Public License for more details.
--
-- You should have received a copy of the GNU General Public License
-- along with this program. If not, see <http://www.gnu.org/licenses/>.
-- ===========================================================================

create table llx_mytable
(
rowid integer NOT NULL AUTO_INCREMENT PRIMARY KEY,
ref varchar(30) NOT NULL, -- object reference number
entity integer DEFAULT 1 NOT NULL, -- multi company id
ref_ext varchar(255),-- reference into an external system (not used by dolibarr)
field_one integer,
field_two integer NOT NULL,
fk_field integer,
field_date datetime,
datec timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,, -- creation datetime
tms timestamp, -- update time stamp
fk_user_author integer NOT NULL, -- Author, foreign key of llx_user
fk_user_mod integer NOT NULL, -- Last updater, foreign key of llx_user
import_key varchar(14) -- Use by import process
)type=innodb;
</syntaxhighlight>

Example: '''file for creating keys/indexes for the table llx_mytable will be llx_mytable.key.sql''':

<syntaxhighlight lang="sql">
-- ===========================================================================
-- Copyright (C) 2013 Author <email@author.com>
--
-- This program is free software; you can redistribute it and/or modify
-- it under the terms of the GNU General Public License as published by
-- the Free Software Foundation; either version 3 of the License, or
-- (at your option) any later version.
--
-- This program is distributed in the hope that it will be useful,
-- but WITHOUT ANY WARRANTY; without even the implied warranty of
-- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-- GNU General Public License for more details.
--
-- You should have received a copy of the GNU General Public License
-- along with this program. If not, see <http://www.gnu.org/licenses/>.
-- ===========================================================================

ALTER TABLE llx_mytable ADD UNIQUE uk_mytable_field (field_one, field_two);

ALTER TABLE llx_mytable ADD CONSTRAINT fk_mytable_fk_field FOREIGN KEY (fk_field) REFERENCES llx_matablepere (rowid);
</syntaxhighlight>

==Table and fields structures==

*Structure of tables.

When you create a new table, it is recommended to use the same conventions as other Dolibarr tables. This means the following fields:
- rowid INTEGER AUTO_INCREMENT PRIMARY KEY that is technical id of record
- entity INTEGER default 1 that is id for the multicompany feature
- date_creation datetime that is the creation date
- tms timestamp that will contain date of last modification (the database manages this field automatically, no need to manage it by the code, just create the field)
- date_valid datetime that is the validation date (if applicable)
- import_key varchar(32) that will contain the import code YYYYMMDDHHMMSS if you make mass import
- status smallint to store a status
Optional
- fk_user_creat or fk_user_author integer that is the id of user making creation
- fk_user_modif integer that is the id of user making change
- fk_user_valid integer that is the id of user validating record (if applicable)
- fk_soc integer that is the ID of the Third party (if applicable)

Note field:
- note_private text for private comment of the object
- note_public text for public comment of the object
or
- note text if there is no need to have private and public

*Type of fields:

To be compatible with any accuracy required by any country on amounts, to be compatible with any database syntax and with the Dolibarr upgrade framework, we will use the following types for database fields:

- integer for a primary key, an integer or any of foreign key (bigint may also be accepted for very large tables)
- smallint for a small number (like for a status) or a boolean
- double(24,8) for any amount
- double(6,3) for any vat rate
- real for a quantity
- varchar for a string (also if length is 1, the type char is more and more deprecated)
- timestamp for a field date+time that is automatically updated
- datetime for a field date+time
- date for a field date
- text or medium text for large fields (no index allowed on such fields)

All business rules must be in the same place, in PHP code, not in the client or the database, that's why type enum is also not allowed.
Other types are not allowed for compatibility reasons.

*All tables have a prefix to avoid name conflicts with other projects. In the current version this prefix is fixed and can't be modified. Its value is <tt>llx_</tt>. In a future version this value should be modified during installation process.

==Primary keys==
The primary key of a table must be called <tt>rowid</tt>.

Some old tables do not use this rule and use a primary key called <tt>id</tt> (e.g. [[Table llx_c_actioncomm]]). The reason is historical and this should not happen anymore.

==Foreign keys==
The name of a foreign key must start with the prefix <tt>fk_</tt> followed by the table name (i.e. name of the referencing table) (this is required to avoid duplicate names in project that are not allowed even if in different tables by some DBMS like Postgresql) then the field name (i.e. name of the referencing field) (this is to allow to have several foreign keys in same table).

Example:
''fk_facture_fourn_fk_soc'' is a foreign key in the table llx_facture_fourn for the field fk_soc in this table (that references the rowid field in another table)

Note when using a foreing key:
- Do not add a hard foreign key (a foreign key controled bydatabase) when the link is not important. This generates more trouble than solution. For exemple, a link to a user table to follow the author of creation of an object is NOT an important link. If parent object,the user, is deleted,the child record will be orphelin but this is not a problem. Record will appear with a cretion author that is "unknown" and that is the truth if we have deleted the parent user.

- If you develop your own external module, it must have no hard foreign keys that point to Dolibarr standard tables. This will break standard dolibarr upgrades, repair, backup and restore tools and may also break standard features. Foreign keys must be soft foreign keys so managed by the code with no database contraints.

==Alternative keys==
Sometimes, we need other unique keys than primary key. When we need this, we can create an alternate unique key. Such a key should have a name that starts with <tt>uk_</tt>, then the table name (this is required to avoid duplicate names of unique keys that may create problems for some DBMS like Postgresql) and then another string to define the key (this is to allow having several unique keys on the same table).

Example:
''uk_societe_code_client'' is a unique key on table llx_societe on field code_client.

==Index performance==
Some fields are often used as search or order criteria, or for joins. In such case, we need to set a performance index on field to increase performances. Such indexes are named with a prefix <tt>idx_</tt> then the table name and then the field name.

Example:
''idx_societe_user_creat'' is a performance index on table llx_societe for field user_creat

==Denormalized field==
Fields that store a data that is result of calculation of other data already stored is a "denormalized field". It must be avoid if we can, and must be used only for performance purpose.
In such a case, to allow developper to understand that the data is not the value that rule, we must prefix the nameof fiel with '''"denormalized_"'''.

For example the field "denormalized_lower_planned_end_date" to store the ending date of the last membership of a member. We already have the information, but doing search or filter on it is difficult as it is stored into another table into another level, so we can duplicate the information into a such field.

If this happen, we must :
* check the any import profile has a function to update the denormalized value during import.
* have a task in the repair.php to recalculate the value and align the data with the original source.
* into the crud method that update any data that impact the field, we must include the update or the denormalized value.

==SQL Coding rules==

*Alias usage/Fields naming

When doing select, we can use alias to simplify writing/reading of requests:
<syntaxhighlight lang="sql">
select chp1, chpxxx2 as chp2 from table2 as t1, table2 as t2 where t1.chpx = t2.chpy
</syntaxhighlight>
However, we must not used alias for update request as they are not compatible with Mysql 3.1.

*Using SELECT * is forbidden ! When using SELECT you must define complete list of fields to get. This avoids confusion. And above all, this make reengeering of code easier and make impact analysis of change on a field possible. Example:

<syntaxhighlight lang="sql">
SELECT field_a, field_b, field_c FROM table_1 WHERE field_d = '$id'
</syntaxhighlight>

*Into SQL requests, you must quote fields except the fields that contain amounts which must be stored as double or real type. Quotes on numbers may result in saving as a different value. For example 412.62 in an insert will be saved as value 412.61999512 into database (due to implicit conversion string to numeric) if the target field has type double(24,8). Only PHP see value 412.61999512. Other tools will see 412.62 letting think that there is no problem. But it's PHP that has the good vision. There is really a wrong value into database. By removing quotes on numbers, no problem occurs.

Example:
<syntaxhighlight lang="sql">
Good: INSERT INTO table_1 (field_txt, field_num) VALUES ('txt', 412.62)
Bad: INSERT INTO table_1 (field_txt, field_num) VALUES ('txt', '412.62')
</syntaxhighlight>

Note, the problem of float numbers is the same on all languages and not only when inserting data into database. It occurs also with any language when you work on "real" numbers, so numbers must be, as soon as they are affected into variable, cleaned with function price2num with second parameter defined to :
'MU' (for unit prices), 'MT' (for total prices) or 'MS' (otherwise) depending on usage of number. (see function documentation)

*SQL Date functions NOW, SYSDATE, DATEDIFF or DATE are forbidden inside SQL requests. Other functions like (MONTH, YEAR) must also be avoided if possible. If you must use the current date into a field, value must come from the PHP and not from the database engine. This is for 3 reasons:
**better portability of code
**better management of TimeZone (reference timezone is the PHP timezone and timezone of database may differs so all dates functions must be on PHP side).
**better performance (see example and final comment)

For example, don't do:
<syntaxhighlight lang="PHP">
$sql="SELECT rowid FROM table where datefield = NOW()";
</syntaxhighlight>
but do:
<syntaxhighlight lang="PHP">
$sql="SELECT rowid FROM table where datefield = '".$this->db->idate(dol_now())."'";
</syntaxhighlight>

For example, don't do:
<syntaxhighlight lang="PHP">
$sql="SELECT rowid FROM table where DATEDIFF(table.datefield, NOW()) > 7";
</syntaxhighlight>
but do:
<syntaxhighlight lang="PHP">
$sql="SELECT rowid FROM table where datefield < '".$this->db->idate(dol_now() - (7 * 24 * 3600))."'";
</syntaxhighlight>

An other advantage of this rule, is that request benefits of index because we are making a compare of a field with a fixed value. When using datediff, you make an operation on field before comparison, this means database can't use the index on field, resulting on very bad performance compared to solution without the datediff.

*The statement WITH ROLLUP is prohibited:

This statement should not be used: it is not handled the same way by different databases.
Also, using WITH ROLLUP breaks the purity of the returned data. The intermediate subtotal generation aggregation performed by this statement can easily be done using PHP and helps keep the returned data array clean (not corrupted by artificially inserted data).

*The sql function GROUP_CONCAT can't be used. It is not portable and ask the database to make subrequests for line into main table, this can be done easier by doing a subrequest inside the PHP loop when building the output of each line.

*Use $db->ifsql for SQL IF

Do not include the IF into your forged SQL request. But use instead $db->ifsql() method to you will make a SQL IF that is compatible with all SQL databases.

*No DELETE CASCADE and ON UPDATE CASCADE

Such SQL instructions are forbidden because they bypass the business rules of the application bringing a lot of troubles out of control of the developers. For example, if there is a delete cascade between table A and B, when the application will execute the code to remove a record in A, the children into table B will also be removed (this is the goal). But if there was a Dolibarr PHP trigger (for example provided by an external module) on the deletion of record of B (for example to validate the deletion or to execute a complementary action), the DELETE CASCADE will be executed without having the Dolibarr PHP trigger on B deletion executed, missing the validation or actions of the PHP trigger of the module. All business rules must be implemented on the same side (so the server PHP side), this is the reason why business rules implemented on Database side (like with delete cascade) are not allowed (same conclusion than the next point about Database triggers).
Note that an external module can use them for links between Dolibarr tables and its module tables but a better recommended solution is to use the trigger to implement the deletion of its tables when a record of a parent official table is deleted.

==Using Database triggers / stored procedures==
Using Database triggers is not allowed into the code of Dolibarr, so you should have no troubles with Database triggers.

*Database triggers are not portable. Compatibility may be broken when upgrading your version of your database
*Database triggers are often forgotten into backup tools
*Database triggers need special permissions that you may not have (and should not have) on a common secured database
*Database triggers means also that you include some "business rules" of your application into the database where most other rules are managed by the code itself (this can create conflict or code that can't be debugged with a step by step debugger)
*Database triggers execute code using the timezone, the default language of the database instead of the reference timezone of the application that may be different (generating offset into database) and the default language setup in application ...
*There is tons of other reasons why we do not recommend to use database triggers in your own development.

Using Database triggers can save you time when you make development but is a very bad practice when quality, portability, security and sustainability are priority, so it is forbidden as it is not compatible with the high level of quality of code expected by Dolibarr team. External modules that uses Database triggers may also be refused on the market place since it won't work for more than 50% of users.

==Basic Migration Rules==

*Structure migration scripts are files of the type '''install/mysql/migration/a.b.c-x.y.z.sql'''. In a migration file from version n to n+1, a table that is no longer used in n+1 is only dropped (DROP TABLE) during the migration from version n+1 to n+2. This is to ensure that obsolete tables are always kept for the duration of a version to correct any issues in case of a migration error.

==MySQL-MariaDB specificity==

*Tables must be declared with format InnoDB.

This format supports foreign keys and their restrictions, and transactions integrity is also supported. This guarantees that Dolibarr events keep all data with correct values between tables even when transaction modify different tables.

*Dolibarr MUST work even if MySQL option '''strict''' is active.

To activate it (required when developing on Dolibarr), add the following line into the config file of your MySQL server (my.cnf or my.ini)
{{MySqlStrictMode}}

==PostgreSQL specificities==
Only MySQL files must be maintained.
Those files are converted "on the fly" by the database Dolibarr driver into the targeted database system.

There is an exception for the SQL "UPDATE FROM" of Postgres:

MySQL Syntax:
<syntaxhighlight lang="sql">
UPDATE table_target as target, table_source as source SET fieldtarget=source.fieldsource
WHERE source.rowid=target.rowid;
</syntaxhighlight>

PgSQL Syntax:
<syntaxhighlight lang="sql">
UPDATE table_target as target SET fieldtarget=source.fieldsource
FROM table_source as source WHERE source.rowid=target.rowid;
</syntaxhighlight>

There is no native SQL requests "UPDATE FROM" in all Dolibarr core (only simple "UPDATE") so this difference of syntax is not a problem. But if you need to use one in your own code of your module, you should do :
<syntaxhighlight lang="PHP">
if ($this->db->type=='pgsql') {
$sql="UPDATE table_target as target SET fieldtarget=source.fieldsource
FROM table_source as source WHERE source.rowid=target.rowid";
} else {
$sql= "UPDATE table_target as target, table_source as source SET fieldtarget=source.fieldsource
WHERE source.rowid=target.rowid";
}
</syntaxhighlight>

=HTML norms=
==Syntax rules==

*HTML used must be HTML compliant and not XHTML. All attributes of HTML tags must be in lower case and quoted with ".

*Links href must be absolute and use the function dol_buildpath() to get absolute path from a relative path and img tag must be build using function img_picto().

For example:
<syntaxhighlight lang="PHP">
print '<a href="'.dol_buildpath('/mydir/mypage.php').'">'.img_picto('Texte alt','namepictopng','').'</a>';''
</syntaxhighlight>

*HTML tables must have columns with no forced width, except for columns that contains data we know the length. For example, a column with a picto only can be forced to with="20px".

Otherwise, we must avoid forcing the column width. Reason is that, in most cases, the browser make a better works to define column width automatically than forced values, and it works whatever is the resolution.

*Javascript/ajax code and call to javascript files into php pages must be avoided. However, if you need to include javascript code, you must add a condition on "$conf->use_javascript_ajax"

<syntaxhighlight lang="PHP">
if ($conf->use_javascript_ajax) {
... // php code generating javascript here
}
</syntaxhighlight>

*Popup windows must not be used, except for tooltips (and must have a condition as explained before).

*External scripts must be written in Perl if they can't be written in PHP. Usage of another language is not forbidden but must be argued before in the development mailing-list.

==External template framework ?==
There is ton of frameworks to provide a template language of an HTML page (smarty, twig, ...). The best and faster one we know is just called "PHP", and because Dolibarr already depends on PHP, using another framework may introduce a dependency on a third language to make templates.

We must remind that template frameworks are just pre-processor, BEFORE PHP. They can't be faster than PHP alone. When we say "speed is increased because template framework use a cache", you must read in fact "the overtime spent by the framework is reduced by cache, not the speed of processing a PHP template file". We should say "any template framework has an overload over PHP, the cache of the template framework just reduces the slowing effect of using this framework", but not "the speed is increased, it is always decreased compared to pure PHP".

Above all, having a template system is completely possible by doing a "'''.tpl.php'''" file that dos not contains any logic code, but only HTML and print of variables. We get same result (but faster and easier to develop because it does not need to do all the setXXX before calling each template). All variables (known by code that include the template) are automatically known into a PHP template page. No risk to forget a set, and a lot of line of codes reduced, a lot of time and development errors are also saved.

But an external template system can keep a guarantee of 100% of isolation between code and HTML output. Yes, but this is interesting in only 1 situation: When teams building design is completely different than team building logic code, AND if you build not too sophisticated pages, AND with no need of too many Ajax features (this need to know how code works).
And this situation is surely not the Dolibarr future (team are often be same, Ajax will be more and more present, even if we hope not "too much", and screens are more and more dependent of dynamic or contextual events, difficult to have this with one simple template without transforming the template into a page with high level of code). Also design is more and more managed now in CSS side instead of PHP side.

In the past, Dolibarr has experimented a template system like Smarty. If on the paper the idea was good, we quickly realized that finding a bug become a headache, coding become a treasure hunt, maintenance and development were done so slower (compared to previous situation where output templates are into the "View" section of each PHP file) that we forgot this idea. Pragmatism won.

There is a ton of other reasons to not use an external template system and all arguments to use them are also the best argument to use HTML/PHP as our template system. We just ask to keep separation between '''Controllers''' (the first section of PHP pages juste after the "/* Action" line), and the '''Views''', the second section after the "/* View" comment that is the presentation section build with PHP).

=CSS norms=

==Syntax rules==

There is NO syntax rules or norms for CSS. During Dolibarr Devcamp 2024/06 (Montpellier) a collective proposition was made to respect classes name from tailwindcss.

The objective is not to include tailwindcss into Dolibarr but to use syntax and classes norms issued from tailwindcss.

See [[migrating to tailwindcss css norms]]

PR: (link to PR to become)

=Dolibarr norms and code skeleton=

==Skeleton code==
To standardize the code, and to speed up the development of new components in Dolibarr, you'll find skeletons of files fully prepared in the directory '''htdocs/modulebuilder/templates/'''.

For example:

*1 file that serves as an example of the module description: '''myModule.class.php'''
*1 file that serves as an example of code for creating a new class: '''skeleton_class.class.php'''
*1 file that serves as an example of code for creating a new page: '''skeleton_page.php'''
*1 file that serves as an example of code for creating a script for executing command lines: '''skeleton_script.php'''

...

Use it as an example.
Note that the skeletons are also used by the PHP Code generator ([[Module ModuleBuilder]]), which is described in the development chapter of Dolibarr modules, to speed up your development.

==Global variables==
There is some information or objects that is common and fixed for all the execution of a PHP page and need to be used nearly everywhere in the code. To avoid to propagate everywhere this
information or objects, they are stored into global variables that you can access everywhere. This global variables are initialized at the begin of each PHP call (into the master.inc.php or master.inc.php or in top of the page). These objects are instantiated only once. The list of available global variables is defined here:
{{Template:TemplateGlobalVariables}}

*$conf is the object that contains the configuration (saved into database)
*$user is the object of the current user
*$mysoc is the object with all information about the current company
*$langs is the object with the current language
*$db is the database handler of the current database connexion (inside classes, we should pass it in the constructor and we should get it with $this->db)
*$hookmanager is a factory class to manage hooks
*$extrafields is a factory class to manage extrafields

==Dates and Timezones==
Dolibarr is an application that is multi-user and multi-location. It's therefore necessary to store dates in the right format. To avoid problems with conversions, the following rules should be applied:

*A date into memory must always be stored with Timestamp GMT format.
*A date stored into database, is the GMT Timestamp of date submitted into the request usng the PHP server timezone. This does not apply to date updated automatically by the database engine (fields '''tms''' into database).

For exemple le 1st january 1970, 3 hour at Paris (TZ=+1) = 2 hour at Greenwitch (TZ=0) will be stored into memory with value integer 7200 (2 * 3600s) and will be submitted into a SQL request to database into the string '19700101030000' (PHP convert the int into its TZ hour and database will unconvert it using its timezone too that is same than PHP).

'''How to manage this for date with hours:'''

So all insert or update methods must convert, during generation of SQL request, the integer memory date into a db string by using db->idate (you may find examples into skeleton).

And all select methods should translate date fields, coming from the database as a string in TZ of server (here '19700101030000'), into a timestamp field (integer) by calling the method db->jdate(). So this stores the date into memory as a GTM Timestamp integer.

'''How to manage dates with no hours (just day):'''

For insert/update, you must convert it with db->idate(value, 'gmt') so for 0, you will get '19700101000000'.

And all select methods should translate date fields, coming from the database as a string in TZ of server (here '19700101000000') by using $db->jdate(..., 'gmt');

'''Other cases'''

*Dates that are updated automatically (field '''tms''' into database) contains a GMT Timestamp of the date when the change is done. The select will also use the db->jdate (that use PHP server TZ) to convert read data into a GMT Timestamp into memory. So if timezone of database differs from timezone of PHP server (one of them is not correctly set), you may experience differences between creation date and update date. Try to never rely on this field in Dolibarr (this autoupdate field is mostly for debug purpose).

*Manipulation date with PHP must be done using the Dolibarr date functions: '''dol_now(), dol_mktime(), dol_stringtotime(), dol_getdate(), dol_time_plus_duree()'''. You may also find other functions available into file '''date.lib.php'''.

==UTF8/ISO encoding==
Dolibarr stores data in the following way:

*In database, data is stored in UTF8 or ISO. It depends on the database's pagecode therefore these options are set at creation time. In any case, Dolibarr's database driver (in lib/database) deals with it to convert from/to UTF8 at insertion and readout.
*Memory data is stored in UTF8 (PHP object instances).
*Web pages are returned and rendered into UTF8

==Float numbers, amount and calculation==
With PHP, like other languages (Java for exemple), non integer data (float, real, double) are not reliable for calculation.
Try to make for example
<syntaxhighlight lang="PHP">
print 239.2 - 229.3 - 9.9;
</syntaxhighlight>
You wont get zero but a very small decimal number. If you get zero here, you should be able to find other examples that don't work.
Problem of float is general, so a variable that is a result of a calculation using decimal numbers must ALWAYS be cleaned using the function '''price2num()''' with the second parameter to: 'MU', 'MT' or 'MS' depending on need (see description of function).
<syntaxhighlight lang="PHP">
print price2num(239.2 - 229.3 - 9.9, 'MT');
</syntaxhighlight>
If data manipulated is not an amount, then using MU, MT, MS has no sense, and you must use the function '''round()'''.

==Creation of tables==
Do not create tables, on the fly, during execution by a standard user, we mean, during current usage of software.
If you create a module that uses its own table, not available in the default Dolibarr code, then take a look at tutorial [[Module development]]. It explains how to provide new tables with your module, so that, the tables will be created during module activation and not during module usage.

==Comparing version==
If your code need to make different things depending on Dolibarr version, you can use the following tip to detect and compare versions
<syntaxhighlight lang="PHP">
$version=preg_split('/[\.-]/',DOL_VERSION);
if (versioncompare($version,array(5,0,-4)) >= 0) { //mycode for 5.0 only; } // For dolibarr 5.0.* (the -4 means we include also alpha, beta, rc and rcX)
</syntaxhighlight>

But this solution need to include the function versioncompare. An alternative solution to test version is to do:
<syntaxhighlight lang="PHP">
if ((float) DOL_VERSION >= 5.0) { //mycode for 5.0 only; } // For dolibarr 5.0.*
</syntaxhighlight>

==Logs==
Add logs to your code using function
<syntaxhighlight lang="PHP">
dol_syslog($yourmessage, LOG_INFO|LOG_DEBUG|LOG_WARNING|LOG_ERR);
</syntaxhighlight>

==Working directory==
If you need to create a working directory for persistent data, into your code, refer to it with
'''DOL_DATA_ROOT.'/mymodule''''

The directory can be created into your code by the following function:
<syntaxhighlight lang="PHP">
$mymoduledir=DOL_DATA_ROOT.'/mymodule';
dol_mkdir($mymoduledir);
</syntaxhighlight>

If you need a directory to store temporary data, this directory must be '''DOL_DATA_ROOT.'/mymodule/temp''''

=Design patterns and Object programming=

==Creation design patterns (GoF)==
Design patterns defined by the Gang Of Four (see wikipédia on [[w:Design patterns|Design patterns]]).
No usage of such patterns is required. We found some objects next to Singletons or Factory but not completely compliant with syntax, this is to be compatible with PHP 4 that is not a pure object language.

==Structure design patterns (GoF)==
Design patterns defined by the Gang Of Four (see wikipédia on [[w:Design patterns|Design patterns]]).
No usage of such patterns is required.

==Behavior design patterns (GoF)==
Design patterns defined by the Gang Of Four (see wikipédia on [[w:Design patterns|Design patterns]]).
No usage of such patterns is required.

==Design patterns of enterprise (Martin Fowler)==

===Patterns of code organization===
[[w:Martin Fowler|Martin Fowler]] has identified 3 ways to organize code:

*The '''Transaction Script''' (The source code is linear for each user action).

This is the old school used by all procedural languages.
Inconvenient: Redundancy of code. Need to know the physical model of data to develop.

*The '''Domain Model'''

This notion is available with object languages. It is business process (to identify before) that are used for objects classes.
Inconvenient: Model very complex to maintain.

*The '''Table Module'''

This is a mix between 2 previous where we have only one unique class for each table of database.

-> As shown in code skeletons (see previous chapter), Dolibarr uses concept of '''Table Module'''.

===Communication between business logic - data (ORM)===

There are 3 ways to make links:

*The '''Table And Row Data Gateway'''

This is the most simple. You have one class per table and each class is a link to the table with CRUD methods (Create, Read, Update, Delete). A class instance is a record in the table. The class contains only code to reach lines and fields of table.

Example: This mode is used by some ORM Frameworks, like '''iBatis''' (http://ibatis.apache.org/).

*The '''Active Record'''

Same as previous, but we are allowed to add some business functions into the CRUD class, if such functions are dedicated to manipulate data into this table.
This pattern is known to be the most productive of the 3, as it is a very good compromise between the '''Table And Row Data Gateway''' and the '''Data Mapper'''.

Example: This mode is used for Dolibarr development and most PHP software that includes their own framework and best practices.

*The '''Data Mapper'''

Classes represent entities of the problem and not the data. So you have to double, triple ... these classes with Mapper classes to access the data.
More "purist" on paper (closer of business), this method also has the disadvantage of being more complex in practice.

Example: This is the choice if you use the ORM Framework '''Propel''' (https://propelorm.org/). We find this model in heavier applications, based on this ORM among others.

-> For Dolibarr development, the pattern used is the connection mode '''Active Record''', which offers the advantages of a model close to the business without having the complexity, without obfuscating technical architecture. It is by this way that the development, understanding of code and technical maintenance and / or business behavior seems the more productive (this is however an ongoing debate between the purists and the pragmatists, debate in which nobody can really be right, because it depends on the objectives).
[[Category:Development]]

==Design pattern for Graphic interfaces (MVC)==
There are several design patterns for user interfaces (MVC, MVP, MVVM).
Many confuse this design pattern with that of using a template framework. It's unrelated. A template framework (see previous point) is only linked to the "V" part of these models.

-> Dolibarr uses the '''MVC''' Design Pattern (Model - View - Controller). Part M (Model) is materialized by a DAO class containing the CRUD (Create-Read-Update-Delete) methods for accessing the table.
Many frameworks have chosen to put the C code part (Controller) and the V code part (View) in different files, or even separate directories. The maintenance seems easier on paper, in practice, you have to juggle constantly between a ton of files when your project become larger. In Dolibarr, the separation is made by a simple comment section. The part of code C (Controller) is therefore the code that follow the tag
<pre>
/*
* Actions
* /
</pre>
It is followed by the part of code V (Vue), well separated from the C by the tag
<pre>
/*
* View
* /
</pre>

This mode of separation has had a neutral effect on new developments but has made it possible to reduce the time required for maintenance and fixing bugs so significantly that it is not envisaged to switch to another type of separation (yes the findings made in real life are not always those expected by school theory). The important thing remains that there is always a separation between C and V, no matter how this separation is materialized, as long as it is (Reminder: Do not confuse the notion of separation of C and V with the notion of separation of the code to feed the data of a View and of the code to format the View, this a principle of separation relating to the Design Pattern of Vue, see next point).

==Design pattern for Views - Presentation==
There are frameworks that specialize in Vue Design Pattern, the part of formatting the screen seen by the user.
Old versions of Dolibarr used Smarty. This framework is an overlay to an already very powerful screen formatting framework called ... PHP. The benefits being much lower than the disadvantages, it has been abandoned in favor of PHP templates (.php files or .tpl.php files) which remain the simplest, the most universal, the most scalable and the most efficient, of the presentation frameworks we tried to use.

Its only flaw is that it cannot guarantee 100% the deviations of a developer who would integrate into the View, a logic unrelated to the presentation (therefore other than code intended for generation, formatting, HTML output , test or loop logic). This point is however controlled by the validation mechanism of the project managers' code.

Here again, it is the experience and the observation of a better productivity performance that has motivated the abandonment of the external Presentation frameworks in favor of the PHP framework.

=Rules to define branch target of a contribution=
The rules to decide if a contribution (Pull Request) must be pushed into an old maintenance branch or into development are not strict and are often defined by the good sense (pragmastism first).
We can find help on the graph found on this page [[:Category:RoadMap#Merging_PR_process_.28develop_or_maintenance_.3F.29]]

=About composer=
Composer is a tool to make deployment of PHP packages and dependenciess. Dolibarr is a PHP application that use dependencies that are PHP packages, so we could imagine to use composer to install Dolibarr.

This is not a good idea as it is just technically not possible for the following reasons:

*First, you must understand that composer is a tool '''to deploy a frozen image of a package'''. It is a tool to '''deploy''', not a tool to '''manage dependencies''' (event if some features exists for that). Dolibarr is an application that has a lot of dependencies, but for each of them, the Dolibarr project has to apply some patches to have the dependencies working correclty (for different reasons, mainly because of bugs or architecture error into original project. See the file '''dev/dolibarr_changes.txt''' for full list we have to do on each dependency). Each PHP dependency has at least one change to do to have it working correctly. So the image of a library L that Dolibarr needs is NOT the image provided into the composer package by the L project. After discussion with '''Nils Adermann''', the author of the composer package during the first OSFS congress (https://05f5.com) to get its point of view on this need for large projects, it appears that if a large project is in this situation, the good way to use composer is to build yourself a very large package called "dolibarr" with no composer dependencies and all external libraries embedded into the same composer project so we can deploy all in one composer command, confirming that composer is above all a good "fast deployment system" but a bad "dependency manager". The dependency system of composer project was simply designed to use an exact version of a library and not to use a patched version of this library. It is even designed to avoid this, making its use not possible in this context.
*Second point is a different problem with the composer dependencies system: Each dependency on a library has itself a high number of sub-dependency. And all this sub-dependencies have also a high number of dependencies that nobody can't control (there is always sub-dependencies on the libraries you use that are managed by a lower level dependency project). The result is that when you use composer to install the main library you need, you install (and you can't avoid it) a ton of other packages you don't need. For example, Dolibarr is a 80Mb project with all its PHP dependencies. If you install it with composer (we suppose that the first point is not a problem), then the project reach the size of 300 Mb. Size of project is multiplicated by 3.5 with no reason. Not sobriety compliant.
*Third point is also problems with the dependency system: When you install an external library this library has dependency and each of this depency of depencies are constraints with each other and with PHP version. Imagine the required library L1 is compatible with PHP x to x+n and the library L2 is compatible with PHP y to y+m, etc... To have an application working correctly, you must find a PHP version that will be common to all the required packages, so here inside the intersection of the two ranges [x - x+n] and [y - y+m]. But when you are using a large number of high level libraries, it means you are depending on a very large number of low level libraries (because each high level libraries has a lot of medium level libraries as dependencies that has a high number of low level dependencies). And when this number is very large, the number of different required ranges become so large that you reach a situation where the number of PHP versions that are common to all of them (hte intersection of all ranges) is very low, and even does not exists at all (there is no combination of version that is compatible with ALL packages you need because each sub-project depreciate its PHP version in its own roadmap without taking care of which child or parent dependency use it). But Dolibarr must works for everybody, whatever is other project roadmaps, and on the "as large as possible" number of PHP versions and not just on one or two given major version of PHP. Compatibiliy must also be guaranted during a very long term (an ERP is not a software we can change every year), when low level libraries are changing requirement very often.
*Last point is about security: As we view in the second point, when using composer, a very high number of PHP files are installed even if you don't need them. Dolibarr is a critical application that need a very strict security policy. Requirement for security is at a high level (See our page [[Security_information]]). When using composer, you install a lot of files and small sub-project and sub-project of sub-projects where security is not considered as important than what we need on the Dolibarr project. If we make an analysis on a given period, the number of vulnerability reported on the whole project Dolibarr + files of external libraries when installed by composer (that we mostly don't need) is multiplicated by 20 compared to the number of vulnerabilities that are reported only in the scope of Dolibarr + external libraries when they are embedded manually with the minimal number of files we need). Such an increase is simply not possible, and give a very bad mesage on security point of view: " yes we reduce 95% of known security vulnerabilities but we don't do it because we are using composer". Some companies (due to a strict security requirements of their business, like secnum or iso requirement) would simply not be allowed to use Dolibarr if we accept these.

As we can see, composer, even if it was largely adopted by a lot of small projects, is far away from the state of the art. For all this reasons, it is just not possible to use composer so we keep the composer.json file in the project so we can use it for some development tests or make upgrade tests of some libraries with it, but we have renamed it by adding the extension ".disabled" to be sure that end users won't try to install or update their Dolibarr with it, in which case, the application will become unstable (remind point 1) and unsecured (remind point 4)

Setup Other

2026-10-12T19:17:07Z

Eldy: /* Global Options */

[[fr:Paramétrage_Divers]]
[[es:Configuración_Varios]]
[[de:Erweiterte_Einstellungen]]
[[zh:其他设置]]


[[Category:Admin]]
{{TemplateDocUser}}

'''Help About Screen''': Other setup

'''Menu Path''': Home ► Setup ► Other

'''Introduction'''

Some options are not visible in the interface (often because they are deprecated or are beta features). In most cases you do not need these functions and their use may make the application unstable or may not work as expected.

{{warning|32px}} This page contains the list of some advanced development parameters. In most cases, they are parameters for internal usage, development, external modules, features in development not stable or that may lead to security risk. For standard usage of Dolibarr, such parameters '''SHOULD NOT''' be used. All experimental options are NOT supported. They may be removed in a future, modified at any version and break stability of your application.

To enable/override a parameter you have to define the constant name and set it to 1 (unless otherwise stated) in <code>Home ► Setup ► Other Setup</code>

The options here may not be documented since they are not stable and are unsupported (remember they are experimental or development options). The basic format of how the list is written is broken down in the example below:

UNSTABLE_OR_DEV_OPTION ► ''Description of config and goal'' ► ''(specific version information) or values''
<center>
__TOC__
</center>
=Global Options=

*'''ADD_UNSPLASH_LOGIN_BACKGROUND''' ► The background image will be refreshed on every login page refresh. Background image is pulled from the popular open source image website Unsplash. If an already saved static background image exists, then this code will override it (but not delete the saved image). Warning: Using this may allow this external website to steel your login credentials (the value to be put is the URL of the service, exemple : https://source.unsplash.com/random) ► (v10.0)
*'''MAIN_HIDE_POWERED_BY''' ► Hide the "Powered by Dolibarr" picto on public pages
*'''MAIN_APPLICATION_TITLE''' ► This will change the title of software (that appears on the login page by default). Warning: changing this may make Dolibarr version detection to fail by smartphone applications like [[Application Android - DoliDroid]], breaking some features when using Dolibarr from such application. If the text start with a "+", the text will be added to the standard "Dolibarr" label instead of replacing it.

*'''MAIN_AUTOFILL_DATE''' ► If this constant is defined (to something other than <code>0</code>), the date of invoice, proposal, order or payment are auto-filled with the current date. It is highly recommended to NOT ENABLE this feature. This can create a lot of input errors with data not validated by users. This leads to incorrect values saved in the database causing confusion when you have to do your accountancy reports!
*'''MAIN_AUTOFILL_DATE_PROPOSAL►'''If this constant is defined (to something other than 0), the date of proposal is auto-filled with the current date.

*'''MAIN_AUTO_TIMESTAMP_IN_PUBLIC_NOTES''' ► Add a timestamp and user automatically when editing the ''public'' note.

*'''MAIN_AUTO_TIMESTAMP_IN_PRIVATE_NOTES''' ► Add a timestamp and user automatically when editing the ''private'' note.

*'''MAIN_DEFAULT_PAYMENT_TERM_ID''' ► With ID of a payment term, will use this as default payment term each time you create a new proposal, order, invoice (customer and supplier). Deprecated. Replaced with the default setup feature instead (see French page of wiki for some exemple : [[Paramétrage Valeurs par défaut]])
*'''MAIN_DEFAULT_PAYMENT_TYPE_ID''' ► With ID of a payment type, will use this as default payment type each time you create a new proposal, order, invoice (customer and supplier). Deprecated. Replaced with the default setup feature instead (see French page of wiki for some exemple : [[Paramétrage Valeurs par défaut]])

*'''MAIN_DEFAULT_LANGUAGE_FILTER''' ► Useful if you do not want to show <code>en_US</code> language option in combo boxes (other languages can easily be removed in <code>langs</code> directory but not <code>en_US</code>) ► (v10.0)

*'''MAIN_LANGUAGES_ALLOWED''' ► Is a list of languages without spaces, example : <code>fr_FR,en_US,de_DE,it_IT</code> If defined, only those languages will appear in combos. ► (v11.0)

*'''MAIN_DISABLE_NOTES_TAB''' ► Show or hide notes tab in the card page

*'''MAIN_DISABLE_CONTACTS_TAB''' ► Show or hide contacts tab in the card page

*'''MAIN_DISABLE_FULL_SCANLIST''' ► Disables the complete scan of tables to allow the pagination to show total number of pages. May be useful to activate on systems with a very high quantity of data (tables with more than 2 000 000 records).

*'''MAIN_DISABLE_JQUERY_JNOTIFY''' ► Disable usage of <code>JNotify</code> to show confirm or error messages

*'''MAIN_DISABLE_AJAX_COMBOX''' ► If you have a large number of third parties or products, you can disable the autocomplete feature on the third parties list by setting this constant to <code>1</code> ► (v3.6.0+)
*'''MAIN_DISABLE_MULTIPLE_FILEUPLOAD''' ► Disable users to upload multiple files at once.
*'''MAIN_DISABLE_TRUNC''' ► Disable all truncings in select list. ► (v7.0+)

*'''MAIN_DISABLEDRAFTSTATUS''' ► Disable the status "Draft" for some objects (project, donation, ...) so the object is directly created with status "Validated"

*'''MAIN_DOC_USE_OBJECT_THIRDPARTY_NAME''' ► Add name of thirdparty at begin of generated document.

*'''MAIN_DOC_USE_TIMING''' ► Add a timestamp at end of generated document. Value must be format of timestamp. For example: <code>%Y%m%d%H%M</code> (only for ODT files)

*'''MAIN_DOC_UPLOAD_NOT_RENAME_BY_DEFAULT''' ► Disable the auto renaming on upload file ► (v10.0)

*'''MAIN_DOL_SCRIPTS_ROOT''' ► Define directory who contains 'scripts' directory (e.g. <code>/var/www/dolibarr</code>). Value of this variable may be requested by some external script or tools.

*'''MAIN_ENABLE_LOG_TO_HTML''' ► If this constant is defined, it is possible to have logs inside pages by adding the parameter <code>&logtohtml=1</code> into URL.

*'''MAIN_ENABLE_IMPORT_LINKED_OBJECT_LINES''' ► Allow to import lines into current document from "linked" compatible documents ► (v8.0+)

*'''MAIN_FIRST_TO_UPPER''' ► Dolibarr add uppercase to Third Parties, contacts or members names if not done. Warning: with some languages (whose words with uppercase are not same words, or pagecode does not always have an uppercase, like Cyrillic languages), this feature may alter your data.

*'''MAIN_ALL_TO_UPPER''' ► Dolibarr puts uppercase for Third Parties, contacts or members names if not done. Warning, with some languages (whose words with uppercase are not same words, or pagecode does not always have an uppercase, like Cyrillic languages), this feature may alter your data. ► (v11.0)

*'''MAIN_ALL_TOWN_TO_UPPER''' ► Dolibarr puts uppercase for town names if not done. ► (v13.0)

*'''MAIN_FILESYSTEM_ENCODING''' ► With some PHP versions, PHP is not able to detect the page code for filesystem of the server OS. To solve this, Dolibarr assumes your OS filesystem is <code>UTF-8</code> if on Linux or OSX system, and <code>ISO-8859-1</code> if on Windows. If not, for example on a Windows server with a NTFS <code>UTF-8</code> pagecode, you can set the variable <code>MAIN_FILESYSTEM_ENCODING</code> to "<code>utf-8</code>".

*'''MAIN_FORCELANGDIR''' ► Relative path of the directory holding your custom <code>langs</code> folder.
*'''MAIN_HTML_TITLE''' ► Can be used to control how the html page title is formatted. If value contains key '<code>noapp</code>', application name will not be output. If value contains '<code>thirdpartynameonly</code>', on tab for thirdparties, only name of thirdparties are output. Value can be list of tags: '<code>noapp;thirdpartynameonly</code>'

*'''MAIN_HELPCENTER_LINKTOUSE''' ► Define the URL link to use as the target page for link "I need help" onto logon page

*'''MAIN_LOGOUT_GOTO_URL''' ► URL to which the user will be redirected after LOGOUT

*'''MAIN_MAXTABS_IN_CARD''' ► Maximum number of tabs visible. Others are grouped into a combo list.

*'''MAIN_MAXLIST_OVERLOAD''' ► Maximum number of line in space's domain.

*'''MAIN_MIN_NB_ENABLED_MODULE_FOR_WARNING''' ► A warning saying setup of modules is not complete is shown if the number of enabled modules is lower or equal than this value (<code>1</code> if not defined)

*'''MAIN_NO_CONCAT_DESCRIPTION''' ► Allow to use only input custom description in lines (proposal, order, invoice) ► (v10.0) < v20.0. [ OSBOLETE since 20.0 | SEE Product module admin configuration to set the description behavior of products and services ]. This value is overwritten by PRODUCT_AUTOFILL_DESC, controled by the option in the product module admin configuration, and is no longer used. Kept in code to allow compatibility if custom modules are using it. Removed completely from v22.

*'''MAIN_OPTIMIZE_SPEED''' ► Use some speed enhancements. See page [[FAQ Increase Performance]] for more information.
*'''MAIN_PASSWORD_FORGOTLINK ►''' Change forgotten password link on login page. ► (v9.0)

*'''MAIN_PROPAGATE_CONTACTS_FROM_ORIGIN''' ► When creating an order, contract, invoice from another object, specific contacts of objects are set as specific contact of the new object when possible. ► (v4.0+)

*'''MAIN_PUBLIC_NOTE_IN_ADDRESS''' ► Show public note in address block ► (v4.0+)

*'''MAIN_REMOVE_INSTALL_WARNING''' ► Remove all security warnings that appear to administrator users if URL <code>/install</code> is public. You should solve the problem if warning occurs, instead of removing the warning! For this, create a file called <code>install.lock</code> into Dolibarr root directory. This will stop the warning but also make the page <code>/install</code> not possible to use, to protect your installation.

*'''MAIN_REPEATCONTACTONEACHTAB''' ► If added and set to <code>1</code>, this adds contacts on all tabs, not only main tab.

*'''MAIN_REPLACE_TRANS_xx_XX''' ► Where <code>xx_XX</code> is language code. If value is <code>string1:newstring1;string2:newstring2</code> then replace <code>string1</code> with <code>newstring1</code> in all translation done for language <code>xx_XX</code>.

*'''MAIN_ROUNDOFTOTAL_NOT_TOTALOFROUND''' ► Change way of rounding total including tax of lines, rounding first of after.

*'''MAIN_ROUNDOFTOTAL_NOT_TOTALOFROUND_SUPPLIER'''► Change way of rounding total including tax of lines, rounding first of after.

*'''MAIN_SERVER_TZ''' ► If you can't set the time zone of your PHP installation, set this constant. Better is to set it to UTC. In future, this constant will be forced to '<code>UTC</code>' so PHP server time zone will not have effect any more. Examples: <code>Europe/Paris</code>, <code>auto</code>. Dolibarr will apply the timezone before saving dates in the database. Meaning that if you remove the parameter the dates saved will not change back to UTC.

*'''MAIN_SEARCH_FORM_ON_HOME_AREAS''' ► Show the search form on home page areas for core modules (Removed after v5 due to global search combo) ► (v6.0+)

*'''MAIN_SEARCHFORM_SUPPLIER_INVOICE_DISABLED''' ► Disable the supplier invoice on the search form

*'''MAIN_SEARCH_DIRECT_OPEN_IF_ONLY_ONE''' ► If only one result is found, then setting this value to <code>1</code> will take you direct to the item (default method). Setting the value to <code>0</code> will show the result in the list as a single result ► (v5.0+)

*'''MAIN_SERVICES_ARE_ECOMMERCE_200238EC''' ► If seller and buyer are in Europe and buyer is not a company, use the VAT of buying country. It can have value '1' or '2'. If value 2, the VATs available to select only the ones of buying country. If '1', the VATs available to select mix the ones of selling country and the ones of buying country. ► (v18.0+)

*'''MAIN_SHOW_TUNING_INFO''' ► Add tuning information into JavaScript console. Better when xdebug is enabled.

*'''MAIN_SHOW_TECHNICAL_ID''' ► Show also technical IDs on elements cards or some lists (not supported everywhere).

*'''MAIN_SHOWDATABASENAMEINHELPPAGESLINK''' ► Show database name in upper help menu ► (v8.0+)

*'''MAIN_USE_ALTERNATE_TRANSLATION_FOR''' ► List of fields per object that need an alternate translation. Example: <code>MAIN_USE_ALTERNATE_TRANSLATION_FOR=societe:name,town;contact:firstname,lastname</code>

*'''MAIN_USE_HOURMIN_IN_DATE_RANGE''' ► On all entities lines (invoice, order, contract...), it is possible to add hour and minutes with date on fields "date start" and "date end".

*'''MAIN_USE_JQUERY_JEDITABLE''' ► Allow to update from screen, directly into database, some properties of elements (invoices, proposals, ...) using Ajax. This make response time faster, but avoid using this feature, because it bypasses some business actions (updates on other data that should be done consistently) and ignores business controls on data you saved. Consequently this feature breaks consistency of data and possibly the stability of the software.

*'''MAIN_USE_JQUERY_MULTISELECT''' ► Allow to use Ajax when a choice that require multiselect is used (for the moment only external modules uses select box with multiselect values). Set the value to the jQuery plugin name to use (multiselect, multiple-select, select2…). Setting it to any other value will result in unwanted side-effects and/or bugs.

*'''MAIN_USE_OLD_SEARCH_FORM''' ► Display the old search form in left menu.

*'''MAIN_VAT_DEFAULT_IF_AUTODETECT_FAILS''' ► Allow to force the VAT rate to a given value (instead of higher VAT rate of country) if the VAT rate of product was not defined.

*'''MAIN_UNKNOWN_CUSTOMERS_ARE_COMPANIES''' ► If we can't guess if a thirdparty is a company or individual (not VAT ID fill, no Prof ID fill, no type of thirdparty fill), then we suppose it is a company (B2B business) if 1, we suppose it is an individual (B2C business) if 0.

*'''MAIN_USE_VAT_COMPANIES_IN_EEC_WITH_INVALID_VAT_ID_ARE_INDIVIDUAL''' ► For intra CEE sales, we use by default, on proposal, order or invoice creation, a 0 VAT for customers that are companies (see MAIN_UNKNOWN_CUSTOMERS_ARE_COMPANIES to change behaviour to know if a thirdparty is a company or an individual). But if the option MAIN_USE_VAT_COMPANIES_IN_EEC_WITH_INVALID_VAT_ID_ARE_INDIVIDUAL is set, we will use the 0 VAT only if a VAT ID is defined for the customer.

*'''MAIN_USE_VAT_OF_PRODUCT_FOR_INDIVIDUAL_CUSTOMER_OUT_OF_EEC''' ► For to use the default VAT of product for individual customers that are out E.E.C. (European Economic Community) ► (v7.0+). ''There is no reason to use this.''

*'''MAIN_VIEW_LINE_NUMBER''' ► Shows a line number for each line of products/services at documents like proposal / order / invoice. Only on screen, not on PDF (available with PDF_ADD_POSITION).

*'''MAIN_VIEW_LINE_NUMBER_IN_LIST''' ► Shows a line number in lists ► (v12.0)

*'''MAIN_VOLUME_DEFAULT_ROUND''' ► Accuracy of volume (number of decimals)

*'''MAIN_VOLUME_DEFAULT_UNIT''' ► Default unit for weight (<code>0=kg</code>, <code>-3=g</code>, ...)

*'''MAIN_WEIGHT_DEFAULT_ROUND''' ► Accuracy of weight (number of decimals)

*'''MAIN_WEIGHT_DEFAULT_UNIT''' ► Default unit for weight (<code>0=kg</code>, <code>-3=g</code>, ...)

*'''USER_HIDE_INACTIVE_IN_COMBOBOX''' ► Disable display inactive users in combobox.

*'''MAIN_DISABLE_PDF_THUMBS''' ► Disable the thumbs PDF (used for preview on screen). Can be used in case of imagick bug or non availability

*'''MAIN_KEEP_REF_CUSTOMER_ON_CLONING''' ► Keep the Customer Reference on cloned object (Propal/Invoice)

*'''MAIN_DONT_KEEP_NOTE_ON_CLONING''' ► Remove the object notes during cloning ► (v11.0)

*'''MAIN_DOC_SORT_FIELD''' ► Set the default sorting field on document page (name by default) ► (v11.0)

*'''MAIN_DOC_SORT_ORDER''' ► Set the default sorting order (ASC or DESC) on document page (ASC by default) ► (v11.0)

*'''MAIN_USE_ZIPTOWN_DICTIONNARY''' ► Use dictionary ZIP for create card.

*'''MAIN_USE_TOP_MENU_SEARCH_DROPDOWN''' ► Show search in top menu with theme eldy ► (v11.0)

*'''MAIN_PHONE_SEPAR''' ► Separ phone number other space ► (v12.0)

*'''GRAPH_USE_FISCAL_YEAR''' ► Widgets uses fiscal year

*'''SHOW_SOCINFO_ON_PRINT''' ► Permit to add user company information on each printed document (when click on Dolibarr print button) ► (v12.0)

*'''MAIN_FEATURES_LEVEL''' ► Level of features to show: <code>-1=stable+deprecated</code>, <code>0=stable only (default)</code>, <code>1=stable+experimental</code>, <code>2=stable+experimental+development</code>

*'''MAIN_SHOW_TECHNICAL_ID''' ► Show technical id for object.

*'''MAIN_HTTP_CONTENT_SECURITY_POLICY''' ► Allows you to fill in the content security rules ► (v6.0)

*'''SOCIETE_ON_SEARCH_AND_LIST_GO_ON_CUSTOMER_OR_SUPPLIER_CARD''' ► Allow to change the link of the third party to customer/supplier card instead of contact card on List.

*'''MAIN_MODULE_SETUP_ON_LIST_BY_DEFAULT''' ► If set to "common" the setup module becomes list by defaut

*'''MAIN_PAGESIZE_CHOICES''' ► Configure select field to choose number of lines displayed on listing (<code>10:10,15:15,20:20,30:30,40:40,50:50,100:100,250:250,500:500,1000:1000,5000:5000</code>).

*'''MAIN_USE_TOP_MENU_QUICKADD_DROPDOWN''' ► Add a dropdown menu with shortcuts to create new objects ► (v13.0)

*'''MAIN_EMAILCOLLECTOR_MAIL_WITHOUT_HEADER''' ► Remove the header stored by email collector ► (v13.0)

*'''MAIN_USE_VAT_OF_PRODUCT_FOR_COMPANIES_IN_EEC_WITH_INVALID_VAT_ID'''

*'''MAIN_OPTIMIZEFORTEXTBROWSER''' ► Optimise interface for a text only browser. This variable is set to 1 automatically if your browser is lynx or links

*'''MAIN_NB_OF_YEAR_IN_WIDGET_GRAPH''' ► Set the number of years visible on some graph of some widgets (2 is default value)

*'''MAIN_CREATEFROM_KEEP_LINE_ORIGIN_INFORMATION'''

*'''API_DISABLE_LOGIN_API''' ►(v14.0)

*'''MAIN_LOGIN_BADCHARUNAUTHORIZED''' ► Add possibility to define bad character unauthorized into login name REGEX expression (Default value is @<>"\') ► (v16.0)
*'''MAIN_SHOW_ALL_FILES_ON_DOCUMENT_TOOLTIP''' ► Add all files visible from the object to be visible from the list of object.
*'''MAIN_LIST_ALLOW_PUBLIC_NOTES''' ► Display public notes on list
*'''MAIN_LIST_ALLOW_PRIVATE_NOTES''' ► Display private notes on list

*'''MAIN_CHECKBOX_LEFT_COLUMN''' ► Display private check boxes on the left ► (v17.0)
*'''MAIN_STATS_GRAPHS_SHOW_N_YEARS''' ► Nb of years to shows in widget and graph ► (v14.0)
*'''MAIN_HOOK_DEBUG''' ► if >=2 the hook in the logs are more verbose ► (v18.0)

*'''MAIN_ENABLE_AJAX_TOOLTIP''' ► if 1 the tooltips are updated with AJAX request ► (v18.0)
*'''MAIN_NO_INPUT_PRICE_WITH_TAX''' ► if 1 the TTC input field is removed from propal/invoices/... ► (v17.0)

*'''MAIN_DISABLE_SELECT2_FOCUS_PROTECTION''' ► if 1 disable the focus protection ► (v17.0)
*'''MAIN_USE_ADVANCED_PERMS ►''' Add advanced user permission

*'''MAIN_FREE_PRODUCT_CHECKED_BY_DEFAULT ►''' Check "product" or "service" by default on order/invoices/propal cards (set value "product" or "service")
*'''MAIN_LINK_BY_REF ►''' Allow to link documents by choosing the type and ref from the object linked option
*'''MAIN_STORE_COMPUTED_EXTRAFIELDS ►''' when enabled, computed extrafields have their formula result evaluated and persisted to the database on save (instead of the default behavior where the formula is re-evaluated on the fly at each display and the column is left null).

'''Official supported option'''

The following options are not hidden option. They are available by default from the interface.

*'''MAIN_ONLY_LOGIN_ALLOWED ►''' Activate maintenance mode and set user that is allowed to login. Value must be user login. Available into menu Home - Admin tools - User session, it is filled with admin user when clicking on button "Block other session". Enable <code>MAIN_STORE_COMPUTED_EXTRAFIELDS</code> when you need to sort, filter, sum or report on a computed extrafield's value in SQL/lists: instead of recalculating the formula on every display (leaving the column null), it stores the result in the database on each save, at the cost of the value being a snapshot that only refreshes when the record is saved again.

[[#Top|(back to top)]]

=Security Options=

*'''MAIN_SECURITY_ANTI_SSRF_SERVER_IP''' ► Can set a complete list of IPs of server.

*'''MAIN_SECURITY_CSRF_WITH_TOKEN''' ► Activate a second anti-CSRF protection on POST (so a POST from another web site can't be done). Note there is also a default protection using test on referrer that is not reliable. This second protection uses TOKEN on forms and is more powerful. Value can be: 0=CSRF protection disabled; 1=CSRF protection is on POST URLs only (default from version Dolibarr 15.0+); 2=CSRF protection is required on POST + some GET URL that contains some white listed parameters like the parameter "action" used to request database change (default from version Dolibarr 16+), 3=CSRF protection is enabled on any POST and GET URLs (a valid CSRF token is expected whatever are the parameters, warning: can be enabled on Dolibarr but some external modules developped by thirdparty may not be ready yet with this option)

*'''MAIN_MODULES_FOR_EXTERNAL''' ► Limit available modules for external users. By default value is '<code>facture,commande,contact,propal,projet,contrat,societe,ficheinter,expedition,agenda</code>'

*'''MAIN_ALLOW_SVG_FILES_AS_IMAGES''' ► Allow to use SVG file as image files. Warning: This may introduce security vulnerability (javascript can be embedded into SVG file).

*'''MAIN_RESTRICTHTML_ONLY_VALID_HTML''' ► Refused parameter if value is not a valid HTML content. The content is also sanitized with Tidy.

*'''MAIN_RESTRICTHTML_ONLY_VALID_HTML_TIDY''' ► Refused parameter if value is not a HTML content validated by Tidy PHP library. The content is also sanitized with Tidy.

*'''MAIN_RESTRICTHTML_REMOVE_ALSO_BAD_ATTRIBUTES''' ► Sanitize also non standard attributes on HTML content.
*'''MAIN_SECURITY_SALT''' ► A salt string to base the hashing on. 8 strings length recommended.

*'''MAIN_SECURITY_MAX_IMG_IN_HTML_CONTENT''' ► Maximum number of Images on the HTML content
*'''MAIN_SECURITY_ALLOW_UNSECURED_LABELS_WITH_HTML''' ► Allow HTML tags into products label

*'''MAIN_SECURITY_FORCERP''' = "strict-origin-when-cross-origin" (default) so browser doesn't send any referrer when going into another web site domain / "same-origin" / "strict-origin"

[[#Top|(back to top)]]

=Members Module=

*'''MEMBER_NEWFORM_FORCEMORPHY''' ► Force nature of member set to "phy" for physical or to "mor" for moral ► (v12.0)
*'''MEMBER_ALLOW_CHANGE_OF_TYPE''' ► Member can edit their type on public subscription page ► (v13.0)
*'''ADHERENT_DEFAULT_CREATE_THIRDPARTY''' ► Thirdparty is created when creating a new member ► (v13.0)
*'''MEMBER_SUBSCRIPTION_SUGGEST_END_OF_MONTH''' ► If set to 1, the member subscription end date will be suggested for the end of the month ► (v18.0)
*'''MEMBER_SUBSCRIPTION_SUGGEST_END_OF_YEAR''' ► If set to 1, the member subscription end date will be suggested for the end of the year ► (v18.0)
*'''MAIN_NB_OF_YEAR_IN_MEMBERSHIP_WIDGET_GRAPH''' ► If set, it limits the number of years visible on graph and widgets of membership (empty is default value to show all) ► (v18.0)
*'''MEMBER_NO_SYNC_LINKED_THIRDPARTY ►''' If set, changes to a member will not be synchronized to a linked third party. ► (v23.0)

[[#Top|(back to top)]]

=Accounting Module=

*'''ACCOUNTANCY_COMBO_FOR_AUX''' ► Add graphic option for ACCOUNTANCY_COMBO_FOR_AUX. Having this option on may slow down and even freeze the accounting features if you have a very large number of thirdparties ► (v10.0)
*'''ACCOUNTING_DEFAULT_NOT_NOTIFIED_VALIDATION_DATE''' ► Avoid validating the lines with the accountancy export.(1= box unchecked by default / 0 = box checked by default) ► (v14.0)
*'''ACCOUNTING_DEFAULT_NOT_NOTIFIED_EXPORT_DATE''' ► Avoid flagging the lines as exported with the accountancy export.(1= box unchecked by default / 0 = box checked by default) ► (v14.0)
*'''ACCOUNTANCY_USE_PRODUCT_ACCOUNT_ON_THIRDPARTY ►''' Add 2 fields on thirdparty card which allow you to set an account for all sells products and an other for all buying products for this customer ► (v14.0)
*'''ACCOUNTING_MANAGE_ZERO''' '''►''' Allow to manage char 0 in accounting account (if enabled 1 ≠ 10) ► (v14.0)

[[#Top|(back to top)]]

=Agenda Module=

*'''AGENDA_ALL_CALENDARS''' ► Change the default view of calendar pages to see all the Agenda's (instead or yours only be default)

*'''AGENDA_AUTOSET_END_DATE_WITH_DELTA_HOURS''' ► To automatically set end date of event to start date + delta on event creation page.

*'''AGENDA_DISABLE_LOCATION''' ► Disable location field in action card ► (>=v5.0)

*'''AGENDA_MAX_EVENTS_DAY_VIEW''' ► Define the maximum number of visible entries for each day in agenda. Default value is 3. Value 0 means no limit.

*'''AGENDA_USE_EVENT_TYPE''' ► Add a mandatory field "Type" when creating an event ('''''deprecated''''').

*'''MAIN_ADD_EVENT_ON_ELEMENT_CARD''' ► Allow to create an event from a document (proposal, order, invoice)

*'''AGENDA_SUPPORT_PRIORITY_IN_EVENTS''' ► Allow to have priorities in events ► (>=v13.0)

*'''AGENDA_ADDACTIONFORPHONE''' ► Allow you to create a event from phone number ► (=<v12.0) - Need to be fix for (=>v12.0) https://github.com/Dolibarr/dolibarr/issues/22720

*'''AGENDA_ADDACTIONFOREMAIL''' ► Allow you to create a event from Email ► (=<v12.0) - Need to be fix for (=>v12.0) https://github.com/Dolibarr/dolibarr/issues/22720
*'''MAIN_ACTIONCOM_CAN_ADD_ANY_CONTACT''' ► Allow you to add any contact on events if set at 1a https://github.com/Dolibarr/dolibarr/releases/tag/18.0.0

[[#Top|(back to top)]]
=Bank Module=

*'''BANK_CAN_RECONCILIATE_CASHACCOUNT''' ► Can reconciliate cash accounts ► (v3.8)

*'''BANK_DISABLE_CHECK_DEPOSIT''' ► Disable check deposit feature

*'''BANK_ASK_PAYMENT_BANK_DURING_ORDER''' ► Ask bank account during creation of an order

*'''BANK_ASK_PAYMENT_BANK_DURING_PROPOSAL''' ► Ask bank account during creation of a proposal

*'''BANK_USE_OLD_VARIOUS_PAYMENT''' ► To allow to enter miscellaneous payments (not covered by other modules) using old method. '''''Deprecated'''''. Entering various payment is preferred ► (<=v12.0).
*'''MAIN_IBAN_IS_NEVER_MANDATORY''' ► IBAN and BIC informations not mandatory. (V15)

[[#Top|(back to top)]]

 

=BOM and MO Module=

*'''ALLOW_USE_KITS_INTO_BOM_AND_MO'''
*'''BOM_SUB_BOM''' ►Allow to add a BOM in another BOM►(v16.0)

[[#Top|(back to top)]]

 

=Bookmarks Module=

*'''BOOKMARKS_SHOW_IN_MENU''' ► Numbers of bookmark entries to be displayed (10 by default)

[[#Top|(back to top)]]

 

=Inalterable Log Module=

*'''BLOCKEDLOG_ADD_ACTIONS_SUPPORTED''' ► Can complete list of triggered action that are logged
*'''BLOCKEDLOG_USE_REMOTE_AUTHORITY''' ► URL of the remote authority for the blockchain

[[#Top|(back to top)]]

 

=Category-Tags Module=

*'''CATEGORY_SHOW_COUNTS''' ► Shows nb of object by tags in tag tree
*'''CATEGORY_EDIT_IN_MENU_NOT_IN_POPUP ►''' Display categories menu instead of managing it only from "Tools"

[[#Top|(back to top)]]

 

=Contracts=

*'''CONTRACT_SUPPORT_PRODUCTS''' ► Products are also suggested into module contract.
*'''CONTRACT_ALLOW_EXTERNAL_DOWNLOAD''' ► When a PDF is generated, a share key is automatically set so the file can be downloaded using the share key. ► (v7.0+)
*'''CONTRACT_HIDE_PLANNED_DATE_ON_PDF''' ► allows you to not display dates on pdf files.
*'''CONTRACT_HIDE_REAL_DATE_ON_PDF''' ► allows you to not display dates on pdf files.
*'''CONTRACT_HIDE_PRICE_ON_PDF''' ► allows you to not display price on pdf files.
*'''CONTRACT_HIDE_QTY_ON_PDF''' ► allows you to not quantity dates on pdf files.
*'''CONTRACT_SHOW_SIGNATURE_STATUS_WITH_SERVICE_STATUS''' ► Show signature status in contract card (Sign by all parties).► (v21.0+)

[[#Top|(back to top)]]

=Cron module=

*'''CRON_DISABLE_KEY_CHANGE''' ► When you provide an instance to a customer, you probably also add an entry in the cron of this user so Dolibarr batch and scheduler can work correctly. For security purpose, it may have a security key that is inside the command line into the cron entry and this entry must match the value defined into Dolibarr setup (setup of module 'Scheduled Jobs'). Because, a customer of a Saas platform will probably have no access to edit the cron file, it is also import that he has no way to edit the key into the Dolibarr setup, so the key in the cron command line will always match the key in Dolibarr setup, and the Dolibarr batches will executed without security errors. To be sure, the customer does not change the value, you can set this constant to 1 into the table [[Table_llx_const]].

*'''CRON_DISABLE_TUTORIAL_CRON''' ► Disable the tutorial about how to install the cron script (on a SaaS hosting, this should be done by the web hosting provider)

*'''CRON_WARNING_DELAY_HOURS''' ► Set this value to the frequency set for the cron script (so a warning will be shown to user to warn it about max frequency of its scheduled jobs)

[[#Top|(back to top)]]

 

=Direct Debit Orders=

*'''WITHDRAWAL_ALLOW_ANY_INVOICE_STATUS''' ► If this option is set, all invoices status (even already paid) may appear on the list of invoices qualified for a direct debit payment. This is the list of invoices with a payment request done, and not linked to a direct debit payment. By default, only "unpayed" invoices are used to avoid to pay twice the same invoice.

[[#Top|(back to top)]]

=Donation Module=

*'''DONATION_USE_THIRDPARTIES''' ► If this option is set, a thirdparty field appear on donation forms.

[[#Top|(back to top)]]
=Email=

*'''MAIN_COPY_FILE_IN_EVENT_AUTO''' ► Add attachment document on event auto generated by sending email from dolibarr. ► (v6.0+)

*'''MAIN_EMAIL_USE_LAYOUT'''► Enable the use of predefined layout when writing an email.

*'''MAIN_MAILFORM_DISABLE_ENTERKEY''' ► Activate JavaScript code to disable the enter key in the MAIL form. ► (>= 8.0.1)

*'''MAIN_MAIL_DEBUG''' ► Write content with header of last mail into file <code>dolibarr_mail.log</code> into directory <code>dolibarr_main_data_root</code>.

*'''MAIN_MAIL_DEBUG_ERR_WITH_DATE''' ► Use a different filename (by adding a prefix of date) for each email sent with error when MAIN_MAIL_DEBUG.

*'''MAIN_MAIL_DEBUG_LOG_WITH_DATE''' ► Use a different filename (by adding a prefix of date) to log each email sent (whatever is result) when MAIN_MAIL_DEBUG.

*'''MAIN_MAIL_FORCE_FROM''' ► (v19+) Can force the value into the From field of the SMTP header. Note that email sender is always saved into the "Reply-To".

*'''MAIN_MAIL_ALLOW_SENDMAIL_F''' ► On Linux or BSD system, PHP email function use the command sendmail local to server. In some cases, the sender email must be provided on command line of sendmail with option <code>-f</code>. This option is here to ask Dolibarr to call the function mail of PHP by adding value for the option <code>-f</code>. Note that in most cases, even with sendmail, sender email is correctly managed as it is added in the email technical header. This option is here only for setup or version of sendmail that ask the -f option to be mandatory or for sendmail setup that does not use by default the From of the header email to define the sender (with this option, the from can be forced on command line to avoid to have the from lost by sendmail).

*'''MAIN_MAIL_SENDMAIL_FORCE_BA''' ► On Linux or BSD system, PHP email function use the command sendmail local to server. In some case, we want to recipient to be provided to sendmail into the email content instead of its command line parameter. For this we must add the -ba parameter to sendmail. This option asks PHP to provide this parameter when sending a mail. Note that another solution is to edit the mail.force_extra_parameters=-ba into <code>php.ini</code> file.

*'''MAIN_MAIL_NO_FULL_EMAIL''' ► Recipient email and sender are cleaned to be on form "<email>" instead of "Name <email>". This might solve problem of compatibility with very old mailers.

*'''MAIN_FIX_FOR_BUGGED_MTA''' ► Some MTA agent are bugged and add some CR chars each time they saw a LF. Because Dolibarr emails are forged to be already cleaned, if MTA agent do that, you will send an email with two CR chars. This may result in having recipient not able to read your email. To fix this, add this constant to 1. Dolibarr will then create an email that is not RFC compliant, but because the MTA agent is bugged, the email will be modified and become correct during sending, solving the problem of bad email received. Add this constant to 1 if your recipient experience problems when opening email for example users using webmail of <code>orange.fr</code> or <code>hotmail.com</code>. Note that some users have reported that when using Exim (Exim 4), you must set this parameter to 0. Default value is 1 but may be changed to 0 in future.

*'''MAIN_MAIL_DO_NOT_USE_SIGN''' ► Do not add user signature at end of suggested pre-defined email

*'''MAIN_MAIL_FORCE_NOT_SENDING_TO''' ► If en email is defined into this variable, emails will never be sent to this email.

*'''MAIL_FORCE_DELIVERY_RECEIPT_INVOICE''' ► Set default as "Yes" on requesting delivery receipt when sending email through the ''Customer Invoice'' module.

*'''MAIL_FORCE_DELIVERY_RECEIPT_ORDER''' ► Set default as "Yes" on requesting delivery receipt when sending email through the ''Customer Order'' module.

*'''MAIL_FORCE_DELIVERY_RECEIPT_PROPAL''' ► Set default as "Yes" on requesting delivery receipt when sending email through the ''Customer Proposal'' module.
*'''MAIL_FORCE_DELIVERY_RECEIPT_SUPPLIER_PROPOSAL''' ► Set default as "Yes" on requesting delivery receipt when sending email through the ''Supplier Proposal'' module.

*'''MAIN_EMAIL_SUPPORT_ACK ►''' Restore email acknowledgment checkbox on sending emails. This feature is commonly abandoned by mailers. Active from Dolibarr V17 - see [https://github.com/Dolibarr/dolibarr/blob/33744f74da1a5c20f8aa9950018ab4e549e00205/ChangeLog#L53 changelog]
*'''MAIN_EMAIL_USECCC''' ► 1 = Shows field BCC into email forms, If value is an email = Shows the BCC pre filled with the email value.

*'''MAIN_MAIL_AUTOCOPY_PROPOSAL_TO''', '''MAIN_MAIL_AUTOCOPY_ORDER_TO''', '''MAIN_MAIL_AUTOCOPY_INVOICE_TO''', '''MAIN_MAIL_AUTOCOPY_SHIPMENT_TO''', '''MAIN_MAIL_AUTOCOPY_..._TO''' ► Email to use as a BCC recipient when sending email for proposal, order or invoice. You can make this value visible by setting MAIN_EMAIL_USECCC (to 1 or to another email, see previous point)

*'''MAIN_EMAIL_ADD_TRACK_ID''' ► When value is 1 (this is also default value if option is not set): The record "Message-id" added into smtp header includes a tracking id to define where the email was sent from. When value is 2: you send an email from third party card, the sender email is completed with the email source tracking string "+thiXXX" on email (your email will be sent with the "From" that is myname+thi123@mycompany.com). So when user receiving email will make "Answer", email will be sent to myname@mycompany.com but with the tracking id included (into header or into target email), allowing you to know to which third party or object, the email exchange is related to.

*'''MAIL_MAX_NB_OF_RECIPIENTS_IN_SAME_EMAIL''' ► Restrict sending of 1 email message to <code>x</code> recipients for same email message (x for To: + CC: + BCC:). If not defined, value is <code>10</code>. Required to fight against spamming that include 1000 recipients in 1 message. Note that '''MAIL_MAX_NB_OF_RECIPIENTS_TO_IN_SAME_EMAIL''', '''MAIL_MAX_NB_OF_RECIPIENTS_CC_IN_SAME_EMAIL''' and '''MAIL_MAX_NB_OF_RECIPIENTS_BCC_IN_SAME_EMAIL''' are also available.

*'''MAIN_MAIL_FORCE_CONTENT_TYPE_TO_HTML''' ► Force to send all email (event with text only content) as HTML formatted email.

*'''MAIN_MAIL_USE_MULTI_PART''' ► Forge email content using an alternate text part ► (for 5.0.2+). By default with 6.0+
*'''MAIN_INFO_SOCIETE_MAIL_ALIASES''' ► add address aliases for the from field on mail. Set his value with "Firstname Name <firstname.lastname@mydomain.tld, Otherfirstname OtherlastName <othermail@mydomain.tld>,..." ► (v5.0.0+)

*'''MAIN_MAIL_ADD_INLINE_IMAGES_IF_IN_MEDIAS''' ► If images were stored into the medias directory from CKEditor, then images into emails are replaced with "inline content". This may increase seriously risk of being detected as SPAM.

*'''MAIN_EXTERNAL_SMTP_CLIENT_IP_ADDRESS''' ► (A better name of this option should be MAIN_EXTERNAL_MAIL_CLIENT_IP_ADDRESS). Set here the list of IPs where your Dolibarr instances are hosted. You can also set the URLs where to get the IP addresses, for exemple: "https://ipv4.urltoshowip.com/_service_showmyip.php,https://ipv6.urltoshowup.com/_service_showmyip.php. So when your customer go into the setup area of email:
**If he chose mail method, a message will explain him how to setup its SPF record for its email domain (showing the list of IP). This is to avoid to have its emails, sent from its Dolibarr instance, fails due to strict antispam rule of some emailing servers.
**If he chose smtp method, a message will explain him the list of IP he can use if there is restriction on IP by the SMTP agent. If you also need to add a message to help SPF setup, see option '''MAIN_EXTERNAL_SMTP_SPF_STRING_TO_ADD'''.

*'''MAIN_IMAP_USE_PHPIMAP''' ► Use embedded PHP-imap library (not using the native php imap) instead of native php imap extension ► (v17.0+, available as official option in setup of emailcollector by default from v19)

*'''MAIN_MAIL_ENABLED_USER_DEST_SELECT''' ► Show also internal users into list of recipients of email in email sending form ► (v8.0+)

*'''MAIL_PREFIX_FOR_EMAIL_ID''' ► Prefix for the mails ID. Default value is <code>$_SERVER["SERVER_NAME"]</code> ► (>= 8.0.1)
*'''MAIL_MASS_ACTION_SEARCH_MOST_RECENT_FILE_IF_NOT_FOUND''' ► When sending an email from a mass action. If the path saved in DB does not point to an existing file, then search for the most recent file and use it as an attahcment.► (>= 24.0.0)

[[#Top|(back to top)]]

=Emailing Module=

*'''MAILING_PREFIX_FOR_EMAIL_ID''' ► Set the value that will be used to compose the "Email ID" into email headers. If you set this value to '<code>SERVER_NAME</code>', the virtual host of web server will be used. By default, this is not defined, so a hash key, unique to each instance, is used.

*'''MAILING_NO_USING_PHPMAIL''' ► If set, the module emailing can't be used with mail setup of "phpmail". Using a thirdparty SMTP server is required. You can complete warning message by adding an email to contact for setup help with constant <code>'''MAILING_SMTP_SETUP_EMAILS_FOR_QUESTIONS'''</code>.

*'''MAILING_SMTP_SETUP_EMAILS_FOR_QUESTIONS''' ► Contains the email of contact to show into the message visible to a user when he try to use emailing module without SMTP server and if option '''MAILING_NO_USING_PHPMAIL''' is set to on.

*'''MAILING_LIMIT_WARNING_PHPMAIL''' ► Show a warning message (var contains the '''message to show''', or '''translation key''') on emailing send form if setup is on "phpmail". Note: The application always try to translate the message considering the message is a translation key, before showing the translation or message if translation was not found.

*'''MAILING_LIMIT_WARNING_NOPHPMAIL''' ► Show a warning message (var contains the '''message to show''', or '''translation key''') on emailing send form if setup is something else than "phpmail". Note: The application always try to translation the message considering the message is a translation key, before showing the translation or message if translation was not found.
*'''EMAILING_USE_ADVANCED_SELECTOR''' ► Enable the advanced selector for recipients.

*'''MAILING_LIMIT_SENDBYWEB''' ► Restrict number of emails you can send in same sending session with emailing module from GUI. The value "<code>dolibarr_mailing_limit_sendbyweb</code>" if defined into config file is used in priority for this limit. A negative value means, sending by web is forbidden.

*'''MAILING_LIMIT_SENDBYCLI''' ► Restrict number of emails you can send in same sending session with emailing module from CLI script. The value "<code>dolibarr_mailing_limit_sendbycli</code>" if defined into config file is used in priority for this limit.

[[#Top|(back to top)]]

 

=Expense Report=

*'''EXPENSEREPORT_ALLOW_OVERLAPPING_PERIODS''' ► Can enter several expense reports on same or overlapping date periods. ► (v7.0+)

*'''EXPENSEREPORT_OVERRIDE_VAT''' ► Setting this constant to 1 will allow expense reports to show VAT even if the global VAT setting is off ► (v10.0)

*'''EXPENSEREPORT_USE_OLD_NUMBERING_RULE''' ► The module Expense Report use numbering rules that you can setup (like other modules do). If you need to keep the hard-coded numbering rule of expenses report used in v6.0 set this constant to 1 ► (>=v7.0+)

*'''MAIN_USE_EXPENSE_IK''' ► This feature allows you to set index kilometres against a mileage index for different types of vehicles. ► (v7.0+)

*'''MAIN_USE_EXPENSE_RULE''' ► This feature allows you to set a variety of rules per user/group/all so they can only create reports within their limits. ► (v7.0+)

[[#Top|(back to top)]]

 

=Export Module=

*'''EXPORT_CSV_SEPARATOR_TO_USE''' ► String value to use as default separator to delimit fields of exported files (by default Dolibarr uses "<code>,</code>"). Example: EXPORT_CSV_SEPARATOR_TO_USE=<code>;</code>

*'''EXPORT_CSV_FORCE_CHARSET''' ► Choose the charset used in the output file built by the CSV exporter. By default it is ISO-8859-1. Example: EXPORT_CSV_FORCE_CHARSET= <code>utf-8</code>

*'''EXPORTTOOL_CATEGORIES''' ► Can export categories (several lines) into one column with the "product export profile"

*'''USE_STRICT_CSV_RULES''' ► Use strict/real CSV format for export. Do not clean/replace CR+LF with '\n' but quote them using the escaping CSV char (<code>"</code>).
*'''EXPORTS_SHARE_MODELS''' ► Share export models between users.

[[#Top|(back to top)]]

=Foundation Module=

*'''MEMBER_URL_REDIRECT_SUBSCRIPTION''' ► Link called and shown when a member account is autocreated in member module by a guest user.

*'''MEMBER_EXT_URL_SUBSCRIPTION_INFO''' ► Link of external page pointed by the "Show here" link added in front of payment cell, into the page to make online subscription.

[[#Top|(back to top)]]

 
=Holiday Module=

*'''HOLIDAY_HIDE_BALANCE''' ► Hide the user's vacation balance on the vacation request page

[https://wiki.dolibarr.org/Setup_Other#Top (back to top)]
=Interventions Module=

*'''FICHINTER_CLASSIFY_BILLED'''► Allow to classify an intervention card as "Billed". This add also trigger <code>FICHINTER_CLASSIFY_BILLED</code> into list of possible automatic event into agenda.

*'''FICHINTER_DISABLE_DETAILS'''► Disable entry of detail lines on intervention. Can validate with no line. Only one line will be shown per intervention on list.
**If set to <code>2</code> details are disabled only on intervention list ► (v21.0+)

[[#Top|(back to top)]]

=Invoice Module=

*'''MAIN_DEPOSIT_MULTI_TVA''' ► In deposits invoice, creates one line per VAT rate from the origin document ► (6.0)
*'''PDF_INVOICE_SHOW_PRICE_INCL_TAX''' ► In customer's invoice, add a column with the total including all taxes ►

*'''INVOICE_ALLOW_REUSE_OF_CREDIT_WHEN_PARTIALLY_REFUNDED''' ► If a credit note was partially refunded (a refund was sent to the customer), with common situation, we wait to have the remain refunded too. With this option, it is possible to convert the remain of invoice into a discount to reuse it into another invoice.

*'''SUPPLIER_INVOICE_ALLOW_REUSE_OF_CREDIT_WHEN_PARTIALLY_REFUNDED''' ► See INVOICE_ALLOW_REUSE_OF_CREDIT_WHEN_PARTIALLY_REFUNDED, but for supplier credit notes.

*'''INVOICE_CAN_BE_EDITED_EVEN_IF_PAYMENT_DONE''' ► Allow to edit invoices even if payment was started. Note: If the module "BlockedLog" is active (required in some countries for legal reasons), this will not change content of archived logs tracked by this module. By definition there is no way to change or remove archived records. It will just update data in your application and a new record to track your change will be recorded into the archive log.

*'''INVOICE_CAN_ALWAYS_BE_REMOVED''' ► Allow to always delete invoices (even if invoice is not last one). Note: If the module "BlockedLog" is active (required by some countries for legal reason), this will not change content of archived logs tracked by this module. By definition there is no way to change or remove archived records. It will just update data in your application and a new record to track your change into the read-only archive log.

*'''INVOICE_CAN_NEVER_BE_EDITED''' ► Never allow to edit invoices (except draft invoices with ref like (PROV%)). See also INVOICE_CAN_NEVER_BE_REMOVED.

*'''INVOICE_CAN_NEVER_BE_REMOVED''' ► Never allow to delete invoices (except draft invoices with ref like (PROV%)). See also INVOICE_CAN_NEVER_BE_EDITED

*'''INVOICE_POSITIVE_CREDIT_NOTE''' ► All amounts on PDF credit notes are positive.

*'''FACTURE_DEPOSITS_ARE_JUST_PAYMENTS''' ► An old way to create initial payment. This treats deposit invoices as a special case and not as legal deposit invoice. Deposit invoices don't get counted on turnover. They are then applied as a payment, like a discount, on the final invoice. By default, when you include the deposit into draft of final invoice, the amount of final invoice is reduced. With this option, final amount is not reduced but a payment is registered. WARNING: In a lot of european countries, using this option is not allowed.

*'''FACTURE_SENDBYEMAIL_FOR_ALL_STATUS''' ► Can send invoice by email to customer even if invoice has status "draft".

*'''INVOICE_CREDIT_NOTE_STANDALONE''' ► Start implementation to allow a credit note even without invoice (dangerous) ► (v3.9)

*'''INVOICE_USE_SITUATION''' ► 1=Enable the "situation invoice" feature. Warning, this feature is bugged and may not be compatible with the final version of the feature once the bug will be solved. Also, using the double-entry accountancy module is not possible when this option is on (due to the same design problem). 2=Enable the "situation invoice" feature with a rewrite. This mode should be better to become a future stable feature.

*'''INVOICE_USE_SITUATION_CREDIT_NOTE''' ► Enable the "situation credit note" feature (need <code>INVOICE_USE_SITUATION</code>) ► (v8.0)
*'''INVOICE_USE_RETAINED_WARRANTY''' ► Enable the retained warranty on invoice ► (v14.0)

*'''INVOICE_DISABLE_DEPOSIT''' ► Disable deposit invoices

*'''INVOICE_DISABLE_REPLACEMENT''' ► Disable replacement invoices

*'''INVOICE_DISABLE_CREDIT_NOTE''' ► Disable credit notes

*<bdi>'''INVOICE_ADD_EXTRAFIELD_IN_NOTE''' ► Add extrafields in note for canelle template ► (v17.0+)</bdi>

*'''INVOICE_DEFAULT_NOTE_PUBLIC''' <bdi>► Default text in public note</bdi>

Note: To decode a QR image of a ZATCA code: https://www.onlinebarcodereader.com/. You can also use the mobile application https://play.google.com/store/apps/details?id=com.posbankbh.einvoiceqrreader&gl=FR

*'''MAIN_GENERATE_DOCUMENTS_WITHOUT_VAT''' ► See PDF option

*'''MAIN_GENERATE_DOCUMENTS_WITHOUT_VAT_COLUMN''' ► See PDF options

*'''WORKFLOW_BILL_ON_SHIPMENT''' ► Change label of button with suitable label when you need to create invoice on shipments

*'''INVOICE_ALLOW_EXTERNAL_DOWNLOAD''' ► When a PDF is generated, a share key is automatically set so the file can be downloaded using the share key. Use the tag __DIRECTDOWNLOAD_URL_INVOICE__ in email template to insert it. ► (v7.0+)

*'''INVOICE_POINTOFTAX_DATE''' ► Add Point of Tax Date on invoices for country-specific legality reasons ► (v4.0+)
*'''FACTURE_ENABLE_NEGATIVE''' ► Can validate an invoice when amount is negative

*'''FACTURE_ENABLE_NEGATIVE_LINES''' ► Allows to add negative lines to an invoice ► (v8.0.2+)
*'''SUPPLIER_INVOICE_ENABLE_NEGATIVE''' ► Can validate an supplier invoice when amount is negative ► (V21 ?)
*'''SUPPLIER_INVOICE_ENABLE_NEGATIVE_LINES''' ► Allows to add negative lines to an supplier invoice ► (V21 ?)

*'''INVOICE_USE_DEFAULT_DOCUMENT''' ► Allow user to select a default invoice documents models according to invoice type. On invoice create page, the model is dynamically changed on invoice type selection. ► (v9.0+)

*'''FACTURE_REUSE_NOTES_ON_CREATE_FROM''' ► Reuse the Public Note and Private note of the previous object (Proposal,...) when creating the bill.
*'''FACTUREFOURN_REUSE_NOTES_ON_CREATE_FROM''' ► Reuse the Public Note and Private note of the previous object when creating the supplier bill ► (V13.0)
*'''MAIN_SHOW_FACNUMBER_IN_DISCOUNT_LIST''' ► Display the reference of credit notes in discount list when creating the bill.
*'''INVOICE_ALLOW_FREE_REF''' ► Capability to change reference of an invoice. This will be possible as long as the invoice has the status “Draft” and only if your country is not in Europe(V11)

*'''INVOICE_DISALLOW_REOPEN'''

*'''INVOICE_MAX_FUTURE_DELAY''' ► Numbers of seconds allowed for billing in the future ► (V14.0)
*'''INVOICE_AUTO_NEXT_MONTH_ON_LINES''' ► Increase start date and end date by one month, if an invoice line is a clone of a time based service AND if this services started on the first day of month and ended on the last day of month ► (V13.0.1)
*'''INVOICE_KEEP_DISCOUNT_LINES_AS_IN_ORIGIN''' ► Does not change a line with a negative price into an absolute discount when creating an invoice ► (V16 ?)
*'''INVOICEREC_SET_AUTOFILL_DATE_START''' and '''INVOICEREC_SET_AUTOFILL_DATE_END ►''' Set start and end date to yes for lines of template invoice when created from a draft invoice ► (V16)
*'''INVOICE_REC_DATE_TO_YES''' '''►''' Set start and end date to yes by default in add line form for template invoice ► (V16)
*'''INVOICE_SUBTYPE_ENABLED''' ► Extends Dolibarr standard invoice with more invoice types used in some countries. A combo box in the new invoice creation card allows the selection of "subtypes" with values from dictionary "Invoice Subtypes" ► (v19.0+)
*'''LIST_OF_QUALIFIED_INVOICES_LIMIT_DEFINED''' '''►''' Perf options to limit list of invoices for "credit note" source (on form "create a credit note"), usable for big quantities of invoices for one customer like you can have with TakePos ► (V22+)

[[#Top|(back to top)]]

=Leave=

*'''MAIN_NON_WORKING_DAYS_INCLUDE_SATURDAY''' ► Set this value to 0 if you want to have the Saturday as a working day
*'''MAIN_NON_WORKING_DAYS_INCLUDE_SUNDAY''' ► Set this value to 0 if you want to have the Sunday as a working day

=Look or Theme=

*'''MAIN_FAVICON_URL''' ► favicon url

*'''MAIN_EASTER_EGG_COMMITSTRIP''' ► Show a comic image from the CommitStrip website. Images are refreshed daily. ► (v6.0+)

*'''MAIN_INCLUDE_GLOBAL_STATS_IN_OPENED_DASHBOARD''' ► This conf will auto remove global stats box item if there are already in the new dashboard of opened elements and keep displayed stats on the opened item box (not only on mouse over) ► (v11.0+)

*'''MAIN_USE_TOP_MENU_SEARCH_DROPDOWN''' ► Actually only for eldy theme, this conf move search input to top menu and use new design too ► (v11.0+)

*'''THEME_AGRESSIVENESS_RATIO''' ► This conf can be used to increase/decrease aggressiveness of colors. Value 0 is medium, value is between -100 (light grey colors) to +100 (very flashy colors) ► (v11.0+)

*'''THEME_SHOW_BORDER_ON_INPUT'''
*'''MAIN_DISABLE_GLOBAL_WORKBOARD''' ► Hide the work board of the main page ► (v13.0+)
*'''MAIN_DISABLE_GLOBAL_BOXSTATS''' ► Hide the Statistic Box of the main page
*'''ALLOW_THEME_JS ►''' Allow JS file in theme folder (same name as theme folder)

 

=Manifest (Progressive Web App)=

*'''MAIN_MANIFEST_APPLI_THEME_COLOR ►''' Theme color for manifest
*'''MAIN_MANIFEST_APPLI_BG_COLOR ►''' Background color for manifest
*'''MAIN_MANIFEST_APPLI_LOGO_URL ►''' Logo for manifest
*'''MAIN_MANIFEST_APPLI_LOGO_URL_SIZE ►''' Logo url size for app (150, 192, 512px) missing 3 configurations

[[#Top|(back to top)]]

=Order Module=

*'''MAIN_MASSACTION_CREATEBILLS_REDIRECT_IF_ONE''' ► If set 1, redirects to the one bill created from massaction create bills from order list ► (v20.0)

*'''MAIN_MASSACTION_CREATEBILLS_REDIRECT_IF_MANY''' ► If set to 1, redirects to the invoice list after plural invoices where generated from tho massaction create bills from order list ► (v20.0)

*'''MAIN_ORDERLIST_CREATEBILLS_ONEBYTHIRD''' ► Allow defining value for option "one by thirdparty" in massaction create bills from orders list page (no by default, yes if set to 'yes' or 1) ► (v20.0)

*'''MAIN_USE_PROPAL_REFCLIENT_FOR_ORDER''' => Copy customer reference from proposal to order. ► (v7.0+)

*'''ORDER_REQUIRE_SOURCE''' => Make the input field "Source of order" mandatory.

*'''ORDER_VALID_AFTER_CLOSE_PROPAL''' => When an order is created on a proposal close, the order is directly defined with status "Validated".

*'''ORDER_ALLOW_EXTERNAL_DOWNLOAD''' => When a PDF is generated, a share key is automatically set so the file can be downloaded using the share key. ► (v7.0+)

*'''ORDER_ENABLE_NEGATIVE''' => Can validate an order when amount is negative

*'''THIRDPARTY_PROPAGATE_EXTRAFIELDS_TO_ORDER''' => Copy also extrafields from thirdparty to order (if name match). ► (v11.0+)
*'''ORDER_DEFAULT_NOTE_PUBLIC''' ► Default text in public note
*'''MAIN_REMOVE_DROPDOWN_CREATE_BUTTONS_ON_ORDER''' => Remove the create dropdown button on order card (introduce on v19) to come back with old buttons. '''►''' (v20.0+)

[[#Top|(back to top)]]

 

=PDF Options=

*'''MAIN_ADD_PDF_BACKGROUND''' ► Define this constant with short name of a PDF file (example "<code>mypdf.pdf</code>") that must be saved into directory "<code>documents/mycompany</code>". This will add PDF as a background of some of your generated PDF files (proposals,invoices,orders). If you need to concat PDF, see instead [[Module Concat PDF]].

*'''MAIN_DISABLE_FORCE_SAVEAS''' ► If your browser always asks to save downloaded files on disk (like PDF), try this this option. File may be displayed directly in your browser. Values : 0= Default (file is auto downloaded), 1= For to output the file into the browser tab, 2= For to output the file into a browser tab open with target_blank

*'''MAIN_DISABLE_PDF_AUTOUPDATE''' ► Disable automatic generation of PDF each time we add/update/delete a product line (we can still build document by clicking on "Generate"). This option may increase interface speed on servers with low CPU.

*'''MAIN_DISABLE_PDF_COMPRESSION''' ► Disable PDF compression.
*'''PDF_ADD_POSITION ►''' Displays document line numbering on the PDF. Combines with the option. <code>MAIN_VIEW_LINE_NUMBER</code>

*'''MAIN_DOCUMENTS_WITH_PICTURE_WIDTH''' ► Can change size of picture when hidden option <code>MAIN_GENERATE_PROPOSALS_WITH_PICTURE</code> is used. By default value is <code>20</code>.

*'''MAIN_GENERATE_DOCUMENTS_SHOW_FOOT_DETAILS''' ► Adding the company address at the bottom of the page. Disabled by default

*'''MAIN_GENERATE_PROPOSALS_WITH_PICTURE''' ► Include the first image of the product into the line of the generated PDF for customer proposals.
*'''MAIN_GENERATE_ORDERS_WITH_PICTURE''' ► Include the first image of the product into the line of the generated PDF for customer orders.

*'''MAIN_GENERATE_INVOICES_WITH_PICTURE''' ► Include the first image of the product into the line of the generated PDF for customer invoices.

*'''MAIN_GENERATE_SUPPLIER_PROPOSAL_WITH_PICTURE''' ► Include the first image of the product into the line of the generated PDF for supplier proposals ► (v5.0.3+)
*'''MAIN_GENERATE_SUPPLIER_ORDER_WITH_PICTURE''' ► Include the first image of the product into the line of the generated PDF for supplier orders

*'''MAIN_GENERATE_DOCUMENTS_WITHOUT_VAT''' ► Disable VAT on generated documents. like for an association. (Works with crabe template)

*'''MAIN_GENERATE_DOCUMENTS_WITHOUT_VAT_COLUMN''' ► Hide column with VAT information but only column not total.

*'''MAIN_INVERT_SENDER_RECIPIENT''' ► Invert sender and recipient in some PDF. Note: This option is set automatically if country if Germany.

*'''MAIN_ODT_AS_PDF''' ► Activate ODT to PDF conversion. Value can be "libreoffice" or "unoconv". Do not use value '''<nowiki/>'jodconverter'<nowiki/>''' any more, as it is declared deprecated and partly not functional, use value '''<nowiki/>'libreoffice'''' instead, it requires only '''soffice''' (OpenOffice or LibreOffice) installed on server (use '''apt install soffice libreoffice-common libreoffice-writer''').

If you got this error: javaldx failed! Warning: failed to read path from javaldx with no return to prompt when running soffice --headless -env:UserInstallation=file:"/tmp" --convert-to pdf --outdir xxx ./yyy.odt, check that directory defined into env:UserInstallation parameters exists and is writeable.

You may also have a look at this page if your server is on Windows: [[Générer automatiquement des documents PDF à partir de fichier ODT avec Doliwamp]]

*'''MAIN_ODT_AS_PDF_DEL_SOURCE''' ► For ODT generation. If set, then initial behaviour is conserved but ODT file is removed when option to convert it as PDF (see previous) is on. Disabled by default

*'''MAIN_PDF_FORCE_FONT''' ► To ignore font defined into language file and force usage of a particular font. For example "<code>DejaVuSans</code>".

*'''MAIN_PDF_FORCE_FONT_SIZE''' ► To force size of font (by default 10). For example "<code>12</code>" ► (v11.0)

*'''MAIN_PDF_FREETEXT_HEIGHT''' ► Change height of space reserved to output the free text.

*'''MAIN_PDF_TITLE_BACKGROUND_COLOR''' ► Can define a background color onto title line. Example: <code>220,220,200</code>

*'''MAIN_PDF_USE_LARGE_LOGO''' ► Use the original logo with its higher resolution into the PDF instead of the small thumb. This may lead to very very large PDF !

*'''MAIN_USE_BACKGROUND_ON_PDF''' ► Define this constant with short name of an image (example "<code>myimage.jpg</code>") that must be saved into directory "<code>documents/mycompany/logos</code>". This will add this background image into your generated PDF files.

*'''MAIN_USE_COMPANY_NAME_OF_CONTACT''' ► Use contact name and information rather than company

*'''MAIN_PDF_ADDALSOTARGETDETAILS''' ► If 1, add details of recipient on generated PDFs (email, fax, url and phone). Can be useful in cases where a printed order/invoice etc is given to a delivery driver/courier etc.

*'''MAIN_TVAINTRA_IN_SOURCE_ADDRESS''' ► Show VAT N° in source address of PDF to comply with legalities in certain countries. Note that VAT number should be already visible in footer of page ► (v8.0.1+)

*'''MAIN_PDF_PROPAL_USE_ELECTRONIC_SIGNING''' ► Add optional esign field in pdf propal ► (v8.0+)

*'''MAIN_PROFID1_IN_SOURCE_ADDRESS''' ► Show Professional ID 1 in source address of PDF to comply with legalities in certain countries ► (v8.0.1+)

*'''MAIN_PROFID2_IN_SOURCE_ADDRESS''' ► Show Professional ID 2 in source address of PDF to comply with legalities in certain countries ► (v8.0.1+)

*'''MAIN_PROFID3_IN_SOURCE_ADDRESS''' ► Show Professional ID 3 in source address of PDF to comply with legalities in certain countries ► (v8.0.1+)

*'''MAIN_PROFID4_IN_SOURCE_ADDRESS''' ► Show Professional ID 4 in source address of PDF to comply with legalities in certain countries ► (v8.0.1+)

*'''MAIN_PROFID5_IN_SOURCE_ADDRESS''' ► Show Professional ID 5 in source address of PDF to comply with legalities in certain countries ► (v8.0.1+)

*'''MAIN_PROFID6_IN_SOURCE_ADDRESS''' ► Show Professional ID 6 in source address of PDF to comply with legalities in certain countries ► (v8.0.1+)

*'''PDF_BANK_HIDE_NUMBER_SHOW_ONLY_BICIBAN''' ► Hide bank number ("code banque/guichet/compte" for France, "sort code/account number" for GB, ...) and keep only BIC/IBAN on PDF.

*'''PDF_BOLD_PRODUCT_REF_AND_PERIOD''' ► Add more visibility (bold) on product ref and period of service in desc. ► (v12.0)

*'''PDF_HIDE_PRODUCT_REF_IN_SUPPLIER_LINES''' ► Modify the use/position of Supplier Ref/Internal Ref with the item Label (name) on PDF documents.

Default (constant not set or Value <code>0</code>): Internal ref followed by supplier ref in brackets."COMPANY-REF-001 (Vendor SKU SUPPLIER-REF-001) - LABEL...".

Value <code>1</code>: Supplier ref only eg."SUPPLIER-REF-001 - LABEL...".

Value <code>2</code>: Supplier ref followed by internal ref in brackets. eg."SUPPLIER-REF-001 (InternalRef COMPANY-REF-001) - LABEL...".

*'''PDF_INCLUDE_ALIAS_IN_THIRDPARTY_NAME''' ► Include alternative/alias name into name on PDF.

*'''PDF_SECURITY_ENCRYPTION''' ► Encrypt PDF produced by dolibarr. See additional parameters :PDF_SECURITY_ENCRYPTION_RIGHTS (block 'modify' or 'copy') - '''PDF_SECURITY_ENCRYPTION_USERPASS''' - '''PDF_SECURITY_ENCRYPTION_OWNERPASS''' (random if not specified) - '''PDF_SECURITY_ENCRYPTION_STRENGTH''' (0 = RC4 40 bit; 1 = RC4 128 bit; 2 = AES 128 bit; 3 = AES 256 bit) - '''PDF_SECURITY_ENCRYPTION_PUBKEYS''' Array of recipients containing public-key certificates ('c') and permissions ('p') - For example: array(array('c' => 'file://../examples/data/cert/tcpdf.crt', 'p' => array('print'))). WARNING: if an 'encrypted PDF' provides a protection against manual change done by mistake, it does NOT provide any protection against modification of your PDF in a security point of view: A protected PDF can still be modified by any advanced PDF editors. Don't forget this: If a software can read the PDF, this software can also rebuild it differently !

*'''PDF_SHOW_PROJECT''' ► Show project onto PDF (supported on supplier order only for the moment)

*'''PDF_USE_ALSO_LANGUAGE_CODE''' ► The value of this constant must be a language code ('fr_FR', 'en_US', 'sa_SA', ...). If set, the PDF document will contains both language (default and the one defined by the constant).
*'''DOC_SHOW_FIRST_SALES_REP''' ► Show the sales representant on header (at least on propal azur and rubis template)
*'''MAIN_PDF_DASH_BETWEEN_LINES'''
*
*'''SHOW_SUBPRODUCT_REF_IN_PDF'''
*'''PDF_HIDE_PRODUCT_LABEL_IN_SUPPLIER_LINES''' ► hide product label in supplier order lines (V15+)
*'''SHIPPING_PDF_DISPLAY_AMOUNT_HT''' ► Show HT unit price and HT total price for lines of PDF shipment

*'''MAIN_DOCUMENTS_HIDE_DESCRIPTION_FOR_FACTURE''' ► To Hide product description in Customer Invoice
*'''MAIN_DOCUMENTS_HIDE_DESCRIPTION_FOR_COMMANDE''' ► To Hide product description in Sales Order
*'''MAIN_DOCUMENTS_HIDE_DESCRIPTION_FOR_ORDER_SUPPLIER''' ► To Hide product description in Purchase Order
*'''MAIN_DOCUMENTS_HIDE_DESCRIPTION_FOR_INVOICE_SUPPLIER''' ► To Hide product description in Vendor Invoice

*'''PDF_PROPAL_SHOW_PRICE_INCL_TAX''' ► Display price with tax on Proposal(cyan template) (V17+)
*'''PDF_ORDER_SHOW_PRICE_INCL_TAX''' ► Display price with tax on Order(eratosthene template) (V17+)
*'''PDF_INVOICE_SHOW_PRICE_INCL_TAX''' ► Display price with tax on Invoice(sponge template) (V17+)

*'''PDF_USE_GETALIASNBPAGE_FOR_TOTAL''' ► Display the page number alias
*'''MAIN_PDF_NO_SENDER_FRAME''' ► Do not display the "sender" mention
*'''MAIN_PDF_HIDE_SENDER_NAME''' ► Do not display the sender name
*'''MAIN_PDF_NO_RECIPENT_FRAME''' ► Do not display BillTo

*'''MULTICURRENCY_SHOW_ALSO_MAIN_CURRENCY_ON_PDF''' ► Show the amount in the 2 currencies on PDF when using the MultiCurrency module
*'''MAIN_PDF_DONOTREPEAT_HEAD ►''' Do not repeat the header of document

[[#Top|(back to top)]]

=Point of Sale (POS)=

*'''CASHDESK_SHOW_KEYPAD''' ► Show a mouse key pad into the 'Simple Point of Sale' module.

*'''POS_ADDON''' ► Set this value to an existing numbering module rule (for example '<code>mod_facture_terre</code>', '<code>mod_facture_mars</code>', ...) to force the numbering module to use for invoice ref definition when invoice is created by the POS. For example setting value <code>POS_ADDON</code> to '<code>mod_facture_terre</code>' will use the numbering module '<code>terre</code>' for invoice generated from POS, whatever is the numbering rule defined into invoice module setup (you can also use POS_NUMBERING_TERRE_FORCE_PREFIX and POS_NUMBERING_MARS_FORCE_PREFIX variable to change the prefix used).

*'''TAKEPOS_ENABLE_SUMUP''' ► Enable the compatibility of TakePOS with the card reader terminal [https://SumUp.fr SumUp]
*'''TAKEPOS_CAN_FORCE_BANK_ACCOUNT_DURING_PAYMENT''' ► Possibility to force the bank account during the payment in TakePOS ► (v13.0)
*'''TAKEPOS_CONTROL_CASH_OPENING''' ► Control the cash opening
*'''TAKEPOS_NUMPAD_FORCE_PAYMENT_ICONS_LABELS'''

[[#Top|(back to top)]]

=Products Module=

*'''CATEGORY_GRAPHSTATS_ON_PRODUCTS''' ► Show graph of products with categories and totals in Products Area screen

*'''MAIN_PRODUCT_DISABLE_CUSTOMCOUNTRYCODE''' ► Avoid customs code and country of origin to be set as product description when added to Propal/Order/Invoice

*'''PRODUCT_ADD_TYPE_IN_DOCUMENTS''' ► Add text "Product" or "Service" at beginning of details lines on built PDF documents.

*'''PRODUCT_DONOTSEARCH_ANYWHERE''' ► When Ajax search is enabled, search is done on criteria anywhere in label of product. By adding this option, search is done only on start of label. This is really faster when you have a huge number of products.

*'''MAIN_DIRECT_STATUS_UPDATE''' ► Allows you to change the status of the product (''for sale/not for sale for purchase/not for purchase'') directly on the product page via a ''on/off'' switch button. This can be convenient for those who need to quickly disable certain statuses of products without having to go through the editing product page individually. Also can be very useful if used as a filter on the product and product search list. This option doesn't generate a MODIFY trigger, so be careful with external modules. ► (v4.0+)

*'''MAIN_SEARCH_PRODUCT_BY_FOURN_REF''' ► Allow to search a product by supplier ref in document's add line form. ► (>= 8.0)

*'''MAIN_DISABLE_FREE_LINES''' ► Disallow using free lines to add line in documents ► (>= 8.0)

*'''MAIN_SHOW_PRODUCT_ACTIVITY_TRIM''' ► Show Product and Services turnover before for all four quarters tax over recent years recent years on the product area ► (v5.0+)

*'''PRODUIT_DESC_IN_LIST''' ► Show long description of product/service into lists.

*'''PRODUCT_DISABLE_PROPAGATE_CUSTOMER_PRICES_ON_CHILD_COMPANIES''' ► Disable propagation of prices per customer from a customer to its child company.

*'''PRODUCT_DISABLE_PUBLIC_URL''' ► Disable public url in product card ► (v14.0+)
*'''PRODUCT_DISABLE_STOCK_LEVELS''' ► Disable properties of stock limits and desired optimal value on product ► (v14.0+)
*'''PRODUCT_DISABLE_NATURE''' ► Disable nature in product card ► (v14.0+)
*'''PRODUCT_DISABLE_WEIGHT''' ► Disable weight in product card ► (v14.0+)
*'''PRODUCT_DISABLE_PRICES''' ► Disable prices in product card ► (v14.0+)
*'''PRODUCT_DISABLE_ACCOUNTING''' ► Disable accounting in product card ► (v14.0+)
*'''PRODUCT_DISABLE_SIZE''' ► Disable size in product card.

*'''PRODUCT_DISABLE_LENGTH''' ► Disable length in product card ► (v4.0+)

*'''PRODUCT_DISABLE_SURFACE''' ► Disable surface in product card. ► (v4.0+)

*'''PRODUCT_DISABLE_VOLUME''' ► Disable volume in product card.

*'''PRODUCT_DISABLE_CUSTOM_INFO''' ► Disable custom info (custom code and country origin) in product/service card.

*'''PRODUIT_MULTIPRICES_USE_VAT_PER_LEVEL''' ► When option to use price per level/segment is on, this allows to also set a dedicated vat for each price level.

*'''PRODUIT_CUSTOMER_PRICES_BY_QTY''' ► If price per quantity ► ''Experimental''
*'''PRODUIT_CUSTOMER_PRICES_BY_QTY_MULTIPRICES''' ► If price per quantity and customer ► ''Experimental''

*'''PRODUCT_LOT_ENABLE_QUALITY_CONTROL''' ► Enable feature (Display fields for life time and quality control duration) for quality control on product and lot

*'''PRODUCT_MAX_LENGTH_COMBO''' ► Limit the length of the label displayed when adding lines in proposals/invoices/orders

*'''PRODUCT_MAX_VISIBLE_PHOTO''' ► Show a maximum number of product photos (as thumbnails) on the product main card. Example, setting this constant to '<code>5</code>' will show the first five product photos found on the product card.

*'''PRODUIT_PDF_MERGE_PROPAL''' ► Enable module Propal merge product PDF

*'''PRODUCT_USE_OLD_PATH_FOR_PHOTO''' ► Ask dolibarr to check also old path (before 3.7) where photos were stored.

*'''PRODUCT_USE_UNITS''' ► Add other units on products (Use same dictionary as default unit feature) and propagate this unit on line of documents.
*'''MAIN_EDIT_LINE_ALLOW_ALL_UNIT_TYPE ►''' Allow the selection of other unit types when editing the document line

*'''RESOURCE_ON_PRODUCTS''' ► Allow to affect resources on products/services ► (v10.0+)
*'''RESOURCE_ON_SERVICES''' ► Allow to affect resources on products/services ► (v10.0+)
*'''PRODUCT_SHOW_ORIGIN_IN_COMBO''' ► Show origin of products when adding lines in proposals/invoices/orders ► (v12.0+)
*'''PRODUIT_ATTRIBUTES_HIDECHILD''' ► Add option hide child if variantes

*'''PRODUCT_ADD_FORM_ADD_TO''' ► Add a product to a draft proposal/order/invoice, from the product card.
*'''PRODUCT_DISABLE_SELLBY''' ► Hide the Sell by date ► (v13.0+)
*'''PRODUCT_DISABLE_EATBY''' ► Hide the Eat by date ► (v13.0+)

*'''PRODUCT_DENY_CHANGE_PRODUCT_TYPE''' ► Forbid to change the product type

*'''PRODUCT_SORT_BY_CATEGORY''' ► Sort the product by categories instead of by ID
*'''PRODUCT_ADD_NET_MEASURE''' ► Support Net Measure in product's card.php (For real weight, volume or piece; needed for some business ie fruits, vegetables....). Note brut value is already available natively, use this option only if you need 2 weights, 2 volumes, ...for each product) ► (v11.0.1+)
*'''PRODUCT_PRICE_BASE_TYPE''' ► value 'TTC' / 'HT' specify the default value of the price (with or without taxes) ► (v16.0.0+)

*'''PRODUCT_LOAD_EXTRAFIELD_INTO_OBJECTLINES''' ► Load product extrafiled on object lines

*'''PRODUCT_USE_SUB_COST_PRICES_IF_COST_PRICE_EMPTY''' : Calculate the parent product production price by child prices.
*'''PRODUCT_SEARCH_AUTO_SELECT_IF_ONLY_ONE''' : Set to 0 to disable or 1 to enable (by default) the auto select product behavior in combobox when there is only one result.(v21.0+)

[[#Top|(back to top)]]

 

=Projects Module=

*'''PROJECT_ALLOW_TO_LINK_FROM_OTHER_COMPANY''' ► Option related to the combo list Project on elements. It is a list of thirdparty IDs. If set, you can link an object to a project owned by one of this thirdparty in the list.

*'''PROJECT_ALLOW_COMMENT_ON_PROJECT''' ► Add comment feature on a project

*'''PROJECT_ALLOW_COMMENT_ON_TASK''' ► Add comment feature on project task
*'''PROJECT_ALWAYS_DISCARD_CLOSED_PROJECTS_IN_SELECT''' ► Discards closed projects in every select field. A closed project can't be associated to an object ► (v20.0+)

*'''PROJECT_CAN_ALWAYS_LINK_TO_ALL_SUPPLIERS''' ► Option related to the combo list Project on elements. Can link a supplier element (vendor proposal, purchase order, vendor invoice, reception, ...) to any project even if object has a different supplier than the one of the project to link to. See also PROJECT_ALLOW_TO_LINK_FROM_OTHER_COMPANY that is different because it allows to define some given thirdparty ID to allow.

*'''PROJECT_CAN_ALWAYS_LINK_TO_ALL_CUSTOMERS''' ► Option related to the combo list Project on elements. Can link a custom element (proposal, sale order, vendor invoice, shipment, ...) to any project even if object has a different customer than the one of the project to link to.

*'''PROJECT_CREATE_ON_OVERVIEW_DISABLED''' ► Hide the "create ..." button on the overview pagec

*'''PROJECT_DISABLE_UNLINK_FROM_OVERVIEW''' ► Enable removing the button from a link in the project overview. ► (>= v8.0.1)

*'''PROJECT_HIDE_UNSELECTABLES''' ► Hide into select list, all project that we can't select (closed or draft)

*'''PROJECT_HIDE_TASKS''' ► Hide tasks. For user using project only as an analytics key and not using tasks.

*'''PROJECT_LIST_SHOW_STARTDATE''' ► Shows start date of projects in project lists.

*'''PROJECT_LINK_ON_OVERWIEW_DISABLED''' ► Hide the "link to" form on the overview page ► (v4.0)

*'''PROJECT_SHOW_REF_INTO_LISTS''' ► Add column with project ref into list (with 3.7 list of supplier invoices only, will be expanded to other lists)

*'''PROJECT_TIME_ON_ALL_TASKS_MY_PROJECTS''' ► Can add time spent on tasks, even if i am not assigned to task (however, task must be a project i am a contact).

*'''PROJECT_OPEN_ALWAYS_ON_TAB''' ► Set to value 'task', or 'preview' to always open the project on the given tab instead of main tab.

*'''PROJECT_ELEMENTS_FOR_MINUS_MARGIN'''

*'''TIMESPENT_ALWAYS_UPDATE_THM''' ► when it's on always check current time of user to update it in task time line ► (v17.0)

*'''PROJECT_CREATE_NO_DRAFT''' ► when you create project status will be validate ► (v19.0)

*'''PROJECT_ENABLE_SUB_PROJECT''' ► Add support for parent projects ► (v19.0)

[[#Top|(back to top)]]

=Proposals Module=

*'''MAIN_GENERATE_PROPOSALS_WITH_PICTURE''' ► Add a picture of the product (the first one found if there are several) into the generated PDF of proposals. Note that using this will reduce the available width for the product description.

*'''MAIN_PROPAL_CHOOSE_ODT_DOCUMENT''' ► On setup page, you'll be able to select which ODT document to use when close or cancel proposals.

*'''MAIN_PDF_PROPAL_USE_ELECTRONIC_SIGNING''' ► add optional esign field in pdf propal ► (v8.0+)

*'''PROPAL_CLONE_ON_CREATE_PAGE''' ► On the create proposal page, ask if we want to create the proposal by cloning an already existing one. You should use instead the "Clone" button available on existing proposals.

*'''PROPAL_DISABLE_SIGNATURE''' ► Do no show the box for signature.
*'''PROPAL_SIGNATURE_ON_SPECIFIC_PAGE ►''' Will show the signature on which page you wanted . Set to 1 will show on first page , set to -1 will show on last second page . ( If '''PROPAL_SIGNATURE_ON_ALL_PAGES''' is enabled, the '''PROPAL_SIGNATURE_ON_SPECIFIC_PAGE''' setting will be ignored.)
*'''PROPAL_SIGNATURE_ON_ALL_PAGES ►''' Will show the signature on every pages .

*'''PRODUIT_PDF_MERGE_PROPAL''' ► When generating the proposal PDF, all PDFs linked to products linked to proposal are also included into final PDF

*'''PROPOSAL_ALLOW_EXTERNAL_DOWNLOAD''' ► When a PDF is generated, a share key is automatically set so the file can be downloaded using the share key. ► (v7.0+)

*'''PROPOSAL_AUTO_ADD_AUTHOR_AS_CONTACT''' ► Add Proposal Author as user contact follow proposal

*'''PROPOSAL_PDF_HIDE_PAYMENTTERM''' ► Do not show the payment term on proposal ► (v11.0+)

*'''PROPOSAL_PDF_HIDE_PAYMENTMODE''' ► Do not show the payment mode on proposal ► (v11.0+)

*'''WORKFLOW_PROPAL_CAN_CLASSIFY_BILLED_WITHOUT_INVOICES''' ► Button "Classified Billed" is visible on proposal even if there is no invoice linked to proposal.
*'''PROPAL_REOPEN_UNSIGNED_ONLY''' ► Do not allow reopening of signed (or billed) proposals. (V15)
*'''PROPOSAL_ARE_NOT_BILLABLE''' ► Disable billing button on proposals (V15)
*'''PROPAL_DEFAULT_NOTE_PUBLIC''' ► Default text in public note
*'''PROPAL_ENABLE_NEGATIVE''' ► Can validate a proposal when amount is negative

[[#Top|(back to top)]]

=Receptions=

*'''RECEPTION_STANDALONE''' ► Create a simple Reception not connected to supplier order, warehouse, stock e.t.c. (>=23.0)

[[#Top|(back to top)]]

=Recruitment=

*'''RECRUITMENT_NEWFORM_TEXT'''► Add a custom text on public recruitment page
*'''MAIN_RECRUITMENT_CSS_URL ►'''Path of custom css file for recruitment public page
*'''RECRUITMENT_IMAGE_PUBLIC_INTERFACE ►'''Path of custom image for recruitment public page

[[#Top|(back to top)]]

=Services Module=

*'''SERVICE_ARE_ECOMMERCE_200238EC''' ► If seller and buyer are in Europe and buyer is not a company, use the VAT of buying country. For french speaking people, see also the page [[Loi_européenne_TVA_Vente_à_Distance_VAD_et_e-commerce_BtoC]].

*'''MAIN_FILL_SERVICE_DATES_FROM_LAST_SERVICE_LINE''' ► (v13.0) On add line form add a button to fill service dates from the last service line

[[#Top|(back to top)]]

=Shipments=

*'''STOCK_WAREHOUSE_NOT_REQUIRED_FOR_SHIPMENTS''' ► If set, you can add a shipment line, with no stock source defined. ► (>= 8.0.1)

*'''SHIPMENT_GETS_ALL_ORDER_PRODUCTS''' ► Add all order lines in shipment, including the one with 0 in quantity
*'''SHIPPING_PDF_HIDE_ORDERED''' ►Hide column quantity ordered on shipment pdf (>=15.0)
*'''STOCK_SUPPORTS_SERVICES''' ►Allow to manage services into warehouse and allow to ship services
*'''SHIPMENT_SUPPORTS_SERVICES''' ►Allow to ship services without stock (>=19.0)
*'''SHIPPING_DISPLAY_STOCK_ENTRY_DATE''' ►Display date entry stock exped and sort in date order (>=19.0)
*'''SHIPMENT_STANDALONE ►'''Create a simple shipment not connected to sales order, warehouse, stock e.t.c. (>=23.0)

[[#Top|(back to top)]]

=SMS=

*'''MAIN_SMS_DEBUG''' ► Write content of SMS sent into file <code>dolibarr_sms.log</code> into directory <code>dolibarr_main_data_root</code>.

[[#Top|(back to top)]]

=Stocks=

*'''SUPPLIER_ORDER_DISABLE_STOCK_DISPATCH_WHEN_TOTAL_REACHED''' ► Disable stock dispatch when total expected was already received

*'''STOCK_EXCLUDE_VIRTUAL_PRODUCTS''' ► If product is a virtual product, we do not manage stock for it.
*'''STOCK_ALLOW_DELETE_OF_MOVEMENT''' ► Enable massaction option to delete in movements list (be carefull !!).

*'''ENTREPOT_EXTRA_STATUS''' ► Instead of the 2 status (Closed, Open), a Warehouse has 3 status: Closed, Open (for all movements), Open (for internal movement only). Internal movement only means you can't use the warehouse to make shipment or receptions.

*'''SUPPLIER_ORDER_STATUS_FOR_VIRTUAL_STOCK''' ► For the calculation of virtual stocks, by default supplier orders with the status 3 (ordered) and 4 (partially received) are used. You can enter the list of statuses to be taken into account separated by commas for this calculation (example: 0,1,2,3)

*'''STOCK_MOVEMENT_LIST_HIDE_UNIT_PRICE''' ► to hide unit price on some pages (V15+)

*'''DISABLE_QTY_OVERWRITE''' ► Disable quantity overwrites on inventories ► (v19.0)
*'''MAIN_WAREHOUSE_LIST_DISPLAY_MODE''' ► Change warehouse select list display mode ► (v21.0) (see github pull request [https://github.com/Dolibarr/dolibarr/pull/31013 #31013] for more info)
**0 : Default behavior, display parents of warehouse
**1 : Display only current warehouse label only
**2 : Display last parent warehouse label

[[#Top|(back to top)]]

=Stripe=

*'''STRIPE_USE_INTENT_WITH_AUTOMATIC_CONFIRMATION''' ► 1 is the default mode and will use the native Stripe form for the checkout (with card only), 2 will use the native Stripe form (PaymentElement complete, multi payment modes). Note that STRIPE_USE_NEW_CHECKOUT is an abandonned alternative (so no more NEW, that does not bring real added value)

=Suppliers Module=

*'''FOURN_PRODUCT_AVAILABILITY''' ► On the Suppliers price page of the products, activate the supplier product availability. ''This is duplicate feature with delivery_delay introduced with 3.8.''

*'''RELOAD_PAGE_ON_SUPPLIER_CHANGE''' ► On creation of a supplier order/invoice, reload form with supplier-specific details when supplier is selected from drop-down list.

*'''SUPPLIER_INVOICE_WITH_PREDEFINED_PRICES_ONLY''' ► Restrict selection of products in supplier invoice to only those with a buying price defined for that supplier. ► (v6.0+)

*'''SUPPLIER_ORDER_AUTOADD_USER_CONTACT''' ► Add user approving supplier order as a contact automatically.

*'''SUPPLIER_ORDER_DEFAULT_PAYMENT_MODE_ID''' ► Set the default payment method for suppliers (<code>rowid</code> in table <code>llx_c_paiement</code>).

*'''SUPPLIER_ORDER_USE_DISPATCH_STATUS''' ► Add a status on each dispatch order line when receiving products from suppliers ► (v4.0+)

*'''SUPPLIER_ORDER_NO_DIRECT_APPROVE''' ► No button "Validate and Approve". Always do step "Validate" and "Approve" in 2 steps.

*'''SUPPLIER_ORDER_WITH_PREDEFINED_PRICES_ONLY''' ► Restrict selection of products in supplier order to only those with a buying price defined for that supplier. ► (v6.0+)

*'''SUPPLIER_ORDER_EDIT_BUYINGPRICE_DURING_RECEIPT''' ► Can modify the buying price used for PMP calculation when making a stock reception on a supplier order. ► (v6.0+)
*'''SUPPLIER_PROPOSAL_WITH_PREDEFINED_PRICES_ONLY''' ► Restrict selection of products in supplier proposal to only those with a buying price defined for that supplier. ► (v6.0+)
*'''SUPPLIER_ORDER_MORE_THAN_WISHED''' ► The supplier order status is set to "Totally received" even if there are more products received than ordered. ► (v15.0+)

*'''DISPLAY_DISCOUNTED_SUPPLIER_PRICE''' ► Allow to display discounted supplier price when searching product in supplier documents ► (v10.0)

*'''MAIN_CAN_EDIT_SUPPLIER_ON_SUPPLIER_ORDER''' ► Allow to change the supplier on a draft supplier order ► (v10.0)

*'''SUPPLIER_PROPOSAL_ALLOW_EXTERNAL_DOWNLOAD'''

*'''SUPPLIER_ORDER_CAN_UPDATE_BUYINGPRICE_DURING_RECEIPT''' ► Allow to change price on receipt ► (v19.0)

*'''SUPPLIER_HIDE_SUPPLIER_OBJECTLINES''' ► Hide the supplier information on objectlines (invoices, etc..) ► (v19.0)

[[#Top|(back to top)]]

=Third Parties Module=

*'''COMPANY_AQUARIUM_CLEAN_REGEX''' ► Add a REGEX rule on the third parties names. It applies a regex replacement pattern on generated code if COMPANY_AQUARIUM_CLEAN_REGEX is set. Value must be a regex with parenthesis. The part into parenthesis is kept, the rest removed. For example if COMPANY_AQUARIUM_CLEAN_REGEX = '<code>^..(..)..(.*)</code>' the first char and second char are removed and the char 5 and 6 too ► (>= 8.0.1)

*'''MAIN_UNKNOWN_CUSTOMERS_ARE_COMPANIES''' ► See in Global options section.

*'''MAIN_USE_VAT_COMPANIES_IN_EEC_WITH_INVALID_VAT_ID_ARE_INDIVIDUAL''' ► See in Global options section.

*'''SOCIETE_EMAIL_MANDATORY''' ► E-mail is a mandatory field when creating a thirdparty

*'''SOCIETE_DISABLE_CUSTOMERS''' ► Remove all menu and features related to customers

*'''SOCIETE_DISABLE_PROSPECTS''' ► Remove all menu and features related to prospects
*'''SOCIETE_DISABLE_PROSPECTSCUSTOMERS ►''' Remove the status "Customer/Prospect" when thirdparties creation or modification

*'''SOCIETE_DISABLE_STATE''' ► Do not use field "state/province"

*'''SOCIETE_SORT_ON_TYPEENT''' ► The combo list of "type of third party" is sorted on alphabetical order instead of the field "position" that appears into dictionary instead.

*'''SOCIETE_ASK_FOR_SHIPPING_METHOD''' ► Shipping method can be predefined on customer card and will be used as default on order creation
*'''SOCIETE_ADD_REF_IN_LIST''' ► Displays the code before the name in the lists ► Value 1 -> Code + name + alias ou Code + name if colone alias 2 -> Code + alias 3 -> Alias

*'''THIRDPARTY_CAN_HAVE_CATEGORY_EVEN_IF_NOT_CUSTOMER_PROSPECT_SUPPLIER''' ► Possible to add Categories to third parties that are not customer, prospect or supplier.

*'''THIRDPARTY_DEFAULT_USELOCALTAX1''' ► When creating a new third party, the field "Use second tax" is set to on or off depending on value of this parameter.

*'''THIRDPARTY_DEFAULT_USELOCALTAX2''' ► When creating a new third party, the field "Use third tax" is set to on or off depending on value of this parameter.

*'''THIRDPARTY_NOTCUSTOMERPROSPECT_BY_DEFAULT''' ► Do not set status "Customer/Prospect" to "on" when creating a new third party from menu "New third party".

*'''THIRDPARTY_INCLUDE_PARENT_IN_LINKTO''' ► Search also for elements on parent third party when using the "link to" object feature.

*'''THIRDPARTY_INCLUDE_PROJECT_THIRDPARY_IN_LINKTO''' ► Search also for elements on third party that own the project of the current element when using the "link to" object feature (if project is owned by a different thirdparty than current one).

*'''THIRDPARTY_LOGO_ALLOW_EXTERNAL_DOWNLOAD''' ► When a logo is uploaded, a share key is automatically set so the file can be downloaded using the share key.

*'''THIRDPARTY_SUGGEST_ALSO_ADDRESS_CREATION''' ► Enabled contact creation on third-party create card
*'''THIRDPARTY_QUICKSEARCH_ON_FIELDS''' ► Personalized search criteria ► Example: $conf->global->THIRDPARTY_QUICKSEARCH_ON_FIELDS = 's.nom=ThirdPartyName;s.name_alias=AliasNameShort;s.code_client=CustomerCode'
*'''MEMBER_CAN_CONVERT_CUSTOMERS_TO_MEMBERS''' ► Enabled member creation on third-party create card
*'''SOCIETE_DISABLE_PARENTCOMPANY''' ► Disables attachment to a parent company.
*'''THIRDPARTY_CUSTOMERPROSPECT_BY_DEFAULT''' ► Set the third party to customer by default
*'''THIRDPARTY_SUPPLIER_BY_DEFAULT''' ► Set the third party to supplier by default
*'''THIRDPARTY_CUSTOMERTYPE_BY_DEFAULT''' ► Set the third party type by default (3 = customer & prospect / 2 = prospect / 1 = customer )
*'''CONTACT_DISABLE_PERSONALINFO''' ► Disable Personal data on contact page
*'''SOCIETE_DISABLE_WORKFORCE''' ► Disable work force selector on society page
*'''SOCIETE_SHOW_VAT_IN_LIST''' ► display VAT number in combo list of thirdparties ► (V15+)
*'''THIRDPARTY_DEFAULT_CREATE_CONTACT''' ► When set, a contact is created at the creation of an individual third party ► (v14.0)

*'''MAIN_SUPPORT_SHARED_CONTACT_BETWEEN_THIRDPARTIES''' ► Able to share contact between several third parties
*'''THIRDPARTY_CUSTOMERCODE_EQUALS_MEMBERREF''' ► When creating third parties out of members, the customer code is set equal to the member Ref. ► (v22.0)
*'''SOCIETE_NO_SYNC_LINKED_MEMBER''' ► If set, changes to a third party will not be synchronized to a linked member. ► (v23.0)

[[#Top|(back to top)]]

=Ticket Module=

*'''TICKET_SHOW_MESSAGES_ON_CARD''' ►Display all ticket related messages on the main ticket card. ► (>= 10.0)
*'''TICKET_AUTO_ASSIGN_CONTRACT_CREATE''' ►Automatically create a contract linked to the ticket ► (>= 10.0)
*'''TICKET_AUTO_CREATE_FICHINTER_CREATE''' ►Automatically create an intervention linked to the ticket ► (>= 10.0)
*'''TICKET_AUTO_ASSIGN_USER_CREATE''' '''►''' (>= 21.0) 0=No auto assignement, 1=Auto assign current user if no user was set, 2=Auto assign current user even if another user was set.
*'''TICKET_CHECK_NOTIFY_THIRDPARTY_AT_CREATION''' ►Automatically check "notify thirdparty at creation" ( >=16)
*'''TICKETS_MESSAGE_FORCE_MAIL''' ► Pre check email sending on ticket message (>=15)
*'''TICKET_SEND_PRIVATE_EMAIL ►''' Allow a private message to be sent by mail (>=17)
*'''TICKET_LIMIT_VIEW_ASSIGNED_ONLY''' '''►''' Only display tickets assigned to the user
*'''TICKET_ADD_AUTHOR_AS_CONTACT''' '''►''' If set to 1: Automatically adds the author as internal contact. If set to 2: Automatically adds the author as external contact if external user. (>=20)
*'''TICKET_ASSIGN_CONTACT_TO_MESSAGE''' '''►''' If known, the external contact is assigned to the message. (>=19)
*'''TICKET_ALLOW_CLASSIFICATION_MODIFICATION_EVEN_IF_CLOSED''' '''►'''Allow modify ticket classification even if closed. (>=19)
*'''WORKFLOW_TICKET_CLOSE_INTERVENTION''' ►On ticket close, automatically close an intervention linked to the ticket
*'''TICKET_INCLUDE_SUSPENDED_STATUS''' ► Use ticket suspended status (>=19)
*'''TICKET_INCLUDE_LINK_TO_PUBLIC_INTERFACE_IN_MESSAGE''' ► Add a link in bottom of emails sent from ticket page with link to public ticket admin tool (>=22)

=VAT Report=

*'''MAIN_INCLUDE_ZERO_VAT_IN_REPORTS''' ► Include lines with VAT to 0% (for "auto-liquidation" in EEC) ► (v8.0.3+)

[[#Top|(back to top)]]

=Website Module=

*'''WEBSITE_USE_WEBSITE_ACCOUNTS''' ► Add a table and a tab to manage some accounts for websites to a third party
*'''WEBSITE_ALLOW_OVERWRITE_GIT_SOURCE''' ► Add a button to export a website over the GIT sources
*'''WEBSITE_ADD_CSS_TO_BODY''' ► Add a CSS class to the body tag of websites

[[#Top|(back to top)]]

 

=WYSIWYG Editor=

*'''FCKEDITOR_ENABLE_DETAILS_FULL''' ► Can cut and paste external images (hosted on external server) into description of proposal, orders or invoices. WARNING: PDF generation is not guaranteed with this. Also if the image is removed or renamed by the image hosting service, your proposal, order or invoice will be broken.
*'''FCKEDITOR_ALLOW_ANY_CONTENT''' ► Allow to enter any content. However, this will totally disable content filtering which is one of the most important CKEditor features. You can use this to keep all your tags and attributes in the html content.
*'''FCKEDITOR_ENABLE_SCAYT_AUTOSTARTUP''' ► Allow to activate the SpellCheckAsYouType (SCAYT) plugins of CKEditor i.e an automatic spell checking. The value to activate this option is 1.
*'''MAIN_ALLOW_WYSIWYG_LOCAL_MEDIAS_ON_PRIVATE_NETWORK''' ► By default, you can add medias links (img src or other) into the rich text content editor, but you can't add links like that use a local host like "https://localhost/file". If you set this option to 1, you can.
*'''MAIN_ALLOW_WYSIWYG_EVEN_ON_UNSECURED_EXTERNAL_HTTP_URL''' ► By default, you can add medias links (img src or other) into the rich text content editor, but not if the link is a unsecure "http" url (not https) and your Dolibarr is http. If you set this option to 1, you can.

[[#Top|(back to top)]]

=STRIPE Module=

*'''STRIPE_FORCE_VERSION''' ► Force the STRIPE version. For Example: "2019-09-09" (v11+)
*'''STRIPE_REUSE_EXISTING_INTENT_IF_FOUND''' ► With this, you will have idempotency key but the payment intention will be reuse and not Generate again (13+)

[[#Top|(back to top)]]

=ClickToDial Module=

*'''CLICKTODIAL_FORCENEWTARGET''' ► Open in new page.

[[#Top|(back to top)]]

 

=For SaaS / Cloud hosting integrators=

The following options are useless for a common usage of Dolibarr. But they are usefull if you plan to host / provide Dolibarr instances as Software As A Service (SAAS) to your customers.

*'''CRON_DISABLE_KEY_CHANGE''' ► When you provide an instance to a customer, you probably also add an entry in the cron of this user so Dolibarr batch and scheduler can work correctly. For security purpose, it may have a security key that is inside the command line into the cron entry and this entry must match the value defined into Dolibarr setup (setup of module 'Scheduled Jobs'). Because, a customer of a Saas platform will probably have no access to edit the cron file, it is also import that he has no way to edit the key into the Dolibarr setup, so the key in the cron command line will always match the key in Dolibarr setup, and the Dolibarr batches will executed without security errors. To be sure, the customer does not change the value, you can set this constant to 1 into the table [[Table_llx_const]].

*'''CRON_DISABLE_TUTORIAL_CRON''' ► Disable the tutorial about how to install the cron script (on a SaaS hosting, this should be done by the web hosting provider)

*'''CRON_WARNING_DELAY_HOURS''' ► Set this value to the frequency set for the cron script (so a warning will be shown to user to warn it about max frequency of its scheduled jobs)

*'''MAILING_NO_USING_PHPMAIL''' ► To avoid bad use of the emailing module, it is recommended to set this option to 1 (This option is described previously). Also you can complete the message visible by customers when they try to setup the SMTP credentials of their Dolibarr by using the constant MAILING_SMTP_SETUP_EMAILS_FOR_QUESTIONS (This option is described previously). For example, you can point to a FAQ on your website.

*'''MAIL_MAX_NB_OF_RECIPIENTS_IN_SAME_EMAIL''' ► If you have set a system limit on number of recipients on your system, you can set also this option to match the same value, so users will be informed: So '''MAIL_MAX_NB_OF_RECIPIENTS_IN_SAME_EMAIL''' restricts sending of 1 email message to <code>x</code> recipients for the same email message (x for To: + CC: + BCC:). If not defined, value is <code>10</code>. Required to fight against spamming that include a ton of recipients in 1 message. Note that '''MAIL_MAX_NB_OF_RECIPIENTS_TO_IN_SAME_EMAIL''', '''MAIL_MAX_NB_OF_RECIPIENTS_CC_IN_SAME_EMAIL''' and '''MAIL_MAX_NB_OF_RECIPIENTS_BCC_IN_SAME_EMAIL''' are also available. Note that this is not a hard limit; it is just the quantity that will be displayed on warnings on screen. For a real limit, this must be implemented into the system.

*'''MAILING_LIMIT_SENDBYDAY''' ► This is a limit of number of emails, an instance can send. Note that this is not a hard limit; it is just the quantity that will be displayed on warnings on screen. For a real limit, this must be implemented into the system.

*'''MAILING_LIMIT_WARNING_PHPMAIL''' ► Set this value to a translation key. Then add translation keys into the instance so user will see a message when into the email setup page. For example, you can set a message to say: ''Warning: To avoid abuse, when using default setup, you are restricted to 500 emails per day for all your application (account may be suspended in case of violation of this rule. You can setup application to use your own SMTP server for sending email so you want have no restriction at all (see menu Home-Setup-Emails)''

*'''MAIN_ALWAYS_CREATE_LOCK_AFTER_LAST_UPGRADE''' ► If set, when you launch upgrades of your customer instances, you are sure that the upgrade process recreate automatically the file install.lock and remove the upgrade.unlock so the administration tools like install.php, upgrade.php and repair.php can't be used on your customer instance (until the install.lock file is deleted or the upgrade.unlock file is created).

*'''MAIN_EXTERNAL_SMTP_CLIENT_IP_ADDRESS''' ► (A better name of this option should be MAIN_EXTERNAL_MAIL_CLIENT_IP_ADDRESS). Set here the list of IPs where your Dolibarr instances are hosted, separated by a comma. So, when your customer go into the Email setup area:
**If he has chosen mail method, a message will explain him how to setup its SPF record for its email domain (showing the list of IP). This is to avoid to have its emails, sent from its Dolibarr instance, fails due to strict antispam rule of some emailing servers.
**If he has chosen smtp method, a message will explain him the list of IP he can use if there is restriction on IP by the SMTP agent. If you also need to add a message to help SPF setup, see option '''MAIN_EXTERNAL_SMTP_SPF_STRING_TO_ADD'''.

You can also provide a list of URLs that return just an IP instead of a list of hardcoded IP. So you can for example set 1 url that contact a whoami service that return the public IP of server and another one doing the one on a IPv6 address, so on the setup page, the public IP adress of the server will always be uptodate for both ipv4 and ipv6 (Example: "https://ipv4.server.com/_service_showmyip.php,https://ipv6.server.com/_service_showmyip.php")

*'''MAIN_EXTERNAL_SMTP_SPF_STRING_TO_ADD''' ► Set here the string to add in the SPF record This string will be shown into a help message when the user in in the setup of email page and has choose a method using an external SMTP server.

*'''MAIN_FIRST_PING_OK_ID''' ► Set this value to "disabled" to remove completely any ping after a complete setup.

*'''MAIN_FILECHECK_LOCAL_SUFFIX''' and '''MAIN_FILECHECK_LOCAL_EXT''' ► If you offer a customized or patched version of Dolibarr, when the user will use the tool to check the integrity of files, the default xml file name used for signature checking will be the official file provided by the Dolibarr team, so it does not includes your own changes. To have the suggested signature file being your own file, you can set the constant MAIN_FILECHECK_LOCAL_SUFFIX to a suffix. For example, set this to "'''-mysaassolution'''". So, when the user will use the file integrity tool, the default file to check for signature will be "'''/install/filelist-10.0.2-mysaassolution.xml'''" instead of "'''/install/filelist-10.0.2.xml'''". All you have to do is generate the signature file '''mysaassolution''' using the tool '''build/generate_filelist_xml.php''' and put this file into the install directory of your customer instance. Doing this, your customer, and yourself, will be able to check if a file was modified without being disturbed by false alerts due to your customized files or patches (they will be included in the signature used for check). Also, if you want to zip the customized signature file into "'''/install/filelist-10.0.2-mysaassolution.xml.zip'''", you can set the constant MAIN_FILECHECK_LOCAL_EXT to '.zip'.

*'''MAIN_HIDE_WARNING_TO_ENCOURAGE_SMTP_SETUP''' ► Set to 1 by default (so warning is hidden). You can set it to 0 to show a warning to encourage admin to set its own SMTP service.

*'''MAIN_MAIL_SENDMODE_password''' ► To force the mode to send the email on the "password forgotten" page. So you can decide to use php mail or SMTP method for this specific use case.

*'''MAIN_MIN_NB_ENABLED_MODULE_FOR_WARNING''' ► If set to N, the warning saying modules are not activated will be shown if number of activated module is < N (Having this variable not defined is same than having it set to 1). This may be usefull if you preinstall an application with some modules already loaded by default and you want to keep the warning to be sure the user will enable other modules he need, even if some modules are already enabed.
*'''MAIN_SETUP_MODULES_DESC''' ► If your installation is already done with activated module, the help message to explain how to enable a module on the setup page is hidden. You can keep it visible by adding this option to 1.

*'''MAIN_NO_UPGRADE_REDIRECT_ON_LEVEL_3_CHANGE''' ► The page to make the migration is not shown automatically when you deploy files of version X.Y.Z+delta over an installation with a database version X.Y.Z. The upgrade page will be shown automatically only if there is a change on value of X or Y in version.

*'''SYSLOG_DISABLE_LOGHANDLER_SYSLOG''' ► Set this to 1 to disable usage of syslog (having all customer instances logging in the same system file is not a good idea).

*'''WEBSITE_REPLACE_INFO_ABOUT_USAGE_WITH_WEBSERVER''' ► Put here a text or a translation key of a text to show when the user will use the feature "Deploy" when he want to deploy a website done with Dolibarr CMS. So you can, for example, show him a message that this feature is not part of its subscription and putting a website online may need a complementary subscription.

[[#Top|(back to top)]]

Module EInvoicing (Generic, FR, ...)

2026-10-08T10:43:13Z

Eldy: /* On the Dolibarr of your customers */

[[Category:Complementary modules]]
{{TemplateDocDevEn}}
{{TemplateDocUser}}
=Information=
{{TemplateModuleInfo
|modulename=EInvoicing (Formerly PDPConnectFR)
|editor=Dolibarr community
|web=
|webbuy=From your Dolibarr v24+, menu Home - Setup - Modules - Find external modules, search on "einvoice"
|status=experimental
|prerequisites=
|minversion=
|maxversion=
|note=Recommended version: 24.0+
}}

=Features=
This module adds support of EInvoice in Dolibarr for some countries. Generating, Sending and Receiving EInvoice is mandatory in some countries, this module deals initialy with the case of France (even if it was designed to support other countries).

For a solution dedicated to other countries, take a look at the page [[Electronic Billing]].

The module allows your Dolibarr to generate EInvoice and to connect to some official Access Point (Plateforme Agréées) to send and retrieve your invoice documents. The supported EInvoice format are:

*CII (Dolibarr v18+, recommended Dolibarr v24+)
*Factur-X (only Dolibarr v24+)
*More format like UBL could be added by contributing (see Development chapter)

Warning: Using the Factur-X format is not recommended. It works with few Access Point only and even if accepted by your own AP, it may be refused by the AP of your customer due to hidden problems inside the format itself and library conflicts when using Dolibarr < 24.0. Also, it consumes a high amount of disk per invoice (an Einvoice may be 1 Mb if you have large images inside !) and make analysis very difficult when there is a trouble. It is highly recommended to use the CII format that is standard and supported by all Access Points, is easier to produce, analyse and process (an Einvoice is a text xml file of 10Kb only) and is not sentitive to PHP or Dolibarr versions.

=Installation=
==With Dolibarr v24+==
Go into menu Home - Setup - Search external modules
Search on einvoicing and click on Install.

The module is available. Go to configuration step.

==With any Dolibarr version==
===Install from dolistore.com===
Go and download the archive zip of the einvocing free module from dolistore.com

Go on menu Home - Setup - Install external module
Upload the zip, the module is available. Go to configuration step.

===Install using git===
In the meantime, install the module in the '''/custom''' directory of your dolibarr. For this, go into the /custom directory:
cd mydolibarrdir/htdocs/custom
Then download the module directory '''einvoicing'''
git clone https://github.com/Dolibarr/dolibarr-community-modules; mkdir einvoicing; cp -pr dolibarr-community-modules/einvoicing/* einvoicing; rm -fr dolibarr-community-modules;

=Setup=

'''Using the french guide:'''
You can have a look at the french |https://www.dolicloud.com/fr/guide-facturation-electronique-dolibarr.php Guide de la facturation électronique pour Dolibarr].

'''Using english help:'''
Go onto the setup of the modulefrom menu "Home - Setup - Modules - Module EInvoice - Wheel configuration".

The first step is to choose, from the combo list, which Access Point you want to use to send your EInvoice. You can select between one in the following list:

*SuperPDP
*EsaLink (hubtimize)
*More providers are coming (See chapter Development to know how to contibute to add your own Provider)

All access point provided by the module are official Access Points (Plateforme Agréée).

==Setup with SuperPDP Access Point==
If you choose [https://www.superpdp.tech SuperPDP] as your official Production Access Point (or as a Test Access Point), you must create an account by clicking on the link suggested by the setup page of the module (link should be https://www.superpdp.tech/app/users/create).

Note that for a production usage, you may need to provide a scan of an identity card. The process of creating an account may last few minutes.

Once your account is created, you must generate credentials to allow Dolibarr to connect to SuperPDP: For this, go into your SuperPDP dashboard, and from the left menu "'''Applications'''", click on "'''New Application'''" to create a new setup for the application Dolibarr. Choose if you want a setup for Production (Real usage) or for Test (Sandbox). Then select the company and the type of application "'''Confidential'''" and click "'''Create'''" (you can keep the field "URLs of redirection" to empty or paste the value provided by Dolibarr setup page).

''The page to get credentials for an application''

[[File:Einvoice superpdp setup.png|border]]

Your credential ('''client_id''' and '''client_secret''') are created and are shown on the next screen.

Go into Dolibarr, into the page to setup the module EInvoice and enter these 2 values, click on Save to save the data and click on "Connect" to get the security key to exchange with SuperPDP.

That's all, you are connected with SuperPDP (For Production usage or for Test depending on the choice you made). To be sure, you can try the link "Test of connection (healthcheck)" to verify the connection.

''Example of setup for sandbox use with an account of SuperPDP''

[[File:Einvoice setup example.png|border]]

[[File:Warning.png]] By default, you can enter only one set of credentials for the Production mode and one set of credentials for the Test mode, so if your Dolibarr instance is a test instance, enter test credentials and set the switch to Test, and if your Dolibarr instance is a production instance, enter credentials of production and set the switch to Production. Even if you can switch from one environment to another one, it is seriously not recommended to save and use both Test and Production credentials in the same Dolibarr instance; Only the Access Point environment is different but your Dolibarr is the same. So if you mix two Access Point environments (Test and Prod) in the same Dolibarr, you may get or send tests invoices on your production instance (and the opposite), so the best thing to avoid this is to enter credentials only for one environment and never for the other. See chapter "Usage in sandbox for test" for more information on how to use the module in a sandbox context.

==Setup VAT exemptions (VATEX), if applicable==
If your business is exempted of VAT, tell Dolibarr the default reason of exemption that will be exported in the EInvoice.

Take note of the VATEX-xxxx code that matches your business and save it into Dolibarr:

*In Dolibarr <= 23, go to "Configuration - Misc" and add a new variable '''MAIN_VAT_EXEMPTION_CODE_FOR_0''' with the VATEX-xx-xxxx matching your situation.
*In Dolibarr >24, save it to the VAT dictionary

''Example: French companies concerned with Art 293B of CGI will type <code>VATEX-FR-FRANCHISE</code>''

==Setup with Esalink/Hubtimize Access point==
L'utilisation de la Plateforme Agréée ESALINK ne se souscrit pas en direct : elle passe obligatoirement par un '''membre distributeur''' de l'association PDP Libre, référencé sur la page [https://pdplibre.org/solutions/ Solutions].

=Usage for production=
==Send a customer invoice==
Once a Dolibarr invoice is generated (and validated), you can use a new button "'''Generate the Einvoice'''".

Note: you can have this action done automatically if you enable the option from menu Home - Setup - Modules - Module Einvoice - Configuration - Tab "other options" and switch "Generate automatically Einvoice".

Once an EInvoice has been generated, you can use the button to "'''Send the invoice'''" to the access point. Wait a minute while the access point answers and observe the returned status code:

*'''Code 200''': the access point has successfully sent the invoice to the client and is waiting for an answer from the customer's approval
*'''Code 213''': rejected: the access point has detected an anomaly on the invoice. Review all invoice data and VAT fields. Download the ''FA-xxxxx_cii.xml'' file from Dolibarr and send it to [https://www.superpdp.tech/outils/validateur-facture-electronique/ a CII validator] to get more information about the anomaly. If you need help, ask [https://www.dolibarr.fr/forum/ on the forum].
*'''Code 210''': the customer explicitly refused the invoice, get it touch with the customer to know why they did not accept the invoice.

'''Note about invoices generated by the POS Module TakePOS'''

By default, any invoice generated by the POS has status "Do not manage Einvoice". For such sales, it is not expected that you send an EInvoice. Instead you will have to send a "report" for all sales done by the point of sale (this will be supported by the module, later as this requirement is expected only for the 1st of september 2027).

==Retrieve vendor invoices==
Go into menu Home - Invoice - EInvoice synchronization.

Click on the button to launch synchronization.

If you experience an error, follow the instruction. for example:

*If you try to import a vendor invoice and the vendor can not be found in your Dolibarr database of suppliers, a link will be suggested to create it.
*If you try to import a vendor invoice and a product line can not be found in your Dolibarr database of products, a link will be suggested to create the product (You may also prefer to edit the vendor card to define a default Product Ref to use when doing an import of a product that is unknown, so each time a product is unknown for this vendor, Dolibarr will use the same default product instead of creating a new one each time).

=Usage in the sandbox env for test=
Using the module in sandbox environment is the same than using it in production mode. Only the credentials to connect to your Access Point differ.

If you are a developper, you can enable the option EINVOICING_ALLOW_DEV_TOOLS to 1 into menu "Home - Setup - Other". This will add more features for developers into an additional tab "Dev tools".
You can also switch the Test / Production mode from the main tab of the setup section of the module. WARNING: Using the switch is dangerous as it allows mixing invoices from different networks in the same Dolibarr instance.

==Using the sandbox and Peppol test Network for tests using several Access Points==
If you are using credentials to use the sandbox mode of SuperPDP, you may need to modify the setup of your company (Menu Home - Setup - Company/Organization) to record the same SIREN than the one of the test company provided by SuperPDP sandbox (So "000000001" for Tricatel or "000000002" for Burger Queen).

However the '''EInvoice address''' is NOT the same than the '''SIREN''' (it is the same in production mode only), so you must also force the Einvoice address of the company into the setup of the module Einvoice: To know your EInvoice address of your test company, go into the SuperPDP dashboard, in sandbox mode, and click on the label of the test company (for example Tricatel), you should see a list of the addresses of this test company in the annuary (the address to find you on the shared test Access Point network). The invoice address to use is the value after the "225:", the one starting with 315143296_XXX with XXX that depends on your account.
Once both are saved, a warning may appear to say that SIREN and Einvoice address ID are not the same. You can ignore it in test environment.

If your SIREN (menu Home - Setup - Company/Organisation) and your EInvoice address (menu Setup - Modules - Einvoice - Configuration) are correctly filled (Example: SIREN: 00000001 and EInvoice address 315143296_XXX), then you can send and retreive invoices from or to any other Access Points working on the Peppol Test network (The SuperPDP sandbox is automatically linked to the Peppol Test network when you use the sandbox credential).

To send an invoice to a test customer available onto another Access Point, as the Peppol network are using addresses that are different from SIREN, you can force the customer EInvoice address from the thirdparty card by editing the field EInvoice address.

''Example of the thirdparty card to send an einvoice from SuperPDP to the customer Test with SIREN 145678239 available at Esalink''

[[File:Einvoice setup customer address.png|border]]

=Options for integrators (mode proxy)=
If you are an integrator or web hosting provider (called P) and you want to provide a solution to allow your customers (Called C) to register and use the einvoicing system in one click, without having to pay (all payments will be done by yourself) the module provides a solution. This is possible with the mode "Proxy" of the einvoicing module and the platform SuperPDP:

== On your own Dolibarr (the proxy) ==
*Install the module einvoicing on your own production Dolibarr of your company P.
*Go into Home - Setup - Other and add the constant EINVOICING_SUPERPDP_VIAPARTNER='proxy'. So your Dolibarr will be able to act as a proxy between your customers C and SuperPDP. Only you need to setup the client_id and client_secret of your API account of SuperPDP (Your customer will register using a simple click, see later).
*Once you have set the option EINVOICING_SUPERPDP_VIAPARTNER to 'proxy' on your own production Dolibarr, go into the setup of the module and choose "SuperPDP as proxy".
*Switch to SuperPDP dashboard and create an application on your SuperPDP account. The URL to allow for OAuth is provied on the Dolibarr setup screen. You will get the client_id and client_secret. Goback into the Dolibarr setup page of the module, and enter the keys. Remind the value of the EINVOICING_SUPERPDP_VIAPARTNER_OAUTH_URL shown, you will need it to the setup your customer instances.
*Once setup is done, you can switch back to the provider "SuperPDP direct access" for yourself (for your company P). The choice "SuperPDP Poxy" is here only to allow to enter some specific option. They are not lost if you go back to another Access Point provider and your Proxy is still active as long as its dedicated setup is ok.

== On the Dolibarr of your customers ==
Now you can deploy the module on all instances of your customers. You must also set the followign constant on the instance of your customer:
* EINVOICING_SUPERPDP_VIAPARTNER_OAUTH_URL = the value provided at previous step (so one constant value for all your customers).
* You can also enter the constant EINVOICING_SUPERPDP_VIAPARTNER = 'YourCompanyName'.
That's all. You customer will see, in the setup of the module a choice "Register to SuperPDP via YourCompanyName". If they select this, they will see a link "Register to SuperPDP via YourCompanyName" and clicking on it will allow them to register without need to create account, no need to create an application, no need to generate and enter API key for each of your customer. The user has just to confirm the creation of its account, and a token to use its account will be recorded into its instance.
Also, you will see all your customer use of the API into the section "Sessions" of your SuperPDP dashboard.

=External Tools=
==E-Invoicing directory==

===Test directory===
To check or see companies/Einvoice ID in a directory, you can use one of these tools

*[https://test-directory.peppol.eu/public/locale-en_US/ Test Peppol directory]
*[https://www.superpdp.tech/outils/info-annuaire/?query=493861496&mode=fr&env=sandbox SuperPDP tool]

===Production directory===
You can use one of these tools to check if a company is in the production directory.

*[https://directory.peppol.eu/public/locale-en_US/ Peppol directory]
*[https://facturation.chorus-pro.gouv.fr/annuaire/#/ French governement directory]
*[https://www.superpdp.tech/outils/info-annuaire/?query=493861496&mode=fr&env=production SuperPDP directory]

==Validation of an EInvoice==
To validate an existing einvoice, you can use one of these tools:

*[https://www.superpdp.tech/outils/validateur-facture-electronique From SuperPDP (CII or Factur-X einvoices)]
*[https://services.fnfe-mpe.org/account/home From FNFE (Factur-X only, need an account)]
*[https://www.itb.ec.europa.eu/invoice/upload From Europa.eu (CII or UBL)]
*[https://ecosio.com/en/peppol-e-invoice-xml-document-validator/ From Ecosi (CII choose CrossIndustryInvoice D16B)]

=Troubleshooting=

==Life cycle and error codes for French EInvoicing==
[[File:Le cycle de vie d’une facture électronique.png|border|1200x1200px|Lifecycle of an electronic invoice]]

==Current error cases==

[[File:Warning.png]] Error "The company fr_siren:123456789 is not subject to the e-invoicing reform"

For France:

*Check that your company can be found from this annuary: https://annuaire-entreprises.data.gouv.fr/
*Then check inside this one: https://facturation.chorus-pro.gouv.fr/annuaire/#/

If you have this error, it probably means you CAN be found in the first one but NOT in the second one. This is a problem known by the DGFIP. What to do? You can't do nothing on your own. You must wait that the french governement add your SIREN record in the second annuary too. You can try to contact import.gouv.fr asking them to "appear in the second annuary to activate the einvoicing" to make things faster, but this works only in few cases only. For all others cases you must wait you appear in the second annuary before retrying to register.

[[File:Warning.png]] Error: HTTP 400 - CREATE_ERROR - pre-check: receiver address does not accept this document.

Check the SIREN and the Einvoice address of the customer. If you set only a SIREN with no specific Einvoice addess (the most common case), check that this SIREN exists that an Einvoice address in the network annuary exists with for this SIREN value. If you used a specific Einvoice address in addition to the SIREN, check that the couple SIREN/Einvoice address is a valid existing couple in the annuary.

=Development=

==Still to do==

*The E-reporting (mandatory in France the 1st september 2027), to report sales done by the Point of Sale module for example. Planned for begin of 2027.

==Sources==
{{TemplateModCommunityEn}}

==Einvoice Specifications==

Specification for France are available on https://www.boutique.afnor.org/en-gb/ and search on "XP Z12-012", "XP Z12-013", "XP Z12-014"
 
{| class="wikitable"
!Field code (Business Term)
!Desc
!Field in Dolibarr
|-
|BT-1
|Numéro de facture
|ref
|-
|BT-2
|Date de facture
|date
|-
|BT-3
|Type de document
|type (380 facture, 381 avoir, 384 rectificative, 386 acompte)
|-
|BT-8
|Exigibilité de la TVA
|TAX_MODE (5 débits / 72 encaissements)
|-
|BT-9
|Date d'échéance
|date_lim_reglement
|-
|BT-10
|Référence acheteur (code service)
|onglet Chorus Pro, sinon ref_client — Chorus Pro uniquement
|-
|BT-13
|Bon de commande du client
|ref_client de la facture, sinon ref_client de la commande liée
|-
|BT-14
|Notre numéro de commande
|ref de la commande liée
|-
|BT-23
|Cadre de facturation
|onglet Chorus Pro (facture ou fiche client)
|-
|BT-25
|Facture d'origine (avoir, acompte)
|fk_facture_source
|-
|BT-29
|SIRET vendeur / acheteur
|Id. prof. 2 (societe / tiers)
|-
|BT-30
|SIREN vendeur
|Id. prof. 1 de votre société
|-
|BT-31
|N° TVA vendeur
|TVA intracom. de votre société
|-
|BT-34
|Adresse électronique vendeur
|SIREN de votre société, schéma 0225
|-
|BT-46
|SIRET acheteur
|Id. prof. 2 du tiers
|-
|BT-47
|SIREN acheteur
|Id. prof. 1 du tiers
|-
|BT-48
|N° TVA acheteur
|TVA intracom. du tiers
|-
|BT-49
|Adresse électronique acheteur
|Id. prof. 5 du tiers, sinon son SIREN
|-
|BT-72
|Date de livraison
|delivery_date
|-
|BT-73/74
|Période de service
|dates de service des lignes
|-
|BT-89/90/91
|Prélèvement SEPA (RUM, ICS)
|RIB par défaut du tiers, PRELEVEMENT_ICS
|-
|BT-113
|Acomptes déjà réglés
|acomptes imputés sur la facture
|-
|BT-121
|Motif d'exonération de TVA
|calculé (franchise 293 B, intracom., autoliquidation, export)
|-
|BT-128
|Référence to other doc or object
|May be a reference to another invoice REF or a reference to something else (phone, ...)
|-
|BT-129
|Unité de la ligne
|unité du produit (fk_unit)
|-
|BT-146
|Prix unitaire
|total HT / quantité de la ligne
|-
|BT-151
|Catégorie de TVA
|calculée d'après le taux et le contexte
|-
|BT-84
|IBAN / BIC
|compte bancaire choisi dans la configuration 
|}

Module EInvoicing (Generic, FR, ...)

2026-10-08T10:42:32Z

Eldy: /* On the Dolibarr of your customers */

[[Category:Complementary modules]]
{{TemplateDocDevEn}}
{{TemplateDocUser}}
=Information=
{{TemplateModuleInfo
|modulename=EInvoicing (Formerly PDPConnectFR)
|editor=Dolibarr community
|web=
|webbuy=From your Dolibarr v24+, menu Home - Setup - Modules - Find external modules, search on "einvoice"
|status=experimental
|prerequisites=
|minversion=
|maxversion=
|note=Recommended version: 24.0+
}}

=Features=
This module adds support of EInvoice in Dolibarr for some countries. Generating, Sending and Receiving EInvoice is mandatory in some countries, this module deals initialy with the case of France (even if it was designed to support other countries).

For a solution dedicated to other countries, take a look at the page [[Electronic Billing]].

The module allows your Dolibarr to generate EInvoice and to connect to some official Access Point (Plateforme Agréées) to send and retrieve your invoice documents. The supported EInvoice format are:

*CII (Dolibarr v18+, recommended Dolibarr v24+)
*Factur-X (only Dolibarr v24+)
*More format like UBL could be added by contributing (see Development chapter)

Warning: Using the Factur-X format is not recommended. It works with few Access Point only and even if accepted by your own AP, it may be refused by the AP of your customer due to hidden problems inside the format itself and library conflicts when using Dolibarr < 24.0. Also, it consumes a high amount of disk per invoice (an Einvoice may be 1 Mb if you have large images inside !) and make analysis very difficult when there is a trouble. It is highly recommended to use the CII format that is standard and supported by all Access Points, is easier to produce, analyse and process (an Einvoice is a text xml file of 10Kb only) and is not sentitive to PHP or Dolibarr versions.

=Installation=
==With Dolibarr v24+==
Go into menu Home - Setup - Search external modules
Search on einvoicing and click on Install.

The module is available. Go to configuration step.

==With any Dolibarr version==
===Install from dolistore.com===
Go and download the archive zip of the einvocing free module from dolistore.com

Go on menu Home - Setup - Install external module
Upload the zip, the module is available. Go to configuration step.

===Install using git===
In the meantime, install the module in the '''/custom''' directory of your dolibarr. For this, go into the /custom directory:
cd mydolibarrdir/htdocs/custom
Then download the module directory '''einvoicing'''
git clone https://github.com/Dolibarr/dolibarr-community-modules; mkdir einvoicing; cp -pr dolibarr-community-modules/einvoicing/* einvoicing; rm -fr dolibarr-community-modules;

=Setup=

'''Using the french guide:'''
You can have a look at the french |https://www.dolicloud.com/fr/guide-facturation-electronique-dolibarr.php Guide de la facturation électronique pour Dolibarr].

'''Using english help:'''
Go onto the setup of the modulefrom menu "Home - Setup - Modules - Module EInvoice - Wheel configuration".

The first step is to choose, from the combo list, which Access Point you want to use to send your EInvoice. You can select between one in the following list:

*SuperPDP
*EsaLink (hubtimize)
*More providers are coming (See chapter Development to know how to contibute to add your own Provider)

All access point provided by the module are official Access Points (Plateforme Agréée).

==Setup with SuperPDP Access Point==
If you choose [https://www.superpdp.tech SuperPDP] as your official Production Access Point (or as a Test Access Point), you must create an account by clicking on the link suggested by the setup page of the module (link should be https://www.superpdp.tech/app/users/create).

Note that for a production usage, you may need to provide a scan of an identity card. The process of creating an account may last few minutes.

Once your account is created, you must generate credentials to allow Dolibarr to connect to SuperPDP: For this, go into your SuperPDP dashboard, and from the left menu "'''Applications'''", click on "'''New Application'''" to create a new setup for the application Dolibarr. Choose if you want a setup for Production (Real usage) or for Test (Sandbox). Then select the company and the type of application "'''Confidential'''" and click "'''Create'''" (you can keep the field "URLs of redirection" to empty or paste the value provided by Dolibarr setup page).

''The page to get credentials for an application''

[[File:Einvoice superpdp setup.png|border]]

Your credential ('''client_id''' and '''client_secret''') are created and are shown on the next screen.

Go into Dolibarr, into the page to setup the module EInvoice and enter these 2 values, click on Save to save the data and click on "Connect" to get the security key to exchange with SuperPDP.

That's all, you are connected with SuperPDP (For Production usage or for Test depending on the choice you made). To be sure, you can try the link "Test of connection (healthcheck)" to verify the connection.

''Example of setup for sandbox use with an account of SuperPDP''

[[File:Einvoice setup example.png|border]]

[[File:Warning.png]] By default, you can enter only one set of credentials for the Production mode and one set of credentials for the Test mode, so if your Dolibarr instance is a test instance, enter test credentials and set the switch to Test, and if your Dolibarr instance is a production instance, enter credentials of production and set the switch to Production. Even if you can switch from one environment to another one, it is seriously not recommended to save and use both Test and Production credentials in the same Dolibarr instance; Only the Access Point environment is different but your Dolibarr is the same. So if you mix two Access Point environments (Test and Prod) in the same Dolibarr, you may get or send tests invoices on your production instance (and the opposite), so the best thing to avoid this is to enter credentials only for one environment and never for the other. See chapter "Usage in sandbox for test" for more information on how to use the module in a sandbox context.

==Setup VAT exemptions (VATEX), if applicable==
If your business is exempted of VAT, tell Dolibarr the default reason of exemption that will be exported in the EInvoice.

Take note of the VATEX-xxxx code that matches your business and save it into Dolibarr:

*In Dolibarr <= 23, go to "Configuration - Misc" and add a new variable '''MAIN_VAT_EXEMPTION_CODE_FOR_0''' with the VATEX-xx-xxxx matching your situation.
*In Dolibarr >24, save it to the VAT dictionary

''Example: French companies concerned with Art 293B of CGI will type <code>VATEX-FR-FRANCHISE</code>''

==Setup with Esalink/Hubtimize Access point==
L'utilisation de la Plateforme Agréée ESALINK ne se souscrit pas en direct : elle passe obligatoirement par un '''membre distributeur''' de l'association PDP Libre, référencé sur la page [https://pdplibre.org/solutions/ Solutions].

=Usage for production=
==Send a customer invoice==
Once a Dolibarr invoice is generated (and validated), you can use a new button "'''Generate the Einvoice'''".

Note: you can have this action done automatically if you enable the option from menu Home - Setup - Modules - Module Einvoice - Configuration - Tab "other options" and switch "Generate automatically Einvoice".

Once an EInvoice has been generated, you can use the button to "'''Send the invoice'''" to the access point. Wait a minute while the access point answers and observe the returned status code:

*'''Code 200''': the access point has successfully sent the invoice to the client and is waiting for an answer from the customer's approval
*'''Code 213''': rejected: the access point has detected an anomaly on the invoice. Review all invoice data and VAT fields. Download the ''FA-xxxxx_cii.xml'' file from Dolibarr and send it to [https://www.superpdp.tech/outils/validateur-facture-electronique/ a CII validator] to get more information about the anomaly. If you need help, ask [https://www.dolibarr.fr/forum/ on the forum].
*'''Code 210''': the customer explicitly refused the invoice, get it touch with the customer to know why they did not accept the invoice.

'''Note about invoices generated by the POS Module TakePOS'''

By default, any invoice generated by the POS has status "Do not manage Einvoice". For such sales, it is not expected that you send an EInvoice. Instead you will have to send a "report" for all sales done by the point of sale (this will be supported by the module, later as this requirement is expected only for the 1st of september 2027).

==Retrieve vendor invoices==
Go into menu Home - Invoice - EInvoice synchronization.

Click on the button to launch synchronization.

If you experience an error, follow the instruction. for example:

*If you try to import a vendor invoice and the vendor can not be found in your Dolibarr database of suppliers, a link will be suggested to create it.
*If you try to import a vendor invoice and a product line can not be found in your Dolibarr database of products, a link will be suggested to create the product (You may also prefer to edit the vendor card to define a default Product Ref to use when doing an import of a product that is unknown, so each time a product is unknown for this vendor, Dolibarr will use the same default product instead of creating a new one each time).

=Usage in the sandbox env for test=
Using the module in sandbox environment is the same than using it in production mode. Only the credentials to connect to your Access Point differ.

If you are a developper, you can enable the option EINVOICING_ALLOW_DEV_TOOLS to 1 into menu "Home - Setup - Other". This will add more features for developers into an additional tab "Dev tools".
You can also switch the Test / Production mode from the main tab of the setup section of the module. WARNING: Using the switch is dangerous as it allows mixing invoices from different networks in the same Dolibarr instance.

==Using the sandbox and Peppol test Network for tests using several Access Points==
If you are using credentials to use the sandbox mode of SuperPDP, you may need to modify the setup of your company (Menu Home - Setup - Company/Organization) to record the same SIREN than the one of the test company provided by SuperPDP sandbox (So "000000001" for Tricatel or "000000002" for Burger Queen).

However the '''EInvoice address''' is NOT the same than the '''SIREN''' (it is the same in production mode only), so you must also force the Einvoice address of the company into the setup of the module Einvoice: To know your EInvoice address of your test company, go into the SuperPDP dashboard, in sandbox mode, and click on the label of the test company (for example Tricatel), you should see a list of the addresses of this test company in the annuary (the address to find you on the shared test Access Point network). The invoice address to use is the value after the "225:", the one starting with 315143296_XXX with XXX that depends on your account.
Once both are saved, a warning may appear to say that SIREN and Einvoice address ID are not the same. You can ignore it in test environment.

If your SIREN (menu Home - Setup - Company/Organisation) and your EInvoice address (menu Setup - Modules - Einvoice - Configuration) are correctly filled (Example: SIREN: 00000001 and EInvoice address 315143296_XXX), then you can send and retreive invoices from or to any other Access Points working on the Peppol Test network (The SuperPDP sandbox is automatically linked to the Peppol Test network when you use the sandbox credential).

To send an invoice to a test customer available onto another Access Point, as the Peppol network are using addresses that are different from SIREN, you can force the customer EInvoice address from the thirdparty card by editing the field EInvoice address.

''Example of the thirdparty card to send an einvoice from SuperPDP to the customer Test with SIREN 145678239 available at Esalink''

[[File:Einvoice setup customer address.png|border]]

=Options for integrators (mode proxy)=
If you are an integrator or web hosting provider (called P) and you want to provide a solution to allow your customers (Called C) to register and use the einvoicing system in one click, without having to pay (all payments will be done by yourself) the module provides a solution. This is possible with the mode "Proxy" of the einvoicing module and the platform SuperPDP:

== On your own Dolibarr (the proxy) ==
*Install the module einvoicing on your own production Dolibarr of your company P.
*Go into Home - Setup - Other and add the constant EINVOICING_SUPERPDP_VIAPARTNER='proxy'. So your Dolibarr will be able to act as a proxy between your customers C and SuperPDP. Only you need to setup the client_id and client_secret of your API account of SuperPDP (Your customer will register using a simple click, see later).
*Once you have set the option EINVOICING_SUPERPDP_VIAPARTNER to 'proxy' on your own production Dolibarr, go into the setup of the module and choose "SuperPDP as proxy".
*Switch to SuperPDP dashboard and create an application on your SuperPDP account. The URL to allow for OAuth is provied on the Dolibarr setup screen. You will get the client_id and client_secret. Goback into the Dolibarr setup page of the module, and enter the keys. Remind the value of the EINVOICING_SUPERPDP_VIAPARTNER_OAUTH_URL shown, you will need it to the setup your customer instances.
*Once setup is done, you can switch back to the provider "SuperPDP direct access" for yourself (for your company P). The choice "SuperPDP Poxy" is here only to allow to enter some specific option. They are not lost if you go back to another Access Point provider and your Proxy is still active as long as its dedicated setup is ok.

== On the Dolibarr of your customers ==
Now you can deploy the module on all instances of your customers. You must also set the followign constant on the instance of your customer:
* EINVOICING_SUPERPDP_VIAPARTNER_OAUTH_URL = the value provided at previous step (so one fixed value for all your customers).
* You can also enter the constant EINVOICING_SUPERPDP_VIAPARTNER = 'YourCompanyName'.
That's all. You customer will see, in the setup of the module a choice "Register to SuperPDP via YourCompanyName". If they select this, they will see a link "Register to SuperPDP via YourCompanyName" and clicking on it will allow them to register without need to create account, no need to create an application, no need to generate and enter API key for each of your customer. The user has just to confirm the creation of its account, and a token to use its account will be recorded into its instance.
Also, you will see all your customer use of the API into the section "Sessions" of your SuperPDP dashboard.

=External Tools=
==E-Invoicing directory==

===Test directory===
To check or see companies/Einvoice ID in a directory, you can use one of these tools

*[https://test-directory.peppol.eu/public/locale-en_US/ Test Peppol directory]
*[https://www.superpdp.tech/outils/info-annuaire/?query=493861496&mode=fr&env=sandbox SuperPDP tool]

===Production directory===
You can use one of these tools to check if a company is in the production directory.

*[https://directory.peppol.eu/public/locale-en_US/ Peppol directory]
*[https://facturation.chorus-pro.gouv.fr/annuaire/#/ French governement directory]
*[https://www.superpdp.tech/outils/info-annuaire/?query=493861496&mode=fr&env=production SuperPDP directory]

==Validation of an EInvoice==
To validate an existing einvoice, you can use one of these tools:

*[https://www.superpdp.tech/outils/validateur-facture-electronique From SuperPDP (CII or Factur-X einvoices)]
*[https://services.fnfe-mpe.org/account/home From FNFE (Factur-X only, need an account)]
*[https://www.itb.ec.europa.eu/invoice/upload From Europa.eu (CII or UBL)]
*[https://ecosio.com/en/peppol-e-invoice-xml-document-validator/ From Ecosi (CII choose CrossIndustryInvoice D16B)]

=Troubleshooting=

==Life cycle and error codes for French EInvoicing==
[[File:Le cycle de vie d’une facture électronique.png|border|1200x1200px|Lifecycle of an electronic invoice]]

==Current error cases==

[[File:Warning.png]] Error "The company fr_siren:123456789 is not subject to the e-invoicing reform"

For France:

*Check that your company can be found from this annuary: https://annuaire-entreprises.data.gouv.fr/
*Then check inside this one: https://facturation.chorus-pro.gouv.fr/annuaire/#/

If you have this error, it probably means you CAN be found in the first one but NOT in the second one. This is a problem known by the DGFIP. What to do? You can't do nothing on your own. You must wait that the french governement add your SIREN record in the second annuary too. You can try to contact import.gouv.fr asking them to "appear in the second annuary to activate the einvoicing" to make things faster, but this works only in few cases only. For all others cases you must wait you appear in the second annuary before retrying to register.

[[File:Warning.png]] Error: HTTP 400 - CREATE_ERROR - pre-check: receiver address does not accept this document.

Check the SIREN and the Einvoice address of the customer. If you set only a SIREN with no specific Einvoice addess (the most common case), check that this SIREN exists that an Einvoice address in the network annuary exists with for this SIREN value. If you used a specific Einvoice address in addition to the SIREN, check that the couple SIREN/Einvoice address is a valid existing couple in the annuary.

=Development=

==Still to do==

*The E-reporting (mandatory in France the 1st september 2027), to report sales done by the Point of Sale module for example. Planned for begin of 2027.

==Sources==
{{TemplateModCommunityEn}}

==Einvoice Specifications==

Specification for France are available on https://www.boutique.afnor.org/en-gb/ and search on "XP Z12-012", "XP Z12-013", "XP Z12-014"
 
{| class="wikitable"
!Field code (Business Term)
!Desc
!Field in Dolibarr
|-
|BT-1
|Numéro de facture
|ref
|-
|BT-2
|Date de facture
|date
|-
|BT-3
|Type de document
|type (380 facture, 381 avoir, 384 rectificative, 386 acompte)
|-
|BT-8
|Exigibilité de la TVA
|TAX_MODE (5 débits / 72 encaissements)
|-
|BT-9
|Date d'échéance
|date_lim_reglement
|-
|BT-10
|Référence acheteur (code service)
|onglet Chorus Pro, sinon ref_client — Chorus Pro uniquement
|-
|BT-13
|Bon de commande du client
|ref_client de la facture, sinon ref_client de la commande liée
|-
|BT-14
|Notre numéro de commande
|ref de la commande liée
|-
|BT-23
|Cadre de facturation
|onglet Chorus Pro (facture ou fiche client)
|-
|BT-25
|Facture d'origine (avoir, acompte)
|fk_facture_source
|-
|BT-29
|SIRET vendeur / acheteur
|Id. prof. 2 (societe / tiers)
|-
|BT-30
|SIREN vendeur
|Id. prof. 1 de votre société
|-
|BT-31
|N° TVA vendeur
|TVA intracom. de votre société
|-
|BT-34
|Adresse électronique vendeur
|SIREN de votre société, schéma 0225
|-
|BT-46
|SIRET acheteur
|Id. prof. 2 du tiers
|-
|BT-47
|SIREN acheteur
|Id. prof. 1 du tiers
|-
|BT-48
|N° TVA acheteur
|TVA intracom. du tiers
|-
|BT-49
|Adresse électronique acheteur
|Id. prof. 5 du tiers, sinon son SIREN
|-
|BT-72
|Date de livraison
|delivery_date
|-
|BT-73/74
|Période de service
|dates de service des lignes
|-
|BT-89/90/91
|Prélèvement SEPA (RUM, ICS)
|RIB par défaut du tiers, PRELEVEMENT_ICS
|-
|BT-113
|Acomptes déjà réglés
|acomptes imputés sur la facture
|-
|BT-121
|Motif d'exonération de TVA
|calculé (franchise 293 B, intracom., autoliquidation, export)
|-
|BT-128
|Référence to other doc or object
|May be a reference to another invoice REF or a reference to something else (phone, ...)
|-
|BT-129
|Unité de la ligne
|unité du produit (fk_unit)
|-
|BT-146
|Prix unitaire
|total HT / quantité de la ligne
|-
|BT-151
|Catégorie de TVA
|calculée d'après le taux et le contexte
|-
|BT-84
|IBAN / BIC
|compte bancaire choisi dans la configuration 
|}

Module EInvoicing (Generic, FR, ...)

2026-10-08T10:42:24Z

Eldy: /* On the Dolibarr of your customers */

[[Category:Complementary modules]]
{{TemplateDocDevEn}}
{{TemplateDocUser}}
=Information=
{{TemplateModuleInfo
|modulename=EInvoicing (Formerly PDPConnectFR)
|editor=Dolibarr community
|web=
|webbuy=From your Dolibarr v24+, menu Home - Setup - Modules - Find external modules, search on "einvoice"
|status=experimental
|prerequisites=
|minversion=
|maxversion=
|note=Recommended version: 24.0+
}}

=Features=
This module adds support of EInvoice in Dolibarr for some countries. Generating, Sending and Receiving EInvoice is mandatory in some countries, this module deals initialy with the case of France (even if it was designed to support other countries).

For a solution dedicated to other countries, take a look at the page [[Electronic Billing]].

The module allows your Dolibarr to generate EInvoice and to connect to some official Access Point (Plateforme Agréées) to send and retrieve your invoice documents. The supported EInvoice format are:

*CII (Dolibarr v18+, recommended Dolibarr v24+)
*Factur-X (only Dolibarr v24+)
*More format like UBL could be added by contributing (see Development chapter)

Warning: Using the Factur-X format is not recommended. It works with few Access Point only and even if accepted by your own AP, it may be refused by the AP of your customer due to hidden problems inside the format itself and library conflicts when using Dolibarr < 24.0. Also, it consumes a high amount of disk per invoice (an Einvoice may be 1 Mb if you have large images inside !) and make analysis very difficult when there is a trouble. It is highly recommended to use the CII format that is standard and supported by all Access Points, is easier to produce, analyse and process (an Einvoice is a text xml file of 10Kb only) and is not sentitive to PHP or Dolibarr versions.

=Installation=
==With Dolibarr v24+==
Go into menu Home - Setup - Search external modules
Search on einvoicing and click on Install.

The module is available. Go to configuration step.

==With any Dolibarr version==
===Install from dolistore.com===
Go and download the archive zip of the einvocing free module from dolistore.com

Go on menu Home - Setup - Install external module
Upload the zip, the module is available. Go to configuration step.

===Install using git===
In the meantime, install the module in the '''/custom''' directory of your dolibarr. For this, go into the /custom directory:
cd mydolibarrdir/htdocs/custom
Then download the module directory '''einvoicing'''
git clone https://github.com/Dolibarr/dolibarr-community-modules; mkdir einvoicing; cp -pr dolibarr-community-modules/einvoicing/* einvoicing; rm -fr dolibarr-community-modules;

=Setup=

'''Using the french guide:'''
You can have a look at the french |https://www.dolicloud.com/fr/guide-facturation-electronique-dolibarr.php Guide de la facturation électronique pour Dolibarr].

'''Using english help:'''
Go onto the setup of the modulefrom menu "Home - Setup - Modules - Module EInvoice - Wheel configuration".

The first step is to choose, from the combo list, which Access Point you want to use to send your EInvoice. You can select between one in the following list:

*SuperPDP
*EsaLink (hubtimize)
*More providers are coming (See chapter Development to know how to contibute to add your own Provider)

All access point provided by the module are official Access Points (Plateforme Agréée).

==Setup with SuperPDP Access Point==
If you choose [https://www.superpdp.tech SuperPDP] as your official Production Access Point (or as a Test Access Point), you must create an account by clicking on the link suggested by the setup page of the module (link should be https://www.superpdp.tech/app/users/create).

Note that for a production usage, you may need to provide a scan of an identity card. The process of creating an account may last few minutes.

Once your account is created, you must generate credentials to allow Dolibarr to connect to SuperPDP: For this, go into your SuperPDP dashboard, and from the left menu "'''Applications'''", click on "'''New Application'''" to create a new setup for the application Dolibarr. Choose if you want a setup for Production (Real usage) or for Test (Sandbox). Then select the company and the type of application "'''Confidential'''" and click "'''Create'''" (you can keep the field "URLs of redirection" to empty or paste the value provided by Dolibarr setup page).

''The page to get credentials for an application''

[[File:Einvoice superpdp setup.png|border]]

Your credential ('''client_id''' and '''client_secret''') are created and are shown on the next screen.

Go into Dolibarr, into the page to setup the module EInvoice and enter these 2 values, click on Save to save the data and click on "Connect" to get the security key to exchange with SuperPDP.

That's all, you are connected with SuperPDP (For Production usage or for Test depending on the choice you made). To be sure, you can try the link "Test of connection (healthcheck)" to verify the connection.

''Example of setup for sandbox use with an account of SuperPDP''

[[File:Einvoice setup example.png|border]]

[[File:Warning.png]] By default, you can enter only one set of credentials for the Production mode and one set of credentials for the Test mode, so if your Dolibarr instance is a test instance, enter test credentials and set the switch to Test, and if your Dolibarr instance is a production instance, enter credentials of production and set the switch to Production. Even if you can switch from one environment to another one, it is seriously not recommended to save and use both Test and Production credentials in the same Dolibarr instance; Only the Access Point environment is different but your Dolibarr is the same. So if you mix two Access Point environments (Test and Prod) in the same Dolibarr, you may get or send tests invoices on your production instance (and the opposite), so the best thing to avoid this is to enter credentials only for one environment and never for the other. See chapter "Usage in sandbox for test" for more information on how to use the module in a sandbox context.

==Setup VAT exemptions (VATEX), if applicable==
If your business is exempted of VAT, tell Dolibarr the default reason of exemption that will be exported in the EInvoice.

Take note of the VATEX-xxxx code that matches your business and save it into Dolibarr:

*In Dolibarr <= 23, go to "Configuration - Misc" and add a new variable '''MAIN_VAT_EXEMPTION_CODE_FOR_0''' with the VATEX-xx-xxxx matching your situation.
*In Dolibarr >24, save it to the VAT dictionary

''Example: French companies concerned with Art 293B of CGI will type <code>VATEX-FR-FRANCHISE</code>''

==Setup with Esalink/Hubtimize Access point==
L'utilisation de la Plateforme Agréée ESALINK ne se souscrit pas en direct : elle passe obligatoirement par un '''membre distributeur''' de l'association PDP Libre, référencé sur la page [https://pdplibre.org/solutions/ Solutions].

=Usage for production=
==Send a customer invoice==
Once a Dolibarr invoice is generated (and validated), you can use a new button "'''Generate the Einvoice'''".

Note: you can have this action done automatically if you enable the option from menu Home - Setup - Modules - Module Einvoice - Configuration - Tab "other options" and switch "Generate automatically Einvoice".

Once an EInvoice has been generated, you can use the button to "'''Send the invoice'''" to the access point. Wait a minute while the access point answers and observe the returned status code:

*'''Code 200''': the access point has successfully sent the invoice to the client and is waiting for an answer from the customer's approval
*'''Code 213''': rejected: the access point has detected an anomaly on the invoice. Review all invoice data and VAT fields. Download the ''FA-xxxxx_cii.xml'' file from Dolibarr and send it to [https://www.superpdp.tech/outils/validateur-facture-electronique/ a CII validator] to get more information about the anomaly. If you need help, ask [https://www.dolibarr.fr/forum/ on the forum].
*'''Code 210''': the customer explicitly refused the invoice, get it touch with the customer to know why they did not accept the invoice.

'''Note about invoices generated by the POS Module TakePOS'''

By default, any invoice generated by the POS has status "Do not manage Einvoice". For such sales, it is not expected that you send an EInvoice. Instead you will have to send a "report" for all sales done by the point of sale (this will be supported by the module, later as this requirement is expected only for the 1st of september 2027).

==Retrieve vendor invoices==
Go into menu Home - Invoice - EInvoice synchronization.

Click on the button to launch synchronization.

If you experience an error, follow the instruction. for example:

*If you try to import a vendor invoice and the vendor can not be found in your Dolibarr database of suppliers, a link will be suggested to create it.
*If you try to import a vendor invoice and a product line can not be found in your Dolibarr database of products, a link will be suggested to create the product (You may also prefer to edit the vendor card to define a default Product Ref to use when doing an import of a product that is unknown, so each time a product is unknown for this vendor, Dolibarr will use the same default product instead of creating a new one each time).

=Usage in the sandbox env for test=
Using the module in sandbox environment is the same than using it in production mode. Only the credentials to connect to your Access Point differ.

If you are a developper, you can enable the option EINVOICING_ALLOW_DEV_TOOLS to 1 into menu "Home - Setup - Other". This will add more features for developers into an additional tab "Dev tools".
You can also switch the Test / Production mode from the main tab of the setup section of the module. WARNING: Using the switch is dangerous as it allows mixing invoices from different networks in the same Dolibarr instance.

==Using the sandbox and Peppol test Network for tests using several Access Points==
If you are using credentials to use the sandbox mode of SuperPDP, you may need to modify the setup of your company (Menu Home - Setup - Company/Organization) to record the same SIREN than the one of the test company provided by SuperPDP sandbox (So "000000001" for Tricatel or "000000002" for Burger Queen).

However the '''EInvoice address''' is NOT the same than the '''SIREN''' (it is the same in production mode only), so you must also force the Einvoice address of the company into the setup of the module Einvoice: To know your EInvoice address of your test company, go into the SuperPDP dashboard, in sandbox mode, and click on the label of the test company (for example Tricatel), you should see a list of the addresses of this test company in the annuary (the address to find you on the shared test Access Point network). The invoice address to use is the value after the "225:", the one starting with 315143296_XXX with XXX that depends on your account.
Once both are saved, a warning may appear to say that SIREN and Einvoice address ID are not the same. You can ignore it in test environment.

If your SIREN (menu Home - Setup - Company/Organisation) and your EInvoice address (menu Setup - Modules - Einvoice - Configuration) are correctly filled (Example: SIREN: 00000001 and EInvoice address 315143296_XXX), then you can send and retreive invoices from or to any other Access Points working on the Peppol Test network (The SuperPDP sandbox is automatically linked to the Peppol Test network when you use the sandbox credential).

To send an invoice to a test customer available onto another Access Point, as the Peppol network are using addresses that are different from SIREN, you can force the customer EInvoice address from the thirdparty card by editing the field EInvoice address.

''Example of the thirdparty card to send an einvoice from SuperPDP to the customer Test with SIREN 145678239 available at Esalink''

[[File:Einvoice setup customer address.png|border]]

=Options for integrators (mode proxy)=
If you are an integrator or web hosting provider (called P) and you want to provide a solution to allow your customers (Called C) to register and use the einvoicing system in one click, without having to pay (all payments will be done by yourself) the module provides a solution. This is possible with the mode "Proxy" of the einvoicing module and the platform SuperPDP:

== On your own Dolibarr (the proxy) ==
*Install the module einvoicing on your own production Dolibarr of your company P.
*Go into Home - Setup - Other and add the constant EINVOICING_SUPERPDP_VIAPARTNER='proxy'. So your Dolibarr will be able to act as a proxy between your customers C and SuperPDP. Only you need to setup the client_id and client_secret of your API account of SuperPDP (Your customer will register using a simple click, see later).
*Once you have set the option EINVOICING_SUPERPDP_VIAPARTNER to 'proxy' on your own production Dolibarr, go into the setup of the module and choose "SuperPDP as proxy".
*Switch to SuperPDP dashboard and create an application on your SuperPDP account. The URL to allow for OAuth is provied on the Dolibarr setup screen. You will get the client_id and client_secret. Goback into the Dolibarr setup page of the module, and enter the keys. Remind the value of the EINVOICING_SUPERPDP_VIAPARTNER_OAUTH_URL shown, you will need it to the setup your customer instances.
*Once setup is done, you can switch back to the provider "SuperPDP direct access" for yourself (for your company P). The choice "SuperPDP Poxy" is here only to allow to enter some specific option. They are not lost if you go back to another Access Point provider and your Proxy is still active as long as its dedicated setup is ok.

== On the Dolibarr of your customers ==
Now you can deploy the module on all instances of your customers. You must also set the followign constant on the instance of your customer:
** EINVOICING_SUPERPDP_VIAPARTNER_OAUTH_URL = the value provided at previous step (so one fixed value for all your customers).
** You can also enter the constant EINVOICING_SUPERPDP_VIAPARTNER = 'YourCompanyName'.
That's all. You customer will see, in the setup of the module a choice "Register to SuperPDP via YourCompanyName". If they select this, they will see a link "Register to SuperPDP via YourCompanyName" and clicking on it will allow them to register without need to create account, no need to create an application, no need to generate and enter API key for each of your customer. The user has just to confirm the creation of its account, and a token to use its account will be recorded into its instance.
Also, you will see all your customer use of the API into the section "Sessions" of your SuperPDP dashboard.

=External Tools=
==E-Invoicing directory==

===Test directory===
To check or see companies/Einvoice ID in a directory, you can use one of these tools

*[https://test-directory.peppol.eu/public/locale-en_US/ Test Peppol directory]
*[https://www.superpdp.tech/outils/info-annuaire/?query=493861496&mode=fr&env=sandbox SuperPDP tool]

===Production directory===
You can use one of these tools to check if a company is in the production directory.

*[https://directory.peppol.eu/public/locale-en_US/ Peppol directory]
*[https://facturation.chorus-pro.gouv.fr/annuaire/#/ French governement directory]
*[https://www.superpdp.tech/outils/info-annuaire/?query=493861496&mode=fr&env=production SuperPDP directory]

==Validation of an EInvoice==
To validate an existing einvoice, you can use one of these tools:

*[https://www.superpdp.tech/outils/validateur-facture-electronique From SuperPDP (CII or Factur-X einvoices)]
*[https://services.fnfe-mpe.org/account/home From FNFE (Factur-X only, need an account)]
*[https://www.itb.ec.europa.eu/invoice/upload From Europa.eu (CII or UBL)]
*[https://ecosio.com/en/peppol-e-invoice-xml-document-validator/ From Ecosi (CII choose CrossIndustryInvoice D16B)]

=Troubleshooting=

==Life cycle and error codes for French EInvoicing==
[[File:Le cycle de vie d’une facture électronique.png|border|1200x1200px|Lifecycle of an electronic invoice]]

==Current error cases==

[[File:Warning.png]] Error "The company fr_siren:123456789 is not subject to the e-invoicing reform"

For France:

*Check that your company can be found from this annuary: https://annuaire-entreprises.data.gouv.fr/
*Then check inside this one: https://facturation.chorus-pro.gouv.fr/annuaire/#/

If you have this error, it probably means you CAN be found in the first one but NOT in the second one. This is a problem known by the DGFIP. What to do? You can't do nothing on your own. You must wait that the french governement add your SIREN record in the second annuary too. You can try to contact import.gouv.fr asking them to "appear in the second annuary to activate the einvoicing" to make things faster, but this works only in few cases only. For all others cases you must wait you appear in the second annuary before retrying to register.

[[File:Warning.png]] Error: HTTP 400 - CREATE_ERROR - pre-check: receiver address does not accept this document.

Check the SIREN and the Einvoice address of the customer. If you set only a SIREN with no specific Einvoice addess (the most common case), check that this SIREN exists that an Einvoice address in the network annuary exists with for this SIREN value. If you used a specific Einvoice address in addition to the SIREN, check that the couple SIREN/Einvoice address is a valid existing couple in the annuary.

=Development=

==Still to do==

*The E-reporting (mandatory in France the 1st september 2027), to report sales done by the Point of Sale module for example. Planned for begin of 2027.

==Sources==
{{TemplateModCommunityEn}}

==Einvoice Specifications==

Specification for France are available on https://www.boutique.afnor.org/en-gb/ and search on "XP Z12-012", "XP Z12-013", "XP Z12-014"
 
{| class="wikitable"
!Field code (Business Term)
!Desc
!Field in Dolibarr
|-
|BT-1
|Numéro de facture
|ref
|-
|BT-2
|Date de facture
|date
|-
|BT-3
|Type de document
|type (380 facture, 381 avoir, 384 rectificative, 386 acompte)
|-
|BT-8
|Exigibilité de la TVA
|TAX_MODE (5 débits / 72 encaissements)
|-
|BT-9
|Date d'échéance
|date_lim_reglement
|-
|BT-10
|Référence acheteur (code service)
|onglet Chorus Pro, sinon ref_client — Chorus Pro uniquement
|-
|BT-13
|Bon de commande du client
|ref_client de la facture, sinon ref_client de la commande liée
|-
|BT-14
|Notre numéro de commande
|ref de la commande liée
|-
|BT-23
|Cadre de facturation
|onglet Chorus Pro (facture ou fiche client)
|-
|BT-25
|Facture d'origine (avoir, acompte)
|fk_facture_source
|-
|BT-29
|SIRET vendeur / acheteur
|Id. prof. 2 (societe / tiers)
|-
|BT-30
|SIREN vendeur
|Id. prof. 1 de votre société
|-
|BT-31
|N° TVA vendeur
|TVA intracom. de votre société
|-
|BT-34
|Adresse électronique vendeur
|SIREN de votre société, schéma 0225
|-
|BT-46
|SIRET acheteur
|Id. prof. 2 du tiers
|-
|BT-47
|SIREN acheteur
|Id. prof. 1 du tiers
|-
|BT-48
|N° TVA acheteur
|TVA intracom. du tiers
|-
|BT-49
|Adresse électronique acheteur
|Id. prof. 5 du tiers, sinon son SIREN
|-
|BT-72
|Date de livraison
|delivery_date
|-
|BT-73/74
|Période de service
|dates de service des lignes
|-
|BT-89/90/91
|Prélèvement SEPA (RUM, ICS)
|RIB par défaut du tiers, PRELEVEMENT_ICS
|-
|BT-113
|Acomptes déjà réglés
|acomptes imputés sur la facture
|-
|BT-121
|Motif d'exonération de TVA
|calculé (franchise 293 B, intracom., autoliquidation, export)
|-
|BT-128
|Référence to other doc or object
|May be a reference to another invoice REF or a reference to something else (phone, ...)
|-
|BT-129
|Unité de la ligne
|unité du produit (fk_unit)
|-
|BT-146
|Prix unitaire
|total HT / quantité de la ligne
|-
|BT-151
|Catégorie de TVA
|calculée d'après le taux et le contexte
|-
|BT-84
|IBAN / BIC
|compte bancaire choisi dans la configuration 
|}

Module EInvoicing (Generic, FR, ...)

2026-10-08T10:42:10Z

Eldy: /* Options for integrators (mode proxy) */

[[Category:Complementary modules]]
{{TemplateDocDevEn}}
{{TemplateDocUser}}
=Information=
{{TemplateModuleInfo
|modulename=EInvoicing (Formerly PDPConnectFR)
|editor=Dolibarr community
|web=
|webbuy=From your Dolibarr v24+, menu Home - Setup - Modules - Find external modules, search on "einvoice"
|status=experimental
|prerequisites=
|minversion=
|maxversion=
|note=Recommended version: 24.0+
}}

=Features=
This module adds support of EInvoice in Dolibarr for some countries. Generating, Sending and Receiving EInvoice is mandatory in some countries, this module deals initialy with the case of France (even if it was designed to support other countries).

For a solution dedicated to other countries, take a look at the page [[Electronic Billing]].

The module allows your Dolibarr to generate EInvoice and to connect to some official Access Point (Plateforme Agréées) to send and retrieve your invoice documents. The supported EInvoice format are:

*CII (Dolibarr v18+, recommended Dolibarr v24+)
*Factur-X (only Dolibarr v24+)
*More format like UBL could be added by contributing (see Development chapter)

Warning: Using the Factur-X format is not recommended. It works with few Access Point only and even if accepted by your own AP, it may be refused by the AP of your customer due to hidden problems inside the format itself and library conflicts when using Dolibarr < 24.0. Also, it consumes a high amount of disk per invoice (an Einvoice may be 1 Mb if you have large images inside !) and make analysis very difficult when there is a trouble. It is highly recommended to use the CII format that is standard and supported by all Access Points, is easier to produce, analyse and process (an Einvoice is a text xml file of 10Kb only) and is not sentitive to PHP or Dolibarr versions.

=Installation=
==With Dolibarr v24+==
Go into menu Home - Setup - Search external modules
Search on einvoicing and click on Install.

The module is available. Go to configuration step.

==With any Dolibarr version==
===Install from dolistore.com===
Go and download the archive zip of the einvocing free module from dolistore.com

Go on menu Home - Setup - Install external module
Upload the zip, the module is available. Go to configuration step.

===Install using git===
In the meantime, install the module in the '''/custom''' directory of your dolibarr. For this, go into the /custom directory:
cd mydolibarrdir/htdocs/custom
Then download the module directory '''einvoicing'''
git clone https://github.com/Dolibarr/dolibarr-community-modules; mkdir einvoicing; cp -pr dolibarr-community-modules/einvoicing/* einvoicing; rm -fr dolibarr-community-modules;

=Setup=

'''Using the french guide:'''
You can have a look at the french |https://www.dolicloud.com/fr/guide-facturation-electronique-dolibarr.php Guide de la facturation électronique pour Dolibarr].

'''Using english help:'''
Go onto the setup of the modulefrom menu "Home - Setup - Modules - Module EInvoice - Wheel configuration".

The first step is to choose, from the combo list, which Access Point you want to use to send your EInvoice. You can select between one in the following list:

*SuperPDP
*EsaLink (hubtimize)
*More providers are coming (See chapter Development to know how to contibute to add your own Provider)

All access point provided by the module are official Access Points (Plateforme Agréée).

==Setup with SuperPDP Access Point==
If you choose [https://www.superpdp.tech SuperPDP] as your official Production Access Point (or as a Test Access Point), you must create an account by clicking on the link suggested by the setup page of the module (link should be https://www.superpdp.tech/app/users/create).

Note that for a production usage, you may need to provide a scan of an identity card. The process of creating an account may last few minutes.

Once your account is created, you must generate credentials to allow Dolibarr to connect to SuperPDP: For this, go into your SuperPDP dashboard, and from the left menu "'''Applications'''", click on "'''New Application'''" to create a new setup for the application Dolibarr. Choose if you want a setup for Production (Real usage) or for Test (Sandbox). Then select the company and the type of application "'''Confidential'''" and click "'''Create'''" (you can keep the field "URLs of redirection" to empty or paste the value provided by Dolibarr setup page).

''The page to get credentials for an application''

[[File:Einvoice superpdp setup.png|border]]

Your credential ('''client_id''' and '''client_secret''') are created and are shown on the next screen.

Go into Dolibarr, into the page to setup the module EInvoice and enter these 2 values, click on Save to save the data and click on "Connect" to get the security key to exchange with SuperPDP.

That's all, you are connected with SuperPDP (For Production usage or for Test depending on the choice you made). To be sure, you can try the link "Test of connection (healthcheck)" to verify the connection.

''Example of setup for sandbox use with an account of SuperPDP''

[[File:Einvoice setup example.png|border]]

[[File:Warning.png]] By default, you can enter only one set of credentials for the Production mode and one set of credentials for the Test mode, so if your Dolibarr instance is a test instance, enter test credentials and set the switch to Test, and if your Dolibarr instance is a production instance, enter credentials of production and set the switch to Production. Even if you can switch from one environment to another one, it is seriously not recommended to save and use both Test and Production credentials in the same Dolibarr instance; Only the Access Point environment is different but your Dolibarr is the same. So if you mix two Access Point environments (Test and Prod) in the same Dolibarr, you may get or send tests invoices on your production instance (and the opposite), so the best thing to avoid this is to enter credentials only for one environment and never for the other. See chapter "Usage in sandbox for test" for more information on how to use the module in a sandbox context.

==Setup VAT exemptions (VATEX), if applicable==
If your business is exempted of VAT, tell Dolibarr the default reason of exemption that will be exported in the EInvoice.

Take note of the VATEX-xxxx code that matches your business and save it into Dolibarr:

*In Dolibarr <= 23, go to "Configuration - Misc" and add a new variable '''MAIN_VAT_EXEMPTION_CODE_FOR_0''' with the VATEX-xx-xxxx matching your situation.
*In Dolibarr >24, save it to the VAT dictionary

''Example: French companies concerned with Art 293B of CGI will type <code>VATEX-FR-FRANCHISE</code>''

==Setup with Esalink/Hubtimize Access point==
L'utilisation de la Plateforme Agréée ESALINK ne se souscrit pas en direct : elle passe obligatoirement par un '''membre distributeur''' de l'association PDP Libre, référencé sur la page [https://pdplibre.org/solutions/ Solutions].

=Usage for production=
==Send a customer invoice==
Once a Dolibarr invoice is generated (and validated), you can use a new button "'''Generate the Einvoice'''".

Note: you can have this action done automatically if you enable the option from menu Home - Setup - Modules - Module Einvoice - Configuration - Tab "other options" and switch "Generate automatically Einvoice".

Once an EInvoice has been generated, you can use the button to "'''Send the invoice'''" to the access point. Wait a minute while the access point answers and observe the returned status code:

*'''Code 200''': the access point has successfully sent the invoice to the client and is waiting for an answer from the customer's approval
*'''Code 213''': rejected: the access point has detected an anomaly on the invoice. Review all invoice data and VAT fields. Download the ''FA-xxxxx_cii.xml'' file from Dolibarr and send it to [https://www.superpdp.tech/outils/validateur-facture-electronique/ a CII validator] to get more information about the anomaly. If you need help, ask [https://www.dolibarr.fr/forum/ on the forum].
*'''Code 210''': the customer explicitly refused the invoice, get it touch with the customer to know why they did not accept the invoice.

'''Note about invoices generated by the POS Module TakePOS'''

By default, any invoice generated by the POS has status "Do not manage Einvoice". For such sales, it is not expected that you send an EInvoice. Instead you will have to send a "report" for all sales done by the point of sale (this will be supported by the module, later as this requirement is expected only for the 1st of september 2027).

==Retrieve vendor invoices==
Go into menu Home - Invoice - EInvoice synchronization.

Click on the button to launch synchronization.

If you experience an error, follow the instruction. for example:

*If you try to import a vendor invoice and the vendor can not be found in your Dolibarr database of suppliers, a link will be suggested to create it.
*If you try to import a vendor invoice and a product line can not be found in your Dolibarr database of products, a link will be suggested to create the product (You may also prefer to edit the vendor card to define a default Product Ref to use when doing an import of a product that is unknown, so each time a product is unknown for this vendor, Dolibarr will use the same default product instead of creating a new one each time).

=Usage in the sandbox env for test=
Using the module in sandbox environment is the same than using it in production mode. Only the credentials to connect to your Access Point differ.

If you are a developper, you can enable the option EINVOICING_ALLOW_DEV_TOOLS to 1 into menu "Home - Setup - Other". This will add more features for developers into an additional tab "Dev tools".
You can also switch the Test / Production mode from the main tab of the setup section of the module. WARNING: Using the switch is dangerous as it allows mixing invoices from different networks in the same Dolibarr instance.

==Using the sandbox and Peppol test Network for tests using several Access Points==
If you are using credentials to use the sandbox mode of SuperPDP, you may need to modify the setup of your company (Menu Home - Setup - Company/Organization) to record the same SIREN than the one of the test company provided by SuperPDP sandbox (So "000000001" for Tricatel or "000000002" for Burger Queen).

However the '''EInvoice address''' is NOT the same than the '''SIREN''' (it is the same in production mode only), so you must also force the Einvoice address of the company into the setup of the module Einvoice: To know your EInvoice address of your test company, go into the SuperPDP dashboard, in sandbox mode, and click on the label of the test company (for example Tricatel), you should see a list of the addresses of this test company in the annuary (the address to find you on the shared test Access Point network). The invoice address to use is the value after the "225:", the one starting with 315143296_XXX with XXX that depends on your account.
Once both are saved, a warning may appear to say that SIREN and Einvoice address ID are not the same. You can ignore it in test environment.

If your SIREN (menu Home - Setup - Company/Organisation) and your EInvoice address (menu Setup - Modules - Einvoice - Configuration) are correctly filled (Example: SIREN: 00000001 and EInvoice address 315143296_XXX), then you can send and retreive invoices from or to any other Access Points working on the Peppol Test network (The SuperPDP sandbox is automatically linked to the Peppol Test network when you use the sandbox credential).

To send an invoice to a test customer available onto another Access Point, as the Peppol network are using addresses that are different from SIREN, you can force the customer EInvoice address from the thirdparty card by editing the field EInvoice address.

''Example of the thirdparty card to send an einvoice from SuperPDP to the customer Test with SIREN 145678239 available at Esalink''

[[File:Einvoice setup customer address.png|border]]

=Options for integrators (mode proxy)=
If you are an integrator or web hosting provider (called P) and you want to provide a solution to allow your customers (Called C) to register and use the einvoicing system in one click, without having to pay (all payments will be done by yourself) the module provides a solution. This is possible with the mode "Proxy" of the einvoicing module and the platform SuperPDP:

== On your own Dolibarr (the proxy) ==
*Install the module einvoicing on your own production Dolibarr of your company P.
*Go into Home - Setup - Other and add the constant EINVOICING_SUPERPDP_VIAPARTNER='proxy'. So your Dolibarr will be able to act as a proxy between your customers C and SuperPDP. Only you need to setup the client_id and client_secret of your API account of SuperPDP (Your customer will register using a simple click, see later).
*Once you have set the option EINVOICING_SUPERPDP_VIAPARTNER to 'proxy' on your own production Dolibarr, go into the setup of the module and choose "SuperPDP as proxy".
*Switch to SuperPDP dashboard and create an application on your SuperPDP account. The URL to allow for OAuth is provied on the Dolibarr setup screen. You will get the client_id and client_secret. Goback into the Dolibarr setup page of the module, and enter the keys. Remind the value of the EINVOICING_SUPERPDP_VIAPARTNER_OAUTH_URL shown, you will need it to the setup your customer instances.
*Once setup is done, you can switch back to the provider "SuperPDP direct access" for yourself (for your company P). The choice "SuperPDP Poxy" is here only to allow to enter some specific option. They are not lost if you go back to another Access Point provider and your Proxy is still active as long as its dedicated setup is ok.

== On the Dolibarr of your customers ==
*Now you can deploy the module on all instances of your customers. You must also set the followign constant on the instance of your customer:
** EINVOICING_SUPERPDP_VIAPARTNER_OAUTH_URL = the value provided at previous step (so one fixed value for all your customers).
** You can also enter the constant EINVOICING_SUPERPDP_VIAPARTNER = 'YourCompanyName'.
That's all. You customer will see, in the setup of the module a choice "Register to SuperPDP via YourCompanyName". If they select this, they will see a link "Register to SuperPDP via YourCompanyName" and clicking on it will allow them to register without need to create account, no need to create an application, no need to generate and enter API key for each of your customer. The user has just to confirm the creation of its account, and a token to use its account will be recorded into its instance.
Also, you will see all your customer use of the API into the section "Sessions" of your SuperPDP dashboard.

=External Tools=
==E-Invoicing directory==

===Test directory===
To check or see companies/Einvoice ID in a directory, you can use one of these tools

*[https://test-directory.peppol.eu/public/locale-en_US/ Test Peppol directory]
*[https://www.superpdp.tech/outils/info-annuaire/?query=493861496&mode=fr&env=sandbox SuperPDP tool]

===Production directory===
You can use one of these tools to check if a company is in the production directory.

*[https://directory.peppol.eu/public/locale-en_US/ Peppol directory]
*[https://facturation.chorus-pro.gouv.fr/annuaire/#/ French governement directory]
*[https://www.superpdp.tech/outils/info-annuaire/?query=493861496&mode=fr&env=production SuperPDP directory]

==Validation of an EInvoice==
To validate an existing einvoice, you can use one of these tools:

*[https://www.superpdp.tech/outils/validateur-facture-electronique From SuperPDP (CII or Factur-X einvoices)]
*[https://services.fnfe-mpe.org/account/home From FNFE (Factur-X only, need an account)]
*[https://www.itb.ec.europa.eu/invoice/upload From Europa.eu (CII or UBL)]
*[https://ecosio.com/en/peppol-e-invoice-xml-document-validator/ From Ecosi (CII choose CrossIndustryInvoice D16B)]

=Troubleshooting=

==Life cycle and error codes for French EInvoicing==
[[File:Le cycle de vie d’une facture électronique.png|border|1200x1200px|Lifecycle of an electronic invoice]]

==Current error cases==

[[File:Warning.png]] Error "The company fr_siren:123456789 is not subject to the e-invoicing reform"

For France:

*Check that your company can be found from this annuary: https://annuaire-entreprises.data.gouv.fr/
*Then check inside this one: https://facturation.chorus-pro.gouv.fr/annuaire/#/

If you have this error, it probably means you CAN be found in the first one but NOT in the second one. This is a problem known by the DGFIP. What to do? You can't do nothing on your own. You must wait that the french governement add your SIREN record in the second annuary too. You can try to contact import.gouv.fr asking them to "appear in the second annuary to activate the einvoicing" to make things faster, but this works only in few cases only. For all others cases you must wait you appear in the second annuary before retrying to register.

[[File:Warning.png]] Error: HTTP 400 - CREATE_ERROR - pre-check: receiver address does not accept this document.

Check the SIREN and the Einvoice address of the customer. If you set only a SIREN with no specific Einvoice addess (the most common case), check that this SIREN exists that an Einvoice address in the network annuary exists with for this SIREN value. If you used a specific Einvoice address in addition to the SIREN, check that the couple SIREN/Einvoice address is a valid existing couple in the annuary.

=Development=

==Still to do==

*The E-reporting (mandatory in France the 1st september 2027), to report sales done by the Point of Sale module for example. Planned for begin of 2027.

==Sources==
{{TemplateModCommunityEn}}

==Einvoice Specifications==

Specification for France are available on https://www.boutique.afnor.org/en-gb/ and search on "XP Z12-012", "XP Z12-013", "XP Z12-014"
 
{| class="wikitable"
!Field code (Business Term)
!Desc
!Field in Dolibarr
|-
|BT-1
|Numéro de facture
|ref
|-
|BT-2
|Date de facture
|date
|-
|BT-3
|Type de document
|type (380 facture, 381 avoir, 384 rectificative, 386 acompte)
|-
|BT-8
|Exigibilité de la TVA
|TAX_MODE (5 débits / 72 encaissements)
|-
|BT-9
|Date d'échéance
|date_lim_reglement
|-
|BT-10
|Référence acheteur (code service)
|onglet Chorus Pro, sinon ref_client — Chorus Pro uniquement
|-
|BT-13
|Bon de commande du client
|ref_client de la facture, sinon ref_client de la commande liée
|-
|BT-14
|Notre numéro de commande
|ref de la commande liée
|-
|BT-23
|Cadre de facturation
|onglet Chorus Pro (facture ou fiche client)
|-
|BT-25
|Facture d'origine (avoir, acompte)
|fk_facture_source
|-
|BT-29
|SIRET vendeur / acheteur
|Id. prof. 2 (societe / tiers)
|-
|BT-30
|SIREN vendeur
|Id. prof. 1 de votre société
|-
|BT-31
|N° TVA vendeur
|TVA intracom. de votre société
|-
|BT-34
|Adresse électronique vendeur
|SIREN de votre société, schéma 0225
|-
|BT-46
|SIRET acheteur
|Id. prof. 2 du tiers
|-
|BT-47
|SIREN acheteur
|Id. prof. 1 du tiers
|-
|BT-48
|N° TVA acheteur
|TVA intracom. du tiers
|-
|BT-49
|Adresse électronique acheteur
|Id. prof. 5 du tiers, sinon son SIREN
|-
|BT-72
|Date de livraison
|delivery_date
|-
|BT-73/74
|Période de service
|dates de service des lignes
|-
|BT-89/90/91
|Prélèvement SEPA (RUM, ICS)
|RIB par défaut du tiers, PRELEVEMENT_ICS
|-
|BT-113
|Acomptes déjà réglés
|acomptes imputés sur la facture
|-
|BT-121
|Motif d'exonération de TVA
|calculé (franchise 293 B, intracom., autoliquidation, export)
|-
|BT-128
|Référence to other doc or object
|May be a reference to another invoice REF or a reference to something else (phone, ...)
|-
|BT-129
|Unité de la ligne
|unité du produit (fk_unit)
|-
|BT-146
|Prix unitaire
|total HT / quantité de la ligne
|-
|BT-151
|Catégorie de TVA
|calculée d'après le taux et le contexte
|-
|BT-84
|IBAN / BIC
|compte bancaire choisi dans la configuration 
|}

FAQ J'ai perdu mon mot de passe

2026-09-25T13:34:13Z

Eldy: /* Si le mot de passe perdu est celui du compte admin Dolibarr */

[[en:FAQ_I_Lost_my_password]]
[[es:FAQ Tengo un problema en la contraseña]]


[[Category:FAQ FR]]
Il peut arriver que vous oubliez votre mot de passe ou que pour une raison inconnue il ne fonctionne plus, voici la solution pour reprendre la main en fonction des 3 types de mots de passes concernés.

= Reset du mot de passe root de la base de donnée MariaDB/MySQL =
Cette section traite d'un problème du mot de passe d'administration root de la base de donnée MariaDB/MySQL et non du mot de passe utilisé par Dolibarr pour accéder à la base de donnée, ni de compte utilisateur d'accès à Dolibarr (voir chapitres suivant pour cela).

== Pour Mariadb installé par DoliWamp (Microsoft Windows) ==
* Connectez vous avec un compte administrateur Windows sur votre machine, 
* Allez dans le menu Windows:
Démarrer -> paramétres -> Panneau de configuration -> Outils d'administration -> Services.
* Trouvez le service MySQL '''doliwampmysql''' dans la liste, et arrêtez le.
* Lancer une console de ligne de commande en allant dans le menu
Démarrer -> Executer CMD
* Tapez les lignes suivantes pour relancer MySQL dans un mode particulier.
CD C:\dolibarr\bin\mysql\mysql5.0.45\bin
C:\dolibarr\bin\mysql\mysql5.0.45\bin\mysqld-nt --skip-grant-tables
* Lancer à nouveau une console de ligne de commande en allant dans le menu
Menu Demarrer -> Executer CMD (une deuxieme fois)
* Tapez
CD C:\dolibarr\bin\mysql\mysql5.0.45\bin
C:\dolibarr\bin\mysql\mysql5.0.45\bin\mysql -u root
* A l'invite, tapez
<syntaxHighlight lang="sql">
mysql> UPDATE mysql.user SET Password = PASSWORD('anewpassword') WHERE User = 'root';
or on a more recent version
mysql> SET PASSWORD FOR 'root@localhost' = PASSWORD('anewpassword');
</syntaxHighlight>
Pour prendre en compte le changement
<syntaxHighlight lang="sql">
mysql> FLUSH PRIVILEGES;
mysql> QUIT;
</syntaxHighlight>
* Tapez
C:\dolibarr\bin\mysql\mysql5.0.45\bin\mysqladmin -u root -pmotdepasseroot shutdown
* Redémarrez Windows.

Vous devez pouvoir accéder à votre Base Mysql ce qui vous permet de réaliser l'étape d'après pour modifier le mot de passe utilisé par Dolibarr pour accéder à sa base de donnée.

== Pour Mysql ou Mariadb sous Linux ==
* Ouvrez une fenêtre terminal ligne de commande avec l'utilisateur système root.
* Arrêtez Mysql:
/usr/sbin/mysql stop
* Tapez la ligne suivante afin de relancer MySQL dans un mode particulier (sans utilisateurs).
/usr/sbin --skip-grant-tables
* Ouvrez une autre fenêtre terminal ligne de commande.
* Lancez le client mysql
/usr/bin/mysql -u root
* Au prompt de MySQL, tapez
<syntaxHighlight lang="sql">
mysql> UPDATE mysql.user SET Password = PASSWORD('anewpassword') WHERE User = 'root';
or on a more recent version
mysql> SET PASSWORD FOR 'root@localhost' = PASSWORD('anewpassword');
</syntaxHighlight>
Et pour prendre en compte
<syntaxHighlight lang="sql">
mysql> FLUSH PRIVILEGES;
mysql> QUIT;
</syntaxHighlight>
* Arrêtez MySql par
/usr/bin/mysqladmin -u root -panewpassword shutdown
* Relancer le serveur physique ou juste le serveur MySql.

Vous devriez être capable de vous connecter à la base de donnée MySQL avec le user root et le mot de passe défini, vous pouvez maintenant dire à Dolibarr d'utiliser le nouveau mot de passe.

= Reset du mot de passe utilisé par Dolibarr pour accéder à la base =
* Allez dans
htdocs\conf
* Editez le fichier conf.php pour changer la variable
$dolibarr_main_db_pass

et modifiez sa valeur avec un nouveau mot de passe.

Le nom de l'utilisateur pour accéder à la base de donnée est dans $dolibarr_main_db_user. Retenez le.

* Sauvez le fichier et quittez.

* Lancer le client mariadb/mysql avec l'utilisateur root
Sous Linux, depuis un terminal: /usr/bin/mysql -u root -ppassword
Sous Windows: Lancer à une console de ligne de commande en allant dans le menu Menu Demarrer -> Executer CMD et Tapez
CD C:\dolibarr\bin\mysql\mysqlx.y.z\bin
C:\dolibarr\bin\mysql\mysqlx.y.z\bin\mysql -u root
* Au prompt de MariaDB/MySQL prompt, tapez
<syntaxHighlight lang="sql">
mysql> UPDATE mysql.user SET Password = PASSWORD('anothernewpassword') WHERE User = 'userusedbydolibarr';
ou avec une version plus récente
mysql> SET PASSWORD FOR 'userusedbydolibarr@localhost' = PASSWORD('anothernewpassword');
</syntaxHighlight>
Et pour prendre en compte
<syntaxHighlight lang="sql">
mysql> FLUSH PRIVILEGES;
mysql> QUIT;
</syntaxHighlight>

= Reset du mot de passe d'un compte utilisateur de l'application Dolibarr =
== Si vous posséder un autre compte d'accès à l'application et que celui ci est admin ==
Connectez vous avec celui ci. Puis aller sur la fiche de l'utilisateur dont il faut modifier le mot de passe. Modifier la fiche pour forcer un nouveau mot de passe.

== Si le mot de passe perdu est celui du compte "admin" Dolibarr ==
Connectez-vous à la base de donnée Dolibarr mysql et modifier le champ "pass" du login avec lequel vous voulez vous connecter.
<syntaxHighlight lang="sql">
mysql> USE nomdelabasedolibarr;
mysql> UPDATE llx_user SET pass = 'atemporarypasswod' WHERE login ='loginuserbloque';
</syntaxHighlight>

Essayez de vous connecter puis modifiez votre mot de passe depuis votre fiche utilisateur. Cela effacera le mot de passe temporaire non crypté afin de stocker votre nouveau mot de passe crypté dans cette table.

FAQ J'ai perdu mon mot de passe

2026-09-25T13:33:57Z

Eldy: /* Pour mysql ou mariadb sous Linux */

[[en:FAQ_I_Lost_my_password]]
[[es:FAQ Tengo un problema en la contraseña]]


[[Category:FAQ FR]]
Il peut arriver que vous oubliez votre mot de passe ou que pour une raison inconnue il ne fonctionne plus, voici la solution pour reprendre la main en fonction des 3 types de mots de passes concernés.

= Reset du mot de passe root de la base de donnée MariaDB/MySQL =
Cette section traite d'un problème du mot de passe d'administration root de la base de donnée MariaDB/MySQL et non du mot de passe utilisé par Dolibarr pour accéder à la base de donnée, ni de compte utilisateur d'accès à Dolibarr (voir chapitres suivant pour cela).

== Pour Mariadb installé par DoliWamp (Microsoft Windows) ==
* Connectez vous avec un compte administrateur Windows sur votre machine, 
* Allez dans le menu Windows:
Démarrer -> paramétres -> Panneau de configuration -> Outils d'administration -> Services.
* Trouvez le service MySQL '''doliwampmysql''' dans la liste, et arrêtez le.
* Lancer une console de ligne de commande en allant dans le menu
Démarrer -> Executer CMD
* Tapez les lignes suivantes pour relancer MySQL dans un mode particulier.
CD C:\dolibarr\bin\mysql\mysql5.0.45\bin
C:\dolibarr\bin\mysql\mysql5.0.45\bin\mysqld-nt --skip-grant-tables
* Lancer à nouveau une console de ligne de commande en allant dans le menu
Menu Demarrer -> Executer CMD (une deuxieme fois)
* Tapez
CD C:\dolibarr\bin\mysql\mysql5.0.45\bin
C:\dolibarr\bin\mysql\mysql5.0.45\bin\mysql -u root
* A l'invite, tapez
<syntaxHighlight lang="sql">
mysql> UPDATE mysql.user SET Password = PASSWORD('anewpassword') WHERE User = 'root';
or on a more recent version
mysql> SET PASSWORD FOR 'root@localhost' = PASSWORD('anewpassword');
</syntaxHighlight>
Pour prendre en compte le changement
<syntaxHighlight lang="sql">
mysql> FLUSH PRIVILEGES;
mysql> QUIT;
</syntaxHighlight>
* Tapez
C:\dolibarr\bin\mysql\mysql5.0.45\bin\mysqladmin -u root -pmotdepasseroot shutdown
* Redémarrez Windows.

Vous devez pouvoir accéder à votre Base Mysql ce qui vous permet de réaliser l'étape d'après pour modifier le mot de passe utilisé par Dolibarr pour accéder à sa base de donnée.

== Pour Mysql ou Mariadb sous Linux ==
* Ouvrez une fenêtre terminal ligne de commande avec l'utilisateur système root.
* Arrêtez Mysql:
/usr/sbin/mysql stop
* Tapez la ligne suivante afin de relancer MySQL dans un mode particulier (sans utilisateurs).
/usr/sbin --skip-grant-tables
* Ouvrez une autre fenêtre terminal ligne de commande.
* Lancez le client mysql
/usr/bin/mysql -u root
* Au prompt de MySQL, tapez
<syntaxHighlight lang="sql">
mysql> UPDATE mysql.user SET Password = PASSWORD('anewpassword') WHERE User = 'root';
or on a more recent version
mysql> SET PASSWORD FOR 'root@localhost' = PASSWORD('anewpassword');
</syntaxHighlight>
Et pour prendre en compte
<syntaxHighlight lang="sql">
mysql> FLUSH PRIVILEGES;
mysql> QUIT;
</syntaxHighlight>
* Arrêtez MySql par
/usr/bin/mysqladmin -u root -panewpassword shutdown
* Relancer le serveur physique ou juste le serveur MySql.

Vous devriez être capable de vous connecter à la base de donnée MySQL avec le user root et le mot de passe défini, vous pouvez maintenant dire à Dolibarr d'utiliser le nouveau mot de passe.

= Reset du mot de passe utilisé par Dolibarr pour accéder à la base =
* Allez dans
htdocs\conf
* Editez le fichier conf.php pour changer la variable
$dolibarr_main_db_pass

et modifiez sa valeur avec un nouveau mot de passe.

Le nom de l'utilisateur pour accéder à la base de donnée est dans $dolibarr_main_db_user. Retenez le.

* Sauvez le fichier et quittez.

* Lancer le client mariadb/mysql avec l'utilisateur root
Sous Linux, depuis un terminal: /usr/bin/mysql -u root -ppassword
Sous Windows: Lancer à une console de ligne de commande en allant dans le menu Menu Demarrer -> Executer CMD et Tapez
CD C:\dolibarr\bin\mysql\mysqlx.y.z\bin
C:\dolibarr\bin\mysql\mysqlx.y.z\bin\mysql -u root
* Au prompt de MariaDB/MySQL prompt, tapez
<syntaxHighlight lang="sql">
mysql> UPDATE mysql.user SET Password = PASSWORD('anothernewpassword') WHERE User = 'userusedbydolibarr';
ou avec une version plus récente
mysql> SET PASSWORD FOR 'userusedbydolibarr@localhost' = PASSWORD('anothernewpassword');
</syntaxHighlight>
Et pour prendre en compte
<syntaxHighlight lang="sql">
mysql> FLUSH PRIVILEGES;
mysql> QUIT;
</syntaxHighlight>

= Reset du mot de passe d'un compte utilisateur de l'application Dolibarr =
== Si vous posséder un autre compte d'accès à l'application et que celui ci est admin ==
Connectez vous avec celui ci. Puis aller sur la fiche de l'utilisateur dont il faut modifier le mot de passe. Modifier la fiche pour forcer un nouveau mot de passe.

== Si le mot de passe perdu est celui du compte admin Dolibarr ==
Connectez-vous à la base de donnée Dolibarr mysql et modifier le champ "pass" du login avec lequel vous voulez vous connecter.
<syntaxHighlight lang="sql">
mysql> USE nomdelabasedolibarr;
mysql> UPDATE llx_user SET pass = 'atemporarypasswod' WHERE login ='loginuserbloque';
</syntaxHighlight>

Essayez de vous connecter puis modifiez votre mot de passe depuis votre fiche utilisateur. Cela effacera le mot de passe temporaire non crypté afin de stocker votre nouveau mot de passe crypté dans cette table.

FAQ J'ai perdu mon mot de passe

2026-09-25T13:33:46Z

Eldy: /* Sous Linux */

[[en:FAQ_I_Lost_my_password]]
[[es:FAQ Tengo un problema en la contraseña]]


[[Category:FAQ FR]]
Il peut arriver que vous oubliez votre mot de passe ou que pour une raison inconnue il ne fonctionne plus, voici la solution pour reprendre la main en fonction des 3 types de mots de passes concernés.

= Reset du mot de passe root de la base de donnée MariaDB/MySQL =
Cette section traite d'un problème du mot de passe d'administration root de la base de donnée MariaDB/MySQL et non du mot de passe utilisé par Dolibarr pour accéder à la base de donnée, ni de compte utilisateur d'accès à Dolibarr (voir chapitres suivant pour cela).

== Pour Mariadb installé par DoliWamp (Microsoft Windows) ==
* Connectez vous avec un compte administrateur Windows sur votre machine, 
* Allez dans le menu Windows:
Démarrer -> paramétres -> Panneau de configuration -> Outils d'administration -> Services.
* Trouvez le service MySQL '''doliwampmysql''' dans la liste, et arrêtez le.
* Lancer une console de ligne de commande en allant dans le menu
Démarrer -> Executer CMD
* Tapez les lignes suivantes pour relancer MySQL dans un mode particulier.
CD C:\dolibarr\bin\mysql\mysql5.0.45\bin
C:\dolibarr\bin\mysql\mysql5.0.45\bin\mysqld-nt --skip-grant-tables
* Lancer à nouveau une console de ligne de commande en allant dans le menu
Menu Demarrer -> Executer CMD (une deuxieme fois)
* Tapez
CD C:\dolibarr\bin\mysql\mysql5.0.45\bin
C:\dolibarr\bin\mysql\mysql5.0.45\bin\mysql -u root
* A l'invite, tapez
<syntaxHighlight lang="sql">
mysql> UPDATE mysql.user SET Password = PASSWORD('anewpassword') WHERE User = 'root';
or on a more recent version
mysql> SET PASSWORD FOR 'root@localhost' = PASSWORD('anewpassword');
</syntaxHighlight>
Pour prendre en compte le changement
<syntaxHighlight lang="sql">
mysql> FLUSH PRIVILEGES;
mysql> QUIT;
</syntaxHighlight>
* Tapez
C:\dolibarr\bin\mysql\mysql5.0.45\bin\mysqladmin -u root -pmotdepasseroot shutdown
* Redémarrez Windows.

Vous devez pouvoir accéder à votre Base Mysql ce qui vous permet de réaliser l'étape d'après pour modifier le mot de passe utilisé par Dolibarr pour accéder à sa base de donnée.

== Pour mysql ou mariadb sous Linux ==
* Ouvrez une fenêtre terminal ligne de commande avec l'utilisateur système root.
* Arrêtez Mysql:
/usr/sbin/mysql stop
* Tapez la ligne suivante afin de relancer MySQL dans un mode particulier (sans utilisateurs).
/usr/sbin --skip-grant-tables
* Ouvrez une autre fenêtre terminal ligne de commande.
* Lancez le client mysql
/usr/bin/mysql -u root
* Au prompt de MySQL, tapez
<syntaxHighlight lang="sql">
mysql> UPDATE mysql.user SET Password = PASSWORD('anewpassword') WHERE User = 'root';
or on a more recent version
mysql> SET PASSWORD FOR 'root@localhost' = PASSWORD('anewpassword');
</syntaxHighlight>
Et pour prendre en compte
<syntaxHighlight lang="sql">
mysql> FLUSH PRIVILEGES;
mysql> QUIT;
</syntaxHighlight>
* Arrêtez MySql par
/usr/bin/mysqladmin -u root -panewpassword shutdown
* Relancer le serveur physique ou juste le serveur MySql.

Vous devriez être capable de vous connecter à la base de donnée MySQL avec le user root et le mot de passe défini, vous pouvez maintenant dire à Dolibarr d'utiliser le nouveau mot de passe.

= Reset du mot de passe utilisé par Dolibarr pour accéder à la base =
* Allez dans
htdocs\conf
* Editez le fichier conf.php pour changer la variable
$dolibarr_main_db_pass

et modifiez sa valeur avec un nouveau mot de passe.

Le nom de l'utilisateur pour accéder à la base de donnée est dans $dolibarr_main_db_user. Retenez le.

* Sauvez le fichier et quittez.

* Lancer le client mariadb/mysql avec l'utilisateur root
Sous Linux, depuis un terminal: /usr/bin/mysql -u root -ppassword
Sous Windows: Lancer à une console de ligne de commande en allant dans le menu Menu Demarrer -> Executer CMD et Tapez
CD C:\dolibarr\bin\mysql\mysqlx.y.z\bin
C:\dolibarr\bin\mysql\mysqlx.y.z\bin\mysql -u root
* Au prompt de MariaDB/MySQL prompt, tapez
<syntaxHighlight lang="sql">
mysql> UPDATE mysql.user SET Password = PASSWORD('anothernewpassword') WHERE User = 'userusedbydolibarr';
ou avec une version plus récente
mysql> SET PASSWORD FOR 'userusedbydolibarr@localhost' = PASSWORD('anothernewpassword');
</syntaxHighlight>
Et pour prendre en compte
<syntaxHighlight lang="sql">
mysql> FLUSH PRIVILEGES;
mysql> QUIT;
</syntaxHighlight>

= Reset du mot de passe d'un compte utilisateur de l'application Dolibarr =
== Si vous posséder un autre compte d'accès à l'application et que celui ci est admin ==
Connectez vous avec celui ci. Puis aller sur la fiche de l'utilisateur dont il faut modifier le mot de passe. Modifier la fiche pour forcer un nouveau mot de passe.

== Si le mot de passe perdu est celui du compte admin Dolibarr ==
Connectez-vous à la base de donnée Dolibarr mysql et modifier le champ "pass" du login avec lequel vous voulez vous connecter.
<syntaxHighlight lang="sql">
mysql> USE nomdelabasedolibarr;
mysql> UPDATE llx_user SET pass = 'atemporarypasswod' WHERE login ='loginuserbloque';
</syntaxHighlight>

Essayez de vous connecter puis modifiez votre mot de passe depuis votre fiche utilisateur. Cela effacera le mot de passe temporaire non crypté afin de stocker votre nouveau mot de passe crypté dans cette table.

FAQ J'ai perdu mon mot de passe

2026-09-25T13:33:22Z

Eldy: /* Sous Microsoft Windows installé par DoliWamp */

[[en:FAQ_I_Lost_my_password]]
[[es:FAQ Tengo un problema en la contraseña]]


[[Category:FAQ FR]]
Il peut arriver que vous oubliez votre mot de passe ou que pour une raison inconnue il ne fonctionne plus, voici la solution pour reprendre la main en fonction des 3 types de mots de passes concernés.

= Reset du mot de passe root de la base de donnée MariaDB/MySQL =
Cette section traite d'un problème du mot de passe d'administration root de la base de donnée MariaDB/MySQL et non du mot de passe utilisé par Dolibarr pour accéder à la base de donnée, ni de compte utilisateur d'accès à Dolibarr (voir chapitres suivant pour cela).

== Pour Mariadb installé par DoliWamp (Microsoft Windows) ==
* Connectez vous avec un compte administrateur Windows sur votre machine, 
* Allez dans le menu Windows:
Démarrer -> paramétres -> Panneau de configuration -> Outils d'administration -> Services.
* Trouvez le service MySQL '''doliwampmysql''' dans la liste, et arrêtez le.
* Lancer une console de ligne de commande en allant dans le menu
Démarrer -> Executer CMD
* Tapez les lignes suivantes pour relancer MySQL dans un mode particulier.
CD C:\dolibarr\bin\mysql\mysql5.0.45\bin
C:\dolibarr\bin\mysql\mysql5.0.45\bin\mysqld-nt --skip-grant-tables
* Lancer à nouveau une console de ligne de commande en allant dans le menu
Menu Demarrer -> Executer CMD (une deuxieme fois)
* Tapez
CD C:\dolibarr\bin\mysql\mysql5.0.45\bin
C:\dolibarr\bin\mysql\mysql5.0.45\bin\mysql -u root
* A l'invite, tapez
<syntaxHighlight lang="sql">
mysql> UPDATE mysql.user SET Password = PASSWORD('anewpassword') WHERE User = 'root';
or on a more recent version
mysql> SET PASSWORD FOR 'root@localhost' = PASSWORD('anewpassword');
</syntaxHighlight>
Pour prendre en compte le changement
<syntaxHighlight lang="sql">
mysql> FLUSH PRIVILEGES;
mysql> QUIT;
</syntaxHighlight>
* Tapez
C:\dolibarr\bin\mysql\mysql5.0.45\bin\mysqladmin -u root -pmotdepasseroot shutdown
* Redémarrez Windows.

Vous devez pouvoir accéder à votre Base Mysql ce qui vous permet de réaliser l'étape d'après pour modifier le mot de passe utilisé par Dolibarr pour accéder à sa base de donnée.

== Sous Linux ==
* Ouvrez une fenêtre terminal ligne de commande avec l'utilisateur système root.
* Arrêtez Mysql:
/usr/sbin/mysql stop
* Tapez la ligne suivante afin de relancer MySQL dans un mode particulier (sans utilisateurs).
/usr/sbin --skip-grant-tables
* Ouvrez une autre fenêtre terminal ligne de commande.
* Lancez le client mysql
/usr/bin/mysql -u root
* Au prompt de MySQL, tapez
<syntaxHighlight lang="sql">
mysql> UPDATE mysql.user SET Password = PASSWORD('anewpassword') WHERE User = 'root';
or on a more recent version
mysql> SET PASSWORD FOR 'root@localhost' = PASSWORD('anewpassword');
</syntaxHighlight>
Et pour prendre en compte
<syntaxHighlight lang="sql">
mysql> FLUSH PRIVILEGES;
mysql> QUIT;
</syntaxHighlight>
* Arrêtez MySql par
/usr/bin/mysqladmin -u root -panewpassword shutdown
* Relancer le serveur physique ou juste le serveur MySql.

Vous devriez être capable de vous connecter à la base de donnée MySQL avec le user root et le mot de passe défini, vous pouvez maintenant dire à Dolibarr d'utiliser le nouveau mot de passe.

= Reset du mot de passe utilisé par Dolibarr pour accéder à la base =
* Allez dans
htdocs\conf
* Editez le fichier conf.php pour changer la variable
$dolibarr_main_db_pass

et modifiez sa valeur avec un nouveau mot de passe.

Le nom de l'utilisateur pour accéder à la base de donnée est dans $dolibarr_main_db_user. Retenez le.

* Sauvez le fichier et quittez.

* Lancer le client mariadb/mysql avec l'utilisateur root
Sous Linux, depuis un terminal: /usr/bin/mysql -u root -ppassword
Sous Windows: Lancer à une console de ligne de commande en allant dans le menu Menu Demarrer -> Executer CMD et Tapez
CD C:\dolibarr\bin\mysql\mysqlx.y.z\bin
C:\dolibarr\bin\mysql\mysqlx.y.z\bin\mysql -u root
* Au prompt de MariaDB/MySQL prompt, tapez
<syntaxHighlight lang="sql">
mysql> UPDATE mysql.user SET Password = PASSWORD('anothernewpassword') WHERE User = 'userusedbydolibarr';
ou avec une version plus récente
mysql> SET PASSWORD FOR 'userusedbydolibarr@localhost' = PASSWORD('anothernewpassword');
</syntaxHighlight>
Et pour prendre en compte
<syntaxHighlight lang="sql">
mysql> FLUSH PRIVILEGES;
mysql> QUIT;
</syntaxHighlight>

= Reset du mot de passe d'un compte utilisateur de l'application Dolibarr =
== Si vous posséder un autre compte d'accès à l'application et que celui ci est admin ==
Connectez vous avec celui ci. Puis aller sur la fiche de l'utilisateur dont il faut modifier le mot de passe. Modifier la fiche pour forcer un nouveau mot de passe.

== Si le mot de passe perdu est celui du compte admin Dolibarr ==
Connectez-vous à la base de donnée Dolibarr mysql et modifier le champ "pass" du login avec lequel vous voulez vous connecter.
<syntaxHighlight lang="sql">
mysql> USE nomdelabasedolibarr;
mysql> UPDATE llx_user SET pass = 'atemporarypasswod' WHERE login ='loginuserbloque';
</syntaxHighlight>

Essayez de vous connecter puis modifiez votre mot de passe depuis votre fiche utilisateur. Cela effacera le mot de passe temporaire non crypté afin de stocker votre nouveau mot de passe crypté dans cette table.

FAQ J'ai perdu mon mot de passe

2026-09-25T13:30:32Z

Eldy: /* Linux */

[[en:FAQ_I_Lost_my_password]]
[[es:FAQ Tengo un problema en la contraseña]]


[[Category:FAQ FR]]
Il peut arriver que vous oubliez votre mot de passe ou que pour une raison inconnue il ne fonctionne plus, voici la solution pour reprendre la main en fonction des 3 types de mots de passes concernés.

= Reset du mot de passe root de la base de donnée MariaDB/MySQL =
Cette section traite d'un problème du mot de passe d'administration root de la base de donnée MariaDB/MySQL et non du mot de passe utilisé par Dolibarr pour accéder à la base de donnée, ni de compte utilisateur d'accès à Dolibarr (voir chapitres suivant pour cela).

== Sous Microsoft Windows installé par DoliWamp ==
* Connectez vous avec un compte administrateur Windows sur votre machine, 
* Allez dans le menu Windows:
Démarrer -> paramétres -> Panneau de configuration -> Outils d'administration -> Services.
* Trouvez le service MySQL '''doliwampmysql''' dans la liste, et arrêtez le.
* Lancer une console de ligne de commande en allant dans le menu
Démarrer -> Executer CMD
* Tapez les lignes suivantes pour relancer MySQL dans un mode particulier.
CD C:\dolibarr\bin\mysql\mysql5.0.45\bin
C:\dolibarr\bin\mysql\mysql5.0.45\bin\mysqld-nt --skip-grant-tables
* Lancer à nouveau une console de ligne de commande en allant dans le menu
Menu Demarrer -> Executer CMD (une deuxieme fois)
* Tapez
CD C:\dolibarr\bin\mysql\mysql5.0.45\bin
C:\dolibarr\bin\mysql\mysql5.0.45\bin\mysql -u root
* A l'invite, tapez
<syntaxHighlight lang="sql">
mysql> UPDATE mysql.user SET Password = PASSWORD('anewpassword') WHERE User = 'root';
or on a more recent version
mysql> SET PASSWORD FOR 'root@localhost' = PASSWORD('anewpassword');
</syntaxHighlight>
Pour prendre en compte le changement
<syntaxHighlight lang="sql">
mysql> FLUSH PRIVILEGES;
mysql> QUIT;
</syntaxHighlight>
* Tapez
C:\dolibarr\bin\mysql\mysql5.0.45\bin\mysqladmin -u root -pmotdepasseroot shutdown
* Redémarrez Windows.

Vous devez pouvoir accéder à votre Base Mysql ce qui vous permet de réaliser l'étape d'après pour modifier le mot de passe utilisé par Dolibarr pour accéder à sa base de donnée.

== Sous Linux ==
* Ouvrez une fenêtre terminal ligne de commande avec l'utilisateur système root.
* Arrêtez Mysql:
/usr/sbin/mysql stop
* Tapez la ligne suivante afin de relancer MySQL dans un mode particulier (sans utilisateurs).
/usr/sbin --skip-grant-tables
* Ouvrez une autre fenêtre terminal ligne de commande.
* Lancez le client mysql
/usr/bin/mysql -u root
* Au prompt de MySQL, tapez
<syntaxHighlight lang="sql">
mysql> UPDATE mysql.user SET Password = PASSWORD('anewpassword') WHERE User = 'root';
or on a more recent version
mysql> SET PASSWORD FOR 'root@localhost' = PASSWORD('anewpassword');
</syntaxHighlight>
Et pour prendre en compte
<syntaxHighlight lang="sql">
mysql> FLUSH PRIVILEGES;
mysql> QUIT;
</syntaxHighlight>
* Arrêtez MySql par
/usr/bin/mysqladmin -u root -panewpassword shutdown
* Relancer le serveur physique ou juste le serveur MySql.

Vous devriez être capable de vous connecter à la base de donnée MySQL avec le user root et le mot de passe défini, vous pouvez maintenant dire à Dolibarr d'utiliser le nouveau mot de passe.

= Reset du mot de passe utilisé par Dolibarr pour accéder à la base =
* Allez dans
htdocs\conf
* Editez le fichier conf.php pour changer la variable
$dolibarr_main_db_pass

et modifiez sa valeur avec un nouveau mot de passe.

Le nom de l'utilisateur pour accéder à la base de donnée est dans $dolibarr_main_db_user. Retenez le.

* Sauvez le fichier et quittez.

* Lancer le client mariadb/mysql avec l'utilisateur root
Sous Linux, depuis un terminal: /usr/bin/mysql -u root -ppassword
Sous Windows: Lancer à une console de ligne de commande en allant dans le menu Menu Demarrer -> Executer CMD et Tapez
CD C:\dolibarr\bin\mysql\mysqlx.y.z\bin
C:\dolibarr\bin\mysql\mysqlx.y.z\bin\mysql -u root
* Au prompt de MariaDB/MySQL prompt, tapez
<syntaxHighlight lang="sql">
mysql> UPDATE mysql.user SET Password = PASSWORD('anothernewpassword') WHERE User = 'userusedbydolibarr';
ou avec une version plus récente
mysql> SET PASSWORD FOR 'userusedbydolibarr@localhost' = PASSWORD('anothernewpassword');
</syntaxHighlight>
Et pour prendre en compte
<syntaxHighlight lang="sql">
mysql> FLUSH PRIVILEGES;
mysql> QUIT;
</syntaxHighlight>

= Reset du mot de passe d'un compte utilisateur de l'application Dolibarr =
== Si vous posséder un autre compte d'accès à l'application et que celui ci est admin ==
Connectez vous avec celui ci. Puis aller sur la fiche de l'utilisateur dont il faut modifier le mot de passe. Modifier la fiche pour forcer un nouveau mot de passe.

== Si le mot de passe perdu est celui du compte admin Dolibarr ==
Connectez-vous à la base de donnée Dolibarr mysql et modifier le champ "pass" du login avec lequel vous voulez vous connecter.
<syntaxHighlight lang="sql">
mysql> USE nomdelabasedolibarr;
mysql> UPDATE llx_user SET pass = 'atemporarypasswod' WHERE login ='loginuserbloque';
</syntaxHighlight>

Essayez de vous connecter puis modifiez votre mot de passe depuis votre fiche utilisateur. Cela effacera le mot de passe temporaire non crypté afin de stocker votre nouveau mot de passe crypté dans cette table.

FAQ J'ai perdu mon mot de passe

2026-09-25T13:30:13Z

Eldy: /* Sous Microsoft Windows */

[[en:FAQ_I_Lost_my_password]]
[[es:FAQ Tengo un problema en la contraseña]]


[[Category:FAQ FR]]
Il peut arriver que vous oubliez votre mot de passe ou que pour une raison inconnue il ne fonctionne plus, voici la solution pour reprendre la main en fonction des 3 types de mots de passes concernés.

= Reset du mot de passe root de la base de donnée MariaDB/MySQL =
Cette section traite d'un problème du mot de passe d'administration root de la base de donnée MariaDB/MySQL et non du mot de passe utilisé par Dolibarr pour accéder à la base de donnée, ni de compte utilisateur d'accès à Dolibarr (voir chapitres suivant pour cela).

== Sous Microsoft Windows installé par DoliWamp ==
* Connectez vous avec un compte administrateur Windows sur votre machine, 
* Allez dans le menu Windows:
Démarrer -> paramétres -> Panneau de configuration -> Outils d'administration -> Services.
* Trouvez le service MySQL '''doliwampmysql''' dans la liste, et arrêtez le.
* Lancer une console de ligne de commande en allant dans le menu
Démarrer -> Executer CMD
* Tapez les lignes suivantes pour relancer MySQL dans un mode particulier.
CD C:\dolibarr\bin\mysql\mysql5.0.45\bin
C:\dolibarr\bin\mysql\mysql5.0.45\bin\mysqld-nt --skip-grant-tables
* Lancer à nouveau une console de ligne de commande en allant dans le menu
Menu Demarrer -> Executer CMD (une deuxieme fois)
* Tapez
CD C:\dolibarr\bin\mysql\mysql5.0.45\bin
C:\dolibarr\bin\mysql\mysql5.0.45\bin\mysql -u root
* A l'invite, tapez
<syntaxHighlight lang="sql">
mysql> UPDATE mysql.user SET Password = PASSWORD('anewpassword') WHERE User = 'root';
or on a more recent version
mysql> SET PASSWORD FOR 'root@localhost' = PASSWORD('anewpassword');
</syntaxHighlight>
Pour prendre en compte le changement
<syntaxHighlight lang="sql">
mysql> FLUSH PRIVILEGES;
mysql> QUIT;
</syntaxHighlight>
* Tapez
C:\dolibarr\bin\mysql\mysql5.0.45\bin\mysqladmin -u root -pmotdepasseroot shutdown
* Redémarrez Windows.

Vous devez pouvoir accéder à votre Base Mysql ce qui vous permet de réaliser l'étape d'après pour modifier le mot de passe utilisé par Dolibarr pour accéder à sa base de donnée.

== Linux ==
* Ouvrez une fenêtre terminal ligne de commande avec l'utilisateur système root.
* Arrêtez Mysql:
/usr/sbin/mysql stop
* Tapez la ligne suivante afin de relancer MySQL dans un mode particulier (sans utilisateurs).
/usr/sbin --skip-grant-tables
* Ouvrez une autre fenêtre terminal ligne de commande.
* Lancez le client mysql
/usr/bin/mysql -u root
* Au prompt de MySQL, tapez
<syntaxHighlight lang="sql">
mysql> UPDATE mysql.user SET Password = PASSWORD('anewpassword') WHERE User = 'root';
or on a more recent version
mysql> SET PASSWORD FOR 'root@localhost' = PASSWORD('anewpassword');
</syntaxHighlight>
Et pour prendre en compte
<syntaxHighlight lang="sql">
mysql> FLUSH PRIVILEGES;
mysql> QUIT;
</syntaxHighlight>
* Arrêtez MySql par
/usr/bin/mysqladmin -u root -panewpassword shutdown
* Relancer le serveur physique ou juste le serveur MySql.

Vous devriez être capable de vous connecter à la base de donnée MySQL avec le user root et le mot de passe défini, vous pouvez maintenant dire à Dolibarr d'utiliser le nouveau mot de passe.

= Reset du mot de passe utilisé par Dolibarr pour accéder à la base =
* Allez dans
htdocs\conf
* Editez le fichier conf.php pour changer la variable
$dolibarr_main_db_pass

et modifiez sa valeur avec un nouveau mot de passe.

Le nom de l'utilisateur pour accéder à la base de donnée est dans $dolibarr_main_db_user. Retenez le.

* Sauvez le fichier et quittez.

* Lancer le client mariadb/mysql avec l'utilisateur root
Sous Linux, depuis un terminal: /usr/bin/mysql -u root -ppassword
Sous Windows: Lancer à une console de ligne de commande en allant dans le menu Menu Demarrer -> Executer CMD et Tapez
CD C:\dolibarr\bin\mysql\mysqlx.y.z\bin
C:\dolibarr\bin\mysql\mysqlx.y.z\bin\mysql -u root
* Au prompt de MariaDB/MySQL prompt, tapez
<syntaxHighlight lang="sql">
mysql> UPDATE mysql.user SET Password = PASSWORD('anothernewpassword') WHERE User = 'userusedbydolibarr';
ou avec une version plus récente
mysql> SET PASSWORD FOR 'userusedbydolibarr@localhost' = PASSWORD('anothernewpassword');
</syntaxHighlight>
Et pour prendre en compte
<syntaxHighlight lang="sql">
mysql> FLUSH PRIVILEGES;
mysql> QUIT;
</syntaxHighlight>

= Reset du mot de passe d'un compte utilisateur de l'application Dolibarr =
== Si vous posséder un autre compte d'accès à l'application et que celui ci est admin ==
Connectez vous avec celui ci. Puis aller sur la fiche de l'utilisateur dont il faut modifier le mot de passe. Modifier la fiche pour forcer un nouveau mot de passe.

== Si le mot de passe perdu est celui du compte admin Dolibarr ==
Connectez-vous à la base de donnée Dolibarr mysql et modifier le champ "pass" du login avec lequel vous voulez vous connecter.
<syntaxHighlight lang="sql">
mysql> USE nomdelabasedolibarr;
mysql> UPDATE llx_user SET pass = 'atemporarypasswod' WHERE login ='loginuserbloque';
</syntaxHighlight>

Essayez de vous connecter puis modifiez votre mot de passe depuis votre fiche utilisateur. Cela effacera le mot de passe temporaire non crypté afin de stocker votre nouveau mot de passe crypté dans cette table.

Report board meeting 20260922 teleconf

2026-09-22T11:09:57Z

Eldy: /* Attorney question */

{{TemplateAssoEn}} {{TemplateAssoFr}}

=Title/Date/Location=

*Title: Foundation board meeting
*Date: 2026-09-22
*Location: Online with NextCloud

=Presents=
Members of the board (subscription up to date) that are present (Name of organization and name of contact):

*ATM (Maxime Kohlhaas)
*DoliCloud (Laurent DESTAILLEUR)
*Inovea Conseil (Alexandre SPANGARO + Nicolas Zabouri)
*SCOPEN (Florian HENRY)
*ATOO NEt

=Topics=

==French Certification of Dolibarr system for France by LNE==

Control was done in july. Around 140 points are ok but there is still 1 non-conformity point reported (only for certification, software is ok for attestation).
Still waiting feedback of LNE about our answer done in end of june on this point.

Note: Problem will not be solved quickly, so users are invited to obtain a "Conformity statement" that can be provided by their integrator or reseller instead of waiting for the public "Certification".

=> Remind sent the 25th of august.
=> The LNE has contacted us the 11th of september to say they will provide us an answer about our solution.

==Action done by Laurent Destailleur (Dolibarr foundation requests)==

*A tool to build a zip, tag the version, update the changelog and publish on dolistore as been developped.

==New preferred partner==
No new preferred partner requested in July.
Remind: Prestalidaire was added in June.
Prestalidaire Switzerland has been accepted as a new Partner (2 entities with 2 different memberships done)

==Foundation tools==

*Quotation validation to upgrade our Nextcloud and split server that host the forum

*A new metabase report has been created to better follow Preferred Partner program = > Need to migrate it on a server of the foundation.

==Replacement of Stripe with Stancer on Dolistore==
Development and test are finished and OK.

Planned for december 2026.

==Donation system==
Go to test and fix the donation module to accept donation (with vat 0%) and a receipt that must be send automatically by email.

==Help to find founding==

*Dolibarr foundation continue to describe all the tasks of Einvoicing module to obtain the fund of the NLNET organization (NLNET - European NGI organization)

==Dolibarr forum==
Move of forum on another server.
Maxime has sent the quote signed to Jean Traullé.
Laurent has sent the credential of the new server.

TODO: Jean: Intervention is planned.

==Attorney question==
* Question on refunding or not sells for module with a very high amount need a lawyer advice (rules for Dolibarr).
** Our attorney has returned a quote to analyze solutions according to french law (around 3 000 euros).
** A meeting was done with the laywer the 7th of september. A document (answer by the lawyer) is expected between end of september and mi october.
** Waiting report for mid-october.

* Some repetitive abuse has been detected by seller that does not respect the rules.

==DevCamps organization==
===Winter DevCamp 2026===

*Date is defined: 26-November-2026 14:00 to 29-November-2026 12:00
*Location: Hôtel Des Congrès, Place du Commandant Rivière, 69100 Villeurbanne
*Organized by: OpenDSI
*Quotation under review by Dolibarr board => Budget validated without the line for coffe the sunday (the breakfast is enough).
*First Deposit was already payed
*Open subscription to all is launched on Forum and Dolibarr News

===Summer DevCamp 2027===

*Date: TBD
*Lille - Nord ERP CRM is confirmed too.

Date planned are 17th june to 19th of june 2027.

TODO Maxime must sign the proposal. Due to higher prices of hostel, price could be rised to 220 euro HT per person.

===Winter DevCamp 2027===

*Date: TBD
*Nancy: Inovea wish to be organizer

===Summer DevCamp 2028===

*Date: TBD
*Nancy: SOLAUV wish to be organizer

===Summer DevCamp 2028===

*Date: TBD
*BRIOUDE(43100): SOLAUV wish to be organizer

===Winter DevCamp 2028===

*Date: TBD
*TBD

===Summer DevCamp 2028===

*Date: TBD
*LACHAPELLE SOUS ROUGEMONT (90360): NSINFO SARL wish to organize

==Community modules==
The foundation confirm that any modules flagged as "Community module" (so with the guarantee of the foundation on CI rules, management of mainteners, management of common transifex translation account, management of github mainteners), must not be stored any more on external repository.

Rules for management of the community repository has been initiated:

https://wiki.dolibarr.org/index.php/Modules_-_Rules_for_community_modules

===DoliSecu et Stancer===
The 2 new modules DoliSecu and Stancer validated during previous meeting have been included.

===E-invoicing===

*Actual repository: https://github.com/Dolibarr/dolibarr-community-modules/tree/main/einvoicing
*Work with Dolibarr Integrator/PDPLibre/Esalink
*Work with SuperPDP

The release 1.2.0 is available.

For the module einvoicing, the minimal version is confirmed to be v18.0

==Next congress / meeting==

===Salon Paris Open Source Experience 2026===

*Location: Paris, Porte de Versailles
*Date: 9 & 10 December 2026

Laurent has made a request to register the 14th of august. Request was confirmed as received. Waiting answer of the organization.

===Salon Solution===

*Location: Paris, Porte de Versailles
*Date: 14 & 15 Octobre 2026
**The foundation will participate for 5K€ + 1K€ remain from last year (gold sponsor) - Budget is around 30 000 € (only 6 k€ si provided by the foundation).
**10 companies will be present (silver sponsor) + 6 other sponsoring companies

===FOSDEM===

* 30 & 31 January 2027 - Brussels, Belgium
* Open for application.
* Laurent must apply for the foundation.

===Salon Swiss IT Forum===

*https://www.swiss-it-forums.tech/fr/
*Date: 30 September 2026 : 11h - 21h to 1er October 2026 : 9h - 17h
*Location: Palexpo Genève
**Discuss between partners about this opportunities

Report board meeting 20260922 teleconf

2026-09-22T11:09:12Z

Eldy: /* Attorney question */

{{TemplateAssoEn}} {{TemplateAssoFr}}

=Title/Date/Location=

*Title: Foundation board meeting
*Date: 2026-09-22
*Location: Online with NextCloud

=Presents=
Members of the board (subscription up to date) that are present (Name of organization and name of contact):

*ATM (Maxime Kohlhaas)
*DoliCloud (Laurent DESTAILLEUR)
*Inovea Conseil (Alexandre SPANGARO + Nicolas Zabouri)
*SCOPEN (Florian HENRY)
*ATOO NEt

=Topics=

==French Certification of Dolibarr system for France by LNE==

Control was done in july. Around 140 points are ok but there is still 1 non-conformity point reported (only for certification, software is ok for attestation).
Still waiting feedback of LNE about our answer done in end of june on this point.

Note: Problem will not be solved quickly, so users are invited to obtain a "Conformity statement" that can be provided by their integrator or reseller instead of waiting for the public "Certification".

=> Remind sent the 25th of august.
=> The LNE has contacted us the 11th of september to say they will provide us an answer about our solution.

==Action done by Laurent Destailleur (Dolibarr foundation requests)==

*A tool to build a zip, tag the version, update the changelog and publish on dolistore as been developped.

==New preferred partner==
No new preferred partner requested in July.
Remind: Prestalidaire was added in June.
Prestalidaire Switzerland has been accepted as a new Partner (2 entities with 2 different memberships done)

==Foundation tools==

*Quotation validation to upgrade our Nextcloud and split server that host the forum

*A new metabase report has been created to better follow Preferred Partner program = > Need to migrate it on a server of the foundation.

==Replacement of Stripe with Stancer on Dolistore==
Development and test are finished and OK.

Planned for december 2026.

==Donation system==
Go to test and fix the donation module to accept donation (with vat 0%) and a receipt that must be send automatically by email.

==Help to find founding==

*Dolibarr foundation continue to describe all the tasks of Einvoicing module to obtain the fund of the NLNET organization (NLNET - European NGI organization)

==Dolibarr forum==
Move of forum on another server.
Maxime has sent the quote signed to Jean Traullé.
Laurent has sent the credential of the new server.

TODO: Jean: Intervention is planned.

==Attorney question==
* Question on refunding or not sells for module with a very high amount need a lawyer advice (rules for Dolibarr).
** Our attorney has returned a quote to analyze solutions according to french law (around 3 000 euros).
** A meeting was done with the laywer the 7th of september. A document (answer by the lawyer) is expected between end of september and mi october.
** Waiting report for mid-october.

* Some abuse has been detected by seller that does not respect the rules.

==DevCamps organization==
===Winter DevCamp 2026===

*Date is defined: 26-November-2026 14:00 to 29-November-2026 12:00
*Location: Hôtel Des Congrès, Place du Commandant Rivière, 69100 Villeurbanne
*Organized by: OpenDSI
*Quotation under review by Dolibarr board => Budget validated without the line for coffe the sunday (the breakfast is enough).
*First Deposit was already payed
*Open subscription to all is launched on Forum and Dolibarr News

===Summer DevCamp 2027===

*Date: TBD
*Lille - Nord ERP CRM is confirmed too.

Date planned are 17th june to 19th of june 2027.

TODO Maxime must sign the proposal. Due to higher prices of hostel, price could be rised to 220 euro HT per person.

===Winter DevCamp 2027===

*Date: TBD
*Nancy: Inovea wish to be organizer

===Summer DevCamp 2028===

*Date: TBD
*Nancy: SOLAUV wish to be organizer

===Summer DevCamp 2028===

*Date: TBD
*BRIOUDE(43100): SOLAUV wish to be organizer

===Winter DevCamp 2028===

*Date: TBD
*TBD

===Summer DevCamp 2028===

*Date: TBD
*LACHAPELLE SOUS ROUGEMONT (90360): NSINFO SARL wish to organize

==Community modules==
The foundation confirm that any modules flagged as "Community module" (so with the guarantee of the foundation on CI rules, management of mainteners, management of common transifex translation account, management of github mainteners), must not be stored any more on external repository.

Rules for management of the community repository has been initiated:

https://wiki.dolibarr.org/index.php/Modules_-_Rules_for_community_modules

===DoliSecu et Stancer===
The 2 new modules DoliSecu and Stancer validated during previous meeting have been included.

===E-invoicing===

*Actual repository: https://github.com/Dolibarr/dolibarr-community-modules/tree/main/einvoicing
*Work with Dolibarr Integrator/PDPLibre/Esalink
*Work with SuperPDP

The release 1.2.0 is available.

For the module einvoicing, the minimal version is confirmed to be v18.0

==Next congress / meeting==

===Salon Paris Open Source Experience 2026===

*Location: Paris, Porte de Versailles
*Date: 9 & 10 December 2026

Laurent has made a request to register the 14th of august. Request was confirmed as received. Waiting answer of the organization.

===Salon Solution===

*Location: Paris, Porte de Versailles
*Date: 14 & 15 Octobre 2026
**The foundation will participate for 5K€ + 1K€ remain from last year (gold sponsor) - Budget is around 30 000 € (only 6 k€ si provided by the foundation).
**10 companies will be present (silver sponsor) + 6 other sponsoring companies

===FOSDEM===

* 30 & 31 January 2027 - Brussels, Belgium
* Open for application.
* Laurent must apply for the foundation.

===Salon Swiss IT Forum===

*https://www.swiss-it-forums.tech/fr/
*Date: 30 September 2026 : 11h - 21h to 1er October 2026 : 9h - 17h
*Location: Palexpo Genève
**Discuss between partners about this opportunities

Report board meeting 20260922 teleconf

2026-09-22T10:56:49Z

Eldy: /* Dolibarr forum */

{{TemplateAssoEn}} {{TemplateAssoFr}}

=Title/Date/Location=

*Title: Foundation board meeting
*Date: 2026-09-22
*Location: Online with NextCloud

=Presents=
Members of the board (subscription up to date) that are present (Name of organization and name of contact):

*ATM (Maxime Kohlhaas)
*DoliCloud (Laurent DESTAILLEUR)
*Inovea Conseil (Alexandre SPANGARO + Nicolas Zabouri)
*SCOPEN (Florian HENRY)
*ATOO NEt

=Topics=

==French Certification of Dolibarr system for France by LNE==

Control was done in july. Around 140 points are ok but there is still 1 non-conformity point reported (only for certification, software is ok for attestation).
Still waiting feedback of LNE about our answer done in end of june on this point.

Note: Problem will not be solved quickly, so users are invited to obtain a "Conformity statement" that can be provided by their integrator or reseller instead of waiting for the public "Certification".

=> Remind sent the 25th of august.
=> The LNE has contacted us the 11th of september to say they will provide us an answer about our solution.

==Action done by Laurent Destailleur (Dolibarr foundation requests)==

*A tool to build a zip, tag the version, update the changelog and publish on dolistore as been developped.

==New preferred partner==
No new preferred partner requested in July.
Remind: Prestalidaire was added in June.
Prestalidaire Switzerland has been accepted as a new Partner (2 entities with 2 different memberships done)

==Foundation tools==

*Quotation validation to upgrade our Nextcloud and split server that host the forum

*A new metabase report has been created to better follow Preferred Partner program = > Need to migrate it on a server of the foundation.

==Replacement of Stripe with Stancer on Dolistore==
Development and test are finished and OK.

Planned for december 2026.

==Donation system==
Go to test and fix the donation module to accept donation (with vat 0%) and a receipt that must be send automatically by email.

==Help to find founding==

*Dolibarr foundation continue to describe all the tasks of Einvoicing module to obtain the fund of the NLNET organization (NLNET - European NGI organization)

==Dolibarr forum==
Move of forum on another server.
Maxime has sent the quote signed to Jean Traullé.
Laurent has sent the credential of the new server.

TODO: Jean: Intervention is planned.

==Attorney question==
Question on refunding or not sells for module with a very high amount need a lawyer advice (rules for dolibarr).
Our attorney has returned a quote to analyze solutions according to french law (around 3 000 euros).

A meeting was done with the laywer the 7th of september. A document (answer by the lawyer) is expected between end of september and mi october.

==DevCamps organization==
===Winter DevCamp 2026===

*Date is defined: 26-November-2026 14:00 to 29-November-2026 12:00
*Location: Hôtel Des Congrès, Place du Commandant Rivière, 69100 Villeurbanne
*Organized by: OpenDSI
*Quotation under review by Dolibarr board => Budget validated without the line for coffe the sunday (the breakfast is enough).
*First Deposit was already payed
*TODO Maxime: Communication for subscribing Partner has been set. Subscription for Preferred Partner are open until the 15th of september (limited to 2 people per company). Then it will be open to everybody (no limit for end users).

===Summer DevCamp 2027===

*Date: TBD
*Lille - Nord ERP CRM is confirmed too.

Date planned are 17th june to 19th of june 2027.

TODO Maxime must sign the proposal. Due to higher prices of hostel, price could be rised to 220 euro HT per person.

===Winter DevCamp 2027===

*Date: TBD
*Nancy: Inovea wish to be organizer

===Summer DevCamp 2028===

*Date: TBD
*Nancy: SOLAUV wish to be organizer

===Summer DevCamp 2028===

*Date: TBD
*BRIOUDE(43100): SOLAUV wish to be organizer

===Winter DevCamp 2028===

*Date: TBD
*TBD

===Summer DevCamp 2028===

*Date: TBD
*LACHAPELLE SOUS ROUGEMONT (90360): NSINFO SARL wish to organize

==Community modules==
The foundation confirm that any modules flagged as "Community module" (so with the guarantee of the foundation on CI rules, management of mainteners, management of common transifex translation account, management of github mainteners), must not be stored any more on external repository.

Rules for management of the community repository has been initiated:

https://wiki.dolibarr.org/index.php/Modules_-_Rules_for_community_modules

===DoliSecu et Stancer===
The 2 new modules DoliSecu and Stancer validated during previous meeting have been included.

===E-invoicing===

*Actual repository: https://github.com/Dolibarr/dolibarr-community-modules/tree/main/einvoicing
*Work with Dolibarr Integrator/PDPLibre/Esalink
*Work with SuperPDP

The release 1.2.0 is available.

For the module einvoicing, the minimal version is confirmed to be v18.0

==Next congress / meeting==

===Salon Paris Open Source Experience 2026===

*Location: Paris, Porte de Versailles
*Date: 9 & 10 December 2026

Laurent has made a request to register the 14th of august. Request was confirmed as received. Waiting answer of the organization.

===Salon Solution===

*Location: Paris, Porte de Versailles
*Date: 14 & 15 Octobre 2026
**The foundation will participate for 5K€ + 1K€ remain from last year (gold sponsor) - Budget is around 30 000 € (only 6 k€ si provided by the foundation).
**10 companies will be present (silver sponsor) + 6 other sponsoring companies

===FOSDEM===

* 30 & 31 January 2027 - Brussels, Belgium
* Open for application.
* Laurent must apply for the foundation.

===Salon Swiss IT Forum===

*https://www.swiss-it-forums.tech/fr/
*Date: 30 September 2026 : 11h - 21h to 1er October 2026 : 9h - 17h
*Location: Palexpo Genève
**Discuss between partners about this opportunities

Report board meeting 20260922 teleconf

2026-09-22T10:56:06Z

Eldy: /* Upgrade of nextcloud */

{{TemplateAssoEn}} {{TemplateAssoFr}}

=Title/Date/Location=

*Title: Foundation board meeting
*Date: 2026-09-22
*Location: Online with NextCloud

=Presents=
Members of the board (subscription up to date) that are present (Name of organization and name of contact):

*ATM (Maxime Kohlhaas)
*DoliCloud (Laurent DESTAILLEUR)
*Inovea Conseil (Alexandre SPANGARO + Nicolas Zabouri)
*SCOPEN (Florian HENRY)
*ATOO NEt

=Topics=

==French Certification of Dolibarr system for France by LNE==

Control was done in july. Around 140 points are ok but there is still 1 non-conformity point reported (only for certification, software is ok for attestation).
Still waiting feedback of LNE about our answer done in end of june on this point.

Note: Problem will not be solved quickly, so users are invited to obtain a "Conformity statement" that can be provided by their integrator or reseller instead of waiting for the public "Certification".

=> Remind sent the 25th of august.
=> The LNE has contacted us the 11th of september to say they will provide us an answer about our solution.

==Action done by Laurent Destailleur (Dolibarr foundation requests)==

*A tool to build a zip, tag the version, update the changelog and publish on dolistore as been developped.

==New preferred partner==
No new preferred partner requested in July.
Remind: Prestalidaire was added in June.
Prestalidaire Switzerland has been accepted as a new Partner (2 entities with 2 different memberships done)

==Foundation tools==

*Quotation validation to upgrade our Nextcloud and split server that host the forum

*A new metabase report has been created to better follow Preferred Partner program = > Need to migrate it on a server of the foundation.

==Replacement of Stripe with Stancer on Dolistore==
Development and test are finished and OK.

Planned for december 2026.

==Donation system==
Go to test and fix the donation module to accept donation (with vat 0%) and a receipt that must be send automatically by email.

==Help to find founding==

*Dolibarr foundation continue to describe all the tasks of Einvoicing module to obtain the fund of the NLNET organization (NLNET - European NGI organization)

==Dolibarr forum==
Move of forum on another server.

Maxime has sent the quote signed to Jean Traullé

TODO: Laurent + Jean: Plan the intervention.

==Attorney question==
Question on refunding or not sells for module with a very high amount need a lawyer advice (rules for dolibarr).
Our attorney has returned a quote to analyze solutions according to french law (around 3 000 euros).

A meeting was done with the laywer the 7th of september. A document (answer by the lawyer) is expected between end of september and mi october.

==DevCamps organization==
===Winter DevCamp 2026===

*Date is defined: 26-November-2026 14:00 to 29-November-2026 12:00
*Location: Hôtel Des Congrès, Place du Commandant Rivière, 69100 Villeurbanne
*Organized by: OpenDSI
*Quotation under review by Dolibarr board => Budget validated without the line for coffe the sunday (the breakfast is enough).
*First Deposit was already payed
*TODO Maxime: Communication for subscribing Partner has been set. Subscription for Preferred Partner are open until the 15th of september (limited to 2 people per company). Then it will be open to everybody (no limit for end users).

===Summer DevCamp 2027===

*Date: TBD
*Lille - Nord ERP CRM is confirmed too.

Date planned are 17th june to 19th of june 2027.

TODO Maxime must sign the proposal. Due to higher prices of hostel, price could be rised to 220 euro HT per person.

===Winter DevCamp 2027===

*Date: TBD
*Nancy: Inovea wish to be organizer

===Summer DevCamp 2028===

*Date: TBD
*Nancy: SOLAUV wish to be organizer

===Summer DevCamp 2028===

*Date: TBD
*BRIOUDE(43100): SOLAUV wish to be organizer

===Winter DevCamp 2028===

*Date: TBD
*TBD

===Summer DevCamp 2028===

*Date: TBD
*LACHAPELLE SOUS ROUGEMONT (90360): NSINFO SARL wish to organize

==Community modules==
The foundation confirm that any modules flagged as "Community module" (so with the guarantee of the foundation on CI rules, management of mainteners, management of common transifex translation account, management of github mainteners), must not be stored any more on external repository.

Rules for management of the community repository has been initiated:

https://wiki.dolibarr.org/index.php/Modules_-_Rules_for_community_modules

===DoliSecu et Stancer===
The 2 new modules DoliSecu and Stancer validated during previous meeting have been included.

===E-invoicing===

*Actual repository: https://github.com/Dolibarr/dolibarr-community-modules/tree/main/einvoicing
*Work with Dolibarr Integrator/PDPLibre/Esalink
*Work with SuperPDP

The release 1.2.0 is available.

For the module einvoicing, the minimal version is confirmed to be v18.0

==Next congress / meeting==

===Salon Paris Open Source Experience 2026===

*Location: Paris, Porte de Versailles
*Date: 9 & 10 December 2026

Laurent has made a request to register the 14th of august. Request was confirmed as received. Waiting answer of the organization.

===Salon Solution===

*Location: Paris, Porte de Versailles
*Date: 14 & 15 Octobre 2026
**The foundation will participate for 5K€ + 1K€ remain from last year (gold sponsor) - Budget is around 30 000 € (only 6 k€ si provided by the foundation).
**10 companies will be present (silver sponsor) + 6 other sponsoring companies

===FOSDEM===

* 30 & 31 January 2027 - Brussels, Belgium
* Open for application.
* Laurent must apply for the foundation.

===Salon Swiss IT Forum===

*https://www.swiss-it-forums.tech/fr/
*Date: 30 September 2026 : 11h - 21h to 1er October 2026 : 9h - 17h
*Location: Palexpo Genève
**Discuss between partners about this opportunities

Report board meeting 20260922 teleconf

2026-09-22T10:55:03Z

Eldy: /* Next congress / meeting */

{{TemplateAssoEn}} {{TemplateAssoFr}}

=Title/Date/Location=

*Title: Foundation board meeting
*Date: 2026-09-22
*Location: Online with NextCloud

=Presents=
Members of the board (subscription up to date) that are present (Name of organization and name of contact):

*ATM (Maxime Kohlhaas)
*DoliCloud (Laurent DESTAILLEUR)
*Inovea Conseil (Alexandre SPANGARO + Nicolas Zabouri)
*SCOPEN (Florian HENRY)
*ATOO NEt

=Topics=

==French Certification of Dolibarr system for France by LNE==

Control was done in july. Around 140 points are ok but there is still 1 non-conformity point reported (only for certification, software is ok for attestation).
Still waiting feedback of LNE about our answer done in end of june on this point.

Note: Problem will not be solved quickly, so users are invited to obtain a "Conformity statement" that can be provided by their integrator or reseller instead of waiting for the public "Certification".

=> Remind sent the 25th of august.
=> The LNE has contacted us the 11th of september to say they will provide us an answer about our solution.

==Action done by Laurent Destailleur (Dolibarr foundation requests)==

*A tool to build a zip, tag the version, update the changelog and publish on dolistore as been developped.

==New preferred partner==
No new preferred partner requested in July.
Remind: Prestalidaire was added in June.
Prestalidaire Switzerland has been accepted as a new Partner (2 entities with 2 different memberships done)

==Foundation tools==

*Quotation validation to upgrade our Nextcloud and split server that host the forum

*A new metabase report has been created to better follow Preferred Partner program = > Need to migrate it on a server of the foundation.

==Replacement of Stripe with Stancer on Dolistore==
Development and test are finished and OK.

Planned for december 2026.

==Donation system==
Go to test and fix the donation module to accept donation (with vat 0%) and a receipt that must be send automatically by email.

==Help to find founding==

*Dolibarr foundation continue to describe all the tasks of Einvoicing module to obtain the fund of the NLNET organization (NLNET - European NGI organization)

==Upgrade of nextcloud==
Waiting for Florian Charlet intervention => Done.

==Dolibarr forum==
Move of forum on another server.

Maxime has sent the quote signed to Jean Traullé

TODO: Laurent + Jean: Plan the intervention.

==Attorney question==
Question on refunding or not sells for module with a very high amount need a lawyer advice (rules for dolibarr).
Our attorney has returned a quote to analyze solutions according to french law (around 3 000 euros).

A meeting was done with the laywer the 7th of september. A document (answer by the lawyer) is expected between end of september and mi october.

==DevCamps organization==
===Winter DevCamp 2026===

*Date is defined: 26-November-2026 14:00 to 29-November-2026 12:00
*Location: Hôtel Des Congrès, Place du Commandant Rivière, 69100 Villeurbanne
*Organized by: OpenDSI
*Quotation under review by Dolibarr board => Budget validated without the line for coffe the sunday (the breakfast is enough).
*First Deposit was already payed
*TODO Maxime: Communication for subscribing Partner has been set. Subscription for Preferred Partner are open until the 15th of september (limited to 2 people per company). Then it will be open to everybody (no limit for end users).

===Summer DevCamp 2027===

*Date: TBD
*Lille - Nord ERP CRM is confirmed too.

Date planned are 17th june to 19th of june 2027.

TODO Maxime must sign the proposal. Due to higher prices of hostel, price could be rised to 220 euro HT per person.

===Winter DevCamp 2027===

*Date: TBD
*Nancy: Inovea wish to be organizer

===Summer DevCamp 2028===

*Date: TBD
*Nancy: SOLAUV wish to be organizer

===Summer DevCamp 2028===

*Date: TBD
*BRIOUDE(43100): SOLAUV wish to be organizer

===Winter DevCamp 2028===

*Date: TBD
*TBD

===Summer DevCamp 2028===

*Date: TBD
*LACHAPELLE SOUS ROUGEMONT (90360): NSINFO SARL wish to organize

==Community modules==
The foundation confirm that any modules flagged as "Community module" (so with the guarantee of the foundation on CI rules, management of mainteners, management of common transifex translation account, management of github mainteners), must not be stored any more on external repository.

Rules for management of the community repository has been initiated:

https://wiki.dolibarr.org/index.php/Modules_-_Rules_for_community_modules

===DoliSecu et Stancer===
The 2 new modules DoliSecu and Stancer validated during previous meeting have been included.

===E-invoicing===

*Actual repository: https://github.com/Dolibarr/dolibarr-community-modules/tree/main/einvoicing
*Work with Dolibarr Integrator/PDPLibre/Esalink
*Work with SuperPDP

The release 1.2.0 is available.

For the module einvoicing, the minimal version is confirmed to be v18.0

==Next congress / meeting==

===Salon Paris Open Source Experience 2026===

*Location: Paris, Porte de Versailles
*Date: 9 & 10 December 2026

Laurent has made a request to register the 14th of august. Request was confirmed as received. Waiting answer of the organization.

===Salon Solution===

*Location: Paris, Porte de Versailles
*Date: 14 & 15 Octobre 2026
**The foundation will participate for 5K€ + 1K€ remain from last year (gold sponsor) - Budget is around 30 000 € (only 6 k€ si provided by the foundation).
**10 companies will be present (silver sponsor) + 6 other sponsoring companies

===FOSDEM===

* 30 & 31 January 2027 - Brussels, Belgium
* Open for application.
* Laurent must apply for the foundation.

===Salon Swiss IT Forum===

*https://www.swiss-it-forums.tech/fr/
*Date: 30 September 2026 : 11h - 21h to 1er October 2026 : 9h - 17h
*Location: Palexpo Genève
**Discuss between partners about this opportunities

Report board meeting 20260922 teleconf

2026-09-22T10:53:35Z

Eldy: /* Replacement of Stripe with Stancer on Dolistore */

{{TemplateAssoEn}} {{TemplateAssoFr}}

=Title/Date/Location=

*Title: Foundation board meeting
*Date: 2026-09-22
*Location: Online with NextCloud

=Presents=
Members of the board (subscription up to date) that are present (Name of organization and name of contact):

*ATM (Maxime Kohlhaas)
*DoliCloud (Laurent DESTAILLEUR)
*Inovea Conseil (Alexandre SPANGARO + Nicolas Zabouri)
*SCOPEN (Florian HENRY)
*ATOO NEt

=Topics=

==French Certification of Dolibarr system for France by LNE==

Control was done in july. Around 140 points are ok but there is still 1 non-conformity point reported (only for certification, software is ok for attestation).
Still waiting feedback of LNE about our answer done in end of june on this point.

Note: Problem will not be solved quickly, so users are invited to obtain a "Conformity statement" that can be provided by their integrator or reseller instead of waiting for the public "Certification".

=> Remind sent the 25th of august.
=> The LNE has contacted us the 11th of september to say they will provide us an answer about our solution.

==Action done by Laurent Destailleur (Dolibarr foundation requests)==

*A tool to build a zip, tag the version, update the changelog and publish on dolistore as been developped.

==New preferred partner==
No new preferred partner requested in July.
Remind: Prestalidaire was added in June.
Prestalidaire Switzerland has been accepted as a new Partner (2 entities with 2 different memberships done)

==Foundation tools==

*Quotation validation to upgrade our Nextcloud and split server that host the forum

*A new metabase report has been created to better follow Preferred Partner program = > Need to migrate it on a server of the foundation.

==Replacement of Stripe with Stancer on Dolistore==
Development and test are finished and OK.

Planned for december 2026.

==Donation system==
Go to test and fix the donation module to accept donation (with vat 0%) and a receipt that must be send automatically by email.

==Help to find founding==

*Dolibarr foundation continue to describe all the tasks of Einvoicing module to obtain the fund of the NLNET organization (NLNET - European NGI organization)

==Upgrade of nextcloud==
Waiting for Florian Charlet intervention => Done.

==Dolibarr forum==
Move of forum on another server.

Maxime has sent the quote signed to Jean Traullé

TODO: Laurent + Jean: Plan the intervention.

==Attorney question==
Question on refunding or not sells for module with a very high amount need a lawyer advice (rules for dolibarr).
Our attorney has returned a quote to analyze solutions according to french law (around 3 000 euros).

A meeting was done with the laywer the 7th of september. A document (answer by the lawyer) is expected between end of september and mi october.

==DevCamps organization==
===Winter DevCamp 2026===

*Date is defined: 26-November-2026 14:00 to 29-November-2026 12:00
*Location: Hôtel Des Congrès, Place du Commandant Rivière, 69100 Villeurbanne
*Organized by: OpenDSI
*Quotation under review by Dolibarr board => Budget validated without the line for coffe the sunday (the breakfast is enough).
*First Deposit was already payed
*TODO Maxime: Communication for subscribing Partner has been set. Subscription for Preferred Partner are open until the 15th of september (limited to 2 people per company). Then it will be open to everybody (no limit for end users).

===Summer DevCamp 2027===

*Date: TBD
*Lille - Nord ERP CRM is confirmed too.

Date planned are 17th june to 19th of june 2027.

TODO Maxime must sign the proposal. Due to higher prices of hostel, price could be rised to 220 euro HT per person.

===Winter DevCamp 2027===

*Date: TBD
*Nancy: Inovea wish to be organizer

===Summer DevCamp 2028===

*Date: TBD
*Nancy: SOLAUV wish to be organizer

===Summer DevCamp 2028===

*Date: TBD
*BRIOUDE(43100): SOLAUV wish to be organizer

===Winter DevCamp 2028===

*Date: TBD
*TBD

===Summer DevCamp 2028===

*Date: TBD
*LACHAPELLE SOUS ROUGEMONT (90360): NSINFO SARL wish to organize

==Community modules==
The foundation confirm that any modules flagged as "Community module" (so with the guarantee of the foundation on CI rules, management of mainteners, management of common transifex translation account, management of github mainteners), must not be stored any more on external repository.

Rules for management of the community repository has been initiated:

https://wiki.dolibarr.org/index.php/Modules_-_Rules_for_community_modules

===DoliSecu et Stancer===
The 2 new modules DoliSecu and Stancer validated during previous meeting have been included.

===E-invoicing===

*Actual repository: https://github.com/Dolibarr/dolibarr-community-modules/tree/main/einvoicing
*Work with Dolibarr Integrator/PDPLibre/Esalink
*Work with SuperPDP

The release 1.2.0 is available.

For the module einvoicing, the minimal version is confirmed to be v18.0

==Next congress / meeting==

===Salon Paris Open Source Experience 2026===

*Location: Paris, Porte de Versailles
*Date: 9 & 10 December 2026

Laurent has made a request to register the 14th of august. Request was confirmed as received. Waiting answer of the organization.

===Salon Solution===

*Location: Paris, Porte de Versailles
*Date: 14 & 15 Octobre 2026
**The foundation will participate for 5K€ + 1K€ remain from last year (gold sponsor) - Budget is around 30 000 € (only 6 k€ si provided by the foundation).
**10 companies will be present (silver sponsor) + 6 other sponsoring companies

===FOSDEM===

*Application is opened.
*Laurent must apply

===Salon Swiss IT Forum===

*https://www.swiss-it-forums.tech/fr/
*Date: 30 September 2026 : 11h - 21h to 1er October 2026 : 9h - 17h
*Location: Palexpo Genève
**Discuss between partners about this opportunities

Report board meeting 20260922 teleconf

2026-09-22T10:41:06Z

Eldy: /* Next congress / meeting */

{{TemplateAssoEn}} {{TemplateAssoFr}}

=Title/Date/Location=

*Title: Foundation board meeting
*Date: 2026-09-22
*Location: Online with NextCloud

=Presents=
Members of the board (subscription up to date) that are present (Name of organization and name of contact):

*ATM (Maxime Kohlhaas)
*DoliCloud (Laurent DESTAILLEUR)
*Inovea Conseil (Alexandre SPANGARO + Nicolas Zabouri)
*SCOPEN (Florian HENRY)
*ATOO NEt

=Topics=

==French Certification of Dolibarr system for France by LNE==

Control was done in july. Around 140 points are ok but there is still 1 non-conformity point reported (only for certification, software is ok for attestation).
Still waiting feedback of LNE about our answer done in end of june on this point.

Note: Problem will not be solved quickly, so users are invited to obtain a "Conformity statement" that can be provided by their integrator or reseller instead of waiting for the public "Certification".

=> Remind sent the 25th of august.
=> The LNE has contacted us the 11th of september to say they will provide us an answer about our solution.

==Action done by Laurent Destailleur (Dolibarr foundation requests)==

*A tool to build a zip, tag the version, update the changelog and publish on dolistore as been developped.

==New preferred partner==
No new preferred partner requested in July.
Remind: Prestalidaire was added in June.
Prestalidaire Switzerland has been accepted as a new Partner (2 entities with 2 different memberships done)

==Foundation tools==

*Quotation validation to upgrade our Nextcloud and split server that host the forum

*A new metabase report has been created to better follow Preferred Partner program = > Need to migrate it on a server of the foundation.

==Replacement of Stripe with Stancer on Dolistore==
Development and test are finished and OK.

Planned for december 2026.

==Help to find founding==

*Dolibarr foundation continue to describe all the tasks of Einvoicing module to obtain the fund of the NLNET organization (NLNET - European NGI organization)

==Upgrade of nextcloud==
Waiting for Florian Charlet intervention => Done.

==Dolibarr forum==
Move of forum on another server.

Maxime has sent the quote signed to Jean Traullé

TODO: Laurent + Jean: Plan the intervention.

==Attorney question==
Question on refunding or not sells for module with a very high amount need a lawyer advice (rules for dolibarr).
Our attorney has returned a quote to analyze solutions according to french law (around 3 000 euros).

A meeting was done with the laywer the 7th of september. A document (answer by the lawyer) is expected between end of september and mi october.

==DevCamps organization==
===Winter DevCamp 2026===

*Date is defined: 26-November-2026 14:00 to 29-November-2026 12:00
*Location: Hôtel Des Congrès, Place du Commandant Rivière, 69100 Villeurbanne
*Organized by: OpenDSI
*Quotation under review by Dolibarr board => Budget validated without the line for coffe the sunday (the breakfast is enough).
*First Deposit was already payed
*TODO Maxime: Communication for subscribing Partner has been set. Subscription for Preferred Partner are open until the 15th of september (limited to 2 people per company). Then it will be open to everybody (no limit for end users).

===Summer DevCamp 2027===

*Date: TBD
*Lille - Nord ERP CRM is confirmed too.

Date planned are 17th june to 19th of june 2027.

TODO Maxime must sign the proposal. Due to higher prices of hostel, price could be rised to 220 euro HT per person.

===Winter DevCamp 2027===

*Date: TBD
*Nancy: Inovea wish to be organizer

===Summer DevCamp 2028===

*Date: TBD
*Nancy: SOLAUV wish to be organizer

===Summer DevCamp 2028===

*Date: TBD
*BRIOUDE(43100): SOLAUV wish to be organizer

===Winter DevCamp 2028===

*Date: TBD
*TBD

===Summer DevCamp 2028===

*Date: TBD
*LACHAPELLE SOUS ROUGEMONT (90360): NSINFO SARL wish to organize

==Community modules==
The foundation confirm that any modules flagged as "Community module" (so with the guarantee of the foundation on CI rules, management of mainteners, management of common transifex translation account, management of github mainteners), must not be stored any more on external repository.

Rules for management of the community repository has been initiated:

https://wiki.dolibarr.org/index.php/Modules_-_Rules_for_community_modules

===DoliSecu et Stancer===
The 2 new modules DoliSecu and Stancer validated during previous meeting have been included.

===E-invoicing===

*Actual repository: https://github.com/Dolibarr/dolibarr-community-modules/tree/main/einvoicing
*Work with Dolibarr Integrator/PDPLibre/Esalink
*Work with SuperPDP

The release 1.2.0 is available.

For the module einvoicing, the minimal version is confirmed to be v18.0

==Next congress / meeting==

===Salon Paris Open Source Experience 2026===

*Location: Paris, Porte de Versailles
*Date: 9 & 10 December 2026

Laurent has made a request to register the 14th of august. Request was confirmed as received. Waiting answer of the organization.

===Salon Solution===

*Location: Paris, Porte de Versailles
*Date: 14 & 15 Octobre 2026
**The foundation will participate for 5K€ + 1K€ remain from last year (gold sponsor) - Budget is around 30 000 € (only 6 k€ si provided by the foundation).
**10 companies will be present (silver sponsor) + 6 other sponsoring companies

===FOSDEM===

*Application is opened.
*Laurent must apply

===Salon Swiss IT Forum===

*https://www.swiss-it-forums.tech/fr/
*Date: 30 September 2026 : 11h - 21h to 1er October 2026 : 9h - 17h
*Location: Palexpo Genève
**Discuss between partners about this opportunities

Report board meeting 20260922 teleconf

2026-09-22T10:32:50Z

Eldy: /* Salon Solution */

{{TemplateAssoEn}} {{TemplateAssoFr}}

=Title/Date/Location=

*Title: Foundation board meeting
*Date: 2026-09-22
*Location: Online with NextCloud

=Presents=
Members of the board (subscription up to date) that are present (Name of organization and name of contact):

*ATM (Maxime Kohlhaas)
*DoliCloud (Laurent DESTAILLEUR)
*Inovea Conseil (Alexandre SPANGARO + Nicolas Zabouri)
*SCOPEN (Florian HENRY)
*ATOO NEt

=Topics=

==French Certification of Dolibarr system for France by LNE==

Control was done in july. Around 140 points are ok but there is still 1 non-conformity point reported (only for certification, software is ok for attestation).
Still waiting feedback of LNE about our answer done in end of june on this point.

Note: Problem will not be solved quickly, so users are invited to obtain a "Conformity statement" that can be provided by their integrator or reseller instead of waiting for the public "Certification".

=> Remind sent the 25th of august.
=> The LNE has contacted us the 11th of september to say they will provide us an answer about our solution.

==Action done by Laurent Destailleur (Dolibarr foundation requests)==

*A tool to build a zip, tag the version, update the changelog and publish on dolistore as been developped.

==New preferred partner==
No new preferred partner requested in July.
Remind: Prestalidaire was added in June.
Prestalidaire Switzerland has been accepted as a new Partner (2 entities with 2 different memberships done)

==Foundation tools==

*Quotation validation to upgrade our Nextcloud and split server that host the forum

*A new metabase report has been created to better follow Preferred Partner program = > Need to migrate it on a server of the foundation.

==Replacement of Stripe with Stancer on Dolistore==
Development and test are finished and OK.

Planned for december 2026.

==Help to find founding==

*Dolibarr foundation continue to describe all the tasks of Einvoicing module to obtain the fund of the NLNET organization (NLNET - European NGI organization)

==Upgrade of nextcloud==
Waiting for Florian Charlet intervention => Done.

==Dolibarr forum==
Move of forum on another server.

Maxime has sent the quote signed to Jean Traullé

TODO: Laurent + Jean: Plan the intervention.

==Attorney question==
Question on refunding or not sells for module with a very high amount need a lawyer advice (rules for dolibarr).
Our attorney has returned a quote to analyze solutions according to french law (around 3 000 euros).

A meeting was done with the laywer the 7th of september. A document (answer by the lawyer) is expected between end of september and mi october.

==DevCamps organization==
===Winter DevCamp 2026===

*Date is defined: 26-November-2026 14:00 to 29-November-2026 12:00
*Location: Hôtel Des Congrès, Place du Commandant Rivière, 69100 Villeurbanne
*Organized by: OpenDSI
*Quotation under review by Dolibarr board => Budget validated without the line for coffe the sunday (the breakfast is enough).
*First Deposit was already payed
*TODO Maxime: Communication for subscribing Partner has been set. Subscription for Preferred Partner are open until the 15th of september (limited to 2 people per company). Then it will be open to everybody (no limit for end users).

===Summer DevCamp 2027===

*Date: TBD
*Lille - Nord ERP CRM is confirmed too.

Date planned are 17th june to 19th of june 2027.

TODO Maxime must sign the proposal. Due to higher prices of hostel, price could be rised to 220 euro HT per person.

===Winter DevCamp 2027===

*Date: TBD
*Nancy: Inovea wish to be organizer

===Summer DevCamp 2028===

*Date: TBD
*Nancy: SOLAUV wish to be organizer

===Summer DevCamp 2028===

*Date: TBD
*BRIOUDE(43100): SOLAUV wish to be organizer

===Winter DevCamp 2028===

*Date: TBD
*TBD

===Summer DevCamp 2028===

*Date: TBD
*LACHAPELLE SOUS ROUGEMONT (90360): NSINFO SARL wish to organize

==Community modules==
The foundation confirm that any modules flagged as "Community module" (so with the guarantee of the foundation on CI rules, management of mainteners, management of common transifex translation account, management of github mainteners), must not be stored any more on external repository.

Rules for management of the community repository has been initiated:

https://wiki.dolibarr.org/index.php/Modules_-_Rules_for_community_modules

===DoliSecu et Stancer===
The 2 new modules DoliSecu and Stancer validated during previous meeting have been included.

===E-invoicing===

*Actual repository: https://github.com/Dolibarr/dolibarr-community-modules/tree/main/einvoicing
*Work with Dolibarr Integrator/PDPLibre/Esalink
*Work with SuperPDP

The release 1.2.0 is available.

For the module einvoicing, the minimal version is confirmed to be v18.0

==Next congress / meeting==

===Salon Paris Open Source Experience 2026===

*Location: Paris, Porte de Versailles
*Date: 9 & 10 December 2026

Laurent has made a request to register the 14th of august. Request was confirmed as received. Waiting answer of the organization.

===Salon Solution===

*Location: Paris, Porte de Versailles
*Date: 14 & 15 Octobre 2026
**The foundation will participate for 5K€ + 1K€ remain from last year (gold sponsor) - Budget is around 30 000 € (only 6 k€ si provided by the foundation).
**10 companies will be present (silver sponsor) + 6 other sponsoring companies

===FOSDEM===

*mm
*kk

===Salon Swiss IT Forum===

*https://www.swiss-it-forums.tech/fr/
*Date: 30 September 2026 : 11h - 21h to 1er October 2026 : 9h - 17h
*Location: Palexpo Genève
**Discuss between partners about this opportunities

Report board meeting 20260922 teleconf

2026-09-22T10:32:09Z

Eldy: /* Next congress / meeting */

{{TemplateAssoEn}} {{TemplateAssoFr}}

=Title/Date/Location=

*Title: Foundation board meeting
*Date: 2026-09-22
*Location: Online with NextCloud

=Presents=
Members of the board (subscription up to date) that are present (Name of organization and name of contact):

*ATM (Maxime Kohlhaas)
*DoliCloud (Laurent DESTAILLEUR)
*Inovea Conseil (Alexandre SPANGARO + Nicolas Zabouri)
*SCOPEN (Florian HENRY)
*ATOO NEt

=Topics=

==French Certification of Dolibarr system for France by LNE==

Control was done in july. Around 140 points are ok but there is still 1 non-conformity point reported (only for certification, software is ok for attestation).
Still waiting feedback of LNE about our answer done in end of june on this point.

Note: Problem will not be solved quickly, so users are invited to obtain a "Conformity statement" that can be provided by their integrator or reseller instead of waiting for the public "Certification".

=> Remind sent the 25th of august.
=> The LNE has contacted us the 11th of september to say they will provide us an answer about our solution.

==Action done by Laurent Destailleur (Dolibarr foundation requests)==

*A tool to build a zip, tag the version, update the changelog and publish on dolistore as been developped.

==New preferred partner==
No new preferred partner requested in July.
Remind: Prestalidaire was added in June.
Prestalidaire Switzerland has been accepted as a new Partner (2 entities with 2 different memberships done)

==Foundation tools==

*Quotation validation to upgrade our Nextcloud and split server that host the forum

*A new metabase report has been created to better follow Preferred Partner program = > Need to migrate it on a server of the foundation.

==Replacement of Stripe with Stancer on Dolistore==
Development and test are finished and OK.

Planned for december 2026.

==Help to find founding==

*Dolibarr foundation continue to describe all the tasks of Einvoicing module to obtain the fund of the NLNET organization (NLNET - European NGI organization)

==Upgrade of nextcloud==
Waiting for Florian Charlet intervention => Done.

==Dolibarr forum==
Move of forum on another server.

Maxime has sent the quote signed to Jean Traullé

TODO: Laurent + Jean: Plan the intervention.

==Attorney question==
Question on refunding or not sells for module with a very high amount need a lawyer advice (rules for dolibarr).
Our attorney has returned a quote to analyze solutions according to french law (around 3 000 euros).

A meeting was done with the laywer the 7th of september. A document (answer by the lawyer) is expected between end of september and mi october.

==DevCamps organization==
===Winter DevCamp 2026===

*Date is defined: 26-November-2026 14:00 to 29-November-2026 12:00
*Location: Hôtel Des Congrès, Place du Commandant Rivière, 69100 Villeurbanne
*Organized by: OpenDSI
*Quotation under review by Dolibarr board => Budget validated without the line for coffe the sunday (the breakfast is enough).
*First Deposit was already payed
*TODO Maxime: Communication for subscribing Partner has been set. Subscription for Preferred Partner are open until the 15th of september (limited to 2 people per company). Then it will be open to everybody (no limit for end users).

===Summer DevCamp 2027===

*Date: TBD
*Lille - Nord ERP CRM is confirmed too.

Date planned are 17th june to 19th of june 2027.

TODO Maxime must sign the proposal. Due to higher prices of hostel, price could be rised to 220 euro HT per person.

===Winter DevCamp 2027===

*Date: TBD
*Nancy: Inovea wish to be organizer

===Summer DevCamp 2028===

*Date: TBD
*Nancy: SOLAUV wish to be organizer

===Summer DevCamp 2028===

*Date: TBD
*BRIOUDE(43100): SOLAUV wish to be organizer

===Winter DevCamp 2028===

*Date: TBD
*TBD

===Summer DevCamp 2028===

*Date: TBD
*LACHAPELLE SOUS ROUGEMONT (90360): NSINFO SARL wish to organize

==Community modules==
The foundation confirm that any modules flagged as "Community module" (so with the guarantee of the foundation on CI rules, management of mainteners, management of common transifex translation account, management of github mainteners), must not be stored any more on external repository.

Rules for management of the community repository has been initiated:

https://wiki.dolibarr.org/index.php/Modules_-_Rules_for_community_modules

===DoliSecu et Stancer===
The 2 new modules DoliSecu and Stancer validated during previous meeting have been included.

===E-invoicing===

*Actual repository: https://github.com/Dolibarr/dolibarr-community-modules/tree/main/einvoicing
*Work with Dolibarr Integrator/PDPLibre/Esalink
*Work with SuperPDP

The release 1.2.0 is available.

For the module einvoicing, the minimal version is confirmed to be v18.0

==Next congress / meeting==

===Salon Paris Open Source Experience 2026===

*Location: Paris, Porte de Versailles
*Date: 9 & 10 December 2026

Laurent has made a request to register the 14th of august. Request was confirmed as received. Waiting answer of the organization.

===Salon Solution===

*Location: Paris, Porte de Versailles
*Date: 14 & 15 Octobre 2026
**The foundation will participate for 5K€ + 1K€ remain from last year (gold sponsor)
**10 companies will be present (silver sponsor) + 6 other sponsoring companies

===FOSDEM===

*mm
*kk

===Salon Swiss IT Forum===

*https://www.swiss-it-forums.tech/fr/
*Date: 30 September 2026 : 11h - 21h to 1er October 2026 : 9h - 17h
*Location: Palexpo Genève
**Discuss between partners about this opportunities

Report board meeting 20260922 teleconf

2026-09-22T10:21:35Z

Eldy: /* Action done by Laurent Destailleur (Dolibarr foundation requests) */

{{TemplateAssoEn}} {{TemplateAssoFr}}

=Title/Date/Location=

*Title: Foundation board meeting
*Date: 2026-09-22
*Location: Online with NextCloud

=Presents=
Members of the board (subscription up to date) that are present (Name of organization and name of contact):

*ATM (Maxime Kohlhaas)
*DoliCloud (Laurent DESTAILLEUR)
*Inovea Conseil (Alexandre SPANGARO + Nicolas Zabouri)
*SCOPEN (Florian HENRY)
*ATOO NEt

=Topics=

==French Certification of Dolibarr system for France by LNE==

Control was done in july. Around 140 points are ok but there is still 1 non-conformity point reported (only for certification, software is ok for attestation).
Still waiting feedback of LNE about our answer done in end of june on this point.

Note: Problem will not be solved quickly, so users are invited to obtain a "Conformity statement" that can be provided by their integrator or reseller instead of waiting for the public "Certification".

=> Remind sent the 25th of august.
=> The LNE has contacted us the 11th of september to say they will provide us an answer about our solution.

==Action done by Laurent Destailleur (Dolibarr foundation requests)==

*A tool to build a zip, tag the version, update the changelog and publish on dolistore as been developped.

==New preferred partner==
No new preferred partner requested in July.
Remind: Prestalidaire was added in June.
Prestalidaire Switzerland has been accepted as a new Partner (2 entities with 2 different memberships done)

==Foundation tools==

*Quotation validation to upgrade our Nextcloud and split server that host the forum

*A new metabase report has been created to better follow Preferred Partner program = > Need to migrate it on a server of the foundation.

==Replacement of Stripe with Stancer on Dolistore==
Development and test are finished and OK.

Planned for december 2026.

==Help to find founding==

*Dolibarr foundation continue to describe all the tasks of Einvoicing module to obtain the fund of the NLNET organization (NLNET - European NGI organization)

==Upgrade of nextcloud==
Waiting for Florian Charlet intervention => Done.

==Dolibarr forum==
Move of forum on another server.

Maxime has sent the quote signed to Jean Traullé

TODO: Laurent + Jean: Plan the intervention.

==Attorney question==
Question on refunding or not sells for module with a very high amount need a lawyer advice (rules for dolibarr).
Our attorney has returned a quote to analyze solutions according to french law (around 3 000 euros).

A meeting was done with the laywer the 7th of september. A document (answer by the lawyer) is expected between end of september and mi october.

==DevCamps organization==
===Winter DevCamp 2026===

*Date is defined: 26-November-2026 14:00 to 29-November-2026 12:00
*Location: Hôtel Des Congrès, Place du Commandant Rivière, 69100 Villeurbanne
*Organized by: OpenDSI
*Quotation under review by Dolibarr board => Budget validated without the line for coffe the sunday (the breakfast is enough).
*First Deposit was already payed
*TODO Maxime: Communication for subscribing Partner has been set. Subscription for Preferred Partner are open until the 15th of september (limited to 2 people per company). Then it will be open to everybody (no limit for end users).

===Summer DevCamp 2027===

*Date: TBD
*Lille - Nord ERP CRM is confirmed too.

Date planned are 17th june to 19th of june 2027.

TODO Maxime must sign the proposal. Due to higher prices of hostel, price could be rised to 220 euro HT per person.

===Winter DevCamp 2027===

*Date: TBD
*Nancy: Inovea wish to be organizer

===Summer DevCamp 2028===

*Date: TBD
*Nancy: SOLAUV wish to be organizer

===Summer DevCamp 2028===

*Date: TBD
*BRIOUDE(43100): SOLAUV wish to be organizer

===Winter DevCamp 2028===

*Date: TBD
*TBD

===Summer DevCamp 2028===

*Date: TBD
*LACHAPELLE SOUS ROUGEMONT (90360): NSINFO SARL wish to organize

==Community modules==
The foundation confirm that any modules flagged as "Community module" (so with the guarantee of the foundation on CI rules, management of mainteners, management of common transifex translation account, management of github mainteners), must not be stored any more on external repository.

Rules for management of the community repository has been initiated:

https://wiki.dolibarr.org/index.php/Modules_-_Rules_for_community_modules

===DoliSecu et Stancer===
The 2 new modules DoliSecu and Stancer validated during previous meeting have been included.

===E-invoicing===

*Actual repository: https://github.com/Dolibarr/dolibarr-community-modules/tree/main/einvoicing
*Work with Dolibarr Integrator/PDPLibre/Esalink
*Work with SuperPDP

The release 1.2.0 is available.

For the module einvoicing, the minimal version is confirmed to be v18.0

==Next congress / meeting==
===Salon Solution===

*Location: Paris, Porte de Versailles
*Date: 14 & 15 Octobre 2026
**Informal group will have a meeting the 13/03/2026 to discuss the budget required from the foundation (estimated target budget 5K€ + 1K€ remain from last year)

===Salon Paris Open Source Experience 2026===

*Location: Paris, Porte de Versailles
*Date: 9 & 10 December 2026

Laurent has made a request to register the 14th of august. Request was confirmed as received. Waiting answer of the organization.

===Salon Swiss IT Forum===

*https://www.swiss-it-forums.tech/fr/
*Date: 30 September 2026 : 11h - 21h to 1er October 2026 : 9h - 17h
*Location: Palexpo Genève
**Discuss between partners about this opportunities

Report board meeting 20260922 teleconf

2026-09-22T10:21:16Z

Eldy:

{{TemplateAssoEn}} {{TemplateAssoFr}}

=Title/Date/Location=

*Title: Foundation board meeting
*Date: 2026-09-22
*Location: Online with NextCloud

=Presents=
Members of the board (subscription up to date) that are present (Name of organization and name of contact):

*ATM (Maxime Kohlhaas)
*DoliCloud (Laurent DESTAILLEUR)
*Inovea Conseil (Alexandre SPANGARO + Nicolas Zabouri)
*SCOPEN (Florian HENRY)
*ATOO NEt

=Topics=

==French Certification of Dolibarr system for France by LNE==

Control was done in july. Around 140 points are ok but there is still 1 non-conformity point reported (only for certification, software is ok for attestation).
Still waiting feedback of LNE about our answer done in end of june on this point.

Note: Problem will not be solved quickly, so users are invited to obtain a "Conformity statement" that can be provided by their integrator or reseller instead of waiting for the public "Certification".

=> Remind sent the 25th of august.
=> The LNE has contacted us the 11th of september to say they will provide us an answer about our solution.

==Action done by Laurent Destailleur (Dolibarr foundation requests)==

*A tool to build a zip, tag the version, update the changelog and publish on dolistoreas been developped.

==New preferred partner==
No new preferred partner requested in July.
Remind: Prestalidaire was added in June.
Prestalidaire Switzerland has been accepted as a new Partner (2 entities with 2 different memberships done)

==Foundation tools==

*Quotation validation to upgrade our Nextcloud and split server that host the forum

*A new metabase report has been created to better follow Preferred Partner program = > Need to migrate it on a server of the foundation.

==Replacement of Stripe with Stancer on Dolistore==
Development and test are finished and OK.

Planned for december 2026.

==Help to find founding==

*Dolibarr foundation continue to describe all the tasks of Einvoicing module to obtain the fund of the NLNET organization (NLNET - European NGI organization)

==Upgrade of nextcloud==
Waiting for Florian Charlet intervention => Done.

==Dolibarr forum==
Move of forum on another server.

Maxime has sent the quote signed to Jean Traullé

TODO: Laurent + Jean: Plan the intervention.

==Attorney question==
Question on refunding or not sells for module with a very high amount need a lawyer advice (rules for dolibarr).
Our attorney has returned a quote to analyze solutions according to french law (around 3 000 euros).

A meeting was done with the laywer the 7th of september. A document (answer by the lawyer) is expected between end of september and mi october.

==DevCamps organization==
===Winter DevCamp 2026===

*Date is defined: 26-November-2026 14:00 to 29-November-2026 12:00
*Location: Hôtel Des Congrès, Place du Commandant Rivière, 69100 Villeurbanne
*Organized by: OpenDSI
*Quotation under review by Dolibarr board => Budget validated without the line for coffe the sunday (the breakfast is enough).
*First Deposit was already payed
*TODO Maxime: Communication for subscribing Partner has been set. Subscription for Preferred Partner are open until the 15th of september (limited to 2 people per company). Then it will be open to everybody (no limit for end users).

===Summer DevCamp 2027===

*Date: TBD
*Lille - Nord ERP CRM is confirmed too.

Date planned are 17th june to 19th of june 2027.

TODO Maxime must sign the proposal. Due to higher prices of hostel, price could be rised to 220 euro HT per person.

===Winter DevCamp 2027===

*Date: TBD
*Nancy: Inovea wish to be organizer

===Summer DevCamp 2028===

*Date: TBD
*Nancy: SOLAUV wish to be organizer

===Summer DevCamp 2028===

*Date: TBD
*BRIOUDE(43100): SOLAUV wish to be organizer

===Winter DevCamp 2028===

*Date: TBD
*TBD

===Summer DevCamp 2028===

*Date: TBD
*LACHAPELLE SOUS ROUGEMONT (90360): NSINFO SARL wish to organize

==Community modules==
The foundation confirm that any modules flagged as "Community module" (so with the guarantee of the foundation on CI rules, management of mainteners, management of common transifex translation account, management of github mainteners), must not be stored any more on external repository.

Rules for management of the community repository has been initiated:

https://wiki.dolibarr.org/index.php/Modules_-_Rules_for_community_modules

===DoliSecu et Stancer===
The 2 new modules DoliSecu and Stancer validated during previous meeting have been included.

===E-invoicing===

*Actual repository: https://github.com/Dolibarr/dolibarr-community-modules/tree/main/einvoicing
*Work with Dolibarr Integrator/PDPLibre/Esalink
*Work with SuperPDP

The release 1.2.0 is available.

For the module einvoicing, the minimal version is confirmed to be v18.0

==Next congress / meeting==
===Salon Solution===

*Location: Paris, Porte de Versailles
*Date: 14 & 15 Octobre 2026
**Informal group will have a meeting the 13/03/2026 to discuss the budget required from the foundation (estimated target budget 5K€ + 1K€ remain from last year)

===Salon Paris Open Source Experience 2026===

*Location: Paris, Porte de Versailles
*Date: 9 & 10 December 2026

Laurent has made a request to register the 14th of august. Request was confirmed as received. Waiting answer of the organization.

===Salon Swiss IT Forum===

*https://www.swiss-it-forums.tech/fr/
*Date: 30 September 2026 : 11h - 21h to 1er October 2026 : 9h - 17h
*Location: Palexpo Genève
**Discuss between partners about this opportunities

Report board meeting 20260922 teleconf

2026-09-22T10:20:15Z

Eldy: Created page with " {{TemplateAssoEn}} {{TemplateAssoFr}} =Title/Date/Location= *Title: Foundation board meeting *Date: 2026-09-22 *Location: Online with NextCloud =Presents= Members of the b..."

{{TemplateAssoEn}} {{TemplateAssoFr}}

=Title/Date/Location=

*Title: Foundation board meeting
*Date: 2026-09-22
*Location: Online with NextCloud

=Presents=
Members of the board (subscription up to date) that are present (Name of organization and name of contact):

*ATM (Maxime Kohlhaas)
*DoliCloud (Laurent DESTAILLEUR)
*Inovea Conseil (Alexandre SPANGARO + Nicolas Zabouri)
*SCOPEN (Florian HENRY)
*ATOO NEt

=Topics=

==French Certification of Dolibarr system for France by LNE==

Control was done in july. Around 140 points are ok but there is still 1 non-conformity point reported (only for certification, software is ok for attestation).
Still waiting feedback of LNE about our answer done in end of june on this point.

Note: Problem will not be solved quickly, so users are invited to obtain a "Conformity statement" that can be provided by their integrator or reseller instead of waiting for the public "Certification".

=> Remind sent the 25th of august.
=> The LNE has contacted us the 11th of september to say they will provide us an answer about our solution.

==Action done by Laurent Destailleur (Dolibarr foundation requests)==

*A tool to build a zip, tag the version, update the changelog and publish on dolistoreas been developped.

==New preferred partner==
No new preferred partner requested in July.
Remind: Prestalidaire was added in June.

==Foundation tools==

*Quotation validation to upgrade our Nextcloud and split server that host the forum

*A new metabase report has been created to better follow Preferred Partner program = > Need to migrate it on a server of the foundation.

==Replacement of Stripe with Stancer on Dolistore==
Development and test are finished and OK.

Planned for december 2026.

==Help to find founding==

*Dolibarr foundation continue to describe all the tasks of Einvoicing module to obtain the fund of the NLNET organization (NLNET - European NGI organization)

==Upgrade of nextcloud==
Waiting for Florian Charlet intervention => Done.

==Dolibarr forum==
Move of forum on another server.

Maxime has sent the quote signed to Jean Traullé

TODO: Laurent + Jean: Plan the intervention.

==Attorney question==
Question on refunding or not sells for module with a very high amount need a lawyer advice (rules for dolibarr).
Our attorney has returned a quote to analyze solutions according to french law (around 3 000 euros).

A meeting was done with the laywer the 7th of september. A document (answer by the lawyer) is expected between end of september and mi october.

==DevCamps organization==
===Winter DevCamp 2026===

*Date is defined: 26-November-2026 14:00 to 29-November-2026 12:00
*Location: Hôtel Des Congrès, Place du Commandant Rivière, 69100 Villeurbanne
*Organized by: OpenDSI
*Quotation under review by Dolibarr board => Budget validated without the line for coffe the sunday (the breakfast is enough).
*First Deposit was already payed
*TODO Maxime: Communication for subscribing Partner has been set. Subscription for Preferred Partner are open until the 15th of september (limited to 2 people per company). Then it will be open to everybody (no limit for end users).

===Summer DevCamp 2027===

*Date: TBD
*Lille - Nord ERP CRM is confirmed too.

Date planned are 17th june to 19th of june 2027.

TODO Maxime must sign the proposal. Due to higher prices of hostel, price could be rised to 220 euro HT per person.

===Winter DevCamp 2027===

*Date: TBD
*Nancy: Inovea wish to be organizer

===Summer DevCamp 2028===

*Date: TBD
*Nancy: SOLAUV wish to be organizer

===Summer DevCamp 2028===

*Date: TBD
*BRIOUDE(43100): SOLAUV wish to be organizer

===Winter DevCamp 2028===

*Date: TBD
*TBD

===Summer DevCamp 2028===

*Date: TBD
*LACHAPELLE SOUS ROUGEMONT (90360): NSINFO SARL wish to organize

==Community modules==
The foundation confirm that any modules flagged as "Community module" (so with the guarantee of the foundation on CI rules, management of mainteners, management of common transifex translation account, management of github mainteners), must not be stored any more on external repository.

Rules for management of the community repository has been initiated:

https://wiki.dolibarr.org/index.php/Modules_-_Rules_for_community_modules

===DoliSecu et Stancer===
The 2 new modules DoliSecu and Stancer validated during previous meeting have been included.

===E-invoicing===

*Actual repository: https://github.com/Dolibarr/dolibarr-community-modules/tree/main/einvoicing
*Work with Dolibarr Integrator/PDPLibre/Esalink
*Work with SuperPDP

The release 1.2.0 is available.

For the module einvoicing, the minimal version is confirmed to be v18.0

==Next congress / meeting==
===Salon Solution===

*Location: Paris, Porte de Versailles
*Date: 14 & 15 Octobre 2026
**Informal group will have a meeting the 13/03/2026 to discuss the budget required from the foundation (estimated target budget 5K€ + 1K€ remain from last year)

===Salon Paris Open Source Experience 2026===

*Location: Paris, Porte de Versailles
*Date: 9 & 10 December 2026

Laurent has made a request to register the 14th of august. Request was confirmed as received. Waiting answer of the organization.

===Salon Swiss IT Forum===

*https://www.swiss-it-forums.tech/fr/
*Date: 30 September 2026 : 11h - 21h to 1er October 2026 : 9h - 17h
*Location: Palexpo Genève
**Discuss between partners about this opportunities

Langages et normes

2026-09-20T16:34:20Z

Eldy: /* Les dates et TimeZone */

[[en:Language_and_development_rules]]
[[de:Sprachen_und_Programmierregeln]]
[[es:Lenguaje_y_Normas_de_Desarrollo]]
[[zh:语言和开发规则]]


{{TemplateDocDevFr}}

Voici les quelques règles sur le langage, la syntaxe et normes de développement en vigueur pour le projet Dolibarr :

=Versions=

*Dolibarr doit fonctionner sur:

#Tous OS (Windows, Linux, MACOS...)
#PHP {{PHPMinVersion}} (Doit fonctionner sans aucun module PHP complémentaire hors les modules d'accès base de donnée). Voir la page [[Versions|Liste des versions, journal des modifications et compatibilités]] pour les prérequis des versions plus anciennes.
#Mysql {{MySqlMinVersion}}

=Normes Copyright=

*Tout fichier PHP doit avoir un en-tête selon le masque suivant

<syntaxhighlight lang="PHP">
<?php
/* Copyright (C) YYYY John Doe <email@email.com>
*
* Licence information
*/
...
</syntaxhighlight>
Quand vous éditez un fichier existant du projet, ajouter une ligne Copyright sous celles existantes.

=Normes PHP=

==PHP==

*Dolibarr est écrit en PHP et supporte toutes versions PHP supérieures à la {{PHPMinVersion}}. Les fichiers doivent tous comporter l'extension .php

*L'appel aux variables superglobales PHP doit passer par les opérateurs dédiés $_COOKIE, $_SERVER, $_ENV. Mais pour récupérer les contenus de $_GET ou $_POST, il faut passer par les fonctions dolibarr [[Fonctions utiles Dolibarr|GETPOST...()]] .

Les autres opérateurs ($HTTP_SERVER_GET, ...) ayant été passés en deprecated au sein de PHP, ne doivent plus être utilisés. Ainsi le code doit fonctionner y compris quand l'option '''register_long_arrays''' est à off.
De plus, le code doit fonctionner aussi bien quand l'option PHP '''register_globals''' est à off (recommandé par PHP) que quand l'option '''register_globals''' est à on (par défaut sur de nombreuses installations).

*Pas d'utilisation de la variable '''PHP_SELF'''. Utiliser à la place $_SERVER["PHP_SELF"]. Notez aussi que le framework Dolibarr passe une routine pour rendre plus sûr le contenu du $_SERVER["PHP_SELF"] (dans le fichier main.inc.php, donc avant tout traitement métier)

*Quand plusieurs variables doivent être initialisées avec la même valeur, il faut utiliser plusieurs instructions:

<syntaxhighlight lang="PHP">
$var1 = 1; $var2 = 1; $var3 = 1;
</syntaxhighlight>
plutôt que
<syntaxhighlight lang="PHP">
$var1 = $var2 = $var3 = 1;
</syntaxhighlight>
qui est moins performant.

*Les chaines doivent avoir les variables sorties de la chaine.

<syntaxhighlight lang="PHP">
print "Mon texte affiche ma ".$variable." !\n";
</syntaxhighlight>

*Les commentaires doivent suivre la syntaxe C, ie un double antislash pour un commentaire d'une ligne et utilisation slash-étoile pour ouvrir un bloc de plusieurs lignes

<syntaxhighlight lang="PHP">
/* Bloc de commentaire
*
* Fin du bloc
*/

$monobjet = new MonObjet($db);
$result=$monobjet->fetch($idobject);

for ($i = 1 , $i < 2 ; $i++)
{
// commentaire sur une ligne
print $i;
}

</syntaxhighlight>

*Les fonctions doivent retourner une valeur strictement > à 0 en cas de succès, et un nombre < à 0 en cas d'erreur.

*Pas de code mort (non utilisé) dans le code principal de Dolibarr (le code utilisé uniquement par un module externe doit être inclus dans le module externe).

*Utiliser "include_once" ou "require_once" pour l'inclusion de tout fichier contenant des définitions de fonction ou de classes (donc fichiers *.class.php et *.lib.php), utiliser "include" pour tout inclusion de fichier de type template ou contenant un mixte de HTML et PHP (donc fichiers *.inc.php et *.tpl.php).

*Le style de code a utiliser est le PSR-12 (https://www.php-fig.org/psr/psr-12/). Seules les règles "MUST" sont imposées. Notez aussi les points/exceptions suivants:
**La longueur des lignes: PSR-12 indique que la longueur des lignes a une limite "soft" à 120. Il est en effet préférable d'avoir de longues lignes de données de déclaration plutôt que de longues pages car ce code ne contient aucune logique intéressante ou utile, toutefois une limite "hard" a été instauré à '''1000''' caractères. Du code qui ira au delà provoquera des erreurs dans la plateforme d'Intégration Continue.
**Les tabulations sont acceptées : L'autre exception est qu'on ne remplace pas les tabulations systématiquement par des espaces. L'utilisation des tabulations simplifie la vie de certains développeurs. De plus, l'utilisation d'espaces rend certaines fonctions d'autoformatage défectueuses (comme sur certaines versions d'Eclipse, lors de copier-coller).
**Note 1: Les règles suivantes sont particulièrement importantes :
***Les fichiers doivent être sauvés en format Unix (LF) et non Windows (CR/LF). Le format Unix étant compatible sur les OS Unix like, Windows, Mac, alors que le format fichier texte Windows pose problème sous certains PHP sous Unix.
***Les smart tags PHP ne sont pas utilisés. Les sections de code doivent commencer par '''<?php'''
**Note 2: Vous pouvez utiliser le fichier '''dev/setup/codesniffer/ruleset.xml''' comme fichier de contrôle pour vérifier votre style de code avec PHPCodeSniffer.
**Note 3: Vous pouvez utiliser le fichier '''dev/setup/eclipse/PSR-12 [built-in].xml''' comme fichier de règles de syntax pour configurer Eclipse.
**Note 4: Vous remarquerez que le code actuel ne suit pas forcément tout cela. La raison est historique. La règle fut instaurée en cours de route, aussi, si vous trouvez du code non respectueux de ce standard, n'hésitez pas à le corriger.

==Structures des classes et champs==

Certaines propriétés de classes se retrouvent dans de nombreuses classes. Pour homogénéité, on utilisera les noms suivants:
{{TemplatePHPFields}}

=Normes SQL=

==Structure et nom des tables et champs==

*Toutes les tables sont préfixées pour éviter les conflits de nommage. Aujourd'hui, le préfixe est modifiable au moment de l'installation. Sa valeur par défaut est <tt>llx_</tt>.

*Structure des tables.

Lorsque vous créez une table, il est recommandé de prendre les même conventions de nommages de tables que les autres tables Dolibarr. Avec, à minima les champs suivant:
- rowid INTEGER AUTO_INCREMENT PRIMARY KEY qui est l'id technique
- entity INTEGER default 1 that is id for the multicompany feature
- date_creation datetime that is the creation date
- tms timestamp qui sera un champ contenant la date de chaque mise à jour (la base de donnée le gère tout seul, pas besoin de le gérer par le code)
- import_key varchar(32) qui contiendra le code d'import YYYYMMDDHHMMSS si vous faites des imports en masse dans la table.
- status smallint pour stocker le status d'un object

Eventuellement
- fk_user_creat integer qui est l'id du user de création (fk_user_author also found)
- fk_user_modif integer qui est l'id du user de modification
- fk_user_valid integer qui est l'id du user de validation
- fk_soc integer qui est l'id du tiers (si applicable)

*Type des champs

Dans la pratique, afin d'être compatible avec toutes les précisions des pays, syntaxes des bases, on utilisera uniquement les types suivants:
- integer pour tout nombre entier, id ou clé étrangère (bigint éventuellement accepté pour les id des très grosses tables)
- smallint pour tout numérique entier de petite taille (comme pour stocker un code de status)
- double(24,8) pour tout montant
- double(6,3) pour les taux de tva
- real pour une quantité
- varchar pour une chaîne (y compris de longueur 1, le type char est de plus en plus déprécié)
- timestamp pour un champ date+heure devant être mis a jour automatiquement
- datetime pour un champ date+heure
- date pour un champ date

==Clé primaire==
La clé primaire d'une table s'appelle <tt>rowid</tt>.

Il y a quelques tables qui échappent à cette règle actuellement (ex [[Table llx_c_actioncomm]]), pour des raisons historiques. Une évolution pourra être étudiée pour une prochaine version.

==Clés étrangères==
Le nom d'une clé étrangère commence par le préfixe <tt>fk_</tt> suivi du nom de la table liée (requis pour éviter doublons globales à la base, problématiques sous certains SGBD comme postgresql) puis du champ lié (pour permettre plusieurs clés étrangères différentes sur une même table).

Exemple:
fk_facture_fourn_fk_soc

Note: Si vous développez votre propre module externe, il ne doit pas y avoir de clé étrangère depuis vos tables qui pointent sur les tables standards de Dolibarr. Ceci casserait les fonctionnalités de mise à jour, de réparation, de sauvegardes et de restauration et ces processus ne doivent pas dépendre de la présence d'un module externe. Il vous faut donc assurer l'intégrité de manière applicative si nécessaire.

==Clés alternatives==
Parfois, il n'y a pas que la clé primaire qui doit être unique. On peut donc ajouter aussi un index clé alternative unique. Un tel index est nommé par un nom qui commence par le préfixe <tt>uk_</tt> suivi du nom de la table (requis pour éviter doublons d'index globals à la base, problématiques sous certains SGBD comme postgresql) puis d'un suffixe qui caractérise la clé (pour permettre plusieurs index uniques sur une même table).

Exemple:
uk_societe_code_client

==Index performance==
Certains champs sont souvent utilisés comme critère de recherche, de tri ou de jointure. Il convient dans ce cas, d'y mettre un index de performance. De tels indexes seront nommés avec un préfix <tt>idx_</tt> puis le nom de la table et le nom du champ sur lequel porte l'index.

Exemple:
idx_societe_user_creat

==Format de fichier DDL==
Les fichiers qui contiennent la définition de la structure de la base (DDL) doivent être au nombre de 2 par tables:
Chaque table est définie dans son propre fichier dont le nom est <tt>llx_''matable''.sql</tt>.
On mettra un commentaire à côté de chaque champ pour en expliquer la signification.
Les clés étrangères et index de performance ou autres contraintes d'unicité sont définies dans un fichier séparé dont le nom est <tt>llx_''matable''.key.sql</tt>

Ces fichiers sont placés dans le répertoire '''install/mysql/tables''' pour les fichiers standards ou '''monmodule/tables''' pour les tables amenées par un module.

Exemple '''fichier table llx_matable.sql''':

<syntaxhighlight lang="sql">
-- ===========================================================================
-- Copyright (C) 2008 Author <email@author.com>
--
-- This program is free software; you can redistribute it and/or modify
-- it under the terms of the GNU General Public License as published by
-- the Free Software Foundation; either version 2 of the License, or
-- (at your option) any later version.
--
-- This program is distributed in the hope that it will be useful,
-- but WITHOUT ANY WARRANTY; without even the implied warranty of
-- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-- GNU General Public License for more details.
--
-- You should have received a copy of the GNU General Public License
-- along with this program. If not, see <http://www.gnu.org/licenses/>.
-- ===========================================================================

create table llx_matable
(
rowid integer AUTO_INCREMENT PRIMARY KEY,
field_one integer,
field_two integer NOT NULL,
fk_field integer,
field_date datetime,
tms timestamp
)ENGINE=innodb;
</syntaxhighlight>

Exemple '''fichier clés/index llx_matable.key.sql''':

<syntaxhighlight lang="sql">
-- ===========================================================================
-- Copyright (C) 2008 Author <email@author.com>
--
-- This program is free software; you can redistribute it and/or modify
-- it under the terms of the GNU General Public License as published by
-- the Free Software Foundation; either version 2 of the License, or
-- (at your option) any later version.
--
-- This program is distributed in the hope that it will be useful,
-- but WITHOUT ANY WARRANTY; without even the implied warranty of
-- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-- GNU General Public License for more details.
--
-- You should have received a copy of the GNU General Public License
-- along with this program. If not, see <http://www.gnu.org/licenses/>.
-- ===========================================================================

ALTER TABLE llx_matable ADD UNIQUE uk_matable_field(field_one, field_two);

ALTER TABLE llx_matable ADD CONSTRAINT fk_matable_fk_field FOREIGN KEY (fk_field) REFERENCES llx_matablepere (rowid);
</syntaxhighlight>

==Règles de codage SQL==

*Utilisation des alias/nommage de champs

Dans le cas des select on pourra utiliser les alias pour simplifier l'écriture des requêtes:
<syntaxhighlight lang="sql">
select chp1, chpxxx2 as chp2 from table2 as t1, table2 as t2 where t1.chpx = t2.chpy
</syntaxhighlight>
Toutefois, il ne faut pas utiliser ces alias sur des requêtes update car non compatible avec mysql 3.1.

*Les SELECT * sont interdits ! Chaque SELECT doit spécifier la liste complète des champs à récupérer. Cela permet d'éviter les confusions. Exemple:

<syntaxhighlight lang="sql">
SELECT field_a, field_b, field_c FROM table_1 WHERE field_d = '$id'
</syntaxhighlight>

*Dans les requêtes SQL, on quote les champs mais pas les numériques qui contiennent des montants destinés à être stockés dans des champs de type double ou real. Les quotes sur les numériques de type float provoquent parfois un stockage d'une valeur différente. Par exemple 412.62 dans le insert sera en fait stocké avec la valeur 412.61999512 en base (suite à des conversions chaines-numériques implicites) si le champ est de type double(24,8). Et seul le PHP voit 412.61999512. Les autres outils verront 412.62 donnant l'impression qu'il n'y a pas de problème. Et c'est le PHP qui a raison, il y a problème en base. En supprimant les quotes sur les numériques, cela va mieux.

Exemple:
<syntaxhighlight lang="sql">
Bon: INSERT INTO table_1 (field_txt, field_num) VALUES ('txt', 412.62)
Mauvais: INSERT INTO table_1 (field_txt, field_num) VALUES ('txt', '412.62')
</syntaxhighlight>

Remarque, le problème des float est général et pas seulement sur les accès base, il est présent dans tous les languages quand on travaille sur des nombres réels, aussi ils doivent être, dès que affectés, nettoyés par la fonction price2num avec le 2eme paramètre renseigné à:
'MU' (si il s'agit d'un prix unitaire), 'MT' (s'il s'agit d'un prix total) ou 'MS' (autres cas) selon le besoin.
Voir aussi le chapitre "Les nombres réels, montants et calculs" plus bas.

*Les fonctions SQL de date NOW, SYSDATE, DATEDIFF, DATE sont interdites au sein des ordres SQL. S'il faut saisir la date du moment dans un champ, la valeur doit venir du PHP, par exemple par la fonction dol_now(), et non du moteur de base de données. Ceci pour les raisons suivantes:
**afin d'avoir une meilleure portabilité du code
**avoir une gestion correcte des TimeZone et ne pas dépendre du TimeZone de la base de donnée (le timezone de réference est le timezone de PHP et le timezone de la base de données peut être différent de celui-ci, aussi les conversions de date doivent se faire toute côté PHP).
**meilleurs performances (voir exemples et commentaire plus loin)

Par exemple, on ne fera pas:
<syntaxhighlight lang="PHP">
$sql="SELECT rowid FROM table where datefield = NOW()";
</syntaxhighlight>
mais:
<syntaxhighlight lang="PHP">
$sql="SELECT rowid FROM table where datefield = '".$this->db->idate(dol_now())."'";
</syntaxhighlight>

Par exemple, on ne fera pas:
<syntaxhighlight lang="PHP">
$sql="SELECT rowid FROM table where DATEDIFF(table.datefield, NOW()) > 7";
</syntaxhighlight>
mais:
<syntaxhighlight lang="PHP">
$sql="SELECT rowid FROM table where datefield < '".$this->db->idate(dol_now() - (7 * 24 * 3600))."'";
</syntaxhighlight>

Un autre avantage de cette règle est que la requête peut bénéficier de l'utilisation de l'index puisqu'on compare datefield à une valeur fixe. Dans le cas du datediff, on applique un traitement sur le champ avant comparaison, rendant impossible l'utilisation de l'index de ce champ. Les conséquences sont des performances très dégradées par rapport à la version sans datediff.

*L'instruction WITH ROLLUP est interdite :

Cette instruction ne doit pas être utilisée : Elle n'est pas gérée de la même manière par des bases de données différentes.
De plus, l'utilisation de WITH ROLLUP brise la pureté des données retournées. L'agrégation intermédiaire de génération de sous-totaux réalisée par cette instruction peut facilement être effectuée à l'aide de PHP et permet de conserver le tableau de données retourné propre (non corrompu par des données insérées artificiellement).
Outres son côté pas bien standardisé, en insérant des résultats de calculs au sein des données, donnant un résultat qui est un mixe donnée et calculs métiers d'aggrégation, la compréhension du code se trouve compliqué et même les évolutions du code sur ces agrégations plus possibles lorsque se complexifient.

*Utilisez $db->ifsql pour le IF SQL

N'incluez pas le IF dans votre requête SQL générée. Mais utilisez plutôt la méthode $db->ifsql() pour créer un SQL IF compatible avec toutes les bases de données SQL.

*Pas de DELETE CASCADE et ON UPDATE CASCADE

De telles instructions SQL sont interdites car elles contournent les règles métiers de l'application. Par exemple, s'il existe une cascade de suppression entre la table A et B, lorsque l'application exécutera le code pour supprimer un enregistrement dans A, les enfants de la table B seront également supprimés. S'il y a eu un trigger Dolibarr PHP (par exemple apporté par un module externe) sur la suppression de l'enregistrement de B (par exemple pour valider la suppression ou pour exécuter une action complémentaire), la DELETE CASCADE sera exécutée sans avoir le trigger Dolibarr PHP exécuté, manquant la validation ou les actions du déclencheur PHP du module. Donc toutes les règles métiers doivent être implémentées du même côté (côté serveur PHP), c'est la raison pour laquelle les règles métier implémentées sur Database ne sont pas autorisées (même situation que le point suivant sur les triggers Database)

==Utilisation des triggers de base de données / procédures stockées==

L'utilisation des triggers de base de données n'est pas autorisée dans le code de Dolibarr. Vous ne devriez donc rencontrer aucun problème avec ces déclencheurs.

*Les triggers de base de données ne sont pas portables. La compatibilité peut être compromise lors de la mise à jour de votre base de données.

*Les triggers de base de données sont souvent oubliés dans les outils de sauvegarde.

*Les triggers de base de données nécessitent des autorisations spéciales que vous ne possédez peut-être pas (et que vous ne devriez pas posséder) sur une base de données sécurisée classique.

*L'utilisation de triggers de base de données implique également l'inclusion de certaines « règles métier » de votre application dans la base de données, alors que la plupart des autres règles sont gérées par le code lui-même (ce qui peut créer des conflits ou rendre le code impossible à déboguer pas à pas).

*Les triggers de base de données exécutent le code en utilisant le fuseau horaire et la langue par défaut de la base de données, au lieu du fuseau horaire de référence de l'application (qui peut être différent), ce qui génère un décalage dans la base de données. De plus, la langue par défaut de l'application est également déconseillée.

*Il existe de nombreuses autres raisons pour lesquelles nous déconseillons l'utilisation des triggers de base de données dans vos développements.

L'utilisation de triggers de base de données peut certes vous faire gagner du temps lors du développement, mais constitue une très mauvaise pratique lorsque la qualité, la portabilité, la sécurité et la pérennité sont primordiales. C'est pourquoi elle est interdite, car elle est incompatible avec le haut niveau de qualité de code exigé par l'équipe Dolibarr. Les modules externes utilisant des déclencheurs de base de données peuvent également être refusés sur la plateforme, car ils ne fonctionneront pas pour plus de 50 % des utilisateurs.

==Règles de migration de base==

*Les scripts de migration de structure sont les fichiers de type '''install/mysql/migration/a.b.c-x.y.z.sql'''. Dans un fichier de migration de n vers n+1, on ne détruit une table (DROP TABLE) qui n'est plus utilisée en n+1 que lors de la migration de la version n+1 vers n+2. Ceci afin de toujours conserver les tables deprecated le temps d'une version pour réparer une situation en cas d'erreur de migration.

==Spécificités MySQL==

*Les tables doivent être au format InnoDB.

En effet, ce format gère les clés étrangères, les éventuelles restrictions qui y sont attachées et la notion d'intégrité de transactions requise pour avoir des données en base cohérente entre tables.

*Dolibarr DOIT fonctionner même avec les options '''strict''' de Mysql active.

Pour l'activer (fortement recommandé en développement), ajouter la ligne suivante dans le fichier config du serveur Mysql (my.cnf ou my.ini)
{{MySqlStrictMode}}

==Spécificités PostgreSQL==
Seuls les fichiers pour Mysql doivent être maintenus.
Les fichiers pour les autres bases sont convertis "à la volée" par le driver Dolibarr de la base.

Il existe une exception.
Les requêtes "UPDATE FROM" :
Syntax MySQL :
<syntaxhighlight lang="sql">
UPDATE table_taget as target, table_source as source SET fieldtarget=source.fieldsource
WHERE source.rowid=target.rowid;
</syntaxhighlight>

Syntax PgSQL:
<syntaxhighlight lang="sql">
UPDATE table_taget as target SET fieldtarget=source.fieldsource
FROM table_source as source WHERE source.rowid=target.rowid;
</syntaxhighlight>

Il n'en existe pas dans Dolibarr, mais pour vos modules Vous devriez faire tel que :
<syntaxhighlight lang="PHP">
if ($this->db->type=='pgsql') {
$sql="UPDATE table_taget as target SET fieldtarget=source.fieldsource
FROM table_source as source WHERE source.rowid=target.rowid";
} else {
$sql= "UPDATE table_taget as target, table_source as source SET fieldtarget=source.fieldsource
WHERE source.rowid=target.rowid";
}
</syntaxhighlight>

=Normes HTML=

*Tous les attributs dans les balises HTML doivent être *en minuscule* et quotés avec des *doubles quote*.

*Les liens href doivent être absolus en se basant sur la fonction dol_buildpath() obtenir un chemin absolu depuis un chemin relatif au répertoire htdocs (pour les modules externes) ou en utilisant DOL_URL_ROOT pour le code core. Pour les tags img, il faut faire appel à la fonction img_picto().

Par example:
<syntaxhighlight lang="PHP">
print '<a href="'.dol_buildpath('/monrep/mapage.php').'">'.img_picto('Texte alt','nompictopng','').'</a>';
print '<a href="'.DOL_URL_ROOT.'/repducore/pageducore.php">'.img_picto('Texte alt','nompictopng','').'</a>';
</syntaxhighlight>

*Les tables HTML doivent avoir des colonnes sans valeurs forcées, excepté pour les colonnes qui contiennent une information dont la longueur est non variable. Par exemple, une colonne avec un picto peut être forcée à with="20px". Dans les autres cas, il faut éviter de forcer la largeur des colonnes. La raison est que, dans la plupart des cas, le navigateur fait un meilleur travail pour définir automatiquement la bonne largeur des colonnes qu'en forçant manuellement les largeurs. Et ceci marche quelle que soit la résolution de l'écran.

*Le javascript/ajax et l'appel aux scripts java dans les pages php est à proscrire. Si toutefois du code javascript est inclus, il doit être conditionné par le test sur "$conf->use_javascript_ajax"

<syntaxhighlight lang="PHP">
if ($conf->use_javascript_ajax) {
... // Le code php qui génère du javascript est ici
}
</syntaxhighlight>

*Les popups windows ne doivent pas être utilisées, sauf pour des tooltips (et restent conditionnées par le point ci-dessus).

*Les scripts externes sont écrits en Perl s'ils ne peuvent l'être en php, l'utilisation d'un autre langage n'est pas interdit mais doit être discuté au préalable dans la mailing list des développeurs.

=Normes Dolibarr et squelettes de code=

==Squelettes de code==
Afin d'uniformiser le code et d'accélérer le développement de nouveaux composants dans Dolibarr, se trouvent dans le répertoire '''htdocs/modulebuilder/templates'''.

Par exemple:

*1 fichier qui sert d'exemple de descripteur de module: '''core/modules/myModule.class.php'''
*1 fichier qui sert d'exemple de code pour faire une nouvelle classe: '''class/skeleton_class.class.php'''
*1 fichier qui sert d'exemple de code pour faire une nouvelle page: '''skeleton_page.php'''
*1 fichier qui sert d'exemple de code pour faire un script à exécuter en ligne de commande: '''scripts/skeleton_script.php'''

...

Servez-vous en comme exemple.
Notons que ces squelettes sont aussi utilisés par le générateur de code PHP ([[Module ModuleBuilder]]) qui est décrit dans la chapitre de développement de module Dolibarr pour accélérer vos développements.

==Variables globales==
Certaines informations ou objets sont communs et fixes pour toute l'exécution d'une page PHP et doivent être utilisés presque partout dans le code. Pour éviter de propager partout ces
informations ou objets, ils sont stockés dans des variables globales auxquelles vous pouvez accéder partout. Ces variables globales sont initialisées au début de chaque appel PHP (dans le master.inc.php ou master.inc.php ou en haut de la page). Ces objets ne sont normalement instanciés qu’une seule fois. La liste des variables globales disponibles est définie ici :
{{Template:TemplateGlobalVariables}}

*$conf est l'objet qui contient la configuration (enregistrée dans la base de données)
*$user est l'objet de l'utilisateur actuel
*$mysoc est l'objet contenant toutes les informations sur l'entreprise actuelle
*$langs est l'objet avec la langue actuelle
*$db est le gestionnaire de base de données de la connexion actuelle à la base de données
*$hookmanager est une classe d'usine pour gérer les hooks
*$extrafields est une classe d'usine pour gérer les extrafields

==Les dates et TimeZone==
Dolibarr est une application multi-utilisateur et multi-site. Il est donc nécessaire de stocker les dates dans le format approprié. Pour éviter les problèmes de conversion, les règles suivantes doivent être appliquées :

* En mémoire, une date doit toujours être stockée au format Timestamp GMT.
* Une date stockée en base de données correspond au Timestamp GMT de la date soumise dans la requête, en utilisant le fuseau horaire du serveur PHP. Cela ne s'applique pas aux dates mises à jour automatiquement par le moteur de base de données (champs `tms` en base de données).

Par exemple, le 1er janvier 1970 à 3 heures à Paris (fuseau horaire +1) équivaut à 2 heures à Greenwich (fuseau horaire 0) ; la date sera stockée en mémoire sous la forme de l'entier 7200 (2 * 3600 s) et transmise à la base de données via une requête SQL sous la chaîne '19700101030000' (PHP convertit l'entier selon son fuseau horaire, et la base de données effectue la conversion inverse en utilisant également son propre fuseau horaire, identique à celui de PHP).

'''Gestion des dates incluant les heures'''

Ainsi, toutes les méthodes d'insertion ou de mise à jour doivent convertir, lors de la génération de la requête SQL, la date stockée en mémoire (sous forme d'entier) en une chaîne de caractères compatible avec la base de données, en utilisant `db->idate` (des exemples sont disponibles dans le squelette de code).

De même, toutes les méthodes de sélection doivent convertir les champs de date provenant de la base de données (chaînes au format du fuseau horaire du serveur, par exemple '19700101030000') en un champ timestamp (entier) en appelant la méthode `db->jdate()`. Cela permet de stocker la date en mémoire sous forme d'entier (Timestamp GMT).

'''Gestion des dates sans heures (jour uniquement)'''

Pour les insertions et mises à jour, vous devez effectuer la conversion avec `db->idate(valeur, 'gmt')` ; ainsi, pour la valeur 0, vous obtiendrez '19700101000000'.

Toutes les méthodes de sélection doivent convertir les champs de date provenant de la base de données (chaînes au format du fuseau horaire du serveur, par exemple '19700101000000') en utilisant `$db->jdate(..., 'gmt')`.

'''Autres cas'''

*Les dates mises à jour automatiquement (champ '''tms''' en base de données) contiennent un horodatage GMT correspondant au moment où la modification a été effectuée. La requête de sélection utilise également `db->jdate` (qui s'appuie sur le fuseau horaire du serveur PHP) pour convertir les données lues en un horodatage GMT en mémoire. Ainsi, si le fuseau horaire de la base de données diffère de celui du serveur PHP (par exemple, si l'un d'eux est mal configuré), vous pourriez constater des écarts entre la date de création et la date de mise à jour. Il est conseillé de ne pas se baser sur ce champ dans Dolibarr (ce champ à mise à jour automatique est principalement destiné au débogage).

*La manipulation des dates en PHP doit s'effectuer à l'aide des fonctions de date de Dolibarr : '''dol_now(), dol_mktime(), dol_stringtotime(), dol_getdate(), dol_time_plus_duree()'''. Vous trouverez également d'autres fonctions disponibles dans le fichier '''date.lib.php'''.

==L'encodage UTF8/ISO==
Dolibarr stocke les informations de manière suivante:

*En base de donnée, les données sont en UTF8 ou ISO. Cela dépend du pagecode de la base, donc des options à la création de cette base. Dans tous les cas le driver d'accès base Dolibarr (dans /lib/database) s'arrange à la lecture et insertion pour convertir vers et depuis de l'UTF8.
*Les données en mémoires sont donc stockées en UTF8 (instances d'objets PHP).
*Les pages web affichées à l'écran sont au format UTF8

==Les nombres réels, montants et calculs==
En PHP comme dans d'autres langages (Java par exemple), les données non entières (float, real, double) ne sont pas fiables.
Essayer de faire par exemple
<syntaxhighlight lang="PHP">
print 239.2 - 229.3 - 9.9;
</syntaxhighlight>
Vous n'obtiendrez pas zéro mais un nombre très petit en puissance de 10 négative. Si vous obtenez zéro, vous pourrez trouvez d'autres exemples qui ne fonctionnent pas.
Le problème des float est général, une variable résultante de calcul de nombre réels doit SYSTEMATIQUEMENT être nettoyée par la fonction '''price2num()''' avec le 2eme paramètre renseigné à: 'MU', 'MT' ou 'MS' selon le besoin (voir doc fonction).
<syntaxhighlight lang="PHP">
print price2num(239.2 - 229.3 - 9.9, 'MT');
</syntaxhighlight>
S'il ne s'agit pas d'un prix sur lequel s'adapte les paramètres MU, MT ou MS, il faut utiliser la fonction '''round()'''.

==Création de tables==
Ne pas créer de table à l'utilisation, c'est-à-dire à la '''première utilisation''' du module.
Si vous créez un module qui utilise des tables qui ne sont pas intégrées en standard dans le code de Dolibarr, veillez à suivre le didacticiel [[Développement module]] qui explique comment joindre des tables qui se créent à l'activation du module et non à son utilisation (voir plus haut).

==Comparer la version==

Si votre code a besoin de faire des choses différentes selon la version de Dolibarr, vous pouvez utiliser le truc suivant pour comparer les versions

<syntaxhighlight lang="PHP">
$version=preg_split('/[\.-]/',DOL_VERSION);
if (versioncompare($version,array(5,0,-4)) >= 0) { //mycode for 5.0 only; } // For dolibarr 5.0.* (the -4 means we include also alpha, beta, rc and rcX)
</syntaxhighlight>

Mais cette solution requiert de faire un include avoir la fonction versioncompare. Une alternative est d'utiliser le test suivant:
<syntaxhighlight lang="PHP">
if ((float) DOL_VERSION >= 5.0) { //mycode for 5.0 only; } // For dolibarr 5.0.*
</syntaxhighlight>

==Logs==
Ajouter des traces dans votre code avec la fonction
<syntaxhighlight lang="PHP">
dol_syslog($yourmessage, LOG_INFO|LOG_DEBUG|LOG_WARNING|LOG_ERR);
</syntaxhighlight>

==Répertoires de travail==
Si vous avez besoin de créer un répertoire de travail, dans votre code, faites référence à ce répertoire par
'''DOL_DATA_ROOT.'/monmodule''''

Le répertoire peut être créé dans votre code à l'exécution par le code suivant:
<syntaxhighlight lang="PHP">
$mymoduledir=DOL_DATA_ROOT.'/monmodule';
dol_mkdir($mymoduledir);
</syntaxhighlight>

Si vous avez besoin d'un répertoire qui contiendra des données temporaires, ce répertoire doit être''' DOL_DATA_ROOT.'/monmodule/temp''''

=Design patterns et programmation objet=

==Design patterns de Création (GoF)==
Design patterns définis par le Gang Of Four (voir la wikipédia sur les [[wikipedia:Patron de conception|Design patterns]]).
Dans Dolibarr, pas de mise en oeuvre de design patterns de comportement particulier.
On trouve des objets proches des Singletons et Fabriques conformes à 100% dans l'esprit mais pas dans la syntaxe, ceci afin d’être compatible avec la plus large plage possible de versions de PHP.

==Design patterns d'entreprises (Martin Fowler)==

===Mode d'organisation du code===
[[wikipedia:Martin_Fowler|Martin Fowler]] a identifié 3 méthodes d'organisation du code appelées '''patterns''' ('''motifs'''):

*Le '''Transaction Script''' (Le code est linéaire en fonction d'une action utilisateur).

C'est le motif à l'ancienne utilisé dans les langages procéduraux.

Inconvénient: Redondance du code. Nécessité de connaitre le modèle physique pour développer les parties métiers.

*Le '''Domain Model'''

C'est un concept possible depuis les langages objets. Ce sont les procédures métiers (qui doivent être identifiés avant) qui servent de bases pour les classes objets. C'est le modèle dit le plus "puriste".

Inconvénient : Motif plus complexe à maintenir.

*Le '''Table Module'''

Un intermédiaire entre les 2 précédents où l'on a une instance unique de classe par table de la base de données.

-> Comme le montre les squelettes de code (voir chapitre précédent Normes Dolibarr et squelettes de code), Dolibarr se base sur le principe du '''Table Module''', car le plus pragmatique des 3.

===Communication Logique métier - Données (ORM)===
Il existe 3 modes de liaisons:

*Le '''Table And Row Data Gateway'''

C'est le plus simple. On crée une classe par table et chaque classe est un pont avec la table correspondante et propose les méthodes CRUD sur cette table (Create, Read, Update, Delete). Une instance de classe étant alors un enregistrement de la table. La classe ne contient que du code d'accès aux lignes ou colonnes de tables. Le code métier doit alors être ajouté dans d'autres classes. Les liens entre ces classes tables et les classes métiers devant être connues ou déduites de la connaissance du développeur.

Exemple: C'est le mode mis en oeuvre quand on utilise certains Frameworks d'ORM comme '''iBatis''' (http://ibatis.apache.org/).

*Le '''Active Record'''

Identique au précédent, mais on se permet d'ajouter quelques fonctions métiers sur la classe, à condition que ces fonctions soient bien propres à la table ou à la notion métier portée par l'enregistrement. Jugé plus éloigné des standards scolaires de la programmation objet, c'est toutefois le pattern qui offre le meilleur rapport fonctionnalité/complexité.

Exemple: C'est le mode choisi pour les développements Dolibarr et de nombreuses autres applications PHP qui ont leur propre framework et pratiques de développement.

La couche ORM de Dolibarr se limite à une couche d abstraction de la base (on développe une fois et le driver de base converti le code pour l'accès base dans la syntaxe de la base de donnée: mysql vs postgresql vs ...)

*Le '''Data Mapper'''

Les classes représentent les entités du problème et non les données. Il faut donc doubler, tripler... ces classes avec des classes Mapper pour accéder aux données.
Plus "puriste" sur le papier car plus proche du métier, ce mode a aussi l'inconvénient d'être très complexe et difficile à maintenir dans la réalité (l'expérience pratique constatée ne rejoignant pas les promesses de la théorie).

Exemple: C'est le choix si on utilise des Framework d'ORM comme '''Propel''' (https://propelorm.org/). On le trouve donc sur des applications plus lourdes basées sur cet ORM entre autres.

-> Pour les développements Dolibarr, il est recommandé d'utiliser le mode de liaison '''Active Record''' qui offre les avantages d'un modèle proche du métier sans en avoir la complexité et sans trop masquer non plus la technique. C'est dans ce mode que le développement, la compréhension du code et la maintenance technique et/ou fonctionnelle semble la plus productive (ceci est toutefois un éternel débat entre les puristes et les pragmatiques, débat dans lequel personne ne peut vraiment avoir raison, car tout dépend des objectifs à atteindre).

==Design Pattern d'Interface Graphique (MVC)==
Il existe plusieurs design pattern pour les interfaces utilisateurs (MVC, MVP, MVVM).
Beaucoup confonde ce design pattern avec celui consistant à utiliser un framework de templates. C'est sans rapport. Un framework de templates (voir point précédent) n'est en lien qu'avec la partie "V" de ces modèles.

-> Dolibarr utilise le Design Pattern '''MVC''' (Model - Vue - Contrôleur). La partie M est matérialisée par une classe DAO contenant les méthode CRUD (Create-Read-Update-Delete) d'accès à la table.
Beaucoup de frameworks ont fait le choix de mettre la partie de code C (Contrôleur) et la partie de code du V (vue) dans des fichiers, voir même répertoires séparés. La maintenance semble plus aisé sur la papier, en pratique, il faut sans arrêt jongler entre n fichiers, le C étant fortement lié au V. Aussi dans Dolibarr, la séparation est faite par une simple section de commentaire. La partie de code C (Contrôleur) est donc le code qui se trouve sont la balise
<pre>
/*
* Actions
*/
</pre>
Elle est suivi par la partie de code V (Vue), bien séparé du C par la balise
<pre>
/*
* View
*/
</pre>

Ce mode de séparation a eu un effet neutre sur les nouveaux développement mais a permis de réduire de manière si importante le temps requis pour la maintenance et correction de bugs qu'il n'est pas envisagé de basculer vers un autre type de séparation (les constats faits dans la vraie vie ne sont pas toujours ceux attendus par la théorie scolaire). L'important reste qu'il y ait toujours séparation entre le C et le V pour être MVC, peu importe comment est matérialisée cette séparation, du moment qu'elle l'est (Rappel: Ne pas confondre la notion de séparation du C et du V qui relève du design pattern MVC avec la notion de séparation du code pour alimenter les données d'une Vue et du code pour formater la Vue, cette deuxième notion étant un principe de séparation relevant du Design Pattern de Vue, autrement appelé notion de templates, sans lien avec le MVC donc, voir point suivant).

==Design Pattern de Vue - Présentation==
Il existe des frameworks spécialisés dans le Design Pattern de Vue, la partie qui consiste à formater l'écran vue par l'utilisateur.
Les vieilles versions de Dolibarr utilisaient Smarty. Ce framework est une surcouche à un Framework, déjà très puissant, de formatage d'écran nommé... PHP. Les bénéfices étant très inférieurs aux inconvénients, il a été abandonné au profit de templates PHP (fichiers .php ou .tpl.php) qui restent, de tous les frameworks de présentation, le plus simple, plus universel, plus évolutif, plus performant et surtout plus résilient au temps.

Son seul défaut est qu'il ne peut garantir à 100% les écarts d'un développeur qui irait intégrer dans la Vue, une logique sans rapport avec la présentation (donc autre que du code à vocation de génération, de formatage, de sortie HTML, de logique de test ou de boucle pour le rendering écran). Ce point est toutefois contrôlé par le mécanisme de validation du code des chefs de projets.

La encore, c'est l'expérience et le constat "sur le terrain" d'un meilleur rendement de productivité, d'évolution applicative et de performance qui a motivé l'abandon des frameworks de Présentation externes au profit du framework PHP.

= Règles pour définir la branche cible d'une contribution =
Les règles pour décider si une contribution (Pull Request) doit être poussée dans une ancienne branche de maintenance ou dans une branche de développement ne sont pas strictes et sont souvent définies par le bon sens (pragmatisme avant tout).
Nous pouvons nous aider du diagramme de décision disponible sur cette page [[:Category:RoadMap#Merging_PR_process_.28develop_or_maintenance_.3F.29]]

Langages et normes

2026-09-20T16:34:01Z

Eldy: /* Les dates et TimeZone */

[[en:Language_and_development_rules]]
[[de:Sprachen_und_Programmierregeln]]
[[es:Lenguaje_y_Normas_de_Desarrollo]]
[[zh:语言和开发规则]]


{{TemplateDocDevFr}}

Voici les quelques règles sur le langage, la syntaxe et normes de développement en vigueur pour le projet Dolibarr :

=Versions=

*Dolibarr doit fonctionner sur:

#Tous OS (Windows, Linux, MACOS...)
#PHP {{PHPMinVersion}} (Doit fonctionner sans aucun module PHP complémentaire hors les modules d'accès base de donnée). Voir la page [[Versions|Liste des versions, journal des modifications et compatibilités]] pour les prérequis des versions plus anciennes.
#Mysql {{MySqlMinVersion}}

=Normes Copyright=

*Tout fichier PHP doit avoir un en-tête selon le masque suivant

<syntaxhighlight lang="PHP">
<?php
/* Copyright (C) YYYY John Doe <email@email.com>
*
* Licence information
*/
...
</syntaxhighlight>
Quand vous éditez un fichier existant du projet, ajouter une ligne Copyright sous celles existantes.

=Normes PHP=

==PHP==

*Dolibarr est écrit en PHP et supporte toutes versions PHP supérieures à la {{PHPMinVersion}}. Les fichiers doivent tous comporter l'extension .php

*L'appel aux variables superglobales PHP doit passer par les opérateurs dédiés $_COOKIE, $_SERVER, $_ENV. Mais pour récupérer les contenus de $_GET ou $_POST, il faut passer par les fonctions dolibarr [[Fonctions utiles Dolibarr|GETPOST...()]] .

Les autres opérateurs ($HTTP_SERVER_GET, ...) ayant été passés en deprecated au sein de PHP, ne doivent plus être utilisés. Ainsi le code doit fonctionner y compris quand l'option '''register_long_arrays''' est à off.
De plus, le code doit fonctionner aussi bien quand l'option PHP '''register_globals''' est à off (recommandé par PHP) que quand l'option '''register_globals''' est à on (par défaut sur de nombreuses installations).

*Pas d'utilisation de la variable '''PHP_SELF'''. Utiliser à la place $_SERVER["PHP_SELF"]. Notez aussi que le framework Dolibarr passe une routine pour rendre plus sûr le contenu du $_SERVER["PHP_SELF"] (dans le fichier main.inc.php, donc avant tout traitement métier)

*Quand plusieurs variables doivent être initialisées avec la même valeur, il faut utiliser plusieurs instructions:

<syntaxhighlight lang="PHP">
$var1 = 1; $var2 = 1; $var3 = 1;
</syntaxhighlight>
plutôt que
<syntaxhighlight lang="PHP">
$var1 = $var2 = $var3 = 1;
</syntaxhighlight>
qui est moins performant.

*Les chaines doivent avoir les variables sorties de la chaine.

<syntaxhighlight lang="PHP">
print "Mon texte affiche ma ".$variable." !\n";
</syntaxhighlight>

*Les commentaires doivent suivre la syntaxe C, ie un double antislash pour un commentaire d'une ligne et utilisation slash-étoile pour ouvrir un bloc de plusieurs lignes

<syntaxhighlight lang="PHP">
/* Bloc de commentaire
*
* Fin du bloc
*/

$monobjet = new MonObjet($db);
$result=$monobjet->fetch($idobject);

for ($i = 1 , $i < 2 ; $i++)
{
// commentaire sur une ligne
print $i;
}

</syntaxhighlight>

*Les fonctions doivent retourner une valeur strictement > à 0 en cas de succès, et un nombre < à 0 en cas d'erreur.

*Pas de code mort (non utilisé) dans le code principal de Dolibarr (le code utilisé uniquement par un module externe doit être inclus dans le module externe).

*Utiliser "include_once" ou "require_once" pour l'inclusion de tout fichier contenant des définitions de fonction ou de classes (donc fichiers *.class.php et *.lib.php), utiliser "include" pour tout inclusion de fichier de type template ou contenant un mixte de HTML et PHP (donc fichiers *.inc.php et *.tpl.php).

*Le style de code a utiliser est le PSR-12 (https://www.php-fig.org/psr/psr-12/). Seules les règles "MUST" sont imposées. Notez aussi les points/exceptions suivants:
**La longueur des lignes: PSR-12 indique que la longueur des lignes a une limite "soft" à 120. Il est en effet préférable d'avoir de longues lignes de données de déclaration plutôt que de longues pages car ce code ne contient aucune logique intéressante ou utile, toutefois une limite "hard" a été instauré à '''1000''' caractères. Du code qui ira au delà provoquera des erreurs dans la plateforme d'Intégration Continue.
**Les tabulations sont acceptées : L'autre exception est qu'on ne remplace pas les tabulations systématiquement par des espaces. L'utilisation des tabulations simplifie la vie de certains développeurs. De plus, l'utilisation d'espaces rend certaines fonctions d'autoformatage défectueuses (comme sur certaines versions d'Eclipse, lors de copier-coller).
**Note 1: Les règles suivantes sont particulièrement importantes :
***Les fichiers doivent être sauvés en format Unix (LF) et non Windows (CR/LF). Le format Unix étant compatible sur les OS Unix like, Windows, Mac, alors que le format fichier texte Windows pose problème sous certains PHP sous Unix.
***Les smart tags PHP ne sont pas utilisés. Les sections de code doivent commencer par '''<?php'''
**Note 2: Vous pouvez utiliser le fichier '''dev/setup/codesniffer/ruleset.xml''' comme fichier de contrôle pour vérifier votre style de code avec PHPCodeSniffer.
**Note 3: Vous pouvez utiliser le fichier '''dev/setup/eclipse/PSR-12 [built-in].xml''' comme fichier de règles de syntax pour configurer Eclipse.
**Note 4: Vous remarquerez que le code actuel ne suit pas forcément tout cela. La raison est historique. La règle fut instaurée en cours de route, aussi, si vous trouvez du code non respectueux de ce standard, n'hésitez pas à le corriger.

==Structures des classes et champs==

Certaines propriétés de classes se retrouvent dans de nombreuses classes. Pour homogénéité, on utilisera les noms suivants:
{{TemplatePHPFields}}

=Normes SQL=

==Structure et nom des tables et champs==

*Toutes les tables sont préfixées pour éviter les conflits de nommage. Aujourd'hui, le préfixe est modifiable au moment de l'installation. Sa valeur par défaut est <tt>llx_</tt>.

*Structure des tables.

Lorsque vous créez une table, il est recommandé de prendre les même conventions de nommages de tables que les autres tables Dolibarr. Avec, à minima les champs suivant:
- rowid INTEGER AUTO_INCREMENT PRIMARY KEY qui est l'id technique
- entity INTEGER default 1 that is id for the multicompany feature
- date_creation datetime that is the creation date
- tms timestamp qui sera un champ contenant la date de chaque mise à jour (la base de donnée le gère tout seul, pas besoin de le gérer par le code)
- import_key varchar(32) qui contiendra le code d'import YYYYMMDDHHMMSS si vous faites des imports en masse dans la table.
- status smallint pour stocker le status d'un object

Eventuellement
- fk_user_creat integer qui est l'id du user de création (fk_user_author also found)
- fk_user_modif integer qui est l'id du user de modification
- fk_user_valid integer qui est l'id du user de validation
- fk_soc integer qui est l'id du tiers (si applicable)

*Type des champs

Dans la pratique, afin d'être compatible avec toutes les précisions des pays, syntaxes des bases, on utilisera uniquement les types suivants:
- integer pour tout nombre entier, id ou clé étrangère (bigint éventuellement accepté pour les id des très grosses tables)
- smallint pour tout numérique entier de petite taille (comme pour stocker un code de status)
- double(24,8) pour tout montant
- double(6,3) pour les taux de tva
- real pour une quantité
- varchar pour une chaîne (y compris de longueur 1, le type char est de plus en plus déprécié)
- timestamp pour un champ date+heure devant être mis a jour automatiquement
- datetime pour un champ date+heure
- date pour un champ date

==Clé primaire==
La clé primaire d'une table s'appelle <tt>rowid</tt>.

Il y a quelques tables qui échappent à cette règle actuellement (ex [[Table llx_c_actioncomm]]), pour des raisons historiques. Une évolution pourra être étudiée pour une prochaine version.

==Clés étrangères==
Le nom d'une clé étrangère commence par le préfixe <tt>fk_</tt> suivi du nom de la table liée (requis pour éviter doublons globales à la base, problématiques sous certains SGBD comme postgresql) puis du champ lié (pour permettre plusieurs clés étrangères différentes sur une même table).

Exemple:
fk_facture_fourn_fk_soc

Note: Si vous développez votre propre module externe, il ne doit pas y avoir de clé étrangère depuis vos tables qui pointent sur les tables standards de Dolibarr. Ceci casserait les fonctionnalités de mise à jour, de réparation, de sauvegardes et de restauration et ces processus ne doivent pas dépendre de la présence d'un module externe. Il vous faut donc assurer l'intégrité de manière applicative si nécessaire.

==Clés alternatives==
Parfois, il n'y a pas que la clé primaire qui doit être unique. On peut donc ajouter aussi un index clé alternative unique. Un tel index est nommé par un nom qui commence par le préfixe <tt>uk_</tt> suivi du nom de la table (requis pour éviter doublons d'index globals à la base, problématiques sous certains SGBD comme postgresql) puis d'un suffixe qui caractérise la clé (pour permettre plusieurs index uniques sur une même table).

Exemple:
uk_societe_code_client

==Index performance==
Certains champs sont souvent utilisés comme critère de recherche, de tri ou de jointure. Il convient dans ce cas, d'y mettre un index de performance. De tels indexes seront nommés avec un préfix <tt>idx_</tt> puis le nom de la table et le nom du champ sur lequel porte l'index.

Exemple:
idx_societe_user_creat

==Format de fichier DDL==
Les fichiers qui contiennent la définition de la structure de la base (DDL) doivent être au nombre de 2 par tables:
Chaque table est définie dans son propre fichier dont le nom est <tt>llx_''matable''.sql</tt>.
On mettra un commentaire à côté de chaque champ pour en expliquer la signification.
Les clés étrangères et index de performance ou autres contraintes d'unicité sont définies dans un fichier séparé dont le nom est <tt>llx_''matable''.key.sql</tt>

Ces fichiers sont placés dans le répertoire '''install/mysql/tables''' pour les fichiers standards ou '''monmodule/tables''' pour les tables amenées par un module.

Exemple '''fichier table llx_matable.sql''':

<syntaxhighlight lang="sql">
-- ===========================================================================
-- Copyright (C) 2008 Author <email@author.com>
--
-- This program is free software; you can redistribute it and/or modify
-- it under the terms of the GNU General Public License as published by
-- the Free Software Foundation; either version 2 of the License, or
-- (at your option) any later version.
--
-- This program is distributed in the hope that it will be useful,
-- but WITHOUT ANY WARRANTY; without even the implied warranty of
-- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-- GNU General Public License for more details.
--
-- You should have received a copy of the GNU General Public License
-- along with this program. If not, see <http://www.gnu.org/licenses/>.
-- ===========================================================================

create table llx_matable
(
rowid integer AUTO_INCREMENT PRIMARY KEY,
field_one integer,
field_two integer NOT NULL,
fk_field integer,
field_date datetime,
tms timestamp
)ENGINE=innodb;
</syntaxhighlight>

Exemple '''fichier clés/index llx_matable.key.sql''':

<syntaxhighlight lang="sql">
-- ===========================================================================
-- Copyright (C) 2008 Author <email@author.com>
--
-- This program is free software; you can redistribute it and/or modify
-- it under the terms of the GNU General Public License as published by
-- the Free Software Foundation; either version 2 of the License, or
-- (at your option) any later version.
--
-- This program is distributed in the hope that it will be useful,
-- but WITHOUT ANY WARRANTY; without even the implied warranty of
-- MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
-- GNU General Public License for more details.
--
-- You should have received a copy of the GNU General Public License
-- along with this program. If not, see <http://www.gnu.org/licenses/>.
-- ===========================================================================

ALTER TABLE llx_matable ADD UNIQUE uk_matable_field(field_one, field_two);

ALTER TABLE llx_matable ADD CONSTRAINT fk_matable_fk_field FOREIGN KEY (fk_field) REFERENCES llx_matablepere (rowid);
</syntaxhighlight>

==Règles de codage SQL==

*Utilisation des alias/nommage de champs

Dans le cas des select on pourra utiliser les alias pour simplifier l'écriture des requêtes:
<syntaxhighlight lang="sql">
select chp1, chpxxx2 as chp2 from table2 as t1, table2 as t2 where t1.chpx = t2.chpy
</syntaxhighlight>
Toutefois, il ne faut pas utiliser ces alias sur des requêtes update car non compatible avec mysql 3.1.

*Les SELECT * sont interdits ! Chaque SELECT doit spécifier la liste complète des champs à récupérer. Cela permet d'éviter les confusions. Exemple:

<syntaxhighlight lang="sql">
SELECT field_a, field_b, field_c FROM table_1 WHERE field_d = '$id'
</syntaxhighlight>

*Dans les requêtes SQL, on quote les champs mais pas les numériques qui contiennent des montants destinés à être stockés dans des champs de type double ou real. Les quotes sur les numériques de type float provoquent parfois un stockage d'une valeur différente. Par exemple 412.62 dans le insert sera en fait stocké avec la valeur 412.61999512 en base (suite à des conversions chaines-numériques implicites) si le champ est de type double(24,8). Et seul le PHP voit 412.61999512. Les autres outils verront 412.62 donnant l'impression qu'il n'y a pas de problème. Et c'est le PHP qui a raison, il y a problème en base. En supprimant les quotes sur les numériques, cela va mieux.

Exemple:
<syntaxhighlight lang="sql">
Bon: INSERT INTO table_1 (field_txt, field_num) VALUES ('txt', 412.62)
Mauvais: INSERT INTO table_1 (field_txt, field_num) VALUES ('txt', '412.62')
</syntaxhighlight>

Remarque, le problème des float est général et pas seulement sur les accès base, il est présent dans tous les languages quand on travaille sur des nombres réels, aussi ils doivent être, dès que affectés, nettoyés par la fonction price2num avec le 2eme paramètre renseigné à:
'MU' (si il s'agit d'un prix unitaire), 'MT' (s'il s'agit d'un prix total) ou 'MS' (autres cas) selon le besoin.
Voir aussi le chapitre "Les nombres réels, montants et calculs" plus bas.

*Les fonctions SQL de date NOW, SYSDATE, DATEDIFF, DATE sont interdites au sein des ordres SQL. S'il faut saisir la date du moment dans un champ, la valeur doit venir du PHP, par exemple par la fonction dol_now(), et non du moteur de base de données. Ceci pour les raisons suivantes:
**afin d'avoir une meilleure portabilité du code
**avoir une gestion correcte des TimeZone et ne pas dépendre du TimeZone de la base de donnée (le timezone de réference est le timezone de PHP et le timezone de la base de données peut être différent de celui-ci, aussi les conversions de date doivent se faire toute côté PHP).
**meilleurs performances (voir exemples et commentaire plus loin)

Par exemple, on ne fera pas:
<syntaxhighlight lang="PHP">
$sql="SELECT rowid FROM table where datefield = NOW()";
</syntaxhighlight>
mais:
<syntaxhighlight lang="PHP">
$sql="SELECT rowid FROM table where datefield = '".$this->db->idate(dol_now())."'";
</syntaxhighlight>

Par exemple, on ne fera pas:
<syntaxhighlight lang="PHP">
$sql="SELECT rowid FROM table where DATEDIFF(table.datefield, NOW()) > 7";
</syntaxhighlight>
mais:
<syntaxhighlight lang="PHP">
$sql="SELECT rowid FROM table where datefield < '".$this->db->idate(dol_now() - (7 * 24 * 3600))."'";
</syntaxhighlight>

Un autre avantage de cette règle est que la requête peut bénéficier de l'utilisation de l'index puisqu'on compare datefield à une valeur fixe. Dans le cas du datediff, on applique un traitement sur le champ avant comparaison, rendant impossible l'utilisation de l'index de ce champ. Les conséquences sont des performances très dégradées par rapport à la version sans datediff.

*L'instruction WITH ROLLUP est interdite :

Cette instruction ne doit pas être utilisée : Elle n'est pas gérée de la même manière par des bases de données différentes.
De plus, l'utilisation de WITH ROLLUP brise la pureté des données retournées. L'agrégation intermédiaire de génération de sous-totaux réalisée par cette instruction peut facilement être effectuée à l'aide de PHP et permet de conserver le tableau de données retourné propre (non corrompu par des données insérées artificiellement).
Outres son côté pas bien standardisé, en insérant des résultats de calculs au sein des données, donnant un résultat qui est un mixe donnée et calculs métiers d'aggrégation, la compréhension du code se trouve compliqué et même les évolutions du code sur ces agrégations plus possibles lorsque se complexifient.

*Utilisez $db->ifsql pour le IF SQL

N'incluez pas le IF dans votre requête SQL générée. Mais utilisez plutôt la méthode $db->ifsql() pour créer un SQL IF compatible avec toutes les bases de données SQL.

*Pas de DELETE CASCADE et ON UPDATE CASCADE

De telles instructions SQL sont interdites car elles contournent les règles métiers de l'application. Par exemple, s'il existe une cascade de suppression entre la table A et B, lorsque l'application exécutera le code pour supprimer un enregistrement dans A, les enfants de la table B seront également supprimés. S'il y a eu un trigger Dolibarr PHP (par exemple apporté par un module externe) sur la suppression de l'enregistrement de B (par exemple pour valider la suppression ou pour exécuter une action complémentaire), la DELETE CASCADE sera exécutée sans avoir le trigger Dolibarr PHP exécuté, manquant la validation ou les actions du déclencheur PHP du module. Donc toutes les règles métiers doivent être implémentées du même côté (côté serveur PHP), c'est la raison pour laquelle les règles métier implémentées sur Database ne sont pas autorisées (même situation que le point suivant sur les triggers Database)

==Utilisation des triggers de base de données / procédures stockées==

L'utilisation des triggers de base de données n'est pas autorisée dans le code de Dolibarr. Vous ne devriez donc rencontrer aucun problème avec ces déclencheurs.

*Les triggers de base de données ne sont pas portables. La compatibilité peut être compromise lors de la mise à jour de votre base de données.

*Les triggers de base de données sont souvent oubliés dans les outils de sauvegarde.

*Les triggers de base de données nécessitent des autorisations spéciales que vous ne possédez peut-être pas (et que vous ne devriez pas posséder) sur une base de données sécurisée classique.

*L'utilisation de triggers de base de données implique également l'inclusion de certaines « règles métier » de votre application dans la base de données, alors que la plupart des autres règles sont gérées par le code lui-même (ce qui peut créer des conflits ou rendre le code impossible à déboguer pas à pas).

*Les triggers de base de données exécutent le code en utilisant le fuseau horaire et la langue par défaut de la base de données, au lieu du fuseau horaire de référence de l'application (qui peut être différent), ce qui génère un décalage dans la base de données. De plus, la langue par défaut de l'application est également déconseillée.

*Il existe de nombreuses autres raisons pour lesquelles nous déconseillons l'utilisation des triggers de base de données dans vos développements.

L'utilisation de triggers de base de données peut certes vous faire gagner du temps lors du développement, mais constitue une très mauvaise pratique lorsque la qualité, la portabilité, la sécurité et la pérennité sont primordiales. C'est pourquoi elle est interdite, car elle est incompatible avec le haut niveau de qualité de code exigé par l'équipe Dolibarr. Les modules externes utilisant des déclencheurs de base de données peuvent également être refusés sur la plateforme, car ils ne fonctionneront pas pour plus de 50 % des utilisateurs.

==Règles de migration de base==

*Les scripts de migration de structure sont les fichiers de type '''install/mysql/migration/a.b.c-x.y.z.sql'''. Dans un fichier de migration de n vers n+1, on ne détruit une table (DROP TABLE) qui n'est plus utilisée en n+1 que lors de la migration de la version n+1 vers n+2. Ceci afin de toujours conserver les tables deprecated le temps d'une version pour réparer une situation en cas d'erreur de migration.

==Spécificités MySQL==

*Les tables doivent être au format InnoDB.

En effet, ce format gère les clés étrangères, les éventuelles restrictions qui y sont attachées et la notion d'intégrité de transactions requise pour avoir des données en base cohérente entre tables.

*Dolibarr DOIT fonctionner même avec les options '''strict''' de Mysql active.

Pour l'activer (fortement recommandé en développement), ajouter la ligne suivante dans le fichier config du serveur Mysql (my.cnf ou my.ini)
{{MySqlStrictMode}}

==Spécificités PostgreSQL==
Seuls les fichiers pour Mysql doivent être maintenus.
Les fichiers pour les autres bases sont convertis "à la volée" par le driver Dolibarr de la base.

Il existe une exception.
Les requêtes "UPDATE FROM" :
Syntax MySQL :
<syntaxhighlight lang="sql">
UPDATE table_taget as target, table_source as source SET fieldtarget=source.fieldsource
WHERE source.rowid=target.rowid;
</syntaxhighlight>

Syntax PgSQL:
<syntaxhighlight lang="sql">
UPDATE table_taget as target SET fieldtarget=source.fieldsource
FROM table_source as source WHERE source.rowid=target.rowid;
</syntaxhighlight>

Il n'en existe pas dans Dolibarr, mais pour vos modules Vous devriez faire tel que :
<syntaxhighlight lang="PHP">
if ($this->db->type=='pgsql') {
$sql="UPDATE table_taget as target SET fieldtarget=source.fieldsource
FROM table_source as source WHERE source.rowid=target.rowid";
} else {
$sql= "UPDATE table_taget as target, table_source as source SET fieldtarget=source.fieldsource
WHERE source.rowid=target.rowid";
}
</syntaxhighlight>

=Normes HTML=

*Tous les attributs dans les balises HTML doivent être *en minuscule* et quotés avec des *doubles quote*.

*Les liens href doivent être absolus en se basant sur la fonction dol_buildpath() obtenir un chemin absolu depuis un chemin relatif au répertoire htdocs (pour les modules externes) ou en utilisant DOL_URL_ROOT pour le code core. Pour les tags img, il faut faire appel à la fonction img_picto().

Par example:
<syntaxhighlight lang="PHP">
print '<a href="'.dol_buildpath('/monrep/mapage.php').'">'.img_picto('Texte alt','nompictopng','').'</a>';
print '<a href="'.DOL_URL_ROOT.'/repducore/pageducore.php">'.img_picto('Texte alt','nompictopng','').'</a>';
</syntaxhighlight>

*Les tables HTML doivent avoir des colonnes sans valeurs forcées, excepté pour les colonnes qui contiennent une information dont la longueur est non variable. Par exemple, une colonne avec un picto peut être forcée à with="20px". Dans les autres cas, il faut éviter de forcer la largeur des colonnes. La raison est que, dans la plupart des cas, le navigateur fait un meilleur travail pour définir automatiquement la bonne largeur des colonnes qu'en forçant manuellement les largeurs. Et ceci marche quelle que soit la résolution de l'écran.

*Le javascript/ajax et l'appel aux scripts java dans les pages php est à proscrire. Si toutefois du code javascript est inclus, il doit être conditionné par le test sur "$conf->use_javascript_ajax"

<syntaxhighlight lang="PHP">
if ($conf->use_javascript_ajax) {
... // Le code php qui génère du javascript est ici
}
</syntaxhighlight>

*Les popups windows ne doivent pas être utilisées, sauf pour des tooltips (et restent conditionnées par le point ci-dessus).

*Les scripts externes sont écrits en Perl s'ils ne peuvent l'être en php, l'utilisation d'un autre langage n'est pas interdit mais doit être discuté au préalable dans la mailing list des développeurs.

=Normes Dolibarr et squelettes de code=

==Squelettes de code==
Afin d'uniformiser le code et d'accélérer le développement de nouveaux composants dans Dolibarr, se trouvent dans le répertoire '''htdocs/modulebuilder/templates'''.

Par exemple:

*1 fichier qui sert d'exemple de descripteur de module: '''core/modules/myModule.class.php'''
*1 fichier qui sert d'exemple de code pour faire une nouvelle classe: '''class/skeleton_class.class.php'''
*1 fichier qui sert d'exemple de code pour faire une nouvelle page: '''skeleton_page.php'''
*1 fichier qui sert d'exemple de code pour faire un script à exécuter en ligne de commande: '''scripts/skeleton_script.php'''

...

Servez-vous en comme exemple.
Notons que ces squelettes sont aussi utilisés par le générateur de code PHP ([[Module ModuleBuilder]]) qui est décrit dans la chapitre de développement de module Dolibarr pour accélérer vos développements.

==Variables globales==
Certaines informations ou objets sont communs et fixes pour toute l'exécution d'une page PHP et doivent être utilisés presque partout dans le code. Pour éviter de propager partout ces
informations ou objets, ils sont stockés dans des variables globales auxquelles vous pouvez accéder partout. Ces variables globales sont initialisées au début de chaque appel PHP (dans le master.inc.php ou master.inc.php ou en haut de la page). Ces objets ne sont normalement instanciés qu’une seule fois. La liste des variables globales disponibles est définie ici :
{{Template:TemplateGlobalVariables}}

*$conf est l'objet qui contient la configuration (enregistrée dans la base de données)
*$user est l'objet de l'utilisateur actuel
*$mysoc est l'objet contenant toutes les informations sur l'entreprise actuelle
*$langs est l'objet avec la langue actuelle
*$db est le gestionnaire de base de données de la connexion actuelle à la base de données
*$hookmanager est une classe d'usine pour gérer les hooks
*$extrafields est une classe d'usine pour gérer les extrafields

==Les dates et TimeZone==
Dolibarr est une application multi-utilisateur et multi-site. Il est donc nécessaire de stocker les dates dans le format approprié. Pour éviter les problèmes de conversion, les règles suivantes doivent être appliquées :

* En mémoire, une date doit toujours être stockée au format Timestamp GMT.
* Une date stockée en base de données correspond au Timestamp GMT de la date soumise dans la requête, en utilisant le fuseau horaire du serveur PHP. Cela ne s'applique pas aux dates mises à jour automatiquement par le moteur de base de données (champs `tms` en base de données).

Par exemple, le 1er janvier 1970 à 3 heures à Paris (fuseau horaire +1) équivaut à 2 heures à Greenwich (fuseau horaire 0) ; la date sera stockée en mémoire sous la forme de l'entier 7200 (2 * 3600 s) et transmise à la base de données via une requête SQL sous la chaîne '19700101030000' (PHP convertit l'entier selon son fuseau horaire, et la base de données effectue la conversion inverse en utilisant également son propre fuseau horaire, identique à celui de PHP).

'''Gestion des dates incluant les heures :'''

Ainsi, toutes les méthodes d'insertion ou de mise à jour doivent convertir, lors de la génération de la requête SQL, la date stockée en mémoire (sous forme d'entier) en une chaîne de caractères compatible avec la base de données, en utilisant `db->idate` (des exemples sont disponibles dans le squelette de code).

De même, toutes les méthodes de sélection doivent convertir les champs de date provenant de la base de données (chaînes au format du fuseau horaire du serveur, par exemple '19700101030000') en un champ timestamp (entier) en appelant la méthode `db->jdate()`. Cela permet de stocker la date en mémoire sous forme d'entier (Timestamp GMT).

'''Gestion des dates sans heures (jour uniquement) :'''

Pour les insertions et mises à jour, vous devez effectuer la conversion avec `db->idate(valeur, 'gmt')` ; ainsi, pour la valeur 0, vous obtiendrez '19700101000000'.

Toutes les méthodes de sélection doivent convertir les champs de date provenant de la base de données (chaînes au format du fuseau horaire du serveur, par exemple '19700101000000') en utilisant `$db->jdate(..., 'gmt')`.

'''Autres cas'''

*Les dates mises à jour automatiquement (champ '''tms''' en base de données) contiennent un horodatage GMT correspondant au moment où la modification a été effectuée. La requête de sélection utilise également `db->jdate` (qui s'appuie sur le fuseau horaire du serveur PHP) pour convertir les données lues en un horodatage GMT en mémoire. Ainsi, si le fuseau horaire de la base de données diffère de celui du serveur PHP (par exemple, si l'un d'eux est mal configuré), vous pourriez constater des écarts entre la date de création et la date de mise à jour. Il est conseillé de ne pas se baser sur ce champ dans Dolibarr (ce champ à mise à jour automatique est principalement destiné au débogage).

*La manipulation des dates en PHP doit s'effectuer à l'aide des fonctions de date de Dolibarr : '''dol_now(), dol_mktime(), dol_stringtotime(), dol_getdate(), dol_time_plus_duree()'''. Vous trouverez également d'autres fonctions disponibles dans le fichier '''date.lib.php'''.

==L'encodage UTF8/ISO==
Dolibarr stocke les informations de manière suivante:

*En base de donnée, les données sont en UTF8 ou ISO. Cela dépend du pagecode de la base, donc des options à la création de cette base. Dans tous les cas le driver d'accès base Dolibarr (dans /lib/database) s'arrange à la lecture et insertion pour convertir vers et depuis de l'UTF8.
*Les données en mémoires sont donc stockées en UTF8 (instances d'objets PHP).
*Les pages web affichées à l'écran sont au format UTF8

==Les nombres réels, montants et calculs==
En PHP comme dans d'autres langages (Java par exemple), les données non entières (float, real, double) ne sont pas fiables.
Essayer de faire par exemple
<syntaxhighlight lang="PHP">
print 239.2 - 229.3 - 9.9;
</syntaxhighlight>
Vous n'obtiendrez pas zéro mais un nombre très petit en puissance de 10 négative. Si vous obtenez zéro, vous pourrez trouvez d'autres exemples qui ne fonctionnent pas.
Le problème des float est général, une variable résultante de calcul de nombre réels doit SYSTEMATIQUEMENT être nettoyée par la fonction '''price2num()''' avec le 2eme paramètre renseigné à: 'MU', 'MT' ou 'MS' selon le besoin (voir doc fonction).
<syntaxhighlight lang="PHP">
print price2num(239.2 - 229.3 - 9.9, 'MT');
</syntaxhighlight>
S'il ne s'agit pas d'un prix sur lequel s'adapte les paramètres MU, MT ou MS, il faut utiliser la fonction '''round()'''.

==Création de tables==
Ne pas créer de table à l'utilisation, c'est-à-dire à la '''première utilisation''' du module.
Si vous créez un module qui utilise des tables qui ne sont pas intégrées en standard dans le code de Dolibarr, veillez à suivre le didacticiel [[Développement module]] qui explique comment joindre des tables qui se créent à l'activation du module et non à son utilisation (voir plus haut).

==Comparer la version==

Si votre code a besoin de faire des choses différentes selon la version de Dolibarr, vous pouvez utiliser le truc suivant pour comparer les versions

<syntaxhighlight lang="PHP">
$version=preg_split('/[\.-]/',DOL_VERSION);
if (versioncompare($version,array(5,0,-4)) >= 0) { //mycode for 5.0 only; } // For dolibarr 5.0.* (the -4 means we include also alpha, beta, rc and rcX)
</syntaxhighlight>

Mais cette solution requiert de faire un include avoir la fonction versioncompare. Une alternative est d'utiliser le test suivant:
<syntaxhighlight lang="PHP">
if ((float) DOL_VERSION >= 5.0) { //mycode for 5.0 only; } // For dolibarr 5.0.*
</syntaxhighlight>

==Logs==
Ajouter des traces dans votre code avec la fonction
<syntaxhighlight lang="PHP">
dol_syslog($yourmessage, LOG_INFO|LOG_DEBUG|LOG_WARNING|LOG_ERR);
</syntaxhighlight>

==Répertoires de travail==
Si vous avez besoin de créer un répertoire de travail, dans votre code, faites référence à ce répertoire par
'''DOL_DATA_ROOT.'/monmodule''''

Le répertoire peut être créé dans votre code à l'exécution par le code suivant:
<syntaxhighlight lang="PHP">
$mymoduledir=DOL_DATA_ROOT.'/monmodule';
dol_mkdir($mymoduledir);
</syntaxhighlight>

Si vous avez besoin d'un répertoire qui contiendra des données temporaires, ce répertoire doit être''' DOL_DATA_ROOT.'/monmodule/temp''''

=Design patterns et programmation objet=

==Design patterns de Création (GoF)==
Design patterns définis par le Gang Of Four (voir la wikipédia sur les [[wikipedia:Patron de conception|Design patterns]]).
Dans Dolibarr, pas de mise en oeuvre de design patterns de comportement particulier.
On trouve des objets proches des Singletons et Fabriques conformes à 100% dans l'esprit mais pas dans la syntaxe, ceci afin d’être compatible avec la plus large plage possible de versions de PHP.

==Design patterns d'entreprises (Martin Fowler)==

===Mode d'organisation du code===
[[wikipedia:Martin_Fowler|Martin Fowler]] a identifié 3 méthodes d'organisation du code appelées '''patterns''' ('''motifs'''):

*Le '''Transaction Script''' (Le code est linéaire en fonction d'une action utilisateur).

C'est le motif à l'ancienne utilisé dans les langages procéduraux.

Inconvénient: Redondance du code. Nécessité de connaitre le modèle physique pour développer les parties métiers.

*Le '''Domain Model'''

C'est un concept possible depuis les langages objets. Ce sont les procédures métiers (qui doivent être identifiés avant) qui servent de bases pour les classes objets. C'est le modèle dit le plus "puriste".

Inconvénient : Motif plus complexe à maintenir.

*Le '''Table Module'''

Un intermédiaire entre les 2 précédents où l'on a une instance unique de classe par table de la base de données.

-> Comme le montre les squelettes de code (voir chapitre précédent Normes Dolibarr et squelettes de code), Dolibarr se base sur le principe du '''Table Module''', car le plus pragmatique des 3.

===Communication Logique métier - Données (ORM)===
Il existe 3 modes de liaisons:

*Le '''Table And Row Data Gateway'''

C'est le plus simple. On crée une classe par table et chaque classe est un pont avec la table correspondante et propose les méthodes CRUD sur cette table (Create, Read, Update, Delete). Une instance de classe étant alors un enregistrement de la table. La classe ne contient que du code d'accès aux lignes ou colonnes de tables. Le code métier doit alors être ajouté dans d'autres classes. Les liens entre ces classes tables et les classes métiers devant être connues ou déduites de la connaissance du développeur.

Exemple: C'est le mode mis en oeuvre quand on utilise certains Frameworks d'ORM comme '''iBatis''' (http://ibatis.apache.org/).

*Le '''Active Record'''

Identique au précédent, mais on se permet d'ajouter quelques fonctions métiers sur la classe, à condition que ces fonctions soient bien propres à la table ou à la notion métier portée par l'enregistrement. Jugé plus éloigné des standards scolaires de la programmation objet, c'est toutefois le pattern qui offre le meilleur rapport fonctionnalité/complexité.

Exemple: C'est le mode choisi pour les développements Dolibarr et de nombreuses autres applications PHP qui ont leur propre framework et pratiques de développement.

La couche ORM de Dolibarr se limite à une couche d abstraction de la base (on développe une fois et le driver de base converti le code pour l'accès base dans la syntaxe de la base de donnée: mysql vs postgresql vs ...)

*Le '''Data Mapper'''

Les classes représentent les entités du problème et non les données. Il faut donc doubler, tripler... ces classes avec des classes Mapper pour accéder aux données.
Plus "puriste" sur le papier car plus proche du métier, ce mode a aussi l'inconvénient d'être très complexe et difficile à maintenir dans la réalité (l'expérience pratique constatée ne rejoignant pas les promesses de la théorie).

Exemple: C'est le choix si on utilise des Framework d'ORM comme '''Propel''' (https://propelorm.org/). On le trouve donc sur des applications plus lourdes basées sur cet ORM entre autres.

-> Pour les développements Dolibarr, il est recommandé d'utiliser le mode de liaison '''Active Record''' qui offre les avantages d'un modèle proche du métier sans en avoir la complexité et sans trop masquer non plus la technique. C'est dans ce mode que le développement, la compréhension du code et la maintenance technique et/ou fonctionnelle semble la plus productive (ceci est toutefois un éternel débat entre les puristes et les pragmatiques, débat dans lequel personne ne peut vraiment avoir raison, car tout dépend des objectifs à atteindre).

==Design Pattern d'Interface Graphique (MVC)==
Il existe plusieurs design pattern pour les interfaces utilisateurs (MVC, MVP, MVVM).
Beaucoup confonde ce design pattern avec celui consistant à utiliser un framework de templates. C'est sans rapport. Un framework de templates (voir point précédent) n'est en lien qu'avec la partie "V" de ces modèles.

-> Dolibarr utilise le Design Pattern '''MVC''' (Model - Vue - Contrôleur). La partie M est matérialisée par une classe DAO contenant les méthode CRUD (Create-Read-Update-Delete) d'accès à la table.
Beaucoup de frameworks ont fait le choix de mettre la partie de code C (Contrôleur) et la partie de code du V (vue) dans des fichiers, voir même répertoires séparés. La maintenance semble plus aisé sur la papier, en pratique, il faut sans arrêt jongler entre n fichiers, le C étant fortement lié au V. Aussi dans Dolibarr, la séparation est faite par une simple section de commentaire. La partie de code C (Contrôleur) est donc le code qui se trouve sont la balise
<pre>
/*
* Actions
*/
</pre>
Elle est suivi par la partie de code V (Vue), bien séparé du C par la balise
<pre>
/*
* View
*/
</pre>

Ce mode de séparation a eu un effet neutre sur les nouveaux développement mais a permis de réduire de manière si importante le temps requis pour la maintenance et correction de bugs qu'il n'est pas envisagé de basculer vers un autre type de séparation (les constats faits dans la vraie vie ne sont pas toujours ceux attendus par la théorie scolaire). L'important reste qu'il y ait toujours séparation entre le C et le V pour être MVC, peu importe comment est matérialisée cette séparation, du moment qu'elle l'est (Rappel: Ne pas confondre la notion de séparation du C et du V qui relève du design pattern MVC avec la notion de séparation du code pour alimenter les données d'une Vue et du code pour formater la Vue, cette deuxième notion étant un principe de séparation relevant du Design Pattern de Vue, autrement appelé notion de templates, sans lien avec le MVC donc, voir point suivant).

==Design Pattern de Vue - Présentation==
Il existe des frameworks spécialisés dans le Design Pattern de Vue, la partie qui consiste à formater l'écran vue par l'utilisateur.
Les vieilles versions de Dolibarr utilisaient Smarty. Ce framework est une surcouche à un Framework, déjà très puissant, de formatage d'écran nommé... PHP. Les bénéfices étant très inférieurs aux inconvénients, il a été abandonné au profit de templates PHP (fichiers .php ou .tpl.php) qui restent, de tous les frameworks de présentation, le plus simple, plus universel, plus évolutif, plus performant et surtout plus résilient au temps.

Son seul défaut est qu'il ne peut garantir à 100% les écarts d'un développeur qui irait intégrer dans la Vue, une logique sans rapport avec la présentation (donc autre que du code à vocation de génération, de formatage, de sortie HTML, de logique de test ou de boucle pour le rendering écran). Ce point est toutefois contrôlé par le mécanisme de validation du code des chefs de projets.

La encore, c'est l'expérience et le constat "sur le terrain" d'un meilleur rendement de productivité, d'évolution applicative et de performance qui a motivé l'abandon des frameworks de Présentation externes au profit du framework PHP.

= Règles pour définir la branche cible d'une contribution =
Les règles pour décider si une contribution (Pull Request) doit être poussée dans une ancienne branche de maintenance ou dans une branche de développement ne sont pas strictes et sont souvent définies par le bon sens (pragmatisme avant tout).
Nous pouvons nous aider du diagramme de décision disponible sur cette page [[:Category:RoadMap#Merging_PR_process_.28develop_or_maintenance_.3F.29]]