Daily updates from Odoo
Friday, October 18, 2024
8 changes · 17.0
Enhancements to existing features
This update adds a new XLSX export option for Colombian companies that provides a detailed trial balance report broken down by both accounts and business partners. Previously, the trial balance only grouped data by accounts. This enhancement makes it easier for Colombian businesses to analyze their financial data with partner-level detail, improving financial reporting and analysis capabilities.
Original PR description
… partners This enhancement introduces an XLSX export variant for the trial balance, specifically tailored for Colombian companies under the report name "BALANCE DE PRUEBA POR TERCERO." The requirement is to provide a detailed breakdown per partner for each account. The initial trial balance lines are primarily derived from the general ledger report, which originally focused on grouping by accounts. Inspired by the structure of the general ledger accounts, this implementation now extends the grouping to include both accounts and partners. While initially designed for the Colombian localization, the code is flexible and can be easily adapted for use in other localizations as needed. Co-authored-by: Brice Bartoletti <bib@odoo.com> task-3594546 Forward-Port-Of: odoo/enterprise#70110
Resolved issues and error corrections
This fix prevents the customer display feature from unexpectedly closing its connection when opened. The issue was causing the display to disconnect, similar to a previously reported problem with the self-order feature. This ensures the customer display remains reliably connected during point-of-sale operations.
Original PR description
Exactly the same case as described in: https://github.com/odoo/odoo/pull/183527 (but happen opening the customer display instead of self-order) opw-4233060
This fix resolves an issue where components manually added to a manufacturing operation on the shopfloor were not visible to users, even though they were correctly added to the system. The problem occurred because newly added components were not being marked with the correct visibility flag. Now when operators add components directly from the shopfloor interface, those components will properly display in the work order.
Original PR description
### Steps to reproduce: - Create a product with a bom and an operation op1 - Create and confirm an MO for 1 unit of that product - Go to the shopfloor > on the operation > 3 dots > Add component -…
### Steps to reproduce: - Create a product with a bom and an operation op1 - Create and confirm an MO for 1 unit of that product - Go to the shopfloor > on the operation > 3 dots > Add component - Add a component to be consumed in that operation #### > While the componenet was correctly added to the MO and linked to the WO it is not visible on hte shopfloor. ### Cause of the issue: The only moves that are visible on "MrpDisplayRecord"'s are the move that are in `manual_consumption = True` see: https://github.com/odoo/enterprise/blob/88a092acd261db8f3a8ee1f0cf8174c3d7089472/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L188-L191 However, when a product is added via the `action_add_component` > `add_product`, the `manual_consumption` of the move is computed as if it was added to the MO without being linked to a `bom_line_id`: https://github.com/odoo/enterprise/blob/88a092acd261db8f3a8ee1f0cf8174c3d7089472/mrp_workorder/wizard/additional_product.py#L36-L46 https://github.com/odoo/odoo/blob/2d652f42f63c2501b1a9feb7a4830ea3d7d05f51/addons/mrp/models/mrp_production.py#L1198 As a result the move_raw is added as a manual_consumption = False. ### Note: Thank to Commit eb751b5f861b25205dbb0b0fb90ddcdbbcd10f55 , the issue is not reproducible in 18.0 anymore. This was soved in the same manner: https://github.com/odoo/enterprise/blob/2a0ccbe7058f8d4383a63ed1897945bec3a1cec3/mrp_workorder/models/mrp_production.py#L36-L38 https://github.com/odoo/enterprise/blob/2a0ccbe7058f8d4383a63ed1897945bec3a1cec3/mrp_workorder/models/mrp_production.py#L107-L114 opw-4199156
This fix ensures that analytic distributions are correctly applied to depreciation entries when computing asset depreciation. Previously, the system was not propagating the analytic distribution model settings to the depreciation journal entries, which could lead to incomplete cost tracking and reporting for assets in companies using analytic accounting.
Original PR description
…entries Steps to reproduce: - Create a belgian company - Create an analytic distibution model - Create an asset, set the expense account to the account defined in the analytic distribution model - Click on "Compute Depreciation" Observed behavior: The analytic ditribution is not applied to the depreciation entries. Desired behavior: The analytic distribution is applied correctly. task-4241362 Forward-Port-Of: odoo/enterprise#72220
Regular users with access to the IoT app were unable to pair IoT boxes due to permission errors. This fix adds the necessary access permissions so that regular users can now successfully pair IoT boxes without encountering errors.
Original PR description
Before this change, if a regular user was granted access to the IoT app, they would get a traceback on trying to pair an IoT box as they cannot access `ir.config_parameter`. This PR adds the missing `sudo` calls to fix this traceback and allow the user to pair an IoT box. task-4216519 Forward-Port-Of: odoo/enterprise#72199
This fix resolves an issue in Web Studio where adding a field to one section and removing another section in a form were being incorrectly combined into a single operation. Now these actions are properly handled as separate, independent operations, allowing users to make multiple edits to form layouts without unexpected results.
Original PR description
…ifferent trees
Add a field at the end of the "left" subgroup and remove the "right" subgroup.
```xml
<form>
<group>
<group>
<field name="display_name" />
[ADD A FIELD]
</group>
[ REMOVE THIS GROUP
<group>
</group>
]
</group>
</form>
```
Before this commit, when "normalizing" the xpaths, the add field operation was aggregated with the remove operation because no unchanged node was found in between.
We were left with the inheriting view:
```xml
<xpath expr="[..]/group[2]" position="replace">
<field name="added_field" />
</xpath>
```
After this commit, this flow works and the two operations are independent.
part of task-4207793
Forward-Port-Of: odoo/enterprise#71289This fix restores the missing confirmation dialog that should appear when users delete appointment bookings from the Gantt calendar view. Previously, users could accidentally delete bookings without any warning prompt. Now the system properly asks for confirmation before removing any appointment records.
Original PR description
Steps to reproduce =================== - Create a booking using any appointment type. - Delete that booking from Gantt view. - The confirmation dialog is missing when deleting the record. This PR addresses the issue of the missing confirmation dialog while deleting calendar event records. Task-4228681
This update corrects the private transport reimbursement calculations in the Belgian payroll system. The changes ensure that employee reimbursements for using personal vehicles for work purposes are calculated accurately according to current Belgian regulations and company policies.