Tuesday, March 18, 2025
18 changes
5 changes
Enhancements to existing features
Spreadsheet date filters now offer a simpler, improved date and time picker experience. This makes it quicker and less error-prone for users to choose dates when working with spreadsheet filters.
Original PR description
See community PR task-4613140
GSTR-2B bill matching now uses the IRN number when available, helping identify supplier bills more accurately and reducing incorrect partial matches. When Odoo creates a missing bill from GSTR-2B data, it also saves the IRN number, with checks to keep IRNs unique per company.
Original PR description
This commit adds an `IRN number` in matching parameters/keys. If the bills from `GSTR2B` have an IRN number then we consider the IRN number for finding the bill in the system and matching the bill with the GSTR2B bill. Also, we are removing ref from matching keys for false ref. A false ref can consider any gstr2b bill with only false ref to go through a matching process and match them partially matched. If there is no bill found in the system, but the bill is present on GSTR2B then we are creating the bill, here if the IRN number is available then add it to the new bill created. task-4408351
When document-related modules are installed, existing attachments on supported records will now be turned into the corresponding Documents entries automatically. This helps customers get a complete document library after enabling integrations, without needing manual cleanup or re-uploading files.
Original PR description
The document App introduces the document mixin that creates automatically a related document when linking an attachment to a record of a model that extends that mixin. But when we enable a bridge…
The document App introduces the document mixin that creates automatically a related document when linking an attachment to a record of a model that extends that mixin. But when we enable a bridge that add this behavior on some models, it is not retroactive. That's what we are implementing here: at install of such bridge module, we launch a cron that create all the document that would have been created if the bridge was installed from the beginning. Note that we don't deal here with the settings that allow the user to enable or disable this behavior as it will become standard with the PR: odoo/odoo#74571. Technical notes: - we avoid to launch the document creation in the post init hook as it could take some times. Instead, we launch the creation in a cron. The cron is defined in the document App and is configured to never be executed (interval 9999 months). In the post init hook, we just configure the next_call so that it is only executed once after the upgrade. To allow some retry in case of concurrent update/errors, we use the progress mechanism of the cron. The limitation is that we only allow a retry if there has been some progression to avoid infinite loop (see code). - the cron doesn't limit the creation of the documents to the bridge that has just been installed. It shouldn't be a problem as if the user delete a document linked to an attachment related to a record, the attachment is also deleted (i.e. won't lead to the creation of an unwanted document if we run the cron again). Task-3486322
WhatsApp event messaging now better supports events with multiple time slots. This helps businesses communicate more accurately with attendees when an event offers several scheduling options.
The report editor now offers a more consistent experience across editing modes. Users can preview reports in the visual editor, print from the preview, and use a read-only preview in XML editing mode, reducing confusion and making report checks easier.
Original PR description
task-3865778
13 changes
Resolved issues and error corrections
The self-ordering interface now appears in the language chosen by the user instead of always using the default language. This improves the experience for customers and staff using point-of-sale self-ordering in multilingual environments.
Original PR description
Before this commit, the interface was always shown in the default language. This fix ensures that the UI is displayed according to the user’s selected language. task-4609518 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change prevents the live chat interface from appearing twice on website pages. Visitors now see a single, clean chat entry point, reducing confusion and improving the support experience.
Original PR description
The live chat module the chat hub inside its shadow root. Do avoid duplicate, it used to remove the chat hub from the main components inside `boot_service.js` file. However, since [1], chat hub is added by a service. As a result, the code that used to removed the chat hub is executed too early resulting in two chat hubs being displayed. This PR fixes the issue by patching the service responsible for adding the chat hub to the main components registry. [1]: https://github.com/odoo/odoo/pull/201771
Sales orders with down payments taken through Point of Sale now correctly show the amount already invoiced when creating the final invoice. This prevents staff from seeing a zero value in the invoicing wizard and helps avoid billing confusion or duplicate charges.
Original PR description
Currently when invoicing a SO which has a downpayment made in Pos this downpayment is not reflected in the wizard. Steps to reproduce: ------------------- * Create an SO * Open pos session and make a downpayment for the SO * Close register * Go back to the SO * Deliver the items * Select the invoice > Observation: Amount already invoiced is at 0 Why the fix: ------------ There was a previous fix at the same place previously: https://github.com/odoo/odoo/commit/f613b87c38d208730ba2470e0a26a110c2089b66 However the wizard had changed and instead of showing `amount_to_invoice` we now show `amount_invoiced` opw-4585413
When workers add or increase components on a manufacturing order that is already in progress, the related stock transfer is now updated correctly. This helps ensure the right materials are moved to production and reduces the risk of shortages or manual corrections on the shop floor.
Original PR description
### Steps to reproduce: - In the settings, enable multi-step routes. - Set Warehouse to 2-step Manufacturing - Create a BoM with an operation and one move raw: 1 x COMP - Create confirm, plan and…
### Steps to reproduce: - In the settings, enable multi-step routes. - Set Warehouse to 2-step Manufacturing - Create a BoM with an operation and one move raw: 1 x COMP - Create confirm, plan and **start** an MO with that bom. - Through Shop Floor, on your operation > Wheel > add components - Set the quantity of COMP to 10 instead of 1. #### > In the backend, observe that the picking Stock -> Pre-Prod has not been updated ### Cause of the issue: Adding a product already referenced as a raw material via the catalog will trigger a call of the `_update_order_line_info` which will update the demand of the move raw: https://github.com/odoo/odoo/blob/38821f7ffae0aa15c10f3e6972b01aafade6bc60/addons/mrp/models/mrp_production.py#L2895-L2898 https://github.com/odoo/odoo/blob/38821f7ffae0aa15c10f3e6972b01aafade6bc60/addons/mrp/models/mrp_production.py#L2913-L2914 If you did not start the MO, this would run the procurement to update the demand and thus update the picking: https://github.com/odoo/odoo/blob/38821f7ffae0aa15c10f3e6972b01aafade6bc60/addons/mrp/models/stock_move.py#L434-L438 However, since the MO was started the state of the MO is 'in_progress' instead of 'confirmed'. Note: The issue was not reproducible before 18.0. Since adding a component was done via a call that would create and confirm a new move (hence running the procurements): https://github.com/odoo/enterprise/blob/b3febe5a1afd5c1c8fd598db95e8c58fa4131563/mrp_workorder/wizard/additional_product.py#L63-L68 Enterprise: https://github.com/odoo/enterprise/pull/81361 opw-4638371 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Delivered and received quantities now update correctly for kit products in intercompany sales and purchases. The change ensures transfers through transit locations are counted, giving teams accurate order fulfillment and receipt information.
Original PR description
Problem: The delivered and received quantities on sale order and purchase order lines don’t get updated during intercompany transactions for kit products. This is because the transit location is used…
Problem: The delivered and received quantities on sale order and purchase order lines don’t get updated during intercompany transactions for kit products. This is because the transit location is used instead of the supplier and customer locations. Purpose: Updating the filter to include transit locations will allow stock moves to and from the transit locations to be included in the delivered and received quantities. Steps to Reproduce on Runbot: 1. Enable Inter-Company Transactions for both companies, with Generate Sales Orders, Generate Purchase Orders, and Synchronize Deliveries to your Receipts selected. 2. Create a product and create a kit type bill of materials for it. Remove the company from the bill of materials so it is available for both companies. 3. Create a sale order for this kit product with the customer set to another one of your companies. 4. Confirm the sale order and validate the picking. 5. Observe the delivered quantity on the sale order line is still 0. 6. Switch to the company you sold the kit to. 7. Navigate to the purchase order that was created and confirm it. 8. Validate the picking. 9. Observe the received quantity is still 0. opw-4536144 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where loyalty points could be changed for multiple open POS orders when only one order was paid. Loyalty balances are now updated only for processed orders, preventing incorrect point deductions or awards for customers with draft orders.
Original PR description
Currently, when having multiple orders opened, when validating one, the points will be granted for all opened orders. Steps to reproduce: ------------------- * Have a loyalty progam with * 1point per $ spent * 5% on order in exchange of 200 points * Have 2 customers A and B with 300 each on their loyalty card * Open pos shop * On the order, select customer A, add items and select the reward * Open a new floating order, do the same but for customer B * Pay the order related to customer B * Go in the backend and check the loyalty card of customer A > Observation: Point have been modifyed * Back in the shop, pay order related to cusotmer A * Go in the backend and check the loyalty card of customer A > Observation: points have been modifyed twice Why the fix: ------------ Only processed orders should modify the points available on the loyalty card in the backend. opw-4539274
Portal shoppers can now configure combo products that include unpublished configurable items when those items belong to a published combo product. This prevents checkout disruption while keeping unpublished combo items unavailable for direct selection from the cart.
Original PR description
_* : website_sale Steps: - Create a combo product with combo items containing unpublished configurable product - on /shop as portal user add the combo product and try to configure any unpublished product Issue: - access error Cause: - The product configurator doesn't sudo the product which is being configured Fix: - if the product for product_configurator is part of published combo product, it will be sudo'ed opw: 4567008 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix stops Italian electronic invoicing from automatically treating negative invoice lines as discounts. It avoids confusion for businesses where negative lines represent other accounting situations, making invoice exports better match user intent.
Original PR description
Feedbacks given talked about the fact the negative lines were wrong and should be considered as discounts. But that's not the case for every user and is more confusing than anything else. So we remove this logic from Italy. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The point of sale now keeps the cashier on the payment screen if the session becomes idle during an online payment. This prevents the active order from losing its context, avoiding confusing empty tickets or unfinished orders after the customer completes payment.
Original PR description
Description of the issue/feature this PR addresses: When doing online payment in POS, customer may take some time and the POS may go to idle state. This causes when it goes to idle and back to alive,…
Description of the issue/feature this PR addresses: When doing online payment in POS, customer may take some time and the POS may go to idle state. This causes when it goes to idle and back to alive, it will direct to the first screen. Steps to reproduce: - Create POS & setup POS online payment (use Demo online payment) - Open POS, add a product, go to payment screen, select the online payment method - Let it go to idle state (triggered by useIdleTimer) - Move the cursor, or at least make it back to active state - You'll see the screen be redirected to first screen - Do the payment, it will redirect to TicketScreen with empty order info, and when you click new order the previous one is still hanging there Alternatively take a look at the recording: https://github.com/user-attachments/assets/b8e8ae81-df04-41e0-b122-002413714735 Current behavior before PR: - Because it bounces to first screen, when attempting payment the pos does not have the order state Desired behavior after PR is merged: - Do not redirect if in payment screen, so that order context won't be lost --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When operators add or increase components on a manufacturing order that is already in progress, Odoo now updates the related stock transfer to pre-production. This prevents missing material moves in two-step manufacturing flows and keeps shop floor changes aligned with warehouse operations.
Original PR description
### Steps to reproduce: - In the settings, enable multi-step routes. - Set Warehouse to 2-step Manufacturing - Create a BoM with an operation and one move raw: 1 x COMP - Create confirm, plan and…
### Steps to reproduce: - In the settings, enable multi-step routes. - Set Warehouse to 2-step Manufacturing - Create a BoM with an operation and one move raw: 1 x COMP - Create confirm, plan and **start** an MO with that bom. - Through Shop Floor, on your operation > Wheel > add components - Set the quantity of COMP to 10 instead of 1. #### > In the backend, observe that the picking Stock -> Pre-Prod has not been updated ### Cause of the issue: Adding a product already referenced as a raw material via the catalog will trigger a call of the `_update_order_line_info` which will update the demand of the move raw: https://github.com/odoo/odoo/blob/38821f7ffae0aa15c10f3e6972b01aafade6bc60/addons/mrp/models/mrp_production.py#L2895-L2898 https://github.com/odoo/odoo/blob/38821f7ffae0aa15c10f3e6972b01aafade6bc60/addons/mrp/models/mrp_production.py#L2913-L2914 If you did not start the MO, this would run the procurement to update the demand and thus update the picking: https://github.com/odoo/odoo/blob/38821f7ffae0aa15c10f3e6972b01aafade6bc60/addons/mrp/models/stock_move.py#L434-L438 However, since the MO was started the state of the MO is 'in_progress' instead of 'confirmed'. ### Note: The issue was not reproducible before 18.0. Since adding a component was done via a call that would create and confirm a new move (hence running the procurements): https://github.com/odoo/enterprise/blob/b3febe5a1afd5c1c8fd598db95e8c58fa4131563/mrp_workorder/wizard/additional_product.py#L63-L68 Community: https://github.com/odoo/odoo/pull/201592 opw-4638371
Invoices using external tax calculators can now keep expected zero-value tax lines so they can be updated with the correct externally calculated tax. This prevents missing journal tax lines on fully discounted invoices where tax is still due, improving accounting accuracy for Avatax and similar integrations.
Original PR description
Tax lines are not created in cases where Odoo expects them to be $0 [1]. This is problematic for cases where tax is computed externally and the tax is not in fact $0. There is now no tax line to…
Tax lines are not created in cases where Odoo expects them to be $0 [1]. This is problematic for cases where tax is computed externally and the tax is not in fact $0. There is now no tax line to adjust to the right amount. To reproduce: 1. Configure Avatax 2. Configure the Discount product to have the "Non-taxable product" Avatax category 2. Create an invoice to Azure Interior 3. Select the Avatax fiscal position 3. Add 1 FURN_6667 with default unit price $295 4. Add 1 Discount with unit price -$295 5. Click "Compute Taxes" The invoice is fully discounted but $30.24 tax must still be paid. This is correct. It's reflected in the invoice total, but the tax lines are not in the journal items. `_set_external_taxes()` goes through the summary to set the right tax amounts, but cannot find the line. This solves the issue by using a new hook in accounting that prevents these $0 tax lines from being excluded. opw-4493544 ## PR note Alternative to https://github.com/odoo/enterprise/pull/80095.
Fixes subscription churn reporting when a renewed subscription has different discount terms than the original. Churn amounts are now based on previous monthly recurring revenue logs, preventing misleading negative revenue figures after cancellations.
Original PR description
Steps to reproduce: - Install `sale_subscription` - Create a sub with a discount - Confirm and invoice it - Renew the sub without the discount - Confirm the renewal - Remove the discount on the original sub via the shell since it's locked (simulate first year discount removal) - Cancel the renewal Issue: MRR log is now negative, this is due to how the way `amount_signed` is computed during the churn event creation. Recurring monthly is now greater because we deleted the first year discount, which results in negative MRR. https://github.com/odoo/enterprise/blob/5a7b55f9e059c3b54492e184d1e2429779399d08/sale_subscription/models/sale_order_log.py#L174 Solution: Compute `amount_signed` using the sum of the previous logs.
This update resolves several issues affecting accounting, manufacturing, field service, delivery tests, and regional reporting. It also adds Spain's Modelo 130 tax report and improves Belgian CodaBox workflows, helping users get more accurate reports, clearer screens, and fewer posting errors.