Daily updates from Odoo
Navigate
Branch
Tuesday, June 10, 2025
57 changes
19 changes
Enhancements to existing features
The Point of Sale settings now include the missing documentation link for the Tyro payment provider. This makes it easier for users configuring Tyro payments to find the right setup guidance directly from Odoo.
Original PR description
Before this commit: --------------------------- - Tyro payment provider were missing documentation link in POS configuration. After this commit: ------------------------- - Added missing documentation link for Tyro payment Provider. Task: 4797691 Related PR: https://github.com/odoo/odoo/pull/210133
Backend text colors have been adjusted to make regular text easier to distinguish from muted text. This improves readability across areas such as Documents, Knowledge, manufacturing work orders, spreadsheets, barcode flows, navigation, and settings without changing the muted text style.
Original PR description
The goal is to increase contrast between the global text-color and text-muted in the backend while keeping the current text-muted color. This is done because the contrast was too small between these two colors and is an opportunity to increase the overall contrast. The contrasting color for headings and active components is set to `$black` (#000 and #FFF darkmode). To avoid the secondary buttons looking "disabled" the color is also adapted. task-4756587 Community PR: https://github.com/odoo/odoo/pull/209125
Odoo now supports selling the same Amazon product through both Fulfillment by Amazon and merchant fulfillment at the same time. This ensures stock levels are synchronized correctly, so businesses can keep selling from their own inventory when Amazon stock runs out.
Original PR description
Amazon allows you to sell products both in FBA and in FBM (as a fallback when Amazon does not have stock anymore), but currently this configuration is not working with Odoo because when an offer is considered FBA, then the FBM stock is forced to 0 in Amazon. This commit removes this limitation, allowing the stock to be correctly synchronized with Amazon in all cases (FBA, FBM, both FBA and FBM). See also: - https://github.com/odoo/documentation/pull/12901 - https://github.com/odoo/upgrade/pull/7507 task-4092410
The WhatsApp test setup now uses partner and guest records instead of a generic persona representation. This keeps enterprise tests closer to real system behavior and helps reduce the risk of mismatches between automated checks and actual customer usage.
Original PR description
Use partners and guests to be as close to python as possible. Part of task-4675747 Part of task-4676466 https://github.com/odoo/odoo/pull/212092
Resolved issues and error corrections
Invoices and similar accounting documents now correctly show the SEPA direct debit mandate linked through their payments. This helps teams rely on accurate mandate information when processing or reviewing direct debit collections.
Original PR description
The sdd_mandate_id field was related to the SDD mandate of origin_payment_id. However, since only journal entries created from payments have an origin_payment_id, other move types do not have the SDD mandate set. Converting it to a computed field that retrieves the SDD mandate from the payments instead. task-4531618
Code cleanup and technical improvements
Odoo now builds IoT box connection links based on how the user is currently accessing the system, avoiding mismatches between secure and non-secure connections. This helps Point of Sale and self-ordering IoT integrations connect more consistently in environments where Odoo can be reached through multiple URLs.
Original PR description
The `ip_url` field on the IoT box model was intended to provide the full URL of the IoT box, e.g. 'http://1.2.3.4:8069' or 'https://1-2-3-4.abcd.odoo-iot.com'. However the problem was that it relied on `web.base.url` to determine if it should use HTTP or HTTPS, which can cause problems if the Odoo database can be accessed via both. To fix this, we instead started to use a helper on the frontend, `formatEndpoint`, to perform the same task, except that it can take into account the actual browsing context and always use the same protocol. This changes the remaining uses of `ip_url` to use `formatEndpoint`, except the `open_homepage` action which now gets the current protocol from the request object. With no remaining usages the field itself can be removed. task-4813536
This change reorganizes a shared testing helper so multiple website-related modules can use the same request mock from a common location. It reduces duplicated test setup and helps keep automated checks consistent across areas like subscriptions, appointments, signing, WhatsApp, and support forums.
Original PR description
odoo/odoo#212405
Miscellaneous changes
When executing follow-up actions, a KeyError could occur if the 'journals' key was missing from the options dictionary Steps to reproduce: Go to Accounting > Reports, open the Follow-up Report, and click Options. Untick journals so that the 'journals' list is effectively removed. Go to Customers, select any customer, Click on Customer Statement. Try to change Report (up right) to Follow_Up Report OPW-4798813 Forward-Port-Of: odoo/enterprise#87079
Original PR description
When executing follow-up actions, a KeyError could occur if the 'journals' key was missing from the options dictionary Steps to reproduce: Go to Accounting > Reports, open the Follow-up Report, and click Options. Untick journals so that the 'journals' list is effectively removed. Go to Customers, select any customer, Click on Customer Statement. Try to change Report (up right) to Follow_Up Report OPW-4798813 Forward-Port-Of: odoo/enterprise#87079
**Issue** In the Mexican localization, the CFDI usage (`l10n_mx_edi_usage`) field is not visible on POS orders in the backend. This prevents users from selecting or modifying the usage when manually generating an invoice from the POS order. **Steps to Reproduce** 1. Install the Point of Sale app and the Mexican localization (l10n_mx) 2. Complete a POS order without generating an invoice 3. In the backend, go to Point of Sale > Orders > Orders 4. Open the newly created order 5. Notice th
Original PR description
**Issue** In the Mexican localization, the CFDI usage (`l10n_mx_edi_usage`) field is not visible on POS orders in the backend. This prevents users from selecting or modifying the usage when manually…
**Issue** In the Mexican localization, the CFDI usage (`l10n_mx_edi_usage`) field is not visible on POS orders in the backend. This prevents users from selecting or modifying the usage when manually generating an invoice from the POS order. **Steps to Reproduce** 1. Install the Point of Sale app and the Mexican localization (l10n_mx) 2. Complete a POS order without generating an invoice 3. In the backend, go to Point of Sale > Orders > Orders 4. Open the newly created order 5. Notice that the CFDI Usage field is missing **Root Cause** The usage field is given a default value at the model level: https://github.com/odoo/enterprise/blob/bc3db24f83473d5646f7c2cfca8ed1c5b064ea2e/l10n_mx_edi_pos/models/pos_order.py#L65-L70 However, this value gets lost during the order processing flow. When an invoice is requested directly from the POS UI, the usage is explicitly set in the `sync_from_ui` method: https://github.com/odoo/enterprise/blob/bc3db24f83473d5646f7c2cfca8ed1c5b064ea2e/l10n_mx_edi_pos/models/pos_order.py#L110-L112 But if no invoice is requested at the time of the order, the usage is not preserved or restored in the backend. **Fix** Explicitly set the CFDI usage to its default value when an invoice is not requested during the POS flow. This ensures the usage field is retained and displayed properly in the backend, allowing users to create invoices manually. opw-4776487 Forward-Port-Of: odoo/enterprise#85954
Previously, the `company_id` field on `budget.analytic` was mandatory. - Removed the `required=True` constraint on the `company_id` field in the `budget.analytic` model. - Updated the record rules `budget_comp_rule` and `budget_lines_comp_rule` to allow access to records where `company_id` is either in the user's companies or unset (`False`). task-4677599 Forward-Port-Of: odoo/enterprise#82955
Original PR description
Previously, the `company_id` field on `budget.analytic` was mandatory. - Removed the `required=True` constraint on the `company_id` field in the `budget.analytic` model. - Updated the record rules `budget_comp_rule` and `budget_lines_comp_rule` to allow access to records where `company_id` is either in the user's companies or unset (`False`). task-4677599 Forward-Port-Of: odoo/enterprise#82955
**[FIX] account_accountant: fully reconcile the move_line if amounts close** If an invoice has a bigger amount than the bank line but within the tolerance of 3%, reconcile the invoice automatically and leave the difference in the suspense account. The statement line will be partially matched. **[IMP] account_accountant: allow filling with reco model on partial** So, with the idea of directly reconciling the aml and leave the partial on the statement line if the amount is close, we want
Original PR description
**[FIX] account_accountant: fully reconcile the move_line if amounts close** If an invoice has a bigger amount than the bank line but within the tolerance of 3%, reconcile the invoice automatically…
**[FIX] account_accountant: fully reconcile the move_line if amounts close** If an invoice has a bigger amount than the bank line but within the tolerance of 3%, reconcile the invoice automatically and leave the difference in the suspense account. The statement line will be partially matched. **[IMP] account_accountant: allow filling with reco model on partial** So, with the idea of directly reconciling the aml and leave the partial on the statement line if the amount is close, we want an easy way for a user to assign these leftovers. Before this commit, when you clicked on the reconciliation model after partially putting amount, it would try to override everything on the statement line and putting what is said by the model. Now, we leave the amounts previously reconciled and complete it with the model. **[IMP] account_accountant: automatic model for fees** For the leftover from the full reco of the invoice that are left on the statement line, we propose a new reconciliation model that will be put when we encounter these situations. We create it when the user is in the case of the 3% and that he put the leftover on a specific account. **[FIX] account_accountant: line auto-reconciled does not change count** To reproduce: Create a statement line of 1000 for partner A Create an invoice of 1000 for same partner Create a statement line of 1000 for same partner => The invoice is now auto-reconciled. But the Count of Reconcile for the first st_line is still 1 task-4749343 Forward-Port-Of: odoo/enterprise#84264
For untracked component moves in the shop floor: - No longer show move lines - Show pencil button instead of add button, clicking opens edit quantity - Apply sets picked (and passes check if applicable) - No remove button, instead: - Add an undo button to unreserve and reassign the move, and set picked to false (and sets quality status to none on check if applicable) Also: make sure to display moves created via Add Component in the shop floor on the relevant MO card (as well as a
Original PR description
For untracked component moves in the shop floor:
- No longer show move lines
- Show pencil button instead of add button, clicking opens edit quantity
- Apply sets picked (and passes check if applicable)
- No remove button, instead:
- Add an undo button to unreserve and reassign the move, and set picked to false (and sets quality status to none on check if applicable)
Also: make sure to display moves created via Add Component in the shop floor on the relevant MO card (as well as all WOs of this MO)
task-4760982
Forward-Port-Of: odoo/enterprise#85019When using the 'skip until' option, we assume the early entries have been already posted elsewhere and their value should be accounted for. However, the outstanding balance of the loan will not keep into account skipped entries, resulting in an incorrectly higher amount, Steps to reproduce: - Create a new loan with: - Amount Borrowed: 24000 - Loan Date: 01/01/2024 - Duration: 48 months - Skip Until: 01/01/2025 - Compute (Duration of 4 years, Interest 1%) - Confirm Issue:
Original PR description
When using the 'skip until' option, we assume the early entries have been already posted elsewhere and their value should be accounted for. However, the outstanding balance of the loan will not keep into account skipped entries, resulting in an incorrectly higher amount, Steps to reproduce: - Create a new loan with: - Amount Borrowed: 24000 - Loan Date: 01/01/2024 - Duration: 48 months - Skip Until: 01/01/2025 - Compute (Duration of 4 years, Interest 1%) - Confirm Issue: Outstanding balance should be 16,105.73 and not 22,016.71 This occurs because, from the amount borrowed, the system subtracts only the posted entries amount, not considering the 'skip until' option opw-4711642 Forward-Port-Of: odoo/enterprise#86711
Problem: When calling `/v1/embeddings`, if the request fails for any reason, the `response` will be `None`. Attempting to access `response['data'][0]['embedding']` then results in a traceback. Solution: Check if `response` is `None` before attempting to extract the embedding from it to ensure graceful error handling. Steps to reproduce: 1. Add a new AI Agent. 2. Attach a document to the agent. 3. Click "Test" to open the chatbot. 4. Send any message. → A traceback occurs due to a fai
Original PR description
Problem: When calling `/v1/embeddings`, if the request fails for any reason, the `response` will be `None`. Attempting to access `response['data'][0]['embedding']` then results in a traceback. Solution: Check if `response` is `None` before attempting to extract the embedding from it to ensure graceful error handling. Steps to reproduce: 1. Add a new AI Agent. 2. Attach a document to the agent. 3. Click "Test" to open the chatbot. 4. Send any message. → A traceback occurs due to a failed embeddings request. opw-4817213 Forward-Port-Of: odoo/enterprise#86803
Using Odoo URLs in the AI app demo data while Odoo.com is upgrading is causing an issue in the runbot as all these URLs are unreachable causing the runbot to be completely red. I am removing these urls for now as a hot fix. Forward-Port-Of: odoo/enterprise#87308
Original PR description
Using Odoo URLs in the AI app demo data while Odoo.com is upgrading is causing an issue in the runbot as all these URLs are unreachable causing the runbot to be completely red. I am removing these urls for now as a hot fix. Forward-Port-Of: odoo/enterprise#87308
Duplicate field was introduced in https://github.com/odoo/enterprise/commit/0703cf2834aeca2db498575ac6e0a35e37e7d048 Duplicate of : https://github.com/odoo/enterprise/pull/85692/files#diff-a75131997102fa2a43d54afca5d43c93165f9eb91a0afc1a707d82ad80e35cf9L48 Forward-Port-Of: odoo/enterprise#85692
Original PR description
Duplicate field was introduced in https://github.com/odoo/enterprise/commit/0703cf2834aeca2db498575ac6e0a35e37e7d048 Duplicate of : https://github.com/odoo/enterprise/pull/85692/files#diff-a75131997102fa2a43d54afca5d43c93165f9eb91a0afc1a707d82ad80e35cf9L48 Forward-Port-Of: odoo/enterprise#85692
Currently, there is an button related to the MX localization that can be accessed outside the localization if `l10n_mx` is installed. Steps to reproduce: ------------------- * Install `l10n_mx` * With company other than MX, go to the pos orders * Select multiple pos orders, select the button **Actions** > Observation: The action `Create Global Invoice` is visible * Select the action `Create GLobal Invoice` > Validation error, Selected orders are not eligible for CFDI Why the fix: -
Original PR description
Currently, there is an button related to the MX localization that can be accessed outside the localization if `l10n_mx` is installed. Steps to reproduce: ------------------- * Install `l10n_mx` * With company other than MX, go to the pos orders * Select multiple pos orders, select the button **Actions** > Observation: The action `Create Global Invoice` is visible * Select the action `Create GLobal Invoice` > Validation error, Selected orders are not eligible for CFDI Why the fix: ------------ This is an `ir.actions.server` which is introduced in the `l10n_mx` localization. It does not look possible to add `invisible` on the xml for the action. https://github.com/odoo/odoo/blob/2540155b5e00a6547fcceee4af4b83f385dcd4ad/odoo/addons/base/models/ir_actions.py#L179-L215 What we can do instead is to throw a more explicit error when trying to use the action outside the MX loca. opw-4805257 Forward-Port-Of: odoo/enterprise#86612
The `account_accountant_tour` test was failing at the step that attempts to set an amount, due to the selector `input[id=amount_0]` not being found within the timeout. The root cause was that the selector used an ID (`amount_0`) which is dynamically generated and can change across test runs . To resolve this, the selector was replaced with a more stable one: `div[name=amount] input`, which targets the same field but does not rely on dynamic IDs. Additionally, a no-op wait step was in
Original PR description
The `account_accountant_tour` test was failing at the step that attempts to set an amount, due to the selector `input[id=amount_0]` not being found within the timeout. The root cause was that the selector used an ID (`amount_0`) which is dynamically generated and can change across test runs . To resolve this, the selector was replaced with a more stable one: `div[name=amount] input`, which targets the same field but does not rely on dynamic IDs. Additionally, a no-op wait step was introduced immediately before this interaction to ensure the DOM has fully rendered the input element before the test proceeds. build_error-220890 Forward-Port-Of: odoo/enterprise#86715
Steps: ----------- - Install the pos_l10n_se module. - Open a POS session with the Swedish Fiscal Data Module configured in the IoT Box settings. - Add a product to the order. Issue: ------------- - An error popup states: "Product has an invalid tax amount. Only 25%, 12%, 6% and 0% are allowed." even when the product is correctly configured with one of these tax rates. Cause: ---------- - The validation logic incorrectly applies conditions for displaying the error popup, mistakenly
Original PR description
Steps: ----------- - Install the pos_l10n_se module. - Open a POS session with the Swedish Fiscal Data Module configured in the IoT Box settings. - Add a product to the order. Issue: ------------- - An error popup states: "Product has an invalid tax amount. Only 25%, 12%, 6% and 0% are allowed." even when the product is correctly configured with one of these tax rates. Cause: ---------- - The validation logic incorrectly applies conditions for displaying the error popup, mistakenly rejecting valid tax rates when the PoS receipt label is set. FIX: ----------- - Updated the tax validation conditions to handle products correctly, allowing tax rates, and preventing false error messages. task-4687156 Forward-Port-Of: odoo/enterprise#87275 Forward-Port-Of: odoo/enterprise#83221
38 changes
Enhancements to existing features
Updates Estonia accounting localization for the VAT rate increase from 22% to 24% effective 1 July 2025. The change adds the new VAT rate to taxes and reports while keeping the old 22% rate available for historical records and past reporting.
Original PR description
Added new tax and tax group for the 24% VAT rate effective from 1 July 2025. Updated account.tax.report to include a new line for the 24% VAT rate (Line 1) to ensure backward compatibility with reports generated before 1 July 2025. Updated account.tax.report to include a new line for the 22% VAT rate (Line 1_2). Ensured automatic creation of new taxes and tax groups during module upgrade. Adjusted related tax report data and views reflect the updated VAT rate. Maintained compatibility with existing data and reports by preserving the 22% VAT rate for historical records. For technical info please see: https://www.emta.ee/en/business-client/e-services-training-courses/how-use-e-services/technical-information-services#value-added-tax-return --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Estonia tax reporting module now supports the KMD6 VAT return format required from 1 July 2025. This helps businesses remain compliant with Estonia's standard VAT rate increase from 22% to 24% and submit reports in the updated official format.
Original PR description
Added compatibility with Estonia tax report version KMD6 that is valid from 1. July 2025. For technical info please see: https://www.emta.ee/en/business-client/e-services-training-courses/how-use-e-services/technical-information-services#value-added-tax-return
Resolved issues and error corrections
This fix lets users update the customer or vendor linked to already reconciled accounting entries, matching what is allowed during the initial reconciliation. It removes an unnecessary restriction so accounting teams can correct partner information without being blocked by reconciliation status.
Original PR description
This has been allowed since saas-12.5, https://github.com/odoo/odoo/commit/6b8acd025758b042cca39508bc8994a1307d1ccd, and is still currently allowed when making a new reconciliation: you can indeed select 2 aml with different partners. But for some reason, in https://github.com/odoo/odoo/commit/1b30777ab63998d1c0b64b655e717d74b3648bcf, we added a restriction to disallow changing that afterwards. All things considered, the change of partner on reconciled entries should be allowed since it's a non-relevant point when reconciling items together. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Sales orders for services that create projects now include the project account within each analytic distribution line instead of adding it as a separate line. This keeps cost and revenue allocation consistent with configured distribution models and avoids duplicate or misleading analytic entries.
Original PR description
1. Have sales and project installed 2. Create a service product which creates a project on order 3. Set up a distribution model for this service 4. Create a sales order with this service. Confirm it. 5. The project account is added to the analytic distribution in a separate line In odoo/odoo#199763, `_compute_analytic_distribution()` in the SO line was changed to add both project account and ditribution model accounts in the analytic distribution. However, the project account should not have its own line and should instead be added to all lines coming from Analytical Distribution Models. no-task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an accounting issue where cash basis VAT entries could include incorrect base tax tags when certain taxes used complex distribution rules. The change helps ensure tax reports reflect the right amounts and categories after vendor bills are paid and reconciled.
Original PR description
Steps to reproduce:
- Have a [TAX] configured with:
- Affect Base of Subsequent Taxes: True
- Base Affected by Previous Taxes: True
- Tax Exigibility: Based on payment
- Distribution for invoices:
- Base, Tax grids: +A, +B
- 100% of tax, Tax grids: +C
- -100% of tax, Tax grids: -D, -E
- Distribution for refunds:
- Base, Tax grids: -A, -B
- 100% of tax, Tax grids: -C
- -100% of tax, Tax grids: +D, +E
- Create a BILL with [TAX]
- Create a matching Bank statement and reconcile with BILL
- Check the created Cash Basis Entry
Issue:
VAT line will feature base tags +A, +B in addition to the tax tags +C
This occurs because in the source bill 2 tax lines are created, the first one got the origin tax assigned
When the cash basis move is created the tax tags will be taken also from that tax
opw-4729298Sales quotations for foreign customers now show the product name in the customer's language, even when the salesperson edits the line description. This avoids duplicate or untranslated product names and helps customers receive clearer, usable quotation PDFs.
Original PR description
Previously, when selling a product to a foreign customer, the translated product name was stored in the order line description. However, the salesman could update this description, and if he did, the product name would be automatically included in the quotation's line description but kept hidden to ensure it appears in the final quotation PDF. Unfortunately, the product name was not translated into the partner language. This commit keeps the previous behavior with the exception that the product name included in quotations' line descriptions is now translated into the partner language. opw-4760300 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change fixes an unreliable automated test in the HTML editor image cropper area. It helps keep validation runs stable so future updates can be checked with fewer false failures.
Original PR description
After merging this commit [1], the test sometimes non-deterministically fails on runbot. This PR aims to fix the test. [1]: https://github.com/odoo/odoo/commit/1a2c3c00869fd9702bb9d15e3d38d9c02a3349f5 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update improves the reliability of automated checks for the HTML editor by waiting for on-screen elements to finish appearing or disappearing before validating them. It helps prevent false test failures in slower environments, supporting smoother development and release validation without changing user-facing features.
Original PR description
### Purpose of this PR: - Add `expectElementCount` test helper to wait for elements to appear or disappear before asserting their count. This fixes flaky tests caused by timing issues and animations, especially on slower environments like runbot, in toolbar, link popover, powerbox, tablepicker, tablemenu, and emoji picker tests. task-4849995 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When customers upgrade to Odoo 18, the newly added Create Bill matching rule will now include the proper translation instead of appearing only in English. This improves consistency for users working in other languages, such as Spanish.
Original PR description
If customers migrate to version 18 from a lower version, 'Create Bill' record newly introduced so it just create but not translated. **Before fix:** ``` test_18=# select id,name from…
If customers migrate to version 18 from a lower version, 'Create Bill' record newly introduced so it just create but not translated.
**Before fix:**
```
test_18=# select id,name from account_reconcile_model;
id | name
----+----------------------------------------------------------------------------------------------------------------------------
3 | {"en_US": "Line with Bank Fees", "es_AR": "Línea con comisiones bancarias"}
1 | {"en_US": "Invoices/Bills Perfect Match", "es_AR": "Coincidencia perfecta de facturas"}
2 | {"en_US": "Invoices/Bills Partial Match if Underpaid", "es_AR": "Coincidencia parcial si hay pagos parciales en facturas"}
4 | {"en_US": "Create Bill"}
5 | {"en_US": "Internal Transfers", "es_AR": "Transferencias internas"}
```
**After Fix:**
```
test_18=# select id,name from account_reconcile_model;
id | name
----+----------------------------------------------------------------------------------------------------------------------------
1 | {"en_US": "Invoices/Bills Perfect Match", "es_AR": "Coincidencia perfecta de facturas"}
2 | {"en_US": "Invoices/Bills Partial Match if Underpaid", "es_AR": "Coincidencia parcial si hay pagos parciales en facturas"}
5 | {"en_US": "Internal Transfers", "es_AR": "Transferencias internas"}
3 | {"en_US": "Line with Bank Fees", "es_AR": "Línea con comisiones bancarias"}
4 | {"en_US": "Create Bill", "es_AR": "Crear factura"}
```
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-prImporting product eCommerce description data now updates the intended translated text without wiping existing translations or replacing the default value. This helps teams safely maintain multilingual product pages through file imports.
Original PR description
## Version: saas-18.0+ ## Issue: Importing eCommerce translations for products erase all existing translations and set the new one as default value, whatever the user's current language is. The…
## Version:
saas-18.0+
## Issue:
Importing eCommerce translations for products erase all existing translations and set the new one as default value, whatever the user's current language is.
The `website_description` acts the same.
## Steps to reproduce:
- From the user's `Preferences`:
- Add a second language you understand;
- Translate all websites and close without switching;
- Access `Sales / Products / Products`:
- Set a product as favorite and open it:
- Under the `Sales` tab, write something in the `ECOMMERCE DESCRIPTION` field;
- Open the translation wizard by clicking the `EN` link appearing when hovering the input:
- Write anything else in the second language's input field and save;
- Come back to the general products view (*`Sales / Products / Products`*):
- Change view to list and select the favorite item (*check the case of the record line*);
- Via the `Actions` button, click on `Export`:
- Check `I want to update data (import-compatible export)`;
- From the `Available fields` list, add `eCommerce Description`;
- Open the exported file:
- Change the `description_ecommerce` content and save;
- From the general products view (*`Sales / Products / Products`*):
- Ensure no product is selected;
- Click the gear next to `Products` then `Import records`
- Click `Upload Data File` and select the exported and modified file;
- Ensure the fields are well mapped;
- Test then import data;
## Cause:
Translation method refactoring via this PR: https://github.com/odoo/odoo/pull/170779, especially `update_field_translations(field_name, {"fr_FR": {"en2": "fr2"}})`, requiring a key (`en2`) and a value (`fr2`) for a given language as a `field_name` translation. Before the fix, giving only one value erases value and key for a given `field_name`
opw-4600662This change removes an extra click in an automated test for boolean fields in list views, preventing random failures caused by the value being toggled twice. It improves reliability of the testing process without changing how users interact with Odoo.
Original PR description
This commit fixes a test involving a boolean property field in list view that randomly fails. The problem was that we clicked twice to toggle the boolean value: once on the cell (I assume that it was done to switch the row in edition), and one on the checkbox to toggle it. However, boolean fields in list views don't require the row to be in edition to be toggled. So the first click already toggled the value, and the second click toggled it again, **sometimes** (I guess that's the non deterministic part, it was a question of timing there). So this commit fixes the issue by removing one of the 2 clicks. runbot error~224053 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
Unbuilding a manufacturing order now correctly applies warehouse putaway rules to the returned component items. This prevents inventory from being recorded in the wrong shelf or location, improving stock accuracy for manufacturing operations.
Original PR description
Steps to reproduce the bug: - Create a storable product “P1”: - Update the quantity to 1 in "WH/Stock" - Create a putaway rule: - From "WH/Stock" to "WH/Stock/Shelf1" - Create a manufacturing order:…
Steps to reproduce the bug:
- Create a storable product “P1”:
- Update the quantity to 1 in "WH/Stock"
- Create a putaway rule:
- From "WH/Stock" to "WH/Stock/Shelf1"
- Create a manufacturing order:
- Select any product to produce
- Add a component:
- 1 unit of P1
- Confirm and validate the MO
- Unbuild the order
Problem:
A stock move for P1 is created from "Virtual Location/Production" to "WH/Stock/Shelf1" instead of "WH/Stock".
This happens because the `_apply_putaway_strategy` method is not called on the `stock.move.line` linked to the move.
In previous versions (e.g., v17), this issue didn't occur because the quantity was directly set on the move. This triggered a write on the `stock.move` model, which in turn called `_set_quantity`. Since no `stock.move.line` was linked at that point, a new one was created, and its quantity was set via `_set_quantity_done`, which itself called `_apply_putaway_strategy`:
- https://github.com/odoo/odoo/blob/002724506123b8160dc05cc3654cf87e49b67933/addons/mrp/models/mrp_unbuild.py#L202
- https://github.com/odoo/odoo/blob/b377e7d586f75ea8418deb498d2d551999ec5143/addons/stock/models/stock_move.py#L399
- https://github.com/odoo/odoo/blob/b377e7d586f75ea8418deb498d2d551999ec5143/addons/stock/models/stock_move.py#L384
- https://github.com/odoo/odoo/blob/b377e7d586f75ea8418deb498d2d551999ec5143/addons/stock/models/stock_move.py#L2133
This scenario used to work only when the product was untracked:
- https://github.com/odoo/odoo/blob/002724506123b8160dc05cc3654cf87e49b67933/addons/mrp/models/mrp_unbuild.py#L186
However, starting from v18, some code was refactored to clean up unnecessary conditions. The `else` block was removed, and now, regardless of the product type, the quantity is not set directly on the move anymore. Instead, a `stock.move.line` is created using `_prepare_move_line_vals`:
- https://github.com/odoo/odoo/blob/002724506123b8160dc05cc3654cf87e49b67933/addons/mrp/models/mrp_unbuild.py#L197
But `_apply_putaway_strategy` is not called in this flow.
Bug introduced in v18.0, commit:
https://github.com/odoo/odoo/commit/79d9dd7f15371aa7293a4af0b0ebd193aa80e2be
opw-4830952This fixes an unreliable automated test for web navigation behavior. It helps keep quality checks stable by making sure the test waits for the page routing state before simulating browser back navigation.
Original PR description
This commit fixes an action service concurrency test that fails randomly. The way the test was written was prone to errors as we didn't wait for the router to be updated before doing browser back. As a matter of fact, we even asserted that we went 2 actions back in the breadcrumbs, whereas it should be only one as we did one browser.history.back(). runbot error~163078 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 the point of sale numpad from briefly appearing and disappearing when users tap the Old unit price text on combo product order lines. It improves the checkout experience for French certified POS sessions by avoiding confusing screen behavior during order editing.
Original PR description
Steps: ------ - Install `l10n_fr_pos_cert` - Open a PoS session, and add a combo product, orderlines corresponding to the combo procuts will be added - Hide the numpad by clicking on the selected…
Steps: ------ - Install `l10n_fr_pos_cert` - Open a PoS session, and add a combo product, orderlines corresponding to the combo procuts will be added - Hide the numpad by clicking on the selected orderline. - Choose a random orderline, and click on the text "Old unit price" -> Observe that the numpad will appear and then disappear immediately. Reason: ------- When clicking the text "Old unit price", two click events are dispatched, those running the click handler twice, the first time it selects the orderline and hence show the numpad, and the second time, it unselects that same orderline, hiding the numpad. Fix: ---- We disable the pointer-events on the "Old unit price" text, making it unclickable, more precisely, preventing it from being a `target` of a click event. With that change, the click handler (aka `clickLink` [1]) will only run once. [1]: https://github.com/odoo/odoo/blob/8fb7e5fd304697aebcce085602a5f3a1ecaf757a/addons/point_of_sale/static/src/app/screens/product_screen/order_summary/order_summary.xml#L9 opw-4636261
Emails with attachments sent to a Documents incoming address now use the company assigned to the target folder when creating the related email alias. This prevents company mismatch errors, so documents can be received correctly in folders owned by a specific company.
Original PR description
# Issue: When sending an email with an attachment to an incoming alias, if the target folder in Documents is explicitly owned by a specific company, an error occurs during alias creation: "We could…
# Issue: When sending an email with an attachment to an incoming alias, if the target folder in Documents is explicitly owned by a specific company, an error occurs during alias creation: "We could not create alias Inactive Alias because domain company1.com belongs to company YourCompany while the owner document belongs to company Company2." This issue arises because the `mail.alias.mixin.optional` model, when determining the `company_id` for the alias associated with the new document, might default to the system's company or another incorrect company, leading to a mismatch with the actual company of the explicitly-owned document folder. # Proposed solution: This commit modifies the `create` method of `mail.alias.mixin.optional` to prioritize the `company_id` of the document's target folder when setting the `company_id` for the associated alias. Specifically, within the loop where alias values are prepared: - It first attempts to retrieve the `company_id` directly from the `vals` dictionary for the current record. - If no `company_id` is explicitly provided in `vals` but a `folder_id` is present, it then checks the `company_id` of that `documents.folder`. - If the folder has an explicit `company_id`, this company is used as the effective `company_id` for the alias. - Otherwise, it falls back to the previously determined `company_id_default`. This ensures that the `company_id` used for alias domain validation aligns with the `company_id` of the document's folder, resolving the domain/owner company mismatch error. opw-4727873 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
HR managers can now choose Employee-specific assignment options, such as Coach or Manager, while creating a new activity plan before it is saved. This removes an extra save-and-reopen step and makes activity plan setup more consistent and efficient.
Original PR description
_Description of the issue/feature this PR addresses:_ When setting up a new activity template on a new activity plan, HR specific values for 'Assignment' such as Coach or Manager are not available.…
_Description of the issue/feature this PR addresses:_ When setting up a new activity template on a new activity plan, HR specific values for 'Assignment' such as Coach or Manager are not available. _Current behavior before PR:_ As an HR manager, go to menu HR -> Configuration -> Activity Plan. Click 'New'. Under Activities To Create, click 'Add a line'. Under 'Assignment', the only options available are Ask at launch and Default user. <img src="https://github.com/user-attachments/assets/97be6790-b450-42c6-910a-07483c30e175" width=50% height=50%> Cancel the 'Create Activities' popup. Give the plan a name and save it. Again, under Activities To Create, click 'Add a line'. Only now are HR specific options (Coach, Manager etc) available under 'Assignment'. _Desired behavior after PR is merged:_ HR specific values for 'Assignment' are immediately availalbe when setting up a new plan for the Employee model.  _Technical solution:_ Pass the plan's model as the default model for new templates so that the related field is populated with a value that unlocks the HR specific values before first saving the plan. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Subscription renewals will no longer add invoice lines for recurring items with an ordered quantity of zero. This avoids unnecessary or confusing invoice entries and keeps customer invoices cleaner.
Original PR description
Before this commit, when a recurring order_line had an invoice_policy "order" and the quantity was 0, it would be added to the invoice. taskid: 4841550
Delivery status buttons and switches in Point of Sale delivery views now align better on smaller screens. This makes mobile use clearer and easier for staff managing delivery orders.
Original PR description
Before this commit: === - The delivery status buttons (New, Ongoing, Done) and the toggle Switches were misaligned on smaller screens due to the use of grid layout, After this commit: === - The layout uses a flex-based structure, which ensures better alignment and spacing across screen sizes. Task: 4844890
Credit and debit notes are now included in India GSTR-3B section 3.1(a), making the reported taxable sales figures more complete. This helps businesses file GST returns with totals that better reflect adjustments made through credit or debit notes.
Original PR description
In Gstr-3B section 3.1(a) credit note/debit note should be calculated. This PR adds credit note/debit note into section 3.1(a). **Older Version PR:** https://github.com/odoo/enterprise/pull/87160 **opw**-https://www.odoo.com/odoo/project/49/tasks/4845457 **Task**-4852947
The EC Sales List now avoids incorrectly warning about duplicate VAT numbers when a partner has both invoices and refunds in the same reporting period. This helps users trust the report warnings and reduces unnecessary investigation of valid customer records.
Original PR description
Fixed the computation of `is_vat_duplicated` to avoid false positive in case of partners having both invoices and refunds in the selected period.
This fix prevents an error that could occur when a user opened an app through the command palette and immediately typed into the search field. It improves reliability of navigation in the Enterprise web interface and avoids an unexpected interruption for users.
Original PR description
Before this commit a traceback was occurring when opening an app using palette and then immediately passing a value in palette search input. After this commit the traceback will not occur anymore. task-4735048
Restaurant staff now keep the relevant order selected after accepting it or marking it as food ready in UrbanPiper POS. This reduces extra clicks and helps teams continue processing online orders without losing context.
Original PR description
Before this commit: === - After accepting an order or marking it as "Food Ready," no order was selected by default. After this commit: === - After accepting an order or marking it as "Food Ready," the respective order is automatically selected by default. task-4442911
Documentation and clarification updates
This pull request records Matias Gibbons' signed Contributor License Agreement. It helps ensure contributions can be accepted under Odoo's legal contribution process, with no effect on product features or users.
Original PR description
Contributor License Agreement for Matias Gibbons I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
Because the `location.assign` method also triggers a `beforeunload` event, the `error_service` doesn't handle errors when downloading a file with the action target `download` (for example download vCard). See [1] for more details about the original fix. task-4457865 [1]: https://github.com/odoo/odoo/commit/e96d3aa6d9181d83e34cefd9fe205f37df2e317c --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213103 Forward-Port-Of:
Original PR description
Because the `location.assign` method also triggers a `beforeunload` event, the `error_service` doesn't handle errors when downloading a file with the action target `download` (for example download vCard). See [1] for more details about the original fix. task-4457865 [1]: https://github.com/odoo/odoo/commit/e96d3aa6d9181d83e34cefd9fe205f37df2e317c --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213103 Forward-Port-Of: odoo/odoo#212432
Issue: The BuyerReference field in Xrechnung is only mandatory to be filled with the appropriate company reference for DE B2G invoices, but not having the company reference resuts in the field being absent entirely from the document for B2C and B2B invoices, which results in the document being rejected. Solution: If the BuyerReference is not filled, it is set to 'N/A' instead of being left absent from the document. Addresses ticket-4715709 task-4756812 --- I confirm I have signed the CL
Original PR description
Issue: The BuyerReference field in Xrechnung is only mandatory to be filled with the appropriate company reference for DE B2G invoices, but not having the company reference resuts in the field being absent entirely from the document for B2C and B2B invoices, which results in the document being rejected. Solution: If the BuyerReference is not filled, it is set to 'N/A' instead of being left absent from the document. Addresses ticket-4715709 task-4756812 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213152 Forward-Port-Of: odoo/odoo#212535
**Steps to reproduce 1:** - Install l10n_tz_account - Switch to a Tanzanian company (e.g. TZ Company) - Check the taxes **Issue 1:** Each tax has the same tax grids (i.e. same number and same sign) for the invoice section and the refund section, which leads to have the amount of the credit notes being added (instead of subtracted) in the Tax report. **Solution 1:** Invert the sign of the tax grids in the refund section. **Steps to reproduce 2:** - Create an invoice for a Tanzanian
Original PR description
**Steps to reproduce 1:** - Install l10n_tz_account - Switch to a Tanzanian company (e.g. TZ Company) - Check the taxes **Issue 1:** Each tax has the same tax grids (i.e. same number and same sign) for the invoice section and the refund section, which leads to have the amount of the credit notes being added (instead of subtracted) in the Tax report. **Solution 1:** Invert the sign of the tax grids in the refund section. **Steps to reproduce 2:** - Create an invoice for a Tanzanian customer without VAT **Issue 2:** The default fiscal position will be "International", instead of "Domestic". A domestic fiscal position for customer without VAT is missing. **Solution 2:** Add a "Domestic individual" fiscal position that is the same as the "Domestic" one except for the VAT that is not required. opw-4840609 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213107
- Vendor bills with taxes of l10n_es_type == 'sujeto_agricultura' (REAGYP) must be reported with regime code '19', as per TicketBAI specifications. - This fix ensures that such invoices include '19' in `regime_key`, avoiding schema validation errors and ensuring legal compliance. https://www.batuz.eus/fitxategiak/batuz/ticketbai/ticketbaiv1-2-2.xsd OPW-4532600 Forward-Port-Of: odoo/odoo#211229
Original PR description
- Vendor bills with taxes of l10n_es_type == 'sujeto_agricultura' (REAGYP) must be reported with regime code '19', as per TicketBAI specifications. - This fix ensures that such invoices include '19' in `regime_key`, avoiding schema validation errors and ensuring legal compliance. https://www.batuz.eus/fitxategiak/batuz/ticketbai/ticketbaiv1-2-2.xsd OPW-4532600 Forward-Port-Of: odoo/odoo#211229
Fix crash when a retention tax is applied on an invoice that includes a down payment line. Steps to reproduce: 1. Create a retention tax (negative, with retention checked) 2. Create a sale order with product A 3. Create and validate a down payment invoice 4. Create the full invoice and add the retention tax to the line of product A 5. Try to submit to ZATCA This raises: `IndexError: list index out of range → tax_category_vals = self._get_tax_category_list(...)[0]` The issue occur
Original PR description
Fix crash when a retention tax is applied on an invoice that includes a down payment line. Steps to reproduce: 1. Create a retention tax (negative, with retention checked) 2. Create a sale order with product A 3. Create and validate a down payment invoice 4. Create the full invoice and add the retention tax to the line of product A 5. Try to submit to ZATCA This raises: `IndexError: list index out of range → tax_category_vals = self._get_tax_category_list(...)[0]` The issue occurs because the retention tax is not filtered due to a missing `filter_to_apply` parameter. opw-4771567 Forward-Port-Of: odoo/odoo#210567 Forward-Port-Of: odoo/odoo#208946
\*: website_mail This PR addresses several issues in the blog module, including: Commit [1]: retain follow-us input button when logged in - Steps to reproduce: 1. Go to any blog post. 2. Enable the sidebar. 3. Select any category (e.g., Travel). Issue: A subscribe button appears in the 'Follow Us' section. - Solution: Currently, the input field is only shown to public users. This happens because the input element is restricted by the `base.groups_public` group in the XML code. Si
Original PR description
\*: website_mail This PR addresses several issues in the blog module, including: Commit [1]: retain follow-us input button when logged in - Steps to reproduce: 1. Go to any blog post. 2. Enable the…
\*: website_mail This PR addresses several issues in the blog module, including: Commit [1]: retain follow-us input button when logged in - Steps to reproduce: 1. Go to any blog post. 2. Enable the sidebar. 3. Select any category (e.g., Travel). Issue: A subscribe button appears in the 'Follow Us' section. - Solution: Currently, the input field is only shown to public users. This happens because the input element is restricted by the `base.groups_public` group in the XML code. Since this is an XML change in v17.0 (stable version), we need to implement the fix in JS instead. After that, we will adapt the code from the master branch. Commit [2]: remove unnecessary months from blog category - Steps to reproduce: 1. Have a blog post in a category (e.g., Astronomy) published in Feb-2025. 2. In another category (e.g., Travel), have blog posts in both Jan-2025 and Feb-2025. 3. When selecting the Astronomy category, the sidebar `Archives` filter shows all months, even if no blog post exists in Jan 2025. - Solution: It will now show only months that contain blog posts for the selected category. Filter out from the backend according to their publishing date. Commit [3]: correct tag redirection to backend in blog posts - Steps to reproduce: 1. Go to any blog post. 2. Turn on the sidebar. 3. Create a new blog post. 4. Save it. Issue : clicking `add some` on tags redirects to the homepage instead of the backend of that blog post. - Solution: a wrong URL was inserted in the anchor tag. For stable, we changed it from JS, but it will be applied to XML in master. task-4546888 Forward-Port-Of: odoo/odoo#210641 Forward-Port-Of: odoo/odoo#197172
### Reason - In Product module, there are two type of product types : type and detailed_type. While they share similar names, they filter different results. The type field only filters consumables and services, whereas detailed_type have type + more specific categories such as Clothing, Electronics, Furniture,...etc making it more relevant for users. - I suggest change the default filter to detailed_type to avoid confusion. Since users are likely to rely on this filter frequently, it should
Original PR description
### Reason - In Product module, there are two type of product types : type and detailed_type. While they share similar names, they filter different results. The type field only filters consumables…
### Reason - In Product module, there are two type of product types : type and detailed_type. While they share similar names, they filter different results. The type field only filters consumables and services, whereas detailed_type have type + more specific categories such as Clothing, Electronics, Furniture,...etc making it more relevant for users. - I suggest change the default filter to detailed_type to avoid confusion. Since users are likely to rely on this filter frequently, it should be set as the default not type. Description of the issue/feature this PR addresses: Current behavior before PR: -Filter by type:  Desired behavior after PR is merged: -Filter by detailed_type:  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212183
Steps to reproduce: 1.- Install ecommerce. 2.- On the top right we click on edit. 3.- Go to customize > Customers > Rating. 4.- Now go to the bottom of the page and open the ratings. Issue: After the changes done in odoo#121104 we have change a few things, between those things, we are passing the rating stats inside the message when previously we used to add it as another key, also we are computing the same stats for all the messages that we have when we only need it 1 time. Solut
Original PR description
Steps to reproduce: 1.- Install ecommerce. 2.- On the top right we click on edit. 3.- Go to customize > Customers > Rating. 4.- Now go to the bottom of the page and open the ratings. Issue: After the changes done in odoo#121104 we have change a few things, between those things, we are passing the rating stats inside the message when previously we used to add it as another key, also we are computing the same stats for all the messages that we have when we only need it 1 time. Solution: Adapt frontend to properly get the rating_stats and avoid computing them more than what is needed. opw-4155895 Forward-Port-Of: odoo/odoo#183541
The `subscribe to known partner presences` test ensures a bus subscription is sent when a new partner (whose presence needs tracking) is discovered. However, this test is prone to race conditions due to non-deterministic subscription timing: - `addChannels` is debounced and called once at the beginning (for the current user from session data), and again after `init_messaging`. This means the timing of the RPC affects the number of subscriptions: 1 if it's fast enough to fall within the first
Original PR description
The `subscribe to known partner presences` test ensures a bus subscription is sent when a new partner (whose presence needs tracking) is discovered. However, this test is prone to race conditions due…
The `subscribe to known partner presences` test ensures a bus subscription is sent when a new partner (whose presence needs tracking) is discovered. However, this test is prone to race conditions due to non-deterministic subscription timing: - `addChannels` is debounced and called once at the beginning (for the current user from session data), and again after `init_messaging`. This means the timing of the RPC affects the number of subscriptions: 1 if it's fast enough to fall within the first call, or 2 otherwise. - `forceUpdateChannel` is also debounced, so the final subscription depends on how these debounces overlap. Ultimately, the test only aims to verify that discovering a new partner or guest adds their presence to the subscription. Using the full flow introduces unnecessary points of failure. This commit rewrites the test to use `store.insert` instead, giving more control over the flow while preserving the test's intent. fixes runbot-161223,182043,182044 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 Forward-Port-Of: odoo/odoo#212332
**Steps to reproduce:** 1. Accounting > Configuration Menu > Journals 2. Archive a Journals with outgoing payment method 3. Go to Expenses > Configuration Menu 4. Settings > Payment methods Under Accounting 5. Notice that the payment methods from archived journals are still visible **Issue:** - In this commit https://github.com/odoo/odoo/commit/c4f21085f8f77d8786eb1bc9494ae0fc1327b8b8 the overridden action_archived method was removed, which previously prevented journals with link
Original PR description
**Steps to reproduce:** 1. Accounting > Configuration Menu > Journals 2. Archive a Journals with outgoing payment method 3. Go to Expenses > Configuration Menu 4. Settings > Payment methods Under Accounting 5. Notice that the payment methods from archived journals are still visible **Issue:** - In this commit https://github.com/odoo/odoo/commit/c4f21085f8f77d8786eb1bc9494ae0fc1327b8b8 the overridden action_archived method was removed, which previously prevented journals with linked payment methods from being archived. **Solution:** - Update the company_expense_allowed_payment_method_line_ids field's domain field to include only payment methods from active journals opw-4745525 Forward-Port-Of: odoo/odoo#210314
This updates the app information for the Asset Management area. It is a minor housekeeping change that helps keep the module details accurate and consistent, with no expected impact on day-to-day business workflows.
In test_generate_all_export_files, PDF and XLSX reports were not generated due to them timing-out the runbot, which was happening randomly. This has been fixed here by only testing the generation of the data then given to wkhtmltopdf, since wkhtmltopdf is quite slow and can randomly create errors. This is taking about 4 minutes with this fix when all reporting modules are enabled in v17.0 but taking around 20 minutes when creating PDFs. task-3603619 Forward-Port-Of: odoo/enterprise#863
Original PR description
In test_generate_all_export_files, PDF and XLSX reports were not generated due to them timing-out the runbot, which was happening randomly. This has been fixed here by only testing the generation of the data then given to wkhtmltopdf, since wkhtmltopdf is quite slow and can randomly create errors. This is taking about 4 minutes with this fix when all reporting modules are enabled in v17.0 but taking around 20 minutes when creating PDFs. task-3603619 Forward-Port-Of: odoo/enterprise#86307
When the post_invoice_hook failed, and sale_subscription_stock was installed, all subscription invoiced would have a "Delivery creation failed" activity created, even if no delivery needed to be created. This commit filter out the subscriptions without any stock lines that needs the stock rule to be run. OPW-4618930 Forward-Port-Of: odoo/enterprise#85604
Original PR description
When the post_invoice_hook failed, and sale_subscription_stock was installed, all subscription invoiced would have a "Delivery creation failed" activity created, even if no delivery needed to be created. This commit filter out the subscriptions without any stock lines that needs the stock rule to be run. OPW-4618930 Forward-Port-Of: odoo/enterprise#85604
### Steps to reproduce: - Have an overdue invoice - Go to Accounting > Customers > Follow-up Reports and click the partner - Change the state of the report to something different than the first state - Click "Follow-up", select "By post" and send - Settings > technical > Email > Snailmail Letters find the letter corresponding to the report - Check the PDF, it is using the mail template of the first followup level ### Cause: When sending a followup report, the followup level of the repo
Original PR description
### Steps to reproduce: - Have an overdue invoice - Go to Accounting > Customers > Follow-up Reports and click the partner - Change the state of the report to something different than the first state…
### Steps to reproduce: - Have an overdue invoice - Go to Accounting > Customers > Follow-up Reports and click the partner - Change the state of the report to something different than the first state - Click "Follow-up", select "By post" and send - Settings > technical > Email > Snailmail Letters find the letter corresponding to the report - Check the PDF, it is using the mail template of the first followup level ### Cause: When sending a followup report, the followup level of the report is recomputed for it to have the correct value. Then the report is generated. But the option to send a letter uses methods from the module `snailmail` for example `` which don't have options. The options are then recomputed to generate the report, reading [`partner.followup_line_id`](https://github.com/odoo/enterprise/blob/c8dac822cf3df23922488f33c07a114bbea05198/account_followup/models/account_followup_report.py#L42) so getting the wrong value. ### Solution: Add a context key to pass the value of `followup_line` to the report generation after snailmail. opw-4766804 Forward-Port-Of: odoo/enterprise#85717
Currently, the VAT is split into two columns only if the VAT code consists solely of numeric values. However, in practice, VAT code may contain a combination of letters and numbers. **Steps to reproduce :** 1) Install `l10n_de_reports` and switch to the `DE` company 2) Create a partner with VAT as `NL000099998B57` from contacts 3) Now create a confirmed invoice for the above created partner 4) Go to "Accounting / Reporting / Audit Reports / General Ledger" 5) Download "DATEV DATA (Z
Original PR description
Currently, the VAT is split into two columns only if the VAT code consists solely of numeric values. However, in practice, VAT code may contain a combination of letters and numbers. **Steps to…
Currently, the VAT is split into two columns only if the VAT code consists solely of numeric values. However, in practice, VAT code may contain a combination of letters and numbers. **Steps to reproduce :** 1) Install `l10n_de_reports` and switch to the `DE` company 2) Create a partner with VAT as `NL000099998B57` from contacts 3) Now create a confirmed invoice for the above created partner 4) Go to "Accounting / Reporting / Audit Reports / General Ledger" 5) Download "DATEV DATA (ZIP)" and check "EXTF_customer_account.csv" **Issue:** Notice that the VAT was not split into country and VAT code for the above created partner. **Cause:** Previously, the code only split the VAT into country code and VAT code if the first two characters were alphabetic and the remainder was numeric. https://github.com/odoo/enterprise/blob/35944a38d306ea881e08e1d51ca77a3eab3a6e36/l10n_de_reports/models/datev_export_csv.py#L220-L227 This approach is insufficient because many countries have VAT codes that include both letters and numbers. For example vat formats for `NL` and `AT` https://business.gov.nl/finance-and-taxes/vat/numbers-for-vat/ https://ec.europa.eu/taxation_customs/vies/#/faq So by only checking whether the VAT code is numberic is not a valid thing. **Solution:** The code now uses the partner’s `_split_vat` method to separate the country code and VAT code whenever a VAT is provided and has more than two characters. It then validates the split VAT using the `simple_vat_check` helper method. If the VAT is valid, the country code (in uppercase) and the VAT code are output in separate columns; otherwise, the original VAT value is kept. This change ensures that VAT numbers with alphanumeric codes are correctly handled and split into their respective columns. opw-4820929 Forward-Port-Of: odoo/enterprise#87167 Forward-Port-Of: odoo/enterprise#86992