Friday, January 30, 2026
11 changes · saas-18.3
New functionality added to Odoo
This update enables Odoo to automatically generate and send FA(3) XML invoices to Poland's KSeF system, fulfilling regulatory requirements. It adds necessary fields to invoices and company records, implements secure communication, and includes automated status updates via a cron job. This ensures accurate and compliant tax reporting for Polish businesses.
Original PR description
- Added new fields to res.company to handle key, certificates and session numbers - Added new fields to account.move to track KSeF status, session, reference number, attachments, errors. - Updated…
- Added new fields to res.company to handle key, certificates and session numbers - Added new fields to account.move to track KSeF status, session, reference number, attachments, errors. - Updated the frontend view of the move and the settings. Some fields are debug-view only. - Implemented the sending method with `account.move.send`, storing the xml attached to the move. - Implemented the APIs to communicate securely with the KSeF - Implemented the Check Sending and Download UPO functionality - Implemented the rendering of the FA(3)-compliant XML structure. - Implemented a cron to update invoice KSeF statuses. - Implemented locking so cron and manual don't mess up with each other. - Set as `auto-install` for those who have the Polish localization. - Wrote minimal tests for basic use cases (to be expanded). - Added `neutralize.sql` script to avoid leaking sensitive data when copying a database for support - Added module to `.weblate.json` to make this i18n-able Task [link](https://www.odoo.com/odoo/project.task/4728713) task-4728713 Forward-Port-Of: odoo/odoo#230988
Resolved issues and error corrections
This update corrects a bug where archived journals with outbound payment methods were still appearing as selectable options when creating expense reports. The fix ensures that only active journals are considered, preventing users from selecting outdated payment methods and improving data accuracy. This resolves an issue that could have led to incorrect expense reporting.
Original PR description
Steps to Reproduce: 1. Go to Accounting > Configuration > Journals 2. Archive a Journal with outgoing payment method 3. Go to Expenses > Create an Expense paid by company 4. Note that payment methods…
Steps to Reproduce:
1. Go to Accounting > Configuration > Journals
2. Archive a Journal with outgoing payment method
3. Go to Expenses > Create an Expense paid by company
4. Note that payment methods from archived journal are still visible and can be selected.
Issue:
- Archived journals with outbound payment methods were still selectable when creating company-paid expenses.
- Due to this [commit](https://github.com/odoo/odoo/commit/5c9a6704dd54bbbde1703850619ddcc1a3552547) The journals can be archived without system prevention as the action_archived method has been removed.
Solution:
- This occurred because selectable_payment_method_line_ids did not filter out inactive journals when falling back to a generic search. -Aligning the search domain with
[company_expense_allowed_payment_method_line_ids]
(https://github.com/odoo/odoo/blob/19.0/addons/hr_expense/models/res_company.py#L20) by excluding payment method lines linked to inactive journals.
Before Fix:
```py
In [1]: expense = self.env['hr.expense'].browse(1639)
In [2]: expense.selectable_payment_method_line_ids
Out[2]: account.payment.method.line(2, 4, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 166, 170, 172, 512, 516)
In [3]: archived_journal_ids = []
In [4]: payment_method_lines = self.env['account.payment.method.line'].search([
...: *self.env['account.journal']._check_company_domain(expense.company_id),
...: ('payment_type', '=', 'outbound'),
...: ])
In [5]: payment_method_lines
Out[5]: account.payment.method.line(2, 4, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 166, 170, 172, 512, 516)
In [6]: for payment_method_line in payment_method_lines:
...: if not payment_method_line.journal_id.active:
...: archived_journal_ids.append(payment_method_line.journal_id.id)
...:
In [7]: archived_journal_ids
Out[7]: [7, 8]
```
After Fix:
```py
In [8]: payment_method_lines_with_fix = self.env['account.payment.method.line'].search([
...: # The journal is the source of the payment method line company
...: *self.env['account.journal']._check_company_domain(expense.company_id),
...: ('payment_type', '=', 'outbound'),
...: ('journal_id.active', '=', True),
...: ])
In [9]: payment_method_lines_with_fix
Out[9]: account.payment.method.line(153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 166, 170, 172, 512, 516)
In [10]: archived_journal_ids_with_fix = []
In [11]: for payment_method_line in payment_method_lines_with_fix:
...: if not payment_method_line.journal_id.active:
...: archived_journal_ids_with_fix.append(payment_method_line.journal_id.id)
In [12]: archived_journal_ids_with_fix
Out[12]: []
```
OPW-5461359
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#242743This update corrects a bug that prevented visitors from appearing in search results when their check-in times were recorded in time zones other than the user's local time. The fix ensures all date/time comparisons are done in UTC, resolving filtering inaccuracies and improving visitor data visibility across different locations.
Original PR description
Steps to reproduce -------------------------- 1. Install Frontdesk 2. Go to Frontdesk → Visitors 3. Create a visitor with a check-in time before today 05:30 (local timezone: Asia/Kolkata) 4. Check visitors Issue: -------- The created record is not displayed because "today" filter used the user's local date to build a datetime range but failed to convert those boundaries to UTC before querying the database, leading to incorrect filtering in non-UTC time zones. Solution ------------- Convert those datetimes to UTC using `.to_utc()` in the filter domain opw-5385995 Forward-Port-Of: odoo/enterprise#102865
This update resolves a problem where customer claims weren't being processed correctly due to a limitation in how the system matched invoices with VAT numbers. Specifically, when a child invoice shared the same VAT number as the parent, the system would incorrectly select a partner, preventing the necessary account move updates. This fix ensures accurate claim processing.
Original PR description
When we process new customer claims, we need to search for the corresponding account moves in order to update their `l10n_cl_dte_acceptation_status`. Currently, we only expect 1 partner per VAT number when searching for a partner to match with the account move. However, this is not always true. For instance, a child invoice contact will share the same VAT number than the parent partner. This can lead to the selection of the wrong partner in the search domain and consequently, the account move not being found. Related ticket: opw-5257481 Forward-Port-Of: odoo/enterprise#105653 Forward-Port-Of: odoo/enterprise#103366
This update corrects a bug where the serial number of products on 'ready' delivery orders was being incorrectly updated. The fix prevents changes to the assigned serial number when adding new moves to these orders, ensuring accurate stock tracking and order fulfillment. This resolves an issue that could lead to discrepancies in inventory counts.
Original PR description
Steps to reproduce: - Create a storable product tracked by serial number (e.g. "P1") - Set the quantity on hand to 2 with serial numbers SN1 and SN2 - Create a delivery order - Add any product with available quantity - Mark the delivery as "To Do" -> The picking is in the `ready` state - Add a new move line with product "P1" and assign serial number SN2 -> Before saving, the quantity is correctlyupdated to 1 - Save the delivery Problem The assigned lot/serial number is unexpectedly replaced with 'SN1'. Fix: Do not update or recompute the serial/lot number when creating a move on pickings that are already in the `ready` state. Forward-Port-Of: odoo/odoo#245622 Forward-Port-Of: odoo/odoo#245447
This fix ensures that customers purchasing event tickets through POS are accurately registered as attendees. Previously, if customer information wasn't provided at the time of purchase, the registration was incomplete. This update aligns the POS registration process with the website, ensuring consistent attendee tracking and reporting.
Original PR description
Currently, when a customer is set on the order and buys a event ticket, the information is not set as partner on the registration. Steps to reproduce: ------------------- * Create an event that asks…
Currently, when a customer is set on the order and buys a event ticket, the information is not set as partner on the registration. Steps to reproduce: ------------------- * Create an event that asks for name but is not required * Open pos and sell on ticket * Do not put name info * Select a customer for the order * Validate order * Check registrations > Observation: The customer is not registered as the attendee Why the fix: ------------ We compare the scenarios with the same flow but from website registrations. On the website if there is no user registered: - If information is not filled, nothing will be registered on the registration - If information is filled it will be used to populate attendee fields If there is a user registered while on website: - If no information is filled, attendee fields will be populated with the data from the connected user - If information is filled, it will be used for attendee fields - If partial information is filled, it will be used for attendee fields but will also be completed with data coming from the connected user To achieve the same behavior from the pos we first need to register the customer as the partner for the event. During event creation we also remove values regarding attendee name, email, phone and company if they were not provided during the order. From the website they are not used during creation if they were not given by the customer. However, in the pos this information is present anyway (as empty string or False) as they are fields on the model "event.registration" and are still send to the backennd even if we remove the information here https://github.com/odoo/odoo/blob/787621e44a9cef30469849929df267cae9e977f2/addons/pos_event/static/src/app/screens/product_screen/product_screen.js#L127 We do the fix server-side as a fix in the frontend would not be as straightforward. A customer might be on the order before selecting event ticket and it's easy but one might also add the customer after the ticket was selected. opw-5137197 Forward-Port-Of: odoo/odoo#242783 Forward-Port-Of: odoo/odoo#234871
This update prevents users without the necessary access rights from being redirected to the website when attempting to view the eCommerce reporting menu. The fix clarifies access restrictions by raising an error instead of a redirect, improving the user experience and ensuring proper access controls.
Original PR description
__Steps to reproduce on runbot:__ 1. Login with Mitchell Admin 2. Remove Marc Demo from the `sales_team.group_sale_salesman` access group (User: Own Documents Only) 3. Login with Marc Demo 4. Open…
__Steps to reproduce on runbot:__ 1. Login with Mitchell Admin 2. Remove Marc Demo from the `sales_team.group_sale_salesman` access group (User: Own Documents Only) 3. Login with Marc Demo 4. Open the Website app and go to Reporting > eCommerce => You are redirected to the website in frontend mode __Reason:__ Clicking on the eCommerce reporting menu calls `action_dashboard_redirect`, which redirects to the website if the user is not in `base.group_system`, `website.group_website_designer`, or `sales_team.group_sale_salesman`. Since Marc Demo is not in any of these groups, he is redirected to the website without any message, which is not very user friendly. __Fix:__ - Add the groups to the menu to prevent showing it if the user does not have access to it anyway. - Raise an access error instead of redirecting to the website to make it clear to the user that they cannot open the dashboard even if they could see it. This also fixes [`TestMenusDemo`] by preventing this menu from being tested with the demo user in case he doesn't have access to it. [`TestMenusDemo`]: https://github.com/odoo/odoo/blob/736b71202db840ba6a7ed7e7f014b5b7c493d589/addons/web/tests/test_click_everywhere.py#L41C9-L41C41 runbot-234747
This update resolves a critical issue where downpayment invoices generated through POS weren't correctly linked to final invoices, leading to report errors. The fix ensures accurate reference creation and correct invoice type codes for downpayment invoices, improving the reliability of financial reporting within the POS system.
Original PR description
Description of the issue/feature this PR addresses: This PR addressed two issues, one related to pos_sale, and the other related to l10n_gcc_invoice that was found during testing. the first and main…
Description of the issue/feature this PR addresses: This PR addressed two issues, one related to pos_sale, and the other related to l10n_gcc_invoice that was found during testing. the first and main issue this PR addresses is that _get_downpayment_lines and _is_downpayment don't work properly on downpayment and final invoices generated in POS since there is no link formed between them through the sale order. the second issue occurs during when printing downpayment invoices that were made through POS. since there is no line.name for the downpayment line. an error pops up due to the dual language logic in place. To reproduce the issue: - install pos_sale & l10n_sa_edi_pos. - configure downpayment product on pos.config - generate an SO and confirm it in the backend - create a downpayment for that SO through POS - settle the SO on the POS or through the backend. - you'll find that the final invoice generated doesn't reference the downpayment invoice - you'll also find that the downpayment invoice doesn't have the correct invoice type code indicating that it's a downpayment. - printing the invoice will also give an error when l10n_gcc_invoice is installed (for the downpayment invoice) Current behavior before PR: xml documents generated from l10n_sa_edi don't carry the correct reference to the downpayment invoice when it's the final invoice. they also don't have the correct invoice type code when it's a downpayment invoice if generated through POS Desired behavior after PR is merged: the methods _get_downpayment_lines and _is_downpayment now correctly identify the downpayment lines & if it's a downpayment respectively. the dual language product name now shows on the invoice pdf without raising an error if line.name is undefined. Task-5135918 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a performance issue in the project timesheet report that was causing it to fail with large datasets. By using a more efficient query structure with CROSS LATERAL JOIN, the report now loads significantly faster – approximately 2 seconds – improving user experience. This change focuses on optimizing the report's data processing.
Original PR description
After this commit https://github.com/odoo-dev/enterprise/commit/6c33bde74342b634d9f6fbda4ef407ffe9bac54f we introduced a new left join which seems that it slowed down the query a lot. So the report…
After this commit https://github.com/odoo-dev/enterprise/commit/6c33bde74342b634d9f6fbda4ef407ffe9bac54f we introduced a new left join which seems that it slowed down the query a lot. So the report doesn't load at all if we have a lot of records. In this PR we are introducing CROSS LATERAL JOIN as we want to generate only the the relevant dates not all dates between the min starting date and max ending date of all slots. Query plan after modification https://explain.dalibo.com/plan/eh5293ba2354f43c The testing cardinality of the tables: `planning.slot` 7178 rows `hr.employee` 332 rows `resource.resource` 332 rows `resource_calendar_leaves` 4061 rows `account_analytic_line` 267376 rows `generate_series()` will produce 206417 rows | Before | After | |-----------------------------------------|-------| | Query keep being active with no results | ~2s | opw-5089052 Forward-Port-Of: odoo/enterprise#105538 Forward-Port-Of: odoo/enterprise#102283
This update allows store managers to directly create new products within the Point of Sale (POS) interface. Previously, this functionality was restricted to system administrators, limiting store managers' ability to quickly add products to the system. This change improves operational efficiency and responsiveness for retail locations.
Original PR description
Before this commit, only system users could create products from the POS interface. This limited the ability of store managers. opw-5418727 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243605 Forward-Port-Of: odoo/odoo#240520
This update resolves issues preventing correct QR code generation for invoices and receipts in the Saudi Arabia (SA) POS system. Specifically, it ensures invoices reprint correctly even with ZATCA onboarding problems and displays the appropriate Phase 1 QR code when electronic invoicing is disabled, improving compliance and user experience.
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#242486 Forward-Port-Of: odoo/odoo#234945