Thursday, August 14, 2025
27 changes · saas-18.4
Enhancements to existing features
This update adds Mexican 16% withholding tax options with new split distributions, along with the related accounts and fiscal positions needed to apply them correctly. It also improves rounding precision for existing 10.67% taxes, helping accounting calculations better match required tax handling.
Original PR description
Add few 16% taxes with special distribution (1/3 - 2/3 and 1/4 - 3/4). Also add few accounts and a new fiscal position for each new tax. Also adjust the rounding precision of 10.67% taxes. Linked:https://github.com/odoo/enterprise/pull/83582 task-4571928 Forward-Port-Of: odoo/odoo#222930 Forward-Port-Of: odoo/odoo#206406
This update adds new Mexican 16% withholding tax configurations with supported split distributions, along with the related accounts and fiscal positions. It also improves rounding precision for existing 10.67% taxes, helping invoices and payments align more accurately with local tax requirements.
Original PR description
Add few 16% taxes with special distribution (1/3 - 2/3 and 1/4 - 3/4). Also add few accounts and a new fiscal position for each new tax. Also adjust the rounding precision of 10.67% taxes. Linked:https://github.com/odoo/odoo/pull/206406 task-4571928 Forward-Port-Of: odoo/enterprise#92347 Forward-Port-Of: odoo/enterprise#83582
Belgian payroll users can now access employee-related payroll actions directly from employee records. This makes it quicker to change working schedules and index contracts without navigating elsewhere.
Original PR description
Added the working schedule change server action to form view of employee, and added index contracts server action to list and form view of employee. Task ID: 4900046
Mexican electronic invoicing now warns users before sending an invoice when the customer is missing required country or ZIP information and the invoice is not marked as CFDI to Public. This helps prevent sending issues and prompts users to correct or intentionally override the default behavior.
Original PR description
Adding a warning and a check to account.move.send constraints for trying to send an invoice for a customer that doesn't have either country or ZIP specified, when 'CFDI to Public' is set to False (requires user action to override default behavior). task-4963869 Forward-Port-Of: odoo/enterprise#91655
The UAE payroll end-of-service report now calculates worked years based on the full period an employee has been with the company, rather than only counting actual worked days. This helps produce more complete and consistent service duration figures for end-of-service calculations and reporting.
Original PR description
- update the calculation for the worked years in the end of service report to return the whole duration worked with the comapny not just the actual worked days. Task: 4703337 Forward-Port-Of: odoo/enterprise#92234 Forward-Port-Of: odoo/enterprise#84223
Resolved issues and error corrections
This fix makes Veri*Factu actions in Spanish POS orders match what the system can legally and practically process. It hides sending where unsupported, allows sending after session closure when needed, and prevents Veri*Factu cancellation of POS orders so users handle corrections through refunds instead.
Original PR description
- The "Send Veri*Factu" button is currently also visible for registered orders (but we can not send documents for such orders anyway; we do not support subsanacion) - We do not allow generating Veri\*Factu documents for posted orders. That makes it impossible to (Veri\*Factu) send orders after the session is closed. - We should not allow to Veri*Factu cancel orders. They would still be included in the closing move. The user should create refund instead. task-None Forward-Port-Of: odoo/odoo#222927 Forward-Port-Of: odoo/odoo#222668
Company enrichment now uses standard industry codes instead of internal database IDs when sharing Dun & Bradstreet industry information. This avoids errors when a customer has changed or deleted local industry records, making partner autocomplete more reliable.
Original PR description
Ticket #4992568 highlighted a weird way of sending the industry from IAP to the Odoo client. Before this commit, we were sending the IAP psql id of the industry to the client. There, it would be use as is. It works because these industries haven't been changed in years and they're created in the same order. However the ticket highlighted the fact that a user can edit/delete/create its own industries, therefore some ids that exist on IAP might not exist on the client's Odoo instance. This resulted in a traceback on the client's side. With this commit, we now send the industry code (the ISIC: International Standard Industrial Classification) instead to the client. There it can correctly be mapped if it exists on the client's DB (e.g. not deleted) opw-4992568 https://github.com/odoo/iap-apps/pull/1152 Forward-Port-Of: odoo/odoo#222486
Purchase orders created from make-to-order sales no longer incorrectly use the customer's delivery address as if they were dropshipped. This prevents misleading addresses on RFQs and purchase documents, helping vendors receive the right purchasing information.
Original PR description
Issue ----- POs created by a SO through the MTO route have the customer address set as if being dropshipped. Steps to reproduce ----- - Enable routes in settings - Unarchive the MTO route - Create a…
Issue ----- POs created by a SO through the MTO route have the customer address set as if being dropshipped. Steps to reproduce ----- - Enable routes in settings - Unarchive the MTO route - Create a product "Prod" - Select both buy and MTO routes - Add a vendor line - Create a SO for "Prod" - Confirm the SO - Go to the linked PO When printing the RFQ, the address field is that of the customer as if the PO was a dropshipped one Cause ----- 564b909 introduced an override of `_compute_dest_address_id` to update the delivery address of dropshipped purchases upon change of the SOL's `partner_shipping_id`. The problem is that the field having a value means it is a dropshipped purchase https://github.com/odoo/odoo/blob/35be5c9edf637fb813025f6817c16a9f50475fa8/addons/purchase/models/purchase_order.py#L89-L91 However, here, the value is set as long as the PO is linked to a SO, even if there was none to begin with. We can make sure that the field was already set via the vals when creating the PO, and that we just want to update it because the depends triggered the compute. ----- Ticket: opw-4925962 Forward-Port-Of: odoo/odoo#220581
This fix improves how website and editor background effects handle rounded corners, so visual layers align more reliably without needing manual editor updates. It also corrects a number input edge case that could accidentally apply borders when whitespace was entered instead of a value.
Original PR description
This commit aims to replace https://github.com/odoo/odoo/commit/4d9f6f664e84216ed505c4b860f8ac9f210ca4fb by using CSS to calculate the inner radius of the background layer instead of JS task-3358501
When a cashier enters a product barcode manually, the point of sale now recognizes the exact product variant and applies the right attribute choices automatically. This removes an unnecessary selection step, reducing checkout friction for products that cannot be scanned.
Original PR description
Before this commit, when a user manually entered a product barcode in the search bar, and the product had multiple attributes and values, the configuration popup required the user to manually select the correct attribute values—even though the barcode uniquely identified the product variant. This slowed down the selling process and caused unnecessary friction. With this commit, when a product is found via its barcode (including manual entry), the configuration popup is automatically preset to the correct attribute values associated with that barcode. This improves the user experience and speeds up sales, especially for products whose barcodes cannot be scanned and must be entered manually. opw-4635497 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222047 Forward-Port-Of: odoo/odoo#207086
This fixes an issue in Point of Sale where products with restricted attribute combinations could get stuck in the configurator, preventing cashiers from choosing a valid option. The configurator now lets users change selections freely and only disables adding the product when the current combination is invalid, reducing checkout friction.
Original PR description
If you setup the attribute exclusion on a product template with 2 attribute, so that only 2 valid combinations are possible, you would not be able to select the second attribute value in the product…
If you setup the attribute exclusion on a product template with 2 attribute, so that only 2 valid combinations are possible, you would not be able to select the second attribute value in the product configurator popup. Steps to reproduce: ------------------- * Create 2 attributes with 2 values each A1V1 A1V2 and A2V1 A2V2 * Create a product template with these attributes and set the attribute exclusion so that only 2 valid combinations are possible. * Open PoS and try to add the product to the cart. * The configurator popup will appear. > Observation: You will not be able to change the selection because the other combinations are not correct. Why the fix: ------------ Instead of blocking the selection of wrong combinations, we disable the add button when the current selection is not valid. This allows the user to change the selection of the attributes without being blocked by the exclusion rules. opw-4825451 Forward-Port-Of: odoo/odoo#222511 Forward-Port-Of: odoo/odoo#219688
Fixes a rounding issue where manually adjusted tax amounts on Portuguese vendor bills could make the displayed untaxed total differ from the accounting entries. This keeps tax totals and bookkeeping values aligned, reducing confusion during invoice review and accounting checks.
Original PR description
Create a vendor bill with a base of 123 and 23% tax. => untaxed_amount = 123 & amount_tax = 28.29 Edit the tax amount to be 28.30 => The tax totals shows an untaxed_amount of 122.99 but the accounting entries say 123.0 This is because during the rounding, since the tax computation is custom in Portugal, we subtract the tax amount from the total amount to get the expected base amount. Since the total is not updated according the tax lines, the base amount takes the difference instead of the total. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222836 Forward-Port-Of: odoo/odoo#220635
Activity date filters now focus on the current user's own next activity deadline instead of mixing in deadlines from other users on the same record. This makes late, today, and future activity views match what users expect from their activity counts and reduces confusing duplicate or misleading results.
Original PR description
Partially revert [1] as users expect to see the deadline of their next activity, matching the count displayed in the systray menu. Currently clicking "future activities" for example will show you all records with *any* future activity so long as the next one is yours. Even if yours is actually late. The mistake seems to be that "my activities" + "next date deadline < X" is equivalent to "my next date deadline < X". But this is not the case as just because the most late activity is not yours does not mean you do not have any late activity. As the more common use case is to view your own activities, that should be what the filter shows. Users may create their own filters to find records based on the next overall deadline. As such the filters are reverted to their previous expression. And the "my activities" filter is not selected by default. [1]: 5c5fbc10b7024c7227f03e37897d421bba64df82 task-4988330 Forward-Port-Of: odoo/odoo#222767
The invoice sending process now ignores invoices that are no longer posted and clears outdated sending information when an invoice is returned to draft. This prevents failed background sending jobs when users cancel or edit invoices before they are sent.
Original PR description
This commit makes the asynchronous invoice sending process more robust. Previously, the `_cron_account_move_send` method would fail if it encountered an invoice that was not in a 'posted' state. This…
This commit makes the asynchronous invoice sending process more robust. Previously, the `_cron_account_move_send` method would fail if it encountered an invoice that was not in a 'posted' state. This could happen if a user changed the state of an invoice back to 'draft' or 'canceled' after it was selected for sending but before the cron job ran. To fix this, we added an extra condition to the search domain, so that only posted invoices are accounted for. We also added an explicit reset of `sending_data` in the draft button method, so that setting a posted invoiced back to draft does not retain (outdated) sending data. Steps to reproduce: 1. Select posted invoices and send. 2. Before cron runs, set one invoice to 'draft'. 3. Manually run the cron job `_cron_account_move_send`. 4. Observe the traceback. FW 18.4: * adapted just the domain given refactor * adapted audit trail test. There seems to be a side effect of the `self.sending_data = False` on how the tracked values get triggered. But from a business logic side, the extra message was actually redundant, since the inform `"Updated\nTrue ⇨ False (Reviewed)"` was already included in a previous audit trail. So we remove that message in the expected list. OPW-4985528 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222278
Employees with flexible working hours will no longer have leave deducted when requesting time off on a company public holiday. This prevents incorrect leave balances and ensures holiday rules are applied consistently for flexible schedules.
Original PR description
**Steps to reproduce:** 1) Create a flexible working schedule. 2) Assign this schedule to an employee. 3) Create a public holiday. 4) Create a leave request for the flexible employee on the public…
**Steps to reproduce:** 1) Create a flexible working schedule. 2) Assign this schedule to an employee. 3) Create a public holiday. 4) Create a leave request for the flexible employee on the public holiday. 5) Notice that the duration of the leave is 1 instead of 0. **Issue:** Due to recent changes in the [commit](https://github.com/odoo/odoo/commit/a826f65c2d95b796f919023d560ec9f0801090d8#diff-38469def2f870bb866f971f57797dd7c21b6a95d52a8eae72f832f0eea2434f9R427-R433) , When a single-day flexible leave is taken, the duration is always set to the real duration. However, we do not check if the leave falls on a public holiday, which results in the leave being set to 1 day, even on holidays. https://github.com/odoo/odoo/blob/8f24da78f60529ea0b1840e48de30e15d17ddb77/addons/hr_holidays/models/hr_leave.py#L427-L433 **For example:** If Christmas is marked as a public holiday and an employee with a flexible schedule requests a one-day leave on Christmas, the leave is recorded with a duration of 1 day. **Fix:** Check for a public holiday on leave date; if yes, set leave duration to 0. opw-4963122 Forward-Port-Of: odoo/odoo#222542 Forward-Port-Of: odoo/odoo#220288
Internal users without administrator rights can now send Spanish Facturae invoices without seeing an access error. This keeps invoice delivery working for regular accounting staff while preserving the existing certificate handling approach.
Original PR description
Non-admin users were hitting an “Access Error” when sending an invoice in facturae format, the onchange reads `company.l10n_es_edi_facturae_certificate_ids`, which reads certificate.certificate…
Non-admin users were hitting an “Access Error” when sending an invoice in facturae format, the onchange reads `company.l10n_es_edi_facturae_certificate_ids`, which reads certificate.certificate records , resulting in an “Access Error” popup. This changes Wrap the certificate lookup in company.sudo(). It's handled the same in https://github.com/odoo/odoo/blob/18.0/addons/l10n_es_edi_facturae/models/account_move.py#L140 https://github.com/odoo/odoo/blob/18.0/addons/l10n_es_edi_facturae/models/account_move.py#L770 install l10n_es_edi_facturae Go to Contacts and create an new contact with Spain as country in the same page (creating contact page) click on Accounting scroll down and set eInvoice format as facturaE Go to Accountant and create an invoice with that client pay the invoice log out and log in with a user with no administration (e.g. Marc demo) try to send the create invoice OPW:4989007 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222207
Odoo now shows a clear user-facing error when a document numbering sequence contains an invalid placeholder in its prefix or suffix. This prevents confusing system errors when creating records such as sales orders and helps users correct the sequence configuration faster.
Original PR description
Currently, an error is raised when a sequence is generated with an invalid legend in the prefix or suffix. **Steps to reproduce:** - Install Sales module. - Update the sale order sequence prefix to S%(days)s. - Create a new sale order. **Error:** `KeyError - 'days'` **Cause:** An error occurs when the user provides an invalid suffix in `ir_sequence` and the system tries to generate that sequence at [1]. [1] - https://github.com/odoo/odoo/blob/18da9b6dfc9dc376700cd948a09ae201bf897990/odoo/addons/base/models/ir_sequence.py#L235-L236 **Fix:** To resolve the issue, raise a user error for an invalid sequence. **Ref:** https://github.com/odoo/odoo/commit/18cac1caa21149d70009aa50f3e90dfbc18456a3 Sentry - 6684586181 Forward-Port-Of: odoo/odoo#222727 Forward-Port-Of: odoo/odoo#217142
This fixes an issue where users on iPhone or iPad could lose Chinese, Japanese, or other composed text when typing in Odoo search fields. The search suggestions now wait until text composition is complete, making search usable again for affected language keyboards on iOS.
Original PR description
Problem: When using Chinese or Japanese keyboards (IME - Input Method Editor) on iOS devices, typed characters vanish immediately after pressing Enter or selecting a character suggestion. This makes…
Problem: When using Chinese or Japanese keyboards (IME - Input Method Editor) on iOS devices, typed characters vanish immediately after pressing Enter or selecting a character suggestion. This makes it impossible for users to input text in these languages on iOS devices (iPhone/iPad). This regression was introduced between versions 18.0 and 18.2 when the search bar was modified to automatically open the suggestion dropdown during typing. Purpose: This commit fixes the IME input issue by preventing the suggestion dropdown from opening while the user is composing text with an IME. Opening the dropdown during IME composition disrupts the input process on iOS Safari, causing the composed text to disappear. The fix ensures that the dropdown only opens after IME composition is complete, allowing Chinese, Japanese, and other IME-based language users to properly input text on iOS devices. Steps to Reproduce on Runbot: 1. Access Odoo instance (version 18.2) on an iOS device (iPhone or iPad) 2. Switch keyboard to Chinese (Pinyin) or Japanese (Romaji) input method 3. Click on the search bar in any view (e.g., Customers, Sales Orders) 4. Type characters that require IME conversion: -For Chinese: type "ni" (for 你) -For Japanese: type "ka" (for か) 5. When the IME suggestion appears, press Enter or tap the suggested character 6. Bug: The text vanishes instead of being inserted into the search field Current behavior before PR: The character disappears immediately after selection Desired behavior after PR is merged: The selected character should be inserted into the search field Notes: -This issue only affects iOS devices (Safari/WebKit) due to how they handle DOM manipulation during IME composition events -The issue does not occur on Android devices or desktop browsers -The fix checks the `isComposing` property of the input event to avoid opening the dropdown during IME composition -No test added as IME input behavior is difficult to simulate in automated tests 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#222151
The Live Chat dashboard now responds correctly when users change its filters. This ensures managers and support teams see accurate, filtered dashboard data for chat performance and activity.
Original PR description
This commit fixes the "Live Chat" dashboard which does not update when changing some of its filters. It happens because the filters were not linked to the spreadsheet pivots/charts. 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
Website event visitors can now move between pages or search results without losing selected event filters. This keeps browsing results consistent and helps users find relevant events more easily.
Original PR description
**Issue**:
In the event page on the website, filters are lost when changing pages.
**Steps to reproduce**:
- Ensure enough events exist with multiple type for a category and sufficient quantity (e.g., 24 per type)
- Go to the website app > events:
- Filter events by a type
- Click "Next page" or perform a search
- The filter is lost
**Cause**:
Commit [7b188cf](https://github.com/odoo/odoo/commit/7b188cfedcdd14d2eef12da54084e46f81221350) introduced slug-based filtering. However, the implementation was not fully complete: the slug_tags were not retained in the `url_args` of the pager. As a result, when changing pages, the generated URLs lacked the necessary slug information, causing filters to be lost and search results to reset unexpectedly.
**Solution**:
Hardcode the slug_tags directly into the URL. This way, the slug_tags are preserved without modifying the XML files.
opw-4887189
Forward-Port-Of: odoo/odoo#217874This fixes an error that could stop invoice PDFs from printing when online payment QR codes were enabled. Customers can now generate invoices with QR payment links normally after creating invoices from sales orders.
Original PR description
### Issue When "Add QR-code link on PDF" is enabled, printing an invoice in a regular Sales → Accounting flow raises an error. The report printing process internally calls…
### Issue
When "Add QR-code link on PDF" is enabled, printing an invoice in a regular Sales → Accounting flow raises an error.
The report printing process internally calls
`_generate_portal_payment_qr`, which creates a `payment.link.wizard` record. This model overrides `default_get` and reads `self.env.context.get('active_model')`.
At that moment, the context still contains `'sale.advance.payment.inv'`, a model that does not implement `_get_default_payment_link_values`. This causes:
AttributeError: 'sale.advance.payment.inv' object has no attribute '_get_default_payment_link_values'
#### Affected versions
- saas-18.3 and later
### Steps to reproduce
1. Install `account_accountant`, `sale_management`
2. Go to Settings
3. Enable "Invoice Online Payment" and "Add QR-code link on PDF"
4. Go to Sales → Quotations
5. Create any quotation
6. Confirm quotation
7. Create invoice (full)
8. Confirm invoice
9. Click "Print"
#### Current behavior
- Error is raised
#### Expected behavior
- Invoice prints with QR code without error
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#222448Activity deadline filters now focus on the current user's own next activity deadline instead of mixing in deadlines from other users on the same record. This makes late, today, and future activity views match the counts users see in the activity menu and reduces confusion across apps.
Original PR description
Partially revert [1] as users expect to see the deadline of their next activity, matching the count displayed in the systray menu. Currently clicking "late activities" for example will show you all records with *any* late activity, instead of records where you personally have late activities. As the more common use case is to view your own activities, that should be what the filter shows. Users may create their own filters to find records based on the next overall deadline. [1]: ad95d7d42f195527bbaccdf349da8316e9c9df12 task-4988330 Forward-Port-Of: odoo/enterprise#92282
German EC Sales List CSV exports now include the required version information expected by the Elster portal. This prevents valid reports from being rejected during upload and helps users submit German tax reporting files successfully.
Original PR description
When uploading the EC Sales List csv to Elster.de portal, users will see the file rejected with the following error (EN translated) """ Your CSV file was created for an older version of the CSV interface. Please refer to the version table in the import help for the latest version of the interface and any changes. If the version information is correct, please check the encoding of your CSV file. The permitted encoding is UTF-8. """ This occurs because the csv is missing the version strings identifying the versions of data format References: https://www.elster.de/eportal/helpGlobal?themaGlobal=zmdo_import_eop https://www.datev-community.de/t5/Betriebliches-Rechnungswesen/Import-CSV-Daten-nacvh-Elster-f%C3%BCr-ZM/td-p/480079 opw-4850314 Forward-Port-Of: odoo/enterprise#92110
The Spanish SME Balance Sheet no longer counts certain group-company account balances twice. This ensures reported investment and liability figures match the actual account balances, improving accuracy for Spanish financial reporting.
Original PR description
Issue: - Amounts were exactly doubled in 'Current Investments in Group Companies and Associates' in the Spanish Balance Sheet - SMEs report as account codes 5523 and 5524 were incorrectly added to…
Issue: - Amounts were exactly doubled in 'Current Investments in Group Companies and Associates' in the Spanish Balance Sheet - SMEs report as account codes 5523 and 5524 were incorrectly added to multiple balance sheet sections Root Cause: - Account codes 5523% and 5524% were included in BOTH: 1. 12400 (Assets): 'Current investments in group companies' 2. 32400 (Liabilities): 'Group companies current liabilities' - This double-counting caused investment amounts to appear twice in the balance sheet How to Reproduce: 1. with Spain - SMEs Fiscal Localization's Package 2. Go to Accounting -> Configuration -> Journal -> Bank 3. Change suspense account to code 5523X or 5524X (should be added to chart of accounts before) 4. Post journal entries to accounts 55230X or 55240X 5. Generate 'Balance Sheet - SMEs (ES)' report 6. Observe amounts are exactly doubled compared to account balances Fix: - Removed duplicate account codes from balance_pymes_line_12400_sub_balances - These accounts are properly handled by the domain formula in line 32400 - Each account code now appears in only one balance sheet section" opw-4983300 Forward-Port-Of: odoo/enterprise#92210
This fix prevents receipt demand quantities from being inflated when warehouse users partially process lot-tracked products in the Barcode app and return later to complete them. It keeps inventory receipts accurate by correctly combining related backorder lines when leaving barcode workflows, including batch picking scenarios.
Original PR description
### Steps to reproduce: - Create a storable product tracked by lot - Create and confirm a receipt for 10 units of that product - Go to the barcode app and regiter 1 unit - Exit the picking - Go back…
### Steps to reproduce: - Create a storable product tracked by lot - Create and confirm a receipt for 10 units of that product - Go to the barcode app and regiter 1 unit - Exit the picking - Go back to the picking register the 9 remaining units - Exit the picking and comeback #### > The demand of the receipt has been updated from 10 to 19. ### Cause of the issue: Exiting the picking will launch a call of the `post_barcode_process` in order to keep track of the changes you made without changing the initial demand: https://github.com/odoo/enterprise/blob/c26c21cec14a234021bb13bbc2684334bc64b70b/stock_barcode/models/stock_move.py#L50-L53 THe first time you enter the picking you have a single move with a quantity of 10. The first time you exit, since you have set a qty_done of 1 (and hence have updated the quantity of the associated move to 1), the `split_uncompleted_moves` will then create a move for a quantity of 9 in order to keep 10 units assigned. The second time you enter the picking both moves are grouped in a single line since the product is tracked by lot, however, when you update the qty_done of that grouped line you will actually only update the quantity of the first move line and its related move. Since the `_truncate_overreserved_moves` was not designed to handle these grouped lines, it does not notice that the combined reservation overcomes the actual demand. opw-4731803 Forward-Port-Of: odoo/enterprise#90586 Forward-Port-Of: odoo/enterprise#89967
Swiss payroll declarations now show which required information is missing and which employees are affected before users send or print them. This helps payroll teams correct issues more easily and reduces failed or incomplete declarations.
Original PR description
It is currently complicated for non trained users to figure out what is missing before sending or printing a declaration. In this PR we extend the warning mechanism to declarations to visualize what information is missing on what employees. Forward-Port-Of: odoo/enterprise#92083 Forward-Port-Of: odoo/enterprise#86195
This fixes an error that could block customers from adding a new address during checkout on Colombian eCommerce websites. The address form now works correctly regardless of how the identification type field is displayed, helping customers complete purchases without interruption.
Original PR description
To reproduce: ============= 1- Install Colombia accounting 2- Install eCommerce 3- Set company address to Colombia 4- Go to website and add item to cart 5- Checkout & click "Add new address" →…
To reproduce: ============= 1- Install Colombia accounting 2- Install eCommerce 3- Set company address to Colombia 4- Go to website and add item to cart 5- Checkout & click "Add new address" → Traceback occurs Problem & Solution: =================== The field l10n_latam_identification_type_id is always present in the address form but its HTML element changes: it's rendered as a `select` when is_commercial_address and can_edit_vat is true, and as an `input` otherwise. The JS code only looked for the `select`, so when the `input` was rendered instead, the selector was null and caused a traceback. Update the selector to look for the field in either `select` or `input` form, so the code works regardless of the rendering conditions. useful-links: https://github.com/odoo/odoo/blob/4806b08dcfc965cdbd463269be078f8da9f48863/addons/l10n_latam_base/views/portal_address_templates.xml#L10-L11 https://github.com/odoo/odoo/blob/4806b08dcfc965cdbd463269be078f8da9f48863/addons/l10n_latam_base/views/portal_address_templates.xml#L32-L33 opw-4969089 Forward-Port-Of: odoo/enterprise#91695