Friday, February 6, 2026
26 changes · saas-19.1
Resolved issues and error corrections
This update resolves an issue where processing refunds for returned POS orders with shipped original orders would cause an error. The fix ensures that picking values are generated correctly, regardless of whether the original order was shipped, allowing for seamless refund processing. This improves the reliability of the POS refund functionality.
Original PR description
Currently, an error occurs when processing the payment of a return POS order whose original order has already been shipped. **Steps to Reproduce:** 1. Install the stock and pos modules with demo…
Currently, an error occurs when processing the payment of a return POS order whose original order has already been shipped. **Steps to Reproduce:** 1. Install the stock and pos modules with demo data. 2. In config, activate the "**Allow Ship Later**" for _Furniture Shop_. 3. Open register and create an order with a Ship Later date. 4. Inventory > Delivery Orders > Validate the picking generated for that order. 5. Open original POS order (form), click "**Return Products**". 6. Open the returned order, click "**Payment**" and make the payment. **Error:** `ValueError - Expected singleton: pos.order(2, 1)` **Cause:** At [1], `reference_ids.pos_order_ids` is a many2many relation, but the logic assumes it contains only a single order. As a result, accessing `order.session_id.id` or `order.id` raises a singleton error when multiple related orders are present. **Fix:** This commit ensures that picking values are generated using a single pos order reference by selecting the relevant one from the multiple pos orders. [1] - https://github.com/odoo/odoo/blob/569b2e27699a76f9bac210e61b47f8a5708c814b/addons/point_of_sale/models/stock_picking.py#L157-L160 sentry- 7071798497 Forward-Port-Of: odoo/odoo#238467
This update fixes an issue where invoices created in one company could incorrectly use accounts from a different company. The change adds a validation check to ensure that invoice line accounts always belong to the invoice's company, preventing accounting inconsistencies and improving data accuracy.
Original PR description
### Issue: When an invoice is created for a company and then its company and journal are changed to another company valid combination, the accounts on the invoice lines are not updated automatically This leads to inconsistencies where move lines use accounts that do not belong to the move’s company ### Cause: A validation check ensuring that move line accounts belong to `move.company_id` or parents was missing in `_post()` for account moves ### Steps to reproduce: - Create Company A and Company B - Create an invoice on Company A with one line having an account in Company A - Change the invoice company to Company B and set a journal belonging to Company B - Save and confirm the invoice opw-5167958 Forward-Port-Of: odoo/odoo#243243
This update enhances the orderpoint wizard in the stock module, making it easier for users to manage replenishment quantities. Specifically, the wizard now allows users to save desired minimum and maximum quantities, and displays deadlines in red if they've passed. This improves usability and ensures accurate orderpoint tracking.
Original PR description
- if deadline_date is in the past, display it in red - allow the user to save a new min and/or max qty when closing the wizard - make sure the table rows stay in order when saving task 5410931 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240096
This update resolves an issue preventing sales users from creating orders with products having custom value attributes. The fix adjusts security permissions to ensure sale users retain access needed to populate these attributes, addressing a previous restriction that limited functionality. This ensures all users can properly create and manage sale orders.
Original PR description
### Issue: Due to this issue, sale group cannot create a sale order with a product with custom value attribute. #### Steps to reproduce: 1- Create a product using admin with a custom value attribute. 2- Using demo user with sale access group, create a so. 3- Add the created product, and fill the custom value. The sale order cannot be saved due to access error. ### Cause: This is due to #197286. However that shouldn't have been applied to `product.attribute.custom` as that shouldn't be only accessed by people who can manage product like the rest of deleted accesses, but also it's needed by sale groups creating SOs. opw-5498719 Forward-Port-Of: odoo/odoo#247276
This update corrects a technical issue with the URL used to connect to the Polish Electronic Data Interchange (KSeF) system. The change ensures that Odoo can properly transmit and receive data required for Polish tax reporting, maintaining compliance. This fix is crucial for businesses using the Odoo accounting module in Poland.
Original PR description
The production URL for the Polish EDI (KSeF) was incorrect. This commit updates the endpoint to the current valid URL to ensure proper connectivity. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247424
This update fixes a problem where users couldn't select payment method journals if the company wasn't a parent or child of the current POS company. Now, the system prevents users from choosing these invalid journals, ensuring payment methods load correctly and preventing errors in the Point of Sale configuration.
Original PR description
Before this commit: =========== - Selecting a journal for a payment method belonging to a company that was neither a parent nor a child of the current company caused payment methods to fail loading for the POS session, resulting in no payment methods being available for the configuration. After this commit: =========== - Users are now prevented from selecting journals belonging to companies that are neither parent nor child of the current company. task-5158448 Forward-Port-Of: odoo/odoo#241519
This pull request updates the core spreadsheet component (o_spreadsheet) to the latest version, addressing several bugs and improving stability. The changes include fixes for crashes, incorrect calculations, and UI issues, ensuring a smoother user experience when working with spreadsheets within Odoo.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/67a692f068 [REL] 19.1.6 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/67a692f068 [REL] 19.1.6 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/8f34d5715d [FIX] dom_helpers: wait for document ready [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/ce4efeedb2 [FIX] Cell: do not rely on key presence in commands [Task: 5499921](https://www.odoo.com/odoo/2328/tasks/5499921) https://github.com/odoo/o-spreadsheet/commit/23bd59864c [FIX] regexextract : invalid regex throw error [Task: 5892417](https://www.odoo.com/odoo/2328/tasks/5892417) https://github.com/odoo/o-spreadsheet/commit/1f06628b29 [FIX] find_and_replace_store: crash after sheet deletion [Task: 5453311](https://www.odoo.com/odoo/2328/tasks/5453311) https://github.com/odoo/o-spreadsheet/commit/5cc8a0c065 [FIX] evaluation: do not overwrite current sheet [Task: 5868007](https://www.odoo.com/odoo/2328/tasks/5868007) https://github.com/odoo/o-spreadsheet/commit/fd532281cd [FIX] menu: can open empty menu popover [Task: 5863077](https://www.odoo.com/odoo/2328/tasks/5863077) https://github.com/odoo/o-spreadsheet/commit/379894f6bd [FIX] *: fix faulty css zoom detection [Task: 5453400](https://www.odoo.com/odoo/2328/tasks/5453400) https://github.com/odoo/o-spreadsheet/commit/bb484e3428 [FIX] XLSXImport: Fix crash on incomplete xlsx file with external reference [Task: 5499753](https://www.odoo.com/odoo/2328/tasks/5499753) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This update fixes an error in the calculation of VAT payable or refundable on Welsh tax returns. The previous formula incorrectly subtracted input VAT from output VAT. The change updates the formula to accurately reflect the correct calculation – output VAT minus input VAT – ensuring accurate reporting for Welsh businesses.
Original PR description
**Steps to produce:** - Install the l10n_cy and accountant modules - Switch to `CY Company`. - Go to accounting > reports > Tax return. **Issue:** - The formula for VAT payable or refundable (difference between box 4 and 3) is incorrect. - box 3 refers to `Total output VAT` and box 4 refers to `Input VAT`. - Current formula: `cy_4.balance - cy_3.balance` **Fix:** - Formula for VAT payable or refundable should be output VAT - input VAT. - Update the formula to: `cy_3.balance - cy_4.balance` <img width="769" height="86" alt="image" src="https://github.com/user-attachments/assets/923a92f9-fc57-465a-9592-771730ee6870" /> opw-5751369 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247309 Forward-Port-Of: odoo/odoo#246273
This update fixes an error in the Spanish VAT (EDI) invoice generation process. Previously, negative invoice amounts (like discounts) caused incorrect tax calculations. This change ensures accurate VAT and withholding tax calculations, even when negative amounts are used, improving invoice accuracy and compliance.
Original PR description
Issue: When using negative amounts, for example to explicitly show a discount, the tax calculation is incorrect due to the application of the `abs` function. Furthermore, the way to find out if a tax…
Issue:
When using negative amounts, for example to explicitly show a discount, the tax calculation is incorrect due to the application of the `abs` function. Furthermore, the way to find out if a tax is of the withholding type is based on the sign of the value, which can lead to error in these cases.
Cause:
A previous change (#237235) added the `abs` function so the `TotalTaxesWithheld` would be always with positive value. But this also affects the calculation of taxes `TotalTaxOutputs` in some cases, such as if the invoice line has negative values.
Steps to reproduce:
- Install `l10n_es_edi_facturae`
- With the ES company, create an invoice with some standard lines and one line with negative amounts, as an explicit discount
- Confirm the invoice and send (facturae)
- Open the XML attached in the chatter
- Observe that the taxes amounts (VAT and WITHHOLDING) are erroneous
A correct invoice should be for example:
```
Product Price Taxes Amount
---------------------------------------------
PRODUCT-A 1000 21%VAT 15%WHI 1000
Discount -100 21%VAT 15%WHI -100
---------------------------------------------
Untaxed amount 900
Withholding 15% -135
VAT 21% 189
-----------------------
TOTAL 954
```
This PR replaces #240808
---
I confirm I have signed the [CLA](https://github.com/odoo/odoo/pull/157955) and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#244428This update resolves a bug where employees were not being fully removed from 'Basic' and 'Minimal' rights groups within the POS settings. The fix ensures that all employees are correctly removed when group memberships are updated, maintaining accurate user permissions. This prevents inconsistencies in employee access levels.
Original PR description
Steps to reproduce ------------------ 1. Enable "Log in with Employees" 2. Add employee "A" to the "Basic rights" group. 3. Add employee "B" to the "Minimal rights" group. 4. Make sure to remove all…
Steps to reproduce ------------------ 1. Enable "Log in with Employees" 2. Add employee "A" to the "Basic rights" group. 3. Add employee "B" to the "Minimal rights" group. 4. Make sure to remove all other employees from these 2 groups!! 5. Now save and go back to the main settings page, remove employee "A" from "Basic rights" group, such that this group is now empty. 6. Save the changes. Observation -> Employee "A" is still in the group "Basic rights"!! Why the issue ------------- When deleting records from an `x2many` field in pos, from the main settings page, we do not pass the associated `unlink` commands in the arguments of `web_save` when clicking "Save", we just pass an empty commands list `[]`, because the backend, specifically the method `_preprocess_x2many_vals_from_settings_view` will take care of unlinking all the records before applying the new commands. So passing an empty commands list when updating an `x2many` field will be equivalent to saying "Unlink all records for that field, then apply no commands", i.e. just unlink all records for that field. However, after https://github.com/odoo/odoo/commit/1f45b035354bb9040be3aba3a79392e603e870b4, we now filter out updates having an empty commands list, and thus now trying to unlink all records of a `x2many` does not work, since an empty command list will be dropped from the updates, before reaching `_preprocess_x2many_vals_from_settings_view`. The fix ------- We add stricter filtering logic, to keep valid command lists, even when they are empty. opw-5725879 Forward-Port-Of: odoo/odoo#245261
This update resolves a performance issue within the spreadsheet dashboard by ensuring the underlying model is correctly marked as 'raw.' This prevents unnecessary reactivity, significantly improving dashboard loading times. The change addresses a design flaw that made it difficult for developers to manage reactivity correctly.
Original PR description
Since we split o-spreadsheet in two: - core engine, independent from owl and DOM - UI The `Model` doesn't mark itself as raw for owl's reactivity. It must be done manually at every call site where it's needed. Here the entire `DashboardLoader` is made reactive, including its properties. We cannot let the model be reactive as it would hurt performance very badly. From a DX POV, the current situation is a bad design because the developer doesn't know the model needs to be marked as raw, and even if the developer knows it, it's very easy to overlook (as we did and this commit proves) It would be probably better with a private constructor and factory methods with clear names. Task-5916564 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where creating invoices for purchase orders with subcontracted tracked products previously caused errors. The change ensures proper handling of multiple finished product lines, addressing problems related to tracked products, backorder flows, and potential upgrade scripts. This ensures accurate invoicing for these transactions.
Original PR description
Before this commit, creating an invoice for a purchase order with a subcontracted tracked product triggered a singleton error. This commit fixes the issue by properly handling multiple finished move lines for the same product, which occurs with tracked products, some back order flows, and possibly upgrade scripts. OPW-5712931 Forward-Port-Of: odoo/odoo#245880
This update fixes an issue where pasting content into the website editor, particularly within iframes, would unexpectedly remove elements. The change adjusts how the editor handles inline elements, preventing the removal of unremovable content during the pasting process. This ensures a more reliable and predictable experience for website builders.
Original PR description
*: website Before this commit: when a editable container is wrapped inside a non-contenteditable, which could happen inside an iframe, pasting on a selection including an unremovable element will remove the element. This is because the config parameter `allowInlineAtRoot` is false by default, the editable container of Contact us button is considered as the edition boundary, and then `wrapInlinesInBlocks` is called on it at insert, which removes invisible nodes in the wrapping process. After this commit: we now use predicates to decide areInlinesAllowedAtRoot We add a predicate specifically for the container of Contact Us button, to allow inline element in the root. The `wrapInlinesInBlocks` won't be called on the container on paste anymore. task-5109662 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#246987 Forward-Port-Of: odoo/odoo#241836
This update resolves an issue where the Point of Sale (POS) system would become unusable after archiving a journal associated with a payment method. The change prevents archiving a journal while it's linked to a POS payment method, ensuring smooth POS operation. This improves stability and prevents disruptions during sales transactions.
Original PR description
Currently, in pos, we only prevent archiving `account.journal` records when a payment in an active pos session is linked to that specific journal. This can lead to issues if a journal is archived while being linked to a `pos.payment.method`. In this commit we prevent that from happening, by only allowing the archival of `account.journal` records when they are not linked to `pos.payment.method`. Steps to reproduce: - in payment method configuration set the journal bank on your card payment method - Link this payment method to your POS - Archive the bank journal in the backend - Open POS - Make a sale - Close register - You're stuck because the POS cannot input the journal item into the archived journal Task 5896123 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247015
This update resolves issues preventing correct QR code generation on POS invoices, particularly when ZATCA invoice processing encounters problems. The fix ensures invoices and receipts display the appropriate QR code format, improving compliance and usability for users. It addresses both incorrect QR codes on reprinted invoices and the display of phase 2 QR codes when e-invoicing is disabled.
Original PR description
Ensure proper handling of QR code generation and POS EDI behavior by fixing multiple issues across invoice reprints and journal onboarding. QR codes now correctly appear on reprinted invoices when…
Ensure proper handling of QR code generation and POS EDI behavior by fixing multiple issues across invoice reprints and journal onboarding. QR codes now correctly appear on reprinted invoices when journal problems occur during order confirmation. POS correctly falls back to the Phase 1 flow when the journal is not onboarded and electronic invoicing is not enabled. Additionally, POS receipts now display the proper Phase 1 QR code whenever the EDI module is installed. Problem 1: If ZATCA does not properly receive the invoice generated from a POS order (wrong onboarding, wrong details on company, etc.) the invoice printed from POS will not contain the QR code, even after successfully resubmitting the invoice to ZATCA, load the order and reprint the invoice to see this Testing the fix: Change the VAT number on the company to be faulty, create a POS order, Fix the VAT number and resubmit the invoice, load the POS order and reprint invoice, it will now show the QR code. Problem 2: When disabling the E-invoicing for a phase 2 journal, the POS receipt will still try to print the phase 2 QR code but the system will flag it as 'not legal' leaving the POS receipt empty, when it should instead print the phase 1 QR code Testing the fix: On the journal, disable the E-invoicing, and create a POS order, it will now show the phase 1 QR code on the receipt task-5032474 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#246932 Forward-Port-Of: odoo/odoo#234945
This update enhances the Glory cash machine integration within the POS system, streamlining the user interface and fixing several technical issues. Key improvements include clearer cash display, reduced UI clutter, and optimized communication with the Glory machine for better performance.
Original PR description
- Cash machine UI in the POS has been cleaned up - Reset button and Download logs button have been moved to the backend. - Warnings about low cash now take up less space. - The cash inserted amount…
- Cash machine UI in the POS has been cleaned up
- Reset button and Download logs button have been moved to the
backend.
- Warnings about low cash now take up less space.
- The cash inserted amount is now shown inside the payment line status
box.
- Shortcut to the Glory admin page has been added to the payment method
form.
- Error detail text is now shown when provided by the cash machine.
- Bugfixes
- There should no longer be multiple disconnected popups appear if the
tab is left inactive for a while.
- The session/occupy settings of the connected Glory machine are now
respected, this reduces the number of requests sent when they are
not enabled.
- Some tests have been added for the Glory service.
In order to add Glory functionality in the backend, the Glory service was split into two components. The `glory_service.js` file handles all the communication with the Glory machine, but it doesn't handle the POS integration at all. The POS side is now handled by `payment_glory.js`. This means that in the backend we can still use `glory_service.js` to interact with the machine without being in the POS.
task-5891688
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#246986This update fixes a visual problem where call cards overlapped when a video stream was active in a chat window. The change ensures that call cards now maintain a standard 16:9 aspect ratio when a video is present, improving the user experience during video calls. This resolves a previous display issue.
Original PR description
Before this commit, when in a call in a chat window and someone in call stream video, the cards were overlapping. This happens because [1] removed the `w-100` on `<video>` which let them have bigger width than imposed by `arrangeTiles`. This change was motivated because the card has aspect ratio of 1 in chat window and this was too small. However the correct fix was to impose the 16:9 ratio on cards when there's at least 1 video stream, which is what this commit does. Task-5917628 [1]: https://github.com/odoo/odoo/pull/241924 Before / After <img width="387" height="607" alt="Screenshot 2026-02-06 at 16 58 51" src="https://github.com/user-attachments/assets/39569572-4eea-4d58-a383-27f9c69e4bb5" /> <img width="386" height="600" alt="Screenshot 2026-02-06 at 16 58 29" src="https://github.com/user-attachments/assets/f9b60e9a-6980-4708-b475-14f9d5a77a36" />
This update fixes an issue where delivery valuations weren't accurately reflecting the existing stock levels (FIFO method) during order fulfillment. The change ensures that the quantity already delivered is properly accounted for, leading to more precise cost of goods calculations. This improves the accuracy of financial reporting.
Original PR description
Steps to reproduce: - Have a product valued in fifo - Create 3 PO for it, each for 1 qty of price 10, 20 and 30. - Confirm these PO & validate their receipts - Create 2 SO for this product, each for 1 qty - Confirm these SO & validate their deliveries together Issue: The value associated to the delivery moves (and so the cogs generated from them) is 10 for both. When calling `_action_done()` on the moves, we'll set the value of each move before moving them. To get the correct value from the fifo stack, we rely on the `qty_available` at the time. However, since we're going to set the value of multiple moves before validating them, the `qty_available` won't be updated between each call. opw-5359484 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238680
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 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 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 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#105813