Daily updates from Odoo
Tuesday, September 2, 2025
9 changes · 18.0
Resolved issues and error corrections
Refunds for standard-cost purchased products now correctly reverse the original cost accounting entries. This prevents credit notes from overstating balances and keeps inventory and purchase accounting aligned after returns.
Original PR description
When users refund a real-time/standard cost product purchase, cogs lines are not reversed
**Steps to reproduce**
1. Create a product category [CATEG]:
- Costing Method: Standard
- Inventory Valuation: Automated
- Price Difference Account: 101403 Outstanding Payments (any account will do)
2. Create a product [PROD]
- Type: Storable
- Category: [CATEG]
3. Create and confirm a PO with [PROD]
4. Process the receipt
5. Create the bill
6. Issue the return and process it
7. Create the refund
**Issue**
The credit note cogs lines (price difference account and stock interim) have the same balance of the bill
However the credit note should mirror the original BILL with the opposite accounting entries.
This seems to occur because, when generating cogs lines, we take into account that the current move is a refund but then we use the move direction sign to alter the balance sign
opw-4845342
Forward-Port-Of: odoo/odoo#221198Italian electronic invoice exports now omit payment information where it should not appear and place supplier invoice references in the correct section. This helps companies using Italy localization produce XML files that better match official tax authority requirements and reduces rejection or compliance risk.
Original PR description
1- `<DatiPagamento>` shouldn't be included in autofatture. 2- The supplier's original invoice number and date must be placed in the `<DatiFattureCollegate>`, using `<IdDocumento>` and `<DataDocumento>` fields respectively. Currently `<IdDocumento>` is added to the `<DatiOrdineAcquisto>`. A fix is made to add `<IdDocumento>` and `<DataDocumento>` to `<DatiFattureCollegate>`. references: https://www.agenziaentrate.gov.it/portale/documents/d/guest/guida_compilazione-fe-esterometro-v1-10_aprile_2025 opw-4810326
Incoming invoice emails sent to a company journal alias are no longer rejected just because the sender's user account cannot access that company. This helps ensure supplier invoices and similar documents are created reliably from email, matching the behavior for unknown senders.
Original PR description
To reproduce the bug: 1- Create a DB with two companies and accounting app 2- Create a user and allow it to access company 2 3- Send a email using the user email to alias from purchase journal alias of company 2 4- The email will be rejected 5- Send a email using a random email address to alias. 6- The email will be accepted and an account.move is created. In a normal flow, when a user associated to the email not exists, the user_id is set to odoobot, otherwise, the user accosiated to the email. In the buggy flow the bug happens because `_compute_company_id` in account_move model, will set `company_id` to empty when user has no access to the company, as a result the `account_move` will fail. opw-4853027 Forward-Port-Of: odoo/odoo#217322
Point of Sale orders that skip the receipt screen are now still sent to the preparation display. This prevents kitchen or preparation teams from missing invoiced orders when automatic receipt printing is enabled.
Original PR description
Steps to reproduce: ------------------- - Enable "Automatic Receipt Printing" - Make a PoS order, with "Invoiced" checked, and validate it -> Observe that the command is not sent to the preparation display. Reason: ------- When skipping the receipt screen, we don't call `checkPreparationStateAndSentOrderInPreparation`, which then doesn't send the new command to the preparation display. The fix: -------- Backporting 26425ab712a3269beec98722 but without any refactoring. opw-5000406
Analytic plans are now processed from parent to child during project app installation. This prevents setup failures when a plan depends on a parent plan that has not yet been prepared, improving reliability for companies using hierarchical analytic plans.
Original PR description
When installing the `project` module, `_sync_plan_column(self, model)` is called for all existing analytic plans. The method iterates through `self` in arbitrary order, which means a child plan can…
When installing the `project` module, `_sync_plan_column(self, model)` is called for all existing analytic plans. The method iterates through `self` in arbitrary order, which means a child plan can be processed before its parent. In such a case, the code tries to create a related field pointing to a parent-level column that does not yet exist, leading to errors like: `Field name "x_plan26_id" unknown for related field "x_plan26_id.plan_id"` This happened because `self` was iterated without guaranteeing that parents are processed first. As a result, the related field chain (`.plan_id.parent_id...`) could reference missing intermediate fields. The fix is ordering the recordset by `parent_path`. Steps to reproduce: 1. In Odoo Inspector, search for model `account.analytic.plan`. and go to records. 2. Create a first plan. 3. Create a second plan and set the first plan as its parent. 4. Install the `project` app (triggers `_sync_plan_column`). 5. Observe the crash due to an unknown related field. OPW-5006494 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue where barcode transfers could incorrectly merge lot-tracked kit component lines with the same component added separately. This prevents unnecessary backorders when warehouse staff scan and validate the correct quantities.
Original PR description
**Problem:** when the components of a kit are tracked by lot, and that a picking is made of the components of a kit (exploded from the kit) and separatly one of the components on its own: if we open…
**Problem:** when the components of a kit are tracked by lot, and that a picking is made of the components of a kit (exploded from the kit) and separatly one of the components on its own: if we open the picking in barcode, the line of the component separated and line of the components of the kit are grouped, which leads to an unwanted backorder creation when validating **Steps to reproduce:** - create two products tracked by lot (comp A and comp B) - set an on hand quantity for both - create a storable product (final product) and create a BOM - in the BOM add comp A and comp B - create an internal transfer for 1 final product and 1 comp B - click on "mark as todo" - open this transfer in barcode, we see that the two lines from the comp B are grouped - scan the source location, click on +1 and +2 button to fulfill the quantities and validate **Current behavior:** a backorder is created **Expected behavior:** no backorder should be created as we entered the right quantities of the picking **Cause of the issue:** the lines from comp B should not have been grouped in the barcode picking. When doing the same scenario but with product not tracked those lines are not grouped opw-4998766
This fixes an error that blocked users from posting several invoices at once when using Avalara Brazil automatic tax mapping. Businesses can now process batches of these invoices without needing to post each one individually or encountering a system traceback.
Original PR description
Issue:
When posting multiple invoices with Avalara Brazil tax mapping, a traceback is raised:
ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: account.move
Only occurs when fiscal position is set to:
Automatic Tax Mapping (Avalara Brazil)
Affected versions:
- 17.0 and later
Steps to reproduce:
1. Set Avalara connection
2. Create an invoice with fiscal position: Automatic Tax Mapping (Avalara Brazil)
3. Duplicate that invoice
4. Select two or more invoices in draft
5. Try to post those entries
https://drive.google.com/file/d/1_CjX9vGhr-ZyUegP9QhOdQ--bfA8ylsH/view?usp=sharing
Current behavior:
- Error is raised: ValueError: Expected singleton
Expected behavior:
- Invoices should post correctly without errors
Forward-Port-Of: odoo/enterprise#93272The Malaysia Statement of Account report now applies the correct currency conversion when invoices are issued in a foreign currency. This prevents balances from being shown with the company currency symbol but the unconverted foreign amount, improving accuracy for customer reporting and receivables review.
Original PR description
## Short functional explanation of the error When we create an invoice with a different currency than the main one, the Statement of Account PDF report in aged receivable has an error. The amount for…
## Short functional explanation of the error When we create an invoice with a different currency than the main one, the Statement of Account PDF report in aged receivable has an error. The amount for each line is displayed as the main currency, but the conversion isn't done. For instance, if we create an invoice line of 3.5$ but our main currency is the Euro, in the report, it will show 3.5€ instead of 2.99€ ## Reproduction Steps 1. In a db without demo data, Download the app l10n_my. 2. In the general settings, click on Currencies. Activate a second currency and set its currency rate (relative to the main currency of the company) different of 1. 3. In accounting > settings, click on -> Currencies. Activate this second currency. 4. Click on configuration > journals and activate the debug mode. In the Journal Entries tab, as Currency, select a different currency than your main one (set in the general settings). 5. Create an invoice. Set a customer and select the journal for which you set an additional currency. Select this additional currency. Finally, add a product and click confirm. 6. Click on Reporting > Aged Receivable. Then, click on the line corresponding to your partner on Statement of Account. A PDF should download. ### Expected behavior The lines under Balance should be displayed as the main currency of the company, with the correct currency rates applying. ### Unexpected behavior The lines under Balance are displayed as the main currency of the company but the currency rates are not applying. ## Origin of the issue In the code, the currency rate isn't used to generate this line of the report: https://github.com/odoo/enterprise/blob/79c1ba68d48e7e068104d867e186610dd5110cc4/l10n_my_reports/report/statement_account_templates.xml#L52 __ opw-4975540 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The website generation flow now reliably stops its background status checks when users leave or the screen is closed early. This prevents unnecessary server calls and avoids crashes that could interrupt the website creation experience.
Original PR description
In a component lifecycle, it may happen that onWillStart is called but not onWillUnmount. Indeed, if the component is destroyed before being mounted (because the current rendering has been cancelled), onWillUnmount isn't called. As a consequence, in the WebsiteGenerator component, the setInverval might never been called, thus producing an orm call every 10 seconds, when the component is destroyed. These calls lead to crashes ("Component is destroyed").
The solution is to use the onWillDestroy hook instead, which is always called.