Thursday, August 15, 2024
29 changes
8 changes
Resolved issues and error corrections
This change prevents upgrades from incorrectly reassigning the short Spanish URL code when a regional Spanish language is already using it. It helps avoid upgrade errors for databases that enabled Spanish variants such as Argentina Spanish before moving to newer versions.
Original PR description
Steps to reproduce [`17.2`]: - Start a fresh DB. - Enable one of the Spanish sub-languages except the `Spanish LATAM` (the one with default `/es` url code) e.g., `"es_AR"`. - An error is triggered…
Steps to reproduce [`17.2`]: - Start a fresh DB. - Enable one of the Spanish sub-languages except the `Spanish LATAM` (the one with default `/es` url code) e.g., `"es_AR"`. - An error is triggered when upgrading to a `17.3+` version by the code trying to set the `'es'` url code while it was already available in another record. Starting from [1], we allow using the short url code `'es'` when a Spanish sub-language is enabled (as long as `es_419` is not) [A]. We also update the records in XML to set the Spanish LATAM (`es_419`) as the one with the default `'es'`, assuming that the `base.lang_es` record will always hold the `'es'` url code. Running the XML updates again in the situation of [A] will try to set the unique `es` url code on a record while another record (other than `base.lang_es`) is holding it (`"es_AR"` in this case). The goal of this commit is to simply add a `noupdate` for the XML updates so they are only loaded on initialization. [1]: https://github.com/odoo/odoo/commit/a992d2deab9d582cc33dc31f0b1bd610f82add0d Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an internal automated test for user presence updates so it no longer depends on timing-sensitive websocket behavior. The change helps keep test results stable and reduces false failures in development and release validation.
Original PR description
The `test_notify_on_status_change` ensures user presences are received when updated. To do so, they send a websocket message to the server. However, there is no guarantee the presence was updated after sending the message as the processing is asynchronous. This PR fixes the issue by directly calling `_update_presence` and waitng for the answer through the websocket. runbot-74017
Miscellaneous changes
Commit 775c113382231 change the variable name from `i` to `picking` but the fw-port 9a3b2940da55f keeps the old name. Resulting on the access token is never found. 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#176560
Original PR description
Commit 775c113382231 change the variable name from `i` to `picking` but the fw-port 9a3b2940da55f keeps the old name. Resulting on the access token is never found. 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#176560
20 changes
Enhancements to existing features
Budget forms now include an ordering sequence for budget lines, making it easier for users to arrange and review line items in the desired order. This is a small usability improvement for budget management workflows.
Original PR description
Before this commit: - There is no sequence for the budget line in the budget form view. After this commit: - Add sequence for budget line in budget form view Task-4108938
1 change
Resolved issues and error corrections
This update fixes warning messages in Kenya's electronic invoicing system to only appear when a company has an active OSCU (Online Sales Control Unit). Previously, warnings about quantity mismatches on invoices and bills of materials would display regardless of whether the company was using Kenya's EDI system, causing unnecessary alerts for non-Kenyan users. The change also removes unused code to keep the system clean.
Original PR description
Two warnings need to be conditionally hidden if the company does not have an OSCU active: - the warning on invoices that the delivered quantities do not match invoiced quantities; and - the warning on BoMs. In addition, we take the opportunity to remove the method `env['product.product']._compute_l10n_ke_validation_message` which is dead code.
steps: - be connected as someone with no accrual - give accrual allocation to an employee - go to his time offs using the smart button on his employee profile -> no settings to set the date, has_accrual_allocation is false because our user's employee doesn't have accrual allocation expected -> see the date picker on the leave dashboard if the employee has accrual allocations, not the connected user Forward-Port-Of: odoo/odoo#175686
Original PR description
steps: - be connected as someone with no accrual - give accrual allocation to an employee - go to his time offs using the smart button on his employee profile -> no settings to set the date, has_accrual_allocation is false because our user's employee doesn't have accrual allocation expected -> see the date picker on the leave dashboard if the employee has accrual allocations, not the connected user Forward-Port-Of: odoo/odoo#175686
Problem --------- Currently, when reversing a move, the current company is used as recipient bank. 1. Set a bank on a partner A 2. Go to Accounting 3. Set A as the customer of the invoice 4. Set a bank under 'recipient bank' in Other Info tab 5. Post the invoice 6. "Add Credit Note" 7. Fill in with wathever and press Reverse -> The Other Info tab of the reverse move has the company bank and not the customer's Objective --------- Obtain a similar behavior as when a credit note is
Original PR description
Problem --------- Currently, when reversing a move, the current company is used as recipient bank. 1. Set a bank on a partner A 2. Go to Accounting 3. Set A as the customer of the invoice 4. Set a bank under 'recipient bank' in Other Info tab 5. Post the invoice 6. "Add Credit Note" 7. Fill in with wathever and press Reverse -> The Other Info tab of the reverse move has the company bank and not the customer's Objective --------- Obtain a similar behavior as when a credit note is created directly: have the customer's bank set as recipient bank. Solution --------- Provide a default bank id that is set, if possible, to one of the customer's bank. opw-4035448 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173640
Steps to reproduce: - Create a product - Update its quantity and set 4 in Stock - Create two MO that consume each 2 units of that product with the same scheduled date - Create a scrap order with 1 quantity of that product and validate it Issue: The unreserve will be done on the first MO. When going through the candidate move lines in the `_free_reservation()`, we sort them depending on their picking, their date if they have a move, or their id if they don't. The issue is that when
Original PR description
Steps to reproduce: - Create a product - Update its quantity and set 4 in Stock - Create two MO that consume each 2 units of that product with the same scheduled date - Create a scrap order with 1 quantity of that product and validate it Issue: The unreserve will be done on the first MO. When going through the candidate move lines in the `_free_reservation()`, we sort them depending on their picking, their date if they have a move, or their id if they don't. The issue is that when their related move have an equal date, then the order becomes underministic. Now, always sort by their id as a last resort, so we have a consistent order no matter what. opw-4046240 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176399 Forward-Port-Of: odoo/odoo#174442
Steps to reproduce: 1. Install `l10n_in_withholding` and `l10n_it_edi_withholding` 2. Create a new company with country `India` and load CoA TDS taxes doesn't get created After this commit: We resolve the above issue. Since the issue was caused by a typo in the method name in `l10n_in_withholding` which had a definition in `l10n_it_edi_withholding` Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: ---
Original PR description
Steps to reproduce: 1. Install `l10n_in_withholding` and `l10n_it_edi_withholding` 2. Create a new company with country `India` and load CoA TDS taxes doesn't get created After this commit: We resolve the above issue. Since the issue was caused by a typo in the method name in `l10n_in_withholding` which had a definition in `l10n_it_edi_withholding` 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#176565
Steps: - install 'purchase' and 'analytic' - open purchase/RFQ - create a new rfq - add a new line in the subview list - Toggle `Analytic Distribution` optional column - Edit 'Analytic Distribution' col with the widget (`analytic_disribution`) - Select first column to edit it (`Projects (100%)`) - Click on `Search More` in the dropdown - A new dialog is opened `Search: Projects` - Go to filters and click `Add Custom Filter` - Another modal is now opened `Add Custom Filter` - Click on
Original PR description
Steps: - install 'purchase' and 'analytic' - open purchase/RFQ - create a new rfq - add a new line in the subview list - Toggle `Analytic Distribution` optional column - Edit 'Analytic Distribution'…
Steps:
- install 'purchase' and 'analytic'
- open purchase/RFQ
- create a new rfq
- add a new line in the subview list
- Toggle `Analytic Distribution` optional column
- Edit 'Analytic Distribution' col with the widget (`analytic_disribution`)
- Select first column to edit it (`Projects (100%)`)
- Click on `Search More` in the dropdown
- A new dialog is opened `Search: Projects`
- Go to filters and click `Add Custom Filter`
- Another modal is now opened `Add Custom Filter`
- Click on the first domain input
- After clicking on this input, the initial `analytic_distribution` drodown is closed
- This is the cause of the problem
- Validate your domain
- Traceback `Component is destroyed`
The initial problem comes from `AnalyticDistribution` Component.
There's a listener on `click`on `document` to manage whether or not to close the widget.
There are several cases that prevent the widget from closing:
- having an active modal containing a list view or kanban view with the following selectors:
- `'.o_modal:not(.o_inactive_modal) .o_list_view'`
- `'.o_modal:not(.o_inactive_modal) .o_kanban_view'`.
- if the click occurred in the widget element
- if the dropdown is closed
However in many other cases we have undesired behavior (unwanted closing of the widget):
- a click on dialog that is open and not modal (as in the steps above)
- a click on a popover
- drag and drop an active modal to the side
This fix normally corrects the first three cases, but unfortunately I haven't found a way to correct the case of the palette command where the `ev.target` is at the point where the element selected in the palette points into the dom, especially as this is not currently the customer's problem.
Here's how the other cases are fixed:
instead of having a condition for each case
(as there used to be for modal list view and modal kanban view)
```js
const modal = document.querySelector('.modal:not(.o_inactive_modal)');
const clickedInSearchMoreDialog = modal && modal.querySelector('.o_list_view') && modal.contains(ev.target);
const clickedInKanbanSelectorDialog = modal && modal.querySelector('.o_kanban_view') && modal.contains(ev.target);
```
I create a list of css selectors corresponding to the elements in which the `ev.target` must not be located in order to close. In particular, I include the two cases already handled by the code, as well as the new ones.
Instead of having the two previous conditions, I just have one selector in my list.
https://github.com/odoo/odoo/blob/4637514b4b1550014fc6affff1b0753ab9bc0f69/addons/analytic/static/src/components/analytic_distribution/analytic_distribution.js#L611
So I add the `o_popover` and `o_dialog` selectors to correct my initial problem.
When dragging and dropping a modal, the `ev.target` is always equal to the document, so to prevent the `analytic_distribution` widget from closing in this case I check that it's not equal to `documentElement`.
https://github.com/odoo/odoo/blob/4637514b4b1550014fc6affff1b0753ab9bc0f69/addons/analytic/static/src/components/analytic_distribution/analytic_distribution.js#L617
opw-3954404
Forward-Port-Of: odoo/odoo#168920This update makes a small correction so records can be viewed properly in editable lists and debugging contexts. It helps keep reporting and Studio customization workflows aligned with recent platform changes, reducing minor usability issues.
Original PR description
This commit applies a small x-path correction following changes made in https://github.com/odoo/odoo/pull/175348 task-3977729
Barcode-related pages now use cleaner, more human-readable web addresses. This makes links easier to understand, share, and verify without changing the underlying barcode workflows.
Original PR description
*= stock_barcode_mrp, stock_barcode_picking_batch This commit modifies existing URLs to the new format so that the URL's become more human readable. Task-3820230
The web grid module's automated tests were moved to a newer testing approach. This helps improve long-term maintainability and confidence in future updates without changing the user-facing grid features.
Original PR description
task-4028356 task-4028335
This update adjusts test coverage to reflect Odoo's newer, more readable URL format. It helps ensure related email and rental product flows continue to work correctly as links become clearer for users.
Original PR description
*= test_rental_product_configurators This commit modifies existing URLs to the new format so that the URL's become more human readable. Task-3820230
Point-of-sale IoT and preparation display pages now use cleaner, easier-to-read web addresses. This makes links more understandable for staff and easier to share or recognize without changing the underlying business workflow.
Original PR description
\* = [iot, preparation_display] This commit improves the readability of URLs by modifying them to a new, more human-friendly format. Task-3820230
The Mexican electronic invoicing integration for Point of Sale now uses clearer, more human-friendly URL formats. This makes links easier for users to read and recognize, with no major workflow changes expected.
Original PR description
This commit improves the readability of URLs by modifying them to a new, more human-friendly format. Task-3820230
The cohort reporting module's automated tests were moved to a newer testing framework. This improves maintainability and helps ensure the feature remains reliable without changing how users interact with it.
Original PR description
task-4028356
This update changes existing links in Discuss and manufacturing work order screens to a cleaner, more human-readable format. This makes shared URLs easier to understand while preserving the same navigation behavior.
Original PR description
This commit modifies existing URLs to the new format so that the URL's become more human readable. Task-3820230
Resolved issues and error corrections
This update corrects the setup for an Indian payroll salary report after a previous salary-by-head report removal. It helps keep payroll reporting components aligned so users do not encounter missing or outdated report references.
Original PR description
commit: https://github.com/odoo/enterprise/pull/59417/commits/e8c87c0980745baeb117ff09f9c665e2a8f6160a task-4107188
This update fixes a typo and adds missing translated text in the Indian GST return reporting area. It helps users see clearer, localized labels when working with GST return periods, reducing confusion in day-to-day compliance tasks.
Code cleanup and technical improvements
This update aligns the Enterprise WhatsApp module with related platform changes by making rating information available in the internal message store. It supports consistent handling of WhatsApp message ratings and includes security test coverage to help ensure access rules remain correct.
Original PR description
Enterprise counter-part. Part of task-3605717 https://github.com/odoo/odoo/pull/176203
Miscellaneous changes
This traceback arises when the user gives an invalid hour value to the end date, while creating or updating a planning template. To reproduce this issue: 1) Install `Planning` 2) Create a new `shift template` from planning configuration 3) Give an invalid hour value to the end date (greater than 24) 4) Try to save the record. Error:- ``` ValueError: hour must be in 0..23 ``` When the user gives an invalid hour value to the end date and tries to save it, a compute method
Original PR description
This traceback arises when the user gives an invalid hour value to the end date, while creating or updating a planning template. To reproduce this issue: 1) Install `Planning` 2) Create a new `shift template` from planning configuration 3) Give an invalid hour value to the end date (greater than 24) 4) Try to save the record. Error:- ``` ValueError: hour must be in 0..23 ``` When the user gives an invalid hour value to the end date and tries to save it, a compute method triggers in which hour is used to calculate the end time. https://github.com/odoo/enterprise/blob/14b37f4141f1c73712d2c5ce16e5fc815e2a6a9b/planning/models/planning_template.py#L37-L38 Which leads to the traceback. Already a condition is there to check the invalid hours for start time. By just modifying the existing condition we can resolve this issue. sentry-5655372261 Forward-Port-Of: odoo/enterprise#67580
### Steps to reproduce: - Create a new Budget with type Expense - Add budget line (ex: Administration) and a period - Open the budget - Create a new RFQ that uses the analytic distribution set on the budget - With a quantity greater than 1, the line should appear red before the budget is reached - For example with a budget of 10000 and a quantity of 2 then the line is red if the price is greater than 2500 ### Cause: Line in question : `(budget.committed_amount + line.price_subtotal * (
Original PR description
### Steps to reproduce: - Create a new Budget with type Expense - Add budget line (ex: Administration) and a period - Open the budget - Create a new RFQ that uses the analytic distribution set on the budget - With a quantity greater than 1, the line should appear red before the budget is reached - For example with a budget of 10000 and a quantity of 2 then the line is red if the price is greater than 2500 ### Cause: Line in question : `(budget.committed_amount + line.price_subtotal * (line.product_qty - line.qty_invoiced)) > budget.budget_amount` The calculation uses `price_subtotal` which is the total amount without taxes, so it already includes the quantity. ### Solution: Use `price_unit` instead of `price_subtotal`. opw-4002330 Forward-Port-Of: odoo/enterprise#66750
Issue ----- [Approvals, Purchase, Stock] 1. In approvals, set the current user as the approver for the "Create RFQ's" approval type. 2. Approvals > New Request > Create RFQ's > Select a product with a vendor setup ("Acoustic bloc screen" for example) > Submit > Approve > Create RFQ > Click smart button to navigate to the PO > Confirm the PO (should work) 4. Repeat step 2, ValidationError when trying to confirm the PO. Note: the issue only arises in this specific flow, the PO can still b
Original PR description
Issue ----- [Approvals, Purchase, Stock] 1. In approvals, set the current user as the approver for the "Create RFQ's" approval type. 2. Approvals > New Request > Create RFQ's > Select a product with…
Issue
-----
[Approvals, Purchase, Stock]
1. In approvals, set the current user as the approver for the "Create RFQ's" approval type.
2. Approvals > New Request > Create RFQ's > Select a product with a vendor setup ("Acoustic bloc screen" for example) > Submit > Approve > Create RFQ >
Click smart button to navigate to the PO > Confirm the PO (should work)
4. Repeat step 2, ValidationError when trying to confirm the PO.
Note: the issue only arises in this specific flow, the PO can still be confirmed by for example just refreshing the page.
Issue
-----
A 'default_name' key is added to the context when creating a request for a category which uses sequential names (which is the case for RFQ's approvals). https://github.com/odoo/enterprise/blob/65a8e25f1ff2d0faf17ad73c1402615d320ffc48/approvals/models/approval_category.py#L154
As a result, it gets propagated all the way to the creation of the picking when the PO is confirmed.
https://github.com/odoo/odoo/blob/beb8c7d86ae6062dbad9fcb17bc3141d14a9fcdc/addons/stock/models/stock_picking.py#L721 As pickings require a unique (name, company_id), a first picking can be created with the name 'New', but later ones will fail.
Fix
-----
Avoid propagating the default_name key when opening the purchase orders so the picking created when confirming the order will have the correct name.
opw-3990816
Forward-Port-Of: odoo/enterprise#66504Some reports display some informational columns (like the VAT for a partner, or the country of origin). These columns sometimes prevent the `Hide Lines at 0` option to correctly do its work: the desired behavior of this option is to hide the lines where the amounts are null. It shouldn't care about the "informational" columns, that are usually always present This commit force the `Hide Lines at 0` feature to ignore columns displaying information other than float, integer of monetary ones.
Original PR description
Some reports display some informational columns (like the VAT for a partner, or the country of origin). These columns sometimes prevent the `Hide Lines at 0` option to correctly do its work: the desired behavior of this option is to hide the lines where the amounts are null. It shouldn't care about the "informational" columns, that are usually always present This commit force the `Hide Lines at 0` feature to ignore columns displaying information other than float, integer of monetary ones. task-4006235 Forward-Port-Of: odoo/enterprise#67818 Forward-Port-Of: odoo/enterprise#65622
### Steps to reproduce: Have 2 companies: CO1 and CO2 - In the setting, enable Multi-Step Routes and Inter-Company Transactions - With CO1 and CO, enable Synchronize Sales and Purchase Order - Go to Inventory > Configuration > Warehouse Management > Routes - Unarchive the MTO Route - With CO1 create a route with a buy action and destination CO1/stock - With CO2 create a route with a manufacture action - Go to Inventory > Configuration > Products > Attributes - Create a product att
Original PR description
### Steps to reproduce: Have 2 companies: CO1 and CO2 - In the setting, enable Multi-Step Routes and Inter-Company Transactions - With CO1 and CO, enable Synchronize Sales and Purchase Order - Go to…
### Steps to reproduce: Have 2 companies: CO1 and CO2 - In the setting, enable Multi-Step Routes and Inter-Company Transactions - With CO1 and CO, enable Synchronize Sales and Purchase Order - Go to Inventory > Configuration > Warehouse Management > Routes - Unarchive the MTO Route - With CO1 create a route with a buy action and destination CO1/stock - With CO2 create a route with a manufacture action - Go to Inventory > Configuration > Products > Attributes - Create a product attribute with a value that "is_custom" - Create a storable product P with using MTO and tour CO1 and CO2 routes - Set CO2 as a vendor for the product - With CO1, create a SO for 1 unit of your product P - a popup asks you for a custom product attribute value, write "test" - Confirm the SO > Automatically creates a PO (w/ description) - Confirm the PO > Automatically create an SO in CO2 (w/ description) - Confirm the SO in CO2 > Automatically create an MO #### Issue: #### The custom description is missing on the final MO. #### Note: If you were to create an SO directly in CO2 for 1 unit of P, the custom description associated with the custom attribute value would be present on the associated MO. ### Cause of the issue: The MO is created by a procurement generated from the SOL during the call of the `_action_launch_stock_rule` method: https://github.com/odoo/odoo/blob/055184ea033e7068ce33c92390c73ae39b2db259/addons/sale_stock/models/sale_order_line.py#L345 The custom description that will appear on the MO and containing the informations related to the custom attribute values is generated here: https://github.com/odoo/odoo/blob/055184ea033e7068ce33c92390c73ae39b2db259/addons/sale_stock/models/sale_order_line.py#L267 However, this method will return an empty string because the `product_custom_attribute_value_ids` is absent from our SOL https://github.com/odoo/odoo/blob/055184ea033e7068ce33c92390c73ae39b2db259/addons/sale/models/sale_order_line.py#L338-L347 On the other hand, this `product_custom_attribute_value_ids` was set and is still existing on the original SO that started the flow in CO1. The reason that it is not present anymore on the last SO is because this SOL field has no equivalent on the `purchase.order.line` model and the information was therefore forgotten on the MO and has not been transferred directly from the PO of CO1 to the SO of CO2. ### Fix: We rely on the `sale_line_id` field of the `purchase.order.line` model in order to determine the original SOL of the final SOL and update the `product_custom_attribute_value_ids` accordingly. ### Note: As a side effect of our change in `sale_purchase_stock` linking our sol to the pol via the procurement commit 63ef74b can be reverted since the message is already automatically posted (the message is now written by the user who cancelled the SO rather than Odoobot). opw-3998861 --- Forward-Port-Of: odoo/enterprise#68139 Forward-Port-Of: odoo/enterprise#67172
Before this commit: Steps 1) Install l10n_es_reports 2) Switch to ES company 3) Create a EU vendor (any except SPAIN) + add TIN 4) Create a bill with last month date 5) Reverse that bill with current month date 6) Go to Tax reports 7) Switch to Tax Report (Mod 349) (ES) 8) Choose date range: This Month 9) Generate BOE => It shows an error with a traceback `/l10n_es_reports/models/aeat_tax_reports.py", line 1257, in _write_type2_refund_records previous_report_amoun
Original PR description
Before this commit:
Steps
1) Install l10n_es_reports
2) Switch to ES company
3) Create a EU vendor (any except SPAIN) + add TIN
4) Create a bill with last month date
5) Reverse that bill with current month date
6) Go to Tax reports
7) Switch to Tax Report (Mod 349) (ES)
8) Choose date range: This Month
9) Generate BOE
=> It shows an error with a traceback `/l10n_es_reports/models/aeat_tax_reports.py", line 1257, in _write_type2_refund_records
previous_report_amount = invoice_line_data['columns'][0]['no_format']
TypeError: 'NoneType' object is not subscriptable`
After this commit:
BOE in mod349 is generated properly without errors
opw-4055702
Forward-Port-Of: odoo/enterprise#68096This is needed to evaluate this column_invisible expression https://github.com/odoo/enterprise/blob/985c085edc66ccb27311a94cfb16f27b06d7bfec/industry_fsm_sale/views/project_sharing_views.xml#L69 opw-4015035 Forward-Port-Of: odoo/enterprise#68216 Forward-Port-Of: odoo/enterprise#68110
Original PR description
This is needed to evaluate this column_invisible expression https://github.com/odoo/enterprise/blob/985c085edc66ccb27311a94cfb16f27b06d7bfec/industry_fsm_sale/views/project_sharing_views.xml#L69 opw-4015035 Forward-Port-Of: odoo/enterprise#68216 Forward-Port-Of: odoo/enterprise#68110
### Fixes in ATS report: - Remove foreign documents '15' and '110'. SRI DIMM returns a validation error  - In sales, filter by commercial partner and not by partner because there may be different addresses (the ATS validates by ID number). - In sales, change the emission point to entity point (tag "codEstab" and "numEstabRuc"). As it says the Technical Sheet of ATS 
- In sales, filter by commercial partner and not by partner because there may be different addresses (the ATS validates by ID number).
- In sales, change the emission point to entity point (tag "codEstab" and "numEstabRuc"). As it says the Technical Sheet of ATS
- In sales, Get all the establishments registered at the SRI (tag "ventasEstablecimiento"). As it says the Technical Sheet of ATS
- Fix Unit tests
Forward-Port-Of: odoo/enterprise#67060