Daily updates from Odoo
Tuesday, October 22, 2024
13 changes · 17.0
New functionality added to Odoo
This update adds localization support for Lebanon, including a complete chart of accounts, tax definitions, and fiscal positions. This allows businesses operating in Lebanon to accurately manage their financial data within Odoo.
Original PR description
Added base localization package with chart of accounts ,taxes and fiscal positions for Lebanon 🇱🇧 Link to task: [#3927914](https://www.odoo.com/web#model=project.task&id=3927914)
Resolved issues and error corrections
This update fixes a calculation error in the Swiss payroll module (l10n_ch_hr_payroll_elm) related to the calculation of CAF (Additional Pension Fund). The system was previously using gross salary instead of the AVS (Swiss Social Security) salary, which is the correct basis for CAF calculations. This ensures accurate reporting and compliance with Swiss regulations.
Original PR description
CAF is based on the AVS Salary and not the GROSS
This update ensures Odoo can continue running on Debian by aligning with a recent change in the PDF library used. Specifically, Odoo has been updated to work with the newer, preferred version of the pypdf library, resolving compatibility issues that were preventing release on Debian. This ensures continued support for key Odoo features.
Original PR description
As Debian wants to remove pypdf2 and keep only pypdf (4.3) in trixie, so we need to be compatible otherwise Odoo could not be released in the next Debian.
This fix ensures that when customers upgrade their subscriptions, the discount rates from their original subscription lines are properly preserved and applied to the new upsell lines. Previously, all upsell lines would incorrectly receive the same discount regardless of their original rates. This is especially important for mid-period upgrades where pricing is already adjusted, ensuring customers see accurate pricing that combines both their original discount and any prorated adjustments.
Original PR description
Steps to reproduce: - Subscriptions app > New > Add 1 line with any recurring product twice - Give both lines different discounts - Confirm > Create Invoice > Confirm > Back to original subscription - Upsell > Lines have the same discount The lines should have the same discount disparity as they did on the original SO, this is even more important when the upsell is made in between periods as the product prices are also prorated, which makes editing the discount manually a lot trickier. Currently both lines will take the first parent that matches the original order line without taking the discount into consideration. i.e a monthly recuring order upsold halfway through the month will already have a 50% discount (Because we only invoice half a period) which should be cumulative with the original line's discount. opw-4081350 Forward-Port-Of: odoo/enterprise#72192
This update corrects how AC and ACC payroll rules handle AVS (pension) policy changes in Swiss payroll processing. The rules now properly verify they're using amounts from the same policy version, and the code has been simplified since all calculations are now centralized in the ACSALARY rule. This ensures accurate payroll calculations when employees switch pension policies.
Original PR description
In the case of an AVS policy change, ac and acc rules do not verify that we are taking the previous amounts of the same policy, those rules are also from the previous version and can be simplified since all the computation is now done in the ACSALARY rule.
The asset modification wizard now automatically updates the residual value when you change the modification date, giving you a more accurate view of your asset's remaining value. The system also intelligently shows or hides gain/loss account information based on whether there's actually a gain or loss to record, making the interface cleaner and less confusing.
Original PR description
When the date in the modify wizard for assets is changed, the residual_value should be updated to give a better view to the user. As this value is changed, the tests had to be changed accordingly. The gain or loss account is now correctly adapted from the computed value (itself computed on the date) and the Asset Counterpart Account is hidden if there is no gain. task-3981380 Forward-Port-Of: odoo/enterprise#70277
When users set up a new foreign VAT fiscal position, the system now automatically creates a draft tax closing move. This prevents a locking issue where the tax lock date would be set prematurely, blocking users from adding invoices to the new foreign closing position. This fix ensures smoother tax position setup and prevents workflow interruptions.
Original PR description
Before this fix, when setting up a new foreign VAT fiscal position, no corresponding draft closing move was created. Because of that, if nothing was made to generate it in the meantime, when the user posted the last of the other draft closing moves, the tax lock date was set, forbidding adding new invoices for the new foreign closing, even though it wasn't posted yet. Though corner cases are still possible, we alleviate that by automatically generating the draft move when the user creates a new foreign VAT fiscal position.
Fixed an issue where XML invoice documents were not being synchronized to the Documents workspace when using Belgian company setup with BIS Billing 3.0. When sending invoices with both PDF and XML attachments, only the PDF was appearing in the workspace. The fix ensures XML files are properly linked during the document creation process.
Original PR description
With a BE Company Setup Go to Documents > Configuration > Settings - Enable Accounting (Centralize accounting files and documents) - Open Journals and synchronize the Customer Invoices journal with a workspace Create an invoice Click Send&Print - Check "BIS Billing 3.0" - Send the message, the invoice will now have 2 attachments: pdf and xml Check the documents workspace Issue: Only the pdf is present This occurs because of the conditions needed to create the document. When we send the message we create the attachment but the move does not have attachment_ids set yet, so we fail to assign the first one. In this phase we just need to link the xml as the pdf will be registered when assigned as main attachment of the move opw-4088910
This fix ensures that when customers change product variants on a rental product page, the system properly checks and displays availability information for the selected variant. Previously, availability was not being updated, which could allow customers to attempt renting unavailable items without warning.
Original PR description
Problem: When changing a variant in the rental product page, the availability is not updated because the `/rental/product/availabilities` endpoint is not called. This results in situations where users can attempt to rent unavailable variants without being warned. Steps to reproduce: - Create a rental product with two variants. - Try to rent the second variant when it is unavailable. - The `/rental/product/availabilities` endpoint is not called, so availabilities are not updated, and no warning is displayed. opw-4130172
This fix resolves a display issue where the Time Spent column was incorrectly hidden in the task list view when both timesheet and document management features are enabled. The fix ensures that only the cell content is hidden for projects without timesheets enabled, rather than hiding the entire cell, which was causing misalignment of other columns in the task list.
Original PR description
Before this commit, when `hr_timesheet` and `documents_project` modules are installed, the project variable created in the template defined `documents_project` will erase the `project` given by the…
Before this commit, when `hr_timesheet` and `documents_project` modules are installed, the project variable created in the template defined `documents_project` will erase the `project` given by the controller route if the user goes to the portal list view of tasks via a specific project, that is, in the route `/my/projects/<id of the project selected>`. And so, some unexpected behavior could happen in `/my/tasks` since it will not be expected to have a project variable set in that route. This commit makes sure the variable created in `documents_project` will only be used inside that template and not beeing used in other override of that template in other modules (such as the one in `hr_timesheet`). Steps to reproduce the issue ============================ 1. Install `hr_timesheet` and `documents_project` modules 2. Go to `Project > Configuration > Projects` 3. Disable the timesheets feature on the first project. 4. Go to `/my/tasks` (portal list view of all tasks) Actual Behavior --------------- The cell containing the Time Spent of each task is hidden, causing a wrong alignment for the next cells in the same row. Moreover, the cell will be hidden even for the tasks with the timesheets feature enabled. Expected Behavior ----------------- The content of the cell containing the Time Spent of each task with the timesheets feature disabled should be hidden instead of the cell itself to avoid breaking the alignment of the next cells in the row. task-4259996
This fix resolves an issue where changes to Display URL and Keyboard layout settings on IoT devices were not being saved when editing the device from the IoT box form. The problem occurred because the device form was opening in a dialog box instead of a full page view. The fix ensures the device form opens in full page view so all changes are properly synchronized to the IoT box.
Original PR description
Due to a quirk in the JS framework, when a device form view is opened from the IoT box form view, it opens in a dialog box where it's `js_class` is not run. This causes updates to Display URL and Keyboard layout not to sync to the IoT box. This PR works around the issue by forcing the full device form view to open, rather than the dialog box. task-4141053
This fix resolves an issue in the Uruguay electronic invoicing system where invoices that were corrected and reposted after errors were being assigned incorrect document numbers. Previously, Odoo would use the next sequential number instead of a generic placeholder, preventing Uruware from assigning the correct official number. Now, when an invoice is reposted after correction, it receives a generic format that allows Uruware to properly assign the official sequence number.
Original PR description
### Description of the Issue: This PR resolves a bug in the invoicing process l10n_uy_edi where the document number needs to be set to a generic format (*ID) when reposting an invoice after…
### Description of the Issue: This PR resolves a bug in the invoicing process l10n_uy_edi where the document number needs to be set to a generic format (*ID) when reposting an invoice after correcting errors (reset to draft). Previously, when an invoice was reset to draft due to errors and reposted, Odoo would incorrectly rename the invoice based on the last posted invoice. This is not correct, since the name should come from Uruware based on the CAEs uploaded in their system. ### Steps to Reproduce: 1. Install l10n_uy_edi and configure the connection with Uruware. 2. Create and post an e-Invoice, retrieving a valid sequence from Uruware (e.g., e-FC A0000195). 3. Create a new invoice, force an error (e.g., add a negative line), and post it. 4. Reset the invoice to draft (the name should be removed and changed to "/"). 5. Correct the error and repost the invoice ### Current Behavior Before PR: The invoice is been named with (e-FC A0000196 - last posted invoice +1) and this is wrong. When an invoice with errors is reset to draft and reposted, Odoo assigns the document name based on the previous posting, instead of leaving it in a generic state to be updated by Uruware upon resubmission. ### Desired Behavior After PR: The invoice is named with the generic name (*ID). When reposting an invoice after resetting it to draft, the document number will be set to a generic format (*ID). The invoice can then be resubmitted to Uruware, where it will receive the correct name, based on the next available sequence from the corresponding CAE. EXTRA: Send the invoice to Uruware to receive the correct name (prior to this PR, the last 2 steps would not function correctly). -- Reference ADHOC task 81644
This fix restores the ability for users to reset cancelled invoices back to draft status when working with global invoices in Mexico. Previously, after cancelling a CFDI (Mexican electronic invoice) within a global invoice, the reset option was hidden, preventing users from making corrections. Now users can properly modify these invoices after cancellation.
Original PR description
Before this fix, after cancelling a CFDI within a global invoice, the "reset to draft" option was not visible, preventing the user from modifying the invoice. Steps to reproduce: 1. Generate 2 invoices 2. Use the option to generate a global invoice (for any period) 3. Go to any of the individual invoices and cancel the CFDI 4. After the cancellation, the option to reset the invoice to draft is not available. With this fix, the "reset to draft" option will be available after cancelling a CFDI in a global invoice, allowing users to reset the invoice for further modifications.