Friday, May 29, 2026
139 changes
1 change
Resolved issues and error corrections
This update fixes a previous issue where payment transaction details weren't consistently saved in Odoo, regardless of whether the payment was triggered by a webhook or polling. The change ensures that all relevant payment information, including card details, is now correctly recorded, improving the accuracy of financial reporting and reconciliation. This resolves a critical data capture problem.
Original PR description
After odoo/odoo#236454, a bug was introduced where the transaction details would only be saved if the payment was resolved via webhook, not via polling. This commit fixes the issue by using the same field names in the webhook payload as is received from the polling endpoint. In addition, the card number and card brand fields are now saved too. opw-6244960 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266788 Forward-Port-Of: odoo/odoo#266629
1 change
Resolved issues and error corrections
This update resolves a problem where the Canadian Localization module was missing essential tax group settings, preventing proper accounting configuration. The fix updates data files and runs a migration script to ensure all necessary tax and account information is correctly populated, improving tax reporting accuracy.
Original PR description
**Steps to reproduce:** * Install the *Canadian Localization* module (*l10n_ca*). * Go to *Accounting* module. * Navigate to *Configuration -> Settings*. * In the *Taxes Configuration* section, click on *Configure Tax Groups*. * Open the tax groups list view and review the available records. **Observed behavior:** * Default tax groups accounts are missing or not visible for taxes, leading to incomplete tax configuration. **Cause:** * The tax and account data files were missing required fields: * *tax_receivable_account_id* * *tax_payable_account_id* * *non_trade* (for accounts) * In *Accounts* , for some places *account_type* was missing * This resulted in improperly configured tax groups and accounts. **Fix:** * Updated CSV data files for tax groups. * Added the missing required fields for taxes and accounts. * Added a migration script to update existing records accordingly. opw-6069621
3 changes
Resolved issues and error corrections
This update resolves an issue where creating a new stock picking type resulted in an error when trying to generate a receipt. The fix disables quick creation of picking types to address a requirement for a unique sequence code, which was previously missing. This ensures smoother operation and prevents the error.
Original PR description
1 change
Resolved issues and error corrections
This update fixes an issue where the pension fund tax was incorrectly applied to all invoice lines with the same VAT rate, leading to inaccurate accounting. The fix now correctly extracts the tax exemption reason from the XML data to ensure the pension fund tax is applied accurately to the first invoice line.
Original PR description
In `l10n_it_edi` vendor bill import, the pension fund tax was incorrectly applied to all invoice lines sharing the same VAT rate, even though they have different `l10n_it_tax_exemption_reason`s, resulting in wrong entries and document total. We now extract the Tax Exemption reason from the `DatiCassaPrevidenziale` node, and use it to search the correct tax. Steps to reproduce: 1. Install `account` and `l10n_edi_it` 2. In the `4% INPS` tax, set `TC22` in pension fund type and `N2.2` in exoneration 3. Import bill from the ticket 4. See the pension fund tax is applied to all the lines. It should only be applied only to the first one. Ticket [link](https://www.odoo.com/odoo/project.task/6212975) opw-6212975 Forward-Port-Of: odoo/odoo#265821
13 changes
New functionality added to Odoo
This update introduces support for Indonesian tax returns within the Odoo Enterprise system. The new module, l10n_id_reports, allows users to generate the necessary reports required for tax compliance in Indonesia. This enhancement improves the system's ability to meet local regulations and reporting needs.
Original PR description
Create new module l10n_id_reports and add return type for Indonesia. task-6239169 Forward-Port-Of: odoo/enterprise#118467 Forward-Port-Of: odoo/enterprise#118304
3 changes
New functionality added to Odoo
This update adds a new report to comply with Vietnamese Accounting Standards (VAS). It ensures the General Ledger accurately reflects counterpart accounts and balances, a key requirement for Vietnamese businesses. A custom SQL query and post-processor are used to handle complex transaction types and maintain report accuracy.
Original PR description
Vietnamese Accounting Standards (VAS) require businesses to generate their General Ledger following a specific format known as Form S03b-DN. A key compliance requirement of this report is the explicit display of the counterpart account for every transaction line, as well as maintaining strictly separated debit and credit balances. To achieve the counterpart mapping, a custom report handler and custom engine are introduced. Because standard journal entries do not strictly bind individual debit and credit lines together, a specialized SQL query was implemented. This query classifies moves by type (1-to-1, 1-to-many, many-to-many, sale/purchase) and uses proportional splitting and label matching to accurately determine the counterpart account for each line. A post-processor is also included to handle uncategorized lines where 1-to-1 matching isn't possible, ensuring the report remains balanced and transparent. task-6092253
3 changes
Resolved issues and error corrections
This update fixes an issue where check amounts weren't being properly rounded when generating the check amount in words for Philippine companies. Previously, the check displayed an incorrect decimal format with 'ONLY' appended. The fix rounds the payment amount to ensure accurate check formatting, improving the user experience for Philippine vendors.
Original PR description
Current behaviour: --- When paying with checks, the amount is not rounded in the check amount in words string. Steps to reproduce: --- 1. Switch to PH company 2. Set setting Check Layout as "Print Check - PH" 3. Create a new vendor bill 4. Add a product with a specific price like 91490.15 5. Confirm the bill, click on Register Payment 6. Select Payment Method "Checks", Create Payment 7. Go to the payment, Amount in Words is wrong 8. Ninety-One Thousand Four Hundred Ninety And 15000000001/100 ONLY Expected behaviour: --- The decimal amount should be rounded, and "ONLY" shouldn't appear. Fix: --- Rounded the pay amount And backported: https://github.com/odoo/enterprise/commit/bb6c9848665709c14c5113b2c98976f869cd473b opw-6058344 Forward-Port-Of: odoo/enterprise#116717
Currently an error occurs when user quick creates a picking type and tries to create a receipt with it. **Steps to replicate:** - Install stock. - Go to Inventory > Receipts and create a new receipt…
Currently an error occurs when user quick creates a picking type and tries to create a receipt with it. **Steps to replicate:** - Install stock. - Go to Inventory > Receipts and create a new receipt > Save it. - Clear the Operation Type field, type `test` and quick create it. - Save and the error will occur. **Error:** ``` UndefinedFunction: operator does not exist: integer = boolean LINE 1: SELECT number_next FROM ir_sequence WHERE id=false FOR UPDAT... ``` **Cause:** - As the user quick created the picking type, the `sequence_code` field was not set and it is a required field [1], when we try to get `next_number` to create the name for the current stock picking this error occurs. - In the versions before `saas-19.1` trying to quick create picking type will lead to a `Not-Null Violation` as `sequence_code` is a required field and then stock picking type form view will open up. - This error occurs only after `saas-19.1` and above versions because this [PR] made the `sequence_code` field into a related field so its required constraint was removed and hence quick create creates a new picking type. **Solution:** - Disabled quick create for stock picking type in multiple views. [1]: https://github.com/odoo/odoo/blob/fe0550ad23ff9128099e7e4994938879a971dcc8/addons/stock/views/stock_picking_type_views.xml#L93 [PR]: https://github.com/odoo/odoo/pull/190305/changes#diff-79cbc763115661182c02285c07320098510f5686700359ddee67443b4893dc30L32-R32 sentry-7203804886 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where global invoices created after a POS order at the end of the month were incorrectly displaying the following month. The fix converts POS order dates to the correct Mexican timezone to ensure accurate invoice month calculations. This ensures invoices reflect the true order date and avoids potential accounting discrepancies.
Original PR description
**PROBLEM** When creating a global invoice, with the last order being at the end of the last day of the month, the month of the global invoice will not be correct. (e.g, order made at the end of May and global invoice created for June). date_order is stored in utc. To compute the day the order was made, we need to convert to a MX timezone. **STEP TO REPRODUCE** 1. Create an pos order at the end of the last day of a month (for example, at 10PM in local MX time). 2. Create a global invoice with this order. 3. Notice the global invoice month will be the month after the one of the order. opw-6221049 Forward-Port-Of: odoo/enterprise#118170
This update resolves a previous issue where payment transaction details weren't consistently saved after payments were processed via polling. The fix ensures that all payment data, including card details, is now captured regardless of the payment method (webhook or polling), improving the reliability of payment records. This enhancement supports accurate financial reporting and reconciliation.
Original PR description
After odoo/odoo#236454, a bug was introduced where the transaction details would only be saved if the payment was resolved via webhook, not via polling. This commit fixes the issue by using the same field names in the webhook payload as is received from the polling endpoint. In addition, the card number and card brand fields are now saved too. opw-6244960 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266788 Forward-Port-Of: odoo/odoo#266629
Enhancements to existing features
This update streamlines the process of generating AI chat channel names, ensuring faster response times for users. By moving channel name coordination to the frontend and optimizing the request flow, the system now prioritizes immediate AI response streaming. This change improves the overall user experience and responsiveness of the AI chat feature.
Original PR description
AI chat responses should start streaming as soon as the user posts a message. Channel name generation must not block the main agent generation. Move channel name coordination to the frontend and split it in two steps: `/ai/compute_channel_name` returns the generated name, then the client writes it to `discuss.channel` once no agent response stream is active. The flow is: first agent response done, channel name request, channel name write. Name request and write (and corresponding retries) are skipped while a stream is active. Once a name has been computed, later turns retry writing that same name instead of generating a new one from the new user message. Furthermore, we don't use the hidden message from any prompt button in the name request. TASK-ID: 6234727
This update simplifies product views for sales users by removing unnecessary information and enhancing clarity. Specifically, the aggregation on product versions has been disabled to prevent misleading totals. This change improves the user experience and provides more accurate data for sales teams.
Original PR description
Simplify product views by hiding non-relevant fields and improving clarity for sales users. - Disable aggregation on version field to avoid misleading totals task-6131606
This update introduces a new report for Hungary, specifically designed to generate the EC Sales list. Unlike the standard report, this version groups sales data by specific tax codes (B, C, K, R & V) instead of just by partner. It also includes the necessary tax return data for this report.
Original PR description
This report is a bit different from the main EC Sales list, instead of just grouping the lines on partner_id, we need to group on specifics tax.tags [B, C, K, R & V]. It also adds the tax returns for this same report. [task-4950959](https://www.odoo.com/odoo/project/967/tasks/4950959) Linked:https://github.com/odoo/odoo/pull/253556 Forward-Port-Of: odoo/enterprise#110448
Resolved issues and error corrections
This update addresses broken templates within the social module following the recent owl3 migration. The migration caused several visual issues and inconsistencies in the social feed display. This fix restores the correct functionality and appearance of the social templates.
Original PR description
Bug === Since the owl3 migration, a lot of templates are broken in social. Task-6241607
This update fixes a problem where tax predictions were incorrectly blocking useful suggestions on invoices. Now, predictions only run when a new description is entered, ensuring accurate suggestions. Additionally, the prediction logic has been simplified and consolidated for better performance and easier future updates.
Original PR description
The confidence threshold (requiring a 10% ranking advantage to confirm a prediction) was a poor proxy for its actual goal: avoiding unwanted overwrites of values the user had already set. It blocked…
The confidence threshold (requiring a 10% ranking advantage to confirm a prediction) was a poor proxy for its actual goal: avoiding unwanted overwrites of values the user had already set. It blocked helpful predictions in ambiguous cases while still allowing unwanted ones. Replace it with a direct check: disable prediction entirely when the line already carried a label before the current edit. This is implemented by overriding `onchange` to inspect the pending form values and inject a context key before `_onchange_name_predictive` fires. Predictions now only run on a blank slate — the first time a description is typed — which is exactly when they are useful. The "anything is better than nothing" philosophy then applies freely, without needing an artificial threshold. At the same time, consolidate all field predictions (account, taxes, product, deductible amount) into a single SQL query via a `_predictive_field_getter` registry, making the feature cheaper to run and straightforward to extend. Note: the previous implementation seeded account predictions with account names from the chart of accounts, improving cold-start accuracy for partners with no history. This is dropped as a trade-off for the simpler design. task-6138749
This update corrects a flaw in the FAIA report generation where a supplier's ID was incorrectly linked to a customer record. This issue arose due to differing criteria used to determine customer vs. supplier status within the accounting system. The fix ensures the FAIA report accurately reflects supplier relationships as defined by the company's financial data.
Original PR description
## Steps to reproduce: 1. Install `l10n_lu_reports`, swap to the LU company 2. Look at the partner Azure Interior. 1. They have no open balances on `asset_receivable` or `liability_payable` accounts.…
## Steps to reproduce:
1. Install `l10n_lu_reports`, swap to the LU company
2. Look at the partner Azure Interior.
1. They have no open balances on `asset_receivable` or `liability_payable` accounts.
2. Their `supplier_count` is higher than their `customer_count`.
3. Navigate to Accounting > Reporting > General Ledger.
4. Select the 2026 fiscal year.
5. Select gear > FAIA report.
6. Open the downloaded file. Notice:
1. Azure Interior is listed under /MasterFiles/Customers/Customer.
2. There are no /MasterFiles/Suppliers.
3. Azure Interior's ID (14 in this case) is referenced in a /SupplierID section.
7. Take a gander at the official XSD for LU [1]. The SupplierID must match an element in /MasterFiles/Suppliers.
Video: [2]
## Explanation
This is one of several errors found with the FAIA export. See PR #113316 for more.
It's possible to have a /SupplierID listed on a /Transaction/Line element but not have a /Suppliers/Supplier element that it refers to. This is not valid according to the FAIA report's schema [1].
This happens because /Transaction/Line and /MasterFiles use different criteria to determine if a partner is a Customer or a Supplier.
The element /Transaction/Line [3] determines this from the `partner_vals['type']` value [4]. This value is 'customer' or 'supplier' and is determined by comparing the ResPartner fields `customer_rank` and `supplier_rank`. In case of a tie, the partner is assigned as a 'supplier'.
The element /MasterFiles allows a partner to be both a Customer and a Supplier via `partner_vals['types']` [5]. Partners with an open `asset_receivable` balance at the start or end of the reporting period are listed as Customers [6]. Likewise, partners with an open `liability_payable` balance are listed as Suppliers [7]. If there are no open balances, partners are put in the Customer list by default.
The XSD validation error will not show up in a standard Runbot database because the namespace for the XSD is incorrect. If you manually fix the XSD namespace (`xmlns:doc` instead of `xmlns`) and use xmllint to check a generated XML against the XSD, it will raise the following error.
> No match found for key-sequence ['14'] of keyref 'RefGLTransactionLineSupplier'. Downloads/general_ledger (5).xml fails to validate
[1] https://pfi.public.lu/dam-assets/backup/FAIA/FAIA/XSD_Files.zip. I will note that there are three XSDs. Version A has a different namespace and appears to be more restrictive. The "full" XSD document does not raise these errors.
[2] https://drive.google.com/file/d/1xeULpCcGgZk-kYcCjBTKxcfv4ICYRzaB/view?usp=sharing
[3] https://github.com/odoo/enterprise/blob/434d88960abb5e424fdc1106fc93935d328bff78/account_saft/data/saft_report.xml#L244-L248
[4] https://github.com/odoo/enterprise/blob/434d88960abb5e424fdc1106fc93935d328bff78/account_saft/models/account_general_ledger.py#L299
[5] https://github.com/odoo/enterprise/blob/434d88960abb5e424fdc1106fc93935d328bff78/account_saft/models/account_general_ledger.py#L303-L309
[6] https://github.com/odoo/enterprise/blob/434d88960abb5e424fdc1106fc93935d328bff78/account_saft/data/saft_report.xml#L153
[7] https://github.com/odoo/enterprise/blob/434d88960abb5e424fdc1106fc93935d328bff78/account_saft/data/saft_report.xml#L173
opw-6107107
Forward-Port-Of: odoo/enterprise#117799This update corrects a rounding error that previously caused the withholding base amount on invoices to exceed the total invoice amount. The fix ensures accurate calculations by limiting the withholding base amount to prevent over-reporting. This improves invoice accuracy and compliance.
Original PR description
**PROBLEM** In some case, because of rounding issues, the withholding base amount can be bigger than the total amount of the invoice, which should not be the case. **STEP TO REPRODUCE** 1. Install…
**PROBLEM** In some case, because of rounding issues, the withholding base amount can be bigger than the total amount of the invoice, which should not be the case. **STEP TO REPRODUCE** 1. Install l10n_pe_edi 2. Create an invoice with those 2 lines: qty: 300, unit_price: 0.481936, tax: VAT 18% + 3% IGV Withholding qty: 300, unit_price: 0.747376, tax: VAT 18% + 3% IGV Withholding 3. Confirm the invoice, and send the xml (if this fail, you may have to change the name of the invoice, using odoo inspector or other means). 4. Open the xml, and notice the base amount for the allowance on the document level is 435.18 which is bigger than the invoice payable amount. **CAUSE** We exclude the withholding taxes to compute the invoice taxInclusiveAmount. When computing this amount, we round the line base and the tax total of the VAT 18% tax leading to the result of 435.17. When creating the allowance node for the Withholding taxes, the base used for the withholding taxes is the sum of the line base, and the tax total of previous tax NOT rounded. There is no easy way to change the withholding tax computation, so we just limit the base to not be bigger than the invoice total when there is rounding issues. opw-6010388 Forward-Port-Of: odoo/enterprise#113689
This update fixes a bug that prevented accurate IT tax closing validation, particularly when dealing with quarterly reporting across year boundaries. The changes ensure correct handling of debit/credit reporting and prevent system errors, leading to more reliable tax calculations.
Original PR description
Description of the issue this commit addresses: The IT tax closing validation compared month numbers only, which broke across year boundaries and could reject valid quarterly progressions. It also assumed a balance column existed in monthly VAT report lines, but this report uses debit/credit columns, which could trigger a traceback. --- Desired behavior after this commit is merged: This commit computes the period gap with year-aware month deltas and aligns the allowed gap with periodicity (monthly or quarterly). It also checks VP lines using balance when present, or debit/credit as fallback, preventing crashes and ensuring consistent tax closing validation. --- opw-6131080 Forward-Port-Of: odoo/enterprise#118450 Forward-Port-Of: odoo/enterprise#117428
This update resolves a crash when generating PDF reports for Vietnamese tax declarations, particularly Appendix 142. It also corrects data references and ensures reports are named and ordered correctly to align with Vietnamese tax form standards, improving data accuracy and reliability.
Original PR description
This commit resolves multiple issues in the Vietnamese accounting reports module: 1. Appendix 142 PDF Export Crash: - Extracted the PDF sectioning logic into a new `_get_pdf_sections` method. - Added…
This commit resolves multiple issues in the Vietnamese accounting reports module: 1. Appendix 142 PDF Export Crash: - Extracted the PDF sectioning logic into a new `_get_pdf_sections` method. - Added safeguards to gracefully handle cases where the report has no lines, preventing an `IndexError` when attempting to access `lines[-1]`. - Added unit tests to ensure empty lines are correctly parsed without crashing. 2. XML Data and Dependency Fixes: - Fixed an invalid `report_id` reference in `account_return_data.xml` by correctly pointing it to `l10n_vn_reports.l10n_vn_tax_report` instead of `l10n_vn.form_01_gtgt_report`. - Reordered the `__manifest__.py` data loading sequence. `account_tax_report_data.xml` now loads before `account_return_data.xml` to prevent "External ID not found" errors during module installation/upgrades. 3. Naming and Sequencing Improvements: - Renamed "Vietnamese Tax Report" to "VAT Declaration - 01/GTGT" to reflect the actual Vietnamese tax form accurately. - Added explicit `sequence` fields to the tax reports (VAT Declaration: 10, Appendix 142: 20) to ensure proper UI ordering. Task-6216318 Forward-Port-Of: odoo/enterprise#117974
This update resolves a potential issue that caused Out of Memory errors during the installation of the `sale_subscription` module on databases with many sales orders. The change ensures that newly added fields are correctly initialized to 'null' during installation, preventing performance bottlenecks and installation failures.
Original PR description
### Description: Installing `sale_subscription` on databases with a large number of `sale.order` and `sale.order.line` can cause Out of Memory (OOM) errors. The issue comes from two stored compute fields, `last_invoiced_date` and `plan_id`. Since these depend on newly added fields, they should default to `null` during installation. ### Reference: opw-6201267 Forward-Port-Of: odoo/enterprise#118419 Forward-Port-Of: odoo/enterprise#118008
This update resolves an issue where the 'Info & Tags' button was hidden in the mobile Documents app's kanban view. The fix adjusts CSS styling to ensure the chatter section is always visible and accessible, improving usability on mobile devices. This ensures users can easily access important document details.
Original PR description
**Steps to reproduce:** - Go to Documents app in mobile - Go to the kanban view - Add some files and select one - Click on `Info & Tags` button in the control panel - Reload the page - Chatter is not…
**Steps to reproduce:** - Go to Documents app in mobile - Go to the kanban view - Add some files and select one - Click on `Info & Tags` button in the control panel - Reload the page - Chatter is not displayed but the button is still enabled - Switching to the list view properly shows it **Issue:** We have two conflicting css styling on mobile: - `overflow-hidden` was added for mobile to avoid multiple scroll bars - `min-height: 100%` which is due to the default `o_kanban_ungrouped` in the controller css This means that the element is present at the bottom of the page, but we can't get to it manually. When re-enabling the action we are properly moved to the existing chatter (but we can't go back to the top). Also the documents panel should have a single scrollbar to display all the records, but we still need a way to scroll the messages of the chatter. **Fix:** Set `min-height: 0;` for documents kanban to ensure the chatter is still visible and accessible on mobile by default. This makes the chatter take the full available height when displayed. original overflow fix: https://github.com/odoo/enterprise/commit/945b9e2b1c6752bd905695aa40b0babcf38c50cd opw-6061993 Forward-Port-Of: odoo/enterprise#118134 Forward-Port-Of: odoo/enterprise#113168
This update resolves an issue where Selection fields in dark mode sign templates appeared unreadable due to white-on-white text. The fix ensures that form controls within PDF sign templates consistently display with appropriate contrast, regardless of the user's dark mode preference. This improves the user experience for all sign templates.
Original PR description
**Problem:** When the user has dark mode enabled and a sign template contains a Selection field, both the displayed value and the dropdown option list are unreadable: the selected value renders…
**Problem:** When the user has dark mode enabled and a sign template contains a Selection field, both the displayed value and the dropdown option list are unreadable: the selected value renders white-on-white in the field, and clicking the dropdown shows an empty-looking popup (white options on white system menu). **Steps to reproduce:** 1. Enable dark mode in user preferences 2. Open Sign > Templates > duplicate any template 3. Add a Selection field with a few options (e.g. Low / Medium / High) 4. Save and Sign Now 5. Reach the Selection field and click it 6. Observe: the dropdown options are invisible (white on white) and, after picking one, the selected value in the field is also invisible **Cause of the issue:** The Selection sign item is rendered with a native `<select>` element inside the PDF.js iframe (`sign_items.xml`, `t-if="type == 'selection'"` branch). The iframe's stylesheet (`sign/static/src/css/iframe.css`) declares the `select` rule with `background: transparent` but no explicit `color`, and never styles `<option>` at all. When the OS or the user activates dark mode, the iframe document resolves to a `color-scheme: light dark` root, so the browser's UA stylesheet paints form controls with the dark palette (white text). The popup background stays white (`<option>` has no explicit background), so options render white-on-white. The same UA-white propagates to the displayed value of the `<select>` inside the pink-tinted sign item, which is also nearly white. **Fix:** Pinning the `<select>` text color and the `<option>` color/background to fixed light-mode values restores predictable contrast inside the iframe regardless of the surrounding color scheme. We deliberately do not rely on `color-scheme: dark` here — that would only swap which side of the contrast issue we land on (browsers don't reliably honor it for `<option>` background painting), and the sign item background (the pink dashed default style) is itself light, so dark option text on a white popup is the readable target in all themes. opw-6197638 Forward-Port-Of: odoo/enterprise#117697
Resolved issues and error corrections
This update fixes an issue where selecting the start date first would incorrectly set both the start and end dates for deferred accounting periods. Previously, selecting the end date first resulted in dates appearing in reverse order. This change ensures the system correctly handles date selection for postponement periods, improving data accuracy and reducing potential errors.
Original PR description
The issue is when selecting deferred dates, if the start date is selected first, the system will set both the start and end dates. However, when selecting the end date first, the period appears backwards example ( 2026 - 2025 ). task: 6140024
This update fixes an issue where split orders sent to the preparation display incorrectly canceled existing items. The change prevents line cancellations and ensures that split orders create new preparation cards with accurate quantities, maintaining the integrity of the initial order and preventing quantity aggregation errors. This improves the reliability of the preparation display process.
Original PR description
*= pos_restaurant_preparation_display, pos_enterprise Steps to Reproduce ================== - Create an order with Product A ×2 and Product B ×2 - Send the order to the preparation display - Split…
*= pos_restaurant_preparation_display, pos_enterprise Steps to Reproduce ================== - Create an order with Product A ×2 and Product B ×2 - Send the order to the preparation display - Split the order and pay for one unit of each product - On the remaining order, add another product - Send the order to the preparation display - The preparation display incorrectly cancels previously sent products Fix === - Prevent cancellation of existing preparation order lines - Avoid duplication of preparation lines when split orders are sent to the kitchen Covered Scenario ================ 1. Send an order with Coca-Cola ×2, Minute Maid ×2, Water ×1 to the kitchen. 2. Split 1 qty of each product into a new order, increase split quantities, and send it. 3. Increase quantities on the original order and send it again. Expected Behavior ================= - Initial preparation order remains unchanged (no line cancellations) - Split order creates a new preparation card with only unsend split quantities - Original order creates a new preparation card with only newly added quantities - No preparation line incorrectly aggregates quantities across orders Task-5355899 Related Comm. PR: https://github.com/odoo/odoo/pull/244195
This update fixes a crash during Odoo 18 upgrades when archiving incoming operation types. The issue stemmed from a requirement for a specific picking type, which wasn't being met for archived types. The fix ensures that archived picking types are considered, allowing the upgrade process to complete successfully.
Original PR description
### Steps to Reproduce: 1) Create a database on v17.4 or earlier with purchase_requisition_stock installed. 2) Archive the incoming operation type of root company (i.e. base.main_company). 3) Upgrade…
### Steps to Reproduce:
1) Create a database on v17.4 or earlier with purchase_requisition_stock
installed.
2) Archive the incoming operation type of root company (i.e. base.main_company).
3) Upgrade to v18.
### Issue:
Upgrade crashes with RedirectWarning, aborting the process entirely.
```python3
Traceback (most recent call last):
File "/home/odoo/src/odoo/18.0/odoo/service/server.py", line 1366, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "<decorator-gen-13>", line 2, in new
File "/home/odoo/src/odoo/18.0/odoo/tools/func.py", line 97, in locked
return func(inst, *args, **kwargs)
File "/home/odoo/src/odoo/18.0/odoo/modules/registry.py", line 129, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "/home/odoo/src/odoo/18.0/odoo/modules/loading.py", line 485, in load_modules
processed_modules += load_marked_modules(env, graph,
File "/home/odoo/src/odoo/18.0/odoo/modules/loading.py", line 365, in load_marked_modules
loaded, processed = load_module_graph(
File "/home/odoo/src/odoo/18.0/odoo/modules/loading.py", line 206, in load_module_graph
registry.init_models(env.cr, model_names, {'module': package.name}, new_install)
File "/home/odoo/src/odoo/18.0/odoo/modules/registry.py", line 605, in init_models
model._auto_init()
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 3474, in _auto_init
new = field.update_db(self, columns)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 3269, in update_db
return super(Many2one, self).update_db(model, columns)
File "/tmp/tmpy3l3l_un/migrations/base/0.0.0/pre-models-no-orm-table-change.py", line 170, in update_db
return orig_update_db(self, model, columns)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1098, in update_db
self.update_db_notnull(model, column)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1150, in update_db_notnull
model._init_column(self.name)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 3390, in _init_column
value = field.default(self)
File "/home/odoo/src/odoo/18.0/addons/purchase_requisition_stock/models/purchase_requisition.py", line 13, in _default_picking_type_id
self.env['stock.warehouse']._warehouse_redirect_warning()
File "/home/odoo/src/odoo/18.0/addons/stock/models/stock_warehouse.py", line 172, in _warehouse_redirect_warning
raise RedirectWarning(msg, warehouse_action.id, _('Go to Warehouses'))
odoo.exceptions.RedirectWarning: ('Cree un almacén para la empresa Navieras Internacionales, S.A. (Navinter).', 464, 'Ir a los almacenes', None)
```
### Cause:
picking_type_id is required=True on purchase.requisition. In 18.0, warehouses are no longer auto-created for every company https://github.com/odoo/odoo/commit/6516ab61927a63e3f2d804cf1b5baa43a151ca19#diff-e018fe59e11c4e0078e9bc19879f9e98c731bb84c71766ef360ccc482c59d2d8R167 If the root company (base.main_company) had its incoming operation type archived and the upgrade, _default_picking_type_id returns nothing and falls through to _warehouse_redirect_warning, raising a RedirectWarning that aborts the upgrade entirely.
### Fix:
Add active_test=False to the search in _default_picking_type_id so archived picking types are also matched, allowing the upgrade to complete successfully.
opw-6245256
upg-4310650
tbg-2758
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 update fixes an issue where the pension fund tax was incorrectly applied to all invoice lines with the same VAT rate, leading to inaccurate accounting. The fix now correctly identifies the tax exemption reason from the bill data, ensuring the pension fund tax is applied accurately to the first invoice line. This improves tax compliance and financial reporting.
Original PR description
In `l10n_it_edi` vendor bill import, the pension fund tax was incorrectly applied to all invoice lines sharing the same VAT rate, even though they have different `l10n_it_tax_exemption_reason`s, resulting in wrong entries and document total. We now extract the Tax Exemption reason from the `DatiCassaPrevidenziale` node, and use it to search the correct tax. Steps to reproduce: 1. Install `account` and `l10n_edi_it` 2. In the `4% INPS` tax, set `TC22` in pension fund type and `N2.2` in exoneration 3. Import bill from the ticket 4. See the pension fund tax is applied to all the lines. It should only be applied only to the first one. Ticket [link](https://www.odoo.com/odoo/project.task/6212975) opw-6212975 Forward-Port-Of: odoo/odoo#265821