Daily updates from Odoo
Wednesday, December 3, 2025
32 changes · master
Resolved issues and error corrections
This update resolves an issue where discount calculations on Mexican global invoices were producing incorrect values, leading to errors. The fix ensures accurate rounding of discount amounts during invoice generation, aligning with Mexican tax regulations. This improves the reliability of invoice creation for our Mexican customers.
Original PR description
Steps to reproduce: ------------------- * Create an invoice with the following line: * Unit price: 47.25, Qty: 1, Taxes: 16%, Discount 50% * Confirm, create a global invoice > Observation: Error ```…
Steps to reproduce: ------------------- * Create an invoice with the following line: * Unit price: 47.25, Qty: 1, Taxes: 16%, Discount 50% * Confirm, create a global invoice > Observation: Error ``` Code : CFDI40108 Message : El TipoDeComprobante es I,E o N, el importe registrado en el campo no es igual al redondeo de la suma de los importes de los conceptos registrados. ``` Why the fix: ------------ The issue occurs because the `descuento` value, originally 23.625, is now being corrected to 23.615 which leads to `importe` having a value of 23.635 which round up to 23.64 and not 23.63. https://github.com/odoo/enterprise/blob/08564f3312c255f2f3ab95cef5a9bfc57727bd1f/l10n_mx_edi/models/l10n_mx_edi_document.py#L1111 https://github.com/odoo/enterprise/blob/08564f3312c255f2f3ab95cef5a9bfc57727bd1f/l10n_mx_edi/models/l10n_mx_edi_document.py#L1336 Before this commit https://github.com/odoo/enterprise/commit/39759babddc732a312ec5cd6a60a2f1819abc62c the discount value was being rounded when corrected. It would end up being evaluated to 23.62. To not bring back the issue the fixed by the mentioned commit we round the discount when generating the global invoice cfdi values. Now `importe` will have a value of 23.63 as `descuento` is rounded to 23.62. opw-5023597 Forward-Port-Of: odoo/enterprise#95982 Forward-Port-Of: odoo/enterprise#94438
This update fixes an issue where Brazilian vendor bills incorrectly applied sales taxes instead of purchase taxes due to a flaw in the external tax calculation. The fix ensures that the correct tax type ('COFINS Incl.' etc.) is used when computing taxes for vendor bills, improving financial accuracy for Brazilian businesses using Odoo.
Original PR description
**Steps to reproduce:** - Install accountant, l10n_br and l10n_br_avatax - Switch to a Brazilian company - In Accounting settings, configure AvaTax (require credentials) - Create a bill - Compute taxes with AvaTax **Issue:** If a tax like "COFINS Incl." should be added, the Sales tax is added instead of the Purchases one, resulting in an incorrect account for the tax line. **Cause:** Brazilian localization allows to use AvaTax for vendor bills, but the external tax feature doesn't take into account the type of the tax when searching for one. It just returns the first one based on the name, the amount and some other domains. **Solution:** Add the tax type in the domain when searching a Brazilian tax. **PR (Community):** https://github.com/odoo/odoo/pull/236930 opw-5044423 Forward-Port-Of: odoo/enterprise#100854 Forward-Port-Of: odoo/enterprise#100340
A technical error was preventing users from correctly adjusting salary benefits within the offer generation process. This update resolves a 'TypeError' that occurred when a specific benefit type ('Always Selected') was present, ensuring the salary package website page functions as intended. This fix improves the user experience for generating salary offers.
Original PR description
Steps to reproduce: 1. Install 'hr_contract_salary_payroll' 2. Create three benefits from Payroll > Configuration > Benefits - Basic: Salary Structure Type: US Employee Contract Related Field: Health…
Steps to reproduce:
1. Install 'hr_contract_salary_payroll'
2. Create three benefits from Payroll > Configuration > Benefits
- Basic:
Salary Structure Type: US Employee
Contract Related Field: Health Benefits Dental
Display Type: Slider (1500, 6000)
- Housing:
Salary Structure Type: US Employee
Contract Related Field: Health Benefits Vision
Display Type: Always Selected
- Transport:
Salary Structure Type: US Employee
Contract Related Field: Health Benefits Vision
Display Type: Manual
Mandatory Benefits: Basic, Housing
3. Go to Employees > Contracts
4. Create a new contract:
Set an employee
Salary Structure Type = US Employee
HR Responsible = Mitchell Admin
5. Click the Generate Offer smart button.
6. Open the link
7. Adjust the sliders
Issue: it gives a traceback
`TypeError: Cannot read properties of undefined (reading 'type')`
Cause:
https://github.com/odoo/enterprise/blob/cc3fe89528a143cff3ab03e1654755c34eaac112/hr_contract_salary/static/src/js/hr_contract_salary.js#L480-L482
In checkInputSelected, the target array is empty when an Always Selected benefit is present, causing an attempt to read target[0].type.
Solution:
Add a guard to check that target is not empty before accessing its elements.
opw-5058994
Forward-Port-Of: odoo/enterprise#94881This update fixes an error that prevented payroll officers from accessing salary offers. The issue stemmed from the module attempting to access candidate information, which required recruitment rights. The fix ensures payroll officers can now open and manage offers without needing these additional permissions.
Original PR description
steps to reproduce: - Install l10n_be_hr_contract_salary - Log in as a payroll officer (without recruitment rights) - Go to Payroll > Contracts > Offers - Open any offer - Notice an 'Access Error' appears: You are not allowed to access 'Candidate' (hr.candidate) records. cause: The module tries to read `employee_id.candidate_id.partner_id` in offer computations. Since payroll officers lack recruitment rights accessing `hr.candidate` triggers an access error. fix: Wrap candidate access in try/except to handle missing permissions. - If accessible, candidate partner data is used as before. - If not accessible, skip without raising an error. This allows payroll officers to open and generate salary offers without requiring recruitment rights. task - 5039712 Forward-Port-Of: odoo/enterprise#100980 Forward-Port-Of: odoo/enterprise#95869
A minor grammatical error in the SEPA Direct Debit payment provider configuration message has been corrected. This ensures consistent and accurate messaging for customers, improving the overall user experience. The change replaces 'an unique' with 'a unique' in the 'Pending Message'.
Original PR description
Currently, a typo appears in the `Pending Message` shown in the SEPA Direct Debit payment provider configuration. **Steps to reproduce:** - Install the `payment_sepa_direct_debit` module. - Navigate…
Currently, a typo appears in the `Pending Message` shown in the SEPA Direct Debit payment provider configuration. **Steps to reproduce:** - Install the `payment_sepa_direct_debit` module. - Navigate to Invoicing > Configuration > Payment Providers > SEPA Direct Debit. - Open the `Messages` tab and observe the `Pending Message`. **Observation:** The message uses "an unique" instead of the grammatically correct "a unique". **Fix:** This commit corrects the message by replacing "an" with "a" at [1]. Before: <img width="1903" height="606" alt="typo_before" src="https://github.com/user-attachments/assets/df4f658b-9f4c-4e68-b8cb-a1bdc2253fc3" /> After: <img width="1900" height="609" alt="typo_after" src="https://github.com/user-attachments/assets/e9192d70-b343-4e4e-9e21-281a93d4d71e" /> [1]: https://github.com/odoo/enterprise/blob/6c3692d85bf1ef7b14d930d9a1ed244cf8aa851b/payment_sepa_direct_debit/data/payment_provider_data.xml#L13 opw-5373274 Forward-Port-Of: odoo/enterprise#100983
This update removes a redundant view used in appointment scheduling that was causing crashes in certain Odoo modules. The change prevents Odoo from incorrectly attempting to use this view, ensuring stability and proper functionality for all appointment-related features. This resolves a technical issue that could impact users.
Original PR description
Remove the extra pos_list view used for calendar_event_list by the pos because Odoo would try to use it by default to all calendar_event_list views and that would cause it to crash for modules which didn't have the view initialized Runbot Error:[234475](https://runbot.odoo.com/odoo/runbot.build.error/234475)
This update resolves an issue where clicking 'Details' on completed signed documents resulted in an error. The fix ensures the correct sign request record is retrieved, allowing users to now seamlessly view the details of signed documents and maintain workflow efficiency.
Original PR description
Version: - saas-18.4 Steps to reproduce: - Open a template that has at least one completed signed request. - Click the Signed Document state button. - See all documents - Click on the detail button Before: - Clicking the Details button on a completed signed document caused a traceback. - This happened because the view was using the record ID from this.props.record.context, which referred to the sign template instead of the sign request, causing incorrect data to be fetched. After: - Use this.props.record.evalContext to retrieve the correct sign request record ID, with this.props.record.context as a fallback. Impact: - Users can now view signed document details without errors, improving workflow continuity and overall usability. task-5253632 Forward-Port-Of: odoo/enterprise#99221
This update addresses inconsistent focus states on buttons, particularly in dark mode, making them easier to see and use. The change standardizes the focus style across the Enterprise module, enhancing user experience and accessibility. This resolves a usability issue reported by users.
Original PR description
The focus states on buttons are inconsistent and sometimes hard to see (eg. darkmode secondary buttons). This PR defines the `focus-ring-*` variables to make the focus state use `o-component-active-border` everywhere. [task-4878272](https://www.odoo.com/web#id=4878272&cids=1&menu_id=4720&action=333&active_id=1695&model=project.task&view_type=form) Community PR: https://github.com/odoo/odoo/pull/235780
This update fixes a reporting issue where the partner filter in the Partner Ledger report wasn't consistently displaying all transactions related to a partner. The fix ensures that both invoices and related operations (like misc entries) are visible when using the filter, improving reporting accuracy and data visibility.
Original PR description
To reproduce: - create an invoice for partner Bernard Gagnant (very important) - reconcile that invoice with a misc operation ; make sure not to set any partner on the receivable line of that entry - Open the Partner Ledger: both the invoice and misc operation appear under "Bernard Gagnant". This is due to a hack in that report and is the intended behavior - Use the partner filter, on top of the report, to only display partner "Bernard Gagnant" ====> The misc operation does not appear anymore. After this fix, if the filter is applied, we will be able to see both the invoice and the misc operation under the partner. task-5150419 Forward-Port-Of: odoo/enterprise#97528
This update fixes a misleading warning that appeared when renewing subscriptions in version 19.0. The change prevents the system from flagging renewal quotes as duplicates, ensuring a smoother process for users. This improves the user experience and avoids unnecessary notifications.
Original PR description
Version: - 19.0 Steps to reproduce: 1. Create a subscription. 2. Set a customer reference 3. Confirm the subscription and create an invoice. 4. Renew the subscription to generate a renewal quote (state '2_renewal'). Issue: A duplicate order warning is displayed when renewing a subscription Solution: Exclude renewal quotes (`subscription_state == '2_renewal'`) from the duplicate order check in `_fetch_duplicate_orders`. This prevents incorrect warnings when creating or opening renewal quotes. taskid-5258963 Forward-Port-Of: odoo/enterprise#99344
This update adds logging to the automated reconciliation process, making it easier to identify and resolve issues when it runs in user environments. Previously, debugging was difficult, but these new loggers provide greater visibility into the process's execution. This improves reliability and reduces troubleshooting time.
Original PR description
For the moment, it's difficult to debug in users databases in the cron and the try auto reconcile. This commit will add some loggers to be more aware of what's going on. task-5358849 Forward-Port-Of: odoo/enterprise#101003 Forward-Port-Of: odoo/enterprise#100601
A bug causing internal server errors when printing audit reports has been resolved. The update ensures the correct PDF export function is used for this specific report type, improving the reliability of the annual report generation process. This prevents errors and ensures accurate report output.
Original PR description
Steps to reproduce: - Go to "Accounting/Review/Audit/Annual Report" and create an Audit Report. - click "Print" -> Internal Server Error This happens when generating the Journal Audit pdf, this report needs to uses the `export_to_pdf` that is defined in its custom handler `account.journal.report.handler`. The solution is to use `dispatch_report_action`, as it will determine which function to use in order to export the pdf for each report. no-task Forward-Port-Of: odoo/enterprise#100949
This update removes outdated configurations that forced specific start dates for reports. Now, users can easily set the correct start date through the standard form view, simplifying the reporting process. This change improves usability and ensures accurate reporting data.
Original PR description
These overrides are useless now that the user can access the return type form view and configure himself the start_date. Overriding _get_start_date_elements should be avoided as much as possible as this is making the field on the form view useless if set. Forward-Port-Of: odoo/enterprise#100728
This update resolves a technical issue that caused a traceback when users clicked the 'Tracks' stat button on an event page. The problem stemmed from missing data fields in the event view. This change ensures a smoother user experience and prevents errors when viewing event tracks.
Original PR description
**How to reproduce:** - Open an event - Click on 'Tracks' stat button **Before this PR:** A traceback occurs. **Technical reason:** Some fields are missing from the view. They were removed here: https://github.com/odoo/enterprise/commit/301f63597b0c21fef16a1941314ac95602c8f01f **After this PR:** No traceback Task-5262404
This update corrects a flaw in the VoIP contact search test. Previously, the test could incorrectly identify matches due to demo data. The fix now ensures the test only uses data created within the test environment, guaranteeing accurate results and preventing misleading test outcomes.
Original PR description
In the test, we suppose to find no phone number matched result when search term length is shorter than `_phone_search_min_length`. However, it can still match `name` or `email` if possible. In this fix, we change the test to only consider the data created in the test, to avoid the wrong result from demo data.
This update allows authorized users to cancel payslips without needing to be accountants. Previously, reversing a payslip required specific accountant group permissions on related account moves. This change simplifies the process and improves usability for users needing to correct payroll data.
Original PR description
As you need to have accountant group on some fields of the account move to be able to reverse it. We need to do it as sudo. Forward-Port-Of: odoo/enterprise#101076
This update enhances the reliability of point-of-sale transactions by automatically retrying failed requests (5xx errors) and ensuring tills remain operational even when the payment processing server is temporarily unavailable. The changes simplify the underlying code and improve error handling, leading to a more stable and dependable POS experience.
Original PR description
In this task: --------------- - Moved the status code handling logic at proper place for all transactions API responses. - Removed the mixed usage of async/await and .then() by async/await totally in all transaction calls to simplify flow and improve readability. - For 5xx errors (e.g., 503), retry once as they occur when the server is unreachable. Print "TSS not reachable" if even after retries followed by exponential backoff logic. - Guarantee tills remain operational and not blocked even if the TSS is unreachable. task:5051693 Forward-Port-Of: odoo/enterprise#101058 Forward-Port-Of: odoo/enterprise#93694
This update clarifies the Pay Run wizard by making the 'Company' field mandatory. Previously, leaving it blank created a misleading impression of generating payslips for all companies. Now, users must select a company for each pay run, ensuring accurate and transparent payroll processing.
Original PR description
In a multi-company environment, leaving the Company field empty in the Pay Run wizard gives the impression that payslips will be generated for all companies, which is misleading for users. In practice, the pay run is created only for the user’s allowed companies, but the optional field causes confusion. This commit: - Make sure that Company field is mandatory in the Pay Run wizard. - add tests for default value to the currently selected company. - Updates the placeholder text from “Visible to all” to “Select a company for this Pay run”. Task-5266945
This update streamlines the HR payroll system by removing unnecessary references to input fields. Previously, values lingered even when other related fields were changed, causing potential upgrade issues. This change enhances stability and simplifies the system's operation.
Original PR description
Currently when setting condition_other_input_id or amount_other_input_id the value stays until changed again, even if we change condition_select or amount_select to another value. In this commit, the reference to an other_input will be removed if we no longer need it. This is done to prevent issues when upgrading for example, where a reference stops a delete_unused when it is not really used. task-5265607
This update resolves a printer blocking issue caused by incorrect handling of reward discounts on receipts. The fix ensures that discounts are applied correctly, regardless of the number of items or reward types, preventing errors and ensuring accurate receipt printing. This improves the reliability of point-of-sale transactions.
Original PR description
This PR fixes the case of printer blocked using reward lines and multiple order lines. To reproduce the issue: - Add a product with reward (for example 10% reward on 50€ , that is 5€) - Add a second product without reward that costs less than 5€ - Print the receipt on fiscal printer The lines are orderer before the non reward lines, than reward lines. The printer is blocking because the adjustmentType discounts last line of less than 5€. It is wrong. Another way to reproduce the issue: - Add a product with reward - Add a second product with reward - The reward line with the sum of both rewards is created The same error appear because it discounts both lines. It is better to discount the entire department instead of the last sale Forward-Port-Of: odoo/enterprise#98699
This update resolves an issue where the AI module was incorrectly handling file content. The changes prevent unnecessary data duplication and ensure consistent checksum calculations, improving the reliability of AI document processing. This is a minor fix focused on internal AI module functionality.
Original PR description
The cron is encoding the `content` to compute its checksum already. Also don't set `index_content`, as far as I can tell it's unconditionally computed by `ir.attachment` on both create and write (via `_set_attachment_data` in the latter case). Forward-Port-Of: odoo/enterprise#100985
This update fixes an issue where changes to fields like insurance or company car didn't correctly update related sub-fields in the employee configuration. The update ensures that these fields always display the most current values, improving the user experience and data accuracy. Additionally, a performance optimization was implemented for a key calculation.
Original PR description
'*' = be, ch purpose: currently when you change the values of fields like insurance or company car the onchange doesn't reflect on the subfields which is the case for cars, insurances, etc. this makes the fields have wrong default values in the configurator - added `_onchange` methods for related fields of `hr_version` in `hr_employee` to call the corresponding `_onchange` in `hr_version` - optimized the method `_compute_l10n_be_mobility_budget_amount` to use binary search instead of linear loop task-id: 5173389 Forward-Port-Of: odoo/enterprise#101077 Forward-Port-Of: odoo/enterprise#97472
This update resolves an issue where our system was interfering with the VoIP library's internal stream management. By directly utilizing the library's remote stream, we've prevented conflicts and ensured more stable VoIP functionality. This change enhances the reliability of our voice communication features.
Original PR description
Before this commit, the remote stream was managed by us: creating the MediaStream object, adding the tracks, stopping them... Because of this, we ended up accidentally overwriting the ontrack handler used by the SIP.js library to manage its internal state After this commit, we directly use the remote stream from the library, preventing unwanted interactions. [Task-5379708](https://www.odoo.com/odoo/project/5778/tasks/5379708)
This update fixes a technical issue that prevented completion notifications within the MRP Work Order module from being translated into different languages. The fix ensures that users receive notifications in their preferred language, improving the overall user experience and localization capabilities. This resolves a previous bug impacting internationalization.
Original PR description
The `_t()` was put around the wrong thing, making the strings never translatable. Followup to: 4403621 Forward-Port-Of: odoo/enterprise#101119
This update fixes an error in the default role name used within the sign module. The incorrect name caused potential issues with role assignments and access control. This change ensures proper functionality and security within the sign process.
Original PR description
task-5358513 Forward-Port-Of: odoo/enterprise#100474
This update fixes a bug in the shop floor component consumption process when tracking by lot. Previously, incorrect quantities were consumed, often resulting in drastically inflated amounts. The fix ensures accurate consumption based on lot quantities, resolving this inconsistency.
Original PR description
**PROBLEM** Component consumption behavior in shop floor is buggy when the component is tracked by lot. When "selecting" a lot to take from, the consumed amount is not correct. (ex, we ask for 50g,…
**PROBLEM** Component consumption behavior in shop floor is buggy when the component is tracked by lot. When "selecting" a lot to take from, the consumed amount is not correct. (ex, we ask for 50g, and it consumes 1000kg). **STEP TO REPRODUCE** 1. create a product. 2. create a bom with: - a component tracked by lot, with kg as product uom, but g as the bom uom. - create a step, during which 50g of the component is consumed. 3. create two lots of the component, with 1kg each. 4. create a MO for the product with the bom. 5. in the shop floor, try consuming the component and select one of the lot as a source. 6. the consumed amount should be 50g, remove the move line created (pencil icon, then remove). 7. recreate the move line, the consume amount will be nonsensical (something like 1 000 000g). **CAUSE** 1. The dialog opened for selecting the lot create a new `stock.quant` record, instead of returning the existing quant for the lot. This quant will have a quantity of 0, impacting the computation we do for the quantity we should take from this quant. 2. The formula for the quantity to take from the quant was : `max(min(remaining_qty, quant.available_quantity), 1)`. The `max(...,1)` doesn't work well when `remaining_qty` is between 0 and 1. For example, when using UoM like we do in the repro steps, `remaining_qty = 50g = 0.05kg`. But instead of taking 50g, because of the max we take 1kg = 1000g. 3. There was a double UoM conversion (`_prepare_move_line_vals` already does the conversion, so we don't need to do it before passing qty_to_take as parameter). opw-5136050 Forward-Port-Of: odoo/enterprise#100913 Forward-Port-Of: odoo/enterprise#97005
This update resolves an issue where the 'Reviewed' button wasn't appearing correctly during bank reconciliation. The fix corrects a data call, ensuring the button is displayed when needed. Additionally, a security check has been added to remove secondary buttons during reconciliation for enhanced stability.
Original PR description
Before this commit, we called the wrong variable to know whether the "Reviewed" button is available or not. It leads to have a no show of this button even when it was needed. This commit also adds a small security check to remove the secondary buttons when the statement is reconciled. no task id Forward-Port-Of: odoo/enterprise#101063
This update corrects a bug that previously prevented users from setting negative completion targets for sales commission plans. Previously, attempting to set a negative target would cause an error. Now, negative targets are allowed, ensuring greater flexibility in commission plan configuration. This resolves a potential issue where accurate commission calculations were impossible.
Original PR description
Before this commit, it was not possible to define negative completion target on the plan. task-5362854 Forward-Port-Of: odoo/enterprise#101095
This update resolves an issue where commas in payment memos for New Zealand EFT files were causing errors and rejected payments. The change removes commas from generated files, ensuring correct formatting and preventing payment processing failures. This ensures accurate EFT file submissions to the BNZ bank.
Original PR description
The EFT file format BNZ is exported as a text file. As such, any commas in the field contents will be treated as a new field, resulting in incorrect formatting and a rejected batch file. This…
The EFT file format BNZ is exported as a text file. As such, any commas in the field contents will be treated as a new field, resulting in incorrect formatting and a rejected batch file. This behavior is due to the Odoo community commit [3082d3b](https://github.com/odoo/odoo/commit/3082d3bd0d7a8b45e647c441ba48adcb84a7a070), which partially reversed an improvement to the group payment memo field. - The original behavior was to concatenate the included invoices with spaces (e.g. 'INV/123 INV/124'). - The improvement replaced this with the batch payment reference (e.g. 'BATCH/IN/002'). - The behavior after 3082d3b is to concatenate the included invoices with a space and a comma (e.g. 'INV/123, INV/124' This commit strips the commas from all generated EFT files, instead of further altering the group payment memo field. It also alters existing unit tests to check that commas are removed from payment memo fields. While a fix that changes the memo generation would resolve some issues, this commit ensures that manually added commas will not cause rejected payments. [Ticket link](https://www.odoo.com/odoo/unassigned-tasks/5099220) opw-5099220 Forward-Port-Of: odoo/enterprise#100670 Forward-Port-Of: odoo/enterprise#98613
A bug in the payment state test has been fixed. The test now correctly reflects the payment state of invoices based on whether the ‘accountant’ module is installed. This ensures consistent invoice tracking across different Odoo configurations.
Original PR description
The `test_bill_state_change_on_payment_state` is throwing an exception. ``` self.assertEqual(payment.invoice_ids.payment_state, 'not_paid') AssertionError: 'paid' != 'not_paid' - paid + not_paid ```…
The `test_bill_state_change_on_payment_state` is throwing an exception. ``` self.assertEqual(payment.invoice_ids.payment_state, 'not_paid') AssertionError: 'paid' != 'not_paid' - paid + not_paid ``` The test was incorrectly expecting invoice `payment_state` to always be `not_paid` when payment is reset to draft, but behavior differs based on whether `accountant` module is installed or not. - With `accountant`: Payment has no move_id (no journal entry created by default), so when drafted, `invoice.matched_payment_ids` filters exclude it, resulting in 'not_paid' state. - Without `accountant`: Payment has move_id (journal entry auto-created) so filter conditions fail (`not p.move_id` is `False`), and invoice stays `paid` due to existing reconciliations in `draft` state. Test was introduced here: https://github.com/odoo/enterprise/pull/100834/commits/402bd85af79fa68fa2cb957d40307edf62f7525c Commits that introduced the behavior change: https://github.com/odoo/odoo/pull/182390/commits/b572fcd78289013f28f11157b1bfbb75c9ea7344 https://github.com/odoo/odoo/blob/57f1053b031f293c6cd8dc8f590dccda4fb3e665/addons/account/models/account_move.py#L1308-L1314 Runbot [link](https://runbot.odoo.com/odoo/error/234573) runbot error: 234573 Forward-Port-Of: odoo/enterprise#101089
This update fixes a reporting issue in the Argentine VAT report by correctly mapping data for exempt sales. Previously, the report incorrectly displayed values for non-exempt sales in the exempt balance column. The change ensures accurate reporting of VAT balances based on whether a sale is exempt or not.
Original PR description
This pull request updates the logic for handling exempt balances in the VAT sales report. The main change is the introduction of a new column mapping for "Monto Neto Exento o No Gravado" and the…
This pull request updates the logic for handling exempt balances in the VAT sales report. The main change is the introduction of a new column mapping for "Monto Neto Exento o No Gravado" and the corresponding handling of exempt and non-exempt balances in the query result processing. These change fixes an issue we encountered when checking the sales CSVs ('Débito' and 'Restitución de débito'). Before this change, the column "Monto Neto Exento o No Gravado" was always filled, even when the operation was not exempt, and in that case it repeated the value of "Monto Neto Gravado".
Here is an example:
<img width="1654" height="187" alt="image" src="https://github.com/user-attachments/assets/578fa197-ab72-4801-b714-9c40ddff4b01" />
The correct behavior should be that for taxed operations, only "Monto Neto Gravado" is filled with the 'balance' value, and for exempt operations only "Monto Neto Exento o No Gravado" should have values.
Here is a screenshot of the 'Debito' CSV after the change:
<img width="1614" height="196" alt="image" src="https://github.com/user-attachments/assets/0a18cbe9-d878-4e37-9bb7-21dc8b5cda72" />
**Summary**
* Changed the column mapping for "Monto Neto Exento o No Gravado" from `balance` to `exempt_balance` in the `columns_map` dictionary in `_vat_simple_build_sale_query`.
* Updated the logic for populating values: added handling for `exempt_balance` and `balance` columns so that only exempt balances are shown in `exempt_balance` and non-exempt balances in `balance`, based on the `is_exempt` flag in the row.
Note: the files created were tested on ARCA environment and they could be uploaded without errors.
Forward-Port-Of: odoo/enterprise#97377This update resolves a technical issue that caused Odoo to crash when users selected multiple boxes within the bank statement attachment previewer. The fix ensures the system correctly handles situations where a page doesn't contain date information, preventing the error and improving stability.
Original PR description
If a group of boxes is selected on the attachment previewer on a page that doesn't contain any date, a crash would occur as `this.boxes['date'][pageNumber]` was undefined. task-none Forward-Port-Of: odoo/enterprise#99549