Under some weird scenarios where some modules are involved, several invoices are posted at the same time, and no invoice exists, we could get to the case when `one.date` or `one.name` were `False`.
Here I provide a default value to avoid comparing `str` to `bool` in those cases.
Tried a lot but couldn't reproduce the test case in code, sorry 😕. However, the traceback was clear:
```
File "/opt/odoo/auto/addons/account_journal_general_sequence/models/account_move.py", line 64, in _compute_entry_number
for move in chosen.sorted(lambda one: (one.date, one.name, one.id)):
File "/opt/odoo/custom/src/odoo/odoo/models.py", line 5583, in sorted
ids = tuple(item.id for item in sorted(self, key=key, reverse=reverse))
TypeError: '<' not supported between instances of 'str' and 'bool'
```
@moduon MT-5559
Instead of defining the new sequence as a field default, it is now a compute. This is because the sequence depends on the company, but we don't have the `company_id` field until the record is created.
Reduced the default number of padded zeroes to 8. This is a product decision.
The original implementation didn't make much sense because it allowed the user to set a different sequence per journal, but Odoo already has that kind of sequence. The only purpose of this module is to have a sequence *per company*. To avoid breaking too much, for now, when the journal sequence is the default one, we set it as readonly.
Limit the available sequences in the renumbering wizard. Display only those that you have access by your selected context companies. For some reason, Odoo doesn't filter sequences by company automatically.
@moduon MT-3076
Co-authored-by: Andrea Cattalani <22261939+anddago78@users.noreply.github.com>
When calling `_next()` in a sequence, it issues calls to `search()`, especially if it is a no-gap or date-range-based sequence (which is common in this use case).
When doing a search, Odoo triggers recomputations. Thus, when doing both a write and a call to `_next()` in the same loop, Odoo had to flush to DB too often, causing a bottleneck.
Now, the process is more optimized:
1. Cache all new entry numbers.
2. Write them all.
3. Mark them all as modified at once, to batch-trigger recomputations.
To reduce the amount of recomputations, tracking is disabled for the entry number. After all, before renumbering there's already a warning telling you that you shouldn't renumber if you already published those entry numbers to your fiscal authority.
Another pseudo-improvement is that the info log is shorter. Enable debug logging to log the list of IDs changed.
A test was failing because it was relying on the fact that computations were not getting as lazy as they should. Manual flushes are added to imitate a user doing different invoice creations.
@moduon MT-3082
On databases with big amounts of account moves, installation would freeze Odoo for some minutes.
We skip now entry number computation at install, to avoid such cases.
@moduon MT-676
Under some legislations, account moves must follow a single sequence. Since Odoo removed this sequence number in recent versions, this information was lost.
With this module, you can force your account moves to follow a separate sequence. The sequence is automatic when a move is posted. Includes a wizard to reorder those numbers in the sequence.
@moduon MT-676
