Odoo Changelog — 2026-07-21

Tuesday, July 21, 2026

10 changes · saas-19.2

Bug Fixes(10)

Resolved issues and error corrections

[FIX] l10n_pe_edi: detraction amount in XML when company currency is not PEN

Enterprisesaas-19.2l10n_pe_ediMedium

Peruvian electronic invoices now calculate detraction withholding amounts in Peruvian soles even when the company currency is set to USD. This prevents incorrect values being sent to SUNAT and ensures invoice PDFs show the correct PEN currency symbol.

Original PR description

**Steps to reproduce:**
* Install the **l10n_pe_edi** module.
* Change the company currency to **USD**.
* Configure **Peruvian detraction** settings:
  * Set a **withholding percentage** on a product.
  * Set a **withholding code** on the same product.
* Create a customer invoice in **USD**.
* Set the **Operation Type** to **[1001] Operation Subject to Detraction**.
* Add the configured product to the invoice.
* Confirm the invoice, **send it to SUNAT** by *process now**, and generate the ZIP which has XML.

**Observed behavior:**
* The generated XML contains: `<cbc:Amount currencyID="PEN">116.82</cbc:Amount>` The `currencyID` is `PEN` but the amount is the raw USD value instead of being converted to PEN using the exchange rate.
* The PDF report also shows the withholding amount with the wrong currency symbol.

**Cause:**
* `_l10n_pe_edi_get_spot()` computed `spot['amount']` as `amount_total_signed * percent`, where `amount_total_signed` is stored in the **company currency**. When the company currency is PEN this works correctly, but when it is changed to USD the value is in USD while the XML node hardcodes `currencyID="PEN"`.
* `spot['currency']` was also set to `company_id.currency_id`, so the PDF rendered the amount with the wrong currency symbol.
* In `_add_invoice_payment_terms_nodes`, `spot_amount` was selected via `spot['amount'] if invoice.currency_id == invoice.company_id.currency_id` which relied on company currency being PEN as a proxy for the invoice being in PEN, breaking when company currency is USD.

**Fix:**
* In `_l10n_pe_edi_get_spot()`, compute `spot['amount']` by explicitly converting `amount_total` from the invoice currency to PEN using `currency_id._convert(..., env.ref('base.PEN'), ...)`, ensuring the detraction amount is always in PEN regardless of the company currency.
* Set `spot['currency']` to `env.ref('base.PEN')` so the PDF report always displays the withholding amount with the correct PEN symbol.
* In `_add_invoice_payment_terms_nodes`, always use `spot['spot_amount']` (invoice currency amount) for the `FormaPago`/`Cuota` arithmetic, since `spot['amount']` is now exclusively the PEN amount for the detraction XML node.

opw-6327571

Forward-Port-Of: odoo/enterprise#123782

#Peru#electronic invoicing#detractions#currency#SUNAT

[FIX] delivery_envia: include item weight to fix Amazon validation error

PR #125017

Enterprisesaas-19.2delivery_enviaMedium

Envia shipping labels for Amazon Ground now include each product's weight in the shipment details. This prevents valid high-quantity orders from being blocked by Amazon's weight validation error.

Original PR description

**Issue:**

Envia API documentation is very bad. When trying to generate an Amazon Ground shipping with Envia, the API will sometimes reject the payload with the following error:

`Total items weight exceeds package weight. Please refer to API documentation for allowable limits. (D-703)`

Even though the [Envia documentation](https://docs.envia.com/reference/create-shipping-label) doesn't include it, it seems that Amazon requires the weight for each product. If the payload doesn't include the per-item weight, Amazon will set a default weight, which will cause the error to show up if the delivery contains a high quantity. This can be a blocking issue for some customers.

**Steps to reproduce on a fresh DB:**

- Install Inventory, Sales, and Envia Shipping
- Switch company to be based in India (need to provide an address to deliver from, I just used the Odoo India address - InfoCity Gate, Gandhinagar, Gujarat 382007)
- Configure an Amazon delivery carrier with Envia (India seems to be the only country that supports Amazon with Envia)
	- Inventory > Configuration > Delivery Methods > Envia.com method
	- Must be in a Production environment (because Envia's sandbox server does not work for some reason?)
	- Add an Envia Production Access Token (will have to use one with some funds)
	- Change 'Ship From' to India
	- Configure the `Envia.com Service Name`, set Carrier and Service to AMAZON and AMAZON - Amazon Shipping Standard
- Create a demo product, give it an arbitrary weight like 0.1 kg
- Create a sales order to an Indian customer, include the demo product with a high quantity (like 20), confirm (might have to create a warehouse and configure the customer's information)
- On the generated picking, set the Carrier to Envia.com on the Additional Info tab
- When trying to Validate, it should throw the error

**Fix:**
When generating the payload in _get_shipping_lines() in envia_request, include the item weight in the dictionary.

Related ticket: opw-6261682

Forward-Port-Of: odoo/enterprise#123935

[FIX] l10n_ar_edi: validate final consumer document type

PR #124983

Enterprisesaas-19.2l10n_ar_ediMedium

Argentine electronic invoices now show a clear warning when a final consumer customer uses an unsupported identification type, such as a passport. This prevents a system error during invoice confirmation and helps users correct customer data before submitting invoices.

Original PR description

After applying the community fix, a new issue appears in enterprise.

**Steps to reproduce:**
- Install the `l10n_ar_edi` module.
- Go to Customers and create a new customer with:
  - Country: Argentina
  - Identification Type: `Passport`
  - Identification Number: `1234567890a`
  - AFIP Responsibility Type: `Consumidor Final`
- Create a new invoice for this customer with:
  - Journal: `Electronic Invoice (FE)`
  - Document Type: `(6) INVOICES B`
- Try to confirm the invoice.

**Error:**
ValueError: invalid literal for int() with base 10: '1234567890a'

**Expected behaviour:**
For Argentinean contacts with AFIP Responsibility Type `Consumidor Final`, 
the identification type must be `DNI` or `CUIL/CUIT`. If another 
identification type is used, the user should receive a proper warning 
instead of a traceback. (see [1])

**Root Cause:**
After the community fix, `_get_id_number_sanitize()` can return an alphanumeric 
value, which is later converted with `int()` at [2] and [3], causing an error.

**Fix:**
This commit adds an explicit validation for Argentinean contacts with 
AFIP Responsibility Type Consumidor Final before converting the 
identification number to an integer, ensuring the user receives the 
proper warning message.

[1]:
https://www.odoo.com/mail/message/1118392033

[2]:
https://github.com/odoo/enterprise/blob/064812dd9f1074f287fee677ba35ea4aeef3ab3f/l10n_ar_edi/models/account_move.py#L780-L798

[3]:
https://github.com/odoo/enterprise/blob/064812dd9f1074f287fee677ba35ea4aeef3ab3f/l10n_ar_edi/models/account_move.py#L927-L931

Related community PR: https://github.com/odoo/odoo/pull/272651

opw-6333998

Forward-Port-Of: odoo/enterprise#124789
Forward-Port-Of: odoo/enterprise#123729

[FIX] account_edi_ubl_cii: allow deletion of generated PDF attachment

PR #271438

Coresaas-19.2accountaccount_edi_ubl_cii

Original PR description

Before this commit:
When importing a vendor bill XML that does not contain an embedded PDF, Odoo generates an PDF attachment (Generated by Odoo). When we try to delete this generated PDF from the chatter raises a UserError and the attachment cannot be removed.

Technical reason:
When PDF is generated it logs the messages as the notification not as comment. In mail_thread.py they have mentioned that (message type != comment) if we try to update messages which is not comment then error will raise.

After this commit:
Generated PDF attachments created by Odoo can be deleted from the chatter. Attachments received through Peppol or imported (such as XML file and embedded documents) remain protected and cannot be deleted.

Task- 6245667

[FIX] payment_payu: allow disconnecting a connected PayU provider

PR #277016

Coresaas-19.2payment_payu

Original PR description

Steps to reproduce:
- Install the PayU payment provider.
- Click the Connect button and complete the onboarding flow.
- After being redirected back to the PayU provider form, click Disconnect.

Issue:
- After confirming the disconnection, a validation error is raised stating that the PayU fields must be filled in.

Cause:
- During disconnection, the PayU-specific fields are cleared. At that point, `_check_required_if_provider` is triggered, and since those fields have the `required_if_provider` attribute, it raises a `ValidationError` because their values are now `None`.

Fix:
- Remove the `required_if_provider` attribute from the PayU-specific fields.

opw-6391133

Forward-Port-Of: odoo/odoo#276567

[FIX] point_of_sale: close active overlays on screensaver trigger

PR #277055

Coresaas-19.2point_of_sale

Original PR description

Currently, overlays remain open when the POS screensaver is loaded [^1].

#### Steps to reproduce:
- Open the POS interface.
- Open a dropdown/popover menu (e.g., the navbar hamburger menu).
- Wait for the screensaver (SaverScreen) to trigger due to inactivity.
- The open dropdown menu remains visible on top of the screensaver.

#### Issue
Dropdowns and popovers are rendered as active overlays outside the main
screen container. While the screensaver setup closes active dialogs, it
does not handle active overlays.

#### Fix
Retrieve the overlay service in SaverScreen and close all active overlays
during its setup phase using a dedicated `closeAllOverlays` method.

[^1]: ![Screensaver Issue](https://github.com/user-attachments/assets/b47d2cb6-8fc0-40aa-80c1-b35392548327)

Forward-Port-Of: odoo/odoo#276672
Forward-Port-Of: odoo/odoo#274716

[FIX] account: done activity shown in the dashboard

PR #277462

Coresaas-19.2account

Original PR description

Steps to reproduce:
1. Edit/Create an activity type (e.g., "To Do") and enable "Keep Done".
2. Schedule an activity of this type on a journal (or a journal entry/move) with a deadline in the past.
3. Mark the activity as done.
4. Go to the Accounting Dashboard. Notice that the activity is still shown as "overdue" in red on the journal card.

When an activity type has "Keep Done" enabled, completed activities are not deleted from the database. Instead, they are archived by setting `active = False` and `date_done` is populated.

Since the activity dashboard query retrieves records via direct SQL, it bypasses Odoo's automatic active filtering on `mail.activity`. As a result, archived (done) activities were incorrectly fetched and displayed on the journal dashboard cards, appearing as overdue.

This commit resolves the issue by explicitly adding `AND activity.active = TRUE` to the SQL queries.

Task-6142042

Forward-Port-Of: odoo/odoo#276998
Forward-Port-Of: odoo/odoo#274313

[FIX] l10n_ar: sanitize identification numbers correctly

PR #277500

Coresaas-19.2l10n_ar

Original PR description

**Issue 1:** Steps to reproduce: - Install the `l10n_ar` module. - Go to Customers and create a new customer with the country set to Argentina. - Set `Identification Type` to `CUIL` and…

**Issue 1:**

Steps to reproduce:
- Install the `l10n_ar` module.
- Go to Customers and create a new customer with the country set to Argentina.
- Set `Identification Type` to `CUIL` and `Identification Number` to `1234567890a`.

**Error:**
`ValueError: invalid literal for int() with base 10: '1234567890a'`

**Issue 2:**
- Set `Identification Type` to any type other than `CUIT`, `DNI`, or `CUIL`.
- Set `Identification Number` to `1234567890a`.

**Observation:**
All non-digit characters are stripped, and the identification number is
silently changed to `1234567890`.

**Expected behaviour:**
Any Identification Type other than CUIT (80), CUIL (86), and DNI (96)
should be kept unchanged without stripping alphabetic characters.

**Root Cause:**
At [1], `_get_id_number_sanitize` sanitizes identification numbers
based on the selected Identification Type.

- For `CUIT` and `CUIL`, `stdnum.ar.cuit.compact()` only removes
separators (e.g., spaces and dashes). If the identification number
contains alphabetic characters, they are preserved and called `int()`
on the resulting value, raising a `ValueError`.
- For all other identification types, valid alphanumeric values are
unintentionally modified by stripping non-digit characters.

**Fix:**
This commit validates identification numbers before sanitization for
`CUIT` (80), `CUIL` (86), and `DNI` (96), ensuring only valid numeric
identification numbers are converted. For all other identification
types, it preserves alphanumeric characters by removing only
non-alphanumeric separators.

[1]:
https://github.com/odoo/odoo/blob/08b75d753c638e9d2d7418b55e9107bda471cb31/addons/l10n_ar/models/res_partner.py#L124-L136

Related enterrpise PR: https://github.com/odoo/enterprise/pull/123729

opw-6333998

Forward-Port-Of: odoo/odoo#277132
Forward-Port-Of: odoo/odoo#272651

[FIX] mrp_account: respect date with production valuation data

PR #277025

Coresaas-19.2mrp_account

Original PR description

# Problem
Cost of production in the inventory valuation report does not respect 'As of' date, and will show current costs of production regardless of the specified date.

# Solution
`_get_report_data` in `mrp_account` is just missing the date enforcement when calling `_get_location_valuation_vals`, so we will simply pass this in.

# Steps to reproduce (runbot v19)
- FIFO Perpetual component with non-zero value
- Manufactured product that consumes the above component
1. Set a cost of production account on the production location
2. Create and confirm an MO for the manufactured product
3. Go to Accounting > Review > Inventory Valuation, and set the At Date to something far in the past, befroe any move history in the db. Note the Cost of Production accounts have data that does not apply to this period

opw-6229088

Forward-Port-Of: odoo/odoo#269911

[FIX] mail: assign correct company to attachments

PR #277643

Coresaas-19.2mailtest_mail

Original PR description

Issue:
In a multi-company environment, when an attachment is uploaded in the chatter, the resulting `ir.attachment` record incorrectly sets the company_id to the current user's default company. This occurs regardless of the active company or the company associated with the record the attachment is linked to.

Steps to reproduce:
In a multi-company setup, activate only Company B. Open any chatter and attach a file.
Navigate to Settings > Technical > Data Structure > Attachments.

Current behaviour:
The created attachment has its company_id set to the user's default company, rather than the currently active company, or the company of the record, even when the record has a company_id field. This behavior introduces inconsistencies in data visibility, particularly when attachments appear to belong to a company different from the one associated with the related business record.

Behaviour After Fix:
If the related record (i.e., the model the attachment is linked to) contains a company_id field, its value will be used as the attachment's company_id otherwise, the attachment's company_id will be set to the currently active company's id.

This logic ensures proper alignment between attachments and their related business records and also maintaining consistency in multi-company scenarios.

task-4563173


---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#277582
Forward-Port-Of: odoo/odoo#235665

**Steps to reproduce:** * Install the **l10n_pe_edi** module. * Change the company currency to **USD**. * Configure **Peruvian detraction** settings: * Set a **withholding percentage** on a product. * Set a **withholding code** on the same product. * Create a customer invoice in **USD**. * Set the **Operation Type** to **[1001] Operation Subject to Detraction**. * Add the configured product to the invoice. * Confirm the invoice, **send it to SUNAT** by *process now**, and generate the ZIP which has XML. **Observed behavior:** * The generated XML contains: `<cbc:Amount currencyID="PEN">116.82</cbc:Amount>` The `currencyID` is `PEN` but the amount is the raw USD value instead of being converted to PEN using the exchange rate. * The PDF report also shows the withholding amount with the wrong currency symbol. **Cause:** * `_l10n_pe_edi_get_spot()` computed `spot['amount']` as `amount_total_signed * percent`, where `amount_total_signed` is stored in the **company currency**. When the company currency is PEN this works correctly, but when it is changed to USD the value is in USD while the XML node hardcodes `currencyID="PEN"`. * `spot['currency']` was also set to `company_id.currency_id`, so the PDF rendered the amount with the wrong currency symbol. * In `_add_invoice_payment_terms_nodes`, `spot_amount` was selected via `spot['amount'] if invoice.currency_id == invoice.company_id.currency_id` which relied on company currency being PEN as a proxy for the invoice being in PEN, breaking when company currency is USD. **Fix:** * In `_l10n_pe_edi_get_spot()`, compute `spot['amount']` by explicitly converting `amount_total` from the invoice currency to PEN using `currency_id._convert(..., env.ref('base.PEN'), ...)`, ensuring the detraction amount is always in PEN regardless of the company currency. * Set `spot['currency']` to `env.ref('base.PEN')` so the PDF report always displays the withholding amount with the correct PEN symbol. * In `_add_invoice_payment_terms_nodes`, always use `spot['spot_amount']` (invoice currency amount) for the `FormaPago`/`Cuota` arithmetic, since `spot['amount']` is now exclusively the PEN amount for the detraction XML node. opw-6327571 Forward-Port-Of: odoo/enterprise#123782

**Issue:** Envia API documentation is very bad. When trying to generate an Amazon Ground shipping with Envia, the API will sometimes reject the payload with the following error: `Total items weight exceeds package weight. Please refer to API documentation for allowable limits. (D-703)` Even though the [Envia documentation](https://docs.envia.com/reference/create-shipping-label) doesn't include it, it seems that Amazon requires the weight for each product. If the payload doesn't include the per-item weight, Amazon will set a default weight, which will cause the error to show up if the delivery contains a high quantity. This can be a blocking issue for some customers. **Steps to reproduce on a fresh DB:** - Install Inventory, Sales, and Envia Shipping - Switch company to be based in India (need to provide an address to deliver from, I just used the Odoo India address - InfoCity Gate, Gandhinagar, Gujarat 382007) - Configure an Amazon delivery carrier with Envia (India seems to be the only country that supports Amazon with Envia) - Inventory > Configuration > Delivery Methods > Envia.com method - Must be in a Production environment (because Envia's sandbox server does not work for some reason?) - Add an Envia Production Access Token (will have to use one with some funds) - Change 'Ship From' to India - Configure the `Envia.com Service Name`, set Carrier and Service to AMAZON and AMAZON - Amazon Shipping Standard - Create a demo product, give it an arbitrary weight like 0.1 kg - Create a sales order to an Indian customer, include the demo product with a high quantity (like 20), confirm (might have to create a warehouse and configure the customer's information) - On the generated picking, set the Carrier to Envia.com on the Additional Info tab - When trying to Validate, it should throw the error **Fix:** When generating the payload in _get_shipping_lines() in envia_request, include the item weight in the dictionary. Related ticket: opw-6261682 Forward-Port-Of: odoo/enterprise#123935

After applying the community fix, a new issue appears in enterprise. **Steps to reproduce:** - Install the `l10n_ar_edi` module. - Go to Customers and create a new customer with: - Country: Argentina - Identification Type: `Passport` - Identification Number: `1234567890a` - AFIP Responsibility Type: `Consumidor Final` - Create a new invoice for this customer with: - Journal: `Electronic Invoice (FE)` - Document Type: `(6) INVOICES B` - Try to confirm the invoice. **Error:** ValueError: invalid literal for int() with base 10: '1234567890a' **Expected behaviour:** For Argentinean contacts with AFIP Responsibility Type `Consumidor Final`, the identification type must be `DNI` or `CUIL/CUIT`. If another identification type is used, the user should receive a proper warning instead of a traceback. (see [1]) **Root Cause:** After the community fix, `_get_id_number_sanitize()` can return an alphanumeric value, which is later converted with `int()` at [2] and [3], causing an error. **Fix:** This commit adds an explicit validation for Argentinean contacts with AFIP Responsibility Type Consumidor Final before converting the identification number to an integer, ensuring the user receives the proper warning message. [1]: https://www.odoo.com/mail/message/1118392033 [2]: https://github.com/odoo/enterprise/blob/064812dd9f1074f287fee677ba35ea4aeef3ab3f/l10n_ar_edi/models/account_move.py#L780-L798 [3]: https://github.com/odoo/enterprise/blob/064812dd9f1074f287fee677ba35ea4aeef3ab3f/l10n_ar_edi/models/account_move.py#L927-L931 Related community PR: https://github.com/odoo/odoo/pull/272651 opw-6333998 Forward-Port-Of: odoo/enterprise#124789 Forward-Port-Of: odoo/enterprise#123729

Before this commit: When importing a vendor bill XML that does not contain an embedded PDF, Odoo generates an PDF attachment (Generated by Odoo). When we try to delete this generated PDF from the chatter raises a UserError and the attachment cannot be removed. Technical reason: When PDF is generated it logs the messages as the notification not as comment. In mail_thread.py they have mentioned that (message type != comment) if we try to update messages which is not comment then error will raise. After this commit: Generated PDF attachments created by Odoo can be deleted from the chatter. Attachments received through Peppol or imported (such as XML file and embedded documents) remain protected and cannot be deleted. Task- 6245667

Steps to reproduce: - Install the PayU payment provider. - Click the Connect button and complete the onboarding flow. - After being redirected back to the PayU provider form, click Disconnect. Issue: - After confirming the disconnection, a validation error is raised stating that the PayU fields must be filled in. Cause: - During disconnection, the PayU-specific fields are cleared. At that point, `_check_required_if_provider` is triggered, and since those fields have the `required_if_provider` attribute, it raises a `ValidationError` because their values are now `None`. Fix: - Remove the `required_if_provider` attribute from the PayU-specific fields. opw-6391133 Forward-Port-Of: odoo/odoo#276567

Currently, overlays remain open when the POS screensaver is loaded [^1]. #### Steps to reproduce: - Open the POS interface. - Open a dropdown/popover menu (e.g., the navbar hamburger menu). - Wait for the screensaver (SaverScreen) to trigger due to inactivity. - The open dropdown menu remains visible on top of the screensaver. #### Issue Dropdowns and popovers are rendered as active overlays outside the main screen container. While the screensaver setup closes active dialogs, it does not handle active overlays. #### Fix Retrieve the overlay service in SaverScreen and close all active overlays during its setup phase using a dedicated `closeAllOverlays` method. [^1]: ![Screensaver Issue](https://github.com/user-attachments/assets/b47d2cb6-8fc0-40aa-80c1-b35392548327) Forward-Port-Of: odoo/odoo#276672 Forward-Port-Of: odoo/odoo#274716

Steps to reproduce: 1. Edit/Create an activity type (e.g., "To Do") and enable "Keep Done". 2. Schedule an activity of this type on a journal (or a journal entry/move) with a deadline in the past. 3. Mark the activity as done. 4. Go to the Accounting Dashboard. Notice that the activity is still shown as "overdue" in red on the journal card. When an activity type has "Keep Done" enabled, completed activities are not deleted from the database. Instead, they are archived by setting `active = False` and `date_done` is populated. Since the activity dashboard query retrieves records via direct SQL, it bypasses Odoo's automatic active filtering on `mail.activity`. As a result, archived (done) activities were incorrectly fetched and displayed on the journal dashboard cards, appearing as overdue. This commit resolves the issue by explicitly adding `AND activity.active = TRUE` to the SQL queries. Task-6142042 Forward-Port-Of: odoo/odoo#276998 Forward-Port-Of: odoo/odoo#274313

**Issue 1:** Steps to reproduce: - Install the `l10n_ar` module. - Go to Customers and create a new customer with the country set to Argentina. - Set `Identification Type` to `CUIL` and `Identification Number` to `1234567890a`. **Error:** `ValueError: invalid literal for int() with base 10: '1234567890a'` **Issue 2:** - Set `Identification Type` to any type other than `CUIT`, `DNI`, or `CUIL`. - Set `Identification Number` to `1234567890a`. **Observation:** All non-digit characters are stripped, and the identification number is silently changed to `1234567890`. **Expected behaviour:** Any Identification Type other than CUIT (80), CUIL (86), and DNI (96) should be kept unchanged without stripping alphabetic characters. **Root Cause:** At [1], `_get_id_number_sanitize` sanitizes identification numbers based on the selected Identification Type. - For `CUIT` and `CUIL`, `stdnum.ar.cuit.compact()` only removes separators (e.g., spaces and dashes). If the identification number contains alphabetic characters, they are preserved and called `int()` on the resulting value, raising a `ValueError`. - For all other identification types, valid alphanumeric values are unintentionally modified by stripping non-digit characters. **Fix:** This commit validates identification numbers before sanitization for `CUIT` (80), `CUIL` (86), and `DNI` (96), ensuring only valid numeric identification numbers are converted. For all other identification types, it preserves alphanumeric characters by removing only non-alphanumeric separators. [1]: https://github.com/odoo/odoo/blob/08b75d753c638e9d2d7418b55e9107bda471cb31/addons/l10n_ar/models/res_partner.py#L124-L136 Related enterrpise PR: https://github.com/odoo/enterprise/pull/123729 opw-6333998 Forward-Port-Of: odoo/odoo#277132 Forward-Port-Of: odoo/odoo#272651

# Problem Cost of production in the inventory valuation report does not respect 'As of' date, and will show current costs of production regardless of the specified date. # Solution `_get_report_data` in `mrp_account` is just missing the date enforcement when calling `_get_location_valuation_vals`, so we will simply pass this in. # Steps to reproduce (runbot v19) - FIFO Perpetual component with non-zero value - Manufactured product that consumes the above component 1. Set a cost of production account on the production location 2. Create and confirm an MO for the manufactured product 3. Go to Accounting > Review > Inventory Valuation, and set the At Date to something far in the past, befroe any move history in the db. Note the Cost of Production accounts have data that does not apply to this period opw-6229088 Forward-Port-Of: odoo/odoo#269911

Issue: In a multi-company environment, when an attachment is uploaded in the chatter, the resulting `ir.attachment` record incorrectly sets the company_id to the current user's default company. This occurs regardless of the active company or the company associated with the record the attachment is linked to. Steps to reproduce: In a multi-company setup, activate only Company B. Open any chatter and attach a file. Navigate to Settings > Technical > Data Structure > Attachments. Current behaviour: The created attachment has its company_id set to the user's default company, rather than the currently active company, or the company of the record, even when the record has a company_id field. This behavior introduces inconsistencies in data visibility, particularly when attachments appear to belong to a company different from the one associated with the related business record. Behaviour After Fix: If the related record (i.e., the model the attachment is linked to) contains a company_id field, its value will be used as the attachment's company_id otherwise, the attachment's company_id will be set to the currently active company's id. This logic ensures proper alignment between attachments and their related business records and also maintaining consistency in multi-company scenarios. task-4563173 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#277582 Forward-Port-Of: odoo/odoo#235665