Saturday, April 25, 2026
5 changes · saas-19.1
Resolved issues and error corrections
This update resolves an issue where the 'is_company' field in several Latin American localizations (AR, BR, EC, CO, PE,UY) was incorrectly configured after a recent system change. The fix ensures accurate company detection, improving data integrity and functionality for users in these regions. It's a general fix impacting multiple localization modules.
Original PR description
*: l10n_{ar,br,ec}
In 19.1 we changed the `is_company` field to a computed
stored field.
This change needs to be reflected correctly in many localisations
where the default computed value is too naive.
This commit is introducing a generic fix for most l10n that depends
on the module `l10n_latam_base`.
Improve the test coverage for the computation.
Note: This is not strictly necessary for this fix
on Enterprise side, since we removed the invisibility
condition but in case of some customization relying
on it it's safer if we can deduce it correctly.
Enterprise: https://github.com/odoo/enterprise/pull/114403
Related: https://github.com/odoo/odoo/pull/211043
task-6141307This update resolves an issue where Peruvian identifiers (like driver licenses) were not displaying correctly in Odoo 19.1 due to a change in how company information was stored. The update removes a restriction on displaying these identifiers, ensuring accurate reporting and data visibility for Peruvian users. This fix also includes a related update to the Community version of the code.
Original PR description
In 19.1 we changed the `is_company` field to a computed stored field. That change broke the visibility for some Peruvian identifiers (driver license, etc). This commit removes the visibility condition on those fields to be displayed all the time. Note: we still add the correct compute on related Community commit for sake of correctness and completeness. Community: https://github.com/odoo/odoo/pull/260224 Related: https://github.com/odoo/odoo/pull/211043 task-6141307
This update resolves a technical issue that was limiting the efficiency of WhatsApp marketing automation. Previously, the system wasn't processing all relevant messages at once, leading to slower performance. This fix ensures that all necessary steps are executed, resulting in a smoother and more reliable marketing automation experience.
Original PR description
Forward-Port-Of: odoo/enterprise#114570
This update fixes a technical issue that caused errors when a restaurant order with an active Fiskaly transaction was opened on multiple devices. Previously, the system didn't properly share transaction details, leading to duplicate transaction attempts and API errors. This change ensures consistent transaction data is shared, improving the reliability of the restaurant POS system.
Original PR description
In a restaurant POS, when an order with an active Fiskaly transaction is opened on a second device, `transactionState` and `tx_revision` were not available (uiState is not persisted to the server), causing the new device to attempt creating a duplicate transaction with a stale revision, which resulted in a Fiskaly API error. opw-6147654 Forward-Port-Of: odoo/enterprise#115170 Forward-Port-Of: odoo/enterprise#114599
This update corrects a bug where Purchase Orders and Manufacturing Orders were incorrectly linked to each other, even when unrelated to a Sales Order. The fix ensures that POs only link to Sales Orders, and MOs only link to Sales Orders, improving data accuracy and streamlining the manufacturing process.
Original PR description
**Steps to reproduce:** * Install modules: *mrp*, *purchase*, *sale_management*. * Go to *Settings* and enable: * *Multi-Step Routes* * *Replenish on Order (MTO)* * *Dropshipping* * Create a…
**Steps to reproduce:**
* Install modules: *mrp*, *purchase*, *sale_management*.
* Go to *Settings* and enable:
* *Multi-Step Routes*
* *Replenish on Order (MTO)*
* *Dropshipping*
* Create a *Dropship* product:
* Set route to *Dropship*.
* Add a vendor under the *Purchase* tab.
* Create an *MTO* product:
* Set route to *Replenish on Order (MTO)*.
* Configure a *Bill of Materials (BoM)*.
* Create a *Sales Order*:
* Add both products.
* Confirm the order.
* Open the Sales Order:
* Observe smart buttons for *Delivery*, *Purchase*, and *Manufacturing*.
* Open the linked *Purchase Order* and *Manufacturing Order*.
**Observed behavior:**
* The *Purchase Order* shows a smart button linking to a *Manufacturing Order*.
* The *Manufacturing Order* shows a smart button linking to a *Purchase Order*, even when unrelated.
**Expected behavior:**
* The *Purchase Order* should only show a smart button linking to the *Sales Order*.
* The *Manufacturing Order* should only show a smart button linking to the *Sales Order*.
* No cross-link between unrelated PO and MO should be displayed.
**Cause:**
* The SO pushes the `stock.reference` into procurement values: https://github.com/odoo/odoo/blob/8a871a120b75f7c09c70dbf07530239244dbb5d6/addons/sale_stock/models/sale_order_line.py#L289
* The same reference is propagated to:
* Purchase Orders: https://github.com/odoo/odoo/blob/8a871a120b75f7c09c70dbf07530239244dbb5d6/addons/purchase_stock/models/stock_rule.py#L355
* Manufacturing Orders: https://github.com/odoo/odoo/blob/8a871a120b75f7c09c70dbf07530239244dbb5d6/addons/mrp/models/stock_rule.py#L184
* Opening the *Purchase Order* form triggers `_compute_mrp_production_count`.
* This compute calls `_get_mrp_productions()`: https://github.com/odoo/odoo/blob/8a871a120b75f7c09c70dbf07530239244dbb5d6/addons/purchase_mrp/models/purchase.py#L21
* That method returns `self.reference_ids.production_ids`.
* Since the MO shares the same sale reference, the PO incorrectly fetches that MO and shows the *Manufacturing* smart button.
* Similarly, opening the *Manufacturing Order* form triggers `_compute_purchase_order_count`.
* This compute calls `_get_purchase_orders()`, which returns `self.reference_ids.purchase_ids`.
* Since the dropship PO shares the same sale reference, the MO incorrectly fetches that PO and shows the *Purchase* smart button.
**Fix:**
* Stop relying on shared `reference_ids` to compute links.
* Instead, follow the actual stock and procurement chain:
* For *MO → PO*:
* Use raw material moves to find related purchase lines: `self.move_raw_ids.created_purchase_line_ids.order_id | self.move_raw_ids.purchase_line_id.order_id`
* For *PO → MO*:
* Use stock move destinations to identify consuming productions.
* This ensures:
* MOs link only to POs supplying their raw materials.
* POs link only to MOs they actually replenish.
* Unrelated documents sharing the same sale reference remain isolated.
---
opw-6008943
---
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#254292