Thursday, April 17, 2025
40 changes · 18.0
Enhancements to existing features
This change adds a reusable way for Odoo to find the default sale orders linked to a process. It makes future customizations easier and safer for businesses that extend sales workflows.
Original PR description
in this commit: - added a helper function to get sale order ids which can be override in inherited models. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
Point of Sale receipts now show the tax label that applies after a fiscal position changes the tax. This prevents mismatches between receipt line labels and tax details, reducing confusion for cashiers and customers.
Original PR description
When using a fiscal position the tax group labels on the receipt order lines where not adapted correctly Steps to reproduce: ------------------- * Create 2 taxes A and B * For each tax go to their corresponding tax group and set the label to "A" and "B" * Create a fiscal position that will match A on B * Add the fiscal position to the PoS * Create a new order and add a product that uses the A tax * Activate the fiscal position * Validate the order and go to the receipt > Observation: The orderline will show the label A but the order tax detail will correctly show the label B Why the fix: ------------ When generating the display data for the orderline we need to first map the taxes according to the fiscal position. opw-4579223
Miscellaneous changes
Before this commit, when the user enables the task dependencies feature globally, all basic projects (that is, non fsm ones) will get the feature. By doing that, the open tasks state will be recomputed to set `Waiting` state on tasks with blocking tasks linked to them. The problem is the compute method of the task state will also reset the state instead of keeping the one set on those open tasks when there is no blocking task linked. This commit makes sure the compute method of task state fie
Original PR description
Before this commit, when the user enables the task dependencies feature globally, all basic projects (that is, non fsm ones) will get the feature. By doing that, the open tasks state will be…
Before this commit, when the user enables the task dependencies feature globally, all basic projects (that is, non fsm ones) will get the feature. By doing that, the open tasks state will be recomputed to set `Waiting` state on tasks with blocking tasks linked to them. The problem is the compute method of the task state will also reset the state instead of keeping the one set on those open tasks when there is no blocking task linked. This commit makes sure the compute method of task state field is no longer called when the task dependencies feature changes. Instead, a inverse method is added on allow_task_dependencies field on `project.project` model to correctly update the state of the tasks linked to the project in which the task dependencies feature changed. Steps to reproduce the issue: ---------------------------- 0. install project 1. Create a project 2. Create some tasks inside that project and changes the state to some tasks 3. Enable the task dependencies feature in `Project > Configuration > Settings` menu. 4. Go back to the tasks kanban view of that project. Current Behavior: ---------------- The state of those tasks is reset to `In progress` (if those tasks did not have a state equals to `Done` or `Canceled`). Expected Behavior: ----------------- The state of those tasks should not be altered since no dependencies are added in those tasks yet. task-4487922 Forward-Port-Of: odoo/odoo#206156 Forward-Port-Of: odoo/odoo#198952
Portal users can now search mail messages by related recipients more reliably. This prevents searches from bypassing the intended mail-specific logic, improving consistency when users look up conversations or followed records.
Original PR description
When searching `message_partner_ids`, we have a search method that will replace the domain, so `_condition_to_sql` will not be called for that field. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a small issue in event email processing when multiple records are handled at once. It helps ensure event-related email updates are applied to the correct record, reducing the risk of inconsistent behavior in less common batch scenarios.
Original PR description
Looping on self, but updating self. As this method is generally called on a singleton recordset no error has been reported but better safe than sorry.
Clearing the Point of Sale cache could leave some reward lines without their related coupon data, causing the POS to get stuck while loading. The fix cleans up those inconsistent order lines during this debug cache-clear scenario, helping the POS recover without affecting normal sales workflows.
Original PR description
After clearing the cache you can have inconsistent reward lines that have no coupon associated with them. Steps to reproduce: ------------------- * Create an order and add any reward (Buy X Get Y for example) * Go to the backend to make sure the order is saved in the database * Go back to the POS and clear the cache > Observation: You are stuck on the loading screen Why the fix: ------------ To avoid having inconsistent reward lines that have no coupon associated with them, we delete all the lines of an order that contains wrong data. As this is not supposed to happen (clearing the cache is a debug functionality), we can safely delete the lines because it's wont impact the real workflow of the users. opw-4655422
Accounting entries now include the country of the related commercial partner. This prepares the accounting module for improved filtering and reporting by partner location.
Original PR description
The commercial partner country field is required for later improvements namely filtering or reports related ones. --- task-4725240 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Creating a new contact from autocomplete could fail when a lowercase GST or VAT number was entered and selected from the suggestions. The fix normalizes those tax identifiers during lookup, preventing the error and making contact creation more reliable.
Original PR description
The system throws an error due to missing `name` in values during RPC `onchange` call Steps to Reproduce: 1. Open the `Contacts app` and click `New`. 2. Enter `32aadcs3224n1zf` as the name. 3. From the autocomplete dropdown, select a company. Error: `KeyError: 'name'` Solution: Added upper() transformation for GST and VAT numbers during autocomplete search to normalize input and avoid missing key errors. Sentry - 6327760196 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The sale details report now calculates totals based on the specific POS configuration, preventing blackbox-related rules from affecting regular POS setups. This helps businesses see accurate sales totals when the blackbox module is installed but not used for every POS configuration.
Original PR description
Before this commit, if the POS blackbox module was installed, the sale details report would display total price in price included because of an override. In this commit, we add the config id to the method computing this price so that the blackbox module can override this computation only if the config is a blackbox one. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix makes the PDF quote builder target the correct sales order line views when customizing quote layouts. It prevents custom or Studio-added sections from being mistaken for the main order line area, reducing the risk of incorrect behavior in sales quote forms.
Original PR description
Description of the issue/feature this PR addresses: sale_pdf_quote_builder uses `//` for selection of the kanban and list views of the order lines rather than `/`. Current behavior before PR: However, in the upstream view the form view is declared first. If any extension, or studio change embeds a list or kanban view inside the form, the current selectors will pick that up instead of the list and kanban views associated with the order line. Desired behavior after PR is merged: More accurately select the correct insertion point of the inherited view OPW-4716782 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Adds example placeholder text for the Peppol EAS field so users know what information to enter when setting up electronic invoicing. This reduces confusion during partner setup and Peppol registration without changing the underlying process.
Original PR description
Add a placeholder for Peppol EAS field. task-4544834 (Part-of)
The Belgian POS blackbox module now skips IP logging when no web request is available, preventing point-of-sale tests and automated session starts from failing. Sale details processing also checks that a configuration uses blackbox before applying blackbox-specific logic.
Original PR description
Before this commit, when pos_blackbox_be was installed, the pos tests were failing because most pos test called `_run_test` which is calling `_satrt_pos_session` which is calling `open_new_session` which is calling `set_opening_control`. This makes that when calling `set_opening_control`, the request is not bound and we cannot do `request.geoip.ip`. We now check that the request is bound in `_log_ip`: if it is not, we return, if it is, we resolve the ip on the fly.
This update fixes the Argentina electronic invoicing connection so it works reliably on both older Python versions and Python 3.12. It helps avoid connection failures when companies or hosting environments upgrade Python.
Original PR description
We adapted it to make it work depending on the version of Python used. It works for version 3.10.6 and below, but for Python 3.12, it fails. We adapted it so it can work in both Python versions Adhoc task 47274
This fix changes Brazilian Avalara account creation so missing fields are sent as empty text instead of false values. This prevents Avalara from storing "false" in account details, reducing EDI processing problems for affected Brazilian tax integrations.
Original PR description
Avalara populates those fields as "false" in the account, which causes issues during EDI. We keep sending the fields, but send empty string instead. opw-4716571
The salesperson subscription dashboard now uses the correct source values and ranking lists in churn, contraction, and expansion tables. This improves the accuracy of reported subscription performance so sales teams can rely on the dashboard for decision-making.
Original PR description
fix wrong formulas in different tables: - in "worst churn" under Value, starting the 7th line, the value used was "recurring_monthly" instead of "amount_signed" - in "worst contraction", the 10th line didn't use the list 4 like the rest of the table - in "top expansion", the 10th line didn't use the list 2 like the rest of the table Task: 4711532
Before this commit, several invisible fields were present in the views in `l10n_ch`, whereas after https://github.com/odoo/odoo/pull/162009 these fields need to be either justified or removed. The needed fields are fetched automatically after https://github.com/odoo/odoo/pull/137031. This commit adds a comment to each field so that the tests pass in stable versions, to avoid potential issues with inheritance in custom views. We will removes the unnecessary invisible fields in master.
Original PR description
Before this commit, several invisible fields were present in the views in `l10n_ch`, whereas after https://github.com/odoo/odoo/pull/162009 these fields need to be either justified or removed. The needed fields are fetched automatically after https://github.com/odoo/odoo/pull/137031. This commit adds a comment to each field so that the tests pass in stable versions, to avoid potential issues with inheritance in custom views. We will removes the unnecessary invisible fields in master. opw-4629332 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205501
**Current behavior:** When receiving product after having billed it already, if: A) the product is valuated, B) the purchase is in a foreign currency, C) there is an underlying exchange diff between time of bill and receiption then the exchange difference account move will occur in the regular exchange account. **Expected behavior:** It should be for the stock valuation account. **Steps to reproduce:** *with anglo saxon accounting enabled* 1. Create a real-time valuated product in
Original PR description
**Current behavior:** When receiving product after having billed it already, if: A) the product is valuated, B) the purchase is in a foreign currency, C) there is an underlying exchange diff between…
**Current behavior:** When receiving product after having billed it already, if: A) the product is valuated, B) the purchase is in a foreign currency, C) there is an underlying exchange diff between time of bill and receiption then the exchange difference account move will occur in the regular exchange account. **Expected behavior:** It should be for the stock valuation account. **Steps to reproduce:** *with anglo saxon accounting enabled* 1. Create a real-time valuated product invoiced on ordered qty 2. Activate a foreign currency, set some exchange rate for today and tomorrow (unique) 3. Make a purchase for the product, invoice -> post 4. The next day, receive the product 5. Check the exchange journal to see the offending AMLs **Cause of the issue:** In this flow, when the receipt is validated, at this point: *from `_validate_accounting_entries()`* https://github.com/odoo/odoo/blob/7e7c1abeead0d4ef19ec15d50808ab33a642d25e/addons/stock_account/models/account_move.py#L185 the SVL linkage is somewhat broken because the bill's SVL was generated before the receiption's. It means the exchange diff reconciliation proceeds as "usual" (without the `stock_account` module impacting the process) so the regular journal and accounts are used to record the amounts. **Fix:** Add overrides for getting the relevant journal and account(s) inside `_prepare_exchange_difference_move_vals()` in order to prevent `real_time` valuated product moves from generating AMLs in the ordinary exchange account (instead, use the stock journal and stock valuation account resp.) opw-4655669 Forward-Port-Of: odoo/odoo#204505
* When checking model coherency for sms, if choose transient model -> raise ValidationError message but the message seem not follow with the code so much 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#205196 Forward-Port-Of: odoo/odoo#188760
Original PR description
* When checking model coherency for sms, if choose transient model -> raise ValidationError message but the message seem not follow with the code so much 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#205196 Forward-Port-Of: odoo/odoo#188760
Replace the non-standard '🠖' (->) character with an arrow icon in the `_search_render_results()` method for consistent and proper rendering across browsers and platforms. Forward-Port-Of: odoo/odoo#205862
Original PR description
Replace the non-standard '🠖' (->) character with an arrow icon in the `_search_render_results()` method for consistent and proper rendering across browsers and platforms. Forward-Port-Of: odoo/odoo#205862
A check on the object received by the IoT Box containing certificate keys was always returning `False`, resulting in the certificate never being applied to the box in addition to an excessive amount of requests to odoo.com. Forward-Port-Of: odoo/odoo#206070 Forward-Port-Of: odoo/odoo#206040
Original PR description
A check on the object received by the IoT Box containing certificate keys was always returning `False`, resulting in the certificate never being applied to the box in addition to an excessive amount of requests to odoo.com. Forward-Port-Of: odoo/odoo#206070 Forward-Port-Of: odoo/odoo#206040
# Context: A recent improvement (https://github.com/odoo/odoo/pull/203739) slightly changed how the search domain for `ancestors` operates. Before it ignored note subtypes, i.e. `'subtype_id', '!=', note_type.id`. After the PR, it now matches all messages as long as they have a subtype. In doing so, it didn't account for the fact that in some production database, you might have `mail.message` records that have **no** message_id set, i.e. `message_id == False`. In such cases a traceba
Original PR description
# Context: A recent improvement (https://github.com/odoo/odoo/pull/203739) slightly changed how the search domain for `ancestors` operates. Before it ignored note subtypes, i.e. `'subtype_id', '!=',…
# Context:
A recent improvement (https://github.com/odoo/odoo/pull/203739) slightly changed how the search domain for `ancestors` operates. Before it ignored note subtypes, i.e. `'subtype_id', '!=', note_type.id`.
After the PR, it now matches all messages as long as they have a subtype.
In doing so, it didn't account for the fact that in some production database, you might have `mail.message` records that have **no** message_id set, i.e. `message_id == False`.
In such cases a traceback would be generated when sending a message from a mail.thread having an ancestor without `message_id` set.
Example:
```
references = ' '.join(m.message_id for m in (ancestors + message_sudo))
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: sequence item 1: expected str instance, bool found
```
While such records *should* not exist when using the ORM, they might be the result of:
* certain upgrade scripts that use direct SQL (cf https://github.com/odoo/upgrade/blob/06b9e7f3cd98c383698695d6028bb7adefb6f805/migrations/base_vat/saas~16.3.1.0/pre-migrate.py#L104-L120)
* direct SQL inserts by users or/and customisations
# Proposed solution:
Since there are no ad-hoc mecanismes to fix such records on productions, the next best thing would be to simply adapt the search domain for `ancestors` and ignore any records where `message_id == False`. Indeed, if there is no `message_id` it makes no sense to try to add it in the references header.
# Reproduction steps:
1) Setup database and install contacts
2) Pick a contact and post a log note
3) For this new `mail.message` write `message_id == False` in the backend 4) Try to send a new message to the contact
-> Traceback
OPW-4728399
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#206279This commit removes four banner-related commands: Banner Info, Banner Success, Banner Warning, and Banner Danger. These commands have been removed in favor of using the Alert command, which offers the same functionality through a fully customizable Alert snippet. Now, when users search for terms like 'Banner', 'Info', 'Success', 'Warning' or 'Danger', the Alert command will appear in the Powerbox instead of the previous banner commands. task-3572344 --- I confirm I have signed the CLA
Original PR description
This commit removes four banner-related commands: Banner Info, Banner Success, Banner Warning, and Banner Danger. These commands have been removed in favor of using the Alert command, which offers the same functionality through a fully customizable Alert snippet. Now, when users search for terms like 'Banner', 'Info', 'Success', 'Warning' or 'Danger', the Alert command will appear in the Powerbox instead of the previous banner commands. task-3572344 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206090 Forward-Port-Of: odoo/odoo#180313
Revealed by the nightly single app tests now testing every module, possibly some other module (and formerly demo data) hides the issue by setting a country which happens to work on the current company. Since #127204 `action_stripe_connect_account` will raise an error if the current company's country is not in `SUPPORTED_COUNTRIES`. When installing the module and running the test, the country is `False`, which is not a country supported by stripe. Ensure a supported country is set before ru
Original PR description
Revealed by the nightly single app tests now testing every module, possibly some other module (and formerly demo data) hides the issue by setting a country which happens to work on the current company. Since #127204 `action_stripe_connect_account` will raise an error if the current company's country is not in `SUPPORTED_COUNTRIES`. When installing the module and running the test, the country is `False`, which is not a country supported by stripe. Ensure a supported country is set before running the test. https://runbot.odoo.com/odoo/error/163118 Forward-Port-Of: odoo/odoo#206141 Forward-Port-Of: odoo/odoo#206066
Forward-Port-Of: odoo/odoo#206289
Original PR description
Forward-Port-Of: odoo/odoo#206289
Steps to reproduce: 1. Install `l10n_in_ewaybill_stock` and `sale_management` 2. Activate Units of measure 3. Create SO and add SO line with a product uom having units 4. Set this parameter `Quantity -> 1`, `UoM -> Dozen`, `Price Unit -> 12` 5. Confirm SO and related picking delivery 6. Create and generate E-waybill 7. Print Receipt The actual Taxable amount should be Rs. 12 but instead it shows 144 In this commit we fix the following issue opw-4728253 --- I confirm I hav
Original PR description
Steps to reproduce: 1. Install `l10n_in_ewaybill_stock` and `sale_management` 2. Activate Units of measure 3. Create SO and add SO line with a product uom having units 4. Set this parameter `Quantity -> 1`, `UoM -> Dozen`, `Price Unit -> 12` 5. Confirm SO and related picking delivery 6. Create and generate E-waybill 7. Print Receipt The actual Taxable amount should be Rs. 12 but instead it shows 144 In this commit we fix the following issue opw-4728253 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206094
Printing the E-Way Bill failed if the company logo was not configured, as the QWeb template attempted to render an image using a non-existent logo. Steps to reproduce: - Remove the company logo from the company settings - Try to print an E-Way Bill for any invoice Expected: - The E-Way Bill should be printed successfully without a logo Actual: - PDF generation fails due to a template rendering error Now: - The template checks for the presence of a logo before rendering it, allow
Original PR description
Printing the E-Way Bill failed if the company logo was not configured, as the QWeb template attempted to render an image using a non-existent logo. Steps to reproduce: - Remove the company logo from the company settings - Try to print an E-Way Bill for any invoice Expected: - The E-Way Bill should be printed successfully without a logo Actual: - PDF generation fails due to a template rendering error Now: - The template checks for the presence of a logo before rendering it, allowing the E-Way Bill to print even if the logo is not set. opw-4709233 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206190
This PR introduces a regression test to ensure that the sitemap remains in the default language of the website, regardless of the language version being accessed. Tests 2 scenarios: - First, configure a website with English and French language. - Set the default language to French. - Access the sitemap at /sitemap.xml -> The sitemap should be displayed in French. - Second, let the default language to be English. - Navigate to the French version of the website at /fr. - Access t
Original PR description
This PR introduces a regression test to ensure that the sitemap remains in the default language of the website, regardless of the language version being accessed. Tests 2 scenarios: - First,…
This PR introduces a regression test to ensure that the sitemap
remains in the default language of the website, regardless of the
language version being accessed.
Tests 2 scenarios:
- First, configure a website with English and French language.
- Set the default language to French.
- Access the sitemap at /sitemap.xml -> The sitemap should be displayed
in French.
- Second, let the default language to be English.
- Navigate to the French version of the website at /fr.
- Access the sitemap at /sitemap.xml -> The sitemap should now be
displayed in English.
This test addresses an issue that was previously fixed in commit
https://github.com/odoo/odoo/commit/809854c5d10735fb280141f5291bdb84d8d36569, but lacked a corresponding test to prevent future
regressions. This test ensures the bug reported in task-3935135 does ``
not reoccur.
**Added test in website_blog as it has routes that were translated.
Reference:
[1]: https://github.com/odoo/odoo/pull/154993#pullrequestreview-1900639267
Forward-Port-Of: odoo/odoo#190779Contains two commits. One adds the node in `account_edi_ubl_cii` module and one to adapt the Nilvera e-invoice to use it. Forward-Port-Of: odoo/odoo#204508
Original PR description
Contains two commits. One adds the node in `account_edi_ubl_cii` module and one to adapt the Nilvera e-invoice to use it. Forward-Port-Of: odoo/odoo#204508
Steps to reproduce: - Install `project` - Create a new `project` and `tasks` within it. - Share the project with the portal user with edit access mode. Issue: - The color picker is not accessible through the portal. Fix: - Hide the color picker for portal users when editing color in shared tasks. task-4495861 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206139 Forward-Port-Of: odoo/odoo#2020
Original PR description
Steps to reproduce: - Install `project` - Create a new `project` and `tasks` within it. - Share the project with the portal user with edit access mode. Issue: - The color picker is not accessible through the portal. Fix: - Hide the color picker for portal users when editing color in shared tasks. task-4495861 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206139 Forward-Port-Of: odoo/odoo#202058
Before this commit, the text wrapping in the product categories sometimes resulted in ugly breaks in the middle of words where not needed. Steps to reproduce ----- 1. Configure a category with spaces in Point of Sale > Configuration > PoS Product Categories For example, a category named "Special Menu" 2. Open a self-ordering kiosk, the "Special Menu" will be displayed as "Special M" + "enu" Cause ----- The styling `word-break: break-all;` was added to this element in #140095 to avoid
Original PR description
Before this commit, the text wrapping in the product categories sometimes resulted in ugly breaks in the middle of words where not needed. Steps to reproduce ----- 1. Configure a category with spaces in Point of Sale > Configuration > PoS Product Categories For example, a category named "Special Menu" 2. Open a self-ordering kiosk, the "Special Menu" will be displayed as "Special M" + "enu" Cause ----- The styling `word-break: break-all;` was added to this element in #140095 to avoid overlapping category names. However `break-all` always breaks in the exact place needed, often resulting in breaks in the middle of words. Solution ----- Use `overflow-wrap: break-word;` instead which will break between words if possible and only break in the middle of a word if needed. opw-4642999 Forward-Port-Of: odoo/odoo#205080
Versions -------- - 16.0+ Steps ----- 1. Run the `test_gift_card_email_sender` without `website_sale_loyalty`. Issue ----- `AttributeError` Cause ----- The `sale_loyalty` test calls `_auto_apply_rewards`, which is defined in `website_sale_loyalty`. Solution -------- The test works just as well without the method call, so we can simply remove it. runbot-163194 Forward-Port-Of: odoo/odoo#206295
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Run the `test_gift_card_email_sender` without `website_sale_loyalty`. Issue ----- `AttributeError` Cause ----- The `sale_loyalty` test calls `_auto_apply_rewards`, which is defined in `website_sale_loyalty`. Solution -------- The test works just as well without the method call, so we can simply remove it. runbot-163194 Forward-Port-Of: odoo/odoo#206295
Revert odoo/enterprise#81587 because errors are triggered on dry-run. Also see discussion here: ref: https://github.com/odoo/enterprise/pull/82900#issuecomment-2800848343 Forward-Port-Of: odoo/enterprise#83422 Forward-Port-Of: odoo/enterprise#83391
Original PR description
Revert odoo/enterprise#81587 because errors are triggered on dry-run. Also see discussion here: ref: https://github.com/odoo/enterprise/pull/82900#issuecomment-2800848343 Forward-Port-Of: odoo/enterprise#83422 Forward-Port-Of: odoo/enterprise#83391
### Step to reproduce: - In the settings enable Multi-step routes - Inventory > Configuration > Warehouse Management > Warehouses - Put you warehouse in manufacturing in 2 steps - Create a bill of material for a final product FP with one raw: - 3 x COMP (storable product with 10 units in stock) - Create and confirm an MO for 1 unit of FP. > This create a picking from stock to preprod for 3 unit of COMP - In the shopfloor on your MO click on the 3 dots and add components - Register
Original PR description
### Step to reproduce: - In the settings enable Multi-step routes - Inventory > Configuration > Warehouse Management > Warehouses - Put you warehouse in manufacturing in 2 steps - Create a bill of…
### Step to reproduce:
- In the settings enable Multi-step routes
- Inventory > Configuration > Warehouse Management > Warehouses
- Put you warehouse in manufacturing in 2 steps
- Create a bill of material for a final product FP with one raw:
- 3 x COMP (storable product with 10 units in stock)
- Create and confirm an MO for 1 unit of FP.
> This create a picking from stock to preprod for 3 unit of COMP
- In the shopfloor on your MO click on the 3 dots and add components
- Register a new unit of COMP
> The picking from stock to pre-prod was updated twice, hence for 5 units
### Cause of the issue:
When you add a product from the shopfloor, we create a new move from pre-prod to virtual/production with the corresponding `product_uom_qty` of 1 and confirm it:
https://github.com/odoo/enterprise/blob/fc1fb4c56da916b165c43d8f6b6a4b903733a12f/mrp_workorder/wizard/additional_product.py#L63-L68 Since the procure method of this move has been adjusted, this confirmation will correctly create and run a procurement to generate a move from stock to pre-prod. Note that this part of the flow is strictly necessary if the additional product is not already part of the component raw of the MO. However, since in the present case there is already move raw from pre-prod to virtual/production associated to that product, the action confirm will also merge our additional move with the current existing one and hence modify its `product_uom_qty`. However, an override of mrp ensures that when such modification happen, we should also run the procurement to ensure that modifying the demand of a move will also update the related pickings:
https://github.com/odoo/odoo/blob/7def831bea18a91e4fa0f9c6aa6de34f4d6d18c8/addons/mrp/models/stock_move.py#L413-L419 Since we already run that same procurement we should bypass this call in our case.
opw-4562965
Forward-Port-Of: odoo/enterprise#82958
Forward-Port-Of: odoo/enterprise#81818Steps to reproduce: 1. Create a new BoM w/ a pass/fail operation step 2. Create a manufacturing order using that BoM 3. Go the the Quality app 4. Open the quality check created for the MO 5. Click on Pass (or Fail, does not matter) 6. Go back to the MO and click Produce All 7. The qty_passed/qty_failed is not computed on the quality check opw-4552103 Forward-Port-Of: odoo/enterprise#80291
Original PR description
Steps to reproduce: 1. Create a new BoM w/ a pass/fail operation step 2. Create a manufacturing order using that BoM 3. Go the the Quality app 4. Open the quality check created for the MO 5. Click on Pass (or Fail, does not matter) 6. Go back to the MO and click Produce All 7. The qty_passed/qty_failed is not computed on the quality check opw-4552103 Forward-Port-Of: odoo/enterprise#80291
Tests were moved to l10n_ch_hr_payroll_elm_account in https://github.com/odoo/enterprise/pull/64454 Forward-Port-Of: odoo/enterprise#83456 Forward-Port-Of: odoo/enterprise#81018
Original PR description
Tests were moved to l10n_ch_hr_payroll_elm_account in https://github.com/odoo/enterprise/pull/64454 Forward-Port-Of: odoo/enterprise#83456 Forward-Port-Of: odoo/enterprise#81018
### Issue: It is currently not possible to generate a return label with sendcloud if the delivery has been generated using a service point. ### Step to reproduce: - Set up Sendcloud, for a belgian company - Select bpost and dpd for delivery and returns while loading products - On a private window buy a storable product on the webstore online and select a sendcloud pickup point as the delivery method. - With an employee confirm the delivery order that was created #### > A problem occ
Original PR description
### Issue: It is currently not possible to generate a return label with sendcloud if the delivery has been generated using a service point. ### Step to reproduce: - Set up Sendcloud, for a belgian…
### Issue: It is currently not possible to generate a return label with sendcloud if the delivery has been generated using a service point. ### Step to reproduce: - Set up Sendcloud, for a belgian company - Select bpost and dpd for delivery and returns while loading products - On a private window buy a storable product on the webstore online and select a sendcloud pickup point as the delivery method. - With an employee confirm the delivery order that was created #### > A problem occured in the generation of the return label ### Cause of the issue: The `to_service_point` parameter is used by sendcloud's API in order to generate parcels and is added here: https://github.com/odoo/enterprise/blob/747482f34ca8210d89d81b3363ec5a8fc3a4ff6f/delivery_sendcloud/models/sendcloud_service.py#L109-L112 However, this parameter does not make sense in case of a return since the customer is allowed to return the product to the pickup point of its choice. In particular, sendcloud's API will fail to genrate the return parcel if it is expecting to link the label to a given pickup point. #### Note: Sendcloud also fails to generate the return label when the shipping provider is the same for the delivery and for the return, so that the `to_service_point` can just not be provided for return labels. opw-4562040 Forward-Port-Of: odoo/enterprise#83436 Forward-Port-Of: odoo/enterprise#83357
Currently, an error may occur when we try to export the trial balance with the SAT (XML) format. This is because a None id is used to browse the account, due to a more specific account_group. Steps to reproduce: - Install l10n_mx_reports. - Create an account_group with a more specific account, such as 401.01.01 - The 4, 401, and 401.01 groups are created with demo data. - Go to trial balance and try exporting with "SAT (XML)". An error will occur (`AttributeError: 'bool' object has
Original PR description
Currently, an error may occur when we try to export the trial balance with the SAT (XML) format. This is because a None id is used to browse the account, due to a more specific account_group.
Steps to reproduce:
- Install l10n_mx_reports.
- Create an account_group with a more specific account, such as 401.01.01
- The 4, 401, and 401.01 groups are created with demo data.
- Go to trial balance and try exporting with "SAT (XML)".
An error will occur (`AttributeError: 'bool' object has no attribute 'startswith'`) because the account is None, so account have no type.
opw-4716047
Forward-Port-Of: odoo/enterprise#83392
Forward-Port-Of: odoo/enterprise#83197**Steps to reproduce:** - Install Accounting and l10n_pe_edi - Switch to a Peruvian company (e.g. PE Company) - Configure Peruvian localization (https://www.odoo.com/documentation/17.0/applications/finance/fiscal_localizations/peru.html) - Create an invoice: * Customer: Comercial Constructora los Patitos S.A. * Operation Type: [0101] Internal sale * Invoice Lines: - Product: [any with a UNSPSC Category] - Taxes: 18% - Terms and Conditions: [text containing special cha
Original PR description
**Steps to reproduce:**
- Install Accounting and l10n_pe_edi
- Switch to a Peruvian company (e.g. PE Company)
- Configure Peruvian localization (https://www.odoo.com/documentation/17.0/applications/finance/fiscal_localizations/peru.html)
- Create an invoice:
* Customer: Comercial Constructora los Patitos S.A.
* Operation Type: [0101] Internal sale
* Invoice Lines:
- Product: [any with a UNSPSC Category]
- Taxes: 18%
- Terms and Conditions: [text containing special characters like '/' or '.']
- Confirm the invoice
- Process UBL 2.1
**Issue:**
In the XML, the content of <cbc:Note> has been stripped of all special characters like [/\!?+-=%.,;:()].
Only "whitespace" special characters should be excluded (i.e. '\n', '\u00A0',...).
opw-4659655
Forward-Port-Of: odoo/enterprise#82787Steps to reproduce: ------------------- * Install l10n_cl_edi_stock * Create a new Transfer * Add as customer a Contact that is part of a Company * Print Delivery Guide SII DTE 52 (CL) > Observation: Why the fix: ------------ The name of the company has to be shown not the actual name of ths customer Legal requirement in Chile ref: https://www.sii.cl/factura_electronica/formato_dte.pdf https://github.com/odoo/odoo/pull/172793 opw-4676871 Forward-Port-Of: odoo/enterprise#83311
Original PR description
Steps to reproduce: ------------------- * Install l10n_cl_edi_stock * Create a new Transfer * Add as customer a Contact that is part of a Company * Print Delivery Guide SII DTE 52 (CL) > Observation: Why the fix: ------------ The name of the company has to be shown not the actual name of ths customer Legal requirement in Chile ref: https://www.sii.cl/factura_electronica/formato_dte.pdf https://github.com/odoo/odoo/pull/172793 opw-4676871 Forward-Port-Of: odoo/enterprise#83311
The SP-API doesn't support SKU containing commas, not even when escaping and listing them in a correct CSV like string, as they'll be considered as either separate SKU or a different one, thus leading to an error saying there are too many identifiers, or not recognizing them anyway. In order to let the synchronization continue for the other items, ensure their SKU are valid beforehand. As from Amazon side, using a comma is a valid value, we can't constrain the SKU either. opw-4710435
Original PR description
The SP-API doesn't support SKU containing commas, not even when escaping and listing them in a correct CSV like string, as they'll be considered as either separate SKU or a different one, thus leading to an error saying there are too many identifiers, or not recognizing them anyway. In order to let the synchronization continue for the other items, ensure their SKU are valid beforehand. As from Amazon side, using a comma is a valid value, we can't constrain the SKU either. opw-4710435 Forward-Port-Of: odoo/enterprise#83367