Friday, February 6, 2026
8 changes · 19.0
Resolved issues and error corrections
This update fixes an issue where Odoo didn't correctly reconcile bank transactions with credit notes. Now, when a credit note is applied to an invoice and the bank transaction is marked as 'fully paid', the system accurately reflects the remaining balance owed. This ensures accurate financial reporting.
Original PR description
1. Create an invoice for $1,000 2. Create a credit note of $200 and apply it to the invoice. The invoice is marked 'partially paid.' The remaining due is $800. 3. Create a bank transaction of $700, reconcile with the invoice. 4. Edit the counterpart line, and click "fully paid". >>> Odoo does not consider the credit note and uses the full amount of $1,000 instead of the remaining due of $800 to reconcile. With the refactor of the bank rec, the way the amount is show is computed from econciled_lines_excluding_exchange_diff_ids in apply_amount.js which only takes into account the direct invoice and not the credit notes (in _compute_reconciled_lines_excluding_exchange_diff_ids it take the matched debit and matched credit so only the partial between the transaction and the move) opw-5485663 Forward-Port-Of: odoo/enterprise#105197
This update resolves an issue where users with specific access rights were incorrectly identified as administrators, causing errors when accessing the AI Documents app. A stricter access check has been implemented to ensure proper functionality for users with 'User' roles, specifically allowing them to use the 'Sort with AI' feature.
Original PR description
Before this commit: If a user with the role 'User' has access to 'Access rights', it puts the user in `base.group_erp_manager` making `is_admin()` return `True`. Resulting in an access error when opening the documents app. After this commit: A more strict check is added for accessing ai_documents fields. Task-5375110 parent support ticket-5270005
This update corrects a previous error in the MRP Workorder module that prevented the automatic generation of serial numbers when production quantities were specified. The fix ensures that necessary serials are created, aligning with the desired workflow and avoiding disruptions to the manufacturing process. This change improves the reliability of production order fulfillment.
Original PR description
This commit update the test since the fix commit introduced a new behavior. Before if the manufacturing had qty_producing, it would not set the move to picked and raise an error because there is no lot. With the fix, when the production has qty_producing. It will generate the missing serial. We prefer this behavior to the old ones so we keep it.
This update fixes an issue where draft and cancelled accounting entries were incorrectly included in tax return calculations, leading to inaccurate tax return amounts. Now, tax returns accurately reflect the values in reports by excluding entries in draft or cancelled states, ensuring data integrity.
Original PR description
Behavior before: When generating tax returns, accounting entries linked to tax group accounts were included in the calculation even if they were in draft or cancelled state. As a result, tax returns displayed incorrect amounts. Behavior after: Tax return amounts now correctly match the values shown in the corresponding reports. Entries in draft or cancelled state are excluded, eliminating discrepancies in tax return calculations. Root cause: The domain used in the _add_line method did not filter entries based on their parent_state. This caused all related accounting entries—regardless of their posting status—to be included in the calculation. Steps to reproduce: 1. Create accounting entries using an account that is part of a tax group. 2. Set the entries to draft or cancelled state. 3. Generate a tax return for the current period. 4. Observe that amounts from draft or cancelled entries are included in the tax return. OPW: 5417293
This update resolves an issue impacting the calculation of coordination deductions for Swiss payroll (l10n_ch_hr_payroll). The fix ensures accurate reporting of these deductions, aligning with Swiss tax regulations. This improves the reliability of payroll reporting for our Swiss clients.
Original PR description
Forward-Port-Of: odoo/enterprise#106615
This update resolves a bug where changing a commission plan's frequency (e.g., from quarterly to monthly) didn't correctly remove outdated periods, leading to incorrect commission calculations. The fix ensures that old periods are removed when the target frequency is updated, preventing overlapping commission targets and inaccurate invoice reporting.
Original PR description
## Issue When changing the *Target Frequency* of a commission plan, previously created periods are not removed. ## Steps to reproduce 1. Install *Sale Commission* (`sale_commission`) 2. Create a…
## Issue
When changing the *Target Frequency* of a commission plan, previously created periods are not removed.
## Steps to reproduce
1. Install *Sale Commission* (`sale_commission`)
2. Create a *Commission Plan*. The default *Target Frequency* (`periodicity`) should be *Quarterly*. In the *Periods* tab, 4 periods (`targets`) are present.
3. Change the *Target Frequency* to *Monthly*
4. **New monthly periods are added, but the quarter periods are not removed**
This behavior leads to a second issue:
5. Following the previous steps, set the current user as a Salesperson the *Sales People* tab
6. Approve the Commission Plan
7. Create an invoice
- Any customer
- Add a product with a price of $100
- Confirm the invoice
8. Go to Sales > Commissions > My Commissions
9. **The invoice impacted multiple commission targets, because the current period is covered multiple times (by the monthly and the quarterly frequencies)**
## Cause
This issue was introduced by https://github.com/odoo/enterprise/commit/e7693f3c61044f689da87218235cd985e26f75d5. The commit aimed to preserve periods when updating the *Effective Period* of a commission plan. In fact, in some cases, it is unnecessary to delete all periods because some of them belong to both the previous and the updated effective period.
https://github.com/odoo/enterprise/blob/2dd98eed0559b6217ef8467f1d56c171d546b85b/sale_commission/model/commission_plan.py#L106-L108
When updating the *Target Frequency* of a commission plan, the *Effective Period* is unaffected, making the `target_changes` list empty. This leads to none of the periods being deleted, eventhough they don't respect the new periodicity.
## Fix
The condition to add periods to the `target_changes` list needs to updated, as it needs to also take in account the periodicity of the commission plan. The `expected_target_duration` needs to be a range, as it depends on the (variable) length of the months that are concerned. These ranges were chosen by looking at the sizes of each period. A margin of one day is added for the "year" case to handle leap years.
<img width="687" height="367" alt="5877405" src="https://github.com/user-attachments/assets/065b0d21-0860-4435-9f9b-55feef789da6" />
## Test
The test `test_commission_target_constraint` was using the fact that the periods were not deleted when updating the periodicity to test against the creation of overlaps between periods. As this is no longer possible, the test was updated.
opw-5877405A recent update in Odoo 19.0 has caused the Kanban view for manufacturing orders to show all active orders instead of those related to the selected operation type. This fix ensures that the Kanban view correctly filters manufacturing orders based on the chosen operation type, improving usability and accuracy.
Original PR description
**Steps to reproduce:** * Install the *stock_barcode_mrp* module. * Go to *Inventory* ‣ *Configuration* ‣ *Operation Types*. * Create two operation types with *Type of Operation* set to…
**Steps to reproduce:**
* Install the *stock_barcode_mrp* module.
* Go to *Inventory* ‣ *Configuration* ‣ *Operation Types*.
* Create two operation types with *Type of Operation* set to *Manufacturing*.
* Create two manufacturing orders.
* In each manufacturing order, under the *Miscellaneous* tab
set a different *Operation Type* created above.
* Ensure sufficient *On Hand Quantity* exists for a product used in manufacturing.
* Open the *Barcode* application.
* Open one of the created manufacturing operation types.
**Observed behavior:**
* The kanban view displays **all** manufacturing orders whose picking
types are active, instead of only those related to the selected operation type.
**Cause:**
* In 19.0, the context key *`'search_default_picking_type_id': self.id`* was removed
from `_get_action` function in this [commit](https://github.com/odoo/odoo/commit/9ed7109b8f11260084374f2d7fa7073a9ad3c240)
* Previously, this context value restricted results to the current picking type by default.
* The method `get_action_picking_tree_ready_kanban` in *stock_barcode_mrp*
now overrides the domain with only *`('picking_type_id.active', '=', True)`*.
* This domain checks that the picking type is active but does not filter by
the selected picking type, causing unrelated MOs to be shown.
**Fix:**
* This ensures only manufacturing orders belonging to
the selected operation type are displayed.
---
opw-5819358This update addresses key changes required for Belgian payroll reporting under the 281.10, 281.45, and 281.XX tax schemes. Specifically, it updates data schemas and declaration values to align with the latest regulations for 2025 and incorporates reporting up to 2026, ensuring accurate and compliant payroll processing for Belgian businesses.