Tuesday, October 14, 2025
10 changes · master
Resolved issues and error corrections
This fixes an access error in the Subscriptions MRR Breakdown report that could appear after archiving an old company and using a new company's currency setup. The report now only considers active companies, so users can open subscription revenue details without being blocked by archived company data.
Original PR description
Step to reproduce: - Start database without demo data and install Subscriptions - Create a new Company and archive the first Company in the Database - Set a currency rate on a currency (i.e. Euro),…
Step to reproduce: - Start database without demo data and install Subscriptions - Create a new Company and archive the first Company in the Database - Set a currency rate on a currency (i.e. Euro), then set that currency as the Main Currency of the new Company. - Then, set a currency rate on the previous Main Currency i.e USD. - Create a Subscription Sales Order and confirm it. - Open the MRR Breakdown report. - Click into the data of the report. Observation: An error message will occur appear (Access Error) Issue: - when building the query, it also fetches the archived company, due to `active_test` context applied from [fetch()](https://github.com/odoo/odoo/blob/754599a7720ee179fc5304b9613df9c177e4b231/odoo/models.py#L3858), and hence wrong query is build which fetches no data, leading to sort of access error as this [condition](https://github.com/odoo/odoo/blob/754599a7720ee179fc5304b9613df9c177e4b231/odoo/models.py#L3876) matches. Fix: - we explicitly search for active companies opw-5090463 Forward-Port-Of: odoo/enterprise#95989
Invoices eligible for early payment discounts now remain marked as partially paid when only part of the invoice is paid. This prevents unpaid balances from being incorrectly treated as paid or moved to suspense, improving payment status accuracy for accounting teams.
Original PR description
Problem: If partial payment is done for Invoice which is eligible for early payment discount, Invoice is marked as paid and remaining amount is debited in suspense account. Cause: While preparing credit entry for receivable account, only eligibility of Invoice for early payment discount was checked and whole residual amount of Invoice is credited instead of amount which is paid, and this is done for partial payments also(which shouldn't be done). After this commit: If partial payment is done for Invoice which is eligible for early payment discount, Invoice is marked as partially paid and only amount which is paid is credited from receivable account and nothing in suspense account. task-5128802 Forward-Port-Of: odoo/enterprise#95994
Fixes an error that prevented users from validating payments in Point of Sale when using Kenya OSCU electronic invoicing. This ensures sales can be completed normally for Kenyan companies using the POS flow.
Original PR description
**Steps to reproduce:** 1. Install `l10n_ke_edi_oscu_pos`. 2. Set company to a Kenya (KE) company. 3. Open POS → Clothes shop → add a product → go to Payment → try to Validate → traceback occurs.…
**Steps to reproduce:**
1. Install `l10n_ke_edi_oscu_pos`.
2. Set company to a Kenya (KE) company.
3. Open POS → Clothes shop → add a product → go to Payment
→ try to Validate → traceback occurs.
**Issue:**
- A traceback is raised when validating a payment in the POS screen.
`undefined
TypeError: Cannot read properties of undefined (reading 'services')
at OrderPaymentValidation.beforePostPushOrderResolve`
**Cause:**
- ` this.env` and `this.orm` is not directly accessible in `OrderPaymentValidation`.
https://github.com/odoo/enterprise/blob/8ca771eb28a1fac13037c0d45e8d716d3dfc6ed2/l10n_ke_edi_oscu_pos/static/src/app/utils/order_payment_validation.js#L7-L24
**Solution:**
- Use `this.pos.env` instead of `this.env`, and `this.pos.data.call` instead of
`this.orm.call` to correctly access the environment and execute data calls
during payment validation.
> Reference:
https://github.com/odoo/enterprise/blob/5a794a6e69ba884862b4a3f399143d1392caa6f0/pos_barcodelookup/static/src/overrides/components/product_screen/product_screen.js#L8-L10
[Related Community PR](https://github.com/odoo/odoo/pull/230069)
**opw - 5137557**
Forward-Port-Of: odoo/enterprise#96284UrbanPiper POS orders now apply the correct taxes when the POS is configured under a company branch. This prevents missing tax amounts on order lines and improves accuracy for businesses operating with parent and child company structures.
Original PR description
Steps to reproduce: --- - Install `pos_urban_piper`. - Create a branch under *Main Company*. - Switch to the new branch. - Create a POS config in this branch and set up UrbanPiper. - Sync "Apple Pie". - Place an order with "Apple Pie". Issue: --- - The 15% tax defined on Apple Pie is not applied on the orderline. Cause: --- - While creating the order line, the tax company was compared directly with the POS config’s company. In this case, the tax belongs to the parent company, while the POS config belongs to a child company. Fix: --- - Compare the `root_id` of both companies instead of the direct company ID to ensure taxes are applied correctly in multi-branch setups. - Additionally, handled the case where a main tax has sub-taxes (e.g., 5% GST split into 2.5% SGST and 2.5% CGST). In such cases, we now fetch the tax type from the sub-taxes instead of the main tax. Task-5050682 Forward-Port-Of: odoo/enterprise#96672 Forward-Port-Of: odoo/enterprise#93467
The invoice payment button now points to the actual confirmed payment linked to the invoice, even when an earlier payment was reset to draft and duplicated. This helps accounting users avoid confusion and prevents them from being sent to an outdated payment record.
Original PR description
[FIX] account: set correct links between invoices and payments The problematic found case was the following: - Create an invoice and register a payment for it, using the wizard, with a journal having…
[FIX] account: set correct links between invoices and payments The problematic found case was the following: - Create an invoice and register a payment for it, using the wizard, with a journal having an outstanding account set - Use the smart button on the invoice form view to open the payment and reset it back to draft - Duplicate the payment, confirm the new one and reconcile it with the invoice => If we go back to the invoice form, the smart button linking payments is now redirecting to the 1st payment, that's in draft state, instead of the second confirmed one. This is because there can be 2 types of links between payments and invoices: - When there's no journal entry for payment, the link is done via the Many2many table 'account_move__account_payment'. - When there's a journal entry, the link is done via the table 'account.partial.reconcile'. Before this commit, the button on the invoice form view was based on account_move__account_payment and wasn't looking at all at account.partial.reconcile as one would expect. To solve that, we now look at reconciled_payment_ids that is computed as the union of account_move__account_payment and account.partial.reconcile. Task-4613193 Runbot: https://runbot.odoo.com/runbot/bundle/18-0-outstanding-double-link-roto-354130 Forward-Port-Of: odoo/enterprise#97003 Forward-Port-Of: odoo/enterprise#89089
Belgian payroll users can now generate Group S reports without encountering an error. The fix corrects the report date handling and adds test coverage for the full process from work entry creation to file export.
Original PR description
Generating a Group S report caused a traceback. Fixed by replacing 'date_start' with 'date' in the 'l10n.be.hr.payroll.export.group.s' model. Added a test to validate the change is working with the whole flow from creating a work entry till exporting the file. task-5005925 Forward-Port-Of: odoo/enterprise#95482
This update corrects the Belgian payroll deduction rule known as deduction 3000 so it remains accurate through July 2025. It helps ensure payroll calculations follow the latest expected values, reducing the risk of incorrect employee pay or compliance issues.
Original PR description
Forward-Port-Of: odoo/enterprise#96951
This fixes an issue where documents selected for a draft chatter note were immediately linked to the underlying record before the note was posted. Attachments now stay with the draft composer until posting, preventing unintended files from appearing on leads, expenses, or other records after a page reload.
Original PR description
When adding attachment from documents in the composer, link the attachment to the composer and not to the thread as it must be linked to the thread only once the message is posted. How to reproduce: - Install the app documents and crm - Open a lead - In the chatter click on "Log a note" - Then click on "Add from Documents" - Select a document and click on "Add from Documents" - Reload the page without posting the message The attachment selected in document is now linked to the lead which shouldn't be the case. Note that if you do the same for an expense, as the attachment is linked to the expense right away when added, the preview panel open immediately, and you have to reopen "Log a note". That was the original bug detected. Task-5075835 Forward-Port-Of: odoo/enterprise#94594
CRM and subscription spreadsheet dashboards now calculate key totals correctly by using the right aggregation method. The CRM pipeline dashboard also focuses on the last 12 months and avoids applying irrelevant default filters when users open the underlying records.
Original PR description
See commit messages Forward-Port-Of: odoo/enterprise#96810
Fixed an issue where Belgian EC Sales List XML exports could omit the month or quarter when opened from the VAT Return page. This ensures exported tax files contain the complete reporting period expected for compliance and submission.
Original PR description
**Issue** When accessing the EC Sales List report via the smart button from the VAT Return page, downloading the XML without explicitly selecting a period omits the <Month> element—even though a…
**Issue** When accessing the EC Sales List report via the smart button from the VAT Return page, downloading the XML without explicitly selecting a period omits the <Month> element—even though a month is visibly preselected. **Steps to Reproduce** 1. Install the Accounting module and Belgium localization. 2. Go to the Accounting dashboard. 3. Open the VAT Return via the "Miscellaneous Operations" section. 4. Click the smart button to access the EC Sales List report. 5. Use the gear icon to export the XML. 6. Observe that the XML <Period> section only includes the <Year>—the <Month> is missing. **Root Cause** If no period is explicitly selected, the report uses a period_type of "tax_period". However, this value was not handled when generating the XML, so the logic to include the \<Month> or \<Quarter> elements skipped it. As a result, only the \<Year>, which is always included, was rendered. **Fix** Extend the handling of tax_period to derive the period from the company’s tax periodicity settings and adjust the filter accordingly. This ensures that the generated XML always includes the \<Month> or \<Quarter> element, in addition to \<Year>, whenever the report is based on a tax period. Opw-4702613 Forward-Port-Of: odoo/enterprise#93647 Forward-Port-Of: odoo/enterprise#89290