Daily updates from Odoo
Thursday, August 21, 2025
38 changes · 18.0
Enhancements to existing features
Completing large batches of manufacturing work orders is now much faster. This reduces waiting time for teams handling many work orders, especially when they belong to the same manufacturing order.
Original PR description
### Description: Improves the performance of `button_finish` when confirming many work orders. Previously, the method would update each work order individually, leading to slow performance. This PR changes the way the write is executed to do it by batch, which is much faster, especially when work orders share the same manufacturing order. ### Benchmark (in 18.0): | N° of work orders | Before | After | |-------------------|--------|-------| | 250 | 14s | 610ms | | 500 | 53s | 1s | ### Reference: opw-4957774
This change updates the sales spreadsheet field synchronization action. It appears to be a work-in-progress change with limited detail, likely affecting how sales-related spreadsheet fields stay aligned with business data.
Resolved issues and error corrections
This fixes instability in an automated test for public mail channels by making sure repeated test runs target the correct message. It helps reduce false build failures and improves confidence in the mail feature testing process.
Original PR description
This tour had many race conditions in the past and keeps having them. Some of them are actually due to the fact the tour is ran twice, but the selectors completely ignore this fact, leading to unexpected results. The message body is now updated before the second run to avoid confusion and the selectors are adapted to always target the message of the current run. Also remove the reload for emojis as they are showing immediately after being added. Also remove the useless comments that makes the test twice as long to read and to understand. https://runbot.odoo.com/odoo/runbot.build.error/230901
This fixes an issue where some sales orders with tracked products could not be properly brought into the Point of Sale when stock movements had not yet been created. Staff can now settle those orders in PoS more reliably, avoiding checkout interruptions for affected sales.
Original PR description
Before this commit, if an order was not confirmed and stock moves were not created, if products are tracked, the order lines would not be added to the PoS. opw-5026892 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents zero-priced lines on credit notes from being exported with a misleading negative zero price. It helps ensure UBL electronic credit notes, including Romanian CIUS-RO files, pass validation and can be sent successfully.
Original PR description
**Issue description:** When creating a UBL credit note, a line with a zero unit price and a negative quantity would have its gross unit price calculated as `0.0 / <negative_qty>`. This results in a negative zero `-0.0`, which is considered an invalid negative net price by some EDI validators (e.g., Romanian CIUS-RO), causing the file to be rejected. **Steps to reproduce:** 1. Create a Sales Order with two lines: one product for €100 and a second (e.g., a delivery service) for €0. 2. Create and pay a downpayment invoice for a fixed amount greater than the order total, e.g., €200. 3. Go back to the Sales Order and create a "Regular Invoice". This will generate a credit note with negative quantities on the lines. 4. Ensure the journal is configured for UBL export (e.g., CIUS-RO). 5. Post, then send the credit note and inspect the generated XML file. The zero-priced line will show `cbc:PriceAmount = '-0.0'`. opw-5000314 Forward-Port-Of: odoo/odoo#223074
This fixes the setup of two Spanish 0% sales taxes so they are correctly treated as exempt with the right legal exemption reasons. It also removes older duplicate exempt tax entries that are no longer needed, helping Spanish invoices and tax reports use the correct classification.
Original PR description
Currently 2 sales taxes are misconfigured.
They both should be marked as 'exento' ("Exento") instead of 'no_sujeto_loc' ("No Sujeto por reglas de Localization")
- "0% EU G"; with "Exempt Reason" E5 / "Art. 25"
- "0% EX G"; with "Exempt Reason" E2 / "Art. 21"
This commit updated those taxes
Due to this the following sales taxes become obsolete.
- "VAT Exempt (Art. 21)"
- "VAT Exempt (Art. 25)"
They are deleted in this commit.
opw-4850585
Forward-Port-Of: odoo/odoo#223603Timesheet entries are now correctly connected to down payment invoices created from sales orders. This makes invoice grouping and reporting more accurate for services billed from tracked time.
Original PR description
To reproduce: ============= - create service product based on timesheet that creates project/task - create sale order with this product - confirm sale order - record couple hours on the task - go back to sale order and create downpayment invoice - go back to timesheet and group by invoice - you will see that the timesheet is not linked to the downpayment invoice Problem: ======== - before this commit, we only link timesheet to regular invoices, not to downpayment invoices. - the `_link_timesheets_to_invoice` method fetches timesheets from the SOL linked to the created invoice, which is in case of downpayment a different SOL than the one linked to the timesheet. Solution: ========= we call `_link_timesheets_to_invoice` in case of downpayment invoices and we also ensure that the method fetches the timesheets from all SOLs on the whole sale order. opw-4850089 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes how Odoo matches debit and credit lines during reconciliation when multiple partners are involved. Matching lines by partner produces cleaner, more accurate reconciliation details behind the scenes and avoids confusing residual amounts.
Original PR description
**Steps to reproduce:** - Install Accounting - Go to "Accounting / Accounting / Journals / Journal Entries" - Create the following MISC entries in this order: 1) | Account | Partner | Debit | Credit…
**Steps to reproduce:** - Install Accounting - Go to "Accounting / Accounting / Journals / Journal Entries" - Create the following MISC entries in this order: 1) | Account | Partner | Debit | Credit | | ------------------ | --------- | ----- | ------ | | Receivable Account | Partner A | 1000 | 0 | | Account X | Partner A | 0 | 1000 | 2) | Account | Partner | Debit | Credit | | ------------------ | --------- | ----- | ------ | | Receivable Account | Partner B | 1001 | 0 | | Account X | Partner B | 0 | 1001 | 3) | Account | Partner | Debit | Credit | | ------------------ | --------- | ----- | ------ | | Receivable Account | Partner C | 1002 | 0 | | Account X | Partner C | 0 | 1002 | 4) | Account | Partner | Debit | Credit | | ------------------ | --------- | ----- | ------ | | Receivable Account | Partner C | 0 | 1002 | | Account X | Partner C | 1002 | 0 | 5) | Account | Partner | Debit | Credit | | ------------------ | --------- | ----- | ------ | | Receivable Account | Partner B | 0 | 1001 | | Account X | Partner B | 1001 | 0 | 6) | Account | Partner | Debit | Credit | | ------------------ | --------- | ----- | ------ | | Receivable Account | Partner A | 0 | 1000 | | Account X | Partner A | 1000 | 0 | - Go to "Accounting / Accounting / Journals / Journal Items" - Select the 6 created lines linked to the Receivable Account - Reconcile them **Issue:** The 6 lines are fully reconciled, but when checking the amounts of the partial reconcile records (not visible in the UI), the debit and credit amounts are matched by their actual order. So, the first debit line of 1000 is matched with the first credit line of 1002, which results in a residual credit of 2 that is then matched with the second debit line of 1001, which leads to a residual debit of 999 and so on. This generates weird amounts in the partial reconcile records. **Solution:** In the case there are several lines with different partners, the lines can be sorted by partner to try to match the lines with the same partner together. opw-449356 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Message action buttons on log notes written by the current user now appear in the expected mirrored position next to the date. This makes the mail thread layout more consistent and easier to use.
Original PR description
**Purpose of this PR:** Fix the position of message actions on log notes authored by the current user. Messages authored by self appear on the right side of the thread. This PR mirrors the action placement logic so that, like messages from others (which show actions to the right of the date), self-authored messages show actions to the left of the date. Before: <img width="392" height="638" alt="image" src="https://github.com/user-attachments/assets/8b66c98f-3e00-47c8-abf3-ee62169ed499" /> After: <img width="392" height="638" alt="image" src="https://github.com/user-attachments/assets/d1a425da-fb0c-4793-a080-735286bc2bb9" /> task-[4689357](https://www.odoo.com/odoo/project/1519/tasks/4689357)
Partial payment links for invoices now correctly request only the partial amount selected, rather than the full invoice total. This prevents customers from being asked to overpay when using a payment link.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Have an unpaid invoice; 2. generate a partial payment link; 3. open partial payment link; 4. click the Pay button. Issue ----- The invoice's full amount gets requested. Cause ----- Commit 5697493e0091 added `amount` as a named keyword parameter in an `_invoice_get_page_view_values` override, but failed to pass it along to the call to `super`. As the base method no longer receives an `amount` parameter, it defaults to the invoice total. Solution -------- Pass `amount` to the `super` call. opw-5013044
This update refreshes the spreadsheet component and fixes several issues affecting exports and data interactions. Users should see more reliable chart exports, safer table row handling, and better pivot behavior when undoing deletions.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/bc6051c9e [REL] 18.0.41 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/bc6051c9e [REL] 18.0.41 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/e95196363 [FIX] xlsx: correctly export aggregated charts [Task: 4954426](https://www.odoo.com/odoo/2328/tasks/4954426) https://github.com/odoo/o-spreadsheet/commit/f55d9f356 [FIX] selection: prevent partial move of table rows with headers [Task: 4862731](https://www.odoo.com/odoo/2328/tasks/4862731) https://github.com/odoo/o-spreadsheet/commit/94acb2343 [FIX] pivot: reload when delete is undone [Task: 5001153](https://www.odoo.com/odoo/2328/tasks/5001153) Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya <rmbh@odoo.com> Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Point of Sale order searches by tracking number now use the correct session information. This helps staff find the right orders reliably, including orders from different sales sessions.
Original PR description
Before this commit, searching for an order by `tracking_number` matched against the `pos_reference` field. However, the `tracking_number` is constructed using the `session_id`, not the `pos_reference`. This mismatch could cause orders from other sessions to be not found, as the session id related part of the `tracking_number` may not align with the `pos_reference`. This commit fixes the issue by adjusting the search logic to match against the `session_id` instead, ensuring accurate results when looking up orders by `tracking_number`. opw-4934482 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue where employee organization charts could behave incorrectly when an employee had more than five managers. The chart now refreshes before the employee record is saved, giving users a more accurate view while editing employee details.
Original PR description
A buggy behavior when there are more than 5 managers was fixed. The org chart now updates before the employee record is saved. task-4609465 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223453 Forward-Port-Of: odoo/odoo#216940
Fixes an issue where removing text color or formatting in the HTML editor could cause the editor to freeze in certain cases. This improves editing reliability, especially when formatting is applied to larger text blocks or protected content is selected.
Original PR description
**Current behavior before PR:** - When color was applied to a block-level element, attempting to remove it caused the `removeFormat` method to enter an infinite loop. - Removing formatting on a contenteditable false element infinite loop when removing format. **Desired behavior after PR is merged:** - Now, the color is correctly removed from the selected text, even when it is applied to a block-level element. - Now, the toolbar no longer opens when the selected element is contenteditable false task: 4575459
Product label reports now pass the selected currency in a safer way when calculating prices. This helps prevent incorrect prices from appearing on printed labels when templates include currency-specific pricing.
Original PR description
Description of the issue/feature this PR addresses: In product label reports, calling _get_product_price with positional arguments may lead to incorrect parameter binding (e.g. currency_id being interpreted as uom). This can cause wrong prices to be displayed in labels in some cases. Current behavior before PR: Some label templates pass currency as a positional argument. This may result in wrong prices being shown depending on argument order. Desired behavior after PR is merged: Label templates always pass currency as a keyword argument, ensuring correct price computation and preventing mismatches. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr My CLA signature is being added in this PR: https://github.com/odoo/odoo/pull/223312
This fix restores an optimization that avoids unnecessary reading of full image data when only file size information is needed. It improves performance in image-heavy views such as product kanban, especially for systems using slower external storage.
Original PR description
Since 7744886d6141ca7971d91807d0444c707e10fdf8, reading binary field with bin_size=True still reads the ir.attachment datas field, which is relatively slow with some storage backends. In the products kanban view this can easily add 1 sec to web_search_read, if there is a 10ms latency when reading images. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes internal email-related tests so they pass consistently when an optional file detection library is present. It helps keep quality checks reliable across environments and reduces false test failures during maintenance.
Original PR description
Those tests are failing when python-magic is installed. Since 26f9c82b99 Odoo > saas-18.4 has this lib as a requirement and comes with appropriate fixes. This commit adapts some test from 17.0 up to saas-18.4 to also work when the python-magic lib is installed. Forward-Port-Of: odoo/odoo#223609
Payment links generated from invoices now correctly apply the custom amount entered by the user. This prevents customers from seeing or paying an unexpected amount when opening the link.
Original PR description
Steps to reproduce: 1. Create an invoice with an amount. 2. Post the invoice. 3. Generate a payment link with a custom amount. 4. Open the link. Issue: The generated link did not respect the amount…
Steps to reproduce: 1. Create an invoice with an amount. 2. Post the invoice. 3. Generate a payment link with a custom amount. 4. Open the link. Issue: The generated link did not respect the amount provided. Cause: In `account`, the method `_invoice_get_page_view_values` retrieves `amount` from `kwargs`. However, in `account_payment`, the overridden `_invoice_get_page_view_values` was incorrectly declaring `amount` as a method parameter instead of leaving it in `kwargs`. As a result, it was not passed to `super()`. This caused the amount from the link to be ignored. Solution: Remove `amount` from the method parameters, keep it inside `kwargs`, and then clean it up in `_get_common_page_view_values` to avoid multiple arguments error when retrieving the payment providers. Note: This issue was found while preparing the Pull Request [#218243](https://github.com/odoo/odoo/pull/218243). --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an editor issue where a line break could disappear after users pressed Shift+Enter and then Enter at the end of a paragraph. The change keeps the intended spacing visible, helping edited content match what users expect.
Original PR description
Problem: When at the end of a paragraph, pressing SHIFT+ENTER followed by ENTER creates a new paragraph, but the previous one loses its last line break. Cause: When splitting an element, the `<br>` at the selection point is moved to the newly created split element. However, to render an empty line visibly, two `<br>` elements are needed. Moving the existing `<br>` makes the last line break in the original paragraph invisible. Solution: In this special case, instead of moving the `<br>` at the selection point, insert a new `<br>` in the new element, preserving the visual line break in the original paragraph. Steps to reproduce: - Add a paragraph - Type some text, then press SHIFT+ENTER - Press ENTER to create a new paragraph -> The last line break in the first paragraph is lost opw-4987922 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#221869
This fixes an accounting issue where switching an invoice from a foreign currency to the company currency and back before saving could incorrectly apply exchange rates to journal item amounts. Businesses can now rely on invoice line balances remaining accurate when users adjust currency selections during invoice entry.
Original PR description
Steps to reproduce: - Enable a foreign currency with rate - Create an invoice in foreign currency - Switch to company currency, then back to foreign currency before saving - Check journal items values Issue: Amount currency and balance have been affected by the currency rate even if the original currency was restored before saving opw-4864994
This fix ensures copied databases using the Greek EDI module are neutralized so they do not accidentally contact live external services. It helps support teams investigate issues on database duplicates without risking real customer or production interactions.
Original PR description
This commit adds the missing neutralization necessary for the l10n_gr_edi module introduced in [1] The purpose of the standard neutralization framework is to allow us to create database copies that will not interact with external systems in ways that could impact the production database (or if it is not possible to prevent the interactions, make sure that they are benign or won't result in actual changes), or impact the customers of the operator of the production database. This is mainly useful to allow safe support investigation on database duplicates. [1] odoo#203428
This fixes the listed external dependency for the LDAP authentication module. It prevents unnecessary warning messages during installation and reduces noise in nightly build checks.
Original PR description
The wrong package name leads to a warning at install time making unnecessary noise in nighlty builds.
This fixes Turkish e-Dispatch XML generation so the delivery customer is taken from the main commercial partner, while the delivery address remains the actual delivery contact. It also uses the appropriate customs ZIP for non-Turkish customers and hides XML generation when no delivery address is available, helping avoid incorrect or invalid dispatch documents.
Original PR description
Behaviour before this commit: - Previously, the picking partner was used for sending both the Delivery Customer and delivery address in the XML. - Secondly, ZIP was used in Delivery Customer regardless of the country of the partner (Turkish or Non-Turkish) Desired behaviour after this commit: - After this commit, the commercial partner of the picking partner will be used for sending the Delivery Customer data and picking partner itself will be used for sending the Delivery Address in the XML. - Additionally, if the commercial partner is non turkish, customs ZIP will be used in the Delivery Customer in the XML. - If the delivery is validated without giving Delivery Address, then the 'Generate e-Dispatch (XML)' button will be hidden. TaskID:4918748 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#218096
The French point of sale certification report now avoids loading unnecessary order data when running its inalterability checks. This reduces memory consumption significantly for businesses with large sales volumes, helping the report complete more reliably.
Original PR description
### Problem: Following this pr https://github.com/odoo/odoo/pull/217348, field prefetching is unnecessary when fetching orders, as all required fields are already fetched explicitly. Keeping prefetching enabled causes excessive memory usage. ### Benchmark | Orders | Before | After | |--------|---------|--------| | 1k | 6MB | 5.8MB | | 10k | 42MB | 27MB | | 100k | 534MB | 320MB | | 200K | 1.1GB | 646MB | opw-4901994 Forward-Port-Of: odoo/odoo#222416
Test builds no longer fail when URL parameters reference unavailable tests that are meant to be excluded. This keeps automated build checks stable across different add-on combinations while preserving useful information for developers when a requested test is missing.
Original PR description
Before this commit, URL test/suite IDs were warned in the console if they didn't match any test/suite registered by the test runner. This is an issue for Runbot which runs sub-builds with the same URL parameters regardless of the installed addons, which repeatedly fails such builds. This commit changes the warning to a regular log, so that these builds stop failing, while still allowing a developer to get the information that an ID has been removed/ignored. runbot [230082](https://runbot.odoo.com/odoo/runbot.build.error/230082) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Employees assigned to a global working schedule now correctly receive timesheet entries for public holidays. This prevents missing timesheet records when a working schedule is shared across companies rather than tied to one company.
Original PR description
_*= project_timesheet_holidays Steps to Reproduce: --------------------------- 1. Create a global working schedule (company should be False). 2. Assign this working schedule to any employee. 3. Create a public time off (for all the working schedule). 4. You will notice that the timesheet entry is not generated for the public holiday for that employee. Issue: ------------------------------- - Employees who use the WS without a company are excluded from timesheet creation. Cause : -------------------------------- - When grouping employees by calendar global WS (with no company) were being excluded. - And the timesheets were not generated due to the check `calendars_dict[calendar_id].company_id != company` when the WS had no company Fix: ------------------ - We will add the domain to include the global WS and and we will check if the the WS has company id then only check the condition. task-4900941
The barcode app now handles completed manufacturing orders that have no by-products when opening the scrap action. This prevents an error screen and lets users continue the scrap workflow normally.
Original PR description
Issue ----- Trying to scrap a production through the barcode app gives the user a traceback. Steps to reproduce ----- - Have a done MO - Go to barcode and try to scrap it --> Traceback Cause ----- When preparing the context for the scrap window, we try to map the MO's byProducts. When there is no byProduct, we end up trying to apply a mapping on "nothing". ----- Ticket: opw-4792599
Fixes an issue where selecting a product variant could apply the subscription plan choice to an outdated dropdown during page updates. This helps keep subscription pricing choices reliable and prevents related automated checkout tests from failing intermittently.
Original PR description
The subscription plan selection gets removed and replaced (static template website_sale_subscription.SubscriptionPricingSelect) So the change of value occurs, but on the wrong select. This was happening as when changing the variant we will replace the plan_select in the widget with another template and since this will happen before the RPC set the plan_id that we are choosing as the default one we will actually have the old select option back on the dom to be selected. https://github.com/odoo/enterprise/blob/82593f9932e92800251d18453b0c73e5ce9b5ec0/website_sale_subscription/static/src/js/variant_mixin.js#L35-L41 We are setting the select option to the old one after replacing it. This commit introduces a delay to prevent the test to fail (which happened most of the time) runbot-error-110627
This fix ensures the invoice posting time matches the official CFDI timestamp used for Mexican electronic invoicing. It also keeps record locking intact during sending, reducing the risk of timing-related inconsistencies.
Original PR description
`fecha_datetime` could be set to a different value than the `document_post_time` passed as parameter because of the `min`. We also must revert the `_cr.commit` during the sending because it removes the lock on records. Instead we set the invoice post time and commit before locking. task-none
This fix ensures each country-specific Intrastat report uses only its own export data rules. It prevents one localization from accidentally altering another country's report data, improving reliability for compliance reporting.
Original PR description
Previously, it was possible for the _get_exporting_dict_data from a localization to change the data of another localization.
This update prevents the Point of Sale system from failing when it tries to read the amount of an order that is not available. It helps keep checkout and payment-related workflows more stable in edge cases.
Original PR description
Before this commit, accessing the order amount caused an error if the order was not defined. opw-5027426
The Sign app guided tour has been corrected so it works consistently when users add and complete a signature field. This prevents the tour from failing due to differences in saved signature data or previous tour activity, improving onboarding and testing reliability.
Original PR description
Fix `sign_tour`. How to reproduce: 1. Go to tours in Odoo 2. Look up sign_tour 3. Click testing ( If testing stops at Sign App, change search filters or archive sign all .request records so that the…
Fix `sign_tour`.
How to reproduce:
1. Go to tours in Odoo
2. Look up sign_tour
3. Click testing ( If testing stops at Sign App, change search filters or archive sign all .request records so that the following screen displays )
<img width="780" height="591" alt="image" src="https://github.com/user-attachments/assets/b164c224-0e3e-4dce-97e6-89848263e59e" />
4. tour fails!
---
First commit
The `sign_tour` was failing after the conversion of the `sign.Template` client action to OWL. The standard `drag_and_drop` tour helper can no longer be used for automatic tour testing because the drop target is inside an iframe whose content is managed by PDF.js.
This commit fixes the tour by utilizing the custom helper function, `dragAndDropSignItemAtHeight`, to programmatically simulate the drag and drop action.
---
Second commit
The step "footer.modal-footer button.btn-primary:enabled" assumes that the Signature Dialog opened from its previous step ("Sign It" navigation button).
However, the "Sign It" navigation button does not always open the dialog.
If signing user (res.users) already has "sign_signature" data, the data will be automatically filled in to the Signature input.
Otherwise, the navigation button will open the Signature Dialog.
Luckily, we can see whether user has "sign_signature" data or not by checking if the <input data-item_type='signature'/> node has "data-auto_value" attribute or not.
We now skip the step if data-auto_value is set for signature.
---
Third commit
If `sign.template_sign_tour` has sign request, it means that the template might have a sign item because the `sign_tour` tour adds the Signature sign item to the template. (If user followed the tour)
When we're copying the sign template to trigger the template tour, we should not copy the sign item. User will be guided to add the sign item during the tour.
---
Note:
ci/security needs to be overriden as it was done for https://github.com/odoo/odoo/pull/134793#issuecomment-1711440188
---
opw-4752794Fixes an accounting reconciliation issue where matching an invoice and a vendor bill from different partners could assign the wrong partner to the generated transfer lines. This helps keep partner ledgers and related accounting reports accurate in workflows where customer invoices and vendor bills are reconciled together.
Original PR description
**Steps to reproduce:** - Install account_accountant - Create an invoice ($100) for Customer X - Create a bill ($100) for Vendor Y - From "Customer Invoices" journal in Accounting dashboard, open…
**Steps to reproduce:** - Install account_accountant - Create an invoice ($100) for Customer X - Create a bill ($100) for Vendor Y - From "Customer Invoices" journal in Accounting dashboard, open "Payments Matching" - Select the invoice and the bill - Reconcile them **Issue:** A move is created with 2 lines that will mark both invoice and bill as paid. However, on both created lines, the partner is "Vendor Y", which is wrong as it will generate incorrect reports (e.g. Partner Ledger). One line should have "Vendor Y" as partner and the other line should have "Customer X". This kind of reconciliation is apparently current in India. **Cause:** When reconciling lines from 2 accounts exactly, a transfer from one account to the other one is created. The transfer is made from the account where the absolute amount to move is the lowest. A transfer is made for each partner that has a move being reconciled with the source account. The transfer is crediting (or debiting) the source account and debiting (or crediting) the reconcile account with the same partner. This is working most of the time but it totally ignores all the partners linked to the moves with the reconcile account. **Solution:** Create one line of the transfer with the source account and the partner as before. For the line on the reconcile account, first check if there's one for the same partner, currency and sign (of the amount to transfer). If not, try to find another partner with the same currency and sign. Otherwise, fall back on the same partner as the line on the source account as it was done before. opw-4735147 Forward-Port-Of: odoo/enterprise#89972
This update adds stable identifiers to Swedish bank clearing range data. It helps prevent duplicate records from being created during future upgrades, keeping bank data cleaner and upgrade processes smoother.
Original PR description
This commit adds id's to clearing range csv. This prevents re-importing the same objects when upgrading to 18.2.
Google Reserve booking updates now keep all existing slot details while adding party size information. This prevents malformed booking data from being sent back to Google, helping reservation updates work reliably.
Original PR description
The controller incorrectly modified the given "slot" to only contain the party size key. Instead, it should update the information to add this key next to the existing ones, and in turn return a properly formatted slot to Google. Task-3083812
Fixed an issue where products split into packages during barcode batch transfers could be assigned to the wrong transfer. This ensures each transfer records the correct delivered quantities, preventing incorrect stock movements and unnecessary backorders.
Original PR description
**Steps to reproduce:** - enable "packages" and "batch transfers" settings - open wharehouse management/operation type - select internal transfer - check "automatic batch" and group by "contact" -…
**Steps to reproduce:** - enable "packages" and "batch transfers" settings - open wharehouse management/operation type - select internal transfer - check "automatic batch" and group by "contact" - create two storable product with an on hand quantity of 10 - create a an internal transfer for the first product for a qty of 10 - mark it as to do - do the same for the second product and make sure that it's the same contact - open barcode and select batches - select the last batch created - scan WH-STOCK - enter and confirm a quantity of 4 for each line - click on put in pack (at this step we can already see that the two new lines created are associated wit the second picking, even though it should be one line per picking) - click on the +6 on each line and click on put in pack - validate **Current behavior:** - a back order has been created for the first picking - the first internal transfer has only delivered 4 units of the first product - the second internal transfer has delivered 10 of the second product and 5 of the first product **Expected behavior:** both pickings should have delivered 10 of their product **Cause of the issue:** The lines created when clicking on "put in pack" for the first time are both associated with the second picking because the line split: https://github.com/odoo/enterprise/blob/898e3e47cfe3b86230da2b146960983d7ad144d0/stock_barcode/static/src/models/barcode_picking_model.js#L514 and the picking_id of the new line is set to the values provided by the `_getNewLineDefaultValues` as the picking_id of the last selected `line`: https://github.com/odoo/enterprise/blob/24b4e49dbe16cb8bd40170abfc089dd64c3f34dd/stock_barcode_picking_batch/static/src/models/barcode_picking_batch_model.js#L280-L281 rather than from the values of the initial line it is split from. opw-4952964 Forward-Port-Of: odoo/enterprise#91378
This fix prevents Belgian payroll accounting setup from failing when a specific mobility budget salary rule is missing. It helps companies complete accounting installation even if the rule was deleted or their database was created before the rule existed.
Original PR description
Currently an issue occurs when the user tries to install `10n_be_hr_payroll_account/account` after follow steps: - Install `l10n_be_hr_payroll` and switch to `BE Company CoA` - Go to Payroll > Configuration > Salary > Rules - Delete `Mobility Budget Special Contribution` - Error occurs when trying to install accounting error: `ValueError: External ID not found in the system: l10n_be_hr_payroll.cp200_employees_salary_mobility_budget_tax` The salary rule mentioned above steps was added with commit [1], and the issue also occurs if the database was created before commit [1] with a module `l10n_be_hr_payroll` and the user tries to install the account after commit [1]. This commit fixes the issue by using `raise_if_not_found=False`, which prevents an error from being raised when the salary rule is missing. [1] - https://github.com/odoo/enterprise/commit/16c8a223beda4e4ebcf2c24f716687726f7230f3 sentry-6578747340
A test user setup was corrected by removing an unnecessary timesheet approval permission. This prevents automated test failures in single-app environments where the timesheet app is not installed, improving release reliability without changing customer-facing behavior.
Original PR description
on the test `test_mrp_aa_employee_without_account_rights` the user was created with the group `hr_timesheet.group_hr_timesheet_approver` which is not needed and was causing the test to fail on Single app test as this module does not depend on hr_timesheet. This commit removes this group from the user creation. runbot-231137