Thursday, January 2, 2025
30 changes · saas-18.1
Enhancements to existing features
The Helpdesk live chat test setup was cleaned up to make automated checks easier to maintain. This helps reduce future maintenance effort and supports more reliable validation without changing customer-facing behavior.
Original PR description
Enterprise counter-part. task-4354325
Resolved issues and error corrections
The live chat message box now hides the attach file button when file uploads are not allowed. This prevents users from clicking a button that appears available but does nothing, reducing confusion during chats.
Original PR description
Before this PR, the attachm file button in the composer was displayed even if upload was not allowed. Clicking on this button woudln't do anything since upload is forbidden. This PR hides the upload file action is upload is not allowed. task-4433082 https://github.com/odoo/enterprise/pull/76259
Miscellaneous changes
Following #184846, the data validation is no longer necessary in a production context. Moreover, it currently limits some capacities for the user to user the history of the spreadsheets. Eg: - Create a new field with studio - Add a datasouce in a spreadsheet which relies on that field - make a bunch of revision - Delete the field you created - Go back to the spreadsheet - Open the version history and try to "make a copy" of some recent revision => it will throw as you try to create
Original PR description
Following #184846, the data validation is no longer necessary in a production context. Moreover, it currently limits some capacities for the user to user the history of the spreadsheets. Eg: - Create…
Following #184846, the data validation is no longer necessary in a production context. Moreover, it currently limits some capacities for the user to user the history of the spreadsheets. Eg: - Create a new field with studio - Add a datasouce in a spreadsheet which relies on that field - make a bunch of revision - Delete the field you created - Go back to the spreadsheet - Open the version history and try to "make a copy" of some recent revision => it will throw as you try to create a spreadsheet with invalid fields However, the data validation still make sense to alert developpers to adapts dashboards when they change the schema of some tables. This revision deactivates the data validation on production which ensures that the last point is still respected while developping (will be detected by runbot tests). Task: 4363803 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#188792
The task form now avoids keeping a duplicate hidden project field that could confuse customizations. This makes task form changes more predictable for teams extending or configuring project workflows, with no expected change for everyday users.
Original PR description
Before this commit, when we do an xpath to place something around the project field in the task form view, the xpath will select the first field found and the project field is actually defined twice in the task form view, once always invisible outside the content of the form view and the other is displayed in the view. This commit removes the first project field defined in the task form view since it is not really needed to have that field in invisible since the project field is always visible and so always available in the task form view. task-4420743
This update adjusts WhatsApp tests to match the corrected composer behavior, where extra action options are hidden when unavailable. It helps ensure the file attachment button continues to work reliably for users.
Original PR description
The community counterpart of this PR hides the composer more actions button when none are availanle. This PR adapt a whatsapp test that was relying on the old behavior. task-4433082 community: https://github.com/odoo/odoo/pull/191831
- Implemented proper validation logic for Uruguayan VAT numbers (RUT). - Now supports VAT numbers starting with '22', addressing previous validation issues. - Corrections in l10n_uy tests due to changes in logic. Task: 1292 adhoc-task-side: 45613 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192116 Forward-Port-Of: odoo/odoo#191066
Original PR description
- Implemented proper validation logic for Uruguayan VAT numbers (RUT). - Now supports VAT numbers starting with '22', addressing previous validation issues. - Corrections in l10n_uy tests due to changes in logic. Task: 1292 adhoc-task-side: 45613 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192116 Forward-Port-Of: odoo/odoo#191066
### Description of the issue this PR addresses: Test TestSaleComboConfigurator.test_sale_combo_configurator (introduced with #186645) depends on the Sale menu being shown, but it isn't if the sale_management module is not installed. This change skips this test in this case. ### Current behavior before PR: The test fails on odoo.sh with custom modules that only depend on sale and not sale_management. ### Desired behavior after PR is merged: The test succeeds in the condition mentio
Original PR description
### Description of the issue this PR addresses: Test TestSaleComboConfigurator.test_sale_combo_configurator (introduced with #186645) depends on the Sale menu being shown, but it isn't if the sale_management module is not installed. This change skips this test in this case. ### Current behavior before PR: The test fails on odoo.sh with custom modules that only depend on sale and not sale_management. ### Desired behavior after PR is merged: The test succeeds in the condition mentionned above. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192148
When field widgets were ported to OWL in 48ef812a, a few ARIA attributes were not adapted correctly. For instance, in the statusbar widget, the title was ported as an `aria-label` attribute ("Current state" and "Not active state"), which overrides the actual status name. This commit fixes the above issue by removing the incorrect `aria-label` attributes and fixing logic for other ones like `aria-checked`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/s
Original PR description
When field widgets were ported to OWL in 48ef812a, a few ARIA attributes
were not adapted correctly. For instance, in the statusbar widget, the
title was ported as an `aria-label` attribute ("Current state" and "Not
active state"), which overrides the actual status name.
This commit fixes the above issue by removing the incorrect `aria-label`
attributes and fixing logic for other ones like `aria-checked`.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#191494
Forward-Port-Of: odoo/odoo#183447Some accounts got the wrong code, while the id rightly changed --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191844 Forward-Port-Of: odoo/odoo#191826
Original PR description
Some accounts got the wrong code, while the id rightly changed --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191844 Forward-Port-Of: odoo/odoo#191826
Tax included in price were not taken into account when using a loyalty program applying on the cheapest product. Steps to reproduce: ------------------- * Create a loyalty program that apply 10% reward on cheapest product * Create a product A that has 10% tax included in price * Open PoS and add this product to the order (make sure this is the cheapest in the order) > Observation: The discount is not taking the tax into account opw-4243827 Forward-Port-Of: odoo/odoo#191846 Forward
Original PR description
Tax included in price were not taken into account when using a loyalty program applying on the cheapest product. Steps to reproduce: ------------------- * Create a loyalty program that apply 10% reward on cheapest product * Create a product A that has 10% tax included in price * Open PoS and add this product to the order (make sure this is the cheapest in the order) > Observation: The discount is not taking the tax into account opw-4243827 Forward-Port-Of: odoo/odoo#191846 Forward-Port-Of: odoo/odoo#189612
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#192143
Original PR description
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#192143
Currently below error occurs when creating a time-off type. Error: `ValueError: invalid literal for int() with base 10: '84,000'` Steps to reproduce :- - Open 'Time Off' >> Go to 'Configuration' >> Click 'Time off Types' >> Click 'New' . - Give 'Time off Type' a name >> Enable 'Allow Negative Cap' >> Set 'Maximum Excess Amount' >> Hit 'Save'. - The error appears in the log. This commit solves the above issue by removing the `widget`. sentry-6184334906 Forward-Port-Of: odoo/odoo#1
Original PR description
Currently below error occurs when creating a time-off type. Error: `ValueError: invalid literal for int() with base 10: '84,000'` Steps to reproduce :- - Open 'Time Off' >> Go to 'Configuration' >> Click 'Time off Types' >> Click 'New' . - Give 'Time off Type' a name >> Enable 'Allow Negative Cap' >> Set 'Maximum Excess Amount' >> Hit 'Save'. - The error appears in the log. This commit solves the above issue by removing the `widget`. sentry-6184334906 Forward-Port-Of: odoo/odoo#191978
Authentication data was accidentally logged when sending requests to the Authorize API. This change stops logging such data to avoid security breaches. opw-4311870 Forward-Port-Of: odoo/odoo#191219
Original PR description
Authentication data was accidentally logged when sending requests to the Authorize API. This change stops logging such data to avoid security breaches. opw-4311870 Forward-Port-Of: odoo/odoo#191219
This commit's purpose is to remove the cost from the aal of manufacturing order from the 'other cost' section and put it inside the 'manufacturing order' section. This section currently contains only the MO linked to a work order. task - 4184226 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/odo
Original PR description
This commit's purpose is to remove the cost from the aal of manufacturing order from the 'other cost' section and put it inside the 'manufacturing order' section. This section currently contains only the MO linked to a work order. task - 4184226 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#186607
This commit's purpose is to put the aal generated from deliveries into the 'materials' section under the costs section in the project profitability panel. Currently, those aal are considered as random aal and put under the 'other costs' section. This does not sees very appropirate. In order to be able to differentiate aal created on the fly and the aal generated from picking, a new option is added on the already existing selection field 'category' in order to avoid a heavy search and computat
Original PR description
This commit's purpose is to put the aal generated from deliveries into the 'materials' section under the costs section in the project profitability panel. Currently, those aal are considered as random aal and put under the 'other costs' section. This does not sees very appropirate. In order to be able to differentiate aal created on the fly and the aal generated from picking, a new option is added on the already existing selection field 'category' in order to avoid a heavy search and computation on the move.line model. version 18.0 - master task - 4180276 Forward-Port-Of: odoo/odoo#184121
**Issue:** in the Saudi Arabia localization, the delivery address is not displayed on invoices even if `Customer Addresses` is enabled. **Steps to reproduce:** 1. Go to settings and enable `Customer Addresses`. 2. Install the Saudi Arabia localization. 3. create an invoice with a delivery address other than the customer's. 4. Print the invoice. 5. notice that the delivery address is not displayed on the invoice. **Solution:** - Added the delivery address to the invoice report next t
Original PR description
**Issue:** in the Saudi Arabia localization, the delivery address is not displayed on invoices even if `Customer Addresses` is enabled. **Steps to reproduce:** 1. Go to settings and enable `Customer Addresses`. 2. Install the Saudi Arabia localization. 3. create an invoice with a delivery address other than the customer's. 4. Print the invoice. 5. notice that the delivery address is not displayed on the invoice. **Solution:** - Added the delivery address to the invoice report next to the QR code. opw-4337379 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190976
### Steps to reproduce the issue: 1. Activate Mexican Localization 2. In Mexican Company, add USD as Currency and give it a Rate 3. Create a Sales Journal and a Pricelist with USD as main Currency 4. _Point of Sale > Configuration > Settings_: Select a Shop and set the USD Journal and Pricelist 5. Open a Session using the USD Shop and complete some Orders, without invoicing them 6. _Point of Sale > Orders > Orders_, select the created Orders and, in the Actions, Create Global Invoice 7.
Original PR description
### Steps to reproduce the issue: 1. Activate Mexican Localization 2. In Mexican Company, add USD as Currency and give it a Rate 3. Create a Sales Journal and a Pricelist with USD as main Currency 4.…
### Steps to reproduce the issue: 1. Activate Mexican Localization 2. In Mexican Company, add USD as Currency and give it a Rate 3. Create a Sales Journal and a Pricelist with USD as main Currency 4. _Point of Sale > Configuration > Settings_: Select a Shop and set the USD Journal and Pricelist 5. Open a Session using the USD Shop and complete some Orders, without invoicing them 6. _Point of Sale > Orders > Orders_, select the created Orders and, in the Actions, Create Global Invoice 7. The document should be accepted, but TipoCambio has a rate of 1.000000. ### Explanation: During the creation of the Global Invoice, the rate is retrieved during `pos.order._prepare_tax_base_line_values` and, since no value is given through POS, the default value is used. https://github.com/odoo/odoo/blob/8fb7e5fd304697aebcce085602a5f3a1ecaf757a/addons/account/models/account_tax.py#L1242 https://github.com/odoo/odoo/blob/8fb7e5fd304697aebcce085602a5f3a1ecaf757a/addons/account/models/account_tax.py#L1212-L1213 https://github.com/odoo/odoo/blob/8fb7e5fd304697aebcce085602a5f3a1ecaf757a/addons/account/models/account_tax.py#L1188-L1193 ### Fix reasoning: `pos.order.currency_rate` is the rate of the Currency at the time the order was created. It is the perfect value to use for `TipoCambio`. We must also adapt workflows that were designed with the absence of `rate` in `tax_base_line_values`. Test in Enterprise opw-4302180 Forward-Port-Of: odoo/odoo#189700
Steps to reproduce : ------------------------- - Install the point_of_sale module. - Order something and go to payment page. - Apply multiple payment lines even with 0 amount. Issue : ------- The payment lines with 0 amount is also shown on receipt as well. Cause : ---------- We never checked for the amount of paymentline. Fix : ---- Updated the condition to remove 0 amount paymentline from the view. task - 4285705 Forward-Port-Of: odoo/odoo#192115 Forward-Port-Of: odoo/od
Original PR description
Steps to reproduce : ------------------------- - Install the point_of_sale module. - Order something and go to payment page. - Apply multiple payment lines even with 0 amount. Issue : ------- The payment lines with 0 amount is also shown on receipt as well. Cause : ---------- We never checked for the amount of paymentline. Fix : ---- Updated the condition to remove 0 amount paymentline from the view. task - 4285705 Forward-Port-Of: odoo/odoo#192115 Forward-Port-Of: odoo/odoo#185448
**Problem**: When destroying a snippet, listeners are not cleared. As a result, when focusing on a new instance of `ReplaceMedia`, the previous listeners remain active with stale context (old `$target`), which no longer has a parent since it was removed during the `img` change. **Solution**: Clear listeners during the `destroy` process. **Steps to reproduce**: 1. Open the website. 2. Add items. 3. Change an image. 4. Unlink that image. 5. Observe a traceback. opw-4412300 ---
Original PR description
**Problem**: When destroying a snippet, listeners are not cleared. As a result, when focusing on a new instance of `ReplaceMedia`, the previous listeners remain active with stale context (old `$target`), which no longer has a parent since it was removed during the `img` change. **Solution**: Clear listeners during the `destroy` process. **Steps to reproduce**: 1. Open the website. 2. Add items. 3. Change an image. 4. Unlink that image. 5. Observe a traceback. opw-4412300 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191142
Currently, a traceback is occurring when the user removes the `uom` and tries to change the `product_uom_qty` in the stock move. While creating the Manufacturing Order. To reproduce this issue: 1) Install MRP and enable UOM from the configuration 2) Create a new mrp order and add a product in components 3) Remove the UOM and change the `To Consume` value Error:- ``` AssertionError: precision_rounding must be positive, got 0.0 ``` This traceback occurs because when the user c
Original PR description
Currently, a traceback is occurring when the user removes the `uom` and tries to change the `product_uom_qty` in the stock move. While creating the Manufacturing Order. To reproduce this issue: 1) Install MRP and enable UOM from the configuration 2) Create a new mrp order and add a product in components 3) Remove the UOM and change the `To Consume` value Error:- ``` AssertionError: precision_rounding must be positive, got 0.0 ``` This traceback occurs because when the user changes the `product_uom_qty`, an onchange method `_onchange_product_uom_qty` will triggered. In that method, `float_round` is used with precision_rounding getting from `product_uom.rounding`. It leads to the above traceback as `product_uom` has an empty recordset. sentry-6170644216 Forward-Port-Of: odoo/odoo#191605
Issue: In the task action view of the sale order, the task ID is passed in the action domain, which results in showing only old tasks. Newly created tasks are not visible because their IDs are not included in the domain. Solution: Instead of passing task ids, we now check for project_id, sale_order_id, or sale_line_id to ensure the new tasks are properly displayed. Steps to Reproduce: - Install the sale_project module. - Create a Sale Order (SO). - Add a product con
Original PR description
Issue: In the task action view of the sale order, the task ID is passed in the action domain, which results in showing only old tasks. Newly created tasks are not visible because their IDs are not included in the domain. Solution: Instead of passing task ids, we now check for project_id, sale_order_id, or sale_line_id to ensure the new tasks are properly displayed. Steps to Reproduce: - Install the sale_project module. - Create a Sale Order (SO). - Add a product configured to create a project with tasks. - Click on the "Tasks" smart button from the SO. - Go to the Kanban view. - Create a new task and give a name. - Reload the page. - Check if the task is visible (the issue was that new tasks were not visible). Affected PR: https://github.com/odoo/odoo/pull/135771/files task-4224564 Forward-Port-Of: odoo/odoo#192005 Forward-Port-Of: odoo/odoo#184879
Currently, when deleting a quotation/SO with a custom `sale.order.spreadsheet`, the latter will see its field `order_id` empty and will become available to be linked to a quotation template. Since it's a custom spreadsheet for that specific SO, it makes no sense to keep it. opw-4385254 Forward-Port-Of: odoo/enterprise#76238
Original PR description
Currently, when deleting a quotation/SO with a custom `sale.order.spreadsheet`, the latter will see its field `order_id` empty and will become available to be linked to a quotation template. Since it's a custom spreadsheet for that specific SO, it makes no sense to keep it. opw-4385254 Forward-Port-Of: odoo/enterprise#76238
To retrieve the radio button corresponding to the currently-selected status in the statusbar, selector is currently relying on the attribute `aria-label`, but such attribute is incorrect and will be removed. Better relying on the attribute `aria-checked`, which indicates if the radio button is actually checked. Forward-Port-Of: odoo/enterprise#76053 Forward-Port-Of: odoo/enterprise#72063
Original PR description
To retrieve the radio button corresponding to the currently-selected status in the statusbar, selector is currently relying on the attribute `aria-label`, but such attribute is incorrect and will be removed. Better relying on the attribute `aria-checked`, which indicates if the radio button is actually checked. Forward-Port-Of: odoo/enterprise#76053 Forward-Port-Of: odoo/enterprise#72063
### Steps to reproduce the issue: 1. Activate Mexican Localization and use Mexican Company 2. Create an Invoice and set CFDI to public to True 3. In list view, select Invoice 4. In Actions, Create Global Invoice and Confirm 5. Log as User without Admin Rights 6. Select Invoice 7. Receive access error: > Sorry, [user] doesn't have 'read' access to: > - Attachment (ir.attachment) ### Explanation: When creating a Global Invoice, `ir.attachment` is created as well and link
Original PR description
### Steps to reproduce the issue: 1. Activate Mexican Localization and use Mexican Company 2. Create an Invoice and set CFDI to public to True 3. In list view, select Invoice 4. In Actions, Create…
### Steps to reproduce the issue: 1. Activate Mexican Localization and use Mexican Company 2. Create an Invoice and set CFDI to public to True 3. In list view, select Invoice 4. In Actions, Create Global Invoice and Confirm 5. Log as User without Admin Rights 6. Select Invoice 7. Receive access error: > Sorry, [user] doesn't have 'read' access to: > - Attachment (ir.attachment) ### Explanation: When creating a Global Invoice, `ir.attachment` is created as well and linked to the Global Invoice `l10n_mx_edi.document`, but if the link from document to attachment is complete, the opposite is not the case. `ir.attachment.res_id` has a value of 0, and, when checking access rights for `ir.attachment`, we will use the `_search` method in which one of three conditions, two of them having a `res_id` check, must be fulfilled for `ir.attachment` to be considered available to the user. https://github.com/odoo/odoo/blob/afdfbc4041f167ba6d6ff6c17b8432eb531df6b1/odoo/addons/base/models/ir_attachment.py#L561-L570 A user that did not Create Global Invoice and without `base.group_system` in their `groups_id` fulfills none of those conditions. ### Fix reasoning: The issue lies more within `res_id` not being `l10n_mx_edi.document.id` rather than a flaw in `_search`. This change should only apply when creating a Global Invoice. When sending an Invoice to the CFDI through the regular `action_send_and_print` process, `ir.attachment` is linked to `account.move` instead. opw-4365535 Forward-Port-Of: odoo/enterprise#76255 Forward-Port-Of: odoo/enterprise#75031
When the `l10n_be_hr_payroll_sepa_salary_payment` context option is passed, an extra `<Ustrd>` gets generated with the Urgency SEPA flag. After the refactoring in odoo/enterprise#60393, when there is no recognized reference type in the default `_get_RmtInf()` generation[^1], we end up with 2 Ustrd elements like this: ```xml <RmtInf> <Ustrd>SPLIP/1234</Ustrd> <Ustrd>/A/ SPLIP/1234</Ustrd> </RmtInf> ``` The SEPA file then gets rejected by banks as invalid. Instead we should detect
Original PR description
When the `l10n_be_hr_payroll_sepa_salary_payment` context option is passed, an extra `<Ustrd>` gets generated with the Urgency SEPA flag. After the refactoring in odoo/enterprise#60393, when there is no recognized reference type in the default `_get_RmtInf()` generation[^1], we end up with 2 Ustrd elements like this: ```xml <RmtInf> <Ustrd>SPLIP/1234</Ustrd> <Ustrd>/A/ SPLIP/1234</Ustrd> </RmtInf> ``` The SEPA file then gets rejected by banks as invalid. Instead we should detect the pre-existing element and update it. [^1]: https://github.com/odoo/enterprise/blob/42b7b322d6c720de45661e3370397adaf74fe1f4/account_iso20022/models/account_journal.py#L324-L326 Forward-Port-Of: odoo/enterprise#74692
Before this commit: Only `companyName` is included in shipping requests sent to FedEx. After this commit: `personName` is added to the request, same as `companyName`. According to FedEx documentation, it is not required if the address is `buisness` but we get an error if the `deliveryAddress` and `soldTo` address are different. Checked with FedEx support, and they said it is required to send the `personName` field always. opw-4415536 Forward-Port-Of: odoo/enterprise#76307
Original PR description
Before this commit: Only `companyName` is included in shipping requests sent to FedEx. After this commit: `personName` is added to the request, same as `companyName`. According to FedEx documentation, it is not required if the address is `buisness` but we get an error if the `deliveryAddress` and `soldTo` address are different. Checked with FedEx support, and they said it is required to send the `personName` field always. opw-4415536 Forward-Port-Of: odoo/enterprise#76307
Currently, An error occurs when reloading the DIAN configuration in an account journal to obtain the security token of a certificate, if no certificate is available. Step to produce: - Install the `l10n_co_dian` module. - Navigate to Settings and click on Certificates under the Certificates and Keys section. - And delete a 'Demo DIAN Certificate'. - Open any Journals and click on a 'Reload DIAN configuration'. `IndexError: tuple index out of range` The error occurs because the sys
Original PR description
Currently, An error occurs when reloading the DIAN configuration in an account journal to obtain the security token of a certificate, if no certificate is available. Step to produce: - Install the `l10n_co_dian` module. - Navigate to Settings and click on Certificates under the Certificates and Keys section. - And delete a 'Demo DIAN Certificate'. - Open any Journals and click on a 'Reload DIAN configuration'. `IndexError: tuple index out of range` The error occurs because the system attempts to access the certificate's token from a company at [1], but it is not available. Link [1]: https://github.com/odoo/enterprise/blob/a354a19060338084df35a14ed7f21defc3c05c11/l10n_co_dian/xml_utils.py#L123 To resolve this issue, Raise a validation error if a certificate is not found when the system attempts to retrieve its security token. Sentry-6165073693 Forward-Port-Of: odoo/enterprise#76052
This commit's purpose is to add a test for the full flow of the creation of a BOM/MO when they are linked to a project. This is to ensure that the aal generated are generated correctly and that the project profitability is then computing them into the correct section. community pr: https://github.com/odoo/odoo/pull/186607 task - 4184226 affetced version 18.0 - master Forward-Port-Of: odoo/enterprise#74398
Original PR description
This commit's purpose is to add a test for the full flow of the creation of a BOM/MO when they are linked to a project. This is to ensure that the aal generated are generated correctly and that the project profitability is then computing them into the correct section. community pr: https://github.com/odoo/odoo/pull/186607 task - 4184226 affetced version 18.0 - master Forward-Port-Of: odoo/enterprise#74398
## Issue: - Uploading a Mexican XML file with an 8% tax results in the addition of an extra 8% tax. ## Steps to reproduce: - Create a new invoice and add a line with an 8% tax. - Validate the invoice and export it as XML. - Upload the XML file as a vendor bill. - The vendor bill incorrectly shows two "8% taxes" instead of one. ## Solution: - The issue stems from a forward-port error from `saas-16.4` https://github.com/odoo/enterprise/commit/5681a8d5abee3a8787f3ee8612a8c3b18ed63ee6 to
Original PR description
## Issue: - Uploading a Mexican XML file with an 8% tax results in the addition of an extra 8% tax. ## Steps to reproduce: - Create a new invoice and add a line with an 8% tax. - Validate the invoice…
## Issue: - Uploading a Mexican XML file with an 8% tax results in the addition of an extra 8% tax. ## Steps to reproduce: - Create a new invoice and add a line with an 8% tax. - Validate the invoice and export it as XML. - Upload the XML file as a vendor bill. - The vendor bill incorrectly shows two "8% taxes" instead of one. ## Solution: - The issue stems from a forward-port error from `saas-16.4` https://github.com/odoo/enterprise/commit/5681a8d5abee3a8787f3ee8612a8c3b18ed63ee6 to `17.0` https://github.com/odoo/enterprise/commit/56a2b66d84d8398ea870d559cd55cfeae44019d8 - In `17.0` we introduced this Extract method `_l10n_mx_edi_import_cfdi_get_tax_from_node` to refactor the `_l10n_mx_edi_import_cfdi_fill_invoice_line`. - We should have add the Exento checks in the new method however we mistakenly pushed code from `saas-16.4` to `17.0` without adapting it. - I removed the extra code introduced during the forward-porting. - Refactored the related code to ensure compatibility with the new changes in `17.0`. OPW-4198016 Forward-Port-Of: odoo/enterprise#76209 Forward-Port-Of: odoo/enterprise#74602
### Steps to reproduce the issue: 1. Activate Mexican Localization 2. In Mexican Company, add USD as Currency and give it a Rate 3. Create a Sales Journal and a Pricelist with USD as main Currency 4. _Point of Sale > Configuration > Settings_: Select a Shop and set the USD Journal and Pricelist 5. Open a Session using the USD Shop and complete some Orders, without invoicing them 6. _Point of Sale > Orders > Orders_, select the created Orders and, in the Actions, Create Global Invoice 7.
Original PR description
### Steps to reproduce the issue: 1. Activate Mexican Localization 2. In Mexican Company, add USD as Currency and give it a Rate 3. Create a Sales Journal and a Pricelist with USD as main Currency 4.…
### Steps to reproduce the issue: 1. Activate Mexican Localization 2. In Mexican Company, add USD as Currency and give it a Rate 3. Create a Sales Journal and a Pricelist with USD as main Currency 4. _Point of Sale > Configuration > Settings_: Select a Shop and set the USD Journal and Pricelist 5. Open a Session using the USD Shop and complete some Orders, without invoicing them 6. _Point of Sale > Orders > Orders_, select the created Orders and, in the Actions, Create Global Invoice 7. The document should be accepted, but TipoCambio has a rate of 1.000000. ### Explanation: During the creation of the Global Invoice, the rate is retrieved during `pos.order._prepare_tax_base_line_values` and, since no value is given through POS, the default value is used. https://github.com/odoo/odoo/blob/8fb7e5fd304697aebcce085602a5f3a1ecaf757a/addons/account/models/account_tax.py#L1242 https://github.com/odoo/odoo/blob/8fb7e5fd304697aebcce085602a5f3a1ecaf757a/addons/account/models/account_tax.py#L1212-L1213 https://github.com/odoo/odoo/blob/8fb7e5fd304697aebcce085602a5f3a1ecaf757a/addons/account/models/account_tax.py#L1188-L1193 ### Fix reasoning: Adding test to make sure Foreign Currency can be used in Global Invoice for `pos.order` and rate is correctly set as well. Fix in Community opw-4302180 Forward-Port-Of: odoo/enterprise#75185