Daily updates from Odoo
Friday, February 7, 2025
41 changes · master
Enhancements to existing features
Test coverage across several Odoo Enterprise apps was updated to match a change in how scheduled jobs are run directly. This keeps automated validation reliable and helps prevent regressions without changing day-to-day user workflows.
Original PR description
We need to adapt the calls to `method_direct_trigger` in tests. The method creates a new cursor now, so we need to be in test mode. task-4433571 odoo/odoo#193740
Users now see a clear message when they try to validate or download documents that have not been fully signed. This avoids confusing redirects and helps users understand what action is still needed before completing the signing process.
Original PR description
Before this commit, if a document wasn't fully signed, the system redirected to a new page and triggered a UserError, but the user couldn't see the error message. With this commit, the validation is improved to properly show a clear error message when documents are not fully signed, ensuring the user is informed. task-4268726
Subscription reminders now skip contracts that are not yet close enough to needing action. This reduces daily background processing for subscriptions where no reminder or closure is needed, improving efficiency without changing customer-facing behavior.
Original PR description
Before this commit, once the next_invoice_date was passed, the cron would process it everyday even if no reminder was necessary and the sub should not be closed. This commit ensure no contract is processed too soon. We decided to look for the minimal auto_close_limit value available and no contract is processed while his next_invoice_date + min_auto_close_limit is still in the future. This should reduce the amount of contract processed for "nothing". Once the auto_close_limit is passed, the contracts are still processed as they could be automatically closed before the 14 days delay is passed. task: 4295613
Belgian CODA bank statement imports now place note information directly in the transaction details. This makes payment information easier to review and helps users reconcile bank transactions with clearer context.
Original PR description
In this commit we will move the information that is placed in the note field in transaction details. task-4496857
This change updates an internal automated test to reflect recent behavior where related scheduled messages are removed when a record is deleted. It helps keep the document accounting test suite accurate and reduces false test failures, with no direct impact on end users.
Original PR description
Purpose: -------- In [this commit](https://github.com/odoo/odoo/commit/f9161cb), the messages scheduled on a record are now unlinked when unlinking this record (for models that inherit from `mail.thread`). This commit increases the query count in the test_move_document_unlink test accordingly. Task-4531402 [1]: https://github.com/odoo/odoo/commit/f9161cb7c132e97d78edef4a2a785f2bc3170b80
The restaurant preparation display setup now gives new point-of-sale users a clearer first step: they can load sample data or create their first product. This makes it easier for businesses to start using the POS restaurant workflow without needing technical guidance.
Original PR description
This commit improves the POS onboarding experience by giving users the option to either load sample data or create a new product for their first POS. Community PR: https://github.com/odoo/odoo/pull/192156 task-4430950
Payment status messages shown to customers on portal documents are now configured by payment method instead of payment provider. This makes messages more relevant for cases like bank transfers or asynchronous payment options and reduces the need to create separate providers just to show different instructions.
Original PR description
The job of transaction state messages is to show a message on top of paid documents on the portal. For example, if a confirmed transaction is linked to a sales order, the following message is shown…
The job of transaction state messages is to show a message on top of paid documents on the portal. For example, if a confirmed transaction is linked to a sales order, the following message is shown at the top of the page: "Your payment has been successfully processed, thank you!". Currently, these messages are configurable per provider, but it's unlikely that one will want Stripe to display something different than Adyen for a given transaction state. However, we definitively want to display a different message depending on the transaction's payment method. For example, wire transfer payments use the `pending_msg` field to display the payment instructions; payment methods like Karna are asynchronous by design, and we'll want to display the appropriate message regardless of the provider used to process the payment; etc. This will also allow modules like `payment_custom` to work with a single provider and multiple payment methods rather than multiple providers and one payment method each. task-2941756
New automated tests verify that planning slot templates are visible only to the right types of users. This helps ensure project users, managers, portal users, and public users get the correct level of access and reduces the risk of unintended shift visibility.
Original PR description
This commit adds test cases to validate planning slot template visibility
based on user roles and project access:
1) Project user:
- Project user can access only specific planning slot template
2) Project manager:
Can access all planning slot templates
Moved in the planning module
3) Public and portal users:
Cannot access any shifts.
task: 4480509The Sign app now has clearer labels, cleaner messages, and improved Terms & Conditions controls. Users can more easily edit or preview website terms pages and find archived templates when they need to restore them.
Original PR description
In this PR we did following changes: - Fixed typo in "Sign" button label. - Updated Terms & Conditions configuration: - Disabled in-place preview for "web page" configurations; introduced an - "Update Webpage" link for front-end editing and a separate "Preview" option. - Added filter to unarchive templates in the template menu list view. - Removed redundant exclamation mark in UI for a more polished finish. task-4231215
This update removes an obsolete styling reference from the Helpdesk portal templates. It has no expected impact on user workflows, but keeps the codebase cleaner and easier to maintain.
Original PR description
The SCSS for the `o_portal_contact_img` class was removed in a previous commit. As this class is no longer being used, it is safe to remove it from the codebase. Reff Commit- https://github.com/odoo/odoo/commit/df8535fbd40e1e5c09dbe616a3332c76c23525c8 task-3970088
Resolved issues and error corrections
This fix removes leftover references to a previously removed mobile field in several business workflows. It helps prevent errors or inconsistencies when using delivery integrations and Belgian reporting features after the earlier cleanup.
Original PR description
Missed few places during removal of mobile field See - https://github.com/odoo/enterprise/pull/75203 Task-4555229
Companies can now view and update the rental location used for rental order replenishment. This prevents users from being blocked after a rental location is deleted, and also restores missing rental locations automatically during setup.
Original PR description
### Problem Before this commit, if the customer deletes the rental location they would be blocked from creating a rental order as it is necessary for replenishment rules. The issue becomes critical because, once deleted, the rental location cannot be set to the company functionally given the field is not present in the view. ### Solution To fix this, this commit adds `Rental Settings` making the `rental_loc_id` field visible in the `res_company` view, allowing customers to select their desired rental location and resolve the issue independently. Additionally, we call `create_missing_rental_location()` in the `post_init_hook` to ensure that the field is correctly set for all companies.  - opw-3973957 - opw-4488182 - opw-4545985
The appraisal module’s sample scenario data was updated to match a recent change in how employees are linked to appraisal goals. This prevents setup or automated validation errors and helps ensure appraisal demo data loads correctly.
Original PR description
The commit https://github.com/odoo/enterprise/commit/dd90f66a536539 Changed the `employee_id` field to Many2Many but the change was not reflected in `hr_appraisal_scenario` data. This commit changes the data file to match the new field. Runbot Error: https://runbot.odoo.com/odoo/action-573/115164
This update fixes how units of measure are handled when orders are created from replenishment and improves how conversion ratios are shown against a product's base unit. This helps users avoid quantity mistakes and better understand unit conversions in purchasing approval and quality control flows.
Code cleanup and technical improvements
The way campaign activities are ordered in the marketing automation form has been simplified without changing the intended display behavior. This makes the underlying logic easier to maintain and adapt in future updates, reducing long-term maintenance risk.
Original PR description
The marketing campaign form view displays child activities sorted topologically, based on ancestry. However, the current implementation of the sorting algorithm is recursive, rendering it unclear and hard to read. This commit implements an easier-to-read sorting algorithm, which should be easier to port to new framework versions. task-3390523
This draft consolidates employee-related work order accounting into the manufacturing accounting area and removes unused work order code. It should make manufacturing cost reporting and valuation logic easier to maintain, with supporting test updates to protect existing behavior.
Miscellaneous changes
Currently the caret build with cutom groupby map could not work as there was a typo made during this commit: https://github.com/odoo/enterprise/commit/f8f7196030c257e3343b0725b5a0b3779d57c8ac task-4555964 Forward-Port-Of: odoo/enterprise#78725
Original PR description
Currently the caret build with cutom groupby map could not work as there was a typo made during this commit: https://github.com/odoo/enterprise/commit/f8f7196030c257e3343b0725b5a0b3779d57c8ac task-4555964 Forward-Port-Of: odoo/enterprise#78725
When updating the module, the bank data is reloaded. When the account is already trusted (`allow_out_payment == True`), the write fails due to checks to prevent fraud. To fix this, we wrap the data in a `noupdate` to prevent further writes from happening. If ever the account number changes, a new record will be created instead of updating the existing one. Since this account is the default one stipulated on the official fps site, it can be trusted by default. Issue reported by upgrade team
Original PR description
When updating the module, the bank data is reloaded. When the account is already trusted (`allow_out_payment == True`), the write fails due to checks to prevent fraud. To fix this, we wrap the data in a `noupdate` to prevent further writes from happening. If ever the account number changes, a new record will be created instead of updating the existing one. Since this account is the default one stipulated on the official fps site, it can be trusted by default. Issue reported by upgrade team. Forward-Port-Of: odoo/enterprise#78760
## Description Following odoo/enterprise@c9ceba2cf5982c244fe1ad3054d1463d9eca0e8c, the set of suitable_partners used to determine which products can be associated with a ticket is based on the `commercial_partner_id` of `self`. This works well for form views, where `self` is a singleton. However, since the field `product_id` is present in the list view, which has a domain depending on `suitable_product_ids`, the computation is triggered for all tickets in the list view, making `self` not a sing
Original PR description
## Description Following odoo/enterprise@c9ceba2cf5982c244fe1ad3054d1463d9eca0e8c, the set of suitable_partners used to determine which products can be associated with a ticket is based on the…
## Description Following odoo/enterprise@c9ceba2cf5982c244fe1ad3054d1463d9eca0e8c, the set of suitable_partners used to determine which products can be associated with a ticket is based on the `commercial_partner_id` of `self`. This works well for form views, where `self` is a singleton. However, since the field `product_id` is present in the list view, which has a domain depending on `suitable_product_ids`, the computation is triggered for all tickets in the list view, making `self` not a singleton. This causes the set of suitable partners to be larger than necessary, as it becomes the collective set for *all* tickets referenced in `self`, leading to false positives where products associated with a specific partner's sales/delivery history might appear suitable for another ticket with a different partner. To address this, we split `self` by `commercial_partner`, as the set of products that could be suitable depends on the partner's sales/delivery history, not on individual tickets. ## Reference opw-4444078 Forward-Port-Of: odoo/enterprise#78765 Forward-Port-Of: odoo/enterprise#78087
*: l10n_cl_edi_pos, l10n_de_pos_res_cert, pos_preparation_display, l10n_it_pos, pos_restaurant_preparation_display, pos_settle_due Reduce number of XHR request by handling preparation change notification directly in the backend. The synchronisation is now more robust, each time we receive a request all local ids are checked to ensure that the record wasn't deleted or modified in the meantime. Forward-Port-Of: odoo/enterprise#77915 Forward-Port-Of: odoo/enterprise#77812
Original PR description
*: l10n_cl_edi_pos, l10n_de_pos_res_cert, pos_preparation_display, l10n_it_pos, pos_restaurant_preparation_display, pos_settle_due Reduce number of XHR request by handling preparation change notification directly in the backend. The synchronisation is now more robust, each time we receive a request all local ids are checked to ensure that the record wasn't deleted or modified in the meantime. Forward-Port-Of: odoo/enterprise#77915 Forward-Port-Of: odoo/enterprise#77812
### Before this commit: Clicking on a budgetary position opened the list view showing all budget lines, regardless of the selected budgetary position. ### After this commit: Now, clicking on a budgetary position will open the list view filtered to show only the budget lines associated with that specific budgetary position. ### Technical: In `doActionButton`, we use the `args` if the action type is object. so, `domain` is irrelevant in this context. **task-4195738** Forward-Port-Of:
Original PR description
### Before this commit: Clicking on a budgetary position opened the list view showing all budget lines, regardless of the selected budgetary position. ### After this commit: Now, clicking on a budgetary position will open the list view filtered to show only the budget lines associated with that specific budgetary position. ### Technical: In `doActionButton`, we use the `args` if the action type is object. so, `domain` is irrelevant in this context. **task-4195738** Forward-Port-Of: odoo/enterprise#78708 Forward-Port-Of: odoo/enterprise#73785
This new module should replace the existing implementation for USPS integration which uses XML which is not the recommended API currently by USPS. The new integration uses USPS's latest RESTful APIs: https://developer.usps.com/apis. Task-3759325 Forward-Port-Of: odoo/enterprise#78712 Forward-Port-Of: odoo/enterprise#73906
Original PR description
This new module should replace the existing implementation for USPS integration which uses XML which is not the recommended API currently by USPS. The new integration uses USPS's latest RESTful APIs: https://developer.usps.com/apis. Task-3759325 Forward-Port-Of: odoo/enterprise#78712 Forward-Port-Of: odoo/enterprise#73906
**Current behavior:** When a user wants to upload its VAT return to the French Government, they receive the following error message: ``` report_line_code = report_lines_code_per_id[report_line_id] ~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^ KeyError: None ``` **Expected behavior:** The user should be able to upload their VAT return without any error message. **Steps to reproduce:** 1. Create a French company, using French Accounting. (`l10n_fr_reports`, `l10n
Original PR description
**Current behavior:** When a user wants to upload its VAT return to the French Government, they receive the following error message: ``` report_line_code = report_lines_code_per_id[report_line_id]…
**Current behavior:**
When a user wants to upload its VAT return to the French Government, they receive the following error message:
```
report_line_code = report_lines_code_per_id[report_line_id]
~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^
KeyError: None
```
**Expected behavior:**
The user should be able to upload their VAT return without any error message.
**Steps to reproduce:**
1. Create a French company, using French Accounting. (`l10n_fr_reports`, `l10n_fr_account`).
2. In the Settings, activate the Analytics option "Add totals below sections".
3. Go to Tax reports > Actions > EDI TVA > Send Report
**Cause of the issue:**
When the "Add totals below sections" parameter is enabled, the system will add new total lines on the report for each group of report lines. In the case of the Standard French VAT report, a single total line is added.
The issue is that before sending the report, the values are formatted by `_get_formatted_edi_values`. Each line to format is mapped to its corresponding line ID in line [255](https://github.com/odoo/enterprise/blob/0c32410b50b0edc2bc68c3199f741756b49600a2/l10n_fr_reports/wizard/l10n_fr_send_vat_report.py#L255): `report_line_id = self.report_id._get_model_info_from_id(line['id'])[-1]` Alas, for the new total lines, the line ID and its corresponding model are both None, which leads to an error on the next line. In version 17.0, there was a check for the model of the line, which was removed in version 18.0.
**Fix:**
- Add a check on the model of the line before formatting its values, to prevent the total lines from being formatted and sent.
opw-4496692
Forward-Port-Of: odoo/enterprise#77964Steps to Reproduce: 1. Enable the Rental Transfers option in Configuration > Settings. 2. Create a rental order with one rental product and one sales product. 3. Confirm the order. 4. Validate the delivery order. Issue: - The delivered quantity is updated for the rental product but not for the sales product. Cause: - This behavior arises because the assign_picking method reuses an existing picking_id if the domain matches, updating subsequent moves' location_dest_id to match
Original PR description
Steps to Reproduce: 1. Enable the Rental Transfers option in Configuration > Settings. 2. Create a rental order with one rental product and one sales product. 3. Confirm the order. 4. Validate the delivery order. Issue: - The delivered quantity is updated for the rental product but not for the sales product. Cause: - This behavior arises because the assign_picking method reuses an existing picking_id if the domain matches, updating subsequent moves' location_dest_id to match the reused picking. Fix: - Override _compute_location_dest_id and update the location_dest_id if conditions are fulfilled. opw-4298443 Forward-Port-Of: odoo/enterprise#78729 Forward-Port-Of: odoo/enterprise#73895
Currently, an exception is generated while connecting to the bank. Error:- ``` TypeError: AccountOnlineLink.create_new_bank_account_action() missing 1 required positional argument: 'journal_type' ``` This is because of the latest changes were added from the below commit. https://github.com/odoo/enterprise/pull/70591/files#diff-72ccf5e061185b2d649fb844db777d7e229c31c38e1dc68283984a0772b481bfR384 A new argument `journal_type` was added in the `create_new_bank_account_action` method.
Original PR description
Currently, an exception is generated while connecting to the bank. Error:- ``` TypeError: AccountOnlineLink.create_new_bank_account_action() missing 1 required positional argument: 'journal_type' ``` This is because of the latest changes were added from the below commit. https://github.com/odoo/enterprise/pull/70591/files#diff-72ccf5e061185b2d649fb844db777d7e229c31c38e1dc68283984a0772b481bfR384 A new argument `journal_type` was added in the `create_new_bank_account_action` method. But forget pass that required argument in the ORM call in below lines. https://github.com/odoo/enterprise/blob/b588877a12f4952d02c747b230065c5b52f21e1a/account_online_synchronization/static/src/components/bank_configure/bank_configure.js#L68-L72 This leads to the above traceback. sentry-6248235685 Forward-Port-Of: odoo/enterprise#78587
The new module introduces these 2 reports: 1. VAT control statement (with its XML export). Documentation: https://adisspr.mfcr.cz/dpr/adis/idpr_pub/epo2_info/popis_struktury_detail.faces?zkratka=DPHKH1 2. VIES report (with its XML export). Documentation: https://adisspr.mfcr.cz/dpr/adis/idpr_pub/epo2_info/popis_struktury_detail.faces?zkratka=DPHSHV The new module also has the tax report XML export logic. The logic was moved here because the new field of tax office was needed in tax repor
Original PR description
The new module introduces these 2 reports: 1. VAT control statement (with its XML export). Documentation: https://adisspr.mfcr.cz/dpr/adis/idpr_pub/epo2_info/popis_struktury_detail.faces?zkratka=DPHKH1 2. VIES report (with its XML export). Documentation: https://adisspr.mfcr.cz/dpr/adis/idpr_pub/epo2_info/popis_struktury_detail.faces?zkratka=DPHSHV The new module also has the tax report XML export logic. The logic was moved here because the new field of tax office was needed in tax reports XML export. Documenation: https://adisspr.mfcr.cz/dpr/adis/idpr_pub/epo2_info/popis_struktury_detail.faces?zkratka=DPHDP3 task-3698642 task-3762956 task-4087283 Forward-Port-Of: odoo/enterprise#78622 Forward-Port-Of: odoo/enterprise#56896
Issue ===== The view is not inserted into the article, or the view link results in a traceback error. Steps ====== 1. Create a custom menu with its configuration using the model (Create a Menu). 2. Navigate to the custom menu action via the parent menu's route. 3. Use the actions to navigate to Knowledge > Insert view/link in article, then select an article (either existing or new). Technical ========= Due to a recent change introduced in this [commit](https://github.com/odoo/enter
Original PR description
Issue ===== The view is not inserted into the article, or the view link results in a traceback error. Steps ====== 1. Create a custom menu with its configuration using the model (Create a Menu). 2. Navigate to the custom menu action via the parent menu's route. 3. Use the actions to navigate to Knowledge > Insert view/link in article, then select an article (either existing or new). Technical ========= Due to a recent change introduced in this [commit](https://github.com/odoo/enterprise/commit/30c71b1fee8c91df5342b2b1ef5f6e888e84571d) the issue arises from the function 'this.actionService.loadAction' requiring either an actionxmlid or actWindow to process the action. Previously, only the actionxmlid was available, which caused the problem. The provided fix resolves this issue by ensuring both identifiers are correctly handled. Task-4437944 Forward-Port-Of: odoo/enterprise#76918
There might be little value in re-creating a template that a user has deleted. This can also trigger the model constraint, specially in smaller databases with only one Whatsapp account and one language installed when a standard template is deleted and a new one with the same name is created. To reproduce: - Install `whatsapp_account` - Delete the `Invoice` template - Create a Whatsapp account - Create a new template, call it `Invoice` and link to the account. - Upgrade the module T
Original PR description
There might be little value in re-creating a template that a user has deleted. This can also trigger the model constraint, specially in smaller databases with only one Whatsapp account and one language installed when a standard template is deleted and a new one with the same name is created. To reproduce: - Install `whatsapp_account` - Delete the `Invoice` template - Create a Whatsapp account - Create a new template, call it `Invoice` and link to the account. - Upgrade the module This will trigger the constraint: ``` psycopg2.errors.UniqueViolation: duplicate key value violates unique constraint "whatsapp_template_unique_name_account_template" DETAIL: Key (template_name, lang_code, wa_account_id)=(invoice, en, 1) already exists. ``` Forward-Port-Of: odoo/enterprise#78501
This PR aims to prevent showing outdated error messages on an uruguayan electronic invoice that has already been amended. When a user creates a CFE invoice with invalid information (for example, the unit price of the product detailed in the invoice is equal to 0.0), the webservice returns an error that is captured on Odoo and shown as a pop-up and added as a banner on the move header. If the user resets the move to draft, corrects the error and for some reason introduces another one (like lea
Original PR description
This PR aims to prevent showing outdated error messages on an uruguayan electronic invoice that has already been amended. When a user creates a CFE invoice with invalid information (for example, the…
This PR aims to prevent showing outdated error messages on an uruguayan electronic invoice that has already been amended. When a user creates a CFE invoice with invalid information (for example, the unit price of the product detailed in the invoice is equal to 0.0), the webservice returns an error that is captured on Odoo and shown as a pop-up and added as a banner on the move header. If the user resets the move to draft, corrects the error and for some reason introduces another one (like leaving the "tax" column empty), then confirm and send the invoice again to DGI, a new pop up is raised showing a new error message accordingly but the banner of the header remains showing the same error as before (saying the product unit price is 0). This leads to confusion about what is the current error to be amended to properly send the invoice to DGI. Steps to reproduce the error: - Create an uruguayan electronic invoice on a testing enviroment. - Select a product and change its unit price to 0. - Try to send & print the invoice, creating the CFE. - An error like this will be shown:  - Go back to the move and check that a banner with the error has been added at the top.  - Reset to draft, add a valid unit price and delete the "Taxes" column value. - Confirm, Send&Print the invoice. - A new pop up like this should raise:  - Go back to the invoice and check that the banner remains as before, showing an outdated error message. Forward-Port-Of: odoo/enterprise#77710
During the upgrade to the "new" headless mode of Chrome (default for v128+), an issue with the tours "hr_contract_salary_tour" and "hr_contract_salary_tour_2" was detected. In a nutshell, in those tours, during the signing of the contract, the "street" field wasn't pre-filled and leaving it empty. The step-by-step filling system (e.g. the "Next" button on the left) was confused and put the date in the street field (sic). For some reason, the "old" Chrome headless mode - while encountering the
Original PR description
During the upgrade to the "new" headless mode of Chrome (default for v128+), an issue with the tours "hr_contract_salary_tour" and "hr_contract_salary_tour_2" was detected. In a nutshell, in those…
During the upgrade to the "new" headless mode of Chrome (default for v128+), an issue with the tours "hr_contract_salary_tour" and "hr_contract_salary_tour_2" was detected. In a nutshell, in those tours, during the signing of the contract, the "street" field wasn't pre-filled and leaving it empty. The step-by-step filling system (e.g. the "Next" button on the left) was confused and put the date in the street field (sic). For some reason, the "old" Chrome headless mode - while encountering the same issue - didn't complained with it... But the "new" mode (which is actually closer to the actual GUI behavior of Chrome) got stuck at those steps. This commit fixes this issue by using the `private_street` field (which contains the actual street name) instead of the `private_street2` field (which is often empty). Once done, a second issue was detected as the step filling the computation of "58/4" didn't match (even wrongly) any empty field anymore. This commit simply removes those unused steps. Forward-Port-Of: odoo/enterprise#78626 Forward-Port-Of: odoo/enterprise#78397
Users with the ability to see the button 'Report in next payslip' should be able to use it even if they don't have Payroll access rights. task-4481091 Forward-Port-Of: odoo/enterprise#77193
Original PR description
Users with the ability to see the button 'Report in next payslip' should be able to use it even if they don't have Payroll access rights. task-4481091 Forward-Port-Of: odoo/enterprise#77193
Description of the issue/feature this PR addresses: This PR prevents creating a CFE XML document with a "-" in the field "NomItem" when the product name is not found but it has a label. Current behavior before PR: If an electronic invoice is sent to DGI with a line without product id but with a label, the field "NomItem" in the XML file created is filled with "-". Desired behavior after PR is merged: If an electronic invoice is sent to DGI with a line without product id but with a lab
Original PR description
Description of the issue/feature this PR addresses: This PR prevents creating a CFE XML document with a "-" in the field "NomItem" when the product name is not found but it has a label. Current…
Description of the issue/feature this PR addresses:
This PR prevents creating a CFE XML document with a "-" in the field "NomItem" when the product name is not found but it has a label.
Current behavior before PR:
If an electronic invoice is sent to DGI with a line without product id but with a label, the field "NomItem" in the XML file created is filled with "-".
Desired behavior after PR is merged:
If an electronic invoice is sent to DGI with a line without product id but with a label, the field "NomItem" in the XML file created is filled with the product description.
Steps to reproduce the issue:
- Create an electronic invoice on an uruguayan company.
- Add a line without a product and add a label, a unit price, quantity and tax.
- Confirm the invoice and create CFE.
- Check that the field "NomItem" is field with a "-" instead of the product label like this:
```
<Item>
<NroLinDet>4</NroLinDet>
<IndFact>2</IndFact>
<NomItem>-</NomItem>
<DscItem>PRODUCT X</DscItem>
<Cantidad>1.000</Cantidad>
<UniMed>N/A</UniMed>
<PrecioUnitario>20.000000</PrecioUnitario>
<MontoItem>20.00</MontoItem>
</Item>
```
Forward-Port-Of: odoo/enterprise#78551Subscriptions with multiple lines and tax-included prices introduced a rounding error in some cases. This commit fixes the _compute_recurring_total method by using the same rounding method as _compute_amounts in the sale/ module, based on AccountTax helper methods. opw-[4460812](https://www.odoo.com/odoo/all-tasks/4460812) Forward-Port-Of: odoo/enterprise#78318 Forward-Port-Of: odoo/enterprise#76686
Original PR description
Subscriptions with multiple lines and tax-included prices introduced a rounding error in some cases. This commit fixes the _compute_recurring_total method by using the same rounding method as _compute_amounts in the sale/ module, based on AccountTax helper methods. opw-[4460812](https://www.odoo.com/odoo/all-tasks/4460812) Forward-Port-Of: odoo/enterprise#78318 Forward-Port-Of: odoo/enterprise#76686
This commit avoids calling the toggle cron function with journal_ids recordset after an online account has been unlinked. Previously, this caused an error because the record was already deleted. The journal_ids model is now retrieved from the environment instead of the potentially stale recordset. The bug was introduced by this commit [[1]]. no task id [1]: https://github.com/odoo/enterprise/commit/bc3b9136d4d62fbc1d09267f73cac7ca29f1ba3a Forward-Port-Of: odoo/enterprise#78680
Original PR description
This commit avoids calling the toggle cron function with journal_ids recordset after an online account has been unlinked. Previously, this caused an error because the record was already deleted. The journal_ids model is now retrieved from the environment instead of the potentially stale recordset. The bug was introduced by this commit [[1]]. no task id [1]: https://github.com/odoo/enterprise/commit/bc3b9136d4d62fbc1d09267f73cac7ca29f1ba3a Forward-Port-Of: odoo/enterprise#78680
Fix runbot error: 113710 Forward-Port-Of: odoo/enterprise#78619 Forward-Port-Of: odoo/enterprise#78543
Original PR description
Fix runbot error: 113710 Forward-Port-Of: odoo/enterprise#78619 Forward-Port-Of: odoo/enterprise#78543
The mapping that is currently used can lead to a constraint on accout types being triggered, blocking the import procedure. This commit aims at fixing this by removing the account code range for the recievable and payable types. From now on, these will only be applied when the corresponding 'CENTRALID' matches respectively 'S' for payables and 'C' for receivable. task-4465663 Forward-Port-Of: odoo/enterprise#78700 Forward-Port-Of: odoo/enterprise#77103
Original PR description
The mapping that is currently used can lead to a constraint on accout types being triggered, blocking the import procedure. This commit aims at fixing this by removing the account code range for the recievable and payable types. From now on, these will only be applied when the corresponding 'CENTRALID' matches respectively 'S' for payables and 'C' for receivable. task-4465663 Forward-Port-Of: odoo/enterprise#78700 Forward-Port-Of: odoo/enterprise#77103
Prior to this commit, undoing auto plan results in having the shifts remaining in the searchBar, and therefore still highlighted. This commit aims to reset the selection and the highlight after undo auto plan. To reproduce the bug: 1. In planning, clcik auto plan and then undo. 2. Auto planned shifts which are now in unassigned are still highlighted and the search bar contains these shifts. task: 3999600 Forward-Port-Of: odoo/enterprise#73821
Original PR description
Prior to this commit, undoing auto plan results in having the shifts remaining in the searchBar, and therefore still highlighted. This commit aims to reset the selection and the highlight after undo auto plan. To reproduce the bug: 1. In planning, clcik auto plan and then undo. 2. Auto planned shifts which are now in unassigned are still highlighted and the search bar contains these shifts. task: 3999600 Forward-Port-Of: odoo/enterprise#73821
**Steps to Reproduce:** 1. Open a sign template. 2. Open a PDF. 3. Copy and paste a sign item. **Issue:** An error occurs when pasting a sign item. **Cause:** The saveChanges function was replaced with setTemplateChanged to manage the template's state, but the old function was still being referenced. **Solution:** Replace saveChanges with setTemplateChanged to ensure proper state management. task-4531219 Forward-Port-Of: odoo/enterprise#78258
Original PR description
**Steps to Reproduce:** 1. Open a sign template. 2. Open a PDF. 3. Copy and paste a sign item. **Issue:** An error occurs when pasting a sign item. **Cause:** The saveChanges function was replaced with setTemplateChanged to manage the template's state, but the old function was still being referenced. **Solution:** Replace saveChanges with setTemplateChanged to ensure proper state management. task-4531219 Forward-Port-Of: odoo/enterprise#78258
We uncomment the subtotals because there was an error about withhold subtotals dict. Now the error has been resolved related: https://github.com/odoo/enterprise/pull/76330 Forward-Port-Of: odoo/enterprise#77592
Original PR description
We uncomment the subtotals because there was an error about withhold subtotals dict. Now the error has been resolved related: https://github.com/odoo/enterprise/pull/76330 Forward-Port-Of: odoo/enterprise#77592
This PR aims to fix an error on PDF reports on UY invoices, that occurs when copy-pasting the addenda text from an editor in Odoo. It happens that sometimes the text has hidden characters inside and those are printed as ? in the pdf. Steps to reproduce: 1) Install l10n_uy_edi 2) Create or duplicate an e-invoice 3) Copy-paste the following text in the "Terms and conditions" section: Estimated Net Weight: 84.000,00 Kg Estimated Gross Weight: 84.240,00 BL Nº: HLCUPN4240969947
Original PR description
This PR aims to fix an error on PDF reports on UY invoices, that occurs when copy-pasting the addenda text from an editor in Odoo. It happens that sometimes the text has hidden characters inside and those are printed as ? in the pdf. Steps to reproduce: 1) Install l10n_uy_edi 2) Create or duplicate an e-invoice 3) Copy-paste the following text in the "Terms and conditions" section: Estimated Net Weight: 84.000,00 Kg Estimated Gross Weight: 84.240,00 BL Nº: HLCUPN4240969947 BANK DETAILS: TEST12344 4) Confirm, print and send the invoice. 5) Check the pdf is created like this:  Expected behavior after this PR: The text on the "Adenda" section of the pdf should not print hidden characters. Forward-Port-Of: odoo/enterprise#76972
During odoo/enterprise@ca5a67c4faaf refactoring, the data file with default ICP for timesheet rounding/min duration was renamed but got removed from the manifest. This commit re-add it into the manifest. Forward-Port-Of: odoo/enterprise#77682
Original PR description
During odoo/enterprise@ca5a67c4faaf refactoring, the data file with default ICP for timesheet rounding/min duration was renamed but got removed from the manifest. This commit re-add it into the manifest. Forward-Port-Of: odoo/enterprise#77682