Tuesday, February 10, 2026
10 changes · 18.0
Enhancements to existing features
This update enhances the generation of electronic invoices (eTransport) for Romanian businesses within Odoo. Specifically, it now uses standard unit prices, includes logging of sent invoices for tracking, and applies necessary rounding to ensure compliance with Romanian tax regulations. This improves the accuracy and reliability of eTransport submissions.
Original PR description
- Adding logging of sent XML into move chatter - Adjusting the XML generator to use standard unit price - Adding rounding for product values as required by the XML structure task-5892338 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247541
This update ensures UrbanPiper receives the correct product tags by dynamically syncing them from product settings. Previously, tags were hardcoded, leading to issues with tax calculations. Now, users can define tags based on their needs, streamlining the integration with UrbanPiper and improving data accuracy.
Original PR description
Before this commit: ------------------------------------------ - The UrbanPiper payload used a hardcoded tag when the tax percentage was not 5%. - There was no mechanism to add additional tags based on providers, even though UrbanPiper supports multiple tags. After this commit: ------------------------------------------ - Tags are now dynamically handled using the Tag field in the product. - Users can define tags according to their tax configurations and aggregator requirements. - UrbanPiper only accepts relevant tags (default or provider-specific). task - 5154061
Resolved issues and error corrections
This change resolves a database error encountered during the KSeF (Polish e-invoice) integration neutralization process. The issue stemmed from a missing column in the 'res_company' table, which has now been corrected by creating a dedicated column for the session key. This ensures smoother database updates and avoids integration failures.
Original PR description
### Issue: Due to recent [commit] (https://github.com/odoo/odoo/commit/06ff5d42e66b800a7e09a52e9abd51b7fb759cc3) , neutralization of the database is hampered and following error is encountered.…
### Issue:
Due to recent [commit]
(https://github.com/odoo/odoo/commit/06ff5d42e66b800a7e09a52e9abd51b7fb759cc3) , neutralization of the database is hampered and following error is encountered.
Traceback on neutralizing:
```py
odoo.sql_db: bad query: b"-- disable_l10n_pl_edi_integration\n\n-- clear KSeF Credentials\nUPDATE res_company\n SET l10n_pl_edi_certificate = NULL,\n l10n_pl_edi_access_token = NULL,\n l10n_pl_edi_refresh_token = NULL,\n l10n_pl_edi_session_id = NULL,\n l10n_pl_edi_session_key = NULL,\n l10n_pl_edi_session_iv = NULL\n;\n\n-- set test environment parameter\n INSERT INTO ir_config_parameter (key, value, create_date, write_date)\n VALUES ('l10n_pl_edi_ksef.mode', 'test', NOW(), NOW())\n ON CONFLICT (key)\n DO UPDATE SET value = 'test',\n write_date = NOW()\n;"
ERROR: column "l10n_pl_edi_session_key" of relation "res_company" does not exist
LINE 9: l10n_pl_edi_session_key = NULL,
```
Before this commit:
```sql
test_18_pl=> SELECT column_name
FROM information_schema.columns
WHERE table_name = 'res_company'
AND column_name LIKE 'l10n_pl_edi%';
column_name
---------------------------
l10n_pl_edi_certificate
l10n_pl_edi_access_token
l10n_pl_edi_refresh_token
l10n_pl_edi_session_id
(4 rows)
```
After this commit:
```sql
test_18_pl=> SELECT column_name
FROM information_schema.columns
WHERE table_name = 'res_company'
AND column_name LIKE 'l10n_pl_edi%';
column_name
---------------------------
l10n_pl_edi_certificate
l10n_pl_edi_session_iv
l10n_pl_edi_session_key
l10n_pl_edi_access_token
l10n_pl_edi_refresh_token
l10n_pl_edi_session_id
(6 rows)
```
### Solution:
Set attachment=False for the fields `l10n_pl_edi_session_key` and `l10n_pl_edi_session_iv`, ensuring that their columns are created directly on the res.company model instead of being stored as attachments. Eventually, during [neutralizing]
(https://github.com/odoo/odoo/blob/18.0/addons/l10n_pl_edi/data/neutralize.sql#L4-#L10) there won't be any column missing error.
Ticket [link](https://www.odoo.com/odoo/project.task/5751411)
opw-5751411This update significantly speeds up the process of creating mass payments within Odoo. Previously, a complex loop structure took up to 120 seconds to process large payment batches. Now, the process is optimized to complete in just 3 seconds, dramatically improving efficiency for users handling many payments at once.
Original PR description
Before this commit, retrieving the total amount used nested loops—iterating over moves and filtering move lines from `batch_result['lines']` in $O(N \times M)$ complexity. This caused significant performance bottlenecks during mass payment creation. In this commit, I refactored the logic to iterate over batch_result['lines'] in a single pass, reducing complexity to $O(M)$. The benchmark done below was on a database where the user tried to mass register a payment for **1200** moves and resulted in **12000** move_lines. | Scenario | Time (seconds) | |-----------|----------------| | **Before** | **120s** | | **After** | **3s** | opw-5440956 Forward-Port-Of: odoo/odoo#246356
This update resolves an issue where breadcrumb traceability was missing when migrating databases from older versions to the latest. The change adjusts how project windows are opened, ensuring proper navigation and functionality across all versions. This improves the user experience when managing projects linked to sales orders.
Original PR description
Steps to reproduce: 1. Create a db with having 'sale' & 'project' installed in version 16. 2. Create a sale order having linkage to more than single project. 3. Migrate the db to version 19. 4. When…
Steps to reproduce:
1. Create a db with having 'sale' & 'project' installed in version 16.
2. Create a sale order having linkage to more than single project.
3. Migrate the db to version 19.
4. When clicking on the project stat button the breadcrumb traceability will not be there.
Issue:
-> In v16.4 the target defined for the action `project.open_view_project_all` is removed from [here](odoo/odoo@a92d686)
When migrating a database from v16 to v19 and opening projects from a sale order linked to multiple projects, the stat button triggers `action_view_project_ids`, which in turn calls
`project.open_view_project_all` for records having len('projects_ids') > 1 from [here]
(https://github.com/odoo/odoo/blame/19.0/addons/sale_project/models/sale_order.py#L220) Because the persisted target is `main`, breadcrumb traceability will be lost. The issue will arise in the DBs coming from version 16 or lesser. Therefore, it would be necessary to address this immediately and set correct target for window_action for databases >= v17
This commit explicitly sets the action target to `current` to restore proper breadcrumb behavior and align it with standard odoo record.
OPW-5448916
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#244245This update resolves an issue where Sale Orders imported into POS and paid with online payments remained in 'Quotation' status. The fix ensures that the Sale Order's state is correctly updated to 'Paid' after online payment processing, improving order tracking and reporting within the POS system. This prevents discrepancies between the POS and Sale apps.
Original PR description
When a Sale Order was imported in PoS and paid using online payment method, the SO's state stayed in Quotation. Steps to reproduce: ------------------- * Create a new Sale Order with a product available in POS * Add Online Payment in the Payment Methods * Import and settle the Order in POS * Pay the order with the Online Payment > Observation: In Sale app, the Sale Order is still in Quotation state. Why the fix: ------------ Online payments call `action_pos_order_paid()` directly, which only sets the POS order state to paid and never confirms the linked sale.order. Other payment methods do it in `sync_from_ui()`. Extended `action_pos_order_paid()` in pos_sale will now confirm linked quotations after POS marks the order as paid. opw-5022526
This update corrects a bug where loyalty points were incorrectly calculated and duplicated after saving a POS order. The fix ensures that loyalty points are accurately reflected, preventing over-earning of rewards. This improves the customer experience and data integrity within the point-of-sale system.
Original PR description
Step to reproduce:
- have a trusted pos and a loyalty program which gives points per $ spent
- start pos and select order and a partner (he should already have some LPs)
- notice the loyalty points assgined
- save the order, you are redirected to new order
- switch back to original order
Observation:
- Notice, the loyalty points are reassigned for example :
- if initially partner's LP = 50, product added is 100$ , LP = 50+100 = 150
- After saving, LP becomes 150 + 100 = 250
Cause:
- LP's are processed after every `sync_from_ui` call from `_postProcessLoyalty` which updates the customer's lp, even before the order is fullfilled or when order is still in `draft` state
Fix:
- Issue is fixed in https://github.com/odoo/odoo/commit/a4b37ec474656c7af23d0134251d589e9a6a61ca
- This commit adds related test for the fix
opw-5609964
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update resolves an issue that prevented accurate payment move synchronization when a payment had multiple liquidity lines. The fix ensures that the system correctly handles payments with varying liquidity line amounts, preventing a technical error and improving payment processing reliability.
Original PR description
This PR improves payment move synchronization and fixes an error that is caused while changing amount of a Payment that has multiple liquidity lines. Steps to reproduce: 1. Create payment with x…
This PR improves payment move synchronization and fixes an error that is caused while changing amount of a Payment that has multiple liquidity lines. Steps to reproduce: 1. Create payment with x amount and validate it. 2. Open the payment journal entry. 3. Reset to draft and update the liquidity line amount from x to (x - y) 4. Create another liquidity line with amount y to balance entry and post it. 5. Draft the payment and try to update the amount. A traceback will appear. `ValueError: Expected singleton` Cause: The lines for payment JE are prepared for the case assuming that there will be only 1 liquidity line, but since we have more than 1, we get a Singleton error. Description of changes made: While preparing values for move in `synchronize_to_moves()` check for multiple liquidity lines and append all values to write. Further, the `_prepare_move_line_default_vals()` is also improved in order to manage different type of move lines individually. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where credit notes were displaying negative tax amounts in the tax totals widget. The fix ensures accurate tax calculations are shown, resolving a discrepancy between the tax line balance and the reported tax amount. This improves the reliability of financial reporting for Brazilian companies using the Avatax module.
Original PR description
Currently, when computing taxes for a credit note, the system will show the included tax as negative in the tax totals widget Steps to reproduce: - Setup a BR Company - Setup a product requiring tax ICMS included in price - Create a credit note with the product - Compute taxes Issue: In tax totals widget the tax amount will be reported as negative, even if the tax line balance is correct. opw-5866180
This update resolves an issue where invoice exports were failing when invoices included a section or note line as the first entry. The fix filters out these lines during currency rate calculations, preventing a division-by-zero error and ensuring invoices can be correctly sent and downloaded. This improves the reliability of our invoicing processes.
Original PR description
Before this commit: Steps 1) Create an invoice with a section or note line as the first line 2) Try to send or download the invoice => A traceback error is raised with the message: File "/home/odoo/src/enterprise/17.0/l10n_cl_edi_exports/models/account_move.py", line 68, in _get_inverse_currency_rate return float_round(abs(self.line_ids[0].balance / self.line_ids[0].amount_currency), 2) ZeroDivisionError: float division by zero This occurs because the `_get_inverse_currency_rate()` method is dividing over self.line_ids[0].amount_currency which is always equal to 0 in case of section or note line is added as a first line in the invoice. After this commit: Filtering out section and note lines in _get_inverse_currency_rate() to correctly calculation the inverse currency rate opw-5488417 Forward-Port-Of: odoo/enterprise#105774