Odoo Changelog — 2025-07-15

Tuesday, July 15, 2025

5 changes · saas-18.3

Bug Fixes(5)

Resolved issues and error corrections

[FIX] l10n_mx_edi: foreign payment does not match mxn values

Enterprisesaas-18.3l10n_mx_ediMEDIUM

This fixes a rounding mismatch when Mexican companies register payments in USD for invoices that must be reported in MXN. Payment CFDI documents should now validate correctly, reducing blocked payment reporting and manual correction work.

Original PR description

Steps to reproduce: - With an MX Company setup - Set USD rate to 20.4277 - Create an invoice as follows: - line 1: price_unit 93.76, quantity 172, tax 16% - line 2: price_unit 74.18, quantity 161,…

Steps to reproduce:
- With an MX Company setup
- Set USD rate to 20.4277
- Create an invoice as follows:
    - line 1: price_unit 93.76, quantity 172, tax 16%
    - line 2: price_unit 74.18, quantity 161, tax 16%
    - line 3: price_unit 74.18, quantity 162, tax 16%
    - line 4: price_unit 93.76, quantity 384, tax 16%
    - line 5: price_unit 111.28, quantity 178, tax 16%
- Confirm and send CFDI
- Register full payment in USD
- Send Payment CFDI

Issue: Payment validation will fail with error

> Code : 301
> Message : Error en complemento Recepción de Pagos. [Error #CRP20204] El
> Valor del campo TotalTrasladosBaseIVA16 no es igual al redondeo de la
> Suma del resultado de multiplicar cada uno de los importes de los
> Atributos BaseP de los impuestos trasladados registrados en el elemento
> TrasladoP donde los atributos contengan en ImpuestoP el valor IVA, en
> TipoFactorP el valor Tasa y en TasaOCuotaP el valor 0.160000, por el
> Valor registrado en el atributo TipoCambioP de cada nodo Pago. Folio: 2.
> Serie: PBNK1/2025/. El atributo "Totales:TotalTrasladosBaseIVA16"
> Contiene el valor "95898.54" sin embargo se calculó que la sumatoria
> Debe contener el valor "95898.45".

opw-4750981

Forward-Port-Of: odoo/enterprise#89817
Forward-Port-Of: odoo/enterprise#88952

#Mexico#CFDI#payments#currency#rounding

[FIX] pos_appointment: compute capacity booked

PR #88777

Enterprisesaas-18.3pos_appointmentMEDIUM

Restaurant reservations now display the number of guests entered during booking instead of showing zero or defaulting to table capacity. This helps staff see accurate party sizes and manage seating more reliably.

Original PR description

Currently when making an appointment for x amount of people, inside the restaurant it will show 0 as the number of people who booked.

Steps to reproduce:
-------------------
* Activate booking on the restaurant
* Open the booking preview
* Place a reservation for 5 people
* In the restaurant and remove default filter
> Observation: It shows 0p on the reservation

Why the fix:
------------
By having a default value on the field is would not trigger the compute unless a change was made on `resource_ids` after the create was over.

After fixing this bug we also aboserve that if we make a reservation for 1 person but all the tables in the restaurant are 4 person seatings, the reservation will show 4p.

The reservation should in priority depend on the number entered while booking otherwise we can compute it regarding the resources.

opw-4882681

#appointments#restaurant#reservations#capacity

[FIX] account_asset: consider imported depreciated amount

PR #90214

Enterprisesaas-18.3account_assetl10n_in_assetMEDIUM

When companies migrate assets from another accounting system, Odoo now includes depreciation that already happened before migration in asset totals and reports. This prevents understated cumulative depreciation and gives finance teams a more accurate depreciation schedule after switching to Odoo.

Original PR description

Working:-
-  When migrating from any other accounting software to Odoo,in
  `Depreciated Amount(already_depreciated_amount_import)` field we put asset's
   depreciated amount till then(before migration). This depreciation is recorded
   in each account when starting in Odoo(the original balances) and in Odoo
   creating Journal Entries are skipped for this imported depreciated amount.

Example:-
- Consider Asset with Original Value: \$10,000.00, Acquisition Date: 01/01/2020,
  Method: Straight Line, Duration: 10 Years, Computation: No Prorata.
- Now according to our computation this asset will depreciate \$1000.00 for the
  years 2020 to 2029 each, and Journal Entries would be created on 31st December
  each year.
- Now someone migrating from other software to Odoo in the year 2025 will put
  Depreciated Amount: \$5,000.00 .
- Now Odoo will create Journal Entries for only years 2025 to 2029 and skip
  creating Journal Entries for the years 2020 to 2024 as these entries are
  created in previous accounting package and are recorded in original balances
  while migrating.

Before this commit:-
- In Depreciation Board, Cumulative Depreciation starts from \$1,000.00 for the
  year 2025 and goes till \$5,000.00 for the year 2029, ignoring imported
  depreciated amount.
- Depreciation Schedule report displays constant \$5,000.00 as depreciated value
  for the years 2020 to 2024.

After this commit:-
- In Depreciation Board, imported depreciated amount is added in Cumulative
  Depreciation, so it starts from \$6,000.00 for the year 2025 and goes till
  \$10,000.00 for the year 2029.
- In Depreciation Schedule Report, `_simulate_imported_depreciation` method will
  modify report values to simulated imported depreciation amount and skipped
  Journal Entries.

task-4864528

Forward-Port-Of: odoo/enterprise#90052
Forward-Port-Of: odoo/enterprise#88127

#assets#depreciation#migration#accounting

[FIX] l10n_hk_hr_payroll: hsbc autopay rounding issue

PR #90215

Enterprisesaas-18.3l10n_hk_hr_payrolltest_l10n_hk_hr_payroll_account

This fixes rare cases where Hong Kong payroll payslip amounts did not match the amounts exported in HSBC autopay files. The change aligns rounding behavior so payment files better reflect payroll records, reducing reconciliation issues.

Original PR description

Explanation:
In some rare cases, the autopay amount in payslip and the amount in hsbc autopay file doesn't match. This is due to hsbc autopay files are trimming all the decimal places, and the amount in payslip are rounded.

Forward-Port-Of: odoo/enterprise#89118

#payroll#hong-kong#hsbc#autopay#rounding

[FIX] l10n_pe_edi_pos: add method to check if order is invoiced

PR #90148

Enterprisesaas-18.3l10n_pe_edi_posMEDIUM

Fixes an issue where refunding an invoiced point-of-sale order in Peru skipped the required reason dialog and sent users back to the order screen. The change ensures the system correctly recognizes invoiced orders, helping staff follow the proper refund flow.

Original PR description

Steps to reproduce - install `l10n_pe_edi_pos` module - open a pos session - create a order, when checking out, tick `invoice` checkbox - pay and complete the order - go to order menu (present in…

Steps to reproduce
- install `l10n_pe_edi_pos` module
- open a pos session
- create a order, when checking out, tick `invoice` checkbox
- pay and complete the order
- go to order menu (present in navbar)
- select the previously completed order, apply for refund Observation: you are navigated to Order screen
Expectation: A dialog for reason should be open first

Issue
- after this commit odoo/odoo@3a09ea7 and odoo/enterprise@e3e84bb account_move field is used instead of `invoiced` state of order. But the `account_move` field is always undefined.
This is due to fact that when pos_order is fulfilled from `syncAllOrders` function, a call to `missingRecursive` is made, as `account.move` model is never
 loaded, it is unable to link it to appropriate model and results to undefined

Fix
- use `order.raw.account_move` instead of `order.account_move`

Note:
`account.move` is loaded from saas-18.3 by https://github.com/odoo/odoo/pull/201528

opw-4744785

Forward-Port-Of: odoo/enterprise#87283

#pos#refund#invoicing#peru

Steps to reproduce: - With an MX Company setup - Set USD rate to 20.4277 - Create an invoice as follows: - line 1: price_unit 93.76, quantity 172, tax 16% - line 2: price_unit 74.18, quantity 161, tax 16% - line 3: price_unit 74.18, quantity 162, tax 16% - line 4: price_unit 93.76, quantity 384, tax 16% - line 5: price_unit 111.28, quantity 178, tax 16% - Confirm and send CFDI - Register full payment in USD - Send Payment CFDI Issue: Payment validation will fail with error > Code : 301 > Message : Error en complemento Recepción de Pagos. [Error #CRP20204] El > Valor del campo TotalTrasladosBaseIVA16 no es igual al redondeo de la > Suma del resultado de multiplicar cada uno de los importes de los > Atributos BaseP de los impuestos trasladados registrados en el elemento > TrasladoP donde los atributos contengan en ImpuestoP el valor IVA, en > TipoFactorP el valor Tasa y en TasaOCuotaP el valor 0.160000, por el > Valor registrado en el atributo TipoCambioP de cada nodo Pago. Folio: 2. > Serie: PBNK1/2025/. El atributo "Totales:TotalTrasladosBaseIVA16" > Contiene el valor "95898.54" sin embargo se calculó que la sumatoria > Debe contener el valor "95898.45". opw-4750981 Forward-Port-Of: odoo/enterprise#89817 Forward-Port-Of: odoo/enterprise#88952

Currently when making an appointment for x amount of people, inside the restaurant it will show 0 as the number of people who booked. Steps to reproduce: ------------------- * Activate booking on the restaurant * Open the booking preview * Place a reservation for 5 people * In the restaurant and remove default filter > Observation: It shows 0p on the reservation Why the fix: ------------ By having a default value on the field is would not trigger the compute unless a change was made on `resource_ids` after the create was over. After fixing this bug we also aboserve that if we make a reservation for 1 person but all the tables in the restaurant are 4 person seatings, the reservation will show 4p. The reservation should in priority depend on the number entered while booking otherwise we can compute it regarding the resources. opw-4882681

Working:- - When migrating from any other accounting software to Odoo,in `Depreciated Amount(already_depreciated_amount_import)` field we put asset's depreciated amount till then(before migration). This depreciation is recorded in each account when starting in Odoo(the original balances) and in Odoo creating Journal Entries are skipped for this imported depreciated amount. Example:- - Consider Asset with Original Value: \$10,000.00, Acquisition Date: 01/01/2020, Method: Straight Line, Duration: 10 Years, Computation: No Prorata. - Now according to our computation this asset will depreciate \$1000.00 for the years 2020 to 2029 each, and Journal Entries would be created on 31st December each year. - Now someone migrating from other software to Odoo in the year 2025 will put Depreciated Amount: \$5,000.00 . - Now Odoo will create Journal Entries for only years 2025 to 2029 and skip creating Journal Entries for the years 2020 to 2024 as these entries are created in previous accounting package and are recorded in original balances while migrating. Before this commit:- - In Depreciation Board, Cumulative Depreciation starts from \$1,000.00 for the year 2025 and goes till \$5,000.00 for the year 2029, ignoring imported depreciated amount. - Depreciation Schedule report displays constant \$5,000.00 as depreciated value for the years 2020 to 2024. After this commit:- - In Depreciation Board, imported depreciated amount is added in Cumulative Depreciation, so it starts from \$6,000.00 for the year 2025 and goes till \$10,000.00 for the year 2029. - In Depreciation Schedule Report, `_simulate_imported_depreciation` method will modify report values to simulated imported depreciation amount and skipped Journal Entries. task-4864528 Forward-Port-Of: odoo/enterprise#90052 Forward-Port-Of: odoo/enterprise#88127

Explanation: In some rare cases, the autopay amount in payslip and the amount in hsbc autopay file doesn't match. This is due to hsbc autopay files are trimming all the decimal places, and the amount in payslip are rounded. Forward-Port-Of: odoo/enterprise#89118

Steps to reproduce - install `l10n_pe_edi_pos` module - open a pos session - create a order, when checking out, tick `invoice` checkbox - pay and complete the order - go to order menu (present in navbar) - select the previously completed order, apply for refund Observation: you are navigated to Order screen Expectation: A dialog for reason should be open first Issue - after this commit odoo/odoo@3a09ea7 and odoo/enterprise@e3e84bb account_move field is used instead of `invoiced` state of order. But the `account_move` field is always undefined. This is due to fact that when pos_order is fulfilled from `syncAllOrders` function, a call to `missingRecursive` is made, as `account.move` model is never loaded, it is unable to link it to appropriate model and results to undefined Fix - use `order.raw.account_move` instead of `order.account_move` Note: `account.move` is loaded from saas-18.3 by https://github.com/odoo/odoo/pull/201528 opw-4744785 Forward-Port-Of: odoo/enterprise#87283