With the changeover from v13 to v14, there was also a major adjustment to the logic for determining invoice numbers in Odoo.
Previously, a sequence was used to determine which invoice number should be applied to a particular journal, but with the solution now in place, the user is free to make adjustments even without technical background knowledge regarding sequences.
The first commit on this topic can be found here: https://github.com/odoo/odoo/commit/dfd01b8c5c7e1177f37bf199790a0732a61eed78
The changeover has not been well received everywhere, and there have already been lively discussions on Twitter: https://twitter.com/fpodoo/status/1344236334588821510
In the following article, we would like to discuss what needs to be taken into account when configuring invoice ranges and how to find the optimal configuration for the respective use case, taking into account that the respective number range will continue to function over a year jump.
Basic settings
First, the journal must be configured correctly. To do this, go to the Finance app and open the configuration of the journal "Outgoing invoices".
There are 2 things to configure in the window that opens:
- The "Fixed credit note sequence" field: Set this if credit notes are to be managed in their own number range. If you want to use the same number range for outgoing invoices and outgoing credit notes, deactivate this function.
- The field "Abbreviation": The first invoice created by Odoo will contain this abbreviation as a prefix for the invoice number (which can, however, be overwritten later).
With this default configuration set, Odoo would now assign the following invoice numbers when creating an invoice for the first time:
- for outgoing invoices: RGN/YEAR/00001
- for outgoing credits RRGN/YEAR/00001 (it is additionally prefixed with the letter "R").
For many applications, this configuration is already sufficient. If an adjustment is necessary, or you want to "enter" e.g. during the year from a certain invoice number, this must be done when creating the first invoice number. As soon as the first invoice is created, Odoo proposes the first invoice number by default, which can be changed by the user:
However, there are a few things to keep in mind, as we will explain in the next step.
To consider
When recognising the invoice number range, Odoo relies on so-called "regex" codes, which evaluate the invoice number transferred to Odoo and try to recognise which part of the invoice number contains the year, for example, on the basis of certain properties.
Odoo checks the invoice number as of 02.02.2022 with the following regex expressions:
- Regex for recognising invoice numbers that contain the year: ^(?P<prefix1>.*?)(?P<year>\d{4})(?P<prefix2>\D+?)(?P<seq>\d*)(?P<suffix>\D*?)$
- Regex for recognising invoice numbers that contain the year and month: ^(?P<prefix1>.*?)(?P<year>\d{4})(?P<prefix2>\D*?)(?P<month>\d{2})(?P<prefix3>\D+?)(?P<seq>\d*)(?P<suffix>\D*?)$
- Regex for recognising invoice numbers without year and month: ^(?P<prefix1>.*?)(?P<seq>\d*)(?P<suffix>\D*?)$
These expressions seem quite complex at first, but are quite easy to check with various free online tools, we recommend here e.g. the following tool: https://pythex.org/
Simply copy the regex you want into the top field of the tool and enter one of your invoice numbers as a "test string" to check whether Odoo can correctly divide the invoice number into its individual components. The invoice number range will only be recognised correctly if a corresponding separation is also possible according to the tool.
Here are a few examples of number ranges that cannot currently be mapped in Odoo (in the standard system) (or consequently do not lead to an automatic change in the case of a period jump):
- 202200001: here the year would be passed directly followed by a consecutive number. However, Odoo cannot recognise the year because it needs a separator between the year and the number.
- 2022/4/0001 (where 4 should stand for a branch number, for example): Here Odoo does not recognise the number 4 as a branch number but as a month.
- 2022/F4/0001 (where F4 should stand for a branch number, for example): Prefixes between year and sequence must not contain numbers (in contrast, e.g. F4/2022/0001 would be allowed, as the first prefix may contain numbers).e.g. should stand for a branch number): Here Odoo does not recognise the number 4 as a branch number but as a month.
- 22/00001 (where 22 stands for the current year): The year passed to Odoo must have 4 digits according to the regex expression, otherwise it will not be recognised accordingly.
Additional technical note: In principle, the journal would provide a setting option to define additional, more complex invoice number ranges; for this purpose, there is a reference to the field "sequence_override_regex" in the source code. However, a setting via the user interface is not possible in the Odoo standard as of 02.02.2022 .
Renumbering invoices
As of v14, it is also possible in Odoo to renumber invoices if this has not been blocked in the journal settings (which is clearly recommended for productive environments).
To do this, the developer mode must be activated and the corresponding invoices must be marked in the overview. Via the button "Action" => "Resequence" new invoice numbers can now be assigned.
However, the following should be noted here:
- Of course, a rearrangement of the invoice numbers is only permissible if this is also legally possible.
- of course, a A change in the prefix can lead to undesired behaviour. For example: suppose there are invoices INV/2019/0001 and INV/2019/0002 and the last invoice is renamed FACT/2019/0001, then the expectation would be that the next invoice would be named FACT/2019/0002. However, this is not the case, as the letter I (of INV) is ranked after the letter F (of FACT) and Odoo recognises the invoice INV/2019/0001 as the last invoice.
Note: There are a number of third-party modules that restore the original behaviour (familiar from Odoo 13). Due to the profound intervention in the system, we would not recommend this procedure - even if the old behaviour was partially solved in a clearer way from our point of view.
Do you have problems with the correct configuration of your billing circuits? Our team will be happy to help you!
