Odoo Changelog — 2026-06-03

Wednesday, June 3, 2026

18 changes · saas-19.2

New Features(1)

New functionality added to Odoo

[ADD] pos_cashmatic: support for cash machine

Coresaas-19.2pos_cashmaticMedium

This update integrates with Cashmatic, a company providing self-service cash machines, through a new HTTP API connection. This allows Point of Sale (POS) systems to communicate with these machines for automated cash counting and dispensing, streamlining transactions. It's a key addition to support modern payment options.

Original PR description

Cashmatic is a company providing self-service cash machines, which can automatically count cash and
dispense change. This commit adds basic support
for Cashmatic cash machines via an HTTP REST API
connection.

Task-5887125

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

Forward-Port-Of: odoo/odoo#253585

#payment#cash#POS#integration

Bug Fixes(17)

Resolved issues and error corrections

[FIX] sale_stock,stock_dropshipping: avoid negative delivery when not a return

PR #267760

Coresaas-19.2sale_stockstock_dropshippingMedium

This update resolves an issue where dropshipping orders incorrectly displayed a negative delivered quantity. The change introduced a new functionality for returns that inadvertently caused this error. The fix ensures accurate delivery quantity calculations by preventing negative values when dropshipping isn't involved.

Original PR description

Currently, an error occurs when the user receives a dropship order instead of delivering it directly to the customer. As a result, the sale order shows a negative delivered quantity. ## Steps to…

Currently, an error occurs when the user receives a dropship order instead of delivering it directly to the customer. As a result, the sale order shows a negative delivered quantity. ## Steps to replicate: - Install Sales, Inventory, and Purchase. - Enable Dropshipping from Inventory settings. - Create a test product with the Dropship route enabled and set a vendor for it in the Purchase tab. - Create and confirm a quotation for a customer. - Go to Purchase > `Deliver To:` and set it to `My Company: Receipts.` - Confirm the Purchase Order and validate the receipt. - Go back to the Sale Order. ## Observed Behavior: The delivered quantity is -1, which is incorrect because the customer has not returned any products, nor has the user created a sale order line with a negative quantity (which would indicate a return). ## Root cause: When computing the delivered quantity at [1], the function `_get_outgoing_incoming_moves` [2] is called to retrieve the incoming and outgoing stock moves associated with the sale order lines. Inside this function, moves are filtered and categorized as incoming or outgoing. At [3], the condition is satisfied because the default value of `to_refund` is `True`, so the move is added to `incoming_move_ids`. Later, during the computation at [1], the code iterates through the incoming moves and subtracts their quantities from the delivered quantity. Since the initial delivered quantity is 0, including such a move in `incoming_move_ids` causes the delivered quantity to become -1. <h3> Why did this behavior not occur in lower versions?:</h3> This issue was introduced by [commit], which added the functionality for users to return products that are not listed in the purchase order. As a result, their quantities appear as negative received quantities on the purchase order. Before this change (in saas-18.2), the field `move.to_refund` had a default value of `False`. Because of this, the condition at [3] was not satisfied, and the move was not included in `incoming_move_ids`. Therefore, it was not subtracted when iterating through incoming moves, and the delivered quantity did not become negative. Starting from 18.3, the default value of `to_refund` was changed to `True`. This causes the condition at [3] to be satisfied, the move to be included in `incoming_move_ids`, and its quantity to be subtracted during the computation, resulting in a delivered quantity of -1. [1]- https://github.com/odoo/odoo/blob/1256875226436a854558a1334ffdc886fa4767a8/addons/sale_stock/models/sale_order_line.py#L193-L209 [2]- https://github.com/odoo/odoo/blob/1256875226436a854558a1334ffdc886fa4767a8/addons/sale_stock/models/sale_order_line.py#L316-L353 [3]- https://github.com/odoo/odoo/blob/1256875226436a854558a1334ffdc886fa4767a8/addons/sale_stock/models/sale_order_line.py#L346-L351 ## Solution: We can make the condition stricter by ensuring that only incoming moves that are actual returns are counted as negative in the quantity delivered on a sale order. Specifically, if an incoming move has no corresponding originating return move and the customer has not created a sale order line with a negative quantity (which could also indicate a return), it should not be considered when calculating the delivered quantity. [commit]: https://github.com/odoo/odoo/pull/209110/changes/c1c86182e4b28e929bf56e79f57f33aaa13e67f1 opw-5933594 Forward-Port-Of: odoo/odoo#267531 Forward-Port-Of: odoo/odoo#252383

Steps to reproduce: ------------------------------------ 1. Install `base_automation` and the Sales module 2. Create an automation rule for a sale order as follows: * Trigger: State set to Sale order * Add a Create Activity action * Change User Type to Dynamic * Set User Field to Customer > Users 3. Create and confirm a sale order with Admin as the customer Observation: ------------------------------------ The activity is created in Chatter, but it was not assigned to any user Issue: ------------------------------------ The condition `self.activity_user_field_name in record` uses the `__contains__` check which only looks for direct fields on the record's model. A dotted path like 'partner_id.user_id' is not a field name on the record itself, so the check evaluated to `False`, skipping the user assignment entirely https://github.com/odoo/odoo/blob/2bafcebfaba01e46856d6eb2a440ede95b9c0a4a/addons/mail/models/ir_actions_server.py#L378-L379 Solution: ------------------------------------ Use `record.mapped()` as a fallback when the field name is not directly present on the record. `mapped()` natively supports dotted paths by traversing the relational chain (e.g. record -> partner_id -> user_id) opw-6191715 Related Enterprise PR: https://github.com/odoo/enterprise/pull/118921 Forward-Port-Of: odoo/odoo#263530

__ ## Short functional explanation of the error When confirming a Purchase Order holding lines with an analytic distribution that has been manually added, and creating a vendor bill out of this PO using the Auto-Complete field. When we change the account of that line, the line loses the manually added Analytic Distribution. ## Reproduction Steps 1. Go to Accounting. Click on the tab Configuration; under the Analytic Accounting section, click on Analytic Distribution Models. 2. Create an Analytic Distribution Model for a product. 3. Go to Purchase. Create a new PO, set a Vendor and select the product you created the Analytic Distribution Model for. On the right side of the form, click on the view menu and check Analytic Distribution to make it appear. 4. Click on the Analytic Distribution of the product and add a new one; for example, select Administrative in the Departments section. 5. Confirm order. 6. Go to Accounting and click on the Vendors tab > Bills. Create a new bill, and in the field Auto-Complete, select the PO you just created. 7. Change the account of the line. ### Expected behavior Only the account should be changed on the line. ### Unexpected behavior The manually added Analytic Distribution has disappeared. ## Origin of the issue When we change the `account_id` field, the compute method `_compute_analytic_distribution` is triggered. This method retrieves the related distributions of the line: https://github.com/odoo/odoo/blob/af32885ec5f07d492f3b8e8fff1785996a739f72/addons/account/models/account_move_line.py#L1154 which, in the context of Purchase, calls this method: https://github.com/odoo/odoo/blob/af32885ec5f07d492f3b8e8fff1785996a739f72/addons/purchase/models/account_invoice.py#L540-L545 We retrieve the distribution of the related line using `self.purchase_line_id.analytic_distribution`. However, this code isn't triggered when the move line has an analytic distribution, even though the related line `purchase_line_id` might have one! Therefore, we need to execute that code whether or not our move line has an analytic distribution. Note: the same behavior is to avoid when creating invoices for quotations. __ opw-6062466 Forward-Port-Of: odoo/odoo#267274 Forward-Port-Of: odoo/odoo#258380

Issue ----- Traceback when trying to get a rate through the e-commerce if the order has to be split into multiple packages due to weight being too high. Steps to reproduce ----- - Setup Sendcloud delivery method - make it available in e-commerce - Create a 150kg product and publish it - Go to e-commerce - Add the product to cart - Checkout the cart > Traceback Cause ----- We retrieve the order's weight through the context. https://github.com/odoo/enterprise/blob/d9a9339e1f30f1e5cc37ebb88949451a6652f83b/delivery_sendcloud/models/delivery_carrier.py#L108 If the call to `_get_shipping_rate` returns that the delivery requires multiple packages, we go into https://github.com/odoo/enterprise/blob/d9a9339e1f30f1e5cc37ebb88949451a6652f83b/delivery_sendcloud/models/delivery_carrier.py#L126-L128 If `order_weight` was not present in the context, this will cause an error in `sendcloud_convert_weight` since it expects a numerical value but receives the `None` fallback. This context key is only present when going through `choose.delivery.carrier` (so not in the e-commerce flow). https://github.com/odoo/odoo/blob/058e640e6687ed3f709dc846f0fa7a1f45226849/addons/delivery/wizard/choose_delivery_carrier.py#L69 ----- Ticket: opw-6210398 Forward-Port-Of: odoo/enterprise#119048 Forward-Port-Of: odoo/enterprise#117028

Several error are logged in the chatter when signing a payslip that includes an IMSS disability time off. Steps to reproduce: * Install l10n_mx_hr_payroll_account modules * Switch to "INNOVACION VALOR Y DESARROLLO SA SA" company * Go to Employees and open Cesar Osbaldo Cruz Solorzano * Click on "Time Off" smart button and create a new time off with "Disability due to illness (IMSS)" type for "02/01/2026"(Any date). * Go to Payroll > Payslips > Payslips and create a new pay run * Select Salary Structure 'Mexico: Regular Pay', Pay Schedule 'Monthly' and the Period '01/01/2026 -> 01/31/2026' * Click on Continue, select Cesar and click on Select * Open the payslip, click on "Validate" and "Ok" * Mark as paid, open the "Journal Entry" from the smart button and click on "Post". * Back to the payslip, and click on "Generate CFDI" button. * An error is added to the chatter. ### Missing node to declare disabilities Original message ```py An error occurred while signing the CFDI document with the government: Code : NOM111 Message : Error no clasificado. Extra Info : El nodo "Incapacidades" se debera informar si se incluye en percepciones la clave 014 "Subsidios por Incapacidad" o bien en deducciones la clave 006 "Descuento por incapacidad". ``` Translated message ```py An error occurred while signing the CFDI document with the government: Code: NOM111 Message: Unclassified error. Extra Info: The "Incapacidades" (Disabilities) node must be reported if the perception key 014 "Subsidios por Incapacidad" (Disability Subsidies) is included, or if the deduction key 006 "Descuento por incapacidad" (Disability Deduction) is included. ``` Legal Context: According to Mexican law, IMSS disabilities must be declared in a specific XML node. There are two primary scenarios for reporting these amounts: * Deduction (Type 006): The employer does not pay for these days, as the IMSS is responsible for the payment to the employee. This is the most common scenario. * Perception (Type 014): The employer pays for these days as a superior benefit. For example, by law, the IMSS does not pay for the first 3 days of a disability due to illness, and employers are not obligated to cover them either. However, companies offering superior benefits may choose to pay these days as a "Disability Subsidy." Solution: The chosen approach is to configure the Deduction node. For the `l10n_mx_regular_pay_imss_disabilities` rule, the `l10n_mx_concept` has been set to `l10n_mx_concept_d6` (D06 - Disability Deduction). This ensures the required node is added. ### Missing "ImporteMonetario" attribute Original message ``` An error occurred while signing the CFDI document with the government: Code : NOM95 Message : El atributo Deduccion:Importe no es igual a la suma de los nodos Incapacidad:ImporteMonetario, ya que la clave expresada en Nomina.Deducciones.Deduccion.TipoDeduccion es "006". ``` Translated message ``` An error occurred while signing the CFDI document with the government: Code: NOM95 Message: The attribute "Deduccion:Importe" does not match the sum of the "Incapacidad:ImporteMonetario" nodes, as the key expressed in "Nomina.Deducciones.Deduccion.TipoDeduccion" is "006". ``` Problem: The "Incapacidades" node requires the "ImporteMonetario" attribute, which should represent the sum of the monetary value associated with the disabilities. Solution: Add the "ImporteMonetario" attribute and calculate its value using `l10n_mx_daily_salary`. ### Invalid "DiasIncapacidad" format ```py An error occurred while signing the CFDI document with the government: Code : 301 Message : XML mal formado Extra Info : Element '{[http://www.sat.gob.mx/nomina12}Incapacidad](http://www.sat.gob.mx/nomina12%7DIncapacidad)', attribute 'DiasIncapacidad': '4.0' is not a valid value of the local atomic type. ``` Problem: Altough the defaultdict where the values are sum up, `number_of_days` is a float field, and when we get back the value, it is a float, adding for example 4.0 instead of 4, which is not a valid value. Solution: Cast the value to int. ### Duplicate deduction on disabilities ```py Wrong python code defined for: - Employee: Cesar Osbaldo Cruz Solorzano - Version: False - Payslip: Salary Slip - Cesar Osbaldo Cruz Solorzano - 05/01/2026 - 05/15/2026 - Salary rule: ISR (Income Tax) (ISR) - Error: TypeError('cannot unpack non-iterable NoneType object') while evaluating " def find_rates(x, rates): for low, high, fix, rate in rates: if low <= x <= high: return low, high, fix, rate gross = categories['GROSS'] result = 0 if gross: isr_table = payslip._rule_parameter('l10n_mx_isr_tables')[version.schedule_pay] low, high, fix, rate = find_rates(gross, isr_table) result = -((gross - low) * rate + fix) period_factor = payslip._rule_parameter('l10n_mx_schedule_table')[version.schedule_pay] if period_factor >= 15: period_factor = (period_factor / 30) * (365 / 12) min_wage = payslip._rule_parameter('l10n_mx_daily_min_wage') * period_factor if gross <= min_wage: result_qty = 0.0 " ``` Problem: The IMSS disability amount is being deducted twice: 1. During "Worked Days" calculation, the IMSS disability is already not considered because the work entries belong to the "Unpaid Work Entry Types" of "Mexico: Regular Pay" structure. 2. During "Salary Computation", the `IMSS_DISABLE` salary rule deducts another time because it is in the `TAXABLE_ALW` category, and this one is deducted in the `NET` rule. When the disability covers more than half of the period (e.g., 20 days in a monthly schedule), the double deduction causes the NET to become negative. This prevents the ISR rule from finding a correct stage in the tax tables, leading to a traceback. Example: For a monthly wage of 30,000.0 and 5 disability days: - The total amount in "Worked Days" is 25,000.0 (disabilities already deducted). - The IMSS_DISABLE rule calculates -5,000.0, and when the NET rule is calculated, the disabilities are deducted again. Total NET becomes 16,843.84 instead of the expected 20,834.85. Solution: Change the rule category to `INTERMEDIARY_COMPUTATION` and avoid the double deduction when the `NET` is calculated, as it is already considered in the "Worked Days". ### Incorrect values in the XML The signing process completes without errors, but some amounts in the generated XML are incorrect. Problem: The introduction of the Deduction 006 (Disability) directly impacts the calculation of the SubTotal and Total attributes in the Comprobante node. For a monthly payslip with a wage of 30,000.00 (daily salary of 1,000.00) and 5 disability days (work risk), the values are calculated incorrectly as follows: Attribute | Calculation | Actual Value | Correct Value ---------------------|----------------------------------|--------------|-------------- Comprobante:SubTotal | Sum of Perceptions (P01) | 25000.00 | 30000.00 (1) Comprobante:Total | SubTotal - Total Deductions (2) | 15803.74 | 20803.74 (1) Must include the 5,000.00 from disabilities to balance the deduction. (2) Total Deductions = D06 (5,000.00) + ISR (3,451.65) + IMSS (744.61) = 9,196.26. The Total is currently undercalculated because the 5,000.00 is being deducted from the SubTotal that already had those 5,000.00 excluded. Solution: Since the `SubTotal` is derived from Perceptions, and the "(P01) Salaries, Wages, Stripes, and Day Labor" amount is driven by the `GROSS_WITHOUT_HOLIDAY` rule, the disability amount must be added. This balances the Deduction 006, ensuring `SubTotal` is correct. ### Absenteeism and Disabilities By law, the calculation of IMSS contributions depends on these two types of unpaid days: * Disabilities: Refers to medical leave issued by the Institute (IMSS). * Absenteeism: Refers to unjustified leave; apply for periods of fewer than 8 days. Source: [Artículo 31](https://www.imss.gob.mx/sites/all/statics/pdf/leyes/LSS.pdf) Translated text: Article 31. When wages are not paid due to the employee's absence from work, but the employment relationship persists, the monthly contribution shall be adjusted according to the following rules: I. If the employee's absences are for periods of fewer than eight consecutive or non-consecutive days, contributions shall be calculated and paid for such periods only for the sickness and maternity insurance... If the employee's absences are for periods of eight consecutive days or more, the employer shall be released from the payment of employer-employee contributions... IV. In the case of absences covered by medical disabilities issued by the Institute, it shall not be mandatory to cover the employer-employee contributions, except regarding the retirement branch. The following table summarizes the contribution requirements based on the type of absence: Insurance Branch (RAMA) | Section I (Absenteeism) | Section IV (Disability) --------------------------------|-------------------------|------------------------ Sickness and Maternity | Paid | Not Paid Disability and Life | Not Paid | Not Paid Severance and Old Age | Not Paid | Not Paid Work Risk | Not Paid | Not Paid Daycare and Social Benefits | Not Paid | Not Paid INFONAVIT | Not Paid | Paid Retirement | Not Paid | Paid The type of unpaid day to be considered depends on the specific insurance branch being calculated within the employer-employee contributions. ### Add test for cfdi with disabilities. target: 19.0 task-6066160 Forward-Port-Of: odoo/enterprise#116819

**Steps to Reproduce:** 1. Configure the website default language different from the user’s current language. 2. Go to Website → Site → Pages. 3. Duplicate an existing page. 4. Edit the duplicated page and save the changes. 5. Duplicate the edited page again. 6. Observe that the newly duplicated page is generated from the original page content instead of the updated duplicated page. **Issue:** When duplicating a website page, the website default language was not passed in the context. As a result, the duplication was performed using the active user language. The root cause is that `copy()` does not simply duplicate the existing `arch_db` translation dictionary. Instead, it copies the field value in the current language and then rebuilds all translations through `copy_translations()`. This behavior becomes problematic when `delayed translations` are involved. After a page is modified in a non-default language, the latest changes may be stored in a delayed translation entry (`_{lang}`) while the regular translation value remains unchanged. During the copy process, these delayed translation entries are intentionally discarded because they are considered temporary data and are not treated as valid language translations. As a result, when the page is duplicated from a non-default language, `copy()` rebuilds the translations using an outdated translation value instead of the most recent content stored in the delayed translation. The newly duplicated page therefore does not accurately reflect the current state of the source page. **Solution:** The fix enables `check_translation=True` during page duplication so that the copy operation uses the latest translation state, including delayed translations when available. This ensures duplicated pages are generated from the most recent version of the source page and keeps translated content consistent across languages. **opw-5914281** Forward-Port-Of: odoo/odoo#264656

Problem ------------------ When creating group allocations, when the allocation type is accrual and the start date is set in the past, the newly created allocations have the accrual amounts at 0. To reproduce: 1. Create an accrual plan with an easily measurable milestone (e.g. 1 day every day) 2. From the allocations view -> New Group Allocation 3. Enter the following values: Grant -> By Employee Employees -> select your employee Time Off Type -> Paid Time Off (doesn't matter too much) Allocation Type -> Based on Accrual Plan Validity Period -> any date a few days in the past (Personally I tested with 1/1/2025 and no end date) Allocation -> Keep at 0 Allocate Time Off 4. Go to the newly created allocation The allocation amount is 0. Reason ---------------------- When creating group allocations, the `hr.leave.allocation.generate.multi.wizard` calls the `_process_accrual_plans()` method to compute the accruals, but when the allocations are created, the nextcall and lastcall fields are set, so the accruals are not computed and the scheduled action also does nothing until the nextcall date. The onchange method manually sets the nextcall date to False so the accruals are processed. Solution ------------------ Created a method to get the fields that need to be set to calculate the initial accrual amounts from the start date, which is called both in the onchange and to batch write in the wizard before accrual plans are processed. The wizard checks the duration values before overwriting the number_of_days field, since user manually setting the amount should overwrite the calculations. task-4938695 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267305 Forward-Port-Of: odoo/odoo#265783

When a mass mailing block uses a `bg-o-color-N` theme color class, the mailing's `body_arch` stores the class and `convert_inline` correctly inlines the resolved color into `body_html`, matching the website palette at save time. The class also stays on the element in `body_html`. The stylesheet rule that gives `bg-o-color-N` its color is declared with `!important`. When the website palette is later rebuilt (any change to the primary colors), the new `bg-o-color-N` rule wins over the inline color whenever `body_html` is rendered. So an already-sent mailing reopened in the backend shows the new palette's color instead of the one that was picked, and resaving the mailing bakes that new color into `body_html`. `classToStyle` already does the right thing for the property value. What was missing is dropping the class itself from `body_html` once its style has been inlined, so no future `!important` palette rule can override the inline color. `body_arch` keeps the class, so the editor preview stays theme-aware while editing, but `body_html` is now stable across palette rebuilds. Steps to reproduce: 1. Open Email Marketing and create a new mailing using the Welcome Message template 2. Select a content block, open Customize, set the background to the 5th theme color 3. Save the mailing 4. Open the Website editor and change the 5th primary color to a different value 5. Reopen the saved mailing in the backend => the block's rendered background follows the new website color instead of the one picked at design time Ticket [link](https://www.odoo.com/odoo/project.task/5892350) opw-5892350 Forward-Port-Of: odoo/odoo#267570 Forward-Port-Of: odoo/odoo#253934

### Description of the issue/feature this PR addresses: **Issue:** When processing incoming EDI/Peppol invoices, multiple contacts (parent companies, joint ventures, child contacts) frequently share the same VAT number. Because the parser's tie-breaker relies primarily on VAT, invoices are often incorrectly assigned to individual child contacts or newly created joint ventures rather than the correct vendor. **Solution:** Prepend is_company DESC, supplier_rank DESC to the SQL search order in the _import_retrieve_customer fallback domain. This ensures that the matching logic explicitly prioritizes business entities over individual contacts, and active vendors over other records. ### Current behavior before PR: When searching by VAT with limit=1, the parser uses order='company_id, parent_id DESC, id DESC'. If a parent company and a child contact share a VAT, the query frequently returns the child contact or a newer joint venture due to the id DESC fallback. ### Desired behavior after PR is merged: The parser will correctly prioritize main companies over individual contacts when VAT numbers are shared. If multiple companies share the same VAT, the most active vendor will be selected. opw-6174628 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266224

New Features(1)

[ADD] pos_cashmatic: support for cash machine

Bug Fixes(17)

[FIX] sale_stock,stock_dropshipping: avoid negative delivery when not a return

New Features(1)

[ADD] pos_cashmatic: support for cash machine

Bug Fixes(17)

[FIX] sale_stock,stock_dropshipping: avoid negative delivery when not a return

[FIX] whatsapp_account_followup: gate free-text required on WhatsApp toggle

[FIX] pos_viva_wallet: send cashRegisterId for Viva when cashier name is missing

[FIX] {,test_}mail: assign user to activity for automation rule

[FIX] html_editor: fix blur not triggered when focused inside nested contenteditable

[FIX] purchase, sale: keep analytic distribution on analytic account change

[FIX] account: keep currency amounts left-to-right in RTL UIs

[FIX] delivery_sendcloud: handle ecommerce multi-packages due to weight flow

[FIX] account: set default account on journal creation

[FIX] l10n_mx_hr_payroll: fix amount calculation in salary rules for IMSS disability

[FIX] hr_holidays: hr.leave.type.leave_validation_type = 'both' does not fallback to responsible_ids

[FIX] purchase: use PO currency when bill matching no bill

[FIX] website: use latest content when duplicating a page

[FIX] hr_holidays: compute group allocation correctly

[FIX] mail, web_editor: strip bg-o-color class from body_html

[FIX] l10n_gt_edi: allow NABN only for vendor credit notes

[FIX] account: prioritize companies and active vendors in EDI matching