Odoo Changelog — 2026-07-08

Wednesday, July 8, 2026

3 changes · 17.0

Bug Fixes(3)

Resolved issues and error corrections

[FIX] l10n_ar_reports: VAT book export for foreign partners

Enterprise17.0l10n_ar_reportsMEDIUM

The Argentine VAT Book ZIP export now handles foreign partners marked as overseas providers without blocking the process. This prevents export errors and helps accounting teams complete VAT reporting for foreign transactions more reliably.

Original PR description

Steps to reproduce:
- Create a partner with:
  - State: Ireland
  - Identification Number: Foreign ID 55000004153
  - ARCA Responsibility Type: Proveedor del Exterior
- Create an invoice for the partner
- Accounting > Reporting > Tax report
- Select Report: VAT Book (AR), Tax Type: Sales
- Click on gear icon > VAT Book (ZIP)

Issue:

Action will be blocked with error "No VAT configured for partner [58] <partner>"

Analysis:

Partners with ARCA responsibility type 'Proveedor del Exterior' (code 8) and a ForeignID identification type, causes a UserError when exporting the VAT Book (ZIP).  Code 8 (foreign provider) is the purchase-side counterpart of code 9 (foreign customer), which already fell back to the country-level VAT.  Extend the existing fallback branch to cover both codes.

opw-6316008

#argentina#vat book#foreign partners#tax reporting

[FIX] hr_holidays: extra accrual on carryover date

PR #245201

Core17.0hr_holidaysMEDIUM

This fix stops annual leave balances from receiving an unexpected extra accrual when carryover is applied. It makes accrual updates follow the intended schedule, so employees and managers see more accurate leave balances and less confusing year-start changes.

Original PR description

## Issue

Currently, an extra accrual happens on carryover date, but it shouldn't. Indeed, accrual only happened at the start - end of a period, or on level transition.

## Reproducing steps

Let's take an accrual plan with a level that adds 2 days/month on the 15th of the month.
The carryover takes place at the beginning of the year.
So we will have this:
- 2025-11-01 -> creation of the allowance, 0 days available
- 2025-11-15 -> 1 day (only 15 days are counted, so only half of the days are added)
- 2025-12-15 -> 3 days (1 full month elapsed)
- 2026-01-01 -> 4 days (as the carryover triggers an accrual) -> this event causes confusion as the accrual seems to “come out of nowhere”
- 2026-01-15 -> 5 days
- 2026-02-15 -> 7 days

task-5432188

#leave#accrual#carryover#hr

[FIX] pos_restaurant: fix runbot 243216

PR #275071

Core17.0pos_restaurantMEDIUM

This update corrects a bug where the restaurant POS system incorrectly returned to a newly created floor after a transaction. The fix ensures the new floor is fully loaded before switching, preventing the system from reverting to the previous state. This improves the overall user experience and reliability of the restaurant ordering process.

Original PR description

Steps were added in the `FloorScreenTour` but after created the new we were switching to fast to another floor, and when the request finished the PoS bring back the new floor just created.

This commit adds a step to ensure the new floor is loaded before switching to another floor.

#POS#Restaurant#UI#Bug Fix

Steps to reproduce: - Create a partner with: - State: Ireland - Identification Number: Foreign ID 55000004153 - ARCA Responsibility Type: Proveedor del Exterior - Create an invoice for the partner - Accounting > Reporting > Tax report - Select Report: VAT Book (AR), Tax Type: Sales - Click on gear icon > VAT Book (ZIP) Issue: Action will be blocked with error "No VAT configured for partner [58] <partner>" Analysis: Partners with ARCA responsibility type 'Proveedor del Exterior' (code 8) and a ForeignID identification type, causes a UserError when exporting the VAT Book (ZIP). Code 8 (foreign provider) is the purchase-side counterpart of code 9 (foreign customer), which already fell back to the country-level VAT. Extend the existing fallback branch to cover both codes. opw-6316008

## Issue Currently, an extra accrual happens on carryover date, but it shouldn't. Indeed, accrual only happened at the start - end of a period, or on level transition. ## Reproducing steps Let's take an accrual plan with a level that adds 2 days/month on the 15th of the month. The carryover takes place at the beginning of the year. So we will have this: - 2025-11-01 -> creation of the allowance, 0 days available - 2025-11-15 -> 1 day (only 15 days are counted, so only half of the days are added) - 2025-12-15 -> 3 days (1 full month elapsed) - 2026-01-01 -> 4 days (as the carryover triggers an accrual) -> this event causes confusion as the accrual seems to “come out of nowhere” - 2026-01-15 -> 5 days - 2026-02-15 -> 7 days task-5432188

Steps were added in the `FloorScreenTour` but after created the new we were switching to fast to another floor, and when the request finished the PoS bring back the new floor just created. This commit adds a step to ensure the new floor is loaded before switching to another floor.