Wednesday, July 23, 2025
7 changes · saas-18.3
Resolved issues and error corrections
Batch payments now handle exchange rate differences correctly, preventing bank statement entries from ending up with incorrect suspense amounts. The update also adds a safeguard so batch payments only group payments with compatible payment methods, reducing accounting inconsistencies.
Original PR description
This commit will add the possibility to have exchange diff on batch payment. That was a problem that cause the move of the bank statement line to have a suspense with an amount currency at zero. task-4921741
Oman companies can now access the tax return closing flow from the Tax Report. This adds the missing enterprise localization data needed to show the Returns button, helping users complete Oman tax reporting in Odoo.
Original PR description
#### Issue: This commit adds a missing account.return.type data in the Oman localization. This is related to the new Accounting Returns #81569 The l10n_om module did not include an…
#### Issue: This commit adds a missing account.return.type data in the Oman localization. This is related to the new Accounting Returns #81569 The l10n_om module did not include an account.return.type record, which prevents the "Returns" button (linked to the action_open_returns) from appearing in the Tax Report. As a result, users in Oman are unable to access the Tax Closing form. Also the l10n_om is a community module, because of that, we need to add a new enterprise module to add the related data for the tax returns. The visibility of the button is controlled by the following condition: [Code](https://github.com/odoo/enterprise/blob/f924f120cbd04002e21c78b081e1c8006b56a4b6/account_reports/models/account_report.py#L1776) #### Affected Versions: 18.3 and later #### Steps to reproduce: 1.Install the l10n_om module 2.Switch to the Oman company 3.Go to Accounting > Reporting > Tax Report 4.The "Returns" button is not visible #### Expected behavior The "Returns" button should be visible, allowing the user to generate the closing tax form. #### Current behavior The button is hidden due to missing account.return.type data in the Oman localization. OPW-4943024
Membership benefits are now assigned more consistently when companies and their child contacts are involved. When a parent partner buys or loses a membership, the relevant level, commission plan, and pricing effects are correctly applied or removed for its children, while a child’s own purchase no longer incorrectly affects the parent.
Original PR description
Corrects the behaviour of the member level assignment in membership when childs partners are concerned. A partner buying a membership should forward the membership level and Pricelist to its children. A child buying a membership should get that membership without forwarding it to its parent. When removed, children should not keep the membership if the parent lose it. TASK-4801759
When optional products are added to a subscription order, manually entered discounts are now preserved instead of being replaced by automatic pricing rules. This prevents unexpected price changes and helps sales teams keep agreed discounts intact.
Original PR description
**Current Behavior:** Manual discounts are not retained when adding optional products to the order. **Steps to Reproduce:** 1) Install the sale_subscription module. 2) Create a subscription with a…
**Current Behavior:** Manual discounts are not retained when adding optional products to the order. **Steps to Reproduce:** 1) Install the sale_subscription module. 2) Create a subscription with a recurring plan. 3) Add a product to the Optional Products section. 4) Manually set a discount on the optional product. 5) Click on the Add to Order Lines (cart) button. 6) A new SOL is created. **Issue:** The newly created SOL does not retain the manually set discount. **Cause:** - When the user clicks the Add to Order Lines button, the `add_option_to_order` method is triggered. This method creates a new sale order line (SOL) using values from `_get_values_to_add_to_order`. - In the current implementation, this method is overridden for subscription orders to exclude the discount value from the returned data. https://github.com/odoo/enterprise/blob/42d829ea6e6a98f251cfffc8fb67b5320a5ada12/sale_subscription/models/sale_order_option.py#L17-L21 - This forces a recomputation of the discount based on pricelist rules, which unintentionally removes any manually set discount. **Solution:** - Only remove the discount value from the returned data and trigger recomputation if there is no manual discount. - This ensures that any user-defined discount is preserved when creating the order line. opw-4840735 Forward-Port-Of: odoo/enterprise#90423 Forward-Port-Of: odoo/enterprise#89381
When creating credit notes for Peruvian vendor bills, users will now see the appropriate purchase journals instead of sales journals. This prevents selection errors and supports smoother supplier credit note processing in accounting.
Original PR description
**Issue** When creating a credit note for a vendor bill, the journal selection dropdown incorrectly shows only sales-type journals instead of purchase-type journals. **Steps to Reproduce** 1. Install the modules: Accounting, l10n_pe, and l10n_pe_edi. 2. Navigate to Accounting > Vendors > Vendor Bills. 3. Open a posted vendor bill and click Credit Note. 4. Open the journal dropdown. 5. Notice that only sales journals are shown. **Root Cause** The journal field's domain was hardcoded to type = 'sale' in the inherited view. This forces the dropdown to show only sales journals, even when reversing a vendor bill. **Fix** Removed the hardcoded domain from the XML view. This allows Odoo to apply its standard logic for journal filtering, which correctly selects purchase journals when reversing vendor bills. Opw-4913997 Forward-Port-Of: odoo/enterprise#90445
This update fixes errors that could block users when adding or setting up a bank account through online bank synchronization. It restores the expected connection flow so users can connect banks without encountering technical error messages.
Original PR description
After [this PR](https://github.com/odoo/enterprise/pull/81894) was merged, we are encountering below errors. **Issue 1:** An error occurs when attempting to connect a new bank account. **Step to…
After [this PR](https://github.com/odoo/enterprise/pull/81894) was merged, we are encountering below errors. **Issue 1:** An error occurs when attempting to connect a new bank account. **Step to produce:** - Install the `account_online_synchronization` module and open `invoicing`. - Go to: `Configuration > Banks > Add a Bank Account`. - `Add new bank > Enter Details > Connect`. **Error:** `TypeError: AccountOnlineLink.create_new_bank_account_action() takes 2 positional arguments but 3 were given` **Root cause:** It appears that removal of `@api.model` was missed in [this PR](https://github.com/odoo/enterprise/pull/89932) during the forward-port process, leading to this error. **Fix:** This commit removes `@api.model` so that the method behaves like a recordset method, as done in [this PR](https://github.com/odoo/enterprise/pull/81894). **Issue 2:** An error occurs when attempting to Setup Bank. At [1], when an exception occurs, the method returns an empty list, and this displays the `Setup Bank` button. Upon clicking the button, an error occurs. [1] https://github.com/odoo/enterprise/blob/443d7d303ecb3bfcba6ac865cf0185b5070b6b9d/account_online_synchronization/models/account_journal.py#L88-L97 **Error:** `ValueError: Expected singleton: account.online.link()` **Root Cause:** At [2], the JS method `fallbackConnectBank` was passing only one positional argument instead of two. However, the corresponding Python method at [3] requires two positional arguments. [2] https://github.com/odoo/enterprise/blob/443d7d303ecb3bfcba6ac865cf0185b5070b6b9d/account_online_synchronization/static/src/components/bank_configure/bank_configure.js#L67-L71 [3] https://github.com/odoo/enterprise/blob/443d7d303ecb3bfcba6ac865cf0185b5070b6b9d/account_online_synchronization/models/account_online.py#L418 This commit updates the JS method `fallbackConnectBank` to pass two positional arguments as required by the python method at [3]. sentry–6745764054,6388425767 Forward-Port-Of: odoo/enterprise#90225
Refusal notifications in Employee Referrals are now sent only after HR confirms the refusal, preventing premature alerts if the wizard is closed. The notification is also linked to the correct referrer user record, avoiding unnecessary mail processing and improving performance.
Original PR description
## [PERF] hr_referral: Send refusal notification to referrer's users Description ----------- Following https://github.com/odoo/enterprise/commit/764f9b6f513c90eb79935d9e8469989ea704b61b,…
## [PERF] hr_referral: Send refusal notification to referrer's users Description ----------- Following https://github.com/odoo/enterprise/commit/764f9b6f513c90eb79935d9e8469989ea704b61b, `_send_notification` will not attach the message on the `hr.applicant` itself, so a `model` was provided. But due to a missing `res_id`, `message_notify` will set both `model` & `res_id` to `False` since both are not specified. This leads to the creation of a `mail.message` with no `res_id` and no `model` (as `self` is an empty `mail.thread` recordset). This leads to a performance regression when mail references need to be computed to attach to the notification in `_notify_by_email_get_base_mail_values`, due to the missing `model` and `res_id` of the message. This commit attaches the notification to the referrer's users instead, providing its `model` and `res_id`. Reference --------- opw-4943488 --- ## [FIX] hr_referral: Do not send notif when opening the refuse wizard Description ----------- Currently, when opening the refusal wizard for an applicant, a call to `archive_applicant` is made. However, there is an override of it in `hr_referral` to send a notification for the applicant's refusal, and closing the `referral_state`, even though the applicant may have not been provided a reason for refusal, and the HR can simply close the wizard instead of confirming it. This commit removes the override of `archive_applicant` and moves its logic into `action_refuse_reason_apply` which is called when the wizard is confirmed. Reference --------- opw-4943488 Forward-Port-Of: odoo/enterprise#90563 Forward-Port-Of: odoo/enterprise#90309