Tuesday, July 18, 2023
4 changes · master
Resolved issues and error corrections
The Peruvian reporting tests now include a required partner identification type. This prevents test failures when assigning invoice document types and helps keep local compliance checks reliable.
Original PR description
The identification type field is required in the view, and now is send in the test. With this avoid error on document type assignation on the tests, because only if the document type in the partner id 6 (RUC) could be used the invoice document type.
This fixes automated checks after a related change altered the order in which price lists are handled. It helps ensure subscription and rental sales flows continue to be validated correctly without changing customer-facing behavior.
Original PR description
Fixes tests invalidated by: https://github.com/odoo/odoo/pull/121441 PR changes the pricelists order opw-3282880
This update improves the performance of document signing workflows by making status-based searches faster. Users should see smoother filtering and signature request handling, especially when many signing records exist.
Original PR description
Add missing index on `state` of `sign.request` and `state` of `sign.request.item` used in: - `_compute_is_sharing` - search view filters - `_search_need_my_signature` - `get_document_qweb_context` task-3420528
The Belgian Partner VAT Listing now calculates which partners must appear before applying any user-defined grouping. This prevents incorrect reported amounts when businesses customize the report, and it should also make the report run more efficiently.
Original PR description
The Partner VAT Listing uses a custom engine, meaning that it is possible for the user to customize its line in order to do the grouping differently, and for example have a group by account on top of…
The Partner VAT Listing uses a custom engine, meaning that it is possible for the user to customize its line in order to do the grouping differently, and for example have a group by account on top of the default group by partner. However, due to legal requirements, this report already "injected" a groupby in the SQL ran for its computation, so that we did not report partners not reaching the "turnover" untaxed value of 250 EUR (or another of the special criteria about credit notes). This completely broke custom grouping, as the turnover got computed on the new groups (so, not only "group by partner_id", but "group by account_id,partner_id", for example). The numbers reported in this case were hence completely wrong. With this commit, we rewrite the queries ran by the report so that the partners meeting the appearance criteria (like the turnover) are computed beforehand and the custom groupby can work as usual. Thanks to that, this refactoring also improves the overall performance of the report in the meantime.