Wednesday, July 22, 2026
7 changes · saas-19.1
Resolved issues and error corrections
This fixes Mexican electronic invoicing so the Tax Object field is recalculated when a unit price is added to an invoice line. It prevents invoices from keeping a missing tax classification after users update a previously zero-priced product, helping keep invoicing data complete and compliant.
Original PR description
**Steps to reproduce the issue:** - Install the l10n_mx_edi module. - Open the Accounting app and go to Customers → Invoices. - From the invoice line, make the Tax Object field visible. - Create a…
**Steps to reproduce the issue:** - Install the l10n_mx_edi module. - Open the Accounting app and go to Customers → Invoices. - From the invoice line, make the Tax Object field visible. - Create a new invoice and add a product that has no Unit Price. - Save the invoice. - Edit the same invoice, set a Unit Price for the product, and save it again. - Issue: The Tax Object field is not automatically set after the Unit Price is added. **Description:** - In our standard code, there is a condition that skips computing the Tax Object when the Unit Price is [0](https://github.com/odoo/enterprise/blob/615a5f756d708db95e22cdbdd6e7aca72ac769ec/l10n_mx_edi/models/account_move.py#L988). This is the expected behavior. - However, after setting a Unit Price on the product, the Tax Object is not recomputed, so it remains unset. - To resolve this issue, I added price_unit to the @api.depends decorator so that the Tax Object is recomputed whenever the Unit Price changes. **Reference videos:** Before the fix: [screen-capture (2).webm](https://github.com/user-attachments/assets/c1162fd9-52b8-4a8c-9ac2-39cf2ca3ad69) After the fix: [screen-capture (1).webm](https://github.com/user-attachments/assets/1c05dc34-6778-487a-9bfc-635cf652e670) OPW -6305080 UPG - 4268848 Forward-Port-Of: odoo/enterprise#123009
This fix prevents users from creating or editing WhatsApp message templates from the event communication setup in a way that can link the wrong template type. It helps avoid access errors after saving and reloading an event, while preserving existing creation flows for other communication types.
Original PR description
Issue: User goes to Event.event Form -> communication tab -> add line Select whatsapp -> type something -> create and edit -> create new template with any model event.registration -> save ( all the way including the event form) reload page -> whatsapp event.mail displays "User does not have access to this record". Fix: add a patch to the js get m2oProps to deactivate edit, and create on the prop. WA Templates need more limitations for creation and edits due to the approval process from META's external API. We cannot block the full creation and edit in the xml becuase other event.mail types rely on that flow to create their types like social posts. This was a fix implemented due to needing to revert the oginal fix odoo/odoo@f58e9f97192ac0ff8d159377494d6c68f871d20b opw-6334168 Forward-Port-Of: odoo/enterprise#124156 Forward-Port-Of: odoo/enterprise#121852
Creating or viewing Australian payroll super accounts could fail because the system used inconsistent employee references when checking contribution proportions. This update makes that lookup consistent, preventing the error and allowing payroll configuration to continue normally.
Original PR description
Version - 19.0 Steps to reproduce(runbot): - Install `l10n_au_hr_payroll` - Go to Payroll -> Configuration -> Super Accounts - Create a Super Account by filling all the required fields - You will…
Version - 19.0
Steps to reproduce(runbot):
- Install `l10n_au_hr_payroll`
- Go to Payroll -> Configuration -> Super Accounts
- Create a Super Account by filling all the required fields
- You will encounter the issue
**TraceBack:**
```
('hr.menu_hr_employee_payroll', 485, 'Employees > Employees', 756):
Traceback (most recent call last):
File "/tmp/tmpao31_hxw/migrations/base/tests/test_mock_crawl.py", line 346, in crawl_menu
self.mock_action(action_vals)
File "/tmp/tmpao31_hxw/migrations/base/tests/test_mock_crawl.py", line 377, in mock_action
return self.mock_act_window(action)
File "/tmp/tmpao31_hxw/migrations/base/tests/test_mock_crawl.py", line 537, in mock_act_window
mock_method(model, view, fields_list, domain, group_by)
File "/tmp/tmpao31_hxw/migrations/base/tests/test_mock_crawl.py", line 570, in mock_view_form
[data] = record.read(fields_list)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 3490, in read
return self._read_format(fnames=fields, load=load)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 3747, in _read_format
vals[name] = convert(record[name], record, use_display_name)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 6688, in __getitem__
return self._fields[key].__get__(self)
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1744, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1915, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/19.0/addons/mail/models/mail_thread.py", line 484, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 4954, in _compute_field_value
determine(field.compute, self)
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 81, in determine
return needle(*args)
File "/home/odoo/src/enterprise/19.0/l10n_au_hr_payroll/models/hr_employee.py", line 118, in _compute_proportion_warnings
proportions[emp.id] * 100,
KeyError: 4
```
Issue:
During the refactoring from `read_group()` to `_read_group()`, the `proportions` dictionary became keyed by `hr.employee` records instead of employee IDs. While the condition was updated to use `proportions.get(emp)`, the warning message still accessed the dictionary using `proportions[emp.id]`, resulting in a `KeyError`.
Fix:
Use the employee record consistently when accessing the `proportions` dictionary after switching to `_read_group()`.
Task ID - 6390373
Refrence:
https://github.com/odoo/enterprise/pull/72217/changes#diff-8ae3564d54e47eec919ef273d44f6276d8c6df60e21c5c8c8f7292b1c38cf541R460
Forward-Port-Of: odoo/enterprise#124478Spanish VAT book reports now correctly include tax amounts for vendor bills using taxes with negative components, such as certain EU purchase taxes. This prevents valid tax amounts from appearing as zero, improving the accuracy of Spanish VAT reporting.
Original PR description
Problem: In the Spanish VAT books, taxes with negative component (like 21% EU G) always show their amounts as zero. Steps to reproduce: 1. Install the l10n_es_reports module and select the Spanish company 2. Create a vendor bill with a vendor from another EU country and add a product 3. Make sure the tax applied to the product has a negative component (like 21% EU G) 4. Confirm the bill 5. Go to Accounting > Reporting > Tax Return 6. Generate the VAT books from the action menu and check the tax amounts 7. Notice how the tax amount is zero, even though the tax was applied to the bill Cause: When calculating the tax amounts, the negative component cancels out the positive component, leading to the amount always showing as zero in the VAT books. opw-6169766 Forward-Port-Of: odoo/enterprise#124030 Forward-Port-Of: odoo/enterprise#123738
French VAT declaration submissions now handle SIRET numbers even when users enter spaces, preventing avoidable filing failures. The update also checks bank account number formatting and warns users when the entered account number appears incorrect.
Original PR description
This commit resolves an issue where VAT declarations failed when the provided SIRET number included spaces. Since check_siret verifies the format, we now strip all spaces from the input. Additionally, this commit introduces a validation for bank account numbers, ensuring that we warn the user if the account number is wrongly formatted. task-6253745 Forward-Port-Of: odoo/enterprise#124718 Forward-Port-Of: odoo/enterprise#120689
Manufacturing planning now applies the product's bill of materials batch size even when the BOM is not manually selected in the Master Production Schedule. This prevents under-planning production quantities and helps keep replenishment recommendations aligned with real manufacturing constraints.
Original PR description
In MPS, if a product’s Bill of Materials (BOM) is not specified at the time of addition, the system will not correctly account for batch size. Steps to reproduce: ------------------- * Create a…
In MPS, if a product’s Bill of Materials (BOM) is not specified at the time of addition, the system will not correctly account for batch size. Steps to reproduce: ------------------- * Create a product with a bom that has a batch size of 2 * Open MPS * Add the product - without specifying the bom - Route Manufacture * Add 1 in the Forcast Demand -> the batch size from the bom it's not taken into account. Observation: ------------- When updating mps, it will call get_production_schedule_view_state: https://github.com/odoo/enterprise/blob/7092dd2cc3578c3f22d1fbc82d958d57e2f93553/mrp_mps/models/mrp_mps.py#L424 this function when calculating the quantity to resplenish will call _get_resplenish_qty: https://github.com/odoo/enterprise/blob/7092dd2cc3578c3f22d1fbc82d958d57e2f93553/mrp_mps/models/mrp_mps.py#L534 to know the quantity to resplenish it will need the batch size, in mps they will only consider the batch size from the bom registered: https://github.com/odoo/enterprise/blob/7092dd2cc3578c3f22d1fbc82d958d57e2f93553/mrp_mps/models/mrp_mps.py#L863-L865 Since there is no default value for bom_id, If there is no bom selected, there is no batch size. opw-6259956 Forward-Port-Of: odoo/enterprise#119560
Mobile self-ordering can now print preparation receipts when the restaurant uses an IoT printer. This fixes a gap for businesses using IoT Boxes, helping kitchen preparation tickets print reliably from mobile orders.
Original PR description
IoT Boxes can be used to print preparation receipts from self ordering mobile, as they can use the WebSocket connection. We now allow printing from self mobile if the preparation printer is an IoT one. see odoo/odoo#276886 opw-6127663 Forward-Port-Of: odoo/enterprise#124652