Friday, March 7, 2025
72 changes
6 changes
Enhancements to existing features
The Monster recruitment integration now deactivates the generic “ALL” industry option. This makes industry selection more logical and helps avoid overly broad or confusing choices in recruitment workflows.
Original PR description
This commit deactivate the "ALL" industry in the hr_recruitment_integration_monster module to make the flow more logical in other recruitment modules. task-4270308
Resolved issues and error corrections
A recent internal change missed a related adjustment in the India reporting module, which could cause errors when using certain linked record fields with avatars. This fix restores the expected behavior so users can continue working in India reports without that disruption.
Original PR description
In the commit [1], we refactor the many2one widgets but the specialisation in this module was missed and caused an error. [1]: bcaa9e9b23d637edfe05baff83aea2ac18d9f4b2
Miscellaneous changes
Automation rule trigger field ids can now be deducted from a default filter domain passed in the context of an action. As a result, in the action used to direct a user of the Documents application to the Automation Rules, it is no longer necessary to pass the trigger field id to be displayed in the new rule creation form. Only the filter domain is required to achieve the same result. This makes it possible to delete an orm call without altering the implemented feature. see odoo/odoo#193576
Original PR description
Automation rule trigger field ids can now be deducted from a default filter domain passed in the context of an action. As a result, in the action used to direct a user of the Documents application to the Automation Rules, it is no longer necessary to pass the trigger field id to be displayed in the new rule creation form. Only the filter domain is required to achieve the same result. This makes it possible to delete an orm call without altering the implemented feature. see odoo/odoo#193576 see odoo/enterprise#75719 task-4502214 Forward-Port-Of: odoo/enterprise#77515
19 changes
Enhancements to existing features
The Documents app now opens its automation rule setup with fewer background calls while keeping the same user experience. This reduces unnecessary system work and can make the transition to automation settings slightly more efficient.
Original PR description
Automation rule trigger field ids can now be deducted from a default filter domain passed in the context of an action. As a result, in the action used to direct a user of the Documents application to the Automation Rules, it is no longer necessary to pass the trigger field id to be displayed in the new rule creation form. Only the filter domain is required to achieve the same result. This makes it possible to delete an orm call without altering the implemented feature. see odoo/odoo#193576 see odoo/enterprise#75719 task-4502214
Activating developer mode with the India reports module installed no longer triggers a validation error. This helps administrators and support teams use debug tools without being blocked by an unexpected issue.
Original PR description
This PR fixes an issue where activating developer mode triggers a validation error due to an invalid `component` object. Steps:- 1. Install the `l10n_in_reports` module. 2. Enable debug mode. 3. Receives a validation error.
Comments are intended for adding notes or remarks on specific parts of the body and are not meant to be forwarded or replied to. This PR disables the reply and forward actions for comments on knowledge articles. Task-4624027 Forward-Port-Of: odoo/enterprise#80752
Original PR description
Comments are intended for adding notes or remarks on specific parts of the body and are not meant to be forwarded or replied to. This PR disables the reply and forward actions for comments on knowledge articles. Task-4624027 Forward-Port-Of: odoo/enterprise#80752
Description of the issue ======================== The initial issue was, when tracked product lines are grouped by product in batch ("Group batch lines" parameter checked in the picking type config), the sublines weren't displayed. This issue was caused by the way we choose to display or not sublines. For a tracked product, we don't display them if reserved lot/serial is hidden (picking type config) and if there is no qty done. That said, that didn't take in consideration the grouping by p
Original PR description
Description of the issue ======================== The initial issue was, when tracked product lines are grouped by product in batch ("Group batch lines" parameter checked in the picking type config),…
Description of the issue
========================
The initial issue was, when tracked product lines are grouped by product in batch ("Group batch lines" parameter checked in the picking type config), the sublines weren't displayed.
This issue was caused by the way we choose to display or not sublines. For a tracked product, we don't display them if reserved lot/serial is hidden (picking type config) and if there is no qty done.
That said, that didn't take in consideration the grouping by product where lines for different pickings are grouped together.
In this case, it's better to show the qty demand anyway to know how many quantity needs to be processed for each picking.
Once this issue is fixed, a second issue appears.
Imagine you have this following case:
- 1 line for lot product (0/4 qty) for receipt 1;
- 1 line for lot product (0/4 qty) for receipt 2.
- In batch, these lines are grouped because they share the same product.
Now, let's say we do the following process:
1. Scan the lot product -> The grouped line is selected;
2. Scan lot01 two times -> receipt 1 line is now 2/4 qty with lot01;
3. Scan lot02 -> receipt 2 line is now 1/4 with lot02.
The point 3. where is the issue happens. Usually, when we scan a lot, we check if the line is completed or not by checking its parent line's quantity. Here, the parent line is the batch grouped line and should not work exactly like that, because by checking this line as the parent of every sublines means we can't know if a particular picking need is fulfilled or not.
How to reproduce
================
- Inventory > Configuration > Operations Types > Barcode App:
- Uncheck "Show reserved lot/SN";
- Check "Group batch lines".
- Create two receipts for the same tracked by lot product;
- Create a batch for this receipt;
- Open the batch in the Barcode app -> You can see there is a line for this product with the total quantity but when clicking on the button to display sublines, the sublines are not shown.
Fix
===
For the first issue, we simply added a condition for `stock.picking.batch` to adapt to this case.
For the second issue, the group by tracked product inside a single picking and the group by product inside a batch are not the same and use a different key.
The first kind of group uses the key `parentLine` and the second one use the key `batchParentLine`. When we want the parent line of a subline, we will always refer to the `parentLine`. But in the interface, if this parent line is itself inside a `batchParentLine`, the `parentLine` won't be displayed, only the batch parent line.
That way, the user still has all lines for a same product grouped together under a single parent line, but to know if a need if fulfilled,
we still check on the parent line limited to a single picking.
[opw-4291149](https://www.odoo.com/odoo/project/49/tasks/4291149)
Forward-Port-Of: odoo/enterprise#79716
Forward-Port-Of: odoo/enterprise#79516Resolved issues and error corrections
This change reverts a previous accounting adjustment because currency fallback handling is already covered elsewhere in the system. It helps prevent redundant logic and reduces the risk of inconsistent invoice tax behavior.
Original PR description
Revert https://github.com/odoo/odoo/commit/fbdf519e0dc8830326a8ac120475966002b8474f The fallback of the currency is already managed automatically since: https://github.com/odoo/odoo/commit/1cf68be0807fbbd040022533ecf6372995296989 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes failing HTML editor tests by checking the actual text color used during testing instead of relying on fixed color values. It helps keep automated validation reliable when table cell colors vary for readability in light or dark modes.
Original PR description
**Problem**: Tests are failing due to hardcoded text color in this commit: https://github.com/odoo/odoo/commit/443e1678e748ee2320c4d361d0d0538d862c5f68 Text color might change during tests, causing failures. This issue affects only `td` elements since `color` is added to them when their background is changed to ensure text visibility in dark/light modes. **Solution**: Use the computed text color instead of hardcoded values in tests. runbot-159850 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The barcode interface no longer shows the return products option where it cannot be used, such as delivery batches or transfers that are not completed. This prevents users from hitting an error and keeps warehouse actions aligned with valid return workflows.
Original PR description
Steps to Reproduce the Bug: - Install stock_picking_batch. - Go to Barcode > Operations > Delivery Orders > Batches. - Select any batch: - Click on the Parameters button > In the Operation section: -…
Steps to Reproduce the Bug:
- Install stock_picking_batch.
- Go to Barcode > Operations > Delivery Orders > Batches.
- Select any batch:
- Click on the Parameters button > In the Operation section: - Click on Return Products.
Problem:
A traceback is raised:
"The method 'stock.picking.batch.action_create_return_picking' does not exist."
The function “action_create_return_picking” belongs to the “stock.picking” model, not to “stock.picking.batch” records. We are not supposed to be able to return products from a batch.
Moreover, even for “stock.picking” records, products can only be returned from done pickings. However, this button is displayed in all picking states except the done state:
https://github.com/odoo/enterprise/blob/2d5dbb93e6b33c2be786f9b2361c993f715d1a7f/stock_barcode/static/src/components/main.xml#L119
Solution:
Have the same condition for done pickings as in:
https://github.com/odoo/enterprise/blob/2d5dbb93e6b33c2be786f9b2361c993f715d1a7f/stock_barcode/static/src/components/main.xml#L165-L170
opw-4624039Saving a restaurant table appointment could fail when the linked point of sale configuration had no active session. The fix sends appointment updates to the correct reserved-table sessions, preventing the error and allowing staff to save appointments normally.
Original PR description
Steps to reproduce: 1. Open new table appointment form from the appointment app 2. Select a table ressource that is linked to a pos_config that has no current_session_id 3. Save Traceback is shown Fix: When notifying the tables of the appointment update the wrong session object was used. This commit ensure that the correct object is used in order to notify the sessions linked to the reserved tables
Miscellaneous changes
Steps to Reproduce: - Create two companies: A and B. - In Company A, create a sale order for Company B with product P1. - Confirm the sale order and navigate to the associated picking. - Add a new product P2 and confirm the picking. Issue: No sale order line is created for the newly added move in the picking. Technical Reason: Before v17.2, intercompany transfers used the "Partner/Customers" location (type: "customer") as the destination. The logic for creating a sale order line
Original PR description
Steps to Reproduce: - Create two companies: A and B. - In Company A, create a sale order for Company B with product P1. - Confirm the sale order and navigate to the associated picking. - Add a new…
Steps to Reproduce: - Create two companies: A and B. - In Company A, create a sale order for Company B with product P1. - Confirm the sale order and navigate to the associated picking. - Add a new product P2 and confirm the picking. Issue: No sale order line is created for the newly added move in the picking. Technical Reason: Before v17.2, intercompany transfers used the "Partner/Customers" location (type: "customer") as the destination. The logic for creating a sale order line checked move.location_dest_id.usage != 'customer', which correctly allowed the sale order line to be created. In v17.2, intercompany transfers now use "Virtual Locations/Inter-company transit" (type: "transit") as the destination. Since 'transit' != 'customer', the condition incorrectly bypasses sale order line creation. Fix: Modify the condition to check if the destination location is either 'customer' or 'transit'. This ensures that sale order lines are correctly generated for intercompany transfers. Task-4455830 Forward-Port-Of: odoo/odoo#197245
### Issue: Currently, leaving the barcode app will split moves/move lines in the backend in order to keep track of the changes made on the move lines to match the next time you go into the barcode app. #### Use case 1 (split move): - Create a storable product P tracked by lot - Adjust the onHand quantity to put 2 quants in stock: - quant1: Location: WH/Stock, lot_id: LOT0001, quantity: 3.0 - quant2: Location: WH/Stock, lot_id: LOT0002, quantity: 3.0 - Create and confirm a Deli
Original PR description
### Issue: Currently, leaving the barcode app will split moves/move lines in the backend in order to keep track of the changes made on the move lines to match the next time you go into the barcode…
### Issue:
Currently, leaving the barcode app will split moves/move lines in the backend in order to keep track of the changes made on the move lines to match the next time you go into the barcode app.
#### Use case 1 (split move):
- Create a storable product P tracked by lot
- Adjust the onHand quantity to put 2 quants in stock:
- quant1: Location: WH/Stock, lot_id: LOT0001, quantity: 3.0
- quant2: Location: WH/Stock, lot_id: LOT0002, quantity: 3.0
- Create and confirm a Delivery order for 3 x P
> The move of the delivery should have reserved 3 units form LOT0001
- Enter the barcode app, scan you DO-name
- Scan your product barcode then scan LOT002 three times
- Leave the barcode app and come back
#### > The barcode line 3/3 was updated to 3/6: 0/3 LOT001 and 3/3 LOT002.
#### Use case 2 (split move line):
- Create 2 storable products P and COMP.
- Adjust the onHand quantity to put 10 units of COMP in stock.
- Create a bill of material for P with one line: - 1 x COMP
- Create and confirm an MO for 10 units of P.
- Set the qty_producing to 5 units -> 5 units of comp are reserved
- Enter the barcode app, scan you MO-name
- The component line should be 5/5 since 5 units are reserved.
- Adjust the registration to 1/5.
- Leave the barcode app and come back
#### > The barcode line 1/5 was updated to 1/1 and 0/9 instead of 0/4.
### Cause of the Issue:
In both cases, the problem comes from the fact we leave the barcode with a different reservation than the initial one.
In the first use case, a new move will be created with a quantity of 3 in order to handle the new line created with LOT002 as soon as you have scanned your products. Therefore even though you entered the barcode app with a reservation demand of 3 units you leave it with 2 move lines with a cumulative quantity of 3 + 3 = 6:
- line1: quantity: 3, lot_id: LOT001, picked: False
- line2: quantity: 3, lot_id: LOT002, picked: True The next time you enter the app you will therefore see a reservation demand of 6 rather than 3.
In the second use case however, a move line is simply created by the `split_uncompleted_moves` when you exit the barcode app: https://github.com/odoo/enterprise/blob/0f4e8ce54be746db02e9f4a6974e387d90608a08/stock_barcode_mrp/models/stock_move.py#L18-L29
And the quantity of the new move line is based on the `prodcut_uom_qty` of the move rather than the initial reservation demand (quantity when entering barcode). This explains why reservation demand changed from 5 to 10 when you left and came back.
Enterprise: https://github.com/odoo/enterprise/pull/77068
opw-4353884 and opw-4417870
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#193465Lately we have been encountering increasing issues with on-prem databases which are being duplicated without running neutralization scripts, and thus when one of the two instances renews its refresh token, the other database's refresh token gets out of sync and we end up with a cryptic error `Invalid signature for request to the account_edi proxy`. 1. Prod and Staging both have refresh token RT1 2. Staging needs new refresh token: sends RT1 to IAP and gets RT2 3. IAP invalidates RT1 4. Pro
Original PR description
Lately we have been encountering increasing issues with on-prem databases which are being duplicated without running neutralization scripts, and thus when one of the two instances renews its refresh token, the other database's refresh token gets out of sync and we end up with a cryptic error `Invalid signature for request to the account_edi proxy`. 1. Prod and Staging both have refresh token RT1 2. Staging needs new refresh token: sends RT1 to IAP and gets RT2 3. IAP invalidates RT1 4. Prod still has RT1 and tries to refresh 5. IAP rejects RT1 because it is no longer aware of RT1 6. Test cannot get a new token and loses access with this error as the signature is no longer valid This commit simply improves this error message and redirects users to odoo support. task-4531587 Forward-Port-Of: odoo/odoo#199999 Forward-Port-Of: odoo/odoo#196271
[task-4421055](https://www.odoo.com/odoo/project.task/4421055)
Original PR description
[task-4421055](https://www.odoo.com/odoo/project.task/4421055)
Steps to reproduce: - create a new quotation - select a customer with another langage than the current user - add a product - add a discount using the discount button (select "global amount" or "fixed amount") Problem: Inside "order lines" from the quotation, the "description" column in the line created for the discount product is not translated. https://github.com/odoo/odoo/blob/c62e8d90db481fb7ba28e888431b6a7dc5ed03cd/addons/sale/wizard/sale_order_discount.py#L126 opw-4534846 Fo
Original PR description
Steps to reproduce: - create a new quotation - select a customer with another langage than the current user - add a product - add a discount using the discount button (select "global amount" or "fixed amount") Problem: Inside "order lines" from the quotation, the "description" column in the line created for the discount product is not translated. https://github.com/odoo/odoo/blob/c62e8d90db481fb7ba28e888431b6a7dc5ed03cd/addons/sale/wizard/sale_order_discount.py#L126 opw-4534846 Forward-Port-Of: odoo/odoo#197892
Forward-Port-Of: odoo/enterprise#80405
Original PR description
Forward-Port-Of: odoo/enterprise#80405
Overrides xml and xlsx export for Estonia intrastat because the current columns of the default intrastat report don't match with estonian government requirements. More information can be found at those addresses: - Arrivals: https://www.stat.ee/en/questionnaires/intrastat-arrivals-2024-month - Dispatches: https://www.stat.ee/en/questionnaires/intrastat-dispatches-2024-month task-3989930 Forward-Port-Of: odoo/enterprise#80816 Forward-Port-Of: odoo/enterprise#71114
Original PR description
Overrides xml and xlsx export for Estonia intrastat because the current columns of the default intrastat report don't match with estonian government requirements. More information can be found at those addresses: - Arrivals: https://www.stat.ee/en/questionnaires/intrastat-arrivals-2024-month - Dispatches: https://www.stat.ee/en/questionnaires/intrastat-dispatches-2024-month task-3989930 Forward-Port-Of: odoo/enterprise#80816 Forward-Port-Of: odoo/enterprise#71114
This commit targets to add new default pos payment method for mexican companies. Also defines l10n_mx_edi_payment_method_id for each default payment method target: saas-17.4 -> master task-4486643 Forward-Port-Of: odoo/enterprise#78148
Original PR description
This commit targets to add new default pos payment method for mexican companies. Also defines l10n_mx_edi_payment_method_id for each default payment method target: saas-17.4 -> master task-4486643 Forward-Port-Of: odoo/enterprise#78148
Changes are introduced to ensure compliance with the regulations established by SUNAT in the context of inventory management, specifically as outlined in Resolution No. 234-2006/SUNAT. Additionally, functionality and data presentation improvements are included to facilitate analysis and interpretation for end users. Main Changes: 1. Initial Balance for the Period - The initial balance of products in stock at the start of the fiscal period is added. - Code is introduced to identi
Original PR description
Changes are introduced to ensure compliance with the regulations established by SUNAT in the context of inventory management, specifically as outlined in Resolution No. 234-2006/SUNAT. Additionally,…
Changes are introduced to ensure compliance with the regulations
established by SUNAT in the context of inventory management,
specifically as outlined in Resolution No. 234-2006/SUNAT. Additionally,
functionality and data presentation improvements are included to
facilitate analysis and interpretation for end users.
Main Changes:
1. Initial Balance for the Period
- The initial balance of products in stock at the start of the fiscal
period is added.
- Code is introduced to identify the initial balance.
2. Corrections in Inventory Valuation
- Fields related to product entries and exits in inventory valuation are
adjusted.
3. Optimized Presentation Order
- A new sorting criterion is established for the records:
- Priority 1: Sort by product code (column 7).
- Priority 2: Sort by date (column 10).
- This allows for better analysis and interpretation, as well as ensuring
correct printing.
4. Delivery Guide Number as the Primary Indicator
- Fields 11, 12, and 13 now use the delivery guide number as the primary
indicator, complying with regulations.
- This includes the delivery guide number corresponding to the transfer
document, payment voucher, internal document, or similar.
Forward-Port-Of: odoo/enterprise#79404
Forward-Port-Of: odoo/enterprise#72064Related to https://github.com/odoo/odoo/pull/195866. Now that `Can publish` is based on access rights, some extra queries are needed when `website` is installed. Note that the `appointment`-only and `appointment.hr`-only counts are unchanged. task-3175890 Forward-Port-Of: odoo/enterprise#79612 Forward-Port-Of: odoo/enterprise#79231
Original PR description
Related to https://github.com/odoo/odoo/pull/195866. Now that `Can publish` is based on access rights, some extra queries are needed when `website` is installed. Note that the `appointment`-only and `appointment.hr`-only counts are unchanged. task-3175890 Forward-Port-Of: odoo/enterprise#79612 Forward-Port-Of: odoo/enterprise#79231
### Issue: Currently, leaving the barcode app will split moves/move lines in the backend in order to keep track of the changes made on the move lines to match the next time you go into the barcode app. #### Use case 1 (split move): - Create a storable product P tracked by lot - Adjust the onHand quantity to put 2 quants in stock: - quant1: Location: WH/Stock, lot_id: LOT0001, quantity: 3.0 - quant2: Location: WH/Stock, lot_id: LOT0002, quantity: 3.0 - Create and confirm a Deli
Original PR description
### Issue: Currently, leaving the barcode app will split moves/move lines in the backend in order to keep track of the changes made on the move lines to match the next time you go into the barcode…
### Issue:
Currently, leaving the barcode app will split moves/move lines in the backend in order to keep track of the changes made on the move lines to match the next time you go into the barcode app.
#### Use case 1 (split move):
- Create a storable product P tracked by lot
- Adjust the onHand quantity to put 2 quants in stock:
- quant1: Location: WH/Stock, lot_id: LOT0001, quantity: 3.0
- quant2: Location: WH/Stock, lot_id: LOT0002, quantity: 3.0
- Create and confirm a Delivery order for 3 x P
> The move of the delivery should have reserved 3 units form LOT0001
- Enter the barcode app, scan you DO-name
- Scan your product barcode then scan LOT002 three times
- Leave the barcode app and come back
#### > The barcode line 3/3 was updated to 3/6: 0/3 LOT001 and 3/3 LOT002.
#### Use case 2 (split move line):
- Create 2 storable products P and COMP.
- Adjust the onHand quantity to put 10 units of COMP in stock.
- Create a bill of material for P with one line: - 1 x COMP
- Create and confirm an MO for 10 units of P.
- Set the qty_producing to 5 units -> 5 units of comp are reserved
- Enter the barcode app, scan you MO-name
- The component line should be 5/5 since 5 units are reserved.
- Adjust the registration to 1/5.
- Leave the barcode app and come back
#### > The barcode line 1/5 was updated to 1/1 and 0/9 instead of 0/4.
### Cause of the Issue:
In both cases, the problem comes from the fact we leave the barcode with a different reservation than the initial one.
In the first use case, a new move will be created with a quantity of 3 in order to handle the new line created with LOT002 as soon as you have scanned your products. Therefore even though you entered the barcode app with a reservation demand of 3 units you leave it with 2 move lines with a cumulative quantity of 3 + 3 = 6:
- line1: quantity: 3, lot_id: LOT001, picked: False
- line2: quantity: 3, lot_id: LOT002, picked: True The next time you enter the app you will therefore see a reservation demand of 6 rather than 3.
In the second use case however, a move line is simply created by the `split_uncompleted_moves` when you exit the barcode app: https://github.com/odoo/enterprise/blob/0f4e8ce54be746db02e9f4a6974e387d90608a08/stock_barcode_mrp/models/stock_move.py#L18-L29
And the quantity of the new move line is based on the `prodcut_uom_qty` of the move rather than the initial reservation demand (quantity when entering barcode). This explains why reservation demand changed from 5 to 10 when you left and came back.
Community: odoo/odoo#193465
opw-4353884 and opw-4417870
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/enterprise#79444
Forward-Port-Of: odoo/enterprise#77068### Steps to reproduce: - Open a Helpdesk ticket - Send message on this ticket - Duplicate this ticket - Go to Reporting > Ticket Analysis - Check 'Hours to First Response' value for the duplicated ticket ### Cause: Those fields of response hours are being copied when duplicating tickets. ### Fix: We added 'copy=False' to each of those fields definition so we don't duplicate those fields when duplicating a record. opw-4582995 Forward-Port-Of: odoo/enterprise#80714 Forward-P
Original PR description
### Steps to reproduce: - Open a Helpdesk ticket - Send message on this ticket - Duplicate this ticket - Go to Reporting > Ticket Analysis - Check 'Hours to First Response' value for the duplicated ticket ### Cause: Those fields of response hours are being copied when duplicating tickets. ### Fix: We added 'copy=False' to each of those fields definition so we don't duplicate those fields when duplicating a record. opw-4582995 Forward-Port-Of: odoo/enterprise#80714 Forward-Port-Of: odoo/enterprise#80562
Steps to reproduce: - create two companies - create two analytic account (no company defined) - create for company B an analytic distribution model with one of the analytic account and define company A as parter - With Company A, create an invoice and on the line use the other analytic account and confirm Issue: The distribution model for Company B will not be used and only the account distribution from the original invoice will be defined on the line Cause: In the _get_distribution
Original PR description
Steps to reproduce: - create two companies - create two analytic account (no company defined) - create for company B an analytic distribution model with one of the analytic account and define company A as parter - With Company A, create an invoice and on the line use the other analytic account and confirm Issue: The distribution model for Company B will not be used and only the account distribution from the original invoice will be defined on the line Cause: In the _get_distribution method, the partner is incorrectly set to Company B, leading to this issue. opw-4414850 Forward-Port-Of: odoo/enterprise#78754 Forward-Port-Of: odoo/enterprise#76395
*l10n_nl_intrastat,l10n_nl_reports,l10n_nl_reports_sbr, l10n_nl_reports_sbr_icp,l10n_nl_reports_sbr_ob_nummer, l10n_nl_reports_sbr_status_info [task-4421055](https://www.odoo.com/odoo/project.task/4421055)
Original PR description
*l10n_nl_intrastat,l10n_nl_reports,l10n_nl_reports_sbr, l10n_nl_reports_sbr_icp,l10n_nl_reports_sbr_ob_nummer, l10n_nl_reports_sbr_status_info [task-4421055](https://www.odoo.com/odoo/project.task/4421055)