Friday, September 26, 2025
29 changes · 18.0
Enhancements to existing features
This change makes it easier for other Odoo modules to customize how analytic distribution information is prepared for accounting entries. It supports more flexible business-specific rules, such as basing analytic distributions on employee-related data, without changing core accounting behavior.
Original PR description
**Description of the issue/feature this PR addresses:** Add an inherit point to let others modules specify others/new values when the analytic distribution is build on the analytic distribution model. **Functional example:** If you wan to determine your analytic distribution on the employee (so the `employee_id` field is added into `account.analytic.distribution.model`), the specific module can not edit the dict (who is extracted by this PR). So I propose to extract the `dict` creation into a dedicated method. **Current behavior before PR:** It's not possible to edit the `dict` **Desired behavior after PR is merged:** Update the `dict` (and let it as a `frozendict` to use it as a key). ✅ I don't find any duplicates PR --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This fix restores a missing database index used by inventory rules to avoid confusing upgrade messages. It helps keep upgrades cleaner and preserves expected performance for company-related stock rule lookups.
Original PR description
due to conflict on this forward port https://github.com/odoo/odoo/pull/113045 ``index=True`` was removed according to this pr https://github.com/odoo/odoo/pull/90531 So, adding it back during upgrade it shows misleading logs ``` 2025-08-26 22:19:25,039 23 INFO db_3112946 odoo.schema: Keep unexpected index stock_rule_company_id_index on table stock_rule ``` opw-5052223 upg-3112946 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226268
Documentation and clarification updates
This pull request updates the Adhoc corporate contributor license agreement records by adding new members. It is an administrative legal update that helps keep contributor authorization records current and does not affect product functionality.
Original PR description
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226715
This fix prevents product packaging entries from being duplicated when a new product has attributes but only one resulting variant. It keeps product setup cleaner and avoids incorrect duplicate packaging records after saving.
Original PR description
**PROBLEM** When creating a new product, with attributes but only one variant the packaging is duplicated on save. **STEP TO REPRODUCE** 1. Install inventory, go to the settings and enable the product packagings option. 2. Create a new product, with one attribute with one possible value, and with a packaging. 3. save the product and notice the packaging was duplicated. **CAUSE** `packaging_ids` is stored on the product.product model (product variant). `packaging_ids` in the product.template model is a compute field with an inverse. When creating the product, the inverse function is called a first time, creating a first packaging. Later in the product creation, it is called a second time because of a write call on the product.template model, creating a second packaging. **FIX** In the create() and write() of product template, set some value in the context to know if we should create the packaging or not when calling the inverse function. opw-5050592
New users can now load demo data in the Attendance app without hitting an access error. This makes initial setup and evaluation smoother for teams trying the module with non-administrator accounts.
Original PR description
Currently, an error occurs when a new user tries to load demo data in the ``Attendance`` module. Steps to reproduce: --- - Install ``hr_attendance`` module (without demo data) - Create NEW user >…
Currently, an error occurs when a new user tries to load demo data in the ``Attendance`` module.
Steps to reproduce:
---
- Install ``hr_attendance`` module (without demo data)
- Create NEW user > Login with new user
- Open ``Attendance`` and Click ``Load Demo Data``
Traceback:
---
```
AccessError
You are not allowed to create 'Resource Working Time' (resource.calendar) records.
This operation is allowed for the following groups:
- Administration/Settings
Contact your administrator to request access if necessary.
ParseError
while parsing /home/odoo/src/odoo/saas-18.1/addons/hr_attendance/data/scenarios/hr_attendance_scenario.xml:5, somewhere inside <record id="resource_calendar_std_38h" model="resource.calendar" forcecreate="1">
<field name="name">Standard 32 hours/week (4 work days, friday free)</field>
<field name="company_id" eval="False"/>
<field name="hours_per_day">8</field>
<field name="attendance_ids" eval="[(5, 0, 0), (0, 0, {'name': 'Monday Morning', 'dayofweek': '0', 'hour_from': 8, 'hour_to': 12, 'day_period': 'morning'}), (0, 0, {'name': 'Monday Lunch', 'dayofweek': '0', 'hour_from': 12, 'hour_to': 13, 'day_period': 'lunch'}), (0, 0, {'name': 'Monday Afternoon', 'dayofweek': '0', 'hour_from': 13, 'hour_to': 17, 'day_period': 'afternoon'}), (0, 0, {'name': 'Tuesday Morning', 'dayofweek': '1', 'hour_from': 8, 'hour_to': 12, 'day_period': 'morning'}), (0, 0, {'name': 'Tu...
ValueError
ParseError('while parsing /home/odoo/src/odoo/saas-18.1/addons/hr_attendance/data/scenarios/hr_attendance_scenario.xml:5, somewhere inside\n<record id="resource_calendar_std_38h" model="resource.calendar" forcecreate="1">\n <field name="name">Standard 32 hours/week (4 work days, friday free)</field>\n <field name="company_id" eval="False"/>\n <field name="hours_per_day">8</field>\n <field name="attendance_ids" eval="[(5, 0, 0), (0, 0, {\'name\': \'Monday Morning\', \'dayofweek\': \'0\', \'hour_from\': 8, \'hour_to\': 12, \'day_period\': \'morning\'}), (0, 0, {\'name\': \'Monday Lunch\', \'dayofweek\': \'0\', \'hour_from\': 12, \'hour_to\': 13, \'day_period\': \'lunch\'}), (0, 0, {\'name\': \'Monday Afternoon\', \'dayofweek\': \'0\', \'hour_from\': 13, \'hour_to\': 17, \'day_period\': \'afternoon\'}), (0, 0, {\'name\': \'Tuesday Morning\', \'dayofweek\': \'1\', \'hour_from\': 8, \'hour...
```
This error occurs because the new user has not been granted administrative rights.
This commit resolves the issue by granting the user superuser rights.
sentry-6110523247
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prNew users can now load demo data in the Appraisal module without running into an error. This makes it easier for teams to try or evaluate the Appraisal feature in a fresh setup.
Original PR description
Currently, an error occurs when a new user tries to load demo data in the `Appraisal` module. Steps to reproduce: --- - Install `hr_appraisal` module (without demo data) - Create NEW user > Login…
Currently, an error occurs when a new user tries to load demo data in the `Appraisal` module.
Steps to reproduce:
---
- Install `hr_appraisal` module (without demo data)
- Create NEW user > Login with new user
- Open `Appraisal` and Click `Load Demo Data`
Traceback:
---
```py
ParseError: <record id="calendar_event_appraisal_1" model="calendar.event" forcecreate="1">
<field name="user_id" ref="base.user_admin"/>
<field name="name">Appraisal of Emma Granger</field>
<field name="partner_ids" eval="[(6,0,[ref('hr.work_contact_sj'), ref('hr.work_contact_mw'), ref('hr.work_contact_eg')])]"/>
<field name="start" eval="(DateTime.now() + relativedelta(months=1)).strftime('%Y-%m-%d 07:00:00')"/>
<field name="stop" eval="(DateTime.now() + relativedelta(months=1)).strftime('%Y-%m-%d 09:00:00')"/>
<field name="res_model_id" ref="hr_appraisal.model_hr_appraisal"/>
<field name="res_model">hr.appraisal</field>
<field name="res_id" ref="hr_appraisal.hr_appraisal_1"/>
</record>
ValueError: ParseError('while parsing /home/odoo/odoo/enterprise/hr_appraisal/data/scenarios/hr_appraisal_scenario.xml:561, somewhere inside\n<record id="calendar_event_appraisal_1" model="calendar.event" forcecreate="1">\n <field name="user_id" ref="base.user_admin"/>\n <field name="name">Appraisal of Emma Granger</field>\n <field name="partner_ids" eval="[(6,0,[ref(\'hr.work_contact_sj\'), ref(\'hr.work_contact_mw\'), ref(\'hr.work_contact_eg\')])]"/>\n <field name="start" eval="(DateTime.now() + relativedelta(months=1)).strftime(\'%Y-%m-%d 07:00:00\')"/>\n <field name="stop" eval="(DateTime.now() + relativedelta(months=1)).strftime(\'%Y-%m-%d 09:00:00\')"/>\n <field name="res_model_id" ref="hr_appraisal.model_hr_appraisal"/>\n <field name="res_model">hr.appraisal</field>\n <field name="res_id" ref="hr_appraisal.hr_appraisal_1"/>\n </record>') while evaluating
'action = model._load_demo_data()'
```
This error occurs because the new user has not been granted administrative rights.
This commit resolves the issue by granting the user superuser rights.
sentry-6110523247This update corrects automated checks around product barcode lookup so product weight data is properly handled when available. It also fixes test permissions for product variants, helping prevent false failures and improving confidence in barcode lookup reliability.
Original PR description
Before this commit: ------------------------- - The weight and volume fields were not present in the main product form, so we can't set them. - The variant rights were not passed correctly for the first basic test. After this commit: ----------------------- - We have updated the test and checked that weight is correctly set when present in the view. - Now we have passed the correct variant right for the test. Runbot error: https://runbot.odoo.com/odoo/runbot.build.error/231155
This fixes an issue where extremely small manufacturing operation or work order durations could break planning. The change ensures scheduling can continue reliably instead of failing with an error when tiny duration values are encountered.
Original PR description
Operation & Workorder duration is a float with 2 decimal digits to be expressed in minutes, meaning minimal duration is 1sec. However one can encounter numbers like 0.001, 0.00001, ... This can lead to : AttributeError: 'NoneType' object has no attribute 'astimezone' in function _get_first_available_slot task: 5090338 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures timesheet reports correctly include helpdesk ticket information where relevant. It repairs a previous update that did not properly target the report field, helping users see the expected ticket context in exported or printed reports.
Original PR description
Description of the issue/feature this PR addresses: The previous commit attempted to extend the timesheet report to display tickets by using position="attributes" on a new . This approach does not work in Odoo reports because position="attributes" can only modify existing elements. There is no indication that the behavior of not displaying tickets was intentional, so this PR corrects that implementation. Current behavior before PR: The previous fix did not correctly locate the existing element for task/project info. Desired behavior after PR is merged: The existing is correctly found and updated to include show_ticket in its t-if. Forward-Port-Of: odoo/enterprise#95206
Google Calendar account resets now consistently bypass event permission checks where needed. This prevents reset failures caused by validation errors, helping users reconnect or reset calendar sync without disruption.
Original PR description
This commit adds the last context key "skip_event_permission" to the remaining writes done to `calendar.event` records at the reset of google_calendar account, created at odoo/odoo#227991. By adding it, we'll no longer face any possibility of triggering a ValidationError during account resets of google_calendar. task-5103918
Updating a product barcode no longer clears the product's e-commerce description when no new description is available from barcode lookup. This prevents accidental loss of sales content on product pages during routine product maintenance.
Original PR description
**Steps to reproduce:** 1.Install website_sale 2.Create a new product and set an e-commerce description (under the Sales page) 3.Update the barcode (length ≥ 8) in General Information page **Issue:** - The e-commerce description is cleared after updating the barcode. **Cause:** https://github.com/odoo/enterprise/blob/c0c4f5d4b9799fb88d80a6074bb1efb0cb73ccc8/product_barcodelookup/models/product_template.py#L16-L21 - The onchange triggered by barcode updates calls _update_product_by_barcodelookup method, which overrides the product's ecommerce description field even when no barcode_lookup_data and no updated description. https://github.com/odoo/enterprise/blob/233e82cf4e6908502a580be4bcd77fadd2aada53/website_product_barcodelookup/models/product_template.py#L8-L11 **Solution:** - Added a check for update the ecommerce description Only if we receive a description. opw-4813710
This fix ensures that when users add a border to an image in email content, the border remains visible after the email is sent. It improves consistency between the email editor preview and what recipients actually receive.
Original PR description
Problem: When adding a border to an image and sending an email, the border is not visible in the received email. Solution: Ensure a `border-style` is set if missing, otherwise keep the existing one. Steps to reproduce: - Open email marketing. - Add an image snippet. - Add a border to the image. - Send the email. - The received image has no border. opw-5004824 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223867
This fix removes an unnecessary navigation step from an automated Point of Sale test that was causing intermittent database-related failures. It helps keep validation runs stable and reduces false alarms in the development pipeline without changing user-facing behavior.
Original PR description
Before this commit: ================= The `test_draft_pos_order_linked_sale_order` test fails intermittently with a `psycopg2.ProgrammingError: no results to fetch`. This failure occurs when the…
Before this commit:
=================
The `test_draft_pos_order_linked_sale_order` test fails intermittently with a
`psycopg2.ProgrammingError: no results to fetch`. This failure occurs when the
browser tour navigates back to the backend.
After this commit:
=====================
The problematic navigation step is removed from the `PosSettleOrder5` tour,
stabilizing the test and preventing the runbot error.
Cause:
========
The `Chrome.clickMenuOption("Backend", { expectUnloadPage: true })` step
forces an immediate database flush (`self.cr.flush()`) during the test's
authentication phase.
This forced flush happens when the records are in an intermediate state (after
loading the Sale Order but before payment/validation). This specific
intermediate state, combined with the subsequent recomputation of computed
fields (like `qty_delivered` through `sale_mrp` and `sale_margin`), exposes an
underlying bug in Odoo's ORM cursor management, leading to the
`psycopg2.ProgrammingError`.
Since the backend navigation is not necessary for the test's assertion logic,
removing this step prevents the premature flush and resolves the failure.
Runbot Error: 226521
Task: 4974084This fix ensures email signature formatting remains intact when messages are prepared for Outlook. It prevents image sizing and other final style settings from being accidentally merged with Outlook-specific hiding rules, leading to more consistent email appearance.
Original PR description
Problem: `_hideForOutlook` breaks the last style when appending `mso-hide: all;` if the style string does not end with `;`. Example: `width: 100%` → `width: 100% mso-hide: all;` Solution: Ensure the new attribute is appended correctly at the end of the styles, regardless of whether the last style ends with `;`. Note: The problem might be only observed on `18.4` because the composer doesn't use the user signature before `18.4`. Steps to reproduce in 18.4: 1. Open "My Profile". 2. Add an image to "email signature" with reduced scaling (25%, 50%). 3. Open any record with chatter (task, SO, invoice, etc.). 4. Type a message in chatter and click "Send". 5. Click "Open Full Compositor" and send a message from the email compositor. 6. Open the runbot's MailHog and observe the differences between the two emails. opw-5046573 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The web test runner now classifies errors and warnings more accurately depending on when they occur. This helps development teams see important problems without unnecessarily stopping test runs, improving reliability of quality checks.
Original PR description
This commit associates separate "issue levels" to the test runner's internal logger. These affect the logging and reporting of issues, i.e. errors and warnings: - suppressed (by 'test.todo'): issues are traced in the console but not reported in test results; - trace (default in test runs): issues are traced in the console and reported in test results; - global: issues are warned/errored in the console with "HOOT" prefix (i.e. won't interrupt the test run); - critical (default outside of test runs): issues are warned/errored in the console without "HOOT" prefix, thus interrupting the whole test run. This fix should hopefully solve errors that were too quiet before test run, or too "important" during the run. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Changing a website theme color from the color palette and saving no longer triggers an error. This improves reliability for users editing website appearance and prevents disruption during routine design updates.
Original PR description
This PR resolves a traceback that occurred when changing the theme color from the color palette and pressing the save button. This was due to an unhandled promise rejection. task-3919146
Users now see a clear warning instead of an error when opening a product forecast in a company that has no warehouse. This prevents a confusing crash and explains why the forecast cannot be shown until a warehouse exists.
Original PR description
Step to reproduce: - install stock - create a new company and switch to that company - open a storable product - click on forecasted smart button Cause: - StockForecasted component needs at least 1 warehouse, but when we create a new company, it does not have any warehouse https://github.com/odoo/odoo/blob/7747c5810eabe798a1631c3e3b26b81a5c89b4b4/addons/stock/static/src/stock_forecasted/stock_forecasted.js#L49-L52 - clicking on the smart button, raises traceback Fix: - we show a warning when the smart button is clicked and no warehouse is found **Note**: not adding a test case, as issue is not reproducible in test mode due to this https://github.com/odoo/odoo/blob/de264d99c22283390d18beb7c7c62c29824f72b3/addons/stock/models/res_company.py#L197-L198 opw-5059799 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Appointment bookings with custom questions or extra fields now correctly show the generated details in the appointment description field. This restores the expected behavior so staff can see customer-provided information directly on the appointment form.
Original PR description
Steps to reproduce: 1. Create an appointment with 1 question or any additional field. 2. Book the appointment throught the website filling all fields. 3. When checking in the appointment form, the description field is empty (even though the description still exists and it's being generated and sent). After #47471 where we improved the appointment sent descriptions, we also get rid of the way we used to autofill the description field in the appointment form view. This fix is a workaround to keep the same behavior we've had before this will be properly fixed in master. opw-3226882
Changing the color of a blog tag now updates how that tag appears on existing blog posts. This prevents outdated tag colors from remaining visible on the blog page after an administrator makes a configuration change.
Original PR description
Steps to reproduce: - Go to the /blog page - See that some posts use some tags - Go to Configuration > Tags - Change the color of an existing tag - Go back to the /blog page => The color of the tag is not updated for existing posts using it. This is a t-cache issue, which unfortunately is difficult to fix in stable (as it would require modifying multiple nodes in qweb). As a workaround, and knowing that the t-cache system was fully removed in 19.0 at [1], this fixes the bug with a hack: on tag update, make a dummy update to the related blog posts already using it. Tag updates should be quite rare anyway. [1]: https://github.com/odoo/odoo/commit/1cf06a5688e6aa80175d5a28a83b639d0eb925a7 task-4045724
A database query in the timesheet attendance reporting area was corrected so it can properly identify employees during processing. This prevents certain upgrade requests from failing due to a mismatched employee reference.
Original PR description
In the affected query, the variable "employee_id" is undefined in the scope where it is used. This leads postgres to interpret it as a variable with default type VARCHAR and to the impossibility to compare it against an integer. We just qualify the variable name so it now works as expected. Failing upgrade requests: [3103245](https://upgrade.odoo.com/odoo/request/3103245) [3121291](https://upgrade.odoo.com/odoo/request/3121291) Fixes https://github.com/odoo/odoo/pull/192434/commits/c97ecfa7fc091f763329af589b69db2292931163 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225401
Closed self-order point-of-sale sessions now remove their temporary database sequence after use. This helps prevent unnecessary database clutter over time, improving maintainability without changing the cashier or customer experience.
Original PR description
to avoid having too many postgres sequences, this make sure the sequence used by the pos session is cleaned up after being closed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223758
Creating a salesperson from a CRM opportunity no longer copies phone details from the related lead by mistake. This prevents incorrect contact information on salesperson records and reduces manual cleanup for sales teams.
Original PR description
To reproduce: ============= 1- add a lead 2- add a phone and a mobile number 3- convert it to opportunity 4- create salesperson from that view 5- salesperson contains lead number Problem: ========= Before this fix, creating a Salesperson inherited the global context, which included unrelated values as active_model was set to crm.lead. This led to incorrect default values being applied. https://github.com/odoo/odoo/blob/d155edfd729ab9b53f38939fe24b6d1e7b578083/addons/web/models/models.py#L872C13-L872C21 The default values contained the lead phone and lead number and was applied in the creation of salesperson. Solution: ========== Since we have some synchronization of some fields (email, phone) that is automatically done normally, it's reasonable to remove the code and see what it gives. opw-4871069
This fixes a visual flicker in the website editor preview after changing page styling such as boxed layout or background color. The preview now keeps styling consistent during reloads, giving users a smoother and less distracting editing experience.
Original PR description
In this [commit], fallback iframe was added to avoid flickering between iframe reloads. But the flicker still happens if we change page's style, since we do not apply the new styles to the fallback iframe. To reproduce the issue: - Open Website and start editing - Move to the 'Theme' tab - Change page layout to 'Boxed' - Set background color to a non-transparent color, e.g. red - Save, and do any action to reload the iframe, e.g. go to /contactus => The iframe flickers from the previous color to red, which shouldn't be the case. Task-4985472 [commit]: https://github.com/odoo/odoo/commit/7b19831e1c624b483008feb526ba773ec8b23009
A test for selling product kits was updated so it matches the intended setup for invoicing before delivery. This helps keep the sales and manufacturing workflow reliable by ensuring automated checks reflect ordered-quantity invoicing rules.
Original PR description
This change updates the test_sell_kit_invoice_before_delivery test to ensure that kit components and the kit product itself use an invoicing policy of Ordered Quantities rather than the default Delivered Quantities. build_error-232796
Changing a quotation template on a sales order now removes the previously linked quote calculator spreadsheet. This prevents users from seeing calculations from an old template and keeps the sales order aligned with the selected template.
Original PR description
Step to reproduce: - Create a new SO - Add a customer and quotation template to the order - Click on quote calculator smart button - Return to sale order (click on SO number in top left) - Change the quotation template - Result: it does not change the quote calculator that is linked to the new quotation template Cause: - Clicking on Quote Calculator creates a copy of the quotation template spreadsheet and links it to the SO. https://github.com/odoo/enterprise/blob/8bc6098335d283e6d210dc788463a8ef8c559b14/spreadsheet_sale_management/models/sale_order.py#L30-L35 - When the quotation template is later changed, the spreadsheet linked to the old template remains attached to the SO. Fix: - On changing the sale_order_template, the old spreadsheet should be unlinked from the SO. - Keeping it linked is inconsistent, as it does not matches the current template opw-4998587
Event registration confirmation emails now keep QR codes at the correct size and shape, even after the email template is edited and previewed. This prevents distorted QR codes and helps attendees reliably scan their registration details.
Original PR description
### Steps to reproduce: 1. Set up an event registration with atleast 1 attendee. 2. Go to email templates and search for "Event: Registration Confirmation". (or any with QR code in it) 3. Check the preview of the email template. 4. Edit any text inside the template and check the Preview again. (QR code stop taking the proper height) ### Issue: During the rendering of the email template, the QR code image html is changing provoking the QR to not have the proper aspect ratio and look stretched. ### Fix: We can make sure we're always taking the 100% height of the container by adding a style attribute to the image tag, thus not losing the aspect ratio of the QR code. opw-4976893
This fixes a problem where reinstalling the Danish Nemhandel module could leave it broken. Businesses using Danish electronic invoicing can reinstall or recover the module more reliably without disrupting related workflows.
Original PR description
**Description of the issue/feature this PR addresses:** Reinstalling the module breaks it. 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
This update adds checks to ensure India GSTR-1 reporting handles sales under reverse charge and SEZ sales with LUT correctly. It helps reduce compliance reporting risk by validating these specific tax scenarios before they affect business filings.
Original PR description
Adding GSTR1 test case with RCM tax and SEZ (with LUT) see https://github.com/odoo/odoo/pull/213931
Greek customer VAT numbers that start with “EL” are now treated as Greece for validation and exports. This prevents missing country information in accounting export files such as DATEV customer account exports.
Original PR description
**Issue** When a VAT number starts with EL, it is not recognised as a valid country code, and therefore Greece is not properly identified in exports. **Steps to Reproduce** 1. Create a new customer…
**Issue** When a VAT number starts with EL, it is not recognised as a valid country code, and therefore Greece is not properly identified in exports. **Steps to Reproduce** 1. Create a new customer from Greece with VAT number EL033910442 2. Create an invoice for that customer 3. Navigate to Accounting > Reporting > General Ledger 4. Download Datev Data through the gear icon 5. Open EXTF_Customer_accounts.csv 6. Notice that EL was not recognised as the country code **Root Cause** The VAT validation logic `simple_vat_check` first tries to find a country-specific check function `check_vat_EL`, but such a function does not exist. For Greece, the correct function is `check_vat_GR` (since the ISO country code is `GR`). When `EL` is passed directly, no check function is found, validation fails, and the VAT country is left empty. **Fix** Normalize the VAT prefix before validation by mapping EL → GR, ensuring Greek VAT numbers prefixed with EL are validated with the existing check_vat_GR logic. Opw-4982164 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr