Tuesday, June 10, 2025
30 changes · 18.0
Resolved issues and error corrections
This fix lets users update the customer or vendor linked to already reconciled accounting entries, matching what is allowed during the initial reconciliation. It removes an unnecessary restriction so accounting teams can correct partner information without being blocked by reconciliation status.
Original PR description
This has been allowed since saas-12.5, https://github.com/odoo/odoo/commit/6b8acd025758b042cca39508bc8994a1307d1ccd, and is still currently allowed when making a new reconciliation: you can indeed select 2 aml with different partners. But for some reason, in https://github.com/odoo/odoo/commit/1b30777ab63998d1c0b64b655e717d74b3648bcf, we added a restriction to disallow changing that afterwards. All things considered, the change of partner on reconciled entries should be allowed since it's a non-relevant point when reconciling items together. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Sales orders for services that create projects now include the project account within each analytic distribution line instead of adding it as a separate line. This keeps cost and revenue allocation consistent with configured distribution models and avoids duplicate or misleading analytic entries.
Original PR description
1. Have sales and project installed 2. Create a service product which creates a project on order 3. Set up a distribution model for this service 4. Create a sales order with this service. Confirm it. 5. The project account is added to the analytic distribution in a separate line In odoo/odoo#199763, `_compute_analytic_distribution()` in the SO line was changed to add both project account and ditribution model accounts in the analytic distribution. However, the project account should not have its own line and should instead be added to all lines coming from Analytical Distribution Models. no-task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change fixes an unreliable automated test in the HTML editor image cropper area. It helps keep validation runs stable so future updates can be checked with fewer false failures.
Original PR description
After merging this commit [1], the test sometimes non-deterministically fails on runbot. This PR aims to fix the test. [1]: https://github.com/odoo/odoo/commit/1a2c3c00869fd9702bb9d15e3d38d9c02a3349f5 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update improves the reliability of automated checks for the HTML editor by waiting for on-screen elements to finish appearing or disappearing before validating them. It helps prevent false test failures in slower environments, supporting smoother development and release validation without changing user-facing features.
Original PR description
### Purpose of this PR: - Add `expectElementCount` test helper to wait for elements to appear or disappear before asserting their count. This fixes flaky tests caused by timing issues and animations, especially on slower environments like runbot, in toolbar, link popover, powerbox, tablepicker, tablemenu, and emoji picker tests. task-4849995 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When customers upgrade to Odoo 18, the newly added Create Bill matching rule will now include the proper translation instead of appearing only in English. This improves consistency for users working in other languages, such as Spanish.
Original PR description
If customers migrate to version 18 from a lower version, 'Create Bill' record newly introduced so it just create but not translated. **Before fix:** ``` test_18=# select id,name from…
If customers migrate to version 18 from a lower version, 'Create Bill' record newly introduced so it just create but not translated.
**Before fix:**
```
test_18=# select id,name from account_reconcile_model;
id | name
----+----------------------------------------------------------------------------------------------------------------------------
3 | {"en_US": "Line with Bank Fees", "es_AR": "Línea con comisiones bancarias"}
1 | {"en_US": "Invoices/Bills Perfect Match", "es_AR": "Coincidencia perfecta de facturas"}
2 | {"en_US": "Invoices/Bills Partial Match if Underpaid", "es_AR": "Coincidencia parcial si hay pagos parciales en facturas"}
4 | {"en_US": "Create Bill"}
5 | {"en_US": "Internal Transfers", "es_AR": "Transferencias internas"}
```
**After Fix:**
```
test_18=# select id,name from account_reconcile_model;
id | name
----+----------------------------------------------------------------------------------------------------------------------------
1 | {"en_US": "Invoices/Bills Perfect Match", "es_AR": "Coincidencia perfecta de facturas"}
2 | {"en_US": "Invoices/Bills Partial Match if Underpaid", "es_AR": "Coincidencia parcial si hay pagos parciales en facturas"}
5 | {"en_US": "Internal Transfers", "es_AR": "Transferencias internas"}
3 | {"en_US": "Line with Bank Fees", "es_AR": "Línea con comisiones bancarias"}
4 | {"en_US": "Create Bill", "es_AR": "Crear factura"}
```
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-prThis change removes an extra click in an automated test for boolean fields in list views, preventing random failures caused by the value being toggled twice. It improves reliability of the testing process without changing how users interact with Odoo.
Original PR description
This commit fixes a test involving a boolean property field in list view that randomly fails. The problem was that we clicked twice to toggle the boolean value: once on the cell (I assume that it was done to switch the row in edition), and one on the checkbox to toggle it. However, boolean fields in list views don't require the row to be in edition to be toggled. So the first click already toggled the value, and the second click toggled it again, **sometimes** (I guess that's the non deterministic part, it was a question of timing there). So this commit fixes the issue by removing one of the 2 clicks. runbot error~224053 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
This fixes an unreliable automated test for web navigation behavior. It helps keep quality checks stable by making sure the test waits for the page routing state before simulating browser back navigation.
Original PR description
This commit fixes an action service concurrency test that fails randomly. The way the test was written was prone to errors as we didn't wait for the router to be updated before doing browser back. As a matter of fact, we even asserted that we went 2 actions back in the breadcrumbs, whereas it should be only one as we did one browser.history.back(). runbot error~163078 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
This fix prevents the point of sale numpad from briefly appearing and disappearing when users tap the Old unit price text on combo product order lines. It improves the checkout experience for French certified POS sessions by avoiding confusing screen behavior during order editing.
Original PR description
Steps: ------ - Install `l10n_fr_pos_cert` - Open a PoS session, and add a combo product, orderlines corresponding to the combo procuts will be added - Hide the numpad by clicking on the selected…
Steps: ------ - Install `l10n_fr_pos_cert` - Open a PoS session, and add a combo product, orderlines corresponding to the combo procuts will be added - Hide the numpad by clicking on the selected orderline. - Choose a random orderline, and click on the text "Old unit price" -> Observe that the numpad will appear and then disappear immediately. Reason: ------- When clicking the text "Old unit price", two click events are dispatched, those running the click handler twice, the first time it selects the orderline and hence show the numpad, and the second time, it unselects that same orderline, hiding the numpad. Fix: ---- We disable the pointer-events on the "Old unit price" text, making it unclickable, more precisely, preventing it from being a `target` of a click event. With that change, the click handler (aka `clickLink` [1]) will only run once. [1]: https://github.com/odoo/odoo/blob/8fb7e5fd304697aebcce085602a5f3a1ecaf757a/addons/point_of_sale/static/src/app/screens/product_screen/order_summary/order_summary.xml#L9 opw-4636261
HR managers can now choose Employee-specific assignment options, such as Coach or Manager, while creating a new activity plan before it is saved. This removes an extra save-and-reopen step and makes activity plan setup more consistent and efficient.
Original PR description
_Description of the issue/feature this PR addresses:_ When setting up a new activity template on a new activity plan, HR specific values for 'Assignment' such as Coach or Manager are not available.…
_Description of the issue/feature this PR addresses:_ When setting up a new activity template on a new activity plan, HR specific values for 'Assignment' such as Coach or Manager are not available. _Current behavior before PR:_ As an HR manager, go to menu HR -> Configuration -> Activity Plan. Click 'New'. Under Activities To Create, click 'Add a line'. Under 'Assignment', the only options available are Ask at launch and Default user. <img src="https://github.com/user-attachments/assets/97be6790-b450-42c6-910a-07483c30e175" width=50% height=50%> Cancel the 'Create Activities' popup. Give the plan a name and save it. Again, under Activities To Create, click 'Add a line'. Only now are HR specific options (Coach, Manager etc) available under 'Assignment'. _Desired behavior after PR is merged:_ HR specific values for 'Assignment' are immediately availalbe when setting up a new plan for the Employee model.  _Technical solution:_ Pass the plan's model as the default model for new templates so that the related field is populated with a value that unlocks the HR specific values before first saving the plan. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Subscription renewals will no longer add invoice lines for recurring items with an ordered quantity of zero. This avoids unnecessary or confusing invoice entries and keeps customer invoices cleaner.
Original PR description
Before this commit, when a recurring order_line had an invoice_policy "order" and the quantity was 0, it would be added to the invoice. taskid: 4841550
Delivery status buttons and switches in Point of Sale delivery views now align better on smaller screens. This makes mobile use clearer and easier for staff managing delivery orders.
Original PR description
Before this commit: === - The delivery status buttons (New, Ongoing, Done) and the toggle Switches were misaligned on smaller screens due to the use of grid layout, After this commit: === - The layout uses a flex-based structure, which ensures better alignment and spacing across screen sizes. Task: 4844890
The EC Sales List now avoids incorrectly warning about duplicate VAT numbers when a partner has both invoices and refunds in the same reporting period. This helps users trust the report warnings and reduces unnecessary investigation of valid customer records.
Original PR description
Fixed the computation of `is_vat_duplicated` to avoid false positive in case of partners having both invoices and refunds in the selected period.
This fix prevents an error that could occur when a user opened an app through the command palette and immediately typed into the search field. It improves reliability of navigation in the Enterprise web interface and avoids an unexpected interruption for users.
Original PR description
Before this commit a traceback was occurring when opening an app using palette and then immediately passing a value in palette search input. After this commit the traceback will not occur anymore. task-4735048
Restaurant staff now keep the relevant order selected after accepting it or marking it as food ready in UrbanPiper POS. This reduces extra clicks and helps teams continue processing online orders without losing context.
Original PR description
Before this commit: === - After accepting an order or marking it as "Food Ready," no order was selected by default. After this commit: === - After accepting an order or marking it as "Food Ready," the respective order is automatically selected by default. task-4442911
Documentation and clarification updates
This pull request records Matias Gibbons' signed Contributor License Agreement. It helps ensure contributions can be accepted under Odoo's legal contribution process, with no effect on product features or users.
Original PR description
Contributor License Agreement for Matias Gibbons I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
Because the `location.assign` method also triggers a `beforeunload` event, the `error_service` doesn't handle errors when downloading a file with the action target `download` (for example download vCard). See [1] for more details about the original fix. task-4457865 [1]: https://github.com/odoo/odoo/commit/e96d3aa6d9181d83e34cefd9fe205f37df2e317c --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213103 Forward-Port-Of:
Original PR description
Because the `location.assign` method also triggers a `beforeunload` event, the `error_service` doesn't handle errors when downloading a file with the action target `download` (for example download vCard). See [1] for more details about the original fix. task-4457865 [1]: https://github.com/odoo/odoo/commit/e96d3aa6d9181d83e34cefd9fe205f37df2e317c --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213103 Forward-Port-Of: odoo/odoo#212432
Issue: The BuyerReference field in Xrechnung is only mandatory to be filled with the appropriate company reference for DE B2G invoices, but not having the company reference resuts in the field being absent entirely from the document for B2C and B2B invoices, which results in the document being rejected. Solution: If the BuyerReference is not filled, it is set to 'N/A' instead of being left absent from the document. Addresses ticket-4715709 task-4756812 --- I confirm I have signed the CL
Original PR description
Issue: The BuyerReference field in Xrechnung is only mandatory to be filled with the appropriate company reference for DE B2G invoices, but not having the company reference resuts in the field being absent entirely from the document for B2C and B2B invoices, which results in the document being rejected. Solution: If the BuyerReference is not filled, it is set to 'N/A' instead of being left absent from the document. Addresses ticket-4715709 task-4756812 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213152 Forward-Port-Of: odoo/odoo#212535
**Steps to reproduce 1:** - Install l10n_tz_account - Switch to a Tanzanian company (e.g. TZ Company) - Check the taxes **Issue 1:** Each tax has the same tax grids (i.e. same number and same sign) for the invoice section and the refund section, which leads to have the amount of the credit notes being added (instead of subtracted) in the Tax report. **Solution 1:** Invert the sign of the tax grids in the refund section. **Steps to reproduce 2:** - Create an invoice for a Tanzanian
Original PR description
**Steps to reproduce 1:** - Install l10n_tz_account - Switch to a Tanzanian company (e.g. TZ Company) - Check the taxes **Issue 1:** Each tax has the same tax grids (i.e. same number and same sign) for the invoice section and the refund section, which leads to have the amount of the credit notes being added (instead of subtracted) in the Tax report. **Solution 1:** Invert the sign of the tax grids in the refund section. **Steps to reproduce 2:** - Create an invoice for a Tanzanian customer without VAT **Issue 2:** The default fiscal position will be "International", instead of "Domestic". A domestic fiscal position for customer without VAT is missing. **Solution 2:** Add a "Domestic individual" fiscal position that is the same as the "Domestic" one except for the VAT that is not required. opw-4840609 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213107
- Vendor bills with taxes of l10n_es_type == 'sujeto_agricultura' (REAGYP) must be reported with regime code '19', as per TicketBAI specifications. - This fix ensures that such invoices include '19' in `regime_key`, avoiding schema validation errors and ensuring legal compliance. https://www.batuz.eus/fitxategiak/batuz/ticketbai/ticketbaiv1-2-2.xsd OPW-4532600 Forward-Port-Of: odoo/odoo#211229
Original PR description
- Vendor bills with taxes of l10n_es_type == 'sujeto_agricultura' (REAGYP) must be reported with regime code '19', as per TicketBAI specifications. - This fix ensures that such invoices include '19' in `regime_key`, avoiding schema validation errors and ensuring legal compliance. https://www.batuz.eus/fitxategiak/batuz/ticketbai/ticketbaiv1-2-2.xsd OPW-4532600 Forward-Port-Of: odoo/odoo#211229
Fix crash when a retention tax is applied on an invoice that includes a down payment line. Steps to reproduce: 1. Create a retention tax (negative, with retention checked) 2. Create a sale order with product A 3. Create and validate a down payment invoice 4. Create the full invoice and add the retention tax to the line of product A 5. Try to submit to ZATCA This raises: `IndexError: list index out of range → tax_category_vals = self._get_tax_category_list(...)[0]` The issue occur
Original PR description
Fix crash when a retention tax is applied on an invoice that includes a down payment line. Steps to reproduce: 1. Create a retention tax (negative, with retention checked) 2. Create a sale order with product A 3. Create and validate a down payment invoice 4. Create the full invoice and add the retention tax to the line of product A 5. Try to submit to ZATCA This raises: `IndexError: list index out of range → tax_category_vals = self._get_tax_category_list(...)[0]` The issue occurs because the retention tax is not filtered due to a missing `filter_to_apply` parameter. opw-4771567 Forward-Port-Of: odoo/odoo#210567 Forward-Port-Of: odoo/odoo#208946
\*: website_mail This PR addresses several issues in the blog module, including: Commit [1]: retain follow-us input button when logged in - Steps to reproduce: 1. Go to any blog post. 2. Enable the sidebar. 3. Select any category (e.g., Travel). Issue: A subscribe button appears in the 'Follow Us' section. - Solution: Currently, the input field is only shown to public users. This happens because the input element is restricted by the `base.groups_public` group in the XML code. Si
Original PR description
\*: website_mail This PR addresses several issues in the blog module, including: Commit [1]: retain follow-us input button when logged in - Steps to reproduce: 1. Go to any blog post. 2. Enable the…
\*: website_mail This PR addresses several issues in the blog module, including: Commit [1]: retain follow-us input button when logged in - Steps to reproduce: 1. Go to any blog post. 2. Enable the sidebar. 3. Select any category (e.g., Travel). Issue: A subscribe button appears in the 'Follow Us' section. - Solution: Currently, the input field is only shown to public users. This happens because the input element is restricted by the `base.groups_public` group in the XML code. Since this is an XML change in v17.0 (stable version), we need to implement the fix in JS instead. After that, we will adapt the code from the master branch. Commit [2]: remove unnecessary months from blog category - Steps to reproduce: 1. Have a blog post in a category (e.g., Astronomy) published in Feb-2025. 2. In another category (e.g., Travel), have blog posts in both Jan-2025 and Feb-2025. 3. When selecting the Astronomy category, the sidebar `Archives` filter shows all months, even if no blog post exists in Jan 2025. - Solution: It will now show only months that contain blog posts for the selected category. Filter out from the backend according to their publishing date. Commit [3]: correct tag redirection to backend in blog posts - Steps to reproduce: 1. Go to any blog post. 2. Turn on the sidebar. 3. Create a new blog post. 4. Save it. Issue : clicking `add some` on tags redirects to the homepage instead of the backend of that blog post. - Solution: a wrong URL was inserted in the anchor tag. For stable, we changed it from JS, but it will be applied to XML in master. task-4546888 Forward-Port-Of: odoo/odoo#210641 Forward-Port-Of: odoo/odoo#197172
### Reason - In Product module, there are two type of product types : type and detailed_type. While they share similar names, they filter different results. The type field only filters consumables and services, whereas detailed_type have type + more specific categories such as Clothing, Electronics, Furniture,...etc making it more relevant for users. - I suggest change the default filter to detailed_type to avoid confusion. Since users are likely to rely on this filter frequently, it should
Original PR description
### Reason - In Product module, there are two type of product types : type and detailed_type. While they share similar names, they filter different results. The type field only filters consumables…
### Reason - In Product module, there are two type of product types : type and detailed_type. While they share similar names, they filter different results. The type field only filters consumables and services, whereas detailed_type have type + more specific categories such as Clothing, Electronics, Furniture,...etc making it more relevant for users. - I suggest change the default filter to detailed_type to avoid confusion. Since users are likely to rely on this filter frequently, it should be set as the default not type. Description of the issue/feature this PR addresses: Current behavior before PR: -Filter by type:  Desired behavior after PR is merged: -Filter by detailed_type:  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212183
Steps to reproduce: 1.- Install ecommerce. 2.- On the top right we click on edit. 3.- Go to customize > Customers > Rating. 4.- Now go to the bottom of the page and open the ratings. Issue: After the changes done in odoo#121104 we have change a few things, between those things, we are passing the rating stats inside the message when previously we used to add it as another key, also we are computing the same stats for all the messages that we have when we only need it 1 time. Solut
Original PR description
Steps to reproduce: 1.- Install ecommerce. 2.- On the top right we click on edit. 3.- Go to customize > Customers > Rating. 4.- Now go to the bottom of the page and open the ratings. Issue: After the changes done in odoo#121104 we have change a few things, between those things, we are passing the rating stats inside the message when previously we used to add it as another key, also we are computing the same stats for all the messages that we have when we only need it 1 time. Solution: Adapt frontend to properly get the rating_stats and avoid computing them more than what is needed. opw-4155895 Forward-Port-Of: odoo/odoo#183541
The `subscribe to known partner presences` test ensures a bus subscription is sent when a new partner (whose presence needs tracking) is discovered. However, this test is prone to race conditions due to non-deterministic subscription timing: - `addChannels` is debounced and called once at the beginning (for the current user from session data), and again after `init_messaging`. This means the timing of the RPC affects the number of subscriptions: 1 if it's fast enough to fall within the first
Original PR description
The `subscribe to known partner presences` test ensures a bus subscription is sent when a new partner (whose presence needs tracking) is discovered. However, this test is prone to race conditions due…
The `subscribe to known partner presences` test ensures a bus subscription is sent when a new partner (whose presence needs tracking) is discovered. However, this test is prone to race conditions due to non-deterministic subscription timing: - `addChannels` is debounced and called once at the beginning (for the current user from session data), and again after `init_messaging`. This means the timing of the RPC affects the number of subscriptions: 1 if it's fast enough to fall within the first call, or 2 otherwise. - `forceUpdateChannel` is also debounced, so the final subscription depends on how these debounces overlap. Ultimately, the test only aims to verify that discovering a new partner or guest adds their presence to the subscription. Using the full flow introduces unnecessary points of failure. This commit rewrites the test to use `store.insert` instead, giving more control over the flow while preserving the test's intent. fixes runbot-161223,182043,182044 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#212332
**Steps to reproduce:** 1. Accounting > Configuration Menu > Journals 2. Archive a Journals with outgoing payment method 3. Go to Expenses > Configuration Menu 4. Settings > Payment methods Under Accounting 5. Notice that the payment methods from archived journals are still visible **Issue:** - In this commit https://github.com/odoo/odoo/commit/c4f21085f8f77d8786eb1bc9494ae0fc1327b8b8 the overridden action_archived method was removed, which previously prevented journals with link
Original PR description
**Steps to reproduce:** 1. Accounting > Configuration Menu > Journals 2. Archive a Journals with outgoing payment method 3. Go to Expenses > Configuration Menu 4. Settings > Payment methods Under Accounting 5. Notice that the payment methods from archived journals are still visible **Issue:** - In this commit https://github.com/odoo/odoo/commit/c4f21085f8f77d8786eb1bc9494ae0fc1327b8b8 the overridden action_archived method was removed, which previously prevented journals with linked payment methods from being archived. **Solution:** - Update the company_expense_allowed_payment_method_line_ids field's domain field to include only payment methods from active journals opw-4745525 Forward-Port-Of: odoo/odoo#210314
This updates the app information for the Asset Management area. It is a minor housekeeping change that helps keep the module details accurate and consistent, with no expected impact on day-to-day business workflows.
In test_generate_all_export_files, PDF and XLSX reports were not generated due to them timing-out the runbot, which was happening randomly. This has been fixed here by only testing the generation of the data then given to wkhtmltopdf, since wkhtmltopdf is quite slow and can randomly create errors. This is taking about 4 minutes with this fix when all reporting modules are enabled in v17.0 but taking around 20 minutes when creating PDFs. task-3603619 Forward-Port-Of: odoo/enterprise#863
Original PR description
In test_generate_all_export_files, PDF and XLSX reports were not generated due to them timing-out the runbot, which was happening randomly. This has been fixed here by only testing the generation of the data then given to wkhtmltopdf, since wkhtmltopdf is quite slow and can randomly create errors. This is taking about 4 minutes with this fix when all reporting modules are enabled in v17.0 but taking around 20 minutes when creating PDFs. task-3603619 Forward-Port-Of: odoo/enterprise#86307
When the post_invoice_hook failed, and sale_subscription_stock was installed, all subscription invoiced would have a "Delivery creation failed" activity created, even if no delivery needed to be created. This commit filter out the subscriptions without any stock lines that needs the stock rule to be run. OPW-4618930 Forward-Port-Of: odoo/enterprise#85604
Original PR description
When the post_invoice_hook failed, and sale_subscription_stock was installed, all subscription invoiced would have a "Delivery creation failed" activity created, even if no delivery needed to be created. This commit filter out the subscriptions without any stock lines that needs the stock rule to be run. OPW-4618930 Forward-Port-Of: odoo/enterprise#85604
### Steps to reproduce: - Have an overdue invoice - Go to Accounting > Customers > Follow-up Reports and click the partner - Change the state of the report to something different than the first state - Click "Follow-up", select "By post" and send - Settings > technical > Email > Snailmail Letters find the letter corresponding to the report - Check the PDF, it is using the mail template of the first followup level ### Cause: When sending a followup report, the followup level of the repo
Original PR description
### Steps to reproduce: - Have an overdue invoice - Go to Accounting > Customers > Follow-up Reports and click the partner - Change the state of the report to something different than the first state…
### Steps to reproduce: - Have an overdue invoice - Go to Accounting > Customers > Follow-up Reports and click the partner - Change the state of the report to something different than the first state - Click "Follow-up", select "By post" and send - Settings > technical > Email > Snailmail Letters find the letter corresponding to the report - Check the PDF, it is using the mail template of the first followup level ### Cause: When sending a followup report, the followup level of the report is recomputed for it to have the correct value. Then the report is generated. But the option to send a letter uses methods from the module `snailmail` for example `` which don't have options. The options are then recomputed to generate the report, reading [`partner.followup_line_id`](https://github.com/odoo/enterprise/blob/c8dac822cf3df23922488f33c07a114bbea05198/account_followup/models/account_followup_report.py#L42) so getting the wrong value. ### Solution: Add a context key to pass the value of `followup_line` to the report generation after snailmail. opw-4766804 Forward-Port-Of: odoo/enterprise#85717
Currently, the VAT is split into two columns only if the VAT code consists solely of numeric values. However, in practice, VAT code may contain a combination of letters and numbers. **Steps to reproduce :** 1) Install `l10n_de_reports` and switch to the `DE` company 2) Create a partner with VAT as `NL000099998B57` from contacts 3) Now create a confirmed invoice for the above created partner 4) Go to "Accounting / Reporting / Audit Reports / General Ledger" 5) Download "DATEV DATA (Z
Original PR description
Currently, the VAT is split into two columns only if the VAT code consists solely of numeric values. However, in practice, VAT code may contain a combination of letters and numbers. **Steps to…
Currently, the VAT is split into two columns only if the VAT code consists solely of numeric values. However, in practice, VAT code may contain a combination of letters and numbers. **Steps to reproduce :** 1) Install `l10n_de_reports` and switch to the `DE` company 2) Create a partner with VAT as `NL000099998B57` from contacts 3) Now create a confirmed invoice for the above created partner 4) Go to "Accounting / Reporting / Audit Reports / General Ledger" 5) Download "DATEV DATA (ZIP)" and check "EXTF_customer_account.csv" **Issue:** Notice that the VAT was not split into country and VAT code for the above created partner. **Cause:** Previously, the code only split the VAT into country code and VAT code if the first two characters were alphabetic and the remainder was numeric. https://github.com/odoo/enterprise/blob/35944a38d306ea881e08e1d51ca77a3eab3a6e36/l10n_de_reports/models/datev_export_csv.py#L220-L227 This approach is insufficient because many countries have VAT codes that include both letters and numbers. For example vat formats for `NL` and `AT` https://business.gov.nl/finance-and-taxes/vat/numbers-for-vat/ https://ec.europa.eu/taxation_customs/vies/#/faq So by only checking whether the VAT code is numberic is not a valid thing. **Solution:** The code now uses the partner’s `_split_vat` method to separate the country code and VAT code whenever a VAT is provided and has more than two characters. It then validates the split VAT using the `simple_vat_check` helper method. If the VAT is valid, the country code (in uppercase) and the VAT code are output in separate columns; otherwise, the original VAT value is kept. This change ensures that VAT numbers with alphanumeric codes are correctly handled and split into their respective columns. opw-4820929 Forward-Port-Of: odoo/enterprise#87167 Forward-Port-Of: odoo/enterprise#86992