Daily updates from Odoo
Friday, February 6, 2026
200 changes
19 changes
Resolved issues and error corrections
This update prevents the daily automatic execution of a reporting cron job, which was causing unnecessary database activity. By changing the cron interval to 9999 months, the reporting process now runs only when triggered, improving system stability and performance. This resolves a potential issue impacting Odoo's responsiveness.
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 resolves an issue where products with a zero price were being sent to UrbanPiper during menu synchronization, causing problems for their system. 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#106491 Forward-Port-Of: odoo/enterprise#105861
This update resolves a bug where time off requests weren't being correctly processed, leading to inaccurate payroll calculations. Specifically, a rounding error was creating a tiny work entry, causing a reporting issue when 'Reporting to Next Month' was used. The fix ensures accurate time off deferral 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 an issue where Odoo didn't correctly reconcile bank transactions with credit notes. Now, when a credit note is applied to an invoice and the bank transaction is marked 'fully paid', the system accurately reflects the remaining balance ($800 in this case) during bank reconciliation. 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 fixes an issue in the French P&L report where accounts 65 were incorrectly categorized. The accounts have been moved to the 'Other Expenses' line, ensuring accurate financial reporting and compliance with French accounting standards. This improves the clarity and reliability of the financial data.
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 change resolves an issue that prevented subscription cancellations for internal users (like 'Mitchel Admin'). The fix uses 'sudo' to allow necessary updates to the partner record during cancellation, preventing access errors. This ensures subscription cancellations function correctly regardless of the user's role.
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 supported. The fix removes a redundant check, allowing the module to function properly in locations without Stripe integration. 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 resolves an issue where closed tickets with high priority were incorrectly displayed in the Odoo Mail Plugin. The fix filters out tickets in 'folded' stages, ensuring users only see active, open tickets related to a contact. This improves the user experience and prevents outdated information from being shown.
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 an issue where the POS ID wasn't correctly transmitted to the blackbox, impacting the generation of receipts. A secondary change restricts blackbox device selection within the POS configuration, enhancing data security and accuracy. This ensures proper receipt generation and improved data integrity.
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#106431
This update fixes a minor issue where the system repeatedly asked users to select an employee when adding goals to an appraisal. The change ensures the system correctly identifies the employee from the appraisal, streamlining the goal creation process and improving user efficiency. This prevents unnecessary steps and reduces potential user frustration.
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 a problem where test cases for Indian GST reports were failing due to a recent change in how payment references are handled. The test cases have been updated to correctly reflect the new label format, ensuring accurate reporting of Indian GST data. This change was prompted by a previous community fix.
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 accurate transmission of coordination deductions for Swiss payroll (l10n_ch_hr_payroll). The fix ensures that deductions are calculated and reported correctly, aligning with Swiss tax regulations. This improves the reliability of payroll reporting for our Swiss clients.
Original PR description
Forward-Port-Of: odoo/enterprise#106615
This update fixes a potential issue where the system wasn't correctly processing weight readings from the scale, particularly when using a 'read_once' action. The change ensures that all weight readings, regardless of the action used, are properly recognized and handled, improving the reliability of scale data collection. This ensures accurate inventory tracking.
Original PR description
This commit adjusts the callback when a new weight is received from the scale to also handle the case where it is the response to the `read_once` action. In this case, the `status` key is `success`. backport of: odoo/enterprise#105324 Forward-Port-Of: odoo/enterprise#106691
This update resolves an issue where changes made to spreadsheets were lost after deleting archived revisions. Now, when you delete all archived revisions and reload the spreadsheet, your latest edits are preserved, ensuring data integrity and a smoother workflow.
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#99357
This update fixes a minor issue where payment links were sometimes displayed even when the subscription was expired and related products had been removed. 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 fixes an issue where the selected card in the appointment scheduling interface would lose its outline when navigating between months. The fix ensures the selected card remains clearly highlighted, improving usability and preventing confusion. A styling adjustment was also made to ensure consistent outline appearance across the interface.
Original PR description
Starting from version 19.1, the user / resource manual selection for appointments has been moved to a grid of cards when picking the user / resource first in the front-end. However, when using chevrons to navigate between month, the selected card looses its outline, making it hard to understand which one is selected. This is because we removed the first 'active' class without checking what is was linked to. Fix: only remove the one on the day element, as it is meant to be (as the day should not be selected anymore when changing month) Also add an '!important' on the outline class, as a strange behavior from existing styling was messing with it depending on its focus and focus-visible properties. To reproduce: select a user. Then click anywhere on the page. The card outline was first thin, then thicker. Now, the behavior is consistent across cards and btns on that page. Task-5870725
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 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 target frequency is updated, streamlining commission reporting and preventing double-counting.
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 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 primarily impacts the accounting 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
10 changes
Resolved issues and error corrections
This update resolves an issue where Odoo incorrectly reconciled bank transactions when credit notes were involved. Now, when a credit note is applied to an invoice and the bank transaction is marked 'fully paid,' the system accurately reflects the remaining balance owed. This ensures accurate bank reconciliation reports.
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 fixes an issue in the French P&L report where accounts 65 were incorrectly categorized. The accounts have been moved to the 'Other Expenses' line, ensuring accurate financial reporting and alignment with French accounting standards. This improves the clarity and reliability of financial data for French users.
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 an issue where folded (closed) tickets were incorrectly showing in the Odoo Mail Plugin for contacts. The fix adjusts the search criteria to exclude folded tickets, ensuring users only see active, open tickets. This improves the accuracy and usability of the plugin.
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 fixes a translation error in the Odoo Enterprise system related to Argentine electronic invoices (ARCA). The error message was previously incorrect, leading to confusion for users. Now, the message accurately states that an invoice date before the last validated invoice will trigger an error, ensuring proper compliance with AFIP regulations.
Original PR description
WSFE error 10016-1 must be "The invoice date cannot be before the last invoice validated in AFIP." instead of "The invoice date cannot be after the last invoice validated in AFIP". Steps to reproduce: validate argentinean customer electronic invoice with invoice date before than the last invoice date validated in ARCA. Task Adhoc side: 44290 Task latam: 1376 Forward-Port-Of: odoo/enterprise#106305
This update resolves an issue related to the transmission of coordination deductions for Swiss payroll (l10n_ch_hr_payroll_elm_transmission_5_3). The fix ensures accurate calculation and reporting of these deductions, improving compliance with Swiss tax regulations. This impacts payroll processing for users in Switzerland.
Original PR description
Forward-Port-Of: odoo/enterprise#106615
This update corrects a technical issue where the user ID was missing during payment processing for the pos_iot_six module. The fix restores functionality previously broken by a recent update, ensuring accurate payment tracking and preventing potential errors. This resolves a minor disruption to the payment process.
Original PR description
This PR reinstates https://github.com/odoo/enterprise/pull/98021 broken by https://github.com/odoo/enterprise/pull/98203 This fixes user id being undefined for pos_iot_six payments
This update resolves a technical error that prevented correct display names from being set for spreadsheet cell threads. The change ensures that only one display name is retrieved, preventing a system crash and improving spreadsheet functionality. This update is a critical fix for ensuring data accuracy within the enterprise version.
Original PR description
**Before this change** We were trying to set the `display_name` of one spreadsheet cell thread record to a set of more than one `display_name`s coming from a set of potentially multiple spreadsheets. **After this change** We use `record` instead of `self` when calling `_get_spreadsheet_record` so that it can only return a set of 1 `display_name`, preventing the crash that occurs when trying to set that field value. opw-5380947 Forward-Port-Of: odoo/enterprise#106593 Forward-Port-Of: odoo/enterprise#106230
This update resolves an error that prevented users from generating the required IRAS Audit File for Singapore companies. The fix corrects a coding issue that caused a 'TypeError' during file generation, ensuring accurate reporting for Singapore businesses. This ensures compliance and accurate financial reporting.
Original PR description
Currently, an error occurs when generating the `IRAS Audit File` for a `Singapore` company **Steps to reproduce:** - Install the `l10n_sg_reports` and `accountant` modules (without demo data). -…
Currently, an error occurs when generating the `IRAS Audit File` for a `Singapore` company **Steps to reproduce:** - Install the `l10n_sg_reports` and `accountant` modules (without demo data). - Create a new company with Singapore as the `country` and set `UEN` and `GST No.`, then switch to this company. - Navigate to Accounting > Reporting > Singapore > IRAS Audit File. - Fill in the required details and click `Generate`. **Error:** `TypeError: 'account.account' object is not callable` **Root cause:** After the refactoring in PR [1], the code at [2] mistakenly calls `browse()` without arguments and then attempts to call the returned recordset with `line_account_ids`. Since `browse()` already returns a recordset, this results in calling an `account.account` recordset as a `function`, causing an `error`. **Fix:** This commit prevents an error during IRAS Audit File generation by correcting the `browse()` call to pass `line_account_ids` directly as its argument. [1]: https://github.com/odoo/enterprise/pull/72675 [2]: https://github.com/odoo/enterprise/blob/444f120fbd4e7158b83c609ededf1b2598fc990f/l10n_sg_reports/models/iras_audit_file.py#L210 opw-5877947
This update resolves an issue that caused errors when importing bank transaction files with more than 80 lines. The fix prevents unnecessary database commits during the import process, ensuring stability and reliable operation for users importing large transaction sets. This improves the overall reliability of the bank statement import feature.
Original PR description
*= account_bank_statement_import_csv An exception is currently triggered when a user attempts to import a bank transaction file containing more than 80 transaction lines (see ref file [1]). Steps to…
*= account_bank_statement_import_csv An exception is currently triggered when a user attempts to import a bank transaction file containing more than 80 transaction lines (see ref file [1]). Steps to produce an error: - Install `Accounting (accountant)` module - Go to `Accounting` > Click on `Bank` > Click `Upload` - Upload ref file [1] and click `Test/Import` >>> Error occurs Error: `psycopg2.errors.SerializationFailure: could not serialize access due to concurrent update` Error from 19.0: `InvalidSavepointSpecification : savepoint "ef05b579-df3f -11f0-bc75-74563c5c983f" does not exist` The issue occurs because, in `model.py` code line [2] creates a `savepoint`. Before this `savepoint` is closed, code line [3] is triggered during the creation of the bank statement line [4] and attempts to commit the cursor using `self.env.cr.commit()`. Because a commit is executed while the savepoint is still active, the system fails when trying to close the previously created savepoint. This commit fixes the issue by avoiding cursor commits during the import process. The `import_file=True` flag is added to the context when `_cron_try_auto_reconcile_statement_lines` is called from `execute_import`, allowing the method to safely skip commit/rollback logic when `import_file` is present in the context. [1]: https://docs.google.com/spreadsheets/d/19hKnR8pGB27xkbEHgYYXIkBaPXV8RZZE/edit?usp=sharing&ouid=111844484867458262929&rtpof=true&sd=true [2]: https://github.com/odoo/odoo/blob/11c469086cb4d08453a70cd7bd30d7391f635ae3/odoo/orm/models.py#L971-L973 [3]: https://github.com/odoo/enterprise/blob/2683b77cd6688877c308d0733bccfc5ad84530c1/account_accountant/models/account_bank_statement.py#L218 [4]: https://github.com/odoo/enterprise/blob/2683b77cd6688877c308d0733bccfc5ad84530c1/account_accountant/models/account_bank_statement.py#L1780 sentry-6974536471 opw-5359810 Forward-Port-Of: odoo/enterprise#102760
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 impacts users creating invoices through the Studio interface.
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
8 changes
Resolved issues and error corrections
This update fixes an issue in the French P&L report where accounts 65 were incorrectly categorized. The accounts have been moved to the 'Other Expenses' line, ensuring accurate financial reporting. This improves the clarity and reliability of financial data for French users.
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 an issue where failure messages weren't shown when a quality check was marked as failed. The fix ensures that failure messages are correctly displayed after a quality check is marked as failed, providing better visibility into manufacturing process issues. This improves operational efficiency and quality control.
Original PR description
*= quality_control, quality_mrp_workorder, mrp_workorder Currently, when a user fails a quality check using the quick-action button, the failure message defined for that quality control point isn’t…
*= quality_control, quality_mrp_workorder, mrp_workorder Currently, when a user fails a quality check using the quick-action button, the failure message defined for that quality control point isn’t shown. **Steps to produce:** * Install `Quality` and `Manufacturing` with demo data * Go to MRP > Configuration > Operations > Manual Assembly * Create a pass/fail quality point with a failure message * Create and confirm an MO for `Table Top` * Go to Shop Floor > Activate work centers if inactive > Manual Assembly * Fail the assembly using the quick-action button Replication video: [Link](https://drive.google.com/file/d/1gBHrvQEAavhjU4lS-bKQHQjAa9qDHj6-/view?usp=sharing) **Observed Behavior:** * No failure message is displayed when the quality check is failed. **Root cause:** * This happens because pressing the quick-action button triggers `failCheck` [1] , which calls `doActionNext` [2], which then runs the server function `action_fail_and_next` [3]. That function sets `quality_state = fail` and calls [4] to get the view. But since [3] wraps that view inside a dictionary, the check in [5] never passes, so the message never appears. **Solution:** * Pass the view correctly to display the failure message. Since the quick action already marks the quality state as failed we can hide the Confirm and Back buttons by passing the context and checking it in the view to show a single OK button, similar to earlier versions. **Before:** <img width="1673" height="813" alt="image" src="https://github.com/user-attachments/assets/029e347b-5f2c-463a-833e-3b55677137b6" /> **After:** <img width="1687" height="829" alt="image" src="https://github.com/user-attachments/assets/e4c85093-ea0d-44ca-bc9c-0fab5ac08fbc" /> [1]: https://github.com/odoo/enterprise/blob/59c06537d82fedd1916b7aeb808dc73904f6a751/quality_mrp_workorder/static/src/mrp_display/quality_check.js#L83-L86 [2]: https://github.com/odoo/enterprise/blob/59c06537d82fedd1916b7aeb808dc73904f6a751/mrp_workorder/static/src/mrp_display/mrp_record_line/quality_check.js#L147-L163 [3]: https://github.com/odoo/enterprise/blob/59c06537d82fedd1916b7aeb808dc73904f6a751/quality_mrp_workorder/models/quality.py#L86-L89 [4]: https://github.com/odoo/enterprise/blob/59c06537d82fedd1916b7aeb808dc73904f6a751/quality_mrp_workorder/models/quality.py#L48-L68 [5]: https://github.com/odoo/enterprise/blob/19.0/mrp_workorder/static/src/mrp_display/mrp_record_line/quality_check.js#L154-L161 opw-5403465
This update resolves an issue where folded (closed) tickets were incorrectly displayed in the helpdesk mail plugin, causing confusion for users. The fix filters out tickets in the 'folded' stage, ensuring that only active tickets are shown, improving the plugin's accuracy and usability.
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 fixes a misleading error message displayed when validating Argentine electronic invoices (ARCA). The message has been corrected to accurately reflect the issue: the invoice date must be after the last validated invoice, not before. This ensures proper compliance with AFIP regulations and prevents incorrect invoice processing.
Original PR description
WSFE error 10016-1 must be "The invoice date cannot be before the last invoice validated in AFIP." instead of "The invoice date cannot be after the last invoice validated in AFIP". Steps to reproduce: validate argentinean customer electronic invoice with invoice date before than the last invoice date validated in ARCA. Task Adhoc side: 44290 Task latam: 1376 Forward-Port-Of: odoo/enterprise#106305
This update resolves an issue related to the transmission of coordination deductions for Swiss payroll (l10n_ch_hr_payroll_elm_transmission_5_3). The fix ensures accurate calculations and reporting of these deductions, aligning with Swiss tax regulations. This improves the reliability of payroll processing for our Swiss clients.
Original PR description
Forward-Port-Of: odoo/enterprise#106615
A bug preventing infinite scrolling of recent VoIP calls in the softphone has been fixed. This issue was specific to Chrome browsers and has been resolved by adding a minimal width and height to the scrolling element, ensuring all calls are displayed correctly. This improves the user experience for accessing call history.
Original PR description
Since [1], the voip calls infinite scrolling does not work anymore. Steps to reproduce: - Make sure to have at least 14 recent calls - Open the softphone - Go to the recent/history tab - Scroll to…
Since [1], the voip calls infinite scrolling does not work anymore. Steps to reproduce: - Make sure to have at least 14 recent calls - Open the softphone - Go to the recent/history tab - Scroll to the end => You are stuck seeing only the 13 last calls. This was a Chrome-only issue, it works on Firefox. Weirdly, the infinite scrolling works on the contact tab on Chrome too, although this is the exact same implementation and configuration. This is due to the unreliable behavior of IntersectionObserver regarding 0x0 elements. The infinite scrolling implementation in VoIP relies on the visibility of a "dummy" `<span/>` added at the end of the tab. That element has no width or height, making the implementation unreliable. As a stable minimal fix, this restores the feature by making the element have a width and height, without any visual/behavior changes thanks to negative margins and no pointer events on the item. Note that [1] disabled a test that was testing the feature. This commit of course re-enables it. [1]: https://github.com/odoo/enterprise/commit/52b3065993c41c6b7c65dda586a66fdd865b3afd
This update resolves an issue that caused errors when importing bank statements with more than 80 transactions. The fix prevents unnecessary database commits during the import process, improving stability and allowing users to successfully upload and process larger bank statement files. This ensures reliable bank transaction import functionality.
Original PR description
*= account_bank_statement_import_csv An exception is currently triggered when a user attempts to import a bank transaction file containing more than 80 transaction lines (see ref file [1]). Steps to…
*= account_bank_statement_import_csv An exception is currently triggered when a user attempts to import a bank transaction file containing more than 80 transaction lines (see ref file [1]). Steps to produce an error: - Install `Accounting (accountant)` module - Go to `Accounting` > Click on `Bank` > Click `Upload` - Upload ref file [1] and click `Test/Import` >>> Error occurs Error: `psycopg2.errors.SerializationFailure: could not serialize access due to concurrent update` Error from 19.0: `InvalidSavepointSpecification : savepoint "ef05b579-df3f -11f0-bc75-74563c5c983f" does not exist` The issue occurs because, in `model.py` code line [2] creates a `savepoint`. Before this `savepoint` is closed, code line [3] is triggered during the creation of the bank statement line [4] and attempts to commit the cursor using `self.env.cr.commit()`. Because a commit is executed while the savepoint is still active, the system fails when trying to close the previously created savepoint. This commit fixes the issue by avoiding cursor commits during the import process. The `import_file=True` flag is added to the context when `_cron_try_auto_reconcile_statement_lines` is called from `execute_import`, allowing the method to safely skip commit/rollback logic when `import_file` is present in the context. [1]: https://docs.google.com/spreadsheets/d/19hKnR8pGB27xkbEHgYYXIkBaPXV8RZZE/edit?usp=sharing&ouid=111844484867458262929&rtpof=true&sd=true [2]: https://github.com/odoo/odoo/blob/11c469086cb4d08453a70cd7bd30d7391f635ae3/odoo/orm/models.py#L971-L973 [3]: https://github.com/odoo/enterprise/blob/2683b77cd6688877c308d0733bccfc5ad84530c1/account_accountant/models/account_bank_statement.py#L218 [4]: https://github.com/odoo/enterprise/blob/2683b77cd6688877c308d0733bccfc5ad84530c1/account_accountant/models/account_bank_statement.py#L1780 sentry-6974536471 opw-5359810
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 stability. This change primarily impacts users working in Studio mode.
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
9 changes
Resolved issues and error corrections
This update fixes an issue in the French P&L report where accounts 65 were incorrectly categorized. The accounts have been moved to the 'Other Expenses' line, ensuring accurate financial reporting and alignment with French accounting standards. This improves the clarity and reliability of the financial data.
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 fixes a visual inconsistency in the Field Service Report generated from the Bubble document layout. Previously, table borders had conflicting styles, creating an uneven appearance. The fix ensures a consistent, professional look for these reports.
Original PR description
Steps to reproduce: -------------------------------- 1. Install `industry_fsm_sale` module 2. Go to Settings > Configure Document Layout 3. Select the Bubble document layout and save 4. Open any…
Steps to reproduce: -------------------------------- 1. Install `industry_fsm_sale` module 2. Go to Settings > Configure Document Layout 3. Select the Bubble document layout and save 4. Open any Field Service task 5. Use the Products smart button to add one or more products 6. Click the Settings icon > Print > Field Service Report Observation: -------------------------------- In Time & Material tables using the Bubble layout, table borders show a mix of rounded corners and sharp edges, resulting in inconsistent visuals Issue: -------------------------------- The table tags in the report were missing the `table-borderless` class. As a result, the layout-applied rounded borders conflicted with the default table borders Solution: -------------------------------- Add the `table-borderless` class to the affected table tags so the tables inherit consistent rounded borders from the document layout Before: <img width="787" height="317" alt="before_css" src="https://github.com/user-attachments/assets/dac136a8-022a-4c36-8cdb-1c0fbb048f3e" /> After: <img width="816" height="372" alt="after_css" src="https://github.com/user-attachments/assets/b5f96e75-2cd3-44cf-89e3-9a3b564c8369" /> opw-5401612
This update resolves a technical issue that prevented users from creating invoices with non-deductible tax values. The fix avoids a SQL error that occurred when attempting to calculate tax on unsaved invoice lines, ensuring accurate tax reporting.
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#106470
This update resolves an issue where closed tickets with high priority were incorrectly displayed in the helpdesk mail plugin. The fix filters out tickets in the 'folded' stage, ensuring users only see active, open tickets for each contact. This improves the plugin's accuracy and usability.
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 corrects a misleading error message displayed when validating Argentine electronic invoices (ARCA). The message has been changed to accurately reflect that an invoice date before the last validated invoice is the issue, not one after. This ensures proper invoice processing and avoids confusion for users.
Original PR description
WSFE error 10016-1 must be "The invoice date cannot be before the last invoice validated in AFIP." instead of "The invoice date cannot be after the last invoice validated in AFIP". Steps to reproduce: validate argentinean customer electronic invoice with invoice date before than the last invoice date validated in ARCA. Task Adhoc side: 44290 Task latam: 1376 Forward-Port-Of: odoo/enterprise#106305
This update resolves an issue with the calculation of coordination deductions in the Swiss payroll module (l10n_ch_hr_payroll_elm_transmission_5_3). The fix ensures accurate reporting of deductions related to coordination payments, improving compliance with Swiss tax regulations. This change impacts payroll processing for Swiss businesses using Odoo Enterprise.
Original PR description
Forward-Port-Of: odoo/enterprise#106615
This update resolves an issue where Modelo 390 reports were incorrectly generating empty BOE files. The fix ensures the reports accurately reflect data for the specified year by correctly identifying the report period. This guarantees accurate tax reporting for Spanish companies.
Original PR description
### Issue: When exporting Modelo 390 reports for a past year, the BOE file was empty — all values were 0 ### Cause: In `export_boe()`, the `report_lines` were get based on the `section_report`…
### Issue: When exporting Modelo 390 reports for a past year, the BOE file was empty — all values were 0 ### Cause: In `export_boe()`, the `report_lines` were get based on the `section_report` options However, `section_reports` do not store the date or return periodicity of the selected report As a result, using their options always fetched data for the current period instead of the specified year ### Note: `_generate_mod_390_page2()` also had issues: some lines were missing or incorrectly indexed The mod 360 format, it strict in the structure with specific index so it may produce invalid documents The latest documentation for mod 390: https://sede.agenciatributaria.gob.es/static_files/Sede/Disenyo_registro/DR_300_399/archivos_25/dr390e2025.xlsx ### Steps to reproduce: - Install `l10n_es_reports` and switch to ES Company - Create an Invoice and a Bill (Any product, Price: 100.00, Tax: 21%, Invoice Date: 01/01/2025) - Open Tax Return, switch to Mod 390, and set year to 2025 - You should see data in the 2 first sections - Use the gear icon, and download the BOE - Use the gear icon to download the BOE, fill the wizard (Natural Person – Name: Test, Principal activity: Test, Activity Code: 12345), and generate the file Before the fix: all values in the BOE were 0 instead of matching the report opw-5457374 Forward-Port-Of: odoo/enterprise#106542 Forward-Port-Of: odoo/enterprise#104928
This update fixes an issue where month names were incorrectly displaying based on the user's locale instead of the Odoo environment's language. This ensures that month names are consistently shown in the correct language for each user, improving accuracy and user experience. The change impacts several payroll and reporting modules.
Original PR description
Month name is using the locale language instead of the env language Get month name in the env language Community PR: odoo/odoo#246790 Task [link](https://www.odoo.com/odoo/project.task/5902364) task-5902364 Forward-Port-Of: odoo/enterprise#106175
This update improves the accuracy of the Kardex report for Peruvian exports by incorporating landed costs and price adjustments, which were previously missing. The changes also address mapping issues and ensure correct operation types are used, leading to more reliable inventory reporting.
Original PR description
Refactored the logic to generate the Kardex report based on `stock.valuation.layer`, for the following reasons: 1. **Landed costs**: These must be considered in the report. Odoo already creates…
Refactored the logic to generate the Kardex report based on `stock.valuation.layer`, for the following reasons: 1. **Landed costs**: These must be considered in the report. Odoo already creates valuation layers for landed costs, and the report must use the date when the landed cost was recorded, not the original stock move date. 2. **Price adjustments**: Product price adjustments generate valuation layers without stock moves. These layers are now included in the report. Additional fixes and improvements: - Correctly map columns 18 to 26 in Report 13.1: - 18–20: Incoming movements - 21–23: Outgoing movements - 24–26: Final balance - Ensure `cost_in` and `cost_out` values are always positive. The sign now depends on the movement quantity, not the unit cost. - Replace the product list with a dictionary to track accumulated quantities and values per product for accurate balance calculation. - Extend test coverage to include cases where the report includes opening balances due to past transactions. - **MRP movements**: MRP processes don’t generate pickings, but their stock moves are linked to operation types. The report now uses codes `19` for incoming and `27` for outgoing MRP-related movements. - **Reversal of pickings**: Since Odoo copies the original picking and skips reassignment logic, we now override the reversal wizard to set the correct PE operation type: - `25` for incoming reversals - `24` for outgoing reversals - Force operation type `99` for all `A1` lines, as required by the report. - Ensure report dates are processed in the user's timezone for consistency with the layer view in Odoo. Forward-Port-Of: odoo/enterprise#88592
28 changes
Resolved issues and error corrections
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
14 changes
Resolved issues and error corrections
This update fixes an issue where Odoo didn't correctly reconcile bank transactions with credit notes. Now, when a credit note is applied to an invoice and the bank transaction is marked as 'fully paid', the system accurately reflects the remaining balance owed. 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 fixes an issue in the French P&L report where accounts 65 were incorrectly categorized. The accounts have been moved to the 'Other Expenses' line, ensuring accurate financial reporting. This improves the clarity and reliability of the French financial statements.
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 an issue where subscription cancellations for internal users (like 'Mitchel Admin') would trigger access errors. The fix uses 'sudo' to allow necessary data updates on the partner record during cancellation, ensuring the process runs smoothly. This prevents disruptions to subscription management.
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 resolves an issue where users with specific access rights were incorrectly identified as administrators, causing errors when accessing the AI Documents app. A stricter access check has been implemented to ensure proper functionality for users with 'User' roles, specifically allowing them to use the 'Sort with AI' feature.
Original PR description
Before this commit: If a user with the role 'User' has access to 'Access rights', it puts the user in `base.group_erp_manager` making `is_admin()` return `True`. Resulting in an access error when opening the documents app. After this commit: A more strict check is added for accessing ai_documents fields. Task-5375110 parent support ticket-5270005
This update ensures that the 'Pay Now' link in subscription payment flows only appears when the advanced payment section is visible. This prevents confusing links from showing up when products associated with the subscription have been archived, leading to a cleaner and more user-friendly experience for customers.
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#105802 Forward-Port-Of: odoo/enterprise#105480
This update resolves an issue where closed tickets with high priority were incorrectly displayed in the Odoo Mail Plugin. The fix filters out tickets in 'folded' stages, ensuring users only see active tickets related to their contacts. This improves the plugin's usability and 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 fixes a test within the l10n_mx_edi module to accurately reflect recent changes to how CFDI export ZIP files are generated. Previously, the test only checked for the CFDI XML, but now it includes all attachments from the mail thread (like PDFs) ensuring the export is fully compliant. This ensures accurate reporting and compliance for Mexican tax filings.
Original PR description
Before this commit: The test assumed that extra_print_items only included the CFDI XML, as the ZIP export previously contained only PDF documents. After this commit: The test now reflects the updated ZIP export behavior introduced by task-5232551, where all attachments from the mail thread are included (PDF, XML, etc.). task-5232551 --- I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)
This update fixes a minor issue where the system wasn't correctly processing weight readings from the scale, particularly when using the 'read_once' action. Now, the system reliably handles all weight readings, ensuring accurate inventory tracking and preventing potential data discrepancies. This backports a fix from a previous enterprise release.
Original PR description
This commit adjusts the callback when a new weight is received from the scale to also handle the case where it is the response to the `read_once` action. In this case, the `status` key is `success`. backport of: odoo/enterprise#105324
This update corrects a previous error in the MRP Workorder module that prevented the automatic generation of serial numbers when production quantities were specified. The fix ensures that necessary serials are created, aligning with the desired workflow and avoiding disruptions to the manufacturing process. This change improves the reliability of production order fulfillment.
Original PR description
This commit update the test since the fix commit introduced a new behavior. Before if the manufacturing had qty_producing, it would not set the move to picked and raise an error because there is no lot. With the fix, when the production has qty_producing. It will generate the missing serial. We prefer this behavior to the old ones so we keep it.
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 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 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
This update resolves an issue impacting the calculation of coordination deductions for Swiss payroll (l10n_ch_hr_payroll). The fix ensures accurate reporting of these deductions, aligning with Swiss tax regulations. This improves the reliability of payroll reporting for our Swiss clients.
Original PR description
Forward-Port-Of: odoo/enterprise#106615
This update resolves a bug where changing a commission plan's frequency (e.g., from quarterly to monthly) didn't correctly remove outdated periods, leading to incorrect commission calculations. The fix ensures that old periods are removed when the target frequency is updated, preventing overlapping commission targets and inaccurate invoice 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-5877405A recent update in Odoo 19.0 has caused the Kanban view for manufacturing orders to show all active orders instead of those related to the selected operation type. This fix ensures that the Kanban view correctly filters manufacturing orders based on the chosen operation type, improving usability and accuracy.
Original PR description
**Steps to reproduce:** * Install the *stock_barcode_mrp* module. * Go to *Inventory* ‣ *Configuration* ‣ *Operation Types*. * Create two operation types with *Type of Operation* set to…
**Steps to reproduce:**
* Install the *stock_barcode_mrp* module.
* Go to *Inventory* ‣ *Configuration* ‣ *Operation Types*.
* Create two operation types with *Type of Operation* set to *Manufacturing*.
* Create two manufacturing orders.
* In each manufacturing order, under the *Miscellaneous* tab
set a different *Operation Type* created above.
* Ensure sufficient *On Hand Quantity* exists for a product used in manufacturing.
* Open the *Barcode* application.
* Open one of the created manufacturing operation types.
**Observed behavior:**
* The kanban view displays **all** manufacturing orders whose picking
types are active, instead of only those related to the selected operation type.
**Cause:**
* In 19.0, the context key *`'search_default_picking_type_id': self.id`* was removed
from `_get_action` function in this [commit](https://github.com/odoo/odoo/commit/9ed7109b8f11260084374f2d7fa7073a9ad3c240)
* Previously, this context value restricted results to the current picking type by default.
* The method `get_action_picking_tree_ready_kanban` in *stock_barcode_mrp*
now overrides the domain with only *`('picking_type_id.active', '=', True)`*.
* This domain checks that the picking type is active but does not filter by
the selected picking type, causing unrelated MOs to be shown.
**Fix:**
* This ensures only manufacturing orders belonging to
the selected operation type are displayed.
---
opw-5819358This update addresses key changes required for Belgian payroll reporting under the 281.10, 281.45, and 281.XX tax schemes. Specifically, it updates data schemas and declaration values to align with the latest regulations for 2025 and incorporates reporting up to 2026, ensuring accurate and compliant payroll processing for Belgian businesses.
8 changes
Resolved issues and error corrections
This update fixes a misleading error message displayed when validating Argentine electronic invoices (ARCA). The message has been corrected to accurately reflect the issue: the invoice date must be after the last validated invoice, not before. This ensures proper compliance with AFIP regulations.
Original PR description
WSFE error 10016-1 must be "The invoice date cannot be before the last invoice validated in AFIP." instead of "The invoice date cannot be after the last invoice validated in AFIP". Steps to reproduce: validate argentinean customer electronic invoice with invoice date before than the last invoice date validated in ARCA. Task Adhoc side: 44290 Task latam: 1376 Forward-Port-Of: odoo/enterprise#106305
This update resolves an issue with 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 fixes an issue where registering payments on payslips incorrectly affected multiple journal entries, leading to payment inconsistencies. Now, payments are reliably registered on the specific NET payable line, ensuring accurate payment tracking and a more reliable ‘Paid’ status for payslips. This improves the payroll accounting process.
Original PR description
## Behavior before When registering a payment from a payslip, the action opened the payment register wizard on **all** journal entry lines (`move_id.line_ids`). This could: - produce an inconsistent…
## Behavior before When registering a payment from a payslip, the action opened the payment register wizard on **all** journal entry lines (`move_id.line_ids`). This could: - produce an inconsistent payment wizard (because it’s not anchored to a single payable/receivable line), - reconcile against unintended lines, - and fail to reliably trigger the **Paid** transition. Additionally, after reconciliation, the payslip was marked as **Paid** only if **all** journal entry lines had zero residual, which is not a reliable indicator of whether the employee **NET payable** has been fully paid. ## Behavior after - The payslip **Register Payment** action now opens the payment register wizard only on the payslip’s **NET payable** move line (credit line on the NET salary rule’s credit account, with the employee work contact as partner). - After reconciliation, the payslip is marked as **Paid** once its **NET payable** line(s) are fully reconciled (residual is zero), and the wizard posts chatter messages linking the payment and the payslip (preserving upstream behavior). ## Root cause Two issues combined: 1. The payment register wizard was invoked on `move_id.line_ids` instead of on the payable line(s) only. The wizard is designed to work on payable/receivable lines; opening it on all move lines breaks assumptions and can lead to incorrect behavior. 2. The **Paid** transition relied on checking residuals for **all** move lines, which does not correctly represent “employee NET salary has been paid”. Only the residual of the **NET payable** line is relevant for payroll payment completion. ## Steps to reproduce 1. Ensure the company is configured for the **individual payslip accounting entry** workflow (one journal entry per payslip), and that the **NET** salary rule has a **reconcilable** credit account. 2. Validate a payslip so it generates a **posted** journal entry containing a **NET credit** line. 3. Open the payslip and click **Register Payment**. 4. Observe that the wizard is opened on **all** move lines (not just the **NET payable** line), and payment/reconciliation behavior can be inconsistent. 5. Register and post the payment; observe that the payslip may fail to transition to **Paid** unless **all** move lines are fully reconciled.
This update resolves a bug that caused accounting reports to fail when formulas resulted in a zero denominator. The fix ensures that calculations within reports are handled correctly, preventing errors and improving report reliability. This ensures accurate reporting for deferred revenue and other financial data.
Original PR description
Currently, an error occurs when opening an `accounting report` when the evaluated data produces a `zero denominator` during formula computation. **Steps to reproduce:** - Install the…
Currently, an error occurs when opening an `accounting report` when the evaluated data produces a `zero denominator` during formula computation. **Steps to reproduce:** - Install the `account_reports` module (without demo) and enable `developer mode`. - Navigate to Accounting > Reporting > Deferred Revenue. - Click the `gear icon` to open the report configuration. - Click `Add a line` to create a new report line. - Click `Add a line` to create a new expression with: >- Computation Engine: `Aggregate Other Formulas` >- Formula: `0/0` - Save the new expression and report line. - Try to reopen the `Deferred Revenue`. **Error:** `ZeroDivisionError: division by zero` **Root Cause:** After commit [1], at [2], expressions without the `ignore_zero_division` subformula are evaluated in the else condition, causing an error when the `denominator is zero`. **Fix:** This commit prevents errors caused by zero denominators during formula evaluation and improves the clarity of the resulting error messages. [1]: https://github.com/odoo/enterprise/commit/2ba548564bd0bb68c36a589ed67b43251b5f45d0 [2]: https://github.com/odoo/enterprise/blob/7adab8bfdccf5f0e97eb2894e065b63ea8200d20/account_reports/models/account_report.py#L3540-L3547 opw-5475146
This update fixes an issue where newly created appointments with future dates incorrectly set the lead's activity deadline to today's date. The fix ensures the deadline aligns with the appointment's scheduled date, improving the accuracy of opportunity tracking and follow-up reminders. This change enhances the user experience for scheduling and managing appointments.
Original PR description
When creating a future appointment via the backend, the generated lead's activity deadline is incorrectly set to today instead of the appointment date. ### Steps to reproduce - Install…
When creating a future appointment via the backend, the generated lead's activity deadline is incorrectly set to today instead of the appointment date. ### Steps to reproduce - Install `appointment_crm`. - Go to Appointments > Schedule > Staff Booking. - Create a booking for a future date (e.g., next month) and add a customer. - Confirm the booking. - Open the newly created Opportunity. - Check the "Next Activity" deadline. - It is set to today's date instead of the appointment's date. ### Cause The `calendar.event` model maintains two sets of fields for timing: `start`/`stop` (Datetime) and `start_date`/`stop_date` (Date). Standard logic dictates that `start_date` and `stop_date` are only populated for All Day events (`allday=True`). For regular time-specific events, these fields are computed as `False` to avoid ambiguity. When an appointment is created, `appointment_crm` generates a linked CRM Lead and schedules an activity. The code responsible for scheduling this activity (`activity_schedule`) was explicitly passing `event.start_date` as the `date_deadline`. Since standard backend appointments are time-specific (not all-day), `event.start_date` is `False`. The `activity_schedule` method defaults to the current date (Today) when it receives a falsy value for the deadline. Consequently, creating a future appointment resulted in an immediate deadline. ### Fix Modify the lead creation logic to use the standard calendar helper `_get_activity_deadline_from_start`. opw-5780578
This update resolves an issue where journal items displayed in reports were incorrectly linked to account groups, causing errors in Odoo 18.3 and later. The fix ensures accurate reporting by adjusting how account group IDs are handled within the report's data retrieval process.
Original PR description
Currently journal items shown don't belong to the account group that they should belong to, and from saas-18.3 an error will be generated after following the below steps or step mentioned in ref PR…
Currently journal items shown don't belong to the account group that they should belong to, and from saas-18.3 an error will be generated after following the below steps or step mentioned in ref PR [1]. - Install `Accounting (accountant)` with demo data - Create account groups e.g., name as `Test 1` and code prefix `1 to 1` - Go to the general ledger report - Click on `Journal Items` of the account group line `1 Test 1` Error from saas-18.3: `ValueError: Cannot convert account.account.group_id to SQL because it is ...` This error occurs because PR with ref [1] in 17.0 added the` group_id` field of the `account.account` model to the search domain. However, in 18.0, commit [2] modified this field so that it is no longer stored. As a result, when a search domain includes this `non-stored` field, Odoo skips the domain evaluation and logs a error at code line [3]. Consequently, the changes introduced by commit [1] have no functional effect from 18.0. Also, starting from saas-18.3, passing such a non-stored field in a domain raises an explicit error at code line [4], instead of being silently ignored. This commit resolves the issue by introducing an SQL query that returns the account ids related to `record_id(account group id)` include `record_id` as `None`. [1]: https://github.com/odoo/enterprise/pull/100191 [2]: https://github.com/odoo/odoo/commit/854c3b27aa5476c208572f19e64f8f3364bfc381#diff-19ef5a530c506fdee93fe0d113e61946b87fae7dd2d360558da69c0014f766b2R114-R767 [3]: https://github.com/odoo/odoo/blob/71e86f38c7699aaea980c929c67835a3495edf55/odoo/osv/expression.py#L1166-L1174 [4]: https://github.com/odoo/odoo/blob/00517e9e085c6fa9e00bedb8aee122a60e407fea/odoo/orm/fields.py#L1201 sentry-7100657414
This update improves the accuracy of the Kardex report for Peruvian businesses by correctly incorporating landed costs and price adjustments, which were previously missing. The changes also address mapping issues and ensure consistent reporting across different movement types, ultimately providing more reliable inventory data.
Original PR description
Refactored the logic to generate the Kardex report based on `stock.valuation.layer`, for the following reasons: 1. **Landed costs**: These must be considered in the report. Odoo already creates…
Refactored the logic to generate the Kardex report based on `stock.valuation.layer`, for the following reasons: 1. **Landed costs**: These must be considered in the report. Odoo already creates valuation layers for landed costs, and the report must use the date when the landed cost was recorded, not the original stock move date. 2. **Price adjustments**: Product price adjustments generate valuation layers without stock moves. These layers are now included in the report. Additional fixes and improvements: - Correctly map columns 18 to 26 in Report 13.1: - 18–20: Incoming movements - 21–23: Outgoing movements - 24–26: Final balance - Ensure `cost_in` and `cost_out` values are always positive. The sign now depends on the movement quantity, not the unit cost. - Replace the product list with a dictionary to track accumulated quantities and values per product for accurate balance calculation. - Extend test coverage to include cases where the report includes opening balances due to past transactions. - **MRP movements**: MRP processes don’t generate pickings, but their stock moves are linked to operation types. The report now uses codes `19` for incoming and `27` for outgoing MRP-related movements. - **Reversal of pickings**: Since Odoo copies the original picking and skips reassignment logic, we now override the reversal wizard to set the correct PE operation type: - `25` for incoming reversals - `24` for outgoing reversals - Force operation type `99` for all `A1` lines, as required by the report. - Ensure report dates are processed in the user's timezone for consistency with the layer view in Odoo. Forward-Port-Of: odoo/enterprise#88592
This update simplifies the sales order interface for subscription customers. It hides a confusing 'remaining hours' field that could mislead users about their service consumption. This change ensures a cleaner, more intuitive experience for subscription customers, aligning with the recurring delivery model.
Original PR description
This change hides the `remaining_hours_so` field when the sales order line is linked to a subscription. Unlike standard service or time-based sales orders, where this field reflects the difference between the quantity ordered and the quantity delivered, the concept does not translate well to subscription logic. In the context of a subscription, the service is delivered on a recurring period (monthly, yearly, etc.). Delivery quantities continuously accumulate over time, and because the subscription renews indefinitely until cancellation, the “remaining hours” calculation quickly becomes misleading. In many cases it can drift into negative values, giving the impression of an error or over-consumption when, in reality, the subscription is simply following its recurring delivery cycle. To avoid confusing end-users and to maintain a clean, intuitive interface, we hide this field whenever the line is part of a subscription. opw-5246238
4 changes
Resolved issues and error corrections
This update resolves an issue with the calculation of coordination deductions in the Swiss payroll module (l10n_ch_hr_payroll_elm_transmission). The fix ensures accurate reporting of these deductions to the Swiss tax authorities, aligning with updated regulations. This improves the reliability of payroll reporting for Swiss businesses.
This update corrects a bug where the email address for Belgian company contacts was missing from VAT reports when an invoice address wasn't specified. The fix automatically pulls the email from the contact's parent record, ensuring accurate reporting and compliance. This prevents data discrepancies in exported XML reports.
Original PR description
**Steps to reproduce:** - Install l10n_be_reports and contacts - Switch to a Belgian company (e.g. BE Company CoA) - Go to Contacts - Open the company contact (i.e. BE Company CoA) - Add an invoice address withtout email - Create an invoice: * Customer: [a Belgian customer with a VAT number] * Invoice Lines: [a line with a tax] - Confirm the invoice - Go to "Accounting / Reporting / Belgium / Partner VAT Listing" - Export the XML **Issue:** In the XML, "<EmailAddress>" is empty althouth it is mandatory. **Cause:** The email is retrieved from the invoice address, but there is no fallback on the parent contact if it is empty. **Solution:** Fallback on the email of the parent contact as it is the case for the phone. opw-5870750
This update adjusts the taxonomy used for Dutch tax reports to the latest NT20 standard. This change ensures compliance with current Dutch tax regulations and maintains compatibility with older versions of the reporting templates. No new functionality was added.
Original PR description
The taxonomy for the Dutch tax reports was updated from NT19 to NT20. There were only changes in the namespaces. Olders versions of the XBRL template are kept for backwards compatibility. task-4568359
This update resolves an issue where withholding tax moves in the Spanish accounting reports were incorrectly assigning a 'type for 347' field. The change ensures this field is left blank, aligning with Spanish tax regulations and improving the accuracy of financial reporting. This update ensures compliance and reliable reporting for Spanish businesses using Odoo Enterprise.
Original PR description
- Moves that use withholding taxes should have the `type for 347` unselected and left blank. Related PR : https://github.com/odoo/odoo/pull/245828 task-5732679