Tuesday, August 19, 2025
83 changes
15 changes
New functionality added to Odoo
The Point of Sale delivery integration now supports Wolt as an additional food delivery provider. This gives restaurants using Odoo more choice in connecting their delivery operations to external platforms.
Original PR description
Following this commit: - Integrated Wolt as delivery provider in pos_urban_piper. task-4882282 Forward-Port-Of: odoo/enterprise#88222
Enhancements to existing features
Belgian Annual Accounts exports from the General Ledger now generate XML files instead of TXT files. This makes the exported data better structured and aligned with official requirements, improving usability for downstream reporting and processing.
Original PR description
The previous Annual Accounts export in the General Ledger generated a TXT file with a fixed column order, which did not meet the structural or formatting requirements for downstream usage. This commit replaces the TXT export with an XML export conforming to the official format, including fields such as account code, debit, credit, multilingual descriptions, and metadata. task-5005345 Forward-Port-Of: odoo/enterprise#92454 Forward-Port-Of: odoo/enterprise#92071
Resolved issues and error corrections
Manual tax calculations now also keep the original taxable base amounts, not just the tax amounts. This helps external tax integrations such as AvaTax and Brazil AvaTax produce more complete and reliable accounting data, reducing discrepancies in invoices and tax reporting.
Original PR description
…unts Forward-Port-Of: odoo/enterprise#92478
10 changes
Resolved issues and error corrections
Combo products now keep the correct pricelist discount from product page through checkout. This prevents customers from seeing misleading original prices or a crossed-out zero price, improving pricing clarity in online purchases.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Have a combo product; 2. create a pricelist that gives a 10% discount on the product; 3. go to product's website page; 4. observe the displayed discount; 5. add product to cart; 6. go to checkout. Issue ----- The discount has disappeared, instead it displays the original price next to a stricken-through "$ 0.00" Cause ----- The `_compute_discount` method does not get the correct `pricelist_item_id` for the combo items. Additionally, on checkout, it shows the `price_unit` of the combo line in the strike-through, which is always 0. Solution -------- When computing the discount of a combo item, retrieve the discount of its linked line, which has the correct value. Additionally, when displaying a combo product in eCommerce, use `_get_display_price_ignore_combo` instead of the `price_unit`. opw-4968848
Mexican localization now includes additional 16% withholding tax options with specific split distributions, along with the related accounts and fiscal positions. This helps businesses apply the correct tax treatment more easily and improves rounding accuracy for existing 10.67% taxes.
Original PR description
Add few 16% taxes with special distribution (1/3 - 2/3 and 1/4 - 3/4). Also add few accounts and a new fiscal position for each new tax. Also adjust the rounding precision of 10.67% taxes. Linked:https://github.com/odoo/odoo/pull/206406 task-4571928 Forward-Port-Of: odoo/enterprise#92347 Forward-Port-Of: odoo/enterprise#83582
Audit balance progress now focuses on accounts that have an audit status, giving users a more accurate view of completion. The update also improves audit return setup screens, search options, and visibility of audit state across localized balance sheets, reducing confusion and preventing an error when creating certain returns.
Original PR description
* On Audit, balances progress bar counts only accounts with states different than none. * When Audit type on return type form, hide non-related fields. * Fix traceback when creating a return for new actionable checks. * In check template search view, add Title to be searchable * Show Audit State on localized balance sheet accounts * task-4991558
The HR interface now uses “employee record” instead of “version” across payroll, salary, and related workflows. This makes labels and menus clearer for users managing employee information, improving day-to-day usability without changing core business processes.
Original PR description
In this PR, we renamed the version into employee record for a better UX. Related task: 4921404.
The Turkish Profit and Loss report now includes 700-series accounts, which are used during the accounting period before being closed into 600-series accounts. This makes the report more useful for local businesses and accountants by supporting more up-to-date financial visibility during the period.
Original PR description
The current Profit and Loss report has some limitations that inhibit its proper adoption as it does not enable the user to use the report in real-time since it excludes the 700 accounts (accounts used within a period until their closing to 600 accounts.) Therefore, this limits the usefulness of the report for local businesses and accountants. In this task, we included the 700 accounts in the report to enable real-time reporting for our users task-4809142
HR teams can now edit employee leave requests even after they reach the approval stage, provided the leave has not already been included in a payslip. This gives administrators more flexibility to correct or update leave records before payroll processing locks them down.
Original PR description
- Allowing HR people to always edit the leave, as long as it's not included in a payslip. task-4866887
IoT administrators can now configure remote debugging directly from the IoT app instead of relying on more manual setup steps. This makes support and troubleshooting easier when devices need remote assistance.
Original PR description
To ease remote debug configuration, we add the possibility to configure remote debug from the IoT app, using the websocket. Community PR: odoo/odoo#216318 Task: 4865987
Signer roles can now have a default contact assigned, so that person is automatically filled in when creating a signature request. Users can still change the signer manually, reducing repetitive entry while keeping flexibility.
Original PR description
In this commit, - added a new field on the Signer Role to link a default Partner. - On the Sign Item Role form, user can now select a default partner. - This partner will be automatically pre-filled as the signer in the sign request wizard. - The default can still be changed manually if needed. task-4812381
Egyptian payroll now applies the exempt amount before calculating income tax. This helps prevent employees from being charged too much tax and improves payroll accuracy.
Original PR description
Issue: - The income tax calculation in Egyptian payroll did not properly account for the exempt amount. - This could result in over-calculating tax for employees by not applying the exemption. Fix: - Updated the 'Taxable Amount' salary rule to correctly apply the exempt amount before tax is calculated. Task-4815156 Forward-Port-Of: odoo/enterprise#86395
This fix ensures payments made through the customer portal for subscriptions are properly connected to the invoice that is created afterward. Business users can now see the related payment from the invoice, improving payment tracking and reducing confusion during subscription billing follow-up.
Original PR description
### Steps to reproduce: - Activate a payment method - Create a subscription and preview it in portal view - Pay this order through the order's portal view - Navigate to the invoice got generated -…
### Steps to reproduce: - Activate a payment method - Create a subscription and preview it in portal view - Pay this order through the order's portal view - Navigate to the invoice got generated - Notice there is not 'Payments' smart button ### Cause: Since https://github.com/odoo/enterprise/pull/77432/commits/02f72f94b7c996fa19c6bfc70a704d27aa677245 we stopped creating the invoice before the payment and the transaction in the controller and we let _post_process do this invoice creation. So the invoice actually gets created after the payment not before and when preparing the payment values the invoice_ids will be False https://github.com/odoo/odoo/blob/6c88e6ffd2c906b72b31d3c34ad3d6da5efba204/addons/account_payment/models/payment_transaction.py#L155-L170 Then we create the invoice for the transaction and we don't propagate it to the payment. https://github.com/odoo/enterprise/blob/20fd574367757c06f30c344056e8b8d91ba8244c/sale_subscription/models/payment_transaction.py#L72-L84 ### Fix: Link the payment to the invoice after creating the invoice and link it to the transaction. opw-4867631 Forward-Port-Of: odoo/enterprise#91690
Employee approval contacts are now recalculated based on the employee's current manager. This helps keep timesheet approval responsibilities accurate when reporting lines change.
Original PR description
To update the approvers information for employee according to his manager, the logic of computing each field has been modified.
Tickets created from Timesheets now automatically use the helpdesk team linked to the selected project. This prevents new support tickets from being assigned to the wrong team and limits team choices to those configured for timesheets.
Original PR description
Steps to Reproduce: - 1. Go to Timesheets > My Timesheets, start the timer, and select the project linked to the helpdesk team. 2. In the timer header, quick-create a new ticket via the "Ticket" field dropdown 3. Observe that the default helpdesk team on the new ticket is incorrect. Issue: - - When creating a ticket from the Timesheets module (e.g., via timer header or views), the system selects an incorrect default helpdesk team, leading to misassigned tickets. Cause: - - The core default logic for team_id prioritizes user membership or the first team without considering the selected project's linked helpdesk team. Fix: - - Override `_default_team_id` to set the correct Helpdesk Team based on the selected project. - A domain has been added to the team selection field within the timesheet views to only show teams that have the timesheet feature enabled. task-4885679 Forward-Port-Of: odoo/enterprise#92227 Forward-Port-Of: odoo/enterprise#89503
This fix prevents errors during fast payment when the order is not yet available on the payment screen, especially with automatic receipt printing and refunds. Businesses using affected POS localizations and payment integrations should see smoother checkout flows with fewer interrupted transactions.
Original PR description
*: l10n_cl_edi_pos, l10n_ke_edi_oscu_pos Before this commit: ---------- - TB appears when the order is not available on the payment screen, while fast payment is running on the product screen with automatic receipt printing, and getting refund lines. - Shifted logic before validation from the payment screen to the POS store. After this commit: ----------- - Fast payment is working seamlessly with automatic receipt printing. Related: - https://github.com/odoo/odoo/pull/216523 task-4874273
Fixes an issue where completed manufacturing orders could not be unbuilt if their components were later changed to require lot or serial tracking. This lets businesses reverse eligible production orders without unnecessary blocking errors while preserving normal tracking rules for components that were tracked originally.
Original PR description
**Description of the issue/feature this PR addresses:** This PR fixes a regression when using the _Unbuild_ feature on a previously completed `mrp.production` whose components did not originally…
**Description of the issue/feature this PR addresses:** This PR fixes a regression when using the _Unbuild_ feature on a previously completed `mrp.production` whose components did not originally require tracking (no lot/serial), but have been updated later to require it. When unbuilding such a product, `stock.move.line._action_done` currently raises a UserError requiring a lot/serial number, because the component moves created by `mrp.unbuild`: - do not have a picking_type_id, - are not inventory moves, - are not scrap moves, - and lack lot/serial information. However, in this context, the lot requirement is misleading, as the original `mrp.production` did not generate tracked components. It is valid to restore untracked components even if they are now tracked. **Current behavior before PR:** - Create an `mrp.production` for a product with untracked components. - Complete the production. - Later, enable lot tracking on one or more of the original components. - Attempt to unbuild the production. - ❌ Error is raised: “You need to supply a Lot/Serial Number for product…” **Desired behavior after PR is merged:** - The unbuild operation proceeds without error. - The untracked components are restored correctly. - Behavior remains unchanged for tracked components that did require lot info during the original MO. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#217282
The website events list now uses the visitor’s local day when applying the “Today” filter, instead of relying on UTC. This ensures events are shown on the correct date for users in different time zones, avoiding missed or incorrectly listed events.
Original PR description
The filters use today in UTC to fetch events in db. The commit fixes this by located today first and then converts it in UTC. related odoo/odoo@bfd55de7c846a0d523e4de4b17020341d8fcfd23 task-4796181
This fix prevents vendor bills or invoices marked as blocked from being automatically unblocked during reconciliation or related accounting updates. It helps preserve payment controls and avoids accidentally allowing payments that were intentionally put on hold.
Original PR description
Problem: When the `payment_state` field on `account.move` is automatically computed, the logic will prioritize whether the move has been posted over whether it has been blocked. The effect is that if…
Problem: When the `payment_state` field on `account.move` is automatically computed, the logic will prioritize whether the move has been posted over whether it has been blocked. The effect is that if an invoice has been marked as blocked, it might be automatically unblocked during reconciliation. Solution: The `_compute_payment_state` method will now prioritize a move's `payment_state` being blocked over whether it has been posted. This prevents a blocked move from being unblocked unexpectedly. Steps to Replicate (Runbot 18) - Create a product - Track inventory - Cost > 0 - Control policy = On ordered quantities - Product category is valuated in real-time (Inventory Valuation - Automated) (requires 'Stock Accounting Automatic' group) 1. Create a PO for the product 2. Create a bill, validate it 3. Block the bill using the contextual action 4. Receive the product If you navigate back to the Vendor Bill, you will see that it has been unblocked. opw-4981799 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Saudi Arabia point-of-sale receipts now encode the local KSA time in their QR codes instead of UTC. This ensures scanned e-invoice details match the printed receipt and follow ZATCA expectations.
Original PR description
**Problem:** If you have an SA company, and try to scan the QR code generated on the receipt, the time will be the UTC time instead of the KSA time, as we are in SA. **Steps to reproduce:** - Change your company to SA and install l10n_sa_pos - Make a purchase with a customer from SA - Scan the QR code from the receipt using an app such as E-invoice QR reader - The invoice date will be the UTC time, or 3 hours less than it should **Why the fix:** Before this fix, the time was always displayed as UTC. It could have been correct if it also displayed a 'Z' in the end, to indicate that it is not local KSA time. We now directly change it using the KSA time, to respect the ZATCA guidelines. The time is now the same on the printed invoice and in the app when scanning the QR code. opw-4769521
Slovenian domestic customers without a VAT number are now assigned the correct domestic fiscal position instead of being treated as EU customers. This prevents domestic sales revenue from being posted to the wrong accounts, improving accounting accuracy for Slovenian businesses.
Original PR description
Before this PR: - Domestic customers without VAT were incorrectly mapped to EU fiscal position, causing domestic revenue accounts (760000) to be mapped to EU accounts (761000). After this PR: - Added new domestic fiscal position for non-VAT customers to ensure proper account mapping for domestic transactions. Task-4918960 Forward-Port-Of: odoo/odoo#217311
A scheduled billing process could stop too early when the first batch included subscriptions that were not ready to invoice, potentially delaying invoices for other eligible subscriptions. This fix applies the batch limit after checking which subscriptions can actually be invoiced, helping ensure renewal invoices are generated on time.
Original PR description
Change was introduced here https://github.com/odoo/enterprise/pull/82340 that caused the cron trigger to not be activated if any of the 31 in the batch of subscriptions found was not to invoice. This is problematic because there could be other subscriptions that meet the domain requirements and the to invoice requirements that are not being seen because the limit is on the search before we check invoiceability. Added a limit to _get_subscriptions_to_invoice instead of on the search in order to take into account both filters for next cron triggers. opw-4850884
Fixes an issue where running a WhatsApp marketing automation test more than once could cause an error and stop the test. The automation now handles each tracking record separately, improving reliability for users validating WhatsApp campaigns.
Original PR description
Currently an error occurs when trying to run whatsapp marketing automation test more than once. **Steps to replicate:** * Install `marketing_automation_whatsapp` * Setup whatsapp integration *…
Currently an error occurs when trying to run whatsapp marketing automation test more than once. **Steps to replicate:** * Install `marketing_automation_whatsapp` * Setup whatsapp integration * Marketing Automation > New > Start From Scratch > Add a new activity * Select Activity Type as Whatsapp Message and a Whatsapp Template * Launch a Test > Pick a contact > Launch > Run (Do this step twice) **Error:** `ValueError: Expected singleton: marketing.trace(6, 4, 3, 2, 1)` **Cause:** This error occurs because the variable `trace` contains multiple records, but the `process_event` method is being called on the entire recordset. Since `process_event` uses `self.ensure_one()`, it expects exactly one record, and therefore raises an error at [1] when multiple records are passed. **Solution:** * Handle trace records one by one using a loop. [1]: https://github.com/odoo/enterprise/blob/624b18bdb5dff0df4756c4e1d37a696631e57a05/marketing_automation_whatsapp/models/marketing_trace.py#L20 **Sentry-6772553612**
The Point of Sale system now checks connected device status less frequently, moving from every 5 seconds to every 60 seconds. This reduces unnecessary background work and can help stores with large product databases avoid slowdowns during PoS use.
Original PR description
We currently check the status of the connected devices every 5s. This is used in only a short selection of the devices and the delay is unnecessarily short. For databases with a lot of products this can unnecesarily slow down their PoS This PR increases the loop until 60s opw-5006302
Non-recurring products sold through upsell orders are now included in the Sales Analysis Report. This gives teams a more complete view of delivered quantities and revenue, improving sales reporting accuracy.
Original PR description
Problem: The non-recurring products added through upsell Sales Orders are not included in the Sales Analysis Report. This results in missing sales data for those products, leading to inaccurate…
Problem:
The non-recurring products added through upsell Sales Orders are not included in the Sales Analysis Report. This results in missing sales data for those products, leading to inaccurate reporting.
Purpose:
To ensure that non-recurring products added through upsell Sales Orders are correctly included in the Sales Analysis Report (report_all_channels_sales_action). This fix updates the report's domain filter to include upsell orders when the product is not recurring, resolving the issue of missing sales data for such products.
Steps to reproduce the bug:
1. Create a Sales Order (SO):
Add two products to the order:
- One recurring product (e.g., a subscription-based product with a recurring billing policy).
- One non-recurring (standard) product.
2. Confirm the SO
3. Generate an Invoice for the confirmed SO.
4. Validate the Invoice and deliver the non-recurring product (process the delivery order fully).
5. Create an Upsell Sales Order:
- From the original SO, create a new upsell SO.
- Add the same non-recurring product again.
6. Navigate to the Non-Recurring Product Page:
- Open the Product form for the non-recurring item.
- Click on the "Sold" smart button (shows delivered/sold quantities in the past 365 days).
- This opens the Sales Analysis Report (report_all_channels_sales_action) filtered by this product.
Issue:
The upsell Sales Order is not included in the Sales Analysis Report for the non-recurring product. As a result, the delivered quantity or revenue from upsell SOs is missing from the report for non-recurring products.
opw-4940977