Monday, December 15, 2025
12 changes · 19.0
Enhancements to existing features
This update ensures that tax information, which the company pays to the government and later claims as a refund, is included in the invoice data sent for government reporting. This aligns with current tax regulations for India (l10n_in_edi) and provides accurate financial data for government transactions. It improves the reliability of exported data.
Original PR description
Following the task- https://www.odoo.com/odoo/project.task/4878805 and PR- https://github.com/odoo/odoo/pull/213931 Here we are not collecting tax from the customer but the company has pay taxes to the goverment and after that the company can claim refund for the taxes. So when we are sending data to goverment then we need to include tax part into the invoice total task-5369117 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238942 Forward-Port-Of: odoo/odoo#238641
This update ensures that the total tax amount paid by the company is included when generating reports for government tax filings (GSTR). Previously, only sales revenue was reported. This change accurately reflects the company's tax obligations and provides a complete picture for reporting purposes.
Original PR description
Here we are not collecting tax from the customer but the company has pay taxes to the goverment and after that the company can claim refund for the taxes. So when we are sending report data to goverment then we need to include tax part into the invoice total task-5369117 Forward-Port-Of: odoo/enterprise#101525 Forward-Port-Of: odoo/enterprise#101308
This update adds detailed logging for communication with the Odoo blackbox. Combined with a related feature for saving and downloading logs, this will significantly simplify troubleshooting client issues and improve support efficiency. It's a key step in proactively addressing potential problems.
Original PR description
Community PR: https://github.com/odoo/odoo/pull/236927 This commit adds several log messages for the communication with the blackbox. In combination with the associated Community PR to save and download these logs, this should enable easier debugging when clients experience problems. Forward-Port-Of: odoo/enterprise#102041 Forward-Port-Of: odoo/enterprise#100183
Resolved issues and error corrections
This update resolves an issue where saving changes to the website footer template caused errors due to how customizations were being applied. The fix ensures that necessary CSS classes are always present, allowing users to successfully save their footer designs after making changes like switching templates or editing company names. This improves the overall stability and usability of the website builder.
Original PR description
The new footer templates had xpath selectors that were breaking in case the user changed some things in the footer. This is caused by a different order of evaluation after the copy is made to save the customized website view. This commit patches the view to add the class on which the xpath relies so that it is always present, thus the xpath always apply. Steps to reproduce: - Open website builder (on an new db) - Click on the footer - Change "Template" to "Mega" (or "Mega Columns", or "Mega Links") - Click on "Company Name" in the footer, and edit the text - Save - Bug: save fails because an xpath does not apply Commit adding "Mega": f252e096a3c8c432e601f6bae6fc1c11cd92c90b Commit adding "Mega Columns": aa0e653b5f641c735b4b6e25f80ae5d1d0a6dd94 Commit adding "Mega Links": 97ab0bc41bd3e5bd48b7e35e7d6918017d66004d task-5181309
This update ensures that rental products are correctly unavailable when their associated employees are on time off. Previously, the system didn't account for employee absences, leading to incorrect availability displays. This fix improves the accuracy of rental product availability, enhancing the customer experience.
Original PR description
…navailabilties Before this commit, when an human resource is linked to rental product thanks to his role and take a time off at a certain day. The user inside ECommerce should be able to add that product when the resource is off (since there is no resource available) at the period chosen. However, that check does not take into account the time off taken by the resources linked to that service rental product. This commit makes sure the time off of the resources linked to the product are correctly taken into account to know if the service rental product is available at a specific period. task-5075698 Forward-Port-Of: odoo/enterprise#98165
This update resolves an issue where multi-step manufacturing processes involving by-products weren't correctly registering the by-product lines in the system. The fix ensures that by-products are properly added to the manufacturing process, creating the necessary pre-production and production lines. This improvement streamlines the 3-step manufacturing workflow.
Original PR description
### Steps to reproduce: - In the settings enable By-Products an Multi-step routes - Put your warehouse in manufacturing in 3 steps - Create two storable products: - Final Product (FP) with an empty…
### Steps to reproduce:
- In the settings enable By-Products an Multi-step routes
- Put your warehouse in manufacturing in 3 steps
- Create two storable products:
- Final Product (FP) with an empty bom
- By Product (BP)
- Go to the barcode app > Operations > Manufacturing > New
- Scan FP > Register By-Products
- Scan BP
#### > The line is created with pre-prod as location and prod as destination
### Cause of the issue:
Since no existing line refers to the by product, a new line is created and its `location_id` and `location_dest_id` are provided by the `_getNewLineDefaultValues`:
https://github.com/odoo/enterprise/blob/17fd46b04d87585b7ed46c00d9559414daa17384/stock_barcode/static/src/models/barcode_model.js#L562-L566 However, at this point nothing had set the `params.newByProduct` in the `processBarcode`:
https://github.com/odoo/enterprise/blob/17fd46b04d87585b7ed46c00d9559414daa17384/stock_barcode_mrp/static/src/models/barcode_mrp_model.js#L375-L383 In fact, the only thing indicating that we are creating a by prodcut line at this point is the `displayByProduct`.
### Note:
The issue is no longer reproducible in 18.0+ as this change has already been applied in 2d5dbb93e6b33c2be786f9b2361c993f715d1a7f
opw-5350222
Forward-Port-Of: odoo/enterprise#101861
Forward-Port-Of: odoo/enterprise#101087This update fixes a bug where credit notes weren't being accurately accounted for when settling invoices. The change allows credit notes to be properly deducted from totals, ensuring accurate financial reporting. This improves the reliability of the POS settlement process.
Original PR description
We had a bug when settling invoices and credit notes of a customer. The credit notes where not correctly computed. Steps to reproduce: ------------------- In accounting: * Create and confirm a customer invoice for a total of 10$. * Create and confirm for the same customer a credit note for a total of 2$. In POS: * In a seesion, open the customer selection menu. * In the burger menu at the right of our customer, select Settle invioces. * Select our invoice and credit note. > Observation: The credit note was previously seen as an amount to pay. Why the fix: ------------ Recomputing updates existing credit notes to use the signed residual logic. The domain change allows credit notes with negative pos_amount_unsettled to appear. After these changes, credit notes should appear in the "Settle invoices" dialog with negative amounts, and selecting them will create negative lines that reduce the total. opw-5257884 Forward-Port-Of: odoo/enterprise#101186
This update ensures that users are prevented from adding rental products to their cart when the resource is unavailable during the selected rental period. Previously, the system didn't check availability if the ‘website_sale_renting_stock’ module wasn't installed, leading to incorrect booking attempts. This change improves the user experience by accurately reflecting resource availability.
Original PR description
Before this commit, when the user goes to the webshop to take a rental service with rental service unavailable at a certain period, the system does not block the user when the resource is not available during 2 hours in the period chosen by the user. The reason is because the hours are not checked when website_sale_renting_stock is not installed. This commit moves the code checking the time of the rental period made in website_sale_renting_stock in website_sale_renting to be able to have that verification for rental service used with planning to make sure the system will prevent the user to add the product in his cart when the resource is unavailable. task-5123239 Forward-Port-Of: odoo/enterprise#96241
This update fixes a calculation error in the MRR evolution dashboard that was causing 'Contraction' figures to be double-counted. The change ensures the dashboard accurately reflects the true net new MRR by properly accounting for contraction trends. This improves the accuracy of revenue forecasting.
Original PR description
…traction **Issue** The formula defined for the "Net new" in the MRR evolution dashboard double counted the "Contraction", as it is already included in the "Up/Downgrade" (cell B6, equal to B4+B5, "Contraction" + "Expansion"). <img width="360" height="354" alt="image" src="https://github.com/user-attachments/assets/0a19a86a-f1b9-462f-812c-71a283f6fe89" /> opw-4925930 Forward-Port-Of: odoo/enterprise#101598 Forward-Port-Of: odoo/enterprise#96878
This update prevents delays when the IoT connection fails. Previously, WebRTC would repeatedly attempt to connect, causing a 6-second fallback to longpolling. Now, if WebRTC fails, it's disabled for 20 minutes, ensuring smoother and faster communication with IoT devices.
Original PR description
Before this commit, WebRTC was always used as the first protocol when communicating with the IoT box. However, in an environment where it was not working, it would take 6 seconds to fallback to longpolling on every request. After this commit, if WebRTC fails, we don't try to use it again for 20 minutes. task-5412223
This update resolves an issue where a key calculation related to account reconciliation was unintentionally removed during a recent system update. This fix ensures accurate reporting of financial transactions and prevents potential discrepancies in accounting data. It's a necessary correction to maintain the integrity of our financial records.
Original PR description
During the forward port of: https://github.com/odoo/enterprise/pull/94552 the recompute of the checked field was removed. It needs to be added back no task id Forward-Port-Of: odoo/enterprise#102086
This update fixes an issue where the VAT summary report for Argentinian invoices was incorrectly calculating totals when multiple IIBB taxes were applied. The fix ensures that VAT amounts are counted accurately, aligning the report totals with the accounting form view. This improves the reliability of financial reporting for Argentinian customers.
Original PR description
**Issue** When using a VAT tax marked as price included, together with multiple IIBB taxes on the same invoice, the VAT summary report displays an incorrect total. Specifically, the VAT amount is…
**Issue** When using a VAT tax marked as price included, together with multiple IIBB taxes on the same invoice, the VAT summary report displays an incorrect total. Specifically, the VAT amount is counted multiple times, once for each IIBB tax, leading to an inflated total. **Steps to Reproduce** 1. Install the Accounting app and the Argentinian localization (l10n_ar) 2. Set the 21% VAT Purchase tax as Included in Price 3. Create a vendor bill applying the 21% VAT tax and at least two IIBB taxes 4. Open the VAT summary report for that bill Expected Behaviour: The total in the VAT summary should match the total shown in the accounting form view, with each tax counted only once. **Root Cause** The VAT summary report in the Argentinian localization relies on an SQL query to aggregate tax information for each `account.move`. The query joins `account_move_line` with `account_tax`, `account_tax_group`, and the many-to-many relation table `account_move_line_account_tax_rel`. Each `account_move_line` related to a VAT tax line (via `tax_line_id`) is joined with the `account_move_line_account_tax_rel` table. If that base line is related to multiple IIBB taxes, the join multiplies the VAT line once per IIBB tax since multiple matching rows exist. **Fix** The solution separates the logic for computing tax lines and base lines into two distinct subqueries. Each is aggregated independently to prevent duplication caused by one-to-many and many-to-many joins. The results are then joined using the unique `account_move_line.id`, ensuring each tax amount is counted exactly once in the final totals. opw-4776861 Forward-Port-Of: odoo/enterprise#98933 Forward-Port-Of: odoo/enterprise#85873