Tuesday, September 23, 2025
32 changes · 19.0
New functionality added to Odoo
Point of Sale now supports using iMin printers for receipt printing. This helps businesses using iMin hardware print customer receipts directly from Odoo, though kitchen printing is not supported yet.
Original PR description
This module enables the use of iMin printers in the Point of Sale. Note: Currently, iMin printers are only supported as receipt printers and cannot be used as kitchen printers. task-5018605
Enhancements to existing features
The website generator now handles the updated eCommerce building blocks introduced in Odoo 19.0. This keeps generated websites compatible with the latest version and avoids issues caused by older scraping logic.
Original PR description
Corresponding IAP PR: https://github.com/odoo/iap-apps/pull/1196
Resolved issues and error corrections
The Spanish SME balance sheet report now avoids counting the same payable accounts twice. This ensures the “Other current payables” total reflects the real accounting balance, improving accuracy for financial reporting.
Original PR description
In **`balance_pymes_line_32300`** (`CURRENT LIABILITIES > Current payables > Other current payables`), amounts are **doubled** because account **551** is included twice. * **Formula using…
In **`balance_pymes_line_32300`** (`CURRENT LIABILITIES > Current payables > Other current payables`), amounts are **doubled** because account **551** is included twice.
* **Formula using `account_codes`:**
```xml <field name="formula">-1034 - 1044 - 190 - 192 - 194 - 500 - 501 - 505 ...551 - 5566 - 5595 - 5598 - 560 - 561 - 569</field> ```
→ Explicitly includes account **551**.
* **Formula using `domain`:**
```xml <field name="formula" eval="['|', ('account_id.code','=like','550%'), '|', ('account_id.code','=like','551%'), '|', ('account_id.code','=like','554%'), ('account_id.code','=like','5525%')]"/> ```
→ Includes **all accounts starting with 551**, so **551** is also counted here.
This overlap causes the balance to be counted twice, inflating the reported value.
**steps to reproduce:**
1. With a Spanish company, go to **Accounting > Dashboard > Bank > Transaction > New**.
2. Select an account, search for **55100**, and add it.
3. Go to **Reporting > Balance Sheet > Other current payables**.
4. Notice that the reported amount is **double** the actual accounting data.
Overlapping formulas: specific account `551` and `5525` are counted in `account_codes`, while the `domain` formula already includes `551%`, leading to duplication.
**Fix**
Remove explicit account codes from `account_codes` if they are already covered by the `domain` prefixes to avoid double-counting. and also made sure to correct the same issue in the whole report.
opw-5075035
Forward-Port-Of: odoo/enterprise#94494This fix prevents users from deleting the default barcode setup that other barcode features depend on. It avoids crashes when re-enabling barcode scanner settings, keeping inventory barcode configuration stable.
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#226594Field service sales orders with zero-priced service lines now correctly show as invoiced once the related invoice is created and posted. This prevents orders from incorrectly remaining marked as needing invoicing, giving teams a more accurate view of billing status.
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
Survey live session leaderboards now show score changes in a clearer sequence, so participants can better understand how points are added after each question. The leaderboard display size was also adjusted to prevent scores from appearing cramped or incorrect.
Original PR description
The way the score bars were animated was a bit confusing. We simplify the animation by: - Showing the score accumulated so far without the question - Animating the score bar towards the accumulated…
The way the score bars were animated was a bit confusing. We simplify the
animation by:
- Showing the score accumulated so far without the question
- Animating the score bar towards the accumulated score with the question
- Animating the numerical score on the left towards the accumulated score with the question while fading the numerical score increment on the bar ("+ x p")
- (reordering participants)
We also fix the size of the leaderboard as it was too small to display the score correctly.
How to reproduce
- Create a scored survey with time reward
- Add a question to get the name and toggle the nickname option
- Add a question with an answer that grants n points
- Start a live session
- After a user has completed the question
- Display the leaderboard
The score animation is confusion as it was going through:
- Showing the score accumulated so far without the question
- Animating towards 0: showing a minimal bar due to the minimum size of the score bar
- Animating towards the score question (on top of the minimal bar)
- And finally adding the score accumulated so far without the question
Task-4893763
Forward-Port-Of: odoo/odoo#224996Website form file upload fields now respect the configured maximum number of files. This lets visitors upload multiple files when allowed, while preventing invalid limits below one.
Original PR description
Steps to Reproduce: - Open the website module. - Drop a basic form snippet. - Change the field type of any field to 'File Upload'. - Set the `Max # of files` to any value greater than 1 and save the changes. - Attempt to upload more than one file. Observed Issue: Users are unable to upload more than one file. Before this commit: The `Max # of files` option available in the snippet settings had no effect. Even when set to more than one, the file input would only allow replacing the previously uploaded file, preventing users from adding multiple files. After this commit: The `Max # of files` setting now functions as intended. When the limit is set to more than one, users can select multiple files, up to the configured limit and within the maximum file size. If the limit is set to one, users can only upload a single file. task-4626847 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226219
Older Safari browsers could crash when public users opened pages because a browser feature needed for translation caching was missing. This change adds a frontend compatibility fallback so those visitors can load pages normally.
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
This fix prevents users from editing the foreign currency amount on posted invoice journal items except where it is safe and intended. It helps keep invoice totals and related analytic accounting data consistent after an invoice has been posted.
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
Sendcloud shipment data now allows customs HS codes up to 12 characters, matching Sendcloud's current API limits. This helps avoid issues where parcels, especially shipments to the US, could be delayed in customs because longer valid codes were cut off or rejected.
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
Timesheet entries in list view now keep the newly entered time when users move focus with Shift+Tab. This prevents confusion and avoids showing outdated time values while creating or editing timesheets.
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
Field Service sale orders now calculate service line prices using the product's currency before converting to the customer's sales order currency. This prevents incorrect pricing when tasks generate sales orders involving products and orders in different currencies.
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
Printing PDF quotations for multiple sales orders now handles incomplete orders more safely. If one selected order cannot generate a valid PDF, it is skipped instead of stopping the whole batch with an error, helping users complete bulk quotation printing more reliably.
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
This fix prevents IoT boxes from getting stuck after a power loss or crash during an update checkout. It clears a leftover lock file before retrying, helping devices resume updates without manual intervention.
Original PR description
Before this commit, if the IoT box were to crash or lose power during a git checkout, it would then become stuck unable to checkout again due to the lockfile never being deleted. After this commit, we remove the lockfile if it exists to ensure we can't get stuck in this way. task-5059113 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226903
Fixed an issue where selection lists could show missing results after a user changed related information, such as switching a country in an address form. This ensures users see the correct suggestions without needing to refresh or retry.
Original PR description
Some web_name_search calls in Many2XAutocomplete were incorrectly cached. The cache key only took into account the latest empty search input, while ignoring changes in the domain or context of the search. As a result, changing the domain or context (e.g., selecting a country without states, then switching to USA) could lead to missing results — for instance, no states being suggested in the partner address form.
This fix ensures POS receipts are sent to the receipt printer configured for the point of sale, even when another IoT printer is also available. It prevents receipts from being accidentally printed on preparation printers, reducing operational confusion at checkout.
Original PR description
Steps to reproduce: 1. Configure a POS with a receipt printer and a preparation printer. 2. Ensure that the preparation printer has a higher ID than the receipt printer (you can force this by deleting it and letting the IoT redetect it.) 3. Try to print a receipt. EXPECTED: The receipt is printed on the configured receipt printer. ACTUAL: The receipt is printed on the prepation printer. This was caused by the hardware proxy code assuming that there will only be 1 printer `iot.device` model loaded, and that it will correspond to the receipt printer. The fix is to ensure the hardware proxy only chooses the printer that is configured as the receipt printer. Forward-Port-Of: odoo/enterprise#93225
Payroll users can now open work entries while several companies are selected without encountering an error. The fix makes the company filter include all active companies, supporting smoother multi-company payroll operations.
Original PR description
**Steps to reproduce:** - Choose multicompanes from the companies on top right - Open work entries by going into Payroll/Work Entries/Work Entries **Issue:** Previously, the domain contained the current company id only, when in reality there was more than a company **Fix:** Changed the domain to cover all companies in the env Task: 5077545 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix helps prevent IoT actions from running twice when the first connection method times out and a fallback is used. It reduces the risk of duplicate prints, registrations, or other device actions, improving reliability for businesses using IoT hardware.
Original PR description
Community PR: odoo/odoo#225678 In the following case an IoT box action can be duplicated: 1. Request is sent over longpolling 2. Action takes longer than 6s to execute, longpolling times out on the client side 3. Websocket request is sent as a fallback 4. Both requests cause an action to be executed (double blackbox registration, double print, etc.) To solve this we will send an ID with every action, and if the ID has already been recently seen we will ignore the action and log a warning. This PR handles the client side code, which just involves adding the new `action_unique_id` key to all our actions that are using fallbacks. task-5067737 Forward-Port-Of: odoo/enterprise#94031 Forward-Port-Of: odoo/enterprise#93985
This fix prevents the same IoT box action from being carried out twice when a request times out and is retried through a fallback connection. It helps avoid duplicate prints, registrations, or other device actions, improving reliability for businesses using connected hardware.
Original PR description
Enterprise PR: odoo/enterprise#93985 In the following case an IoT box action can be duplicated: 1. Request is sent over longpolling 2. Action takes longer than 6s to execute, longpolling times out on the client side 3. Websocket request is sent as a fallback 4. Both requests cause an action to be executed (double blackbox registration, double print, etc.) To solve this we will send an ID with every action, and if the ID has already been recently seen we will ignore the action and log a warning. task-5067737 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225777 Forward-Port-Of: odoo/odoo#225678
Event registration now avoids showing a misleading or broken sign-in button in cases where checkout cannot proceed or is not needed. This prevents users from hitting an error when seats are unavailable and makes free event registration clearer by showing the correct confirmation action.
Original PR description
This commit fixes two bugs related to the "Sign in" in button of the registration form. First bug: ------------ If there is more ordered seats than available seats, an error modal is displayed with a…
This commit fixes two bugs related to the "Sign in" in button of the registration form. First bug: ------------ If there is more ordered seats than available seats, an error modal is displayed with a "Sign In" button. This button shouldn't be present. On click, a 500 error is triggered. Now, the button does not appeared on this modal. Reproduce: Check "Mandatory" for "Sign in/up at checkout" in the settings. In the event form, add a limit of 1 available seat and add two tickets with each one 1 seat. With a public user, on the website page of the event, click on "Register" to open the registration modal. In the tickets form, select the maximum number of registrations for each tickets. The error modal with the "Sign In" button should appear. Clicking on this button trigger the 500 error. Second bug: ---------------- The "Sign in" button is displayed even if the tickets have no price. So the label of the button is wrong because public users are not redirected to the checkout. Now, the "Confirm Registration" button is displayed in this case. Reproduce: With the same settings as for the first bug, create an event without tickets. Order a registration with an public user. Click on the "Sign In" button of the attendee details form. The confirmation page appears instead of the sign in page. task-4797022 Forward-Port-Of: odoo/odoo#215585
The website editor now respects the same filtering rules used in the backend when selecting related records such as job locations. This prevents users from seeing unrelated contacts and keeps website editing choices consistent with recruitment setup.
Original PR description
Steps to reproduce: 1. Install `website_hr_recruitment` 2. Open the Recruitment module's tree view 3. Create a new job position 4. See the Job Location field in the form view under the recruitment page 5. Observe the fetched records 6. Go to the website via the smart button 7. Edit the website and click on the remote under the job position (Job Location) 8. Observe contacts in the web editor Issue: All partners are fetched instead of the filtered ones. Cause: The backend domain of the clicked field is not applied while fetching records in the web editor. https://github.com/odoo/odoo/blob/afa26af132566a68ad6bf67565062bd73ddd7429/addons/hr_recruitment/models/hr_job.py#L25-L36 Solution: Apply the backend domain of the clicked field when fetching records in editor. opw-4879929
This fixes an issue where online orders could keep using the Click and Collect warehouse even after the customer switched back to standard delivery. Orders now recalculate the warehouse at the right time, helping quotations and fulfillment use the correct stock location.
Original PR description
Steps: - Activate Click and Collect, then create a new warehouse. - For the product, add quantities in both locations. - Assign the second warehouse to Click and Collect. - Go to the website, add the product to the cart, choose Click and Collect as the delivery method, then switch it to Delivery and confirm payment. Issue: - When checking the quotation, it still uses the warehouse linked to Click and Collect. Cause: - Warehouse recomputation logic is called after _remove_delivery_line which resets the delivery_type of sale order. Since delivery_type is reset the sale order filter for warehouse recomputation does not work as intended. Fix: - Moved warehouse recomputation logic to _set_delivery_method which will filter the sale order before _remove_delivery_line. opw - 4965726, 5004170 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227983 Forward-Port-Of: odoo/odoo#225989
Credit notes for Mexico's general public tax regime now keep the selected "Returns, discounts or bonuses" usage instead of being changed to "No fiscal effects." This helps businesses generate compliant XML documents when issuing refunds or discounts under current SAT rules.
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#95246 Forward-Port-Of: odoo/enterprise#93071
A Chilean localization invoice report issue was fixed so invoiced Point of Sale orders can be validated without triggering a template rendering error. This helps businesses using Chilean electronic invoicing avoid blocked sales processing at checkout.
Original PR description
**Steps to reproduce:** - Install l10n_cl_edi_pos - Create a PoS order and enable the invoice option. - When clicking on the validate button, the following traceback appears - Error :- `Error while rendering the template` - Please see [issue](https://www.loom.com/share/24f02eca5b2344c083bf7e0b990d3979?sid=d20f31e8-2776-4dda-a6bc-819a76eb3275) **Cause**: - In [this commit](https://github.com/odoo/odoo/pull/223686/files#diff-c85e75bc27fc841662ca0598c09a22670e0a0b4e5120815934c0a50999ff02bfL175), we removed the 'current_total' section. **Solution:** - Correct the XPath according to the new commit
Cancelling a sales order after multiple return steps no longer causes the system to crash. This improves reliability for teams handling product returns and prevents failed cancellation workflows.
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