Odoo Changelog — 2026-03-18

Wednesday, March 18, 2026

6 changes · 19.0

Bug Fixes(6)

Resolved issues and error corrections

[FIX] l10n_co_dian: prevents original document to be unlinked

Enterprise19.0l10n_co_dianMEDIUM

This update corrects a bug in the DIAN invoice processing workflow. Previously, the system incorrectly deleted the original invoice document, potentially leading to data loss. The fix ensures the correct invoice document is protected, preventing accidental deletion during the update process.

Original PR description

**PROBLEM**
In some configurations, `_l10n_co_dian_cron_update_event_status()` would delete the original document of the invoice.

**CAUSE**
The logic that tried to exclude the original document from the code that unlinks duplicated documents is wrong.
It protect the oldest document of `self` instead of `move`. So the document of the move we are currently working on is not protected, and could be deleted.

**STEP TO REPRODUCE**
1. Setup DIAN.
2. Create multiples invoices and send them to DIAN.
3. Run _l10n_co_dian_cron_update_event_status()
If the original document of the invoice have the same commercial_status as some other document, it could be destroyed.

opw-5447147

#DIAN#invoice#accounting

[FIX] hr_work_entry_attendance: handle timezone overlaps in overtime intervals

PR #109419

Enterprise19.0hrMEDIUM

This update resolves issues where overtime calculations were incorrect due to timezone discrepancies, leading to crashes and orphaned overtime records. The fix ensures accurate overtime intervals are generated and handled, regardless of the employee's location, improving data integrity and reliability.

Original PR description

Steps to reproduce (singleton crash): Create an employee in a UTC+ timezone (e.g. Asia/Shanghai or Australia/Adelaide) with an overtime ruleset containing a paid rule. Generate work entries for a…

Steps to reproduce (singleton crash):

Create an employee in a UTC+ timezone (e.g. Asia/Shanghai or Australia/Adelaide) with an overtime ruleset containing a paid rule. Generate work entries for a period, then create two consecutive midnight-to-midnight attendances in the employee's local timezone. Creating the second attendance crashes with: "ValueError: Expected singleton: hr.attendance.overtime.line(...)".

Steps to reproduce (stale overtime lines):

With the same setup, delete the attendance after it generated overtime lines. The overtime lines remain in the database instead of being removed.

The singleton crash occurred because `end_of_day` in `_get_overtime_intervals` was computed as a naive datetime, implicitly treated as UTC. For UTC+ timezones, the actual local end of day is earlier than UTC midnight. As a result, overtime intervals were computed with a stop time extending past the real local midnight into UTC time. When consecutive attendances were processed together, these extended intervals overlapped. The `Intervals` class (`keep_distinct=True`) merges overlapping intervals into a single entry with a multi-record recordset as payload. The subsequent `overtime.rule_ids.work_entry_type_id` and `overtime.status` calls expected a singleton but received a multi-record set, causing the crash. The same multi-record issue also affected the iteration in `_set_real_overtime_intervals` and the overtime work entry loop in `_get_attendance_intervals`.

The stale overtime lines issue occurred because `_get_overtimes_to_update_domain` (hr_attendance) built its search date range from raw UTC `.date()` values instead of the employee's local timezone. For UTC+ employees whose attendance spans local midnight, the overtime line is dated in the next local calendar day. Since the domain was derived from UTC dates, that next local day fell outside the search range, so the overtime line was never found and deleted when the attendance was removed.

Solution:
- In `_get_overtime_intervals`, localize `end_of_day` to the employee's timezone before converting to UTC, so overtime intervals are correctly bounded by the local end of day.
- In `_set_real_overtime_intervals` and the overtime loop in `_get_attendance_intervals`, iterate over individual records from potentially multi-record `Intervals` payloads to avoid singleton errors.
- In `_get_overtimes_to_update_domain` (hr_attendance), localize check_in/check_out to the employee's timezone before computing the date range so overtime lines for dates that only exist in local time are correctly included in the delete-and-recreate cycle.

opw-5931665

#overtime#timezone#payroll#hr

[FIX] ai_website_livechat: make ai snippet edition match real visual

PR #109569

Enterprise19.0ai_website_livechatMEDIUM

This update corrects a visual discrepancy between how the AI livechat snippet is displayed in the editor and how it appears to users. The issue stemmed from mismatched code structures, leading to inconsistent rendering. This fix ensures the AI livechat snippet displays correctly across different devices and configurations.

Original PR description

Scenario:

- add ai livechat snippet block
- switch to mobile
- enable "Fallback Button"
- save

Result: the rendering is different between edition and real usage of AI
livechat snippet.

Cause: structure and classes don't match

Fix: make the structure and classes match.

opw-5458575

pr note: I copied `ai_website_livechat.AILivechatComponent` in `ai_website_livechat.s_ai_livechat_edit` but it might make more sense to just render the owl widget with a class that neuter the AI (this way we don't need to update both template at each change)

#livechat#ai#UI#rendering

[FIX] l10n_us_payment_nacha: prioritize account holder name in NACHA file

PR #108756

Enterprise19.0l10n_us_payment_nachaMEDIUM

This update ensures that NACHA payment files accurately reflect the actual account holder's name, rather than the customer's name in Odoo. Prioritizing the bank account holder's name improves payment processing accuracy and compliance with NACHA regulations.

Original PR description

The NACHA entry detail was using the partner's name (res.partner.name) for the Individual Name field. This should instead prioritize the Account Holder Name (acc_holder_name) from the bank account, as this reflects the actual name on the bank account which may differ from the partner's name in Odoo.

The code now uses bank.acc_holder_name if set, and falls back to payment.partner_id.name if not set.

Forward-Port-Of: odoo/enterprise#108414
Forward-Port-Of: odoo/enterprise#105582

#payments#NACHA#bank account

[IMP] hr_expense_stripe: Make PIN visible for virtual card

PR #107231

Enterprise19.0hr_expense_stripeMEDIUM

This update ensures that the PIN code is now displayed for both physical and virtual expense cards. Previously, users were blocked from completing transactions using virtual cards (via digital wallets) because they couldn't access the necessary PIN information. This change improves the user experience and ensures seamless payment processing.

Original PR description

Before this commit:
- Currently, we show the PIN code for physical expense cards only, not for virtual cards. 
- In some case transactions are made via virtual cards (through digital wallets) also requires a PIN. The users will be blocked because they currently can't access this information.

After this commit:
- Now we show the PIN code for both physical and virtual cards.

task-5926462

#expense#virtual card#payment

[FIX] l10n_ar_edi: return the correct ARCA code when final consumer

PR #106881

Enterprise19.0l10n_ar_ediMEDIUM

This update resolves a validation error with the ARCA system (used for Argentinian tax compliance) when processing invoices for 'Final Consumers' without VAT/CUIT numbers. The system now correctly sends a 'null' value for the invoice number, aligning with ARCA's requirements and preventing invoice rejection.

Original PR description

**Description of the issue/feature this PR addresses:** This PR fixes a validation error (Code 10015) returned by ARCA (formerly AFIP) when attempting to validate invoices for "Final Consumers"…

**Description of the issue/feature this PR addresses:**
This PR fixes a validation error (Code 10015) returned by ARCA (formerly AFIP) when attempting to validate invoices for "Final Consumers" (Consumidor Final) who do not have a VAT/CUIT number assigned. The system currently defaults the DocNro field to 0, which is rejected by the fiscal authority's web service.

**Current behavior before PR:**
When a contact is marked as "Final Consumer" but lacks a specific ID number (VAT/CUIT), the integration sends DocNro: 0 to ARCA. This triggers Error 10015, as "0" is not considered a valid identification number for this responsibility type, leading to a blocked invoice.

**Desired behavior after PR is merged:**
For contacts meeting these conditions (Final Consumer without a defined ID), the system will now automatically categorize the transaction as "sigd" (System Identified/Global Data) instead of a standard Final Consumer. By doing this, the DocNro is sent as None (or null), which is the legally accepted format by ARCA for these specific cases, successfully bypassing the validation error.

#ARCA#VAT#CUIT#Argentina#Tax Compliance

**PROBLEM** In some configurations, `_l10n_co_dian_cron_update_event_status()` would delete the original document of the invoice. **CAUSE** The logic that tried to exclude the original document from the code that unlinks duplicated documents is wrong. It protect the oldest document of `self` instead of `move`. So the document of the move we are currently working on is not protected, and could be deleted. **STEP TO REPRODUCE** 1. Setup DIAN. 2. Create multiples invoices and send them to DIAN. 3. Run _l10n_co_dian_cron_update_event_status() If the original document of the invoice have the same commercial_status as some other document, it could be destroyed. opw-5447147

Steps to reproduce (singleton crash): Create an employee in a UTC+ timezone (e.g. Asia/Shanghai or Australia/Adelaide) with an overtime ruleset containing a paid rule. Generate work entries for a period, then create two consecutive midnight-to-midnight attendances in the employee's local timezone. Creating the second attendance crashes with: "ValueError: Expected singleton: hr.attendance.overtime.line(...)". Steps to reproduce (stale overtime lines): With the same setup, delete the attendance after it generated overtime lines. The overtime lines remain in the database instead of being removed. The singleton crash occurred because `end_of_day` in `_get_overtime_intervals` was computed as a naive datetime, implicitly treated as UTC. For UTC+ timezones, the actual local end of day is earlier than UTC midnight. As a result, overtime intervals were computed with a stop time extending past the real local midnight into UTC time. When consecutive attendances were processed together, these extended intervals overlapped. The `Intervals` class (`keep_distinct=True`) merges overlapping intervals into a single entry with a multi-record recordset as payload. The subsequent `overtime.rule_ids.work_entry_type_id` and `overtime.status` calls expected a singleton but received a multi-record set, causing the crash. The same multi-record issue also affected the iteration in `_set_real_overtime_intervals` and the overtime work entry loop in `_get_attendance_intervals`. The stale overtime lines issue occurred because `_get_overtimes_to_update_domain` (hr_attendance) built its search date range from raw UTC `.date()` values instead of the employee's local timezone. For UTC+ employees whose attendance spans local midnight, the overtime line is dated in the next local calendar day. Since the domain was derived from UTC dates, that next local day fell outside the search range, so the overtime line was never found and deleted when the attendance was removed. Solution: - In `_get_overtime_intervals`, localize `end_of_day` to the employee's timezone before converting to UTC, so overtime intervals are correctly bounded by the local end of day. - In `_set_real_overtime_intervals` and the overtime loop in `_get_attendance_intervals`, iterate over individual records from potentially multi-record `Intervals` payloads to avoid singleton errors. - In `_get_overtimes_to_update_domain` (hr_attendance), localize check_in/check_out to the employee's timezone before computing the date range so overtime lines for dates that only exist in local time are correctly included in the delete-and-recreate cycle. opw-5931665

Scenario: - add ai livechat snippet block - switch to mobile - enable "Fallback Button" - save Result: the rendering is different between edition and real usage of AI livechat snippet. Cause: structure and classes don't match Fix: make the structure and classes match. opw-5458575 pr note: I copied `ai_website_livechat.AILivechatComponent` in `ai_website_livechat.s_ai_livechat_edit` but it might make more sense to just render the owl widget with a class that neuter the AI (this way we don't need to update both template at each change)

The NACHA entry detail was using the partner's name (res.partner.name) for the Individual Name field. This should instead prioritize the Account Holder Name (acc_holder_name) from the bank account, as this reflects the actual name on the bank account which may differ from the partner's name in Odoo. The code now uses bank.acc_holder_name if set, and falls back to payment.partner_id.name if not set. Forward-Port-Of: odoo/enterprise#108414 Forward-Port-Of: odoo/enterprise#105582

Before this commit: - Currently, we show the PIN code for physical expense cards only, not for virtual cards. - In some case transactions are made via virtual cards (through digital wallets) also requires a PIN. The users will be blocked because they currently can't access this information. After this commit: - Now we show the PIN code for both physical and virtual cards. task-5926462

**Description of the issue/feature this PR addresses:** This PR fixes a validation error (Code 10015) returned by ARCA (formerly AFIP) when attempting to validate invoices for "Final Consumers" (Consumidor Final) who do not have a VAT/CUIT number assigned. The system currently defaults the DocNro field to 0, which is rejected by the fiscal authority's web service. **Current behavior before PR:** When a contact is marked as "Final Consumer" but lacks a specific ID number (VAT/CUIT), the integration sends DocNro: 0 to ARCA. This triggers Error 10015, as "0" is not considered a valid identification number for this responsibility type, leading to a blocked invoice. **Desired behavior after PR is merged:** For contacts meeting these conditions (Final Consumer without a defined ID), the system will now automatically categorize the transaction as "sigd" (System Identified/Global Data) instead of a standard Final Consumer. By doing this, the DocNro is sent as None (or null), which is the legally accepted format by ARCA for these specific cases, successfully bypassing the validation error.