Daily updates from Odoo
Friday, December 12, 2025
15 changes · master
Resolved issues and error corrections
This update resolves an issue where the bank statement import wizard wasn't correctly identifying the 'Cumulative Balance' field. The fix adds a necessary step to ensure the wizard recognizes this field, allowing users to properly set up their bank journal imports. This improves the accuracy and usability of the bank statement import process.
Original PR description
When importing a bank statements xlsx in a bank journal, the wizard would not match the "Cumulative Balance", not even proposing it for manual setup. Steps to reproduce: - Go to the accounting…
When importing a bank statements xlsx in a bank journal, the wizard would not match the "Cumulative Balance", not even proposing it for manual setup. Steps to reproduce: - Go to the accounting dashboard - On a bank journal tile, in the right corner menu "New > Import File" - Upload a file (there is one attached to the ticket) - Cumulative Balance is not matched This commit adds module.init() that is skipped in the "onWillStart" override (it's present in the parent onWillStart). This has for consequence that the "bank_stmt_import" key is now present in the context when get_fields_tree() from Base_ImportImport is called, allowing the addition of missing field. See https://github.com/odoo/enterprise/blob/19.0/account_bank_statement_import_csv/wizard/account_bank_statement_import_csv.py#L18 This commit also adds a check to only add debit & credit in the added field list if they are not actual field on the bst line model (see: https://github.com/odoo/enterprise/commit/af863c5a53d0ab50fe67cb9ea910391d4a1979dd) This commit also checks that those fields are only added when the model is account bank statement line (only useful in this case). opw-5222326 Forward-Port-Of: odoo/enterprise#100693
This update fixes an issue where pickup moves related to rental orders were not correctly linked in the inventory reporting. The change addresses a consequence of removing a field from the stock move model, ensuring that rental order references are accurately recorded when a pickup is initiated. This improves the visibility and tracking of rental transactions.
Original PR description
### Steps to reproduce: - Create a rentable, storable product - Create and confirm a rental order for 1 unit of this product - Click on pickup - Inventory > Reporting > Moves History #### > Your…
### Steps to reproduce: - Create a rentable, storable product - Create and confirm a rental order for 1 unit of this product - Click on pickup - Inventory > Reporting > Moves History #### > Your pickup move appears without any reference ### Cause of the issue: The issue has been introduced in d0c1e7845feeee1c2e85a21b5d40570d051458d3 which purpose was to remove the `name` field of the `stock.move` model. However, the `_compute_reference` compute method use to rely on this `move.name` to propagate the info that the move was related to a rental order (since there is no picking). Indeed prior to saas-18.4, the compute method was: https://github.com/odoo/odoo/blob/404cb10283cbc706eae67dd793ced363273f3602/addons/stock/models/stock_move.py#L325-L328 And the reference to the rental order was set on the move at pickup: https://github.com/odoo/enterprise/blob/1466a0139ee64ecd059738bc414f6e7e5a9f4354/sale_stock_renting/models/sale_order_line.py#L303-L313 https://github.com/odoo/enterprise/blob/1466a0139ee64ecd059738bc414f6e7e5a9f4354/sale_stock_renting/models/sale_order_line.py#L248-L257 ### Fix: Since the reference field is a computed and stored fields and since some of its dependencies are set at creation the rental move we can not set the `reference` directly in the creation of the record as we used to do for its name since the compute method will then override and erase or reference. opw-5385004 Forward-Port-Of: odoo/enterprise#101670
This update resolves an issue where users were encountering errors when creating filters within the Spreadsheet Edition, particularly with broken data sources. The fix extends a previous safeguard to all filter types, allowing users to safely manage and delete invalid data sources and filters, improving spreadsheet usability.
Original PR description
Forward-Port-Of: odoo/enterprise#100989 Forward-Port-Of: odoo/enterprise#98448
This update improves the AI agent's responses by automatically adding links to the source documents used to generate the information. Previously, the AI agent didn't provide context for its claims. Now, each claim is cited with a direct link to the relevant source material, enhancing transparency and trust. This change ensures users can easily verify the information provided by the AI.
Original PR description
## Summary: This PR introduces `_get_llm_response_with_sources` to correctly parse the LLM's output format, which includes a trailing `[SOURCES]` line containing attachment IDs of the sources used. The method is responsible for: - Splitting the raw LLM message into content and the source line if any. - Fetching the associated `ir.attachment` records based on the IDs and linking their sources' urls to the response. task-id-5153916 Forward-Port-Of: odoo/enterprise#101463
This update fixes an issue where the bank reconciliation widget on the accounting side didn't update correctly when navigating through paginated records. The fix ensures that buttons and partner counts are consistently displayed on all pages, improving the user experience for managing bank reconciliations. This resolves a display problem that prevented accurate reconciliation tracking.
Original PR description
Issue: when navigating through paginated records in the bank reconcilliation widget the functions `computeReconcileLineCountPerPartnerId` and `computeAvailableReconcileModels` were not re-executed. This caused reconciliation model buttons and partner counts to disappear on pages after the first. steps to Reproduce: 1 - In a database with >80 records to reconcile and pre-existing reconciliation models: 2 - Go to Accounting -> N to reconcile button. 3 - In Kanban view expand a record to view reconciliation model buttons (displays correctly). 4 - Navigate to the next page. - From the second page onward, reconciliation model buttons and partner counts are not displayed. fix: on top of the `onWillStart` hook, which runs at the view is first rendered, I added `onRootLoaded` to ensure computations run whenever the dependencies change, updating the widget correctly on pagination. opw-5083877 Forward-Port-Of: odoo/enterprise#98916 Forward-Port-Of: odoo/enterprise#98127
This update fixes issues with the snailmail follow-up report, ensuring correct address formatting, cover page functionality, and proper PDF generation for sending. It now validates addresses and includes a cover page option, preventing potential delivery problems and providing users with feedback on report status.
Original PR description
#### [FIX] snailmail_account_followup: fix address, cover page and layout Currently there is the following potential problem when sending the followup report via snailmail. 1. The address generation…
#### [FIX] snailmail_account_followup: fix address, cover page and layout
Currently there is the following potential problem when sending
the followup report via snailmail.
1. The address generation is not adjusted for snailmail. That can
lead to problems with the service we use to send the actual letter.
They validate the address rather strictly.
2. The cover page option does not work; it does not add a cover page.
So we can not work around problems with the address generation
by adding a cover page.
3. The layout / dimensions / margins of the generated document / PDF may not work
with our current snailmail provider (Pingen). But there is no error
message about it. (Although we do have something in the usual
snailmail flow)
4. In case the address is invalid we do not try to "print" / send the letter,
so the user does not receive any feedback.
This could be an issue in case multiple follow-up reports are sent
at the same time.
This commit fixes these issues. (See below for details.)
(1)
The logic for this already exists but it is only activated when
a context key is set. This is not the case currently.
After this commit we do set the key.
(2) & (3)
The issue is that we generate the PDF attachment before creating the
'snailmail.letter' record.
In the usual snailmail flow the PDF attachment generation is handled during the sending and
printing (in function `_fetch_attachment` on model 'snailmail.letter').
There is some special logic to
- add a cover page to the report PDF (if the option is selected)
- make sure the page dimensions of the PDF are okay
- overwrite the margins of the PDF with white to make sure the PDF is
not rejected by Pingen because of this
But all this only happens if we do not have an attachment already.
(So it does not happen currently with the followup report)
For this a function called `_generate_report_pdf` was extracted from `_fetch_attachment`
in the related community commit to generate the report PDF (and its
filename). The function is extended here to be able to generate the
followup report.
(4)
We try to print / send the letter even if the address is invalid
Reproduce (i.e. for the cover page issue; but it explains how to get
the PDF that will be sent in general)
1. Install `snailmail_account_followup`
2. Create an overdue invoice
3. Set the "Add a Cover Page" option
(Settings -> Accounting -> section "Customer Invoices")
- enabled to test for the cover page
- disabled to test that the address generation is adjusted
4. Send a follow-up report:
- On 17.0: Accounting -> menu: "Customers" / "Follow-up Reports"
-> click on a line / partner -> button "Follow up"
- On 18.0+: partner form view -> tab "Accounting"
-> section "invoice follow-ups" -> button "Send"
5. Go to the snailmail letter:
In debug mode: Settings -> menu: "Technical" -> section: "Email" -> "Snailmail Letters"
(or just search for "snailmail" in the main screen)
And select the letter
6. Download the PDF document
#### [FIX] snailmail_account_followup: forbid regenerating failed letters
The wizard to resend failed letters which allows to change the
cover page option is broken: The follow-up report can not be regenerated
correctly because it requires special follow-up specific `options` that are
lost after the initial pdf generation for the letter.
Currently it can happen that the follow-up PDF is regenerated but
without (actual) content (table listing the overdue amounts).
After this commit we cancel the snailmail letters and show an
error notification indicating that the followup needs to be done again to
create a new letter.
Reproduce
(needs credit on IAP or locally edit this function https://github.com/odoo/odoo/blob/3ffd51f1cb18e3f4fb0367c4a498d7438e0c0357/addons/snailmail/static/src/core_ui/message_patch.js#L11
to open the resend wizard `this.openFormatLetterAction()` for `sn_credit` error or always)
1. Install `snailmail_account_followup`
2. Create an overdue invoice
3. Ensure the address of the partner causes issues with Pingen
4. Ensure the cover page option is disabled:
Settings -> Accounting -> section "Customer Invoices"
5. Send a follow-up report:
- On 17.0: Accounting -> menu: "Customers" / "Follow-up Reports"
-> click on a line / partner -> button "Follow up"
- On 18.0+: partner form view -> tab "Accounting"
-> section "invoice follow-ups" -> button "Send"
6. Make some modifications like editing the follow-up message or a custom attachment
7. Download the snailmail letter PDF (see previous commit for details)
8. In the chatter go to the message saying "Letter sent by post with Snailmai"
9. Click on the red symbol (paper plane) next to the name
10. A "Format Error" wizard should show up
11. Select "Add a Cover Page"
12. Click the button "Update Config and Re-Send"
13. Download the snailmail letter PDF (see previous commit for details)
14. Compare PDFs from 7 and 13; they are different (not just the cover page)
#### references
opw-5160121
opw-5209504
opw-5226366
Forward-Port-Of: odoo/enterprise#101737
Forward-Port-Of: odoo/enterprise#99491This update corrects a bug in the Czech VAT reporting module that incorrectly calculated VAT amounts. The fix ensures accurate reporting by properly handling foreign currency invoices and using the absolute value of the total amount for foreign currency transactions. This improves the reliability of Czech tax reports.
Original PR description
With l10n_cz_reports: - Create a currency exchange between CZK and EUR where the EUR is valued at least at twice the amount of CZK. - Create an invoice in EUR, with a line with price_unit 5000 and a tax. - In the CZ Tax Report, in the VAT control statement, the converted amount is found in section B.3, which contains received taxable supplies and provided payments up to CZK 10,000. However, the converted amount of the invoice in CZK is higher than 10,000. In `_report_custom_engine_control_statement`, the amount used to check whether the move should be included in this section uses `amount_total`, which in the case of foreign currency gives the wrong result. If the move is in a foreign currency the total is not in CZK so we have to use the absolute value of the signed total. opw-5080339 Forward-Port-Of: odoo/enterprise#100456
This update resolves a problem that prevented users from correctly setting accounting periods for tax returns when installing the accountant module. The fix ensures the necessary onboarding process is triggered, allowing users to configure their tax returns journal without errors. This improves the stability and usability of the tax returns feature.
Original PR description
From **saas-18.3**, when installing the accountant module, after [this PR](https://github.com/odoo/enterprise/commit/49aca723c2422fedcc8bda963a6346a172825617#diff-c703c688dc3f80644a43c96657cb2db0122b83cee9bcfa417554b0c7f1e4f550L22) the `_initiate_account_onboardings()` was not called anymore for companies that already had a chart template. This caused a traceback while configuring the Accounting Period on the Tax Returns journal: `ValueError - Expected singleton: onboarding.progress()` We now fix this behavior by ensuring that `_initiate_account_onboardings()` is called when installing the chart_template, filling the gap that was introduced. **Steps to Reproduce:** 1. Install `accountant` module without demo data. 2. Accounting > Dashboard > _Tax Returns_ Journal, click on the **"Tax Returns"** button. 3. Set an **Opening Date** in the wizard and try to apply the **Accounting Periods**. sentry-7064593163 Forward-Port-Of: odoo/enterprise#101442
This update expands the availability of the 'Emission Stat' button to all types of account moves, including Purchase Receipts, previously limited to Vendor Bills. This change ensures accurate emissions reporting across all financial transactions, improving the overall sustainability data captured within Odoo Enterprise.
Original PR description
Prior to this PR, we limited the display of the Emissions stat button of 'account.move' to Vendor Bills and Credit Vendor Bills ('in_invoice' and 'in_refund'). But emissions could be reported in other types of moves (e.g. Purchase Receipt), so we remove that condition.
task-5407761
Forward-Port-Of: odoo/enterprise#101906This update ensures that the status of Brazilian e-invoices is accurately reflected as 'cancelled' after a cancellation request is processed. Previously, the status field was left blank, causing confusion. The fix correctly updates the status within the EDI system, aligning with the expected e-invoice cancellation workflow.
Original PR description
**Steps to reproduce:** * Install the **Accounting** and **l10n_br_edi** modules. * Create and post a Brazilian customer invoice using an **Avatax fiscal position** * [Guide to setup EDI for…
**Steps to reproduce:** * Install the **Accounting** and **l10n_br_edi** modules. * Create and post a Brazilian customer invoice using an **Avatax fiscal position** * [Guide to setup EDI for l10n_br](https://docs.google.com/document/d/1CSUKpnyhty5WBqUDBE-7dGvu0qxaC5vQ0loz0fYNg04/edit?tab=t.0) * Confirm the invoice and **send it to e-invoice (Brazil)**. * Confirm the **Brazil E-Invoice Status** shows **'Accepted'**. * Click **Request Cancellation**, enter a cancellation reason, and submit the request. **Observed behavior:** * The invoice moves to **Cancelled** state. * The cancellation XML is generated and attached in the chatter. * SEFAZ returns a successful cancellation response. * However, the **BR EDI Status** becomes **empty**, instead of reflecting **'Cancelled'**. **Cause:** * In the wizard `l10n_br_edi.invoice.update`, both `_finalize_update()` and `_submit_services()` assign `l10n_br_last_edi_status = 'cancelled'` **before** calling `button_cancel()`. * `button_cancel()` internally triggers `button_draft()` for posted invoices. * The Brazil EDI override of `button_draft()` resets `l10n_br_last_edi_status = False`. * This clears the status that was just set, leaving the field blank. **Fix:** * move `l10n_br_last_edi_status = "cancelled"` to `button_cancel()` method. opw-5378542 Forward-Port-Of: odoo/enterprise#101438
This update resolves an issue where the accounting section in the payroll settings was limited to SEPA countries. Now, all localization options, including the Payroll HSBC Autopay option for Hong Kong, are available, ensuring consistent functionality across all Odoo Enterprise users. This improves usability and avoids limitations for non-SEPA countries.
Original PR description
Before this commit, the accounting section in V19 was exclusive to SEPA countries, causing some fields located in this section for other localizations to disappear. This was the case for the HK localization, which had the Payroll HSBC Autopay option inside this section, causing it not to appear, and also prevented the Batch account move lines option from being available for non-SEPA countries. With this commit, the accounting section and the Batch account move lines option are available for all localizations. This was already fixed in the master here is the PR in question odoo/enterprise#96283 task - 5268780 Forward-Port-Of: odoo/enterprise#100004
This update corrects a previous issue where employee wages were incorrectly adjusted when benefits like mobility budgets or holidays were selected. Now, the wage remains consistent, only the yearly cost is updated based on selected benefits, simplifying payroll calculations and improving accuracy. This change streamlines the salary configuration process.
Original PR description
This commit fixes a regression introduced in https://github.com/odoo/enterprise/pull/96094 where wage was modified when selecting the mobility budget or holidays. In backend employee form view, the…
This commit fixes a regression introduced in https://github.com/odoo/enterprise/pull/96094 where wage was modified when selecting the mobility budget or holidays. In backend employee form view, the wage should stay identical when changing benefits. Only the yearly_cost should be adapted. Also include the holidays in that process. As only the final yearly cost will change on benefit/advantage/sacrifice opt in/out, the wage and the wage on payslip are now identical. so wage_on_payslip can be deleted. The simplifies a lot the whole thing: - Wage is fix. depends on yearly costs. - Yearly cost depends on wage + all benefit/advantage/sacrifices When setting the final yearly cost manually, the wage is recomputed via the inverse method. But otherwise, the wage won't ever be modified. For salary configurator, this means that when creating a new version with all the benefit/advantage/sacrifices selected by the applicant, we only need to ensure that the final yearly cost is the one from the offer. so that every other amount (wage / Mobility budget / 13th month / double holiday pay / etc..) will be computed accordingly. Task-5387236
This update resolves an issue where customer displays weren't updating after orders were added. The fix ensures the correct POS instance is used, guaranteeing that order information is accurately reflected on the display. This improves the customer experience and prevents order discrepancies.
Original PR description
Step to reproduce: -Open customer display -Add products => The customer display doesn't update Fix: Replaced arguments with an explicit pos parameter to ensure the correct POS instance is forwarded.
This update resolves several issues related to the POS Blackbox feature, primarily focusing on printing receipts and product loading. Specifically, it prevents duplicate TVA ticket prints and ensures correct receipt types are generated after Self-Order payments, enhancing the accuracy and reliability of the POS system.
Original PR description
- Prevent multiple TVA ticket prints on Feedback Screen by limiting `canPrintReceipt` to a single print when Blackbox is active. - Ensure Blackbox work in/out products are loaded in Self-Order (`_load_pos_self_data_read`), preventing fiscal products from appearing in Kiosk/Self. - Correct receipt type after Self-Order payment: use `blackbox_signature` to avoid printing PRO FORMA for valid signed sales. task-id: 5410921
This update fixes an error in how audit status is calculated for financial reports across multiple languages (e.g., French, German, Chinese). The previous calculation used incorrect settings, leading to inaccurate reporting. This change ensures accurate audit status indicators are displayed for financial reports.
Original PR description
When computing allow_account_audit_status_on_lines, we used the wrong field_name and default_value. Removed all the localized value as this fix should have been the one done in the first place. task-5106852 Forward-Port-Of: odoo/enterprise#101708