Wednesday, March 12, 2025
25 changes · saas-17.4
Resolved issues and error corrections
This fixes a duplicate field shown in the Spanish TicketBAI multi-refund accounting view. Users will see a cleaner form with the same information displayed only once, reducing confusion without changing business processes.
Original PR description
The module is added in https://github.com/odoo/odoo/pull/191303 as a backport to https://github.com/odoo/odoo/pull/166533 in `saas-17.3`. In `saas-17.4` this module adds similar functionality from `l10n_es_edi_tbai`. The view is modified to avoid displaying the [same field](https://github.com/odoo/odoo/blob/6140fa87601af7a75b6cf1bd93132ebc471f9181/addons/l10n_es_edi_tbai/views/account_move_view.xml#L16) twice. The module will be merged in the upgrade to `18.0`. upgrade https://github.com/odoo/upgrade/pull/7341 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an error that could appear when viewing a project's raw data while the project stage feature was disabled. The duration tracking information is now only calculated when project stages are enabled, preventing the crash and keeping the project data view accessible.
Original PR description
Before this commit, a traceback is occurred when the user would like to see the raw data of a specific project and the project stage feature is disabled. This commit adds a group on `duration_tracking` field definition to be sure this field will only be computed when the project stage feature is enabled. opw-3709542 Closes #197321
The Planning app now handles deleted recurring shift series correctly when the scheduled job creates future shifts. This prevents the background process from crashing after users delete all repeats from one recurring shift while other recurring shifts still need processing.
Original PR description
To reproduce: - create two repeating planning.slot records, Shift A and Shift B - delete Shift A and all of its repeats - delete only the last repeat of Shift B - run the "Planning: generate next recurring shifts" scheduled action - Cron fails with "record is missing or deleted" error Problem: The function to create the repeat shifts (planning.recurrency _repeat_slot) iterates over recurrences and deletes them if there are 0 existing shifts linked to them (i.e. Shift A's reccurency). On a subsequent loop iteration, an attempt is made to access the company_id field of the recordset (self) which will now contain a deleted planning.recurrency record, causing the missing record error. Solution: Access the company_id field on the current iterated planning.recurrency record instead of the 'self' recordset. opw-4457844
Miscellaneous changes
Live chat sessions are accessible to live chat managers so they should be able to join or invite anyone to said session. task-4637836 https://github.com/odoo/upgrade/pull/7372 Forward-Port-Of: odoo/odoo#201321
Original PR description
Live chat sessions are accessible to live chat managers so they should be able to join or invite anyone to said session. task-4637836 https://github.com/odoo/upgrade/pull/7372 Forward-Port-Of: odoo/odoo#201321
### Steps to reproduce * install `mass_mailing` * send an email with the "Training" template You will see that the "unsubscribe" link does not appear in the email that is sent opw-4615170 Forward-Port-Of: odoo/odoo#200342
Original PR description
### Steps to reproduce * install `mass_mailing` * send an email with the "Training" template You will see that the "unsubscribe" link does not appear in the email that is sent opw-4615170 Forward-Port-Of: odoo/odoo#200342
A [commit](https://github.com/odoo/odoo/pull/192524/commits/2694f9f9bfb8d3d92bd4618e041359150e1ba501) added a test that was failing when running it with demo data. It was due to a tax unnecessary for the test that was present with demo data. This commit ensures the test is run with no tax applied. opw-4389303 Forward-Port-Of: odoo/odoo#200893
Original PR description
A [commit](https://github.com/odoo/odoo/pull/192524/commits/2694f9f9bfb8d3d92bd4618e041359150e1ba501) added a test that was failing when running it with demo data. It was due to a tax unnecessary for the test that was present with demo data. This commit ensures the test is run with no tax applied. opw-4389303 Forward-Port-Of: odoo/odoo#200893
Have a many2many_tags field, in a form view for instance, with multiple tags. Focus its input, and then quickly press `Backspace` multiple times. Before this commit, there were 2 problems. First, if there was an onchange on that field, the onchange was triggered multiple times with the same forget command, especially on a slow-ish network. Second, there could be a crash, but to reproduce it the timing had to be precise: backspace should have been pressed when a previous tag deletion was al
Original PR description
Have a many2many_tags field, in a form view for instance, with multiple tags. Focus its input, and then quickly press `Backspace` multiple times. Before this commit, there were 2 problems. First, if…
Have a many2many_tags field, in a form view for instance, with multiple tags. Focus its input, and then quickly press `Backspace` multiple times. Before this commit, there were 2 problems. First, if there was an onchange on that field, the onchange was triggered multiple times with the same forget command, especially on a slow-ish network. Second, there could be a crash, but to reproduce it the timing had to be precise: backspace should have been pressed when a previous tag deletion was already processed by the model (i.e. the tag is no longer in the list), but the DOM wasn't updated yet. This could be done more easily then it sounds, by quickly pressing backspace on a many2many_tags with a lot of tags. The related opw is about the second issue, as the first one isn't obversable functionally. However, testing the second one is really tricky, even impossible without going white-box. We thus wrote a test for the first issue only, as the fix for both is actually the same. opw-4596936 Forward-Port-Of: odoo/odoo#201164
Feedbacks given talked about the fact the negative lines were wrong and should be considered as discounts. But that's not the case for every user and is more confusing than anything else. So we remove this logic from Italy. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199100
Original PR description
Feedbacks given talked about the fact the negative lines were wrong and should be considered as discounts. But that's not the case for every user and is more confusing than anything else. So we remove this logic from Italy. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199100
**Steps:** - Install Ecom - Add some products to the cart - Go to my/orders - select any order then click on Order again - Click on the Add To Cart button - You'll see one confirmation dialog, click on the close button of that dialog **Issue:** - By clicking on close dialog should get closed but instead, products are added in the cart **Cause:** - Default close method provided in the setup method of the confirmation dialog component **Fix:** - While extending the confirmation d
Original PR description
**Steps:** - Install Ecom - Add some products to the cart - Go to my/orders - select any order then click on Order again - Click on the Add To Cart button - You'll see one confirmation dialog, click on the close button of that dialog **Issue:** - By clicking on close dialog should get closed but instead, products are added in the cart **Cause:** - Default close method provided in the setup method of the confirmation dialog component **Fix:** - While extending the confirmation dialog we overwrite the default close method defined in Confirmation Dialog component affected version-16.0 opw-4566505 Forward-Port-Of: odoo/odoo#199837 Forward-Port-Of: odoo/odoo#199567
To reproduce: 1) install with any chart of accounts. 2) delete account with account_type equity_unaffected(Current Year Earnings). 3) add custom account with type equity_unaffected. 4) load chart of templates by bumping minor version with a local upgrade script. we should only have one account with equity_unaffected per company, otherwise we violate `_check_account_type_unique_current_year_earning` constraint. Description of the issue/feature this PR addresses: Current beh
Original PR description
To reproduce: 1) install with any chart of accounts. 2) delete account with account_type equity_unaffected(Current Year Earnings). 3) add custom account with type equity_unaffected. 4) load chart of templates by bumping minor version with a local upgrade script. we should only have one account with equity_unaffected per company, otherwise we violate `_check_account_type_unique_current_year_earning` constraint. 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#201073
The navigation buttons on the cart were repositioned on the screen for mobile view by setting position to absolute. However this causes an issue if a user adds blocks from the editor below the checkout screen, since disregards the height of the element. To fix this the height of the element is set on the placeholder element to which the navigation buttons are anchored. opw-4498660 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Por
Original PR description
The navigation buttons on the cart were repositioned on the screen for mobile view by setting position to absolute. However this causes an issue if a user adds blocks from the editor below the checkout screen, since disregards the height of the element. To fix this the height of the element is set on the placeholder element to which the navigation buttons are anchored. opw-4498660 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195305
This error occurs when user deletes the Picking Operations action. Steps to Reproduce : - Install the `Stock` module. - Navigate to Settings > Technical > Actions. - Search for `Picking Operations` in the list of actions. - Delete the `Picking Operations` action. - Go to Inventory > Operations and open any `Receipt`. - Click on the `Print` button. ValueError: External ID not found in the system: stock.action_report_picking This error occurs when the system attempts to access the
Original PR description
This error occurs when user deletes the Picking Operations action. Steps to Reproduce : - Install the `Stock` module. - Navigate to Settings > Technical > Actions. - Search for `Picking Operations` in the list of actions. - Delete the `Picking Operations` action. - Go to Inventory > Operations and open any `Receipt`. - Click on the `Print` button. ValueError: External ID not found in the system: stock.action_report_picking This error occurs when the system attempts to access the Picking Operations action, but it has been deleted. To resolve this issue, restrict the deletion of the `Picking Operations` report from the `ir actions`, to ensure that users cannot delete it (except during the module uninstallation), and also raise a user error for already existing DBs where `Picking Operations` has been deleted. Sentry - 6302556324 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198796
During the upgrade tests the test module will start with `odoo.upgrade` instead of `odoo.addons` Fixing the canonical tag to work in both cases. Forward-Port-Of: odoo/odoo#200942
Original PR description
During the upgrade tests the test module will start with `odoo.upgrade` instead of `odoo.addons` Fixing the canonical tag to work in both cases. Forward-Port-Of: odoo/odoo#200942
Add some logic to check the partner fields of models when formatting numbers based on a specific record. This is useful when we would otherwise have to fallback on the current company for formatting as it's generally a much better guess. task-4199766 Forward-Port-Of: odoo/odoo#195686
Original PR description
Add some logic to check the partner fields of models when formatting numbers based on a specific record. This is useful when we would otherwise have to fallback on the current company for formatting as it's generally a much better guess. task-4199766 Forward-Port-Of: odoo/odoo#195686
## Summary 1. `--test-tags ".test_js[mail > widgets]"` will start all test_js starting with "mail > widgets" 2. `--test-tags "/web,-.test_js[Components > CheckBox]"` will start all web test, but skip Components > CheckBox qunit 3. ` --test-tags ".test_js[utils,-utils > Hooks,-utils > Patch]"` start all test_js utils tests except the Hooks and Patch ones 4. `--test-tags "-.test_js[Components > CheckBox]"` will start **all** tests, but skip Components > CheckBox qunit Note: this was adapt
Original PR description
## Summary 1. `--test-tags ".test_js[mail > widgets]"` will start all test_js starting with "mail > widgets" 2. `--test-tags "/web,-.test_js[Components > CheckBox]"` will start all web test, but skip…
## Summary
1. `--test-tags ".test_js[mail > widgets]"` will start all test_js starting with "mail > widgets"
2. `--test-tags "/web,-.test_js[Components > CheckBox]"` will start all web test, but skip Components > CheckBox qunit
3. ` --test-tags ".test_js[utils,-utils > Hooks,-utils > Patch]"` start all test_js utils tests except the Hooks and Patch ones
4. `--test-tags "-.test_js[Components > CheckBox]"` will start **all** tests, but skip Components > CheckBox qunit
Note: this was adapted for hoot in 17.4,
`--test-tags ".test_unit_mobile[-@web/core/autocomplete/select option]"`
`--test-tags ".test_unit_mobile[@web/core,-@web/core/autocomplete]"`
## Motivation
Tags are used by runbot to *disable* randomly failing tests without the need to commit changes.
They can precisely target a python test method, class or module.
They can also be used by developer to run a *specific* test.
The problem is that the qunit is a special case, a js test suite inside the test_suite. It is only possible to disable all of them, or none of them.
Adding the possibility to enable/disable some of them was requested for a long time.
## Using test tags
The solution to use test-tags as multiple pros:
- avoid a new command line argument
- runbot already manages test-tags for errors meaning that this solution would imply minimal changes on this side
- passing arguments to a specific tests, without regard of the qunit needs looks like a decent solution. This is a generic solution that could lead to other posibilities (profiling, test mode, ...)
Test tags are not aware of the purpose of the parameters, they will only be passed to the test. The tests has the responsibility to parse them.
## Chosen syntax and behavior
The main need is to be enable/disable some qunit. This means that we may want to support having parameters using comma `,` Unfortunately this may conflict with comma used to split tags if the syntax is not well defined.
The main idea to solve this issue was that it would be intuitive to give parameters as a function call would, between parentheses.
The opening and closing of the parentheses would allow to identify if a comma is part of the parameters or a tag separator. But using parenthesis is not a good idea in a command line since it could be interpreted by the shell.
The chosen alternative was to use `[]` to have a opening and closing symbol. Depending on how the parameters are interpreted, it can also be quite intuitive to understand: we select a specific element.
`.test_js[mail,stock]`
to run only js tests concerning mail and stock.
The idea to disable some qunit would be to specify a negative filter as for tags:
`.test_js[-some_module]`
Multiple matching tags may be given, in this case all parameters are given to the test. This is why test_parameters are a list of strings.
`.test_js[-m1,-m2],.test_js[-m3]` will be given to the test as `['-m1,-m2', '-m3']`
## Splitting the tags
The idea to support nested [] in params was considered but this would complexify a lot the parsing
`.test_method[filters=[mail,crm],failfast=0]`
This is NOT supported even if it could be.
Parsing such tags would need a more complex parser (to split the , )
The final decision was made to keep it simple for now since it wouldn't be a problem to add this in the future if needed.
## Negating a parametric tag
A test tag can be negated to disable a test `-.test_js` (no op if test_js was not expected to run)
The question is, what is the expected behaviour of `-.test_js[mail]`.
### 1. Forbid this form
Simple solution, consider it as disabling a test, so passing the parameters would be usellesss and we should just don't allow that. But forbidding this form may force to make some complex development in runbot, since the current logic to disable a test is to add a '-' in front of the tag extected to run the test.
### 2. Transform it to negate the parameter
It could be as simple as transforming `-.test_js[mail]` to `.test_js[-(mail)]`, or to manage the case when we could have already negated arguments (and multiple ones), tansform it to `.test_js[-mail-]`
The only cons of this solution is that adding the tag -.test_js[mail] would actually enable the test_js even if it is not the case, and be more equivalent to `.test_js,.test_js[-mail]`
### 3. Consider them apart: negated but not including.
With this last solution, it is not possible to translate it as a tag, it would mean `.test_js[-mail]` if test_js is already enabled. This is whats looks to be the most robust solution. Adding a negated test-tag should not enable a test that wouldn't if not present
### 4. Always considered as parameters
`.test_js[mail]` would not enable test_js, but pass mail as parameter to test_js if another test enables it.
This means that to start the mail js test, we would use --test-tags .test_js,.test_js[mail]
This could make sence but would be less practical.
Since the main goal is to be able to disable a specific qunit from the runbot, 2, 3 and 4 could work in most cases
but 2 could be problematic in edge cases, and for odoosh were we may want to use autotags but only enable test from one module. /my_module,.test_js[-some_test] would enable the test_js.
3 and 4 are equivalent for negation, but the automatic generation of config wouldn't work with 4.
The current chosen solution is 3 since it looks to be the more practical.
Forward-Port-Of: odoo/odoo#200889
Forward-Port-Of: odoo/odoo#200413### Steps to reproduce the issue: (Easier to reproduce with demo data) 1. Create a Fixed Tax and assign it to a Product 2. Open POS session, add Product to Order 3. Add a Coupon Code: "10pc" - This code should give a 10% Discount on the Order 4. The Discount Line includes the Fixed Tax amount and accounts for more than 10% of the Order Total ### Explanation: During the creation of the reward line, the fixed taxes are not excluded from discounts. While it is logical for percen
Original PR description
### Steps to reproduce the issue:
(Easier to reproduce with demo data)
1. Create a Fixed Tax and assign it to a Product
2. Open POS session, add Product to Order
3. Add a Coupon Code: "10pc"
- This code should give a 10% Discount on the Order
4. The Discount Line includes the Fixed Tax amount and accounts for more than 10% of the Order Total
### Explanation:
During the creation of the reward line, the fixed taxes are not excluded from discounts. While it is logical for percentage taxes to be included, as they become part of the discount, fixed taxes are added to the amount.
### Fix reasoning:
The opposite issue was fixed in commit odoo/odoo@534de1e47ab882bfb1cc006bdf1fa00fc877c6c4, adapting the code to javascript.
opw-4506550
Forward-Port-Of: odoo/odoo#200684
Forward-Port-Of: odoo/odoo#200175Currently, in models with the analytic mixin, users are not able to filter records by analytic distribution. Steps to reproduce: - Enable analytic accounting - Create a Purchase order, having analytic distribution set on a line - In list view filter by [Add Custom Filter] for Order Lines > Analytic Distribution Issue: Mentioned filter cannot be found. It was removed in https://github.com/odoo/odoo/pull/195765 Now users have no way to filter records by analytic distribution. This com
Original PR description
Currently, in models with the analytic mixin, users are not able to filter records by analytic distribution. Steps to reproduce: - Enable analytic accounting - Create a Purchase order, having analytic distribution set on a line - In list view filter by [Add Custom Filter] for Order Lines > Analytic Distribution Issue: Mentioned filter cannot be found. It was removed in https://github.com/odoo/odoo/pull/195765 Now users have no way to filter records by analytic distribution. This commit backport the `distribution_analytic_account_ids` field introduced in 18.0 [1] in order to properly search analytic accounts [1] https://github.com/odoo/odoo/commit/381f201d49626bdd22c1f0b10d7050df0d264714 opw-4620169 Forward-Port-Of: odoo/odoo#200931
We call NotSupportedError with the keyword "new" in order to avoid this kind of errors in py_js: UncaughtPromiseError > TypeError Uncaught Promise > Class constructor NotSupportedError cannot be invoked without 'new' ... Forward-Port-Of: odoo/odoo#200971
Original PR description
We call NotSupportedError with the keyword "new" in order to avoid this kind of errors in py_js: UncaughtPromiseError > TypeError Uncaught Promise > Class constructor NotSupportedError cannot be invoked without 'new' ... Forward-Port-Of: odoo/odoo#200971
This reverts commit aef59e06d8d0ba388cd781fd9a9511d6ff74ea05. It was wrongly assumed that `_getRpcParameters` was useless in `s_dynamic_snippet_products`. It adds a parameter `productTemplateId` to the request to `/website/snippet/filters` which is used by `ir.actions.server`: - `dynamic_snippet_accessories_action`, - `dynamic_snippet_recently_sold_with_action`, - `dynamic_snippet_alternative_products`. Forward-Port-Of: odoo/odoo#201158
Original PR description
This reverts commit aef59e06d8d0ba388cd781fd9a9511d6ff74ea05. It was wrongly assumed that `_getRpcParameters` was useless in `s_dynamic_snippet_products`. It adds a parameter `productTemplateId` to the request to `/website/snippet/filters` which is used by `ir.actions.server`: - `dynamic_snippet_accessories_action`, - `dynamic_snippet_recently_sold_with_action`, - `dynamic_snippet_alternative_products`. Forward-Port-Of: odoo/odoo#201158
Steps to reproduce the issue: 1. Activate the Odoo Mexican Localization Reports module 2. In a Mexican company, create a new Account with 1 as code 3. Go to Trial Balance and download COA SAT (XML) 5. In the General Settings with developer mode active, Download XSD files 6. Go to Trial Balance and download COA SAT (XML) again 7. You get a UserError with an unclear message Explanation: The Mexican Chart of Accounts have clear rules regarding `account.account.code`. The only way to v
Original PR description
Steps to reproduce the issue: 1. Activate the Odoo Mexican Localization Reports module 2. In a Mexican company, create a new Account with 1 as code 3. Go to Trial Balance and download COA SAT (XML)…
Steps to reproduce the issue: 1. Activate the Odoo Mexican Localization Reports module 2. In a Mexican company, create a new Account with 1 as code 3. Go to Trial Balance and download COA SAT (XML) 5. In the General Settings with developer mode active, Download XSD files 6. Go to Trial Balance and download COA SAT (XML) again 7. You get a UserError with an unclear message Explanation: The Mexican Chart of Accounts have clear rules regarding `account.account.code`. The only way to verify those accounts is through the XSD files check, but they are not automatically downloaded and the error received with those files downloaded is not user friendly. Fix reasoning: Instead of regulating the code when downloading the XML. We'll add warnings on the Chart of Accounts to notify the user when a code is incorrect. To make the report error clearer to the user, we added a RedirectWarning that displays the accounts with faulty codes before generating the xml. opw-4287338 Forward-Port-Of: odoo/enterprise#80817 Forward-Port-Of: odoo/enterprise#73943
The current implementation of spreadsheet history does not support UNDO/REDO commands as those were never designed to be rollbacked in the first place (to rollback and UNDO, you cast a REDO). Furthermore, the datasources are not properly reloaded when navigating the history. When selecting a revision for which the domain or more generally the definition of datasource is altered, the latter is not reloaded and therefore the values displayed do not correspond to the definition in place. This
Original PR description
The current implementation of spreadsheet history does not support UNDO/REDO commands as those were never designed to be rollbacked in the first place (to rollback and UNDO, you cast a REDO). Furthermore, the datasources are not properly reloaded when navigating the history. When selecting a revision for which the domain or more generally the definition of datasource is altered, the latter is not reloaded and therefore the values displayed do not correspond to the definition in place. This revision changes the flow by simply re-instanciating a new `Model` every time we change the target revision. Task-4506832 Forward-Port-Of: odoo/enterprise#77667
We support sending credit transfers using ISO 20022 to accommodate non SEPA bank transfers (any party having no IBAN number). However when generating the XML file, we assumed that our company always had an IBAN number and put it in an IBAN node. For non IBAN numbers however we need to put it in another node. This commit fixes that. [opw-4585994](https://www.odoo.com/odoo/project.task/4585994) Forward-Port-Of: odoo/enterprise#80757
Original PR description
We support sending credit transfers using ISO 20022 to accommodate non SEPA bank transfers (any party having no IBAN number). However when generating the XML file, we assumed that our company always had an IBAN number and put it in an IBAN node. For non IBAN numbers however we need to put it in another node. This commit fixes that. [opw-4585994](https://www.odoo.com/odoo/project.task/4585994) Forward-Port-Of: odoo/enterprise#80757
Currently it's not possible for a public user to send themselves a message over whatsapp when the message contains information linked to a record This is because most records do not allow public users from reading them. This bypass is fairly safe as event whatsapp users can only select fields from `_get_whatsapp_safe_fields` which are considered safe to be rendered by SU in the first place. So you cannot simply create any template and render it as a public user. Additional: The phone f
Original PR description
Currently it's not possible for a public user to send themselves a message over whatsapp when the message contains information linked to a record This is because most records do not allow public users from reading them. This bypass is fairly safe as event whatsapp users can only select fields from `_get_whatsapp_safe_fields` which are considered safe to be rendered by SU in the first place. So you cannot simply create any template and render it as a public user. Additional: The phone formatter should be able to guess the country of a record based on the country of its partner task-4199766 Forward-Port-Of: odoo/enterprise#70608
### Steps to reproduce: - Create 3 products: Final product (FP), components COMP FP using the UOM category of Unit and COMP using Weigth for instance. - Create and confirm an MO for 1 unit of FP - Process the MO from the barcode app. - Click on "Add Component" select COMP as a product and set 1 unit - Confirm the additional move line #### > Invalid operation: "The unit of measure Unit defined on the order line doesn't belong to the same category as the unit of measure g defined on the pr
Original PR description
### Steps to reproduce: - Create 3 products: Final product (FP), components COMP FP using the UOM category of Unit and COMP using Weigth for instance. - Create and confirm an MO for 1 unit of FP -…
### Steps to reproduce: - Create 3 products: Final product (FP), components COMP FP using the UOM category of Unit and COMP using Weigth for instance. - Create and confirm an MO for 1 unit of FP - Process the MO from the barcode app. - Click on "Add Component" select COMP as a product and set 1 unit - Confirm the additional move line #### > Invalid operation: "The unit of measure Unit defined on the order line doesn't belong to the same category as the unit of measure g defined on the product. Please correct the unit of measure defined on the order line or on the product. They should belong to the same category." ### Cause of the issue: When processing an MO from the barcode app and adding a component the method `_getNewLineDefaultContext` will be called to set the default context of that new line before creation: https://github.com/odoo/enterprise/blob/83268aa3a5a7afdc8c09b0ac9bbee2b673fd25e9/stock_barcode_mrp/static/src/models/barcode_mrp_model.js#L367-L372 However, in this flow, `this.record` is an `mrp.production` and its `product_uom_id` is the product_uom_id of FP. In particular, the `default_product_uom_id` key will be used to alter the vals_list used in the create of our stock move line and an error will be raised since the unit category of COMP2 is Weight and is not compatible with the default product uom set by the context. opw-4527706 Forward-Port-Of: odoo/enterprise#79266
In case of having two lines with the same product, the cfdi field `ValorUnitarioAduana` is wrong, it is set as the total of the two lines. With this commit, we set it as the average of the lines. Steps (with demo data, company `ESCUELA ...`): - Partner "Azure Interior" -> change `Tax ID` from `US12345677` to `123456779` - Product `[E-COM06]` -> - `UNSPC Catgegory`: `01010101` - `Tariff Fraction`: `0101290200` - `UMT Aduana`: `Units` - Make an invoice: - Currency: USD - Two lines for pro
Original PR description
In case of having two lines with the same product, the cfdi field `ValorUnitarioAduana` is wrong, it is set as the total of the two lines. With this commit, we set it as the average of the lines. Steps (with demo data, company `ESCUELA ...`): - Partner "Azure Interior" -> change `Tax ID` from `US12345677` to `123456779` - Product `[E-COM06]` -> - `UNSPC Catgegory`: `01010101` - `Tariff Fraction`: `0101290200` - `UMT Aduana`: `Units` - Make an invoice: - Currency: USD - Two lines for product `[E-COM06]` - Incoterm: `[EXW] EX WORKS` - External Trade: `Definitive` - Confirm and sent to cfdi -> Error opw-4596628 Forward-Port-Of: odoo/enterprise#80660