Daily updates from Odoo
Wednesday, March 25, 2026
40 changes · master
New functionality added to Odoo
This update introduces a new module to support the processing of e-Resguardos documents, a key requirement for businesses operating in Uruguay. The changes address a previous bug related to automatic addenda calculation and include new unit tests for improved reliability. This ensures accurate accounting and compliance with local regulations.
This update enables businesses to formally cancel previously sent DTEs (Digital Tax Evasion) by sending an XML file to Infile. Users can initiate the cancellation process through a wizard, specifying the reason for the cancellation, which is then transmitted to the SAT (Mexican tax authority). This improves compliance and reduces potential penalties.
Original PR description
Allow users to void a sent DTE by sending an AnulacionDTE XML to Infile. Clicking "Request Cancel" on a sent invoice opens a wizard asking for the cancellation reason, which is then sent to SAT. task-5994798
Enhancements to existing features
This update adds a new system for calculating and managing professional tax deductions for employees in Russia. The change combines existing logic for LWF deductions and introduces flexible payment cycles (monthly, quarterly, etc.) to simplify tax processing and improve accuracy. This enhancement ensures compliance with Russian tax regulations.
Original PR description
[IMP] l10n_in_hr_payroll: professional tax deduction cycle
1 - New deduction cycle field is added for professional tax (monthly, quarterly, half_yearly, yearly)
1.1 - It is added form view of employee just below of Professional Tax in Tax Deductions
2 - There was a written logic for LWF deductions in the code already _l10n_in_apply_lwf.
2.1 - Since the logic was almost same, I combined both professional tax deduction and lwf tax deduction and made a small refactor.
task - 4978408This update improves the speed and reliability of refreshing social media data (Facebook and Instagram) by using batch API requests. It also ensures consistent engagement trend calculations across platforms, leading to more accurate reporting and a better user experience. The changes focus on efficiency and data accuracy.
Original PR description
Purpose ======= The Meta API supports batch requests: > https://developers.facebook.com/docs/graph-api/batch-requests This can reduce a lot the HTTP calls we make, and makes the module faster to…
Purpose ======= The Meta API supports batch requests: > https://developers.facebook.com/docs/graph-api/batch-requests This can reduce a lot the HTTP calls we make, and makes the module faster to refresh. We could have been way more aggressive in the optimization (eg, fetch the stats and the posts at the same time), but it will deteriorate the readability, so we just batched API calls in loop, and stuff like that. Time of a refresh for 6 Facebook pages and 1 Instagram page: <img width="881" height="71" alt="a" src="https://github.com/user-attachments/assets/ec319c4a-c51d-49b8-a6ab-3ee879cf63b4" /> After: <img width="886" height="103" alt="b" src="https://github.com/user-attachments/assets/0b707b72-f30f-4e00-a38c-614feea6e204" /> Use `total_interactions` instead of `reach` for the engagement trend of Instagram. Show the view and saved statistic for Instagram. Do misc UI improvement. Fix an inconsistency for the engagement trend computation between Facebook and Instagram. Task-4865381
This update simplifies the tracking of materials within MRP components by removing unnecessary packaging fields from the SML form. These fields were previously visible but are not used when components are consumed unpacked, preventing user confusion and ensuring data accuracy. This change improves the user experience and data integrity.
Original PR description
Hide the `Destination Package` and `Destination Container Package` fields in the SML form for MO components in the Barcode app, as they are always consumed unpacked. Keeping these fields visible can mislead users into entering information with no functional meaning. Community PR:- odoo/odoo#243072 TaskID-4068485
Resolved issues and error corrections
This update enhances the testing process for WhatsApp features within Odoo Enterprise. Specifically, it improves how the system verifies notifications sent through the bus, ensuring more reliable test results. This change contributes to overall product stability and quality.
Original PR description
Enterprise counter-part. task-4715511 https://github.com/odoo/odoo/pull/253083/
This update fixes an issue where users weren't receiving email notifications for signature requests, even when their notification preferences were set to 'inbox'. Now, all signature requests will trigger email alerts, ensuring signers are promptly informed. The change preserves in-app notifications for users who rely on them.
Original PR description
When a user's notification preference is set to "inbox", no email is sent, which may prevent signers from being notified of signature requests. This commit enforces sending email notifications for signature requests regardless of user notification settings. Notifications are still created in Odoo, preserving in-app visibility for users who rely on it. task-6041834 Forward-Port-Of: odoo/enterprise#111094
This update resolves a small, technical issue with a message displayed within the documents generated for employee payroll. The fix ensures consistent and accurate document formatting, improving the overall user experience. This change does not impact business processes or functionality.
Original PR description
Task#5980045 Forward-Port-Of: odoo/enterprise#109063
This update ensures that payroll moves with analytic distribution rules are correctly anonymized, protecting employee privacy. The fix addresses a previous issue where lines weren't merged properly, leading to unnecessary detail in financial reports. This enhancement improves data security and compliance.
Original PR description
The Batch Account Move Lines option in the settings is used to aggregate together the different payslips of a payrun and to create only one move with aggregated lines, per account. This is done to…
The Batch Account Move Lines option in the settings is used to aggregate together the different payslips of a payrun and to create only one move with aggregated lines, per account. This is done to enforce privacy and avoid having lines for each employee in the payrun. If salary rules with analytic distributions are involved, though, the lines are not merged and we lose the anonimity.
This happens because in the _get_existing_lines funciton, that should return the lines to be merged with the input line (line), the condition for the rules that have an analytic distribution is wrong.
In particular, the condition is wrong because the
distribution_analytic_account_ids field is a recordset of the accounts, while line_id['analytic_distribution'] is a dictionary with keys that are comma separated strings of the ids of the accounts, with values reflecting the percentage.
For example, if a rule has one analytic distribution for 40% and involving accounts 13,7 and 12 + another analytic distribution for 60% involving accounts 3 and 5, line_id['analytic_distribution'] will be {'13,7,12': 40.0, '3,5': 60.0} while distribution_analytic_etc will be a recordset containing (13,7,12,3,5). To fix the problem and keep everything inline, we extract the logic to a new function, where we first unravel the ids from the keys of the dictionary and only then try to match them to the values in the recordset.
Task: 6043957
Forward-Port-Of: odoo/enterprise#111705
Forward-Port-Of: odoo/enterprise#111140This update fixes an issue where salary deductions weren't being accurately calculated for certain payroll rules, specifically 'ATTACH_SALARY'. The changes ensure that these deductions are now correctly processed, leading to more precise net salary figures. This improves payroll accuracy and reporting.
Original PR description
**Behavior before this commit** Some salary rules (e.g. `ATTACH_SALARY`) were ignored in the NET calculation. **Behavior after this commit** - Four rules are now added to the "Total deductions" line: their sequence and category has been changed. - The sign of these lines has also been switched: an attachment of salary of a positive amount should be added to the amount of total deductions, which is then deducted from the net.  opw-5894647 Forward-Port-Of: odoo/enterprise#111080 Forward-Port-Of: odoo/enterprise#107033
This update enhances the performance of Odoo's email functionality by utilizing record rules for access control, leading to more efficient database queries. The changes also address a security improvement by replacing a custom access check method with a more robust record rule approach. This results in a more stable and secure email experience for enterprise users.
Original PR description
Update of query count. odoo/odoo#254381
This update resolves an issue where users were directed to the wrong document form view when configuring PEPPOL document syncing settings. The change adds a dedicated Kanban view for PEPPOL documents within the settings, ensuring users access the correct document management interface. This improves the user experience and streamlines the process of managing PEPPOL documents.
Original PR description
Before this commit: clicking through on the setting of configuring the folder to sync peppol documents would lead to the document form view instead of the kanban view. Task-6040802 Forward-Port-Of: odoo/enterprise#111765 Forward-Port-Of: odoo/enterprise#111341
This update resolves an issue where the AEAT tax report file was being rejected due to an incorrect date format. The fix ensures the file includes a default date ('00000000') when a procuration date isn't specified, meeting AEAT's requirements and allowing successful file uploads.
Original PR description
Steps to reproduce: - Install the `l10n_es_reports` module and switch to the `ES company`. - Go to Invoices and create an invoice with taxes, then confirm it. - Navigate to Accounting > Reporting >…
Steps to reproduce: - Install the `l10n_es_reports` module and switch to the `ES company`. - Go to Invoices and create an invoice with taxes, then confirm it. - Navigate to Accounting > Reporting > Tax Report. - From the smart button, select `Report: Tax Report (Mod 390) (ES)` and choose the year as `This Financial Year`. - Download the `BOE` file using the dropdown and fill the wizard fields (e.g., Natural Person – Name: Test, Principal activity: Test, Activity Code: 12345). - Upload the generated .txt file to the AEAT portal. (AEAT credentials are required) **Observation:** AEAT rejects the file with: `Caracteres no válidos '4. Representante - Personas Jurídicas - Represent. 1 - Fecha Poder (DDMMAAAA)'` **Root cause:** At [1], when `judicial_person_procuration_date` is `false`, an empty string is written to the BOE file, resulting in blank spaces in the exported file. This does not comply with AEAT’s required numeric format and causes the file to be rejected. **Fix:** This commit ensures the file contains '00000000' when `judicial_person_procuration_date` is false, complying with AEAT numeric format requirements. [1]: https://github.com/odoo/enterprise/blob/45d3a537c3b2eaccee425d959e89d26229e376cd/l10n_es_reports/models/aeat_tax_reports.py#L1696 opw-5995290 Forward-Port-Of: odoo/enterprise#109652
This update updates how Odoo retrieves configuration settings within the currency rate module. The change replaces an older method with the recommended approach, ensuring greater stability and compatibility with future Odoo versions. This improves the reliability of the currency rate calculations.
Original PR description
https://github.com/odoo/odoo/pull/223180 removes the `get_param` method from `res.config_parameter`, which was used in the `currency_rate_live` module. This commit replaces it with the `get_str` method, which is the recommended way to retrieve configuration parameters in Odoo. No task ID Forward-Port-Of: odoo/enterprise#110975
This update fixes an issue where subscription quotations weren't displaying correctly in the customer portal. Recent changes caused orders to be incorrectly directed to a general subscription page. Now, draft and sent subscription orders will correctly redirect users to their specific order details page, ensuring a smoother user experience.
Original PR description
Version: - saas~19.2 Steps to reproduce: - Create a subscription quotation. - Open it from the portal. Issue: - The portal view of the subscription quotation is not displayed correctly. Cause: - After recent changes, subscription orders were always redirected to `/my/subscriptions/` route. - This route renders the `subscription_portal_template`, which is not suitable when the order is still in draft or sent state. Solution: - If the subscription order is in draft or sent state, redirect the user to `/my/orders/<order_id>` instead. task-5966871 Forward-Port-Of: odoo/enterprise#108509
This update resolves issues where overtime calculations were incorrect due to timezone discrepancies, specifically impacting employees in UTC+ timezones. The fix ensures accurate overtime interval determination and prevents crashes related to overlapping attendances, while also correctly deleting stale overtime lines.
Original PR description
Steps to reproduce (singleton crash): Create an employee in a UTC+ timezone (e.g. Asia/Shanghai or Australia/Adelaide) with an overtime ruleset containing a paid rule. Generate work entries for a…
Steps to reproduce (singleton crash): Create an employee in a UTC+ timezone (e.g. Asia/Shanghai or Australia/Adelaide) with an overtime ruleset containing a paid rule. Generate work entries for a period, then create two consecutive midnight-to-midnight attendances in the employee's local timezone. Creating the second attendance crashes with: "ValueError: Expected singleton: hr.attendance.overtime.line(...)". Steps to reproduce (stale overtime lines): With the same setup, delete the attendance after it generated overtime lines. The overtime lines remain in the database instead of being removed. The singleton crash occurred because `end_of_day` in `_get_overtime_intervals` was computed as a naive datetime, implicitly treated as UTC. For UTC+ timezones, the actual local end of day is earlier than UTC midnight. As a result, overtime intervals were computed with a stop time extending past the real local midnight into UTC time. When consecutive attendances were processed together, these extended intervals overlapped. The `Intervals` class (`keep_distinct=True`) merges overlapping intervals into a single entry with a multi-record recordset as payload. The subsequent `overtime.rule_ids.work_entry_type_id` and `overtime.status` calls expected a singleton but received a multi-record set, causing the crash. The same multi-record issue also affected the iteration in `_set_real_overtime_intervals` and the overtime work entry loop in `_get_attendance_intervals`. The stale overtime lines issue occurred because `_get_overtimes_to_update_domain` (hr_attendance) built its search date range from raw UTC `.date()` values instead of the employee's local timezone. For UTC+ employees whose attendance spans local midnight, the overtime line is dated in the next local calendar day. Since the domain was derived from UTC dates, that next local day fell outside the search range, so the overtime line was never found and deleted when the attendance was removed. Solution: - In `_get_overtime_intervals`, localize `end_of_day` to the employee's timezone before converting to UTC, so overtime intervals are correctly bounded by the local end of day. - In `_set_real_overtime_intervals` and the overtime loop in `_get_attendance_intervals`, iterate over individual records from potentially multi-record `Intervals` payloads to avoid singleton errors. - In `_get_overtimes_to_update_domain` (hr_attendance), localize check_in/check_out to the employee's timezone before computing the date range so overtime lines for dates that only exist in local time are correctly included in the delete-and-recreate cycle. opw-5931665 Forward-Port-Of: odoo/enterprise#111684 Forward-Port-Of: odoo/enterprise#109419
This update resolves a bug where the 'documents' button on employee records incorrectly redirected users to the wrong domain, preventing them from accessing their documents. The fix ensures users are directed to the correct domain based on their login location, improving document access for all users.
Original PR description
Steps to reproduce:
- Have two domains for your database (".odoo.com" and ".example.com")
- set the ".example.com" domain as your web base url
- login on the ".odoo.com" domain, go on an employee and click the documents smart button
-> you cannot see any documents because you are redirected on the ".example.com" domain on which you are not connected
opw-5857914
Forward-Port-Of: odoo/enterprise#110390
Forward-Port-Of: odoo/enterprise#107384This update resolves an issue where documents uploaded to the 'All' folder in the Documents app were not viewable through the bridge interface. The fix ensures that uploads to 'All' now default to the standard bridge folder, restoring full accessibility for users.
Original PR description
Problem: When a user uploads a document through a bridge to the Documents app, if the destination is set to the `All` folder, the file becomes unviewable from the bridge. It can only be accessed directly via the Documents app. Cause: This occurs because `All` is not an actual folder. Uploads directed to it default to the `My Drive` folder instead. Because `My Drive` is restricted and inaccessible via the bridge, the uploaded documents remain hidden. Solution: To solve this problem, this PR ensures that uploads directed to the `All` folder default to the default bridge folder rather than to `My Drive`. task-6023290 Forward-Port-Of: odoo/enterprise#111715 Forward-Port-Of: odoo/enterprise#111290
This update resolves two critical bugs preventing new employee creation in the Belgian payroll module. The first issue involved duplicate record creation due to a mail activity trigger. The second bug occurred when the payroll system attempted to link to a non-existent record before it was fully saved. These fixes ensure proper employee setup and data integrity.
Original PR description
First bug: Steps: - Switch to belgian company - Create new employee - Set contract start date - Click save manually -> boom Cause: in _trigger_l10n_be_next_activities, we create a new mail activity for the created employee which is already created in the default create function leading to duplicate follower records. Fix: in the super.create, pass the context variable mail_create_nosubscribe=True to disable adding the current user as a follower again to the same record Second bug: Steps: - Switch to belgian company - Create new employee - Set contract date - Add a wage then click anywhere -> boom Cause: _trigger_l10n_be_next_activities is called before the record is saved, hence trying to link to a null object Fix: check if the record is created before working on the activities Forward-Port-Of: odoo/enterprise#111780 Forward-Port-Of: odoo/enterprise#109799
This update fixes an issue where currency rates for Bulgaria were incorrectly calculated after the country switched to the Euro. The system was using reversed rates from the XML data, leading to inaccurate unit conversions. This change ensures correct currency calculations are used for Bulgarian transactions.
Original PR description
Issue: after Bulgaria switched to EUR, currency rate fetching from BNB was incorrectly set to still use reversed currency rates from the fetched XML, resulting in unit-to-EUR and EUR-to-unit rates being flipped in the database. Solution: adjusting the parser to get rate from 'RATE' rather than 'REVERSERATE', as the XML provides both. task-6050519 Forward-Port-Of: odoo/enterprise#111753 Forward-Port-Of: odoo/enterprise#111275
This update resolves a technical error that prevented users from completing the checkout process within the Enterprise module. The issue stemmed from an outdated reference to a property name, which has now been corrected. This ensures a smoother and more reliable user experience.
Original PR description
Steps to reproduce: - In the home menu of a database, click on the ActivityMenu at top of page (red dot) - Click check in - Click ActivityMenu (green dot) again and click check out Current behavior: - Traceback saying this.displayAllowBillable is not a function Expected behavior: - No error Note: displayAllowBillable was renamed to displayIsBillable in this commit https://github.com/odoo/enterprise/pull/110708 opw-6061392 Forward-Port-Of: odoo/enterprise#111850
This update resolves a warning appearing in the Time Off popup within the Odoo Enterprise demo payroll module. The change removes unnecessary data dependencies, allowing the system to automatically calculate time off balances correctly. This ensures accurate reporting and a smoother user experience for payroll administrators.
Original PR description
. Remove payslip_state for hr.leave(178) to be automatically computed . Add corresponding tests task-6044925
This update resolves a technical issue that was preventing updates to the AI module. The fix ensures the system correctly verifies changes to the AI model, preventing crashes and allowing updates to proceed smoothly. This improves the stability and reliability of the AI functionality.
Original PR description
Prior to this commit one could not run the update of `ai` module because of a constraint on the write method which would cause it to crash. The constraint checked for modification to the `llm_model` without checking that the model was actually different from the original model assigned to the image generation agent. With this commit, we add a condition to check that the `llm_model` in the values is different form the one currently assigned to the image generation agent.
This update removes a specific exception (JC 999) from minimum wage checks within the Odoo Enterprise Belgian payroll module. This change ensures more accurate compliance with Belgian labor laws and avoids potential warnings for employees classified as JC 999. Associated tests have been added to verify the updated functionality.
Original PR description
. Exclude JC 999 from minimum wage checks in both versions and offer versions . Add corresponding tests task-6055486
This update restores the appointment synchronization onboarding banners, which guide staff users to connect their Google and Microsoft calendars. These banners also display a warning for users with Google Meet set up on appointments, ensuring correct meeting links are added.
Original PR description
: appointment{_google,_microsoft}_calendar This is a revert commit of [1] reintroducing the appointment_microsoft_calendar module, as we bring back the synchronization onboarding banners on the…
: appointment{_google,_microsoft}_calendar
This is a revert commit of [1] reintroducing the
appointment_microsoft_calendar module, as we bring back the
synchronization onboarding banners on the appointment.type
form view that were removed in [1]
- A banner includes a shorcut to setup / connect google /
outlook external calendars as well as an informative message.
- A banner is a warning banner on staff users without
active synchronization in the case of google_meet set up
on the appointment, as those will not have a google_meet
link correctly added to their meetings.
Note: as the original commit removed the whole module
appointment_microsoft_calendar, the revert would also
reintroduce i18n files. To allow a clean module reintroduction,
we do not keep them in this revert commit.
In a separate commit, reintroduce the helper for the field
event_videocall_location.
[1] https://github.com/odoo/enterprise/commit/c64e3435db792508ecec0b25dd25dc6e9360fc63.
Task-5969306This update prevents partner address changes from erasing previously stored location coordinates. This ensures automatic lead assignments continue to function correctly and avoids disruptions for partners relying on their existing geolocation data. Users can still manually update coordinates if needed.
Original PR description
Previously, updating a partner address reset latitude and longitude to 0.0. This removed existing coordinates and could prevent automatic lead assignment. With this change, coordinates are preserved when the address is modified. This avoids losing existing coordinates and allows partners to continue receiving leads based on their stored geolocation. Users can still manually refresh the geolocation if updated coordinates are required. Task-4812621
This update fixes an issue where payroll attendance calculations were incorrectly high when public holidays were present. The change ensures accurate attendance amounts by properly accounting for public holiday hours, preventing inflated attendance figures.
Original PR description
Fixes the calculation of the worked day lines amount, in cases where a public holiday is set. The current computation doesn't account for hours of public holiday when calculating the attendance amount; causing it to be higher than expected. This is caused by the calculation of work_time, which comes from the calendar data from _work_intervals_batch. If there is a public holiday, the work interval for that day is being removed from the result, causing it to wrongly calculate a lower work_time than expected and increasing the attendance line amount. task-5979501 Forward-Port-Of: odoo/enterprise#111819 Forward-Port-Of: odoo/enterprise#111741
A recent update to Odoo Enterprise prevented the deletion of automatically created approval rules within the Studio module. This issue arose during an upgrade from version 18.0 to 19.0 and resulted in data inconsistencies. The fix ensures these rules are created with a safeguard to prevent accidental deletion.
Original PR description
Server and automated actions created by the ORM for the purpose of revoking approval rights are created without `noupdate=True` which leads to said records being removed by the ORM becuase of not being found in the source. Such records created on the fly should have `noupdate=True` to prevent that from happening. This bug can be reproduced by going to Settings > Technical > User Interface > Studio Approval Rules and creating a new record from there and updating `web_studio`. The update will drop the record from the database. Issue originally detected in the upgrade process from 18.0 to 19.0. This fix will be complemented by an upgrade script that fixes erronous records. Forward-Port-Of: odoo/enterprise#110065
This update removes a previous restriction that prevented users from adjusting production quantities on work orders when quality checks were marked as complete. Now, changes to the work order quantity automatically update related quality checks, streamlining the production process and eliminating a potential bottleneck. This improves efficiency and accuracy in managing work orders.
Original PR description
Initially users were blocked from splitting or updating quantity to produce if we have quality check points marked as complete as an old limitation in odoo/enterprise#5193, That doesn't exist anymore. Now when the quantity is updated in MO its also updated for quality checks in shopfloor. Task: 5438445
This update fixes an issue where project budget totals were incorrectly summing expenses and revenue. The fix adjusts how the system calculates totals, ensuring accurate reporting of project spending and allocated funds. This improves the reliability of project financial data.
Original PR description
### Steps to reproduce: - Create a billable project - Create two budgets one expense and the other revenue or both each for 100$ - Create a vendor bill with the analytic account of the created project - Notice in the project dashboard the two budgets are summed up in the total ### Cause: When calculating the total spent and total allocated we add up the amount whether it is an expense or revenue. https://github.com/odoo/enterprise/blob/1dccb87a48ac44735da4c78594e37d4783789cd6/project_account_budget/models/project.py#L120-L121 ### Fix: Set the expense budget to -ve and the revenue/both to +ve amount when calculating the total spent and total allocated opw-5488131 Forward-Port-Of: odoo/enterprise#106504
This update enhances payroll processing, particularly for employees with changing contracts during a pay period. The system now intelligently adjusts calculations to prevent overpayment of contributions and allowances, ensuring accurate payroll processing, especially in Hong Kong.
Original PR description
This commit aims to provide better support for contract changes that happen in the middle of a pay period. It has a few impacting changes, notably: 1) Payslip calculation sequencing As of now, all…
This commit aims to provide better support for contract changes that happen in the middle of a pay period. It has a few impacting changes, notably: 1) Payslip calculation sequencing As of now, all payslips of a same payrun have their line calculated all at once. While this is better for performances, it has a negative effect when a single employee has multiple payslips in the same payrun. In such cases, we may want or need for the payslips to know what was already calculated in the same payrun to avoid overpaying contributions or allowances that have caps. To solve this issue, we now group payslips by employee, sort them chronologically, and evaluate them in horizontal "layers": - Layer 1: Computes the 1st payslip for ALL employees simultaneously. - Layer 2: Computes the 2nd payslip for the subset of employees who have one, etc 2) More tools in HK payroll to support these cases The payslip rules now have a `l10n_hk_payrun_totals` dict that contains the total amount already reported in previous payslips of a same payruns for a selection of rules that needs it. We also provides a `worked_days_prorata_rate` which gives the ratio of worked days vs unworked days in a month for cases where we need to adjust amounts based on that ratio. 3) Rule updates The last part of the fix requires some updates in a few rules that are fixed amounts/not based on the wage and ends up being counted double in our use case. These rules will now take into account already computed amounts as said above to avoid going over the limit. In most cases it will only affect that specific use case, with a small exception for fixed mpf voluntary contributions, which have been updated to be prorated based on the worked days in the month. Forward-Port-Of: odoo/enterprise#111814 Forward-Port-Of: odoo/enterprise#111570
This update fixes an issue where linked records were lost when importing spreadsheets from CSV or XLSX files. The change ensures that newly created spreadsheet documents automatically link to the same source document, maintaining data relationships. This improves data integrity and simplifies spreadsheet workflows.
Original PR description
When importing an XLSX or CSV document into a spreadsheet, the linked record is lost on the newly created spreadsheet document. This happens because the conversion creates a new document through `copy()`, while `res_model` and `res_id` are computed fields and are not copied by default. This commit explicitly forwards the linked record values during the conversion so the created spreadsheet keeps the same linked record as the source document. Task: [6008920](https://www.odoo.com/odoo/project/2328/tasks/6008920) Forward-Port-Of: odoo/enterprise#111569 Forward-Port-Of: odoo/enterprise#110047
This update corrects a rounding error in the US payslip PDF that was causing incorrect overtime rates, particularly for very small overtime durations. The fix changes how the rate is calculated directly on the work entry, ensuring accurate overtime pay is displayed. This improves the reliability of payroll reports.
Original PR description
The Rate column on the US payslip PDF is computed as amount / hours, but amount is a Monetary field rounded to 2 decimals. For small hour values (e.g. seconds from the attendance app), the rounding error causes us to compute the wrong rate. For example, working 6 seconds of overtime at an hourly rate of $26 with a 1.5x overtime multiplier results in this calculation: $26/hour * 1.5 * 0.00166667 hour = $0.065 ≈ $0.06 We then attempted to calculate the rate in reverse for the PDF: $0.06 / 0.00166667 hour = $35.9999 ≈ $36.00 Because of the rounding that happened, it doesn't show the expected $39/hour rate ($26 * 1.5). We now compute the rate directly from hourly_wage * multiplier on the work entry type instead. This is a manual forward-port of the work in Odoo 18 [1], to instead use the new amount_rate field on hr.work.entry.type instead. task-6052711 [1] https://github.com/odoo/enterprise/pull/111540 Forward-Port-Of: odoo/enterprise#111733
This update resolves an issue where equity transactions couldn't be created in currencies other than the company's default (USD). Now, users can set the equity currency for the first transaction, ensuring flexibility in recording equity values. Subsequent transactions automatically use this chosen currency.
Original PR description
### Issue: When a company is set in USD, it was not possible to create equity transactions in another currency (e.g., EUR) ### Cause: The equity_currency_id is initialized with the company currency at partner creation (or module installation) However, there was no way to override this value when creating transactions ### Fix: It is now possible to set the equity currency on the first transaction Subsequent transactions reuse this currency and the field becomes read-only ### Steps to reproduce: - Install `equity` with demo data (currency and equity_currency default to USD) - Enable the EUR currency - Create an equity transaction for a company - You can now choose EUR on this transaction - Create another transaction for the same company, the selector is hidden and the currency remains EUR opw-5382255 Forward-Port-Of: odoo/enterprise#108248
This update resolves an issue where ISO20022 XML files generated for Swiss companies were being rejected by banks due to an outdated configuration. The fix ensures the correct 'PAIN 09' format is used, guaranteeing compatibility with Swiss banking standards after database migration. This prevents delays and errors in financial transactions.
Original PR description
To reproduce the issue:
- Create a database in 17.0, with a Swiss company, and install account_sepa. Make sure the bank journal uses the Swiss IS020022 PAIN version.
- Migrate this database to 18.0
- Generate an ISO20022 xml file for the Swiss company
==> The file is wrongly formatted, and will be rejected by the bank.
This happens because the sepa_pain_version field of the journal is still set to its old selection value ('pain.001.001.03.ch.02') after migration, which is not supported anymore. The ORM hence returns an empty value when accessing the selection field, and does not enter the proper conditions when generating the file.
An upgrade fix has been made here https://github.com/odoo/upgrade/pull/9771. This commit makes sure already-migrated databases dynamically fix the issue as well.
opw-6060612
Forward-Port-Of: odoo/enterprise#111949This update resolves a technical issue where reports were failing to load correctly on some migrated databases. The change adds a backup system to automatically identify and use account codes when the standard XMLIDs are missing, ensuring reports run smoothly without warnings. This improves the reliability of our financial reporting.
Original PR description
Description of the issue this commit addresses: On some migrated BE databases, account template refs a4121/a4521 are missing as XMLIDs. l10n_be_reports then fails to recover partner/reconcile account refs and logs warnings during post-init load. --- Desired behavior after this commit is merged: This commit adds a fallback in BE report chart template data to resolve a4121/a4521 by account code when XMLIDs are missing, preventing recovery warnings while keeping normal XMLID behavior unchanged. --- runbot-[233845](https://runbot.odoo.com/odoo/runbot.build.error/233845) Forward-Port-Of: odoo/enterprise#111325
This update fixes a potential issue where a user could indirectly change an employee's work email through contract settings. Previously, linking an employee to a user allowed for unintended email updates. Now, the system ensures the work_email remains consistent when an employee is associated with a user, improving data integrity.
Original PR description
Due to https://github.com/odoo/enterprise/pull/106974,the employee's work_email may be reset to False when creating or updating an offer. This behavior is acceptable if the employee does not have a linked user. However, if the employee is linked to a user, resetting work_email can allow a user to indirectly modify their own work_email through salary confi. To prevent this, we now ensure that work_email never changes if employee has a user linked to it. Steps to reproduce: - Hire an applicant from Recruitment (the employee has no work_email). - Set a random work_email and create a user for the employee. - Open the hired applicant and create a new offer to update the contract. - work_email should not be modified, even after new contract. task: 6033382 Forward-Port-Of: odoo/enterprise#111815 Forward-Port-Of: odoo/enterprise#110810
This update resolves a problem where reports with annotations were failing to export correctly. The previous filtering process was redundant, and the unnecessary date filters have been removed. This ensures reports with annotations now export reliably.
Original PR description
[FIX] account_report: Unable to export Report with Annotations Following changes to the date filter in https://github.com/odoo/enterprise/pull/98695, the date options can be missing a date_from (For example, when using period type: "today"). The date were used to filter on the annotations to display during the period of the report. However, we already filter on those date when generating the annotations so this was redondant and can be safely removed. To reproduce: - Open the Balance sheet - Open the chatter of any account and post a message - Click on the "PDF" button to export the report Forward-Port-Of: odoo/enterprise#109984
This update resolves an issue preventing superuser administrators from deleting work entry types within the Odoo payroll module. This change allows for greater flexibility in managing payroll configurations and correcting errors. It's a technical fix to improve administrative control.
Original PR description
Forward-Port-Of: odoo/enterprise#111967
Features or functions removed from Odoo
This change removes a redundant field related to tracking payslip documents with tags. The feature was no longer required and has been removed from the system configuration and associated files. This simplifies the system and reduces potential maintenance overhead.
Original PR description
According to the linked task, the documents_hr_payslip_tags field is no longer needed, therefore we can remove the override of the view adding it and the field on res_config_settings (we remove the whole file since it was the only thing that it was changing). Finally we also remove the documents_tag_payslips record, which was used as a default tag but is no longer needed. Task: 5936989