Daily updates from Odoo
Tuesday, September 23, 2025
34 changes · saas-18.3
Resolved issues and error corrections
Fixed an issue in the HTML editor where changing a linked item between numbered and bulleted list styles could cause an error. Users can now edit list formatting in To-Do content more reliably without interruptions.
Original PR description
Steps to Reproduce: 1. Go to To-Do 2. Create a link 3. Select all using Ctrl + A 4. Switch to order list and then unordered list. 5. Traceback occurs Description of the issue: - This issue occurs because a feff (zero-width no-break space) character is present inside the link. When the link is inside a list and the list type is changed, the `removeFEFF` method is triggered. `removeFEFF` removes the feff characters, but the selection is preserved based on positions from when those feffs were still present inside the link. As a result, after the list type is changed, restoring the selection causes a traceback. Solution: - Triggered `clean_handlers` before preserving the selection. This ensures feff characters are removed from the link before the selection is preserved, preventing invalid selection offsets and avoiding the traceback. task-5095561 Forward-Port-Of: odoo/odoo#227680
Odoo now protects the default barcode setup record from being deleted. This prevents crashes when users disable and re-enable the Barcode Scanner setting, keeping inventory barcode configuration reliable.
Original PR description
The system will crash with error when user tries to enable barcode scanner in settings. **Steps to produce: -** - Install `Inventory` module. - `Inventory > configuration > products > Barcode…
The system will crash with error when user tries to enable barcode scanner in settings.
**Steps to produce: -**
- Install `Inventory` module.
- `Inventory > configuration > products > Barcode Nomenclatures`.
- Delete the `Default Nomenclature` record.
- Go to settings uncheck `Barcode Scanner` and save settings.
- Now, again `enable` that and save.
Error: -
```py
ValueError: External ID not found in the system: barcodes.default_barcode_nomenclature
ParseError: while parsing /home/odoo/src/enterprise/saas-18.4/stock_barcode/data/data.xml:40, somewhere inside <record id='scale_up_alias_1' model='barcode.rule'>
<field name='name'>Scale Up Receipt</field>
<field name='type'>alias</field>
<field name='pattern'>WH-RECEIPTS</field>
<field name='alias'>WHIN</field>
<field name='barcode_nomenclature_id' ref='barcodes.default_barcode_nomenclature'/>
<field name='sequence'>0</field>
</record>
```
**Root cause: -**
- At [1], the records use the ref of `default_barcode_nomenclature` which is defined in barcode module. So, when the ref is deleted and we are trying to use it then it gives error.
**Solution: -**
- This commit resolves the error by prevent the deletion of `default nomenclature`.
[1]: https://github.com/odoo/enterprise/blob/400171c9cebc46ecdd907ada210c65f3bbd2dd66/stock_barcode/data/data.xml#L40-L71
**sentry-6823596992**
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#226594Timesheet users can now edit the Time Spent value in list view and move focus away without the field reverting to the previous value. This prevents confusion and helps ensure newly entered or adjusted time remains visible before saving.
Original PR description
Steps to reproduce: ----------------- 1. Go to Timesheet → My Timesheet → List View → New OR Edit already filled time. 2. Change time in the Time Spent field. 3. Press Shift + Tab. Observation:…
Steps to reproduce: ----------------- 1. Go to Timesheet → My Timesheet → List View → New OR Edit already filled time. 2. Change time in the Time Spent field. 3. Press Shift + Tab. Observation: ----------------- The focus changes, but the Time Spent field reverts to its old value instead of keeping the newly entered one. Issue: ----------------- - For new records, the component retrieves the value only from the state, which is updated in the `onWillUpdateProps` lifecycle. This lifecycle triggers only on saving or editing, not when simply changing focus. https://github.com/odoo/enterprise/blob/e14b991927df14f41535e92dd01ea2ecac44a404/timesheet_grid/static/src/components/timesheet_display_timer/timesheet_display_timer.js#L123-L128 - The same behavior occurs when editing existing records, leading to incorrect value display. https://github.com/odoo/enterprise/blob/e14b991927df14f41535e92dd01ea2ecac44a404/timesheet_grid/static/src/components/timesheet_display_timer/timesheet_display_timer.js#L31-L33 Solution: ----------------- - For new records, since the default value is 0, the fix makes the component fall back to the updated record value if the state value is not yet available. - For existing records, if the timer is running, the timer’s value is displayed. otherwise, the component falls back to the updated record value. opw-4922847 Forward-Port-Of: odoo/enterprise#95141 Forward-Port-Of: odoo/enterprise#94729
Credit notes for Mexico’s general public tax regime now keep the selected “Returns, discounts or bonuses” usage when allowed by current SAT rules. This prevents XML documents from being generated with the wrong usage value, helping businesses issue compliant credit notes without manual correction.
Original PR description
**Steps to reproduce:** 1. Install `l10n_mx` and `l10n_mx_edi`. 2. Create an invoice with: * Enable *CFDI to Public*. * Confirm, then send to SAT. 3. Create a credit note with: * *Usage* = `Returns,…
**Steps to reproduce:** 1. Install `l10n_mx` and `l10n_mx_edi`. 2. Create an invoice with: * Enable *CFDI to Public*. * Confirm, then send to SAT. 3. Create a credit note with: * *Usage* = `Returns, discounts or bonuses` (G02). 4. Download the generated XML for the credit note. **Observed behavior:** - The `<UsoCFDI>` tag in the XML shows `S01` (No fiscal effects). **Expected behavior:** - The `<UsoCFDI>` tag should show `G02` for credit notes under regime 616 when explicitly selected. **Root cause:** - For regime 616 (`Público en general`), the code always defaults to `S01`. - The condition only allowed `G02` when refunding a global invoice (`is_refund_gi`), not for normal credit notes. **Solution:** - Allow `G02` usage to be preserved for credit notes (tipo_de_comprobante = 'E') even when `CFDI to public` is active, as this is now permitted by SAT regulations for fiscal regime 616. **ref:** http://omawww.sat.gob.mx/tramitesyservicios/Paginas/documentos/catCFDI_V_4_20250820.xls opw-5012917 Forward-Port-Of: odoo/enterprise#93071
Field service sales orders with zero-priced service lines now correctly show as invoiced after the related invoice is created and posted. This prevents orders from remaining incorrectly marked as needing invoicing, reducing confusion during billing follow-up.
Original PR description
Steps: - Install sale and fsm module. - Enable anglo-saxon from the setting. - Create a service type product with fsm project as template. - Select that product on SO and set unit price to 0 on SOL. - Confirm that order and create and post invoice. Issue: - Sale order status still shows `To invoice` even though we create SOL related invoice. Cause: - In [PR] we made invoice status for anglo-saxon line `To Invoice` so it always say `To Invoice` even user create related invoice. Fix: - Make those lines `Invoiced` if there is related invoice by checking qty_invoiced is greater or equal to qty. [PR]: https://github.com/odoo/enterprise/pull/70132 opw-5055540 Forward-Port-Of: odoo/enterprise#94723
This change fixes an access problem in the self-ordering feature that could block public users from completing expected actions. It helps keep the customer ordering flow reliable without requiring unnecessary sign-in or extra permissions.
Original PR description
bypass Public user ACLs. build_error-231606
Timesheet reports printed from a sales order now show the related helpdesk ticket name alongside the helpdesk team. This makes billed support work easier to identify and verify for customers and internal teams.
Original PR description
to reproduce: ============= 1. make helpdesk team billable and records timesheets 2. create a helpdesk ticket and link it to a sale order 3. log timesheets on the ticket 4. print the timesheet report…
to reproduce: ============= 1. make helpdesk team billable and records timesheets 2. create a helpdesk ticket and link it to a sale order 3. log timesheets on the ticket 4. print the timesheet report **from the sale order** -> the task column will contain only the helpdesk team name, while it should contain "helpdesk team / ticket name" Problem: ======== in helpdesk_timesheet we inherit `hr_timesheet.timesheet_table` to adapt it to helpdesk tickets, but we use `show_ticket` to display the ticket name, which is only set in `hr_timesheet.report_timesheet` and `hr_timesheet.timesheet_project_task_page` but not in `sale_timesheet.timesheet_sale_page` which is the one used when printing the report from the sale order. Solution: ========= `show_ticket` should be set with value `bool(lines.helpdesk_ticket_id)` which is equivalent to `line.helpdesk_ticket_id` in the t-if condition. so we can directly use `line.helpdesk_ticket_id` and remove the `show_ticket` variable. opw-5002650 Forward-Port-Of: odoo/enterprise#95179
A date used in the product margin test was corrected to keep automated checks reliable. This helps prevent false test failures and supports smoother maintenance without changing business functionality.
Original PR description
runbot-230719 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227210 Forward-Port-Of: odoo/odoo#226089
Sendcloud shipments can now include longer customs classification codes, matching the carrier API limit. This helps avoid customs delays for affected international parcels, especially shipments to the US.
Original PR description
**PROBLEM** We limit the `hs_code` length to 8 characters, but if we refer to the [sendcloud v2 api doc](https://api.sendcloud.dev/docs/sendcloud-public-api/branches/v2/parcels/schemas/parcel-item), we see that `hs_code` length can be up to 12 characters. Some clients have issue with parcels being held longer in custom when sending them to the US. [opw-5051585](https://www.odoo.com/odoo/project/49/tasks/5051585) Forward-Port-Of: odoo/enterprise#94894
Field service tasks now create sales orders using the product's currency when calculating line prices. This ensures prices are converted correctly when the product and sales order use different currencies, preventing incorrect billing amounts.
Original PR description
### Steps to reproduce: - Open Field Service module. - Create a new task. In the Customer field, select “Bloem GmbH”. - Open the task’s project. - In the Invoicing tab, create a new line for any…
### Steps to reproduce: - Open Field Service module. - Create a new task. In the Customer field, select “Bloem GmbH”. - Open the task’s project. - In the Invoicing tab, create a new line for any employee and any service. - Return to the task and in the Timesheets tab, add a new timesheet. - Click the Mark as done button. - Click the Sales order button. ### Cause: When creating the sale order out of the fsm task we use _get_tax_included_unit_price to get the price of the SO line but we are passing the order currency twice to this method so it doesn't convert the price as when it checks the currency and the product_currency it found they are the same so no need to convert https://github.com/odoo/odoo/blob/6653355b8bc063ceadf08af17fbf2c4a250553e6/addons/account/models/product.py#L239-L240 ### Fix: We pass the product currency instead of the order currency in order to be able to convert the price according to the currencies opw-5045071 Forward-Port-Of: odoo/enterprise#95134 Forward-Port-Of: odoo/enterprise#94947
This fixes missing timesheet entries when public holidays are deleted or their work calendar changes after employee leave has already been approved. Businesses get more reliable time tracking and fewer manual corrections around holiday and leave overlaps.
Original PR description
…ay change **Steps to reproduce** - Create a public holiday without a calendar during a work day. - Create a leave for an employee overlapping the public holiday for a time off type generating…
…ay change **Steps to reproduce** - Create a public holiday without a calendar during a work day. - Create a leave for an employee overlapping the public holiday for a time off type generating Timesheets. Validate it. - Expected: on the day of the public holiday, no timesheet is generated for the `hr.leave` to avoid duplication. - Either delete the public holiday, or set a calendar on it different than the one defined on the employee. - Issue: the public holiday timesheet has been deleted, but its deletion should've lead to the creation of the `hr.leave` timesheet that we didn't create at the time the public holiday existed. - Second issue: after that, change the calendar of the public holiday to the same as the employee's. Still a missing timesheet. **Solution** We can use `_reevaluate_leaves` to find the leaves affected by changes in public holidays. `_generate_timesheets` then re-generates the timesheets as if the leave was just validated (the call to `list_work_time_per_day` ignores the already present resource.calendar.leave). We also check missing public holidays timesheets to fix the second issue. opw-4819697 Forward-Port-Of: odoo/odoo#225066 Forward-Port-Of: odoo/odoo#216901
This fix stops Argentina partner records from crashing when an invalid VAT or identification value is entered. It makes data cleanup more reliable and helps users continue working even when tax ID inputs contain unexpected characters.
Original PR description
Manual backport of https://github.com/odoo/odoo/commit/b01a6640895c4dd4b5bcf849740aa6b3312e9a54. This is needed to prevent crashes when trying to sanitize invalid VAT inputs for Argentina partners due to the assumption that the identification number can always be safely cast to int(). --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223661
This fix stops users from editing the amount in currency on posted journal items where it could leave invoices with inconsistent totals and related analytic data. The field is now only editable for tax lines while the entry is still in draft, helping preserve accurate accounting records.
Original PR description
- Create an invoice with some products and post it - Go to Accounting > Journal items and ser for the ones belonging to the invoice. - Set the checkbox for the product sales one and set whatever tax…
- Create an invoice with some products and post it - Go to Accounting > Journal items and ser for the ones belonging to the invoice. - Set the checkbox for the product sales one and set whatever tax grid (you'll have to reveal that column). - Accept the changes. - Now go back to the invoice. - You'll see a new tracking message. Something like Journal Item #1093 updated - It contains a link and from that link you can go to the journal item form. - In that form you can edit the *amount in currency* field. Issue: - If a user do so, it leaves inconsistent invoice amounts: totals aren't recomputed, analytic lines aren't recomputed either. How it should behave: - Amount in currency shouldn't be editable here. Mainly when the journal entry is already posted! opw-4951629 A vídeo showing the issue: 📹️ https://www.loom.com/share/f7cd1d8f4138458f9b6c190233b0b9df?sid=eec77c17-a4a6-4698-8604-10aaa7e33f47 MT-10887 cc @moduon --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225346 Forward-Port-Of: odoo/odoo#223187
Invoice imports now avoid linking lines to unrelated products when the item name is very short, such as “-” or “a”. This reduces incorrect product assignments on imported accounting documents and improves data accuracy.
Original PR description
hen resolving a product in _retrieve_product, the code searched by barcode, default_code, and then by name using both exact and ilike domains. For very short item names coming from imports (e.g., “-”, “A-1”, “0001”), the ilike fallback could match unrelated products whose names merely contain that short string. this led to incorrect product linkage on created documents (e.g., EDI-imported invoices). discussed with: Christophe (chkl) Steps to reproudce: Accounting -> Invoices upload an XML with a product name liek `-` or `a` See the product attched to the invoice line. opw-5003482 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225143
Odoo now avoids crashing when printing PDF quotations for multiple sales orders if one of the selected orders cannot generate a valid PDF. Incomplete or problematic orders are skipped so users can continue producing quotations for the rest of the selection.
Original PR description
Description of the issue/feature this PR addresses: This PR addresses a KeyError that occurs when attempting to generate a PDF quotation for multiple sales orders at once in Odoo. The issue arises…
Description of the issue/feature this PR addresses: This PR addresses a KeyError that occurs when attempting to generate a PDF quotation for multiple sales orders at once in Odoo. The issue arises when one or more selected orders do not have a valid PDF stream (e.g., due to missing data like order lines or incorrect templates). The error occurs because the system tries to access result[order.id]['stream'] for a sales order that doesn't have the stream generated, causing the server to fail. Current behavior before PR: Before this PR, when attempting to print the quotation for multiple sales orders, the system will throw a KeyError if any of the selected orders do not have a valid PDF stream generated. This can happen if a sales order is missing data (such as products or a client) or has an incomplete quotation template. The error prevents users from generating quotations for a group of sales orders, even if only one order is missing the necessary data. Desired behavior after PR is merged: After merging this PR, the system will check if the PDF stream exists before attempting to access it. If a sales order does not have a valid stream (due to missing data or other issues), it will be skipped without causing a server error. This allows users to print multiple quotations at once without the system failing due to one incomplete order. The feature will improve robustness when handling orders with missing or incomplete data and prevent unexpected crashes. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227517 Forward-Port-Of: odoo/odoo#227347
The website search suggestions dropdown now chooses the side of the search bar with the most available space. This prevents suggestions from appearing in a cramped area, improving usability for shoppers using high zoom levels or smaller browser windows.
Original PR description
Scenario: - go to /shop - increase zoom to 175% (or decrease height of window) - search "a" and let the suggestions dropdown open Result: the dropdwon menu is shown on top of the search bar, where…
Scenario: - go to /shop - increase zoom to 175% (or decrease height of window) - search "a" and let the suggestions dropdown open Result: the dropdwon menu is shown on top of the search bar, where there is the less space available. Cause: When the dropdown doesn't fit fully in the viewport below the searchbar it is always added on top even if there is less space available. The code was added in 15.0 62c265ee7d7cf36db01bf6a95b2c5ea9843ba2d3 with the intent of putting the dropdown on the top if it increased the page height when putting it below (eg. when we put a search bar in the footer). But in saas-18.2 refactoring (b9b3a605e0f4c5da3a258c980107d6162da7f44f), the code was rewritten and now: - the dropdown has a scroll bar if it is too big to fit on viewport - if the dropdown doesn't fit fully below the searchbar in the viewport, it is placed above the searchbar even if there is less space Fix: place the dropdown below the searchbar if there is more space below than above. opw-5019685 Forward-Port-Of: odoo/odoo#225220
The Spanish Modelo 130 report now uses an end-date selection instead of a date range. This prevents users from expecting results for only a selected range when the report is designed to calculate from the start of the fiscal period, reducing confusion in tax reporting.
Original PR description
Currently mod130 report is configured to compute from the beginning of the fiscal period, however the date filter widget is in range mode. This means that when a user open the report and select a date range, the entries will not be just in the selected range but span from the beginning of the fiscal year to the end of the range, creating confusion. We should disable filter date range, so the date widget allow to set an end date to the current period Enterprise PR: https://github.com/odoo/enterprise/pull/90044 opw-4933241 Forward-Port-Of: odoo/odoo#226177 Forward-Port-Of: odoo/odoo#218544
This update adds test coverage for the Spanish Modelo 130 tax report to help ensure it continues to calculate and display correctly. It reduces the risk of regressions in Spanish tax reporting after future changes.
Original PR description
opw-4933241 Forward-Port-Of: odoo/enterprise#94251 Forward-Port-Of: odoo/enterprise#90044
The point of sale payment screen now correctly disables the Validate button on mobile when no payment method is selected. This helps prevent checkout mistakes and gives cashiers clearer guidance during mobile payments.
Original PR description
- Fix issue where the `Validate` button (in the payment screen) was not correctly disabled on mobile devices when no payment methods was selected. task-id: 5072759 enterprise PR: https://github.com/odoo/enterprise/pull/94100 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225975 Forward-Port-Of: odoo/odoo#225917
This change prevents public website visitors using older Safari versions from seeing a crash when pages load. It adds browser compatibility support needed for translation caching, improving reliability for affected users without changing normal functionality.
Original PR description
Safari < 17 (09/2023) doesn't support Set.difference. This function is used in our indexeddb wrapper, which runs also in the frontend, even for public (non logged-in) users, to fetch and cache translations. As a consequence, those people have a crash at each page launch. Safari 17 being recent enough for public users, we add a polyfill (for frontend only). Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The point of sale payment screen now correctly keeps the Validate button disabled on mobile when no payment method has been selected. This prevents cashiers from accidentally proceeding with incomplete payments and improves checkout reliability on mobile devices.
Original PR description
- Fix issue where the `Validate` button (in the payment screen) was not correctly disabled on mobile devices when no payment methods was selected. community PR: https://github.com/odoo/odoo/pull/225917 task-id: 5072759 Forward-Port-Of: odoo/enterprise#94132 Forward-Port-Of: odoo/enterprise#94100
Brazilian service invoices using AvaTax now send installment amounts without tax values, preventing mismatches that could cause invoice rejection. This improves reliability when processing service invoices with installment payments.
Original PR description
Service invoices require us to send installments without taxes. If we include taxes we get an error: **Errors**: Rejection: Total Installments doesn’t match Total Lines ∑ installments[m]grossValue - ∑ (lines[n].lineAmount-line[n].lineTaxedDiscount) <> 0 This **PR** clears taxes before tax calculation to ensure the installments we send are correct. **task**-4761630 Forward-Port-Of: odoo/enterprise#95244 Forward-Port-Of: odoo/enterprise#85108
Large online stores can now generate product sitemaps without exhausting server memory. This helps prevent crashes caused by search engine crawlers repeatedly requesting sitemaps for very large catalogs.
Original PR description
### Issue Server crashes with MemoryErrors when a database has a large product catalogs. ### Solution This commit disables the prefetcher to avoid MemoryErrors when generating the sitemap for large product catalogs as web crawlers would continously crash the server when requesting the sitemap. ### References opw-5001680 opw-4955333 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223054
Appointments linked to resources now appear in the calendar views where users expect to find them. This restores visibility after the removal of the previous “Everybody’s Calendar” option, helping teams manage resource bookings without missing scheduled appointments.
Original PR description
**Steps to reproduce:** - Install Appointment app - Create a new resource - Create an appointment type with the new resource - Create an appointment for this type - Go to the Calendar app or to Appointments > Schedule > Resources Bookings - Click on the calendar view - The new appointment can't be found **Issue:** As "Everybody's Calendar" option was removed, there is currently no way to display the appointments on resources in the calendar view. **Fix:** Added a `calendar.resource.filters` model and its flow to the calendar view. It was also necessary to revert the parallel fetching of filters in https://github.com/odoo/odoo/commit/aa5f2d5dc3b7c64217cea57535b04261e801c4d2 to ensure the order of filters remains constant. related: https://github.com/odoo/odoo/commit/08ceb41a47de5ee1a0758eb0ebba3a3c6964a2f9 opw-4964405 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Appointments linked to resources can now be found and displayed in the calendar view again. This restores visibility for resource bookings after the previous shared calendar option was removed, helping teams manage appointments without missing bookings.
Original PR description
**Steps to reproduce:** - Install Appointment app - Create a new resource - Create an appointment type with the new resource - Create an appointment for this type - Go to the Calendar app or to Appointments > Schedule > Resources Bookings - Click on the calendar view - The new appointment can't be found **Issue:** As "Everybody's Calendar" option was removed, there is currently no way to display the appointments on resources in the calendar view. **Fix:** Added a `calendar.resource.filters` model and its flow to the calendar view. related: https://github.com/odoo/odoo/commit/08ceb41a47de5ee1a0758eb0ebba3a3c6964a2f9 opw-4964405
The point of sale settlement tests no longer rely on a fixed calendar year when choosing invoices to settle. This makes automated checks more stable over time and helps prevent false failures that could slow down future releases.
Original PR description
Remove hardcoded year date for selecting invoices to settle. rb-error: 230713 community PR: https://github.com/odoo/odoo/pull/224171
Cancelling a sales order after creating multiple nested returns no longer triggers a system crash. This improves reliability for teams handling returned deliveries and prevents disruption during order cancellation.
Original PR description
The system crashes with a `RecursionError` during the `Sale Order` cancellation with nested `returns`. **Steps to produce:-** - Install the `Purchase Stock` and `Sales` modules. - Create a new `Sales Order` (SO) with `Product A`. - Confirm the `Sales Order` and click on the `Delivery` button. - Click on `Return > Return all`. - In the new window, also click on `Return > Return all`. - Return to the `Sales Order` and attempt to `Cancel` it. **Error:-** `RecursionError: maximum recursion depth exceeded` **Solution:-** - Added a check for the self not already visited in the method `_get_upstream_documents_and_responsibles` to prevent revisiting the same move multiple times and `avoid infinite recursion`. **Sentry - 6693197358** I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227992 Forward-Port-Of: odoo/odoo#217113
This fix removes a hardcoded year used when selecting invoices to settle in point of sale localization tests. It helps keep automated checks reliable over time, reducing false failures without changing business workflows.
Original PR description
Remove hardcoded year date for selecting invoices to settle. rb-error: 230713 enterprise PR: https://github.com/odoo/enterprise/pull/93166 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The bank reconciliation report now excludes currency adjustment entries that do not represent real bank money movements. This prevents exchange rate adjustments from appearing under miscellaneous operations, making the report clearer and more accurate for foreign-currency bank journals.
Original PR description
**Steps to reproduce** - Have foreign currency with rates for date 1 and date 2 - Have a Bank journal in foreign currency - Register a transaction in date 1 - In date 2 open the unrealized currency report - Create the adjustment entry - From the Accounting dashboard Bank[EUR] > Reconciliation report **Issue** The adjustment entry difference is present under the 'Misc. operations' line. This occurs because we look for journal entries hitting the bank account but that specific entry should not be reported as it does not represent a bank in/out operation A solution is to exclude the exchange entry journal, so any operation reported there is not taken into account in the report opw-4867870 [Ticket link](https://www.odoo.com/odoo/project/49/tasks/4867870) Forward-Port-Of: odoo/enterprise#94172 Forward-Port-Of: odoo/enterprise#93999
This change fixes an inconsistent accounting test caused by duplicate domestic fiscal position candidates. It removes an invalid test assumption and adds a safeguard to warn if future localization data introduces the problematic case.
Original PR description
#### Issue: `test_domestic_fp` randomly fail #### Cause: While computing domestic fiscal position, there are 2 fiscal position candidates for being domestic as they got the same `sequence` and no `country_id`. It happens randomly that the second one is fetch instead of the first one. #### Solution: The failing assert checks a case that doesn't exist in any fiscal position data. Therefore, this commits remove this part of the test, but add a warning in `test_all_l10n` to ensure this case won't happen in new data. runbot-231686 This PR is linked to [this PR](https://github.com/odoo/odoo/pull/224599) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix reorganizes editor tests so each check has its own timeout instead of sharing one combined limit. It reduces random test failures in automated validation, helping keep development and release checks more stable without changing user-facing behavior.
Original PR description
Grouping multiple `testEditor` in a single `it` is bad practice because the timeout of `it` is then shared between the different `testEditor` calls rather than each having their own separate timers. Technically, only the web_edior tests ever timed out, but I split the html_editor ones as well for good measure. runbot-231687 Forward-Port-Of: odoo/odoo#227985
POS receipts now display preset information, such as customer addresses or time slots, centered in the receipt header. This improves receipt readability and provides a cleaner presentation for customers.
Original PR description
We now want to center preset infos on receipt header (customer address or time slot) in POS. task-id: 5048706 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Mexican e-invoicing flow now handles customer names entered with accents in the self-invoicing portal. This prevents valid invoice requests from failing when government records store the same legal names without accents.
Original PR description
Currently, the self-invoicing portal lets client request an invoice after making a purchase in PoS. A form allows them to enter their personal informations such as their name. Many of them enter their name with accents, however the government has all the names without any accents which causes errors when trying to match the requesting party with their legal name during the stamping process of the CFDI. task-4952174 Forward-Port-Of: odoo/enterprise#95207
Refreshing appointment time slots now handles cases where no resource is selected. This prevents errors when checking maximum capacity, helping customers continue booking appointments without interruption.
Original PR description
When refreshing the slots, it's possible that the resource_selected_id is equal to None, False or just empty string. This was leading to some error when parsing it to an integer. This commit move the parsing into the method computing the max possible capacity after checking if we got a value. Related commit 3cca7e47ab58f8a7d4e9196dbf60f7068348216b task-5102895 Forward-Port-Of: odoo/enterprise#95144