Daily updates from Odoo
Friday, March 27, 2026
10 changes · 18.0
New functionality added to Odoo
This update integrates Viettel SInvoice, enabling Point of Sale (PoS) systems to automatically generate and attach e-invoices compliant with Vietnamese regulations. The changes improve the PoS system's ability to meet local tax requirements and streamline the invoicing process for Vietnamese businesses. A key technical update involves extracting invoice file retrieval logic for reusability and improved accuracy.
Original PR description
Add Viettel SInvoice integration with the Point of Sale module to support PoS e-invoicing for the Vietnamese market. task-4844619
Enhancements to existing features
This update incorporates changes to India's tax regulations (IT Act 2025) regarding TDS and TCS. It adds new tax sections and calculations aligned with the updated legislation, ensuring accurate reporting and compliance. Existing tax configurations have been deactivated to reflect the new rules.
Original PR description
The Income Tax Bill 2025 introduces TDS and TCS provisions in a more structured way compared to the existing Income-tax Act 1961, with the addition of new sections and taxes. This commit adds new sections and corresponding taxes for sections 392, 393, and 394, along with their respective reports. It also introduces new TDS and TCS tax groups for these taxes to differentiate them from the existing ones. The old taxes are deactivated as they are no longer applicable. task-6035844
Resolved issues and error corrections
This update fixes an issue where barcode scans didn't correctly apply putaway rules, resulting in incorrect destination locations for new stock moves. The fix ensures that barcode-created moves now automatically use the designated shelf location as defined in the putaway rules, improving inventory accuracy.
Original PR description
**Steps to reproduce:** * Install the `stock` module. * Go to Inventory → Configuration → Settings and enable Storage Locations(warehouse). * Create a new tracked product: * Enable Track Inventory by…
**Steps to reproduce:**
* Install the `stock` module.
* Go to Inventory → Configuration → Settings and enable Storage
Locations(warehouse).
* Create a new tracked product:
* Enable Track Inventory by Lots.
* Assign a Barcode to the product.
* Go to Inventory → Configuration → Putaway Rules and create a rule:
* When Product arrives in:`WH/Stock`
* Store to: `WH/Stock/Shelf 1`
* Go to Inventory → Configuration → Operations Types → Internal
Transfers and enable Create New under Lots/Serial Numbers.
* Open the Barcode application.
* Navigate to Operations → Internal Transfers and create a New
transfer.
* Scan the product barcode.
* Scan lot lot1.
* Scan lot lot2.
**Issue:**
The barcode flow sets a wrong destination location on the generated move lines.
Current:
- `WH/Stock`
Expected:
- `WH/Stock/Shelf 1`
The destination should follow the putaway rule, but barcode-created lines
keep the raw operation destination instead of the putaway-resolved sublocation.
**Cause:**
The issue comes from the barcode new-line creation flow.
The scan starts in `BarcodeModel._processBarcode()`
When no matching line is found, `_processBarcode()` prepares the scanned values
with `_convertDataToFieldsParams()` then calls `createNewLine()`
`createNewLine()` is only a wrapper and directly forwards the
call to `_createNewLine()`
So the flow is:
`_processBarcode()` -> `_convertDataToFieldsParams()` then `createNewLine()` ->
`_createNewLine()`
Then the real issue comes in `_createNewLine()`
where the new line is created with:
https://github.com/odoo/enterprise/blob/c5e90ec84f4b18cae93fc4d1b4a1d830f66cb90b/stock_barcode/static/src/models/barcode_model.js#L798-L802
The data used by `createNewLine()` comes from `_convertDataToFieldsParams()` in
There, `location_dest_id` is only set if the user explicitly scans a
destination location, at and In this flow no destination location is scanned
manually,
https://github.com/odoo/enterprise/blob/c5e90ec84f4b18cae93fc4d1b4a1d830f66cb90b/stock_barcode/static/src/models/barcode_picking_model.js#L1170-L1173
so `fieldsParams` does not contain
`location_dest_id`.
Because of that, `_createNewLine()` falls back to `_getNewLineDefaultValues()`
in which sets:
https://github.com/odoo/enterprise/blob/c5e90ec84f4b18cae93fc4d1b4a1d830f66cb90b/stock_barcode/static/src/models/barcode_model.js#L877
`_defaultDestLocation()` itself simply returns the picking destination location
So the issue is that the barcode model has no putaway handling when creating a
new line.
It simply takes the default destination from the picking, and that is
why the move line gets `WH/Stock` instead of the putaway destination
`WH/Stock/Shelf 1`.
**Fix:**
The fix is to handle putaway when a new line is created from the Barcode app.
Since the base barcode model does not handle putaway for new lines,
So add that logic in `BarcodePickingModel._createNewLine()`.
The new flow is:
- if a destination location was explicitly provided in `fieldsParams`,
keep it as is
- if a selected line already exists for the same product and already has
the correct destination, reuse that selected line destination
- otherwise, make one RPC call to get the putaway-resolved destination
for the new line
This RPC returns the correct destination according to the putaway rule,
and that value is assigned to the new line instead of keeping
the normal picking destination.
With this fix, barcode-created lines no longer fallback to `WH/Stock`.
They now use the correct putaway destination `WH/Stock/Shelf 1`.
---
opw-5220141This update fixes an issue where failing quality checks in subcontracting production orders led to incorrect quantity updates, causing inconsistencies in recorded products. The change ensures that quantities are correctly reduced from productions linked to the inspected lot, preventing unintended impacts on recorded products. This improves the accuracy of inventory tracking within subcontracting processes.
Original PR description
*:mrp_subcontracting{,_quality}, quality_control **Issue** In subcontracting, a failing quality check could lead to inconsistent quantities. **Steps to reproduce** - Create two tracked products…
*:mrp_subcontracting{,_quality}, quality_control
**Issue**
In subcontracting, a failing quality check could lead to inconsistent quantities.
**Steps to reproduce**
- Create two tracked products (final and component)
- Create a BoM for the final product using the component, with subcontracting
- Create a pass/fail Quality check with:
- Operation type: Receipts
- Control per Quantity
- Create a PO for the final product:
- With a quantity of 3
- With the associated partner be the one mentioned in the subcontracting BOM
- Confirm it
- Open the associated receipt
- Record 2/3 products
- Perform the quality check and fail 1 product
-> The quantity is removed from the 1 unrecorded product instead of the recorded ones
-> It is no longer possible to record additional products, although 1 should still be available
**Cause**
While recording products, the subcontracting production is split into multiple productions:
https://github.com/odoo/odoo/blob/a03fb90069c5a51340c81626cc90dbea22ca45bb/addons/mrp_subcontracting/models/mrp_production.py#L76
https://github.com/odoo/odoo/blob/a03fb90069c5a51340c81626cc90dbea22ca45bb/addons/mrp_subcontracting/models/mrp_production.py#L94
When a quality check fails, the quantity is reduced on the stock move:
https://github.com/odoo/enterprise/blob/2d3722242461a77ed954cc09835539e8010494f8/quality_control/models/quality.py#L471
This reduction is propagated to the subcontracting productions, removing the quantity from the first production,
then the next one if needed.
The production order is determined here:
https://github.com/odoo/odoo/blob/a03fb90069c5a51340c81626cc90dbea22ca45bb/addons/mrp_subcontracting/models/stock_move.py#L320
As a result, the reduction could be applied to a production unrelated to the inspected lot.
**Solution**
In case of a quality failure, ensure subcontracting productions are ordered so that:
- productions linked to the inspected finished lot (when lot tracking is enabled), and
- among them, productions that have already been recorded
are reduced first when applying the quality failure.
opw-5427873This update resolves an issue where the Master Production Schedule (MPS) wasn't properly considering safety stock levels for indirect demand. The change ensures that demand forecasts accurately reflect the need to buffer against potential supply disruptions, improving production planning accuracy. This primarily impacts how the system calculates and schedules production for components.
Original PR description
Steps to reproduce: ------------------- * Enable "Master Production Schedule" in Inventory settings * Create tracked Product "Child" and set up a vendor * Create tracked Product "Parent" and set up a…
Steps to reproduce: ------------------- * Enable "Master Production Schedule" in Inventory settings * Create tracked Product "Child" and set up a vendor * Create tracked Product "Parent" and set up a bom as component "Child" and Lead Time: 2 days * Create tracked Product "GParent" and set up a bom as component "Parent" and Lead Time: 2 days * Open MPS and add your three products: - Child, Parent: activate indirect demand - Parent: Safety Stock Target of 10 * Add 1 in the forecast demand for "Gparent" on third column -> Will have 20 Indirect Demand Forecast of Child in the first column and -9 on the second Observation: ------------- Usefull comment form the function : https://github.com/odoo/enterprise/blob/b332af45a46b2295797a5096f68b7953554a495b/mrp_mps/models/mrp_mps.py#L424-L447 When creating a demand from the MPS, it will always take the first date of the interval (ex: Week 10 (2-8/Mar), it will create the demand for the 2 of Mars) When calculating the production schedule. we wil we calculate each product for each date_range: https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L488 https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L509 When calculating the values for a product, we will set the indirect demand qty for it component The demand will created the demand in function of the date of when the parent need and the lead time (it will for the previous date range because of the lead time): https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L554 https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L555 If the demand is not equal to the resplensih_qty we will create another demand to compensate, it will use the first date of range minus the lead time it will send it to the previous date range: https://github.com/odoo/enterprise/blob/ea805995f66e007c0aef6b473a2b16dbe54d73bc/mrp_mps/models/mrp_mps.py#L556-L560 In our case this will create the issue, since it will try to compensate each time on the previous week. opw-5413838
This update fixes an issue where failing quality checks in subcontracting production orders incorrectly reduced quantities, leading to inconsistencies. The change ensures that quantities are accurately deducted from the correct production orders when a quality failure occurs, resolving a discrepancy in recorded product quantities.
Original PR description
*:mrp_subcontracting{,_quality}, quality_control **Issue** In subcontracting, a failing quality check could lead to inconsistent quantities. **Steps to reproduce** - Create two tracked products…
*:mrp_subcontracting{,_quality}, quality_control
**Issue**
In subcontracting, a failing quality check could lead to inconsistent quantities.
**Steps to reproduce**
- Create two tracked products (final and component)
- Create a BoM for the final product using the component, with subcontracting
- Create a pass/fail Quality check with:
- Operation type: Receipts
- Control per Quantity
- Create a PO for the final product:
- With a quantity of 3
- With the associated partner be the one mentioned in the subcontracting BOM
- Confirm it
- Open the associated receipt
- Record 2/3 products
- Perform the quality check and fail 1 product
-> The quantity is removed from the 1 unrecorded product instead of the recorded ones
-> It is no longer possible to record additional products, although 1 should still be available
**Cause**
While recording products, the subcontracting production is split into multiple productions:
https://github.com/odoo/odoo/blob/a03fb90069c5a51340c81626cc90dbea22ca45bb/addons/mrp_subcontracting/models/mrp_production.py#L76
https://github.com/odoo/odoo/blob/a03fb90069c5a51340c81626cc90dbea22ca45bb/addons/mrp_subcontracting/models/mrp_production.py#L94
When a quality check fails, the quantity is reduced on the stock move:
https://github.com/odoo/enterprise/blob/2d3722242461a77ed954cc09835539e8010494f8/quality_control/models/quality.py#L471
This reduction is propagated to the subcontracting productions, removing the quantity from the first production,
then the next one if needed.
The production order is determined here:
https://github.com/odoo/odoo/blob/a03fb90069c5a51340c81626cc90dbea22ca45bb/addons/mrp_subcontracting/models/stock_move.py#L320
As a result, the reduction could be applied to a production unrelated to the inspected lot.
**Solution**
In case of a quality failure, ensure subcontracting productions are ordered so that:
- productions linked to the inspected finished lot (when lot tracking is enabled), and
- among them, productions that have already been recorded
are reduced first when applying the quality failure.
opw-5427873This update fixes issues with how Odoo captures Chrome logs during shutdown, ensuring critical errors are recorded. The changes also enhance the stability of the shutdown process by addressing log buffering problems and adding safeguards to handle Chrome termination issues.
Original PR description
odoo/odoo#255054 saved the chrome log at the end of a tour (logging that as `INFO` on success and `RUNBOT` on failure). However as it turns out there are a few issues with that: 1. In case of chrome error during termination (`stop`), those errors can not be in the log, since the log was already saved. 2. Chrome buffers logs a lot more than anticipated, and because `--v=0` logs are a lot less chatty than `--v=1` the logs routinely show essentially nothing (a few tour steps are logged then nothing). Also make `stop` a bit more resilient to chrome issues: - handle errors around ws shutdown - wait for chrome to shut down before we try to remove the data directory - also add a fallback *killing* chrome if it doesn't seem to be shutting down Forward-Port-Of: odoo/odoo#256123 Forward-Port-Of: odoo/odoo#256061
This update resolves an issue where the Point of Sale app on iOS/Safari experienced crashes due to IndexedDB connection interruptions. Specifically, the app now handles situations where the database connection is lost or the app returns from the background, preventing errors and improving overall stability for iOS users. This ensures a smoother Point of Sale experience.
Original PR description
On iOS/Safari, the WebKit IDB server process can be killed by the OS (e.g. due to memory pressure when the app is backgrounded), resulting in an UnknownError: "Connection to Indexed Database server lost". Additionally, returning from background can leave the connection in an InvalidStateError "closing" state while this.db remains non-null. opw-5121896 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update addresses an issue where picking actions within the MRP and stock modules could trigger unintended consequences. The changes aim to stabilize these processes and avoid disruptions to inventory management. This resolves several related operational problems (opw-6069780, opw-6065341, etc.)
Original PR description
Commit [1] impacts some other flows (like on a picking) [1] 63e44737fe469ab56b8e8e96c1ad47205ead1094 opw-6069780 opw-6065341 opw-6071663 opw-6073396 opw-6065189 opw-6070129 opw-...
This update corrects a bug where modifying a recurring event's start time would incorrectly recreate Outlook events, leading to duplicate invitations and notifications. The fix ensures Microsoft IDs are preserved, preventing these issues and improving the reliability of meeting synchronization.
Original PR description
When an attendee syncs a recurring event where the first occurrence (base event) was modified by the organizer, `_write_from_microsoft` falsely triggers the destructive recreation path. This happens because `_has_base_event_time_fields_changed` compares the exception's modified time against the seriesMaster's pattern time, detecting a "change" even though the master hasn't changed. This causes: - All non-base events lose their microsoft_id and ms_universal_event_id - The base event gets recreated without Microsoft IDs - A duplicate event is pushed to Outlook on the next odoo2microsoft sync - Spurious "join the meeting now" notifications are sent to attendees Add a `follow_recurrence` guard so that when the base event is an exception (follow_recurrence=False), the non-destructive else branch is taken instead, preserving all Microsoft IDs. Forward-Port-Of: odoo/odoo#254414