Daily updates from Odoo
Wednesday, April 29, 2026
42 changes · master
New functionality added to Odoo
This update adds quick access buttons to payslips, making it easier for users to view and edit employee time entries and attendance records. Previously, accessing these records was more complex, especially when the payslip wasn't part of a payrun. The change also removes an unnecessary field setting.
Original PR description
Currently, if the payslip is not in a payrun, it is harder to reach a screen to edit time entries. This PR adds/adjusts stat buttons on the payslip form to facilitate access to time off and attendances of payslip's employee. Also removing the admin group form the `attendance_based` field as it is not needed. task-6110624
Enhancements to existing features
This update enhances the Sales Order Gantt chart by displaying the commercial partner's name alongside the order number. Previously, users could only see the order number, making it difficult to quickly identify the customer associated with each Sales Order group. This change improves clarity and efficiency when reviewing sales planning.
Original PR description
Before this PR --- - When grouping Planning Gantt by Sales Order, only the order number was displayed, making it hard to identify which customer an order belongs to After this PR --- - Sales Order groups display the commercial partner name alongside the order number (e.g. "S00027 - Acme Corporation") for better identification task - 5140117
This update implements changes required by a new Vietnamese tax regulation (Decree 175/2025) regarding VAT rates on specific goods and services. It allows businesses to generate and export Appendix 142 reports, which are necessary for declaring transactions with the reduced 8% VAT rate. Certain businesses are exempt from submitting this report based on specific invoice criteria.
Original PR description
According to Decree 175/2025/NĐ-CP, an decrease of 2% will be applied to a certain goods and services which has 10% VAT rate (from 10% to 8%) and this will be effective until 12/2026 according to Decision 205/2025/QH15. This decision will be considered after that to decide if 8% VAT rate will be still applied. Appendix 142 report is meant to declare those operations and is only for Purchased and Sold goods with 8% VAT rate. For enterprises which satisfies these two following conditions don't have to submit Appendix 142: + Don't have both input and output invoices related to products & services with applied decreased tax rate (8%) + Only have input but not output invoices related to products & services with applied decreased tax rate (8%) We want to allow users to view and export form 01/GTGT and Appendix 142 with xml format from Odoo. task-5498205 Forward-Port-Of: odoo/enterprise#112572
This update removes unnecessary data from the internal data structures used in account reporting. This optimization improves the performance and efficiency of generating reports, particularly for large datasets. The change focuses on internal improvements within the account_reports module.
This update simplifies tax deductions for employees in India by allowing HR to select a tax deduction schedule (monthly, quarterly, etc.). The system now automatically calculates and displays TDS amounts correctly on tax declarations, ensuring accurate reporting and compliance. This change improves the user experience for HR and payroll teams.
Original PR description
- Added a `l10n_in_tds_schedule` field to the contract and template so HR can easily choose the tax deduction schedule (monthly, quarterly, half-yearly, last three months). - Updated the TDS formula in salary rules to deduct tax based on the chosen schedule, while keeping the tax declaration amounts evenly spread out. - Modified the Tax Declaration web view and PDF report to automatically show the correct label for the chosen schedule. task-4236978
This update simplifies the URLs used to access spreadsheets within Odoo Enterprise. The change replaces a lengthy `sheet_id` parameter with a shorter `sid` parameter, making the URLs easier to read and manage. This is a minor improvement focused on user experience.
Original PR description
Current behavior before PR: - The URL used the `sheet_id` parameter, which was unnecessarily long. Desired behavior after PR is merged: - Replace `sheet_id` with `sid` to make the URL more concise and readable. Task: [6171969](https://www.odoo.com/odoo/project.task/6171969) Forward-Port-Of: odoo/enterprise#115488
Resolved issues and error corrections
This update enhances the stability of WhatsApp tests by modernizing the testing framework. The team replaced an older, deprecated technology (Deferred) with a more current Promise-based approach, ensuring compatibility and reliability in future test runs. This change is part of a larger effort to maintain a robust and dependable Odoo Enterprise platform.
Original PR description
Replace Deferred with Promise.withResolvers in tests. [Part of task-5262203](https://www.odoo.com/odoo/1519/tasks/5262203) Community: https://github.com/odoo/odoo/pull/261739
This update corrects a reporting issue where payslips were incorrectly marked as 'paid' during the generation of payment reports. The change ensures that payslips are accurately reflected in reports, improving the reliability of payroll accounting data. This resolves a potential discrepancy in financial reporting.
Original PR description
…t generation Forward-Port-Of: odoo/enterprise#115273
This update fixes an issue where the BIK (Business Income Key) calculation for company cars wasn't accurately reflecting changes throughout the month. The system now correctly updates the BIK monthly based on the employee's car usage, ensuring accurate payroll calculations and compliance. This impacts the 'l10n_be_hr_payroll_fleet' module.
Original PR description
**Description of the issue/feature this PR addresses:** When there is a change of car during a month, the employee will have 2 versions but all will be merged on the same payslips but currently only the BIK of one version is taken into account (or no BIK if the employee has no company car anymore) **Current behavior before PR:** . car_atn value equal the yearly_atn / 12 . ATN.CAR rule returns the car_atn value of the first version **Desired behavior after PR is merged:** . Update the car_atn value to be computed monthly, based on the number of calendar days in the current month . Update ATN.CAR payslip rule, it get the value of the car's atn on the current payslip month then prorated based on the versions periods within the payslip period . Modify the corresponding tests . Add corresponding tests task-6108696 Forward-Port-Of: odoo/enterprise#115022 Forward-Port-Of: odoo/enterprise#113484
This update corrects a potential error in the account reports module where custom modules could cause conflicts with standard 'state' fields. The fix ensures that column references are clearly defined, preventing ambiguous column errors during report generation and improving data accuracy.
Original PR description
Issue: ------- There are cases where clients might have the same named 'state' field/column for custom modules in the models 'res.partner' or 'account.fiscal.position' and therefore they might get conflicted with the standard one's when the below query executes, https://github.com/odoo/enterprise/pull/84391/changes#diff-2f90e40d6e7b35681a4af03037e8e5ee0fddab2ba0876d9f148bf79786a91c29R1359 and can cause ``` File "/home/odoo/src/enterprise/account_reports/models/account_return.py", line 2204, in _check_suite_common_vat_report self.env.cr.execute(SQL( File "/home/odoo/src/odoo/odoo/sql_db.py", line 433, in execute self._obj.execute(query, params) psycopg2.errors.AmbiguousColumn: column reference "state" is ambiguous LINE 9: state = 'posted' ``` Solution: ------------ Use the corresponding alias while mentioning the column i.e; `move.state = 'posted'` OPW - 6044665 Forward-Port-Of: odoo/enterprise#114341
A minor technical issue was resolved where the wrong function was being used within the VoIP sales module. This fix ensures the system functions correctly and prevents potential errors in call processing. The change is considered low impact.
Original PR description
Shh! We used the wrong function. Forward-Port-Of: odoo/enterprise#114869
A recent update caused a crash when viewing customer previews after signing a Field Service worksheet. This fix corrects a misapplication of a previous patch that was adding unnecessary base64 encoding to signature data. By removing this encoding, the customer preview now functions correctly.
Original PR description
Steps to reproduce: - 1. Install 'planning_field_service_worksheet'. 2. Open a Field Service planning slot, pick a worksheet template that has a signature property, and sign it. 3. From the slot, open the customer preview (portal page). Issue: - The customer preview crashes with a traceback. Cause: - Commit https://github.com/odoo-dev/enterprise/commit/b6997ed6f9a8fc29233e1d324e91bbda7eae4df2 added .to_base64() on prop['value'] to follow the same pattern as: https://github.com/odoo-dev/odoo/commit/c62d1cec96498f424c42aee87b1428a4615d576c , which fixed real Binary/Image fields that returns BinaryValue objects. That patch was misapplied here. The signature value in this template does not come from a Binary field, it comes from a Properties field, so signature data is already stored as a base64 encoded str. Fix: - Drop the .to_base64() call and embed prop['value'] directly, since it is already a base64 string. task-6157798 Forward-Port-Of: odoo/enterprise#115231
This update ensures vehicle license plates are included in invoice exports only when the Enterprise module (`account_accountant_fleet`) is active. It also resolves a bug related to tax calculations, preventing incorrect line splitting. This improves data consistency across different Odoo versions and database types.
Original PR description
[FIX] account_accountant_fleet: vehicle sent in XML when an invoice line has a vehicle linked, the vehicle license plate will be in the export XML file only if the enterprise module `account_accountant_fleet` is installed. Any community db will then not have the ref included This commit moves the vehicle data in `account_fleet` to expose it to community dbs Also fix a bug when expense is installed: super was not called in a method about tax lines, causing side effects (splitting repartition lines when it shouldn't) runbot-242562 Forward-Port-Of: odoo/enterprise#114902
This update resolves a minor issue in the account reports module by correcting a sign error for the CTA value. The changes involve simplifying queries and functions within the module to improve efficiency and stability. This ensures accurate reporting data.
Original PR description
Followup PR of odoo/enterprise#103529 * Simplification of some queries * Simplification of functions * Sign correction for cta value Forward-Port-Of: odoo/enterprise#114338
This update simplifies the setup of financial accounts for Sri Lankan businesses by reducing the complexity of account codes. New lines for equity and liabilities have been added to the Balance Sheet report, providing a more complete financial picture. This change enhances flexibility and accuracy in reporting.
Original PR description
Reduces Balance Sheet account code formulas from 3-digit to 2-digit prefixes to make the COA setup more flexible. New equity and liability lines are also added to the Balance Sheet. Community PR: https://github.com/odoo/odoo/pull/260920 task-6141758 Forward-Port-Of: odoo/enterprise#115340 Forward-Port-Of: odoo/enterprise#114768
This update ensures that when a company is quickly created through the equity module, the system correctly identifies it as a company. Previously, this wasn't happening, leading to incorrect data. Additionally, a minor typo was corrected in the user interface for improved clarity.
Original PR description
The partner_id field on all equity models represents a company. Therefore, quick-creating a partner_id should create it with is_company set to True. However, that wasn't the case. This commit fixes this issue by making sure that partner_id when quick-created in equity models has is_company set to True. It also fixes a typo in the string attribute of valuation list and form views. task-6132343 Forward-Port-Of: odoo/enterprise#114375
This update fixes a critical issue where IoT events were missed due to a failure in the longpolling fallback mechanism. Now, if longpolling fails, the system automatically switches to using the more reliable WebSocket connection, preventing disruptions like failed Worldline payment confirmations. This ensures consistent event delivery.
Original PR description
Community PR: https://github.com/odoo/odoo/pull/260931 Before this commit, if `onMessage` in `iot_http_service` was called directly, it would fail to fallback to websocket if the longpolling request failed, causing events to be missed. One symptom of this is Worldline payments failing to confirm when using websocket. After this commit, the `_longpolling` method will now throw an error in this case, causing the fallback mechanism to attempt websocket instead. Forward-Port-Of: odoo/enterprise#115277 Forward-Port-Of: odoo/enterprise#114779
This update resolves an issue where the SBR tax report wizard would crash if an SBR certificate wasn't configured. The change ensures the wizard gracefully handles missing certificates, guiding users to the correct settings and preventing errors. This improves report generation reliability for users in the Netherlands.
Original PR description
In the SBR tax report wizard, the code previously attempted to access the `pem_certificate` attribute on a potentially empty recordset if no certificate was configured (see [here](https://github.com/odoo-dev/enterprise/commit/0b50021bdae54779396d75d3cddbd9eb42571553)). This resulted in an AttributeError before the validation check could trigger the intended RedirectWarning. This commit fixes the logic by: * Checking for the existence of the `cert_sudo` recordset immediately after retrieval. * Raising the RedirectWarning if the certificate record is missing, guiding the user to the Accounting Settings. * Accessing the certificate and private key content only after confirming the record exists. no-task Forward-Port-Of: odoo/enterprise#115489
This update resolves an issue where the vendor invoice fetching cron job in multi-company Odoo environments was failing due to incorrect company settings. The fix ensures invoices are retrieved from the correct company associated with each move, preventing errors and improving data accuracy.
Original PR description
In a multi-company context, the cron might be run with a user having a default company that is not the same as the target moves companies, maybe raising a `RedirectionWarning` (if the current company is not fully set-up). This commit ensure to fetch the invoice in move's target company. opw-5225553 Forward-Port-Of: odoo/enterprise#115350 Forward-Port-Of: odoo/enterprise#113254
This update fixes a problem where payment reminder emails for subscriptions were missing the subscription's closing date. The fix ensures that all payment reminder emails, regardless of how they're sent (automatically or manually), accurately display the subscription's end date. This improves the clarity and accuracy of payment notifications.
Original PR description
### Issue before this commit: When sending a payment reminder email for a subscription using the email composer, the template was not correctly populated with the expected dynamic values. In…
### Issue before this commit: When sending a payment reminder email for a subscription using the email composer, the template was not correctly populated with the expected dynamic values. In particular, fields such as the subscription closing date and the subscription code were missing. ### Steps to reproduce the issue: 1. Install subscription and go to that app 2. Open one subscription 3. Send message > Load template: "Subscription: Payment Reminder" 4. Sentence is incomplete: missing end date of the subscription ### Cause of the issue: The issue was caused by the absence of a proper context injection when rendering the email template from the mail.compose.message wizard. The template relied on context variables like date_close, but these values were not being computed nor passed during manual email composition. Unlike automated flows, the composer did not provide the subscription-specific context required by the template. ### Reason to introduce the fix: The fix makes the payment reminder and closing templates self-sufficient by replacing context-based values with fields and helper methods directly available on the subscription record. A dedicated method is introduced to compute the subscription close date consistently, so the templates render the expected values both in automated flows and when manually loaded from the email composer. opw-6031613 Forward-Port-Of: odoo/enterprise#115164 Forward-Port-Of: odoo/enterprise#111801
The Profit & Loss report for French associations was displaying incorrect financial figures due to an error in the report formulas. This update fixes the issue by correcting the formulas in the report, ensuring accurate calculations of income and expenses for association accounting. This ensures financial reporting aligns with French accounting standards for associations.
Original PR description
### Issue: The Profit and Loss report for associations shows incorrect values with inverted signs, leading to wrong totals in the final computation ### Cause: In 19.1, a new fiscal localization package for associations as been added In the report `account_financial_report_l10n_fr_cdr_asso`, all formulas in the `Operating income (I)` section are incorrectly inverted The equivalent section in `account_financial_report_l10n_fr_cdr_column_2024` is correct, where accounts are properly inverted in the formulas ### Steps to reproduce: - Install `l10n_fr_reports` - Create and switch to a French company - In Accounting Settings, select the fiscal localization: `France - Associations accounting plan` - Create and confirm an invoice (any amount) - Open `Profit and Loss` and select `Profit and loss account for associations (FR)` Before the fix, the Operating Income (I) is negative opw-6117967 Forward-Port-Of: odoo/enterprise#114414
This update simplifies the returns process by removing the 'reviewed' state. Now, returns are automatically considered ready for submission once all required checks are complete, improving efficiency. This change reduces manual steps and speeds up the return workflow.
Original PR description
task-5266305
This update fixes several issues within the AI chat interface, primarily improving readability and preventing formatting errors. Specifically, the font size of headings was adjusted to better suit the chat channel size, and a bug causing random asterisks within AI responses was resolved. This ensures a cleaner and more accurate user experience.
Original PR description
- The font-size of h1/h2 headers is large given the small size of chat channels which makes it harder to read the rest of the text. So, the font-size of h1/h2 headers is reduced in ai chat channels. - This commit removes the double border at the bottom of tables and updates the table borders by using table-bordered bootstrap class instead of border. - This commit also fixes an error where markdown2 2.4.11 doesn't detect the boundaries of bold markup properly causing asterisks to appear randomly inside AI responses. For example, "The **dog**, the **cat** and the **rat**" becomes "The <strong>dog<em>*, the *</em>cat<em>* and the *</em>rat</strong>" where it should only use <strong>dog/cat/rat</strong> task-6109286 Forward-Port-Of: odoo/enterprise#114687 Forward-Port-Of: odoo/enterprise#114592
This update ensures that the AI chat window opens in full-screen mode when initiated from the system tray or command palette. Previously, the chat opened in the background, which was inconvenient. This change improves the user experience for interacting with the AI assistant.
Original PR description
Prior to this commit, when opening the chat with an agent from the systray button, the chat window was opened in the background. This commit fixes the issue by adding a call to `channel.open` which opens the chat when in full-screen mode. This commit also fixes an issue where the chat window wasn't properly opened when done from the command palette. task-5172978 Forward-Port-Of: odoo/enterprise#115165 Forward-Port-Of: odoo/enterprise#114598
This update fixes a bug where commission calculations were failing for recurring subscription orders. The issue stemmed from an empty currency rate table, which prevented the system from correctly applying commission rates. The fix adds a fallback rate, ensuring commissions are calculated accurately for all subscription orders, regardless of currency settings.
Original PR description
Steps to reproduce: 1- Installed sale_commission_subscription and accounting 2- Go to [Sales -> Commissions -> Commission Plans] 3- Create a new commission plan of type MRR, specify a salesperson and approve 4- Go to Subscriptions app and create a new order with a recurring monthly plan and specify the same salesperson 5- Create an invoice for the order and confirm it 6- Go back to the commission plan and click on the Commissions smart button Issue: Commissions show up as 0 Expected behavior: Should have the corresponding commission based on the rate specified Why this happens: The `res_currency_rate` table is empty by default and only gets populated if you are in a multi-currency environment and sync the rates in the settings or by manually making a currency rate entry. Since the commission calculation depends on this table, it results in 0 rows when joining the sub-query. opw-6108580 Forward-Port-Of: odoo/enterprise#114354
This update corrects a bug that was causing overtime work entries to incorrectly generate on previous days. The fix adjusts how work entries are calculated, considering employee timezones to ensure accurate date comparisons and prevent incorrect overtime assignments. This ensures payroll calculations are reliable.
Original PR description
How to reproduce: - Select an employee with an overtime ruleset and work entries based on attendances - Create attendance with an approved overtime - Go to "Work Entries" in Payroll, and regenerate…
How to reproduce: - Select an employee with an overtime ruleset and work entries based on attendances - Create attendance with an approved overtime - Go to "Work Entries" in Payroll, and regenerate the work entries for the following day of the attendance - A new overtime work entry is generated on the first day. Reason: Because of how regenerating work entries is done, the computed date for searching overtime lines took into account the previous day (i.e. regenerating a work entry for a tuesday in an UTC+1 timezone made it so the starting date was on monday at 23:00:00), and since the _read_group only looked at the date part of the time start without taking into account the hour, it included the overtime of the previous day. How it was fixed: The domain now takes into account the timezone of the employee to generate the domain for the _read_group to ensure the correct day is selected Task ID: 5899657 Forward-Port-Of: odoo/enterprise#115289 Forward-Port-Of: odoo/enterprise#107266
This update ensures that Timesheet reports are only generated for invoices with service lines, not goods-only invoices. Previously, irrelevant reports were automatically created and attached, leading to wasted resources and potential confusion. This change improves efficiency and accuracy in invoice sending.
Original PR description
Before this PR: --- - When adding the Timesheets dynamic report to the "Invoice: Sending" email template, it was always included in the Send & Print wizard. - Even if the invoice contained only goods and no timesheet-based service lines, the Timesheets PDF was generated. - The wizard built attachment placeholders purely from the mail template configuration without validating invoice content. - As a result, irrelevant Timesheets PDFs were generated and attached to goods-only invoices. After this PR: --- - The Timesheets dynamic report is generated only when the invoice contains at least one timesheet-based service line. - For goods-only invoices, the Timesheets report does not appear in the Send & Print attachments widget. - The wizard now filters dynamic report placeholders based on actual invoice content. - Unnecessary Timesheets PDFs are no longer generated or sent. Related - https://github.com/odoo/odoo/pull/187381 task - 5361456
This update fixes an issue where leave calculations were incorrectly recomputed due to outdated employee version references. The change ensures that leave time-offs are calculated using the correct, active version of employee data, leading to more accurate and reliable leave balances. This improves the stability and accuracy of the payroll system.
Original PR description
The employee_type_id, job_id and structure_type_id fields on hr.leave were stored related fields pointing to current_version_id. This caused all time offs to be recomputed whenever the employee's current version changed, and stored the current version's values instead of those active at the time of the leave. task-6175086
This update addresses an issue where Coda transaction files sometimes lacked complete data, leading to default 'No description' labels appearing on bank statements. The change ensures accurate payment references by handling potential missing data from the Coda file, preventing incorrect statement line descriptions.
Original PR description
It can happens that coda file with transaction have no communication or structure communication. This can cause problem since we will have an empty payment_ref for the statement line. This will add "No description" as a default value. task-6045138 Forward-Port-Of: odoo/enterprise#111300
This update resolves two issues impacting manufacturing order management within the Barcode app. Previously, changes to the unit of measure and production quantity were not saved correctly, leading to inconsistencies. Now, these changes are reliably preserved, ensuring accurate production tracking.
Original PR description
### Issue Two bugs reported in the Barcode app / Manufacturing Order flow: **1. UoM change after confirm leaves MO inconsistent** Changing the UoM on a confirmed MO via the Barcode app does not…
### Issue Two bugs reported in the Barcode app / Manufacturing Order flow: **1. UoM change after confirm leaves MO inconsistent** Changing the UoM on a confirmed MO via the Barcode app does not recalculate `product_qty` / `qty_producing`. The backend locks the UoM after confirm — the Barcode view did not. **2. `qty_producing` reset on wizard open/close** Typing a value in `qty_producing` then opening the "Change Qty to Produce" widget (even closing without saving) caused the typed value to vanish. Root cause: the widget's `onClose` calls `env.model.load()`, which refetches from DB and discards any unsaved form edits. ### Fix - `product_uom_id` in the Barcode MO form is now readonly once `state != 'draft'`, matching the backend. - `openChangeQtyWizard` now saves the record before opening the wizard, so pending edits survive the reload. ### Steps to reproduce **UoM bug** 1. Create an MO, confirm it. 2. Open it in the Barcode app. 3. Try to change the UoM → it was editable (bug). **Qty reset bug** 1. Open a confirmed MO in the Barcode app, go to the header product page. 2. Type a value in `qty_producing` (e.g. `3`). 3. Click the `/ X` button next to it (opens the Change Qty wizard) then close it without clicking "Set Quantity". 4. `qty_producing` reverts to its previous value (bug). ### After the fix - UoM field is greyed out once the MO is confirmed. - Typed value in `qty_producing` is preserved after opening and closing the wizard. opw-5809178 Forward-Port-Of: odoo/enterprise#115254 Forward-Port-Of: odoo/enterprise#114075
This update fixes an error in how tax returns are calculated for companies with multiple branches. Previously, rounding adjustments were incorrectly applied, leading to inaccurate closing entries. The fix ensures that rounding is calculated correctly for each branch, resulting in accurate financial reporting.
Original PR description
Some countries lile Estonia, Nederlands or France apply a rounding from the tax report by adding a line to the end of the query results representing the sum of the roundings on each line of the tax…
Some countries lile Estonia, Nederlands or France apply a rounding from the tax report by adding a line to the end of the query results representing the sum of the roundings on each line of the tax report. When having a company with branches, the rounding is applying in each closing move (one per company/branch) but the value is coming from the aggregated report lines, this leads to wrong computation of the closing entries. Cause: In `_generate_tax_closing_entries` we loop over each company, therefore `_compute_tax_closing_entry` is called one time for each company, but it uses the report options containing all companies Fix: Use options with only the current company in `_compute_tax_closing_entry` Steps: - Install FR localisation - Select FR company and create two branches - Create, for last month: - 1 bill for parent company (100 with tax 20% G) - 1 invoice per branch (200 and 300 with tax 20% G) - Create a tax return with opining date at the beginning of the current month - Submit the last return and go to the created closing entries -> See that closing entries are wrong opw-5976359 Forward-Port-Of: odoo/enterprise#115116 Forward-Port-Of: odoo/enterprise#110652
This pull request addresses a problem with invoice testing related to rounding calculations in the l10n_mx_edi module. It reverts a previous change that introduced the issue and confirms the fix. This ensures accurate invoice generation and reporting for Mexican businesses using this module.
Original PR description
This reverts commit 50ad147e1f579a094141f6f126e02f75ecc62ab3. Forward-Port-Of: odoo/enterprise#115612
This update resolves a visual issue where the timesheet system tray overlapped with records when scrolling on smaller devices. The changes expand the timesheet grid and adjust its layout to prevent overlapping, ensuring a cleaner and more user-friendly experience for timesheet management.
Original PR description
Before: The systray overlaps the records when scrolling on small screens Changes: - Expands the record list to avoid scrolling overlaps - Make the timesheet list expand before the checkout button to ensure no overlap - Restrict the height of the timesheet list to avoid the double-scrolling problem --- task: 6115674 Forward-Port-Of: odoo/enterprise#114093
This update corrects a calculation error in the salary configurator. Previously, payslips were generated using outdated salary rules if the configuration was initiated on the contract start date. Now, payslips accurately reflect current salary rules, ensuring correct net pay calculations.
Original PR description
When the salary configurator is used, it generate a simulation payslip to know get a net value based on the gross. It should be done at the current date, because if it is at contract_start day, maybe years ago, it'll use wrong salary rules values to compute it Forward-Port-Of: odoo/enterprise#115319
This update fixes an issue where the system incorrectly flagged payruns as 'missed' reports due to delayed STP payment dates. The change now uses the payrun's creation date to accurately determine if a report needs to be submitted to the ATO, ensuring compliance and accurate reporting.
Original PR description
When a payslip is created after the submission of a previous payrun, it should trigger an update event to ensure the missed payslip is reported to the ATO with the totals, including all the slips already paid. It currently uses the submit date of STP to check if it's a missed report. However, sometimes the submit/payment date might be set in the future for a delayed payment of the payrun. In this case, the new payrun should not be considered as a missed payrun as it is still the correct order. This fix uses past payslip dates to check if a payrun is a missed report or not, instead of using the submit/payment date of STP. task-6134865 Forward-Port-Of: odoo/enterprise#114280
This update corrects a discrepancy in the automated tests for the Odoo Enterprise subscription module. The community branch now uses websocket communication instead of polling. The tests have been adjusted to reflect this change, ensuring accurate test results and maintaining the stability of the subscription functionality.
Original PR description
In community branch, polling was replaced by a websocket call Adjust tests to use that url instead of polling. task-4951436 See Also: https://github.com/odoo/odoo/pull/232112
This update enhances the accuracy of French tax reports (liasse) by completing XML data and fixing minor bugs. Specifically, it adds missing fields and tags to the reports, validates company data, and incorporates country information, ensuring more reliable data transmission to tax authorities. This improves compliance and reduces potential reporting errors.
Original PR description
This commit aims to make the xml that we send to aspone for the liasse fiscale is the more complete as possible and to correct some small bugs. - Add missing fields in the reports - Add missing tags in the xml - Add a data validation on company data before exporting the reports - Correct errors in the reports - Add country fields in the reports as many2one task-6128878 Forward-Port-Of: odoo/enterprise#114468
This update fixes a bug in the payroll calculation that previously failed to account for zero worked hours. Now, the system accurately computes full-time equivalent (FTE) figures, ensuring payroll reports and data are reliable. This improves the accuracy of employee time tracking and reporting.
Original PR description
Before this commit, the full-time equivalent compute was not taking into account the fact that the total worked hours could be 0. Forward-Port-Of: odoo/enterprise#115598
This update corrects a technical issue where styling applied to list views was incorrectly affecting other views within the account reports module. The fix ensures that styling is applied only to the intended list views, improving the visual consistency of the reporting interface. This resolves a minor cosmetic problem.
Original PR description
The css selector used to add the small border at the start of the line. So it end-up being applied in other view as well. task-6141685 Forward-Port-Of: odoo/enterprise#115568 Forward-Port-Of: odoo/enterprise#114903
This update resolves an issue where selling a main asset with a closed child asset resulted in incorrect accounting entries. The fix ensures that only active, non-closed assets are considered during the sale process, preventing double-entry errors and maintaining accurate fixed asset and depreciation calculations. A new test case confirms the resolution.
Original PR description
This commit fixes the double entries created when selling the main asset after disposing the child asset. Previously, the sale of the main asset with a closed child asset created 2 entries which resulted in wrong values in fixed asset, depreciation, and gain accounts. This commit filters the non-closed/non-cancelled assets, while previously it would try to close/sell all assets even if it was already closed/cancelled. Test case added to verify fix. opw-6018649 Forward-Port-Of: odoo/enterprise#115559 Forward-Port-Of: odoo/enterprise#115115
This update resolves an issue where the cumulated balance calculation in the general ledger was incorrect when using journal groups. The fix ensures that the balance is accurately computed regardless of whether all journals are selected, improving the reliability of financial reporting.
Original PR description
Usually the journal filters doesn't allow the selection of all journals when no journal group is present. However, when a journal group is added, the journal filters allow the selection of all the journal groups to be valid. So, we end up with a filter Journals, with all journals selected but the cumulated balance is not computed. To fix this, if all the journals are selected in the Journals filter, we dont add the journal_ids filter. Step to reproduce: - On any journal, create a journal group - Go to the general ledger - In the Journals filter select "Local Gapp" and the created journal group - Click the journal items button on the line of any account - The cumulated balance will be at 0 even when all the journals are selected. Forward-Port-Of: odoo/enterprise#112943
Code cleanup and technical improvements
This update ensures the HR payroll module seamlessly integrates with Odoo's Fleet module. The changes correct missing return statements, ensuring proper functionality across various HR payroll processes related to fleet employees. This improves accuracy and consistency in payroll calculations for employees associated with company vehicles.
Original PR description
task-6045425