1) In tax groups repartition lines are not used, however when creating
tax groups from templates the default repartition lines are created.
If you run the chart update again, it will detect those "useless"
default repartition lines and mark them to removal, raising an
error when trying to do so as a minial of 2 repartition lines are
needed (on base and one tax).
2) When matching taxes, if not match, do not add `False` to the list.
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
Steps to reproduce the problem:
- User (Not accountant) create an invoice.
- Create invoice plan with Deposit on 1st Invoice
- Confirm Order > Register Deposit > Create and View bills
- It throws a permission error
That's because the search on asset lines is done always for each write on the account.move
if certain fields (like the date) are written.
inv5 YYYYMM20 posted
INV4 YYYYMM15 posted
INV3 YYYYMM10 posted
INV2 YYYYMM05 posted
INV1 YYYYMM01 posted
if we pass INV3 to draft and change the date to YYYYYMM15 or YYYYYMM05 it should be able to validate, but if we change the date higher than YYYYYMM15 or lower than YYYYYMM05 it should not be able to validate.
