Daily updates from Odoo
Friday, February 6, 2026
38 changes · master
Resolved issues and error corrections
This update streamlines the database synchronization process by removing outdated XMLRPC support and improving error handling. The user interface wizard for KPI selection has been simplified, and synchronization errors are now reported clearly instead of disrupting the entire process. This enhances the stability and efficiency of database updates.
Original PR description
### [IMP] databases: remove xmlrpc fallback for odoo.com Since odoo.com migrated to 19.0, it will always support the json2 API, and XMLRPC support will be dropped on the next version. In order to…
### [IMP] databases: remove xmlrpc fallback for odoo.com Since odoo.com migrated to 19.0, it will always support the json2 API, and XMLRPC support will be dropped on the next version. In order to simplify the code and avoid subsequent requests in case of errors on the json2 API, the XMLRPC fallback is stripped off from `databases.api`. In this commit, we only adapt the tests so that they don't test the fallback to XMLRPC when calling odoo.com. In the next commit, we will remove the dead code. The configuration parameter `databases.odoocom_apiuser` is removed, as well as the corresponding field in the Settings page. ### [FIX] databases: disable the KPI-selection wizard With this commit, we disable the wizard displayed at the end of a synchronization to select which KPIs are added to the properties field. Instead, we always store all the KPIs that are provided by the databases, and the users can still select which ones they want to display on the list view. The wizard is still used in the background for stable compliance, but it is not displayed to the user any more. It will be removed in the next stable version (saas~19.2). Task-id: [5868314](https://www.odoo.com/odoo/project.task/5868314) ### [FIX] databases: handle fetch errors better With this commit, fetching errors like 502 Bad Gateway are handled better, as they are reported as an error message in the final summary instead of interrupting the whole synchronization and showing a traceback to the end user. ### [FIX] databases: synchronize up to immediate_sync_limit databases synchronously Previously, if the number of databases to be synchronized exceeded `databases.immediate_sync_limit`, no databases were synchronized synchronously. Instead, all were queued for a triggered scheduled action. With this commit, the synchronization process will handle up to `immediate_sync_limit` databases synchronously, while the remaining databases will be sent to the scheduled action. Forward-Port-Of: odoo/enterprise#105965 Forward-Port-Of: odoo/enterprise#105176
This update fixes a bug preventing appraisal templates from displaying departments without a linked company. The issue stemmed from a filtering error in the template selection process. Now, all departments, including those without a company association, are correctly available for selection on appraisal templates.
Original PR description
### Issue:
On the appraisal template form view, the dropdown of "Departments" does not show departments with no company.
### Steps to reproduce:
- In the Employee app create a new Department with no company
- Go in Appraisals > Configuration > Appraisal Templates
- Click on a template, remove it's company if it has one
- Try to change the Department of the template
- The new department does show
### Cause:
The field `department_ids` on `hr.appraisal.template` have this domain: `(company_id and [('company_id', 'in', [company_id, False])] or [('company_id', 'in', allowed_company_ids)])` It excludes departments with no company when the template have no company because `allowed_company_ids` doesn't contain `False`.
### Solution:
Add `False` in `allowed_company_ids`.
opw-5354581
Forward-Port-Of: odoo/enterprise#103531This update resolves an issue where toggling the Studio feature in Odoo Enterprise could disrupt the layout of form stat buttons. The fix ensures the stat button layout remains consistent, regardless of whether Studio is active, improving the user experience and preventing potential design inconsistencies.
Original PR description
**Before this commit:** Toggling Studio could break the layout of form stat buttons. **After this commit:** The stat button layout remains intact when Studio is toggled. task-5480309 Forward-Port-Of: odoo/enterprise#106452
This update resolves an issue where sale commission IDs exceeded JavaScript's maximum safe integer, causing errors. The fix increases the range of the plan ID, allowing for a significantly larger number of sales plans (from 900 to 90,000) while maintaining security and minimizing potential data conflicts. This improves the system's ability to handle increased sales volume.
Original PR description
Issue: 10^13 was too big of an exponent as such the id generated were bigger than JS limit `Number.MAX_SAFE_INTEGER`, this resulted in the id being rounded to the nearest reprentable integer. Which resulted in a traceback as we were fetching records that didn't exist. This fix allow a bigger margin for the plan_id while keeping the collusion risk equal, as we have the following: - user_id margin is 10^5 - date is in YYMMDD format, so it occupies at most 6 integer - plan_id can thus occupy the space after which is 5 + 6 so 10^11 Only issue possible left with this id generation would be to have user that are 1000 id apart, with same date and same plan. Or that we have too much plan that we exceed the JS limit. Number of plan that can be handled with this change goes from ~900 -> ~90000 which seems reasonable. Forward-Port-Of: odoo/enterprise#106513
This update corrects a previous error that prevented users from posting miscellaneous operations with both expense and revenue accounts when deferred entry methods were configured differently. The fix ensures the validation process now correctly targets lines with actual deferred dates, improving usability and preventing unnecessary errors.
Original PR description
The `_get_deferred_entries_method` checks for expense/income account conflicts using all line accounts, not just lines with deferred dates. This causes a false positive error when posting misc…
The `_get_deferred_entries_method` checks for expense/income account conflicts using all line accounts, not just lines with deferred dates. This causes a false positive error when posting misc entries with both expense and revenue accounts but no deferred dates configured. https://github.com/odoo/enterprise/blob/3e6d2f3ca7e2d4e940f2c2022f816202c72cbd1b/account_accountant/models/account_move.py#L150-L151 Steps To Reproduce: 1. Go to Settings → Accounting and set different "Generate Entries" methods for deferred expenses "On bill validation" and deferred revenues "Manually & Grouped". 2. Go to Accounting Dashboard and create a new Miscellaneous Operation. 3. Create 2 journal items: one with an expense account and one with a revenue account (neither configured for deferred entries). 4. Try to post the entry. 5. Error appears: "Having different deferred entries generation methods for expenses and revenues is not supported..." The validation should only apply when lines actually have deferred dates set, not for all misc entries with mixed account types. Commit that caused the issue: https://github.com/odoo/enterprise/commit/3e6d2f3ca7e2d4e940f2c2022f816202c72cbd1b Ticket [link](https://www.odoo.com/odoo/project.task/5486114) opw-5486114 Forward-Port-Of: odoo/enterprise#104476
This update simplifies the one-time payment form by removing a redundant version field. The form now automatically displays payments for the correct employee based on the context, ensuring a more streamlined and accurate user experience. This change improves usability and avoids potential errors.
Original PR description
… payment form The one time payment view is accessed only via the smart button on the employee form for a specific version. This view displays only that employee's one time payments for the selected version. Since the version is provided by the context and creating a payment for a different employee or version would not make sense, the version field is made invisible. Task: 5384437 Forward-Port-Of: odoo/enterprise#103245
This update resolves an issue where older sign requests without a designated 'communication company' would cause the system to crash. The fix automatically uses the user's company date format, ensuring sign requests can be processed correctly regardless of the initial company setting. This improves the reliability of the sign request workflow.
Original PR description
For old databases that were created before 16.0, existing sign request might not have a communication company set. Following commit odoo/enterprise@6b505a34f7bdee89c155eed7507296d5acfd8a9b trying to…
For old databases that were created before 16.0, existing sign request might not have a communication company set.
Following commit odoo/enterprise@6b505a34f7bdee89c155eed7507296d5acfd8a9b trying to open such sign request will result in a crash:
```
Traceback:
...
File "/data/build/odoo/enterprise/saas-18.3/sign/controllers/main.py", line 354, in get_document
context = self.get_document_qweb_context(request_id, token)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/enterprise/saas-18.3/sign/controllers/main.py", line 88, in get_document_qweb_context
date_format = posix_to_ldml(lang.date_format, locale=locale)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/data/build/odoo/odoo/saas-18.3/odoo/tools/misc.py", line 606, in posix_to_ldml
for c in fmt:
TypeError: 'bool' object is not iterable
```
This commit fallback to the create user's company to determine the date language when there is not communication company set.
no-task (from feedback pad)
Forward-Port-Of: odoo/enterprise#87526This update resolves a technical issue preventing the correct installation of the l10n_be_hr_payroll_fleet module. The fix ensures the module correctly relies on the hr_fleet module, avoiding a missing field error when demo data is created. This ensures the module functions as intended.
Original PR description
Steps to reproduce: 1. Install l10n_be_hr_payroll_fleet with --skip-auto-install and demo data. 2. Traceback when creating demo data because driver_employee_id is missing on the model fleet.vehicle Cause: The module depends on fleet instead of hr_fleet so hr_fleet is only auto installed. Thus, when skipping auto install, the field driver_employee_id doesn't exist. Fix: Change the dependency from fleet to hr_fleet to force the module to be installed. Runbot error: https://runbot.odoo.com/odoo/runbot.build.error/237909 Task: 5875410 Forward-Port-Of: odoo/enterprise#106256 Forward-Port-Of: odoo/enterprise#106199
This update corrects a technical issue related to the Swiss localization of Odoo's payroll system. Specifically, a test tour was incorrectly triggered due to differences in how work entries are handled in Switzerland. This change ensures the tour functions correctly for Swiss companies, streamlining the payroll setup process.
Original PR description
The Work Entries button on the form view of the hr_payslips is defined differently in the Swiss localization. We need to override the tour to make it work for swiss companies. Runbot Error: 234647 Forward-Port-Of: odoo/enterprise#106311 Forward-Port-Of: odoo/enterprise#106147
This update resolves an issue where Worldline receipts were incorrectly duplicated in POS receipts. The change ensures receipts are only updated when a Worldline transaction is fully completed, improving the accuracy of sales records. This prevents data inconsistencies and ensures reliable reporting.
Original PR description
This PR fixes the issue where Worldline receipts were sometimes added twice to the pos receipt by only modifying the receipt if the transaction has been finished (currently we modify the receipt no matter the message type (cancellation/payment failed etc.)) ticket-5342655 Forward-Port-Of: odoo/enterprise#106554
This update fixes an issue where the 'Mark as Paid' button wasn't appearing correctly during the pay run tour. The fix ensures the button is always visible and accessible, streamlining the user experience. A related change adjusts the test setup to account for a dependency update.
Original PR description
The Mark as Paid button doesn't appear in the view right away, but has been moved in the options (the ellipses button). It's enough to just add a click action on the ellipses so that the Mark as Paid button is visible and the tour can continue. Also, the button is secondary and not primary so we have removed that class altogether, since there is only one button with Mark as Paid text. This fix was already present for the hr_payroll_account_iso20022 but is now needed for the hr_payroll_account module too. However, since the iso20022 version doesn't depend on hr_payroll_account, we modify its override to only open the option if they are not already opened. This is to avoid the fact that when the override happens, the options ubtton is triggered twice, closing it and hiding the Mark as Paid button Runbot Error: 234625 Forward-Port-Of: odoo/enterprise#105015
This update fixes an issue where sign templates created in languages other than English didn't automatically update with the correct document name. The fix ensures that the template name always matches the document name, regardless of the user's language setting, improving the accuracy and usability of the signature process.
Original PR description
## Steps to reproduce: 1. Upload a new PDF document to be signed. 2. Select it in the Documents app to sign it. 3. Check the name of the sign template created. ## Issue: When creating signature templates in languages other than English, the template name would stay as "New Template" instead of updating to the actual document name. This happened because the code was comparing the template name against a translated version of "New Template", but the template was initially created with the English default value. Since "New Template" ≠ "Nueva Plantilla" (Spanish), the comparison failed and the name never got updated. The fix ensures we always compare against the original English default value, so the template name gets properly updated to match the document name regardless of the user's language. Related commit: 4254542 opw-4980747 Forward-Port-Of: odoo/enterprise#104846 Forward-Port-Of: odoo/enterprise#92682
This update brings back previously disabled tests related to work order accounting functionality. Specifically, tests now verify that users with limited account access can still complete work orders, requiring sudo access in certain areas. This ensures the system continues to function correctly with different user permission levels.
Original PR description
Bring back all tests temporarily disabled by [1] `.test_mrp_aa_employee_without_account_rights` `.test_user_can_complete_workorder_despite_project_restrictions` Use lowest rights level. This explains the needed `sudo` in: `/project_mrp_workorder_account:MrpWorkcenterProductivity.write` [1] https://github.com/odoo/enterprise/commit/be6eb5e22283e952554b1bab435a7113f3061e23 Forward-Port-Of: odoo/enterprise#106194 Forward-Port-Of: odoo/enterprise#105626
This update fixes an issue where the business card scanner button disappeared from the mobile CRM interface after a recent update. The button has been restored, ensuring users can still scan business cards directly from the mobile kanban view. This improves the usability of the CRM on mobile devices.
Original PR description
After the introduction of the lead generation dropdown (task-4876662) in the CRM kanban control panel, the business card scanner button was no longer rendered on mobile devices. This commit restores the business card scanner button in the kanban control panel on mobile. Task-5899751 Forward-Port-Of: odoo/enterprise#106453
This update adjusts the automatic scheduling of reports to prevent unnecessary database activity. By changing the cron interval to 9999 months, the reports will no longer run daily, optimizing system performance and reducing resource consumption. This change ensures a smoother and more efficient reporting experience.
Original PR description
The cron interval is updated from 1 day to 9999 months to effectively Disable automatic execution. The workflow is fully real-time and trigger-based, and running this cron Daily would unnecessarily wake up registries and databases. task-5885482 Forward-Port-Of: odoo/enterprise#106264
This update improves the user experience by adding breadcrumbs to the booking views within the Enterprise application. Previously, users navigating to appointments lacked a clear path back to previous locations within the system. This change provides better navigation and clarity for appointment scheduling.
Original PR description
In this commit: - Enable breadcrumbs for the booking view by explicitly allowing them in the action context. Task:5490961 Forward-Port-Of: odoo/enterprise#104560
This update fixes an issue where Odoo didn't properly account for credit notes during bank reconciliation. Now, when reconciling a bank transaction with a credit note applied to an invoice, the system correctly uses the remaining balance due ($800 in this example) instead of the full invoice amount. This ensures accurate financial reporting.
Original PR description
1. Create an invoice for $1,000 2. Create a credit note of $200 and apply it to the invoice. The invoice is marked 'partially paid.' The remaining due is $800. 3. Create a bank transaction of $700, reconcile with the invoice. 4. Edit the counterpart line, and click "fully paid". >>> Odoo does not consider the credit note and uses the full amount of $1,000 instead of the remaining due of $800 to reconcile. With the refactor of the bank rec, the way the amount is show is computed from econciled_lines_excluding_exchange_diff_ids in apply_amount.js which only takes into account the direct invoice and not the credit notes (in _compute_reconciled_lines_excluding_exchange_diff_ids it take the matched debit and matched credit so only the partial between the transaction and the move) opw-5485663 Forward-Port-Of: odoo/enterprise#105197
This update resolves an issue that occurred when cancelling subscriptions for internal users (like 'Mitchel Admin'). The original system triggered an access error when attempting to update partner records. The fix utilizes 'sudo' to grant necessary permissions, ensuring subscription cancellations for internal users function correctly.
Original PR description
*: sale_subscription_partnership To reproduce: ============= 1/ be sure Marc Demo has only sales admin righ 2/ as admin create a subscription with customer = Mitchel Admin (or other internal user) and confirm it (only confirm, do not invoice) 3/ as demo, cancel the SO => Acccess error on res.user Problem: ======== When cancelling a subscription we want to write some fields on the partner related to the SO. If the partner is an internal user, and the current user has no access to write on res.users, we get an access error. Solution: ========= Use sudo when writing on the partner when cancelling a subscription. opw-5857627 Forward-Port-Of: odoo/enterprise#106393 Forward-Port-Of: odoo/enterprise#105901
This update fixes a problem that prevented the 'hr_expense_stripe' module from installing correctly in certain countries where Stripe payment processing isn't available. The fix removes a redundant check, allowing the module to function properly in locations without Stripe support. This ensures a smoother installation experience for all users.
Original PR description
[FIX] hr_expense_stripe: error when installing loca not supported Step to reproduce the bug: - install 'hr_expense_stripe' - try to install a localization where Stripe is not available (e. g. Romania) - The error raise This is due to an @api.constrains that can be removed no-task Forward-Port-Of: odoo/enterprise#106351
This update corrects inaccurate state data for Saudi Arabia within the HR payroll module. The system has been updated to reflect the 13 actual Saudi regions instead of the previous 93, improving data accuracy and compliance. The old state information is now stored for migration purposes.
Original PR description
Before this commit: - There are a total of 93 states in Saudi Arabia - That is not correct After this commit: - We replace the 93 States with the new 13 states/Actual Saudi Region - Stored that old value of state in chatter during migration task-5155736
This update fixes a reporting issue in the French P&L statement. Accounts 65 were incorrectly categorized in 'Other purchases and external charges.' This change ensures these accounts are now accurately displayed within the 'Other Expenses' line, improving the accuracy of financial reporting.
Original PR description
On the french P&L, accounts 65 are refferenced in the line 'Other purchases and external charges' but this is not where those accounts need to be, they need to be part of the line 'Other Expenses' task-5446018 Forward-Port-Of: odoo/enterprise#106465 Forward-Port-Of: odoo/enterprise#103357
This update resolves a bug where time off requests weren't correctly being processed, leading to inaccurate payroll calculations. Specifically, a rounding error was creating a tiny work entry, causing issues with deferring time off to the next month. The fix ensures accurate time off reporting and payroll processing.
Original PR description
STEP TO REPRODUCE: ------------------ 1- Set to an employee a schedule of 7h36 hours per day 2- Create a payslip for him on february and pay it 3- Create a time off from 28th debruary to 4th of march 4- Approve it and click on the button "Report to Next Month" You will have an issue but you should be able to do it REASON: ------- A rounding issue caused the creation of work entry of 1*10^-15 hours Forward-Port-Of: odoo/enterprise#106473
This update fixes a potential issue where applicants could incorrectly reopen and re-sign expired job offers. The system now prevents access to these offers, ensuring data integrity and a smoother applicant experience. A database check has been added to enforce offer validity.
Original PR description
This commit improves the offer validation logic to avoid invalid or unintended signature attempts. Fixes included: - Block access to offers that are already fully signed, preventing applicants from reopening the link and unintentionally reverting the offer to a partially signed state. - Add an SQL constraint on the `validity` field to disallow negative values, ensuring that expired/invalid offers cannot be accessed due to incorrect validity data. These changes ensure that expired or fully processed offers no longer expose active signature links and that offer validity is consistently enforced at the database level. task-5405456 Forward-Port-Of: odoo/enterprise#105646 Forward-Port-Of: odoo/enterprise#101834
This update fixes a minor issue where the system repeatedly asked users to select an employee when adding goals to appraisals. The fix ensures the correct employee context is used, streamlining the goal creation process and improving user efficiency. This prevents unnecessary steps and ensures a smoother experience.
Original PR description
When adding goals from an employee appraisal, Appraisal of an employee > Goals > Open Library > Select Goals > Continue On the next screen, you need to select the employee, but you come from an employee appraisal! The employee was already known but the flow still asked to re-select an employee again. - The root cause was the employee context was passed as a list while goal creation expects a single employee. - This fix adapts the context so goals are directly created for the current appraisal employee. task-[5420664](https://www.odoo.com/odoo/project/1251/tasks/5420664) Forward-Port-Of: odoo/enterprise#102751
This update resolves an issue where folded (closed) tickets were incorrectly showing in the helpdesk email plugin, causing confusion for users. The fix filters out tickets in the 'folded' stage, ensuring that users only see active, relevant tickets in the plugin. This improves the user experience and data accuracy.
Original PR description
**Steps to reproduce:** - Install Mail_plugin - Setup the outlook mail plugin in Outlook - Once connected, click on a mail from a contact on the database - Click on the Odoo Inbox Addin. action - Under the contact 5 related tickets are showed - Create 5 tickets with priority and put them in folded stage (closed) - Create new normal tickets - User can't see new tickets in the plugin **Issue:** The search is done on priority and then id ordering, this means that tickets in folded stages (closed) which have a high priority are always showed first. Tickets in a folded stage are considered as closed, so they should not appear anymore in the contact data to avoid displaying them indefintely. **Fix:** Adapted search domain and removed fold attribute in the answer. opw-5075477 Forward-Port-Of: odoo/enterprise#100883
This update resolves a failing test case related to Indian GST reports. A recent community fix changed how payable lines are labeled, now including the bill reference. The test cases have been updated to reflect this new labeling format, ensuring accurate reporting.
Original PR description
Before: - Test cases in Indian GST reports were failing because they expected payable line labels like `installment #1`, but after the community fix (Task: 4982864), payable lines are now populated with the bill reference when Payment Reference is empty, resulting in labels like `TEST/0001 installment #1`. After: - Modified test cases to expect the new label format that includes the bill reference. Related PR (Community) : https://github.com/odoo/odoo/pull/221491 Task: 4982864 Forward-Port-Of: odoo/enterprise#106573 Forward-Port-Of: odoo/enterprise#91535
This update resolves an issue related to the calculation of coordination deductions in the Swiss payroll module (l10n_ch_hr_payroll_elm_transmission_5_3). The fix ensures accurate reporting of these deductions, aligning with Swiss tax regulations. This improves the reliability of payroll data for Swiss businesses using Odoo Enterprise.
Original PR description
Forward-Port-Of: odoo/enterprise#106615
This update resolves an issue where the employee's filling status wasn't updating correctly when the working address state was changed. The fix adjusts the calculation of the filling status based on the address's state, ensuring accurate status reflection across the system. This prevents incorrect payroll calculations related to state-specific tax rules.
Original PR description
to reproduce: ============= - create employee and set working address with state in CA - set filling status to match the state - in the address record change the state to AL (don't change the record in employee) - go back to employee form view, filling status is still the same problem: ======== currently we are relying on a constraint to check if the filling status is valid for the state in the working address. But `api.constrains` doesn't support dotted paths, so modifying `address_id.state_id` doesn't trigger it. solution: ========= make the filling status computated field depending on `address_id.state_id` opw-5878740 Forward-Port-Of: odoo/enterprise#106511 Forward-Port-Of: odoo/enterprise#106000
This update resolves an issue with spreadsheet collaboration by aligning the client move debounce functionality. The underlying o-spreadsheet library has been updated to handle this, and this change ensures smoother and more reliable collaborative editing within the enterprise version of Odoo. This improves the overall user experience.
Original PR description
This is the counter-part of a change in o-spreadsheet lib. The lib no longer debounces client moves. It's the responsibility of the transport service to do it. See o-spreadsheet commit for more details. Task-5916695
This update resolves an issue where actions within the Odoo Enterprise phone system were failing when a call wasn't initially established. The change ensures that action contexts are properly set, utilizing available phone numbers to improve reliability and functionality across multiple modules like CRM, Helpdesk, and HR.
Original PR description
For sessions with a missing call, some actions were executed without a default phone number in their context. This change updates ActionList and its patches to work with the session and extract a known phone number (if any), ensuring action contexts are set correctly.
This update resolves an issue where products with a zero price were being sent to UrbanPiper during menu synchronization, causing problems on their end. The change now excludes these zero-price products from the sync process, ensuring smoother integration with UrbanPiper and preventing potential errors.
Original PR description
Before this commit: --- - During menu sync, charge products with a price of zero were sent to UrbanPiper which caused issues on the UrbanPiper side. After this commit: --- - Exclude charge products with a zero price from the menu sync. task-5867272 Forward-Port-Of: odoo/enterprise#106616 Forward-Port-Of: odoo/enterprise#105861
This update resolves an issue where the blackbox system wasn't sending the correct POS ID, impacting data transmission for tax reporting. A secondary change restricts blackbox device selection within the POS configuration, enhancing security and data integrity. This ensures accurate financial reporting for our SE clients.
Original PR description
When using a v1 CleanCash blackbox, the command being sent to the blackbox was mistakenly sending a POS ID of " ". It just so happened this worked correctly when testing with our blackbox because it had " " registered as a POS ID. The POS ID is now sent correctly. Another small fix was made to only allow selecting blackbox devices in the Fiscal Data Module field in the POS config settings. task-5077448 Forward-Port-Of: odoo/enterprise#106530 Forward-Port-Of: odoo/enterprise#106431
This update resolves an issue where changes made to spreadsheets were lost after deleting archived revisions. The fix allows users to continue making edits even after removing older versions, ensuring data integrity and preventing data loss. This improves the stability and usability of the spreadsheet edition.
Original PR description
Steps to reproduce - create a spreadsheet - do a few changes - leave the spreadsheet (to snapshot) - reopen the spreadsheet - do a few more changes - from another tab, go to Settings/Technical/Revisions - delete all archived revisions - reload the spreadsheet => the last changes are lost and new changes are no longer saved. Forward-Port-Of: odoo/enterprise#106659 Forward-Port-Of: odoo/enterprise#99357
This update fixes an issue where draft and cancelled accounting entries were incorrectly included in tax return calculations, leading to inaccurate tax return amounts. Now, tax returns accurately reflect the values in related reports by excluding entries in draft or cancelled states, ensuring data integrity.
Original PR description
Behavior before: When generating tax returns, accounting entries linked to tax group accounts were included in the calculation even if they were in draft or cancelled state. As a result, tax returns…
Behavior before: When generating tax returns, accounting entries linked to tax group accounts were included in the calculation even if they were in draft or cancelled state. As a result, tax returns displayed incorrect amounts. Behavior after: Tax return amounts now correctly match the values shown in the corresponding reports. Entries in draft or cancelled state are excluded, eliminating discrepancies in tax return calculations. Root cause: The domain used in the _add_line method did not filter entries based on their parent_state. This caused all related accounting entries—regardless of their posting status—to be included in the calculation. Steps to reproduce: 1. Create accounting entries using an account that is part of a tax group. 2. Set the entries to draft or cancelled state. 3. Generate a tax return for the current period. 4. Observe that amounts from draft or cancelled entries are included in the tax return. OPW: 5417293 Forward-Port-Of: odoo/enterprise#106101
This update fixes a minor issue where payment links were sometimes displayed even when the subscription had expired and related products were no longer available. Now, the 'Pay Now' link only appears if the advance payment section is visible, ensuring a cleaner and more accurate user experience for subscription renewals.
Original PR description
When the subscription is expired and has to be paid, only use an anchor for `Pay Now` if the advance payment section is displayed (it could be hidden for ex. if any of the product has been archived) Forward-Port-Of: odoo/enterprise#105879 Forward-Port-Of: odoo/enterprise#105480
This update resolves an issue where changing a commission plan's frequency (e.g., from quarterly to monthly) didn't properly remove outdated periods, leading to incorrect commission calculations. The fix ensures that old periods are removed when the plan's frequency is updated, preventing overlapping commission targets and ensuring accurate reporting.
Original PR description
## Issue When changing the *Target Frequency* of a commission plan, previously created periods are not removed. ## Steps to reproduce 1. Install *Sale Commission* (`sale_commission`) 2. Create a…
## Issue
When changing the *Target Frequency* of a commission plan, previously created periods are not removed.
## Steps to reproduce
1. Install *Sale Commission* (`sale_commission`)
2. Create a *Commission Plan*. The default *Target Frequency* (`periodicity`) should be *Quarterly*. In the *Periods* tab, 4 periods (`targets`) are present.
3. Change the *Target Frequency* to *Monthly*
4. **New monthly periods are added, but the quarter periods are not removed**
This behavior leads to a second issue:
5. Following the previous steps, set the current user as a Salesperson the *Sales People* tab
6. Approve the Commission Plan
7. Create an invoice
- Any customer
- Add a product with a price of $100
- Confirm the invoice
8. Go to Sales > Commissions > My Commissions
9. **The invoice impacted multiple commission targets, because the current period is covered multiple times (by the monthly and the quarterly frequencies)**
## Cause
This issue was introduced by https://github.com/odoo/enterprise/commit/e7693f3c61044f689da87218235cd985e26f75d5. The commit aimed to preserve periods when updating the *Effective Period* of a commission plan. In fact, in some cases, it is unnecessary to delete all periods because some of them belong to both the previous and the updated effective period.
https://github.com/odoo/enterprise/blob/2dd98eed0559b6217ef8467f1d56c171d546b85b/sale_commission/model/commission_plan.py#L106-L108
When updating the *Target Frequency* of a commission plan, the *Effective Period* is unaffected, making the `target_changes` list empty. This leads to none of the periods being deleted, eventhough they don't respect the new periodicity.
## Fix
The condition to add periods to the `target_changes` list needs to updated, as it needs to also take in account the periodicity of the commission plan. The `expected_target_duration` needs to be a range, as it depends on the (variable) length of the months that are concerned. These ranges were chosen by looking at the sizes of each period. A margin of one day is added for the "year" case to handle leap years.
<img width="687" height="367" alt="5877405" src="https://github.com/user-attachments/assets/065b0d21-0860-4435-9f9b-55feef789da6" />
## Test
The test `test_commission_target_constraint` was using the fact that the periods were not deleted when updating the periodicity to test against the creation of overlaps between periods. As this is no longer possible, the test was updated.
opw-5877405
Forward-Port-Of: odoo/enterprise#105813This update ensures that invoices generated with the Solution Factible PAC in Mexico comply with Mexican tax regulations regarding exchange rate precision. Previously, a rounding issue caused invoices to be rejected; this fix applies the existing rounding fix to all PACs, resolving this compatibility problem and preventing invoice errors.
Original PR description
The PACs Quadrum and SwSapien both require the exchange rate to have 6 decimal places. This can cause some valid invoices to be rejected for large enough payment values. Pull request…
The PACs Quadrum and SwSapien both require the exchange rate to have 6 decimal places. This can cause some valid invoices to be rejected for large enough payment values. Pull request [83499](https://github.com/odoo/enterprise/pull/83499) added rounding precision for these PACs. Now, the remaining PAC (Solution Factible) appears to the same requirement. This commit ensures that the previous bug fix is applied to all PACs. [opw-5165200](https://www.odoo.com/odoo/project.task/5165200) ## Steps to reproduce: [Setup](https://drive.google.com/file/d/1BUkNG-Ezk-I47yvbNolOmlj0ne1iqDto/view?usp=sharing) 1. Navigate to Apps and install l10n_mx_edi. 2. Switch to any of the Mexican companies that appear. 3. Navigate to Accounting > Configuration > Currencies. 4. Click into the USD currency. 5. Change the current rate to be 20.101796407186 MXN per USD. (inverse_company_rate field). 6. Navigate to Accounting > Configuration > Settings, and set the PAC to Solution Factible. [Workflow](https://drive.google.com/file/d/11TFZ78QGDYdnD9R3CoJDAuFI-1_0dNyG/view?usp=sharing) 1. Navigate to Accounting > Customers > Invoices. 2. Select New to create a new invoice. 3. Add a mexican customer (such as XENON INDUSTRIAL ARTICLES). 4. Add the 45 day Payment terms. This should change the payment policy to PPD. 5. Change the currency to USD. 6. Add the product FURN_8220 (or any with the unspsc_code_id set). 7. Set the unit price of the product to 58968.29. 8. Confirm the invoice. 9. Select Send & Print, then ensure that the CFDI option is selected before clicking Send & Print again. 10. Select Register Payment, then Confirm Payment. 11. Select the Update Payments smart button. 12. Navigate to the CFDI tab; there will be a "Payment Send in Error" line. Forward-Port-Of: odoo/enterprise#105412 Forward-Port-Of: odoo/enterprise#102557
This update resolves a technical issue that caused a SQL error when creating invoices with non-deductible tax values in Studio. The fix ensures the system handles unsaved invoice lines correctly, preventing the error and improving data integrity. This change impacts the account asset module.
Original PR description
**Steps to reproduce:** * Install **account_asset** and **l10n_be**. * Enable **developer mode**. * Using **Studio**, add the field **non_deductible_tax_value** to invoice lines. * Create a new invoice. * Select a partner and add a product with **21% VAT** applied. * Do not save the invoice before adding the line. **Observed behavior:** * A **SQL syntax error** occurs: `WHERE tdq.base_line_id IN ()`. * The error is triggered when accessing the non-deductible tax value on unsaved records. **Cause:** * `_compute_non_deductible_tax_value()` executes SQL query with `tuple(self.ids)`. * For unsaved records, `self.ids` is empty, creating invalid SQL `IN ()` syntax. * This path is only reached for **non-deductible taxes**. **Fix:** * Skip the SQL query when no record IDs are available. * Return a default value for unsaved records. opw-5896716 Forward-Port-Of: odoo/enterprise#106655 Forward-Port-Of: odoo/enterprise#106470