Daily updates from Odoo
Wednesday, January 14, 2026
28 changes · 19.0
New functionality added to Odoo
This update adds support for payment channels in Thailand (TH), Malaysia (MY), and Vietnam (VN) through Xendit. This expansion allows Odoo users to accept payments from customers in these key Southeast Asian markets, improving our payment processing capabilities and customer reach.
Original PR description
Xendit has expanded to TH, MY and VN supporting the local payment channels. This commit is to add the supported pamyent channels according to what they have added. task-4334511 Forward-Port-Of: odoo/odoo#189527
Enhancements to existing features
This update improves how combo products are displayed during order preparation. Previously, the POS system split combo items into separate orderlines due to price differences. Now, the preparation display will combine these orderlines for the same product, streamlining the process and making it easier to manage orders.
Original PR description
When ordering a combo product, the POS will split the included products from the extra products in different orderlines. This is done because of the extra products have a different price/unit than the extra items. But for the preparation display we don't care about different prices, so this PR will make the different orderlines of the same combo be merged in the preparation display if they target the same product. Task-[5473387](https://www.odoo.com/odoo/project/1737/tasks/5473387) Enterprise PR-[#104188](https://github.com/odoo/enterprise/pull/104188) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This update resolves an issue where automated time tracking activities were delayed when exceeding allocated time limits. The fix ensures that dependent fields are correctly recomputed after pre-filter conditions are applied, preventing inconsistencies and delays in activity creation. This improves the reliability of time tracking workflows.
Original PR description
This PR is a cherry-pick of: https://github.com/odoo/odoo/pull/236323 When a pre-filter condition of an automation flushes fields, we must ensure that their recomputation is still scheduled…
This PR is a cherry-pick of: https://github.com/odoo/odoo/pull/236323
When a pre-filter condition of an automation flushes fields, we must ensure that their recomputation is still scheduled afterwards For example, if a rule pre-filters on field B (which depends on A), computing A should not clear the compute flag of B
### Issue:
In some automation rules, computed fields must be processed in a specific order (e.g., `effective_hours` -> `remaining_hours`)
However, if `remaining_hours` is referenced in the automation `Before Update Domain`, its compute flag may be incorrectly cleared, preventing the proper recomputation chain
This results in inconsistent behavior, such as delays in activities being created when timesheets exceed allocated time
### Cause:
The automation engine flushes fields referenced in the `Before Update Domain`, but does not restore their compute flags afterward Thus dependent fields are not recomputed as expected
### Steps to reproduce:
1. Enable Debug Mode
2. Create an Automation Rule
-- Name: Time Exceeded
-- Model: Task
-- Trigger: On Save
-- Before Update Domain: [("remaining_hours", ">=", 0)]
-- Apply on: [("remaining_hours", "<", 0)]
4. Create a Project with Timesheets
5. Create a Task inside the Project
6. Set Allocated Time to 10h
7. Use the Start button to record 11h (No activity appears in chatter)
8. Do the same again (Activity appears only after the second exceed) Before the fix, there is always a delay because the recomputation chain is broken
### Tickets:
18.0: opw-4409744
17.0: opw-5237430
Forward-Port-Of: odoo/odoo#243059
Forward-Port-Of: odoo/odoo#239667This update resolves an issue where saving company settings with duplicate VAT and Codice Fiscale (parent and branch) caused errors during proxy user setup. The fix ensures the correct company is identified during user searches, preventing conflicts and improving the stability of the Electronic Invoicing process. This ensures accurate EDI processing for multiple company setups.
Original PR description
Fix issue when saving a branch company sharing the same VAT and Codice Fiscale as its parent. The proxy user search fails because `account_edi_proxy_client.user` is looked up in the branch company instead of the parent one. The same applies when searching the demo user to remove. Steps to reproduce: - Install `account` and `l10n_it_edi` - Set up the company's VAT and Codice Fiscale - Create a branch company with the same VAT and Codice Fiscale - Enable the Electronic Invoicing processing through the SDI in the settings - Select only the branch company and try to save the settings - Observe error since we will try to create a proxy user on the IAP server for an already existing company (the parent one). Ticket [link](https://www.odoo.com/odoo/project.task/5391668) opw-5391668 Forward-Port-Of: odoo/odoo#241443
This update addresses a bug where user edits within the website builder preview were lost. The system now immediately reverts the preview when text is entered or shortcuts are used, preventing conflicting state changes. This ensures a more reliable editing experience for users.
Original PR description
Forward-Port-Of: odoo/odoo#243039
This update fixes a critical issue where payroll sheets were incorrectly computed even when errors existed on payslips. Now, errors are properly flagged with a detailed message, ensuring payroll calculations are accurate and users are immediately alerted to resolve any problems. This prevents incorrect payments and improves payroll reliability.
Original PR description
Bug: When there is an issue on a payslip with an error level, and we try to compute the sheet, the sheet is computed. Instead of computing, it should raise and the message should specify what errors need to be resolved first. Cause: When computing the sheet, we were calling the self._get_error_message() without using the result, which is a string. Fix: Actually raise a ValidationError and use the result of self._get_error_message() for the error message. Introducing the raise brought other problems because some code supposed to fail was running seamlessly fine. But now, the raise is called and those needed to be solved as well. The issue raised multiple times is the "No contract in the payslip period". Task: 5153497
This update corrects a display issue in the Point of Sale (PoS) module where prices were incorrectly shown as excluding tax, even when tax-included settings were selected. The fix adjusts how prices are calculated to align with the PoS settings, ensuring accurate price displays for users. This improves the overall user experience and data consistency.
Original PR description
Steps to reproduce ------------------ 1. Set the PoS taxes display to tax-included 2. In PoS, add a product, change its quantity to 2, and change its price too Notice that the new price / unit is shown as price excluded, even though we set the prices to tax-included in the PoS settings. Reason ------ We were using the getter `currencyDisplayPriceUnit` which uses `displayPriceUnit` which always shows the price as `tax_exluded`. Fix --- Now we change `displayPriceUnit` to adapt to the `iface_tax_included` config in PoS. That follows well the convention used for the non-unit price getter, `displayPrice`. For the cases where we want to explicitly use the tax excluded unit price, we have created the getters `displayPriceUnitExcl` and `currencyDisplayPriceUnitExcl` for that, which replaces some usages of the old getters. opw-5405572
This update corrects a calculation error that occurred when offering part-time contracts. Previously, the system incorrectly attempted to adjust percentages based on full-time salaries. Now, the system accurately reflects the employer's contribution when a part-time offer is created, ensuring accurate payroll calculations.
Original PR description
When you make an offer to a 4/5 time for example, you set the 4/5 gross or employer cost and not the full, so no need to modify the percentage on the offer
This update resolves two issues related to overtime calculations in the payroll module. Specifically, it prevents the creation of overtime work entries when no paid rules are present in a ruleset, and it corrects a bug where regenerating work entries caused shifts in hours across consecutive days. This ensures accurate overtime calculations and payroll processing.
Original PR description
# Bug 1: ## Steps to reproduce: - Create an overtime ruleset and add rules. - Disable "Pay extra hours" on all rules in the ruleset. - Assign this ruleset to an employee. - Create an attendance that…
# Bug 1: ## Steps to reproduce: - Create an overtime ruleset and add rules. - Disable "Pay extra hours" on all rules in the ruleset. - Assign this ruleset to an employee. - Create an attendance that normally generates overtime. - Navigate to the work entries in payroll. - Overtime work entries are created! This fix will skip generating work entries when their will be no `paid` rules in a ruleset. # Bug 2: ## Steps to reproduce: - Create attendances with overtime for multiple consecutive days. - Navigate to Work Entries in Payroll. - Click on Reset->"Regenerate Work Entries” on the same period for bulk regeneration. - Observe that attendance and overtime hours are shifted between days. ### Fix: In `_get_overtime_intervals`, the overtime list was recreated inside the per-day loop, causing previously computed overtime intervals to be lost when multiple days were involved. Overtime intervals are now accumulated per resource across all days in the requested range before building the final Intervals. task - [5189151](https://www.odoo.com/odoo/project/1251/tasks/5189151)
This update ensures that the correct warehouse location is linked to merged manufacturing orders. Previously, the location information wasn't properly carried over, causing issues with multi-location workflows. This fix resolves a potential disruption in order fulfillment, particularly for complex manufacturing processes.
Original PR description
Situation ----- When applying a push rule after manufacturing a merged MO, there is an odd case where the link between the merged MO's transfer and the demand move breaks in…
Situation ----- When applying a push rule after manufacturing a merged MO, there is an odd case where the link between the merged MO's transfer and the demand move breaks in https://github.com/odoo/odoo/blob/182a387d0ec6ad28d7d052d7100b2184372514be/addons/stock/models/stock_move.py#L1054 because of the `m.location_id == move.location_final_id` part being false in https://github.com/odoo/odoo/blob/182a387d0ec6ad28d7d052d7100b2184372514be/addons/stock/models/stock_move.py#L1090-L1097 This is because, during the merge, `location_final_id` is not propagated to the new MO https://github.com/odoo/odoo/blob/5f8336c7d8ab891103a3035a9ebb5242cfa46ce6/addons/mrp/models/mrp_production.py#L2416-L2424 so when the new MO's `move_finished_id` gets computed https://github.com/odoo/odoo/blob/5f8336c7d8ab891103a3035a9ebb5242cfa46ce6/addons/mrp/models/mrp_production.py#L822 it gets the MO's `location_final_id` https://github.com/odoo/odoo/blob/5f8336c7d8ab891103a3035a9ebb5242cfa46ce6/addons/mrp/models/mrp_production.py#L1202 which is false. This leads to to the move getting the warehouse's default stock location thanks to https://github.com/odoo/odoo/blob/182a387d0ec6ad28d7d052d7100b2184372514be/addons/mrp/models/stock_move.py#L456-L457 This is problematic for complex use cases with multi-locations and custom routes. It should be safe to propagate the `location_final_id` of the merged MOs if they all share the same one. Use case example ----- <details> <summary>Full use case</summary> - Enable multi-step routes - Create location "WH/Stock/L1" - Create location "WH/Stock/L2" - Create Operation Type "MO child" - Type of Operation: Manufacturing - Sequence Prefix: MOCHILD - Source Location: L1 - Destination Location: L2 - Create Operation Type "Push Transfer" - Type of Operation: Internal Transfer - Sequence Prefix: L2L1 - Source Location: L2 - Destination Location: L1 - Create Route "MO child" - Create Rule "Manufacture" - Action: Manufacture - Operation Type: MO child - Source Location: False - Destination Location: Stock - Create Route "2-step" - Warehouse: Main WH - Create Rule "L1 -> Virtual/Production" - Action: Pull from - Operation Type: MO child - Source Location: L1 - Destination Location: Virtual/Production - Create Rule "Push: L2 -> L1" - Action: Push To - Operation Type: Push Transfer - Source Location: L2 - Destination Location: L1 - Unarchive MTO - Edit MTO route - Create Rule "L1 -> Virtual/production (MTO)" - Action: Pull - Operation Type: "My Company: Manufacturing" - Source Location: L1 - Destination Location: Virtual/Production - Supply Method: Trigger another rule - Create product "Main product" - Create product "Child product" - Routes: "MO child" & MTO - Create product "Material" (consumable) - Create BOM - Product: "Main product" - Component: "Child product" - Create BOM - Product: "Child product" - Component: "Material" - Create MO for "Main product" - Misc/Component Location set to L1 - Duplicate the MO - Merge child MOs & produce - Validate merged MO transfer to L1 - Go back to one of the "Main product" MO > Component quantity is 0 </details> ----- Ticket: opw-5144196 Forward-Port-Of: odoo/odoo#242373 Forward-Port-Of: odoo/odoo#240695
This update corrects a bug where delivery fees weren't accurately calculated when sales orders and company currencies differed. The fix ensures that delivery costs are correctly displayed based on the order's currency, preventing discrepancies in pricing. This improves the reliability of delivery cost reporting.
Original PR description
Issue ----- When the SO and the company use different currencies, the picking currency is correctly set to the SO's but the amount is still computed using the company's currency. Example: Sale in…
Issue ----- When the SO and the company use different currencies, the picking currency is correctly set to the SO's but the amount is still computed using the company's currency. Example: Sale in EUR, Company in USD and 1.5 EUR = 1 USD rate. Sell for 15 EUR of products => the delivery picking shows 10 EUR Steps to reproduce ----- - Activate EUR currency at 1.5 EUR = 1 USD rate - Setup company in USD - Setup INTL FEDEX delivery method - Create a dummy product with a 10 USD sale price - Create a pricelist using the EUR currency - Create a sale for some INTL client - set pricelist to EUR - add dummy product - add INTL FEDEX shipping - confirm the sale - Confirm the linked delivery > Message in chatter shows a price of 10 EUR instead of 15 EUR Cause ----- The problem is with the `carrier_price` field of `stock.picking`. https://github.com/odoo/odoo/blob/7c443175f563b9b12a7b8f638524f7f625962dc2/addons/stock_delivery/models/stock_picking.py#L21 The value is set by https://github.com/odoo/odoo/blob/7c443175f563b9b12a7b8f638524f7f625962dc2/addons/stock_delivery/models/stock_picking.py#L155 which gets its' value from the response of https://github.com/odoo/enterprise/blob/0aea72c8db3067073afe1f89dfddf2b43d9392e9/delivery_fedex_rest/models/delivery_fedex.py#L157 We then go through https://github.com/odoo/enterprise/blob/0aea72c8db3067073afe1f89dfddf2b43d9392e9/delivery_fedex_rest/models/fedex_request.py#L382 where we call https://github.com/odoo/enterprise/blob/0aea72c8db3067073afe1f89dfddf2b43d9392e9/delivery_fedex_rest/models/fedex_request.py#L484 The problem is that in `_decode_pricing` we take the first line matching the `rateType` with no regard to the currency of the rate https://github.com/odoo/enterprise/blob/0aea72c8db3067073afe1f89dfddf2b43d9392e9/delivery_fedex_rest/models/fedex_request.py#L594-L598 we should also filter to ensure the rate matches the order's specified currency. ----- Ticket: opw-5419724 Forward-Port-Of: odoo/enterprise#103737 Forward-Port-Of: odoo/enterprise#103232
This update resolves a crash that occurred when using integer rounding on accounting reports like Aged Receivable. The issue was caused by attempting to perform calculations with 'None' values, which resulted in an error. The fix skips rounding when a 'None' value is encountered, ensuring reports function correctly.
Original PR description
Currently, enabling the Integer Rounding option (e.g. 'Nearest') on accounting reports like Aged Receivable/Payable causes a crash when expanding lines if any column value evaluates to None. Steps to…
Currently, enabling the Integer Rounding option (e.g. 'Nearest') on accounting reports like Aged Receivable/Payable causes a crash when expanding lines if any column value evaluates to None. Steps to reproduce: 1) Install 'account_reports' module with demo data and enable developer mode. 2) Navigate to Accounting > Reporting> Partner Reports > Aged Receivable. 3) Click on 'gear icon' to navigate advance options. 4) Click on the Options tab and set Integer Rounding to 'Nearest', click save and close adv options. 5) Expand a partner line. Error: `TypeError: unsupported operand type(s) for /: 'NoneType' and 'int'` Root Cause: When integer rounding is enabled, the system iterates over formula results to round them using `float_round`(see[1]). However, specific report columns (such as totals for empty periods) may return None. The `float_round` function attempts to perform arithmetic on this value, failing because it cannot divide NoneType. FIX: Skip the rounding if the value received at [1] is None. [1]- https://github.com/odoo/enterprise/blob/9b517564d95424836da1e8368f6b5dc52ae45d1a/account_reports/models/account_report.py#L3329 opw-5392883 Forward-Port-Of: odoo/enterprise#102417
This update fixes an error in how stock valuations are calculated when receiving products purchased in a foreign currency (like EUR) with an auto-standard product. Previously, an incorrect currency exchange entry was created, leading to inaccurate inventory values. The fix ensures the stock valuation accurately reflects only the product's cost, regardless of currency.
Original PR description
Processing a buy-receive-bill process in a foreign currency and with an auto-standard product will lead to an incorrect valuation To reproduce the issue: (Company in USD) 1. Enable EUR and define the…
Processing a buy-receive-bill process in a foreign currency and with an auto-standard product will lead to an incorrect valuation To reproduce the issue: (Company in USD) 1. Enable EUR and define the rates as followed: - Yesterday: 2 - Today: 2.5 2. Create a product category: - Method: Standard - Valuation: Automated 3. Create a product P in that category - Cost: 10 USD 4. [Yesterday] Confirm a PO in EUR with 1 x P 5. [Yesterday] Receive it 6. Bill Error: the stock valuation has two entries: one with 10 USD debit, the receipt. Another one with 2 USD credit, the currency exchange rate difference. The second one is a mistake, in a standard configuration, the stock valuation should be impacted by nothing but the cost defined on the product form. Since [1], in some conditions the method `_get_exchange_account` returns the stock valuation account. This is what happens here, but it's a mistake since in the above case, we should stick with the classic account (i.e. the `super` call). The conditions must be more strict. [1] https://github.com/odoo/odoo/commit/bae7feefcb08db7329d52bc36517dfd73f3347a7 OPW-5380665 Forward-Port-Of: odoo/odoo#243094 Forward-Port-Of: odoo/odoo#243029
This update fixes an issue where components added to manufacturing orders through the product catalog weren't correctly transferred to the pre-production warehouse. The fix adds a warehouse ID to these moves, ensuring proper inventory tracking and fulfillment within multi-step manufacturing processes. This improves the accuracy of component usage and reduces potential stock discrepancies.
Original PR description
Issue
-----
In multi step manufacturing, components added to MO through the catalog don't get transfered to the pre-prod location.
Steps to reproduce
-----
- 2 step manufacturing
- Create 2 products
- Create a MO for the first product
- Open the product catalog
- Add some qty of the second product
- Go back to the MO & confirm it
> No procurement transfer for the second product from stock to pre-prod
Cause
-----
The move created by the catalog has no `warehouse_id` so in `adjust_procure_method` we don't find any rule which means it gets set to MTS
https://github.com/odoo/odoo/blob/6ecd271ff34313d900a0ad14b1c20679808ba9b8/addons/stock/models/stock_move.py#L2366-L2368
-----
Ticket:
opw-5221418
Forward-Port-Of: odoo/odoo#243036
Forward-Port-Of: odoo/odoo#239265This update fixes an issue where loyalty programs with pricelist restrictions weren't properly recognized in the POS. Now, the POS correctly considers pricelist restrictions when applying loyalty programs, ensuring accurate pricing and preventing incorrect loyalty applications based on the current transaction's pricelist.
Original PR description
Before this commit, if a loyalty program had pricelist restrictions, the POS would not consider them when loading the applicable loyalty programs. This could lead to scenarios where a loyalty program was applied in a POS session even if the session's pricelist was not allowed by the program. This happened when the pricelist was also not available in the POS configuration and program.pricelist_ids was empty. opw-5467990 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242279
This update resolves a problem where clients were incorrectly using outdated number ranges when syncing data with DIAN. The fix ensures that the latest, valid number range provided by DIAN is always used, preventing invoice errors and improving data accuracy. This impacts invoice processing with DIAN.
Original PR description
**PROBLEM** When a client has exhausted a number range for a prefix, if he request a new one, when trying to sync the DIAN data the old range will be use instead of the new one. **STEP TO REPRODUCE**…
**PROBLEM** When a client has exhausted a number range for a prefix, if he request a new one, when trying to sync the DIAN data the old range will be use instead of the new one. **STEP TO REPRODUCE** According to the DIAN documentation, the GetNumberRange service is only available in the production environment. So i'm not sure if we can safely test this. The repro steps would be something like: 1. Request a range. 2. Exhaust all number from this range by sending invoices to DIAN. 3. Request a new range. 4. sync with DIAN. (notice the range selected is still the old one). 5. Try sending a new invoice to DIAN and notice there is an error. **CAUSE** In `l10n_co_dian/models/account_journal.py` the function `_l10n_co_dian_get_journal_values()` loops on all the xml `NumberRangeResponse` node and store the last range values encountered for each prefix. We don't check if the this last range is still valid, if it's the newest created (could be checked with the xml field `ResolutionDate`, but the date could be the same if the range were created the same day), if it's the latest in term of number range (DIAN start with range 1-100, then 101-something etc.). Forward-Port-Of: odoo/enterprise#103943
This update automatically recalculates taxes and fiscal positions for draft website orders whenever a partner's address is updated. This prevents incorrect tax calculations and ensures data accuracy for online sales. The change introduces a flexible mechanism to recompute taxes for a wider range of records, prioritizing draft orders to maintain data integrity.
Original PR description
Followup of 290d77cde41295b28aa522025136b48f74abcfc5.
When updating a partner address that may impact the fiscal position, we will recompute the fiscal position (and taxes) for draft website orders.
But other modules may also need to recompute other records, so avoid repeating the recomputing, this commit introduces a hook to allow extending the subset of records for which we need to recompute the fiscal position and taxes.
As the extended domain may contain non-draft records, ensure we only recompute prices for draft orders.
opw-5365258
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update fixes an issue where subscription tax calculations were incorrect after a partner address was updated. The change ensures that fiscal positions and taxes are automatically recalculated when subscriptions are running or churned subscriptions are reopened, preventing inaccurate invoice amounts. This improves the accuracy of subscription billing and invoicing.
Original PR description
When updating a partner address that may impact the fiscal position, we need to ensure the fiscal position (and taxes) are also updated on running subscription or when reopening a churned subscription. Otherwise the subscription and generate invoices won't have the correct taxes and amount. opw-5365258
This update fixes a dashboard display issue that was preventing accurate employee information from being shown in payroll export warnings. The changes now correctly list employees without version ID export codes and incorporate Prisma code for a better user experience. This ensures more reliable and complete payroll export data.
Original PR description
\* = {acerta, group_s, prisma}
Dashboard warnings opened a contract template containing the version data of the employee, while not showing employee's name or id, this commit changes the redirected view to a list of employees that do not have the version id's export code.
This commit also adds Prisma code to the external codes group for better UX
task: 5212681This update resolves an issue where Nilvera e-invoice synchronization for sales and purchases was conflicting, preventing updates to both flows. By using unique configuration keys based on the journal type (sale or purchase), the system now ensures each flow can independently fetch and sync e-invoices without interference. This improves the reliability of Nilvera data import.
Original PR description
# Description of the issue/feature this PR addresses: Nilvera e-invoice synchronization stores the last fetched date in a system parameter to allow incremental fetching on subsequent runs. Currently,…
# Description of the issue/feature this PR addresses: Nilvera e-invoice synchronization stores the last fetched date in a system parameter to allow incremental fetching on subsequent runs. Currently, this parameter is shared between sales and purchase flows, causing their synchronization states to overwrite each other. # Current behavior before PR: When sales and purchase documents are synchronized from Nilvera, both flows use the same configuration parameter to store the last fetched date. As a result, running one synchronization (e.g. sales) may prevent the other flow (e.g. purchases) from fetching new documents, leading to missing or incomplete imports. # Desired behavior after PR is merged: Sales and purchase synchronizations maintain independent last fetched dates by using journal-specific configuration keys. This allows both flows to run reliably and incrementally without interfering with each other. taskId - 5494295 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where ZATCA invoice XML generated in version 19.0 had inconsistent line amount calculations, leading to validation errors. The fix ensures that LineExtensionAmount, TaxAmount, and RoundingAmount align correctly, allowing invoices to pass ZATCA validation. This improves compliance and avoids potential disruptions to sales processes.
Original PR description
**Steps to reproduce:** * Install the **l10n_sa_edi** and **accounting** modules. * Create a **15% tax** (tax-included). * Create a customer invoice with two lines with amounts 18 and 14 and apply…
**Steps to reproduce:**
* Install the **l10n_sa_edi** and **accounting** modules.
* Create a **15% tax** (tax-included).
* Create a customer invoice with two lines with amounts 18 and 14 and apply
the tax on an invoice line.
* Post the invoice and **send it to ZATCA**.
* Review the generated XML or submit it for ZATCA validation.
**Observed behavior:**
* The XML nodes **LineExtensionAmount**, **TaxAmount**, and
**RoundingAmount** contain inconsistent values.
* ZATCA validation raises warnings due to rounding mismatches.
* Example:
* in xml data look like this
* `15.66(LineExtensionAmount) + 2.34(TaxAmount) != 17.99(RoundingAmount)`(v19)
* The required relation
**LineExtensionAmount + TaxAmount = RoundingAmount**
is violated.
**Cause:**
* In v19.0, `_round_base_lines_tax_details()` distributes rounding deltas so
that the **sum of rounded line taxes** matches the **rounded global tax**.
* When taxes are **included in price** and there are **multiple invoice lines**,
this distribution adjusts the per-line tax and base amounts.
Example pattern:
* Raw line taxes sum to something like **4.1739…**
* Rounded global tax = **4.17**
* Sum of individually-rounded line taxes = **4.18**
* A **-0.01 delta** is distributed across the lines
* Result:
* Line 1 base becomes **15.66**, tax **2.34**
* Line 2 base becomes **12.17**, tax **1.83**
So the XML correctly reports:
* **LineExtensionAmount = 15.66**
* **TaxAmount = 2.34**
* However, **RoundingAmount** is computed differently:
https://github.com/odoo/odoo/blob/e8a41b5b50ac71974d98c18fa9d47e37e0f7763f/addons/l10n_sa_edi/models/account_edi_xml_ubl_21_zatca.py#L439-L444
* Here, `base_line['tax_details']['total_excluded_currency']` **does not include the distributed delta**. It still reflects the *pre-distribution* base (e.g. **17.99 total excluded**), while **LineExtensionAmount** uses `vals['total_excluded_currency']`, which *does* include the delta.
* Result: the required identity
`LineExtensionAmount + TaxAmount = RoundingAmount`
is broken — producing inconsistencies such as:
`15.66 + 2.34 ≠ 17.99`
**Fix:**
* Use the same **vals[total_excluded_currency]** as it has a tax-excluded price with the delta included.
opw-5402750This update resolves an issue preventing the creation of credit notes with DIAN support documents, specifically when using certain journals. The problem stemmed from an incorrect namespace being used, leading to errors when sending the required DIAN documents. This fix ensures credit notes with DIAN support documents can be successfully processed.
Original PR description
**PROBLEM** When trying to create a credit notes using a journal with support documents, there is a lot of errors when sending the dian documents. **STEP TO REPRODUCE** 1. setup DIAN (knowledge page https://www.odoo.com/odoo/knowledge/5/knowledge/23114). 2. create a vendor bill, and then create a credit note with the DIAN support document journal. 3. Confirm and click on send DIAN documents. **CAUSE** `_get_document_nsmap()` uses the wrong namespace for credit notes. opw-5378540
This update fixes an error in the calculation of pay run end dates for Mexican companies using specific payroll schedules (10 Days, 14 Days, Bi-weekly, Bi-monthly). The underlying calculation method was updated, but the Mexican payroll module hadn't been adjusted, leading to incorrect period determination. This ensures accurate payroll processing for Mexican businesses.
Original PR description
Bug: When we create a new pay run for a mexican company and we select the schedule "10 Days", "14 Days", "Bi-weekly" or "Bi-monthly", the end of the period is computed incorrectly. Cause: The standard method changed but it wasn't updated in the mexican payroll module. Fix: Change the signature of the method to match the one in hr_payroll. Task: 5421825 Forward-Port-Of: odoo/enterprise#102326
This update corrects a potential issue in how the system locks payroll periods for tax reporting in Switzerland (l10n_ch_hr_payroll). By using a reference date, the system now accurately reflects the period being used for ELM transmission, ensuring correct tax calculations and compliance. This improves the reliability of financial reporting.
Original PR description
Forward-Port-Of: odoo/enterprise#104269
This update fixes an issue where changes to website views (like footer edits) were lost during module upgrades. The fix ensures that translations are correctly applied after upgrades, preventing data loss and maintaining consistent website content across languages. This improves the reliability of website updates and the accuracy of translated content.
Original PR description
In commit 03a85b13b2c46ef7174123d902e95d5103031c6c, delayed translations were restored. Delayed translations of a view were lost on upgrade of the module that contains the corresponding generic view.…
In commit 03a85b13b2c46ef7174123d902e95d5103031c6c, delayed translations were restored. Delayed translations of a view were lost on upgrade of the module that contains the corresponding generic view. This happened because the update of the view did not take into account the possible delayed translations when updating it and the translations in specific views. This commit updates (and uses as source) the current versions, instead of the delayed ones. Steps to reproduce: - Install a second language for the website - Set the default language for the website to the second language - Edit footer by changing structure not just text (like changing a link to have a button appearance) - Upgrade the "Website" app - Bug: footer lost the last edit Steps to reproduce: - Install a second language for the website - Edit footer by changing structure not just text (like changing a link to have a button appearance) - (Observe that the change is not in the website in the second language) - Upgrade the "Website" app - Bug: the change is now in the website in the second language task-5248173 Fixes #233723
This update fixes an issue where GS1 barcodes with quantity information weren't being properly used in manufacturing orders. Previously, the system only added one unit of the product, regardless of the barcode's quantity. Now, the system accurately reflects the quantity specified in the GS1 barcode when scanning the final product, ensuring consistent behavior and accurate production tracking.
Original PR description
Description of the issue/feature this PR addresses: The quantity of GS1 barcodes was not taken into account when scanning the final product of a manufacturing order. More details of this issue can be found in https://www.odoo.com/odoo/project.task/4817418 Current behavior before PR: When scanning a GS1 barcode with a quantity defined (e.g. 0120250524135700310210000010LOT887766 ) as the final product of a manufacturing order, the quantity is not taken into account in the call to produceQty(), so the line will have a qty_done of 0 regardless of the quantity specified in the barcode Desired behavior after PR is merged: The qty_done of the final product line should be the one specified in the barcode, in order to make the behaviour consistent with other usages of GS1 barcodes. Forward-Port-Of: odoo/enterprise#104024 Forward-Port-Of: odoo/enterprise#95174
This update resolves an issue where the original invoice linked to a reverse move was not being displayed correctly. Previously, when reversing an invoice, the 'Source Document' field in the invoice list was blank. This fix ensures that the correct original invoice is always linked, improving reporting accuracy and traceability of financial transactions. This was a regression identified and addressed in the Odoo system.
Original PR description
### Issue: Reverse moves miss `invoice_origin` field. #### To reproduce: 1- Create a SO. 2- Create an invoice and confirm. 3- In invoice list view make the `Source Document` visible. 4- Create a credit note and reverse the move. From invoice list view, you can observe that `Source Document` is empty for reverse move. ### Cause: This is a regression introduced by #236656. opw-5362055 Forward-Port-Of: odoo/odoo#240439
This update fixes an issue where customer statements incorrectly showed an outstanding balance after invoices were partially paid and reconciled. The fix ensures the system accurately considers the remaining amount due, including partially reconciled invoices, leading to more precise customer statements. This improves the accuracy of financial reporting.
Original PR description
**Steps to Reproduce:** 1. Create an invoice with a due date 20 days prior and an amount of $100 2. Create a payment of 120$ 3. Create an invoice of 100$ 4. Reconcile the second invoice with the…
**Steps to Reproduce:** 1. Create an invoice with a due date 20 days prior and an amount of $100 2. Create a payment of 120$ 3. Create an invoice of 100$ 4. Reconcile the second invoice with the payment 5. Go to the customer record. 6. The Customer Statement smart button shows an amount due, but the followup status in the Accounting tab shows "No action needed". [Video (with different values, same result)](https://drive.google.com/file/d/1MFg-tUos-oGbk7SKn92OE8w0-PnObae7/view?usp=sharing) **Cause:** - The query in `_get_followup_data_query` checks an account.move.line's `balance`, ignoring amounts partially reconciled. [1](https://github.com/odoo/enterprise/blob/da8a0fb49861a5cfb366c85da459876ad1556924/account_followup/models/res_partner.py#L404) - In the example above, the sum of unreconciled balances is 100 - 120 = -20 due, where the amount_residual shows 100 -20 = 80 due. **Solution:** Use `amount_residual` instead of `balance` in `_get_followup_data_query`. This fix was applied last year to 17.0, but was never forward-ported to master. [2](https://github.com/odoo/enterprise/pull/77679) [opw-5216007](https://www.odoo.com/odoo/project.task/5216007) Forward-Port-Of: odoo/enterprise#101874