Daily updates from Odoo
Friday, June 5, 2026
27 changes · master
Resolved issues and error corrections
This update ensures that the IPA reduction amount is now correctly displayed in the payroll summary tab (274.XX form). The change adjusts calculations to accurately reflect deductions and provides a clearer view of employee earnings. This improves reporting accuracy and transparency.
Original PR description
Previously, the IPA reduction was introduced on its own dedicated tab on the 274.XX form but was not shown in the summary tab. Added the IPA reduction to the Summary tab by updating the form view to display the "IPA Reduction" field inside the "Exempted Amounts" group, conditionally visible only when active. Modified the `_compute_amounts` method to: - Add `sme_exempted_amount` to the total `deducted_amount` when active. - Delay the calculation of `amount_to_pay` so it correctly reflects the updated total deductions. Task: 6268701
This update resolves compatibility issues with the latest o-spreadsheet library. The changes ensure the spreadsheet edition continues to function correctly after the library's update, improving stability and preventing potential disruptions to users. It addresses minor UI adjustments related to comment popups and layout configurations.
This update ensures all survey results spreadsheets now include a 'Participant' column, linking responses to the correct respondent. This was previously missing for surveys without login requirements, allowing for better tracking of survey data. The change preserves anonymity for truly anonymous surveys by leaving the column blank when no respondent information is available.
Original PR description
Problem: The "Analyze Results" spreadsheet only added a participant column when the survey required login (users_login_required). For surveys that do not require login, such as recruitment screening or surveys launched from CRM, no participant column was produced at all, so the exported answers could not be tied to a respondent. The response already stores partner_id, email and nickname, and the Participations list shows them regardless of login, so the omission was an oversight rather than anonymity protection. Solution: Always emit a "Participant" column, filled with the partner name and falling back to email then nickname. Responses carrying no identity stay blank, preserving anonymity for genuinely anonymous surveys.
This update ensures the HR payroll payslip run Kanban overlay continues to function correctly after a recent update to Odoo's core framework. The change replaces outdated XPath targeting with more reliable CSS selectors, guaranteeing consistent overlay functionality regardless of the underlying form structure. This prevents potential disruptions to payroll processing.
Original PR description
## Summary Companion to the `odoo/odoo` PR on the same `master-tref-pr-1-nby` branch, which migrates `web.KanbanHeader`'s root `<div>` from `t-custom-ref="root"` to `t-ref="this.rootRef"` (Owl 3 signals). The `hr_payroll` payslip-run kanban overlays that `<div>` with an xpath targeting `[@t-ref='root']`. After the migration that attribute no longer exists — and the same xpath also fails against the pre-migration `t-custom-ref` form. ## Change Switch both xpaths in `hr_payslip_run_kanban.xml` to `hasclass()` selectors so they match regardless of which ref form the upstream template uses, keeping the overlay working across the migration. ## Notes - odoo/odoo#267687
This change fixes a problem where DHL shipping labels weren't using the correct template dimensions, resulting in labels printed in the wrong size (8x4 instead of 6x4). The code now maps the selected label template to the correct DHL API format, ensuring accurate label dimensions are generated.
Original PR description
Issue ----- Labels generated with DHL do not respect the template (dimensions) set on the delivery method. Steps to reproduce ----- - Set up DHL - set label template as 6X4_A4_PDF - Create a delivery…
Issue
-----
Labels generated with DHL do not respect the template (dimensions) set on the
delivery method.
Steps to reproduce
-----
- Set up DHL
- set label template as 6X4_A4_PDF
- Create a delivery using the method
- Validate the delivery
> The generated label is in 8x4 inch format instead of 6x4 full page
Explanation
-----
All info below was found in DHL's API doc from the following YAML file
https://developer.dhl.com/sites/default/files/2026-05/dpdhl-express-api-3.3.0.yaml
There are 2 issues with the current implementation regarding the label format.
1. The formats defined on the model (the `ProviderDHL` `delivery.carrier`) do not match the ones of the API. From the API, the accepted values are the following:
- ECOM26_84_A4_001
- ECOM26_84_001
- ECOM_TC_A4
- ECOM26_A6_002
- ECOM26_84CI_001
- ECOM26_84CI_002
- ECOM26_84CI_003
- ECOM_A4_RU_002
- ECOM26_84_LBBX_001
- ECOM26_64_LBBX_001
(values taken from the excerpt below)
```
templateName:
description: >-
Please enter DHL Express document template name.
<BR> Sample Transport label
templates:<BR> ECOM26_84_A4_001
<BR> ECOM26_84_001 - default<BR>
ECOM_TC_A4<BR> ECOM26_A6_002<BR>
ECOM26_84CI_001<BR> ECOM26_84CI_002 - supported
single customer barcode<BR> ECOM26_84CI_003 -
to be used if customer barcodes are used<BR>
ECOM_A4_RU_002<BR>
ECOM26_84_LBBX_001 - supported for loose BBX shipment<BR>
ECOM26_64_LBBX_001 - supported for loose BBX shipment<BR>
[...]
type: string
maxLength: 25
example: ECOM26_84_001
```
[...]: additional info unrelated to labels (useful only for other `typeCode` values)
Since `ProviderDHL` is a model, the `dhl_label_template` selection values cannot be changed and must thus be mapped to the corresponding API values.
- 8X4_A4_PDF => ECOM26_84_A4_001
- 8X4_thermal => ECOM26_84_001
- 8X4_A4_TC_PDF => ECOM_TC_A4
- 6X4_thermal => ECOM26_A6_002
- 6X4_A4_PDF => ECOM26_A6_002
- 8X4_CI_PDF => ECOM26_84CI_001
- 8X4_CI_thermal => ECOM26_84CI_001
- 8X4_RU_A4_PDF => ECOM_A4_RU_002
- 6X4_PDF => ECOM26_A6_002
- 8X4_PDF => ECOM26_84_001
Couple notes about this matching:
- There is no 6x4 in the API, so A6 is used instead (A6 is 105x148mm, 4x6 is 101.6x152.4mm so not a perfect match but the best option still)
- ECOM26_84_001 and ECOM26_A6_002 are used as default values for the respective formats when there is no exact match possible (eg 6x4 only has one option in the API, the default one)
- "A4" is being ignored, because of point 2
2. There is a specific field to force the label to be in A4 format (according to the API, see excerpt below)
```
fitLabelsToA4:
description: >-
To print respective Transport Label and Waybill document into
A4 margin PDF.<BR> Note:
ECOM26_A6_002,ECOM26_84CI_001,ECOM26_84CI_002,ARCH_6X4,ARCH_8X4
template. <BR> This option is applicable only
for PDF encodingFormat selection.<BR> false:
Transport Label and Waybill document will use default margin
settings (default behavior) <BR> true:
Transport Label and Waybill document will print into A4 margin
PDF
type: boolean
example: false
```
-----
Ticket:
opw-6148713
Forward-Port-Of: odoo/enterprise#117281This update resolves an issue where large product weights (over 150kg) triggered errors when calculating shipping rates through Sendcloud in the e-commerce flow. The fix ensures that the system correctly identifies the need to split orders into multiple packages, preventing errors and improving order processing.
Original PR description
Issue ----- Traceback when trying to get a rate through the e-commerce if the order has to be split into multiple packages due to weight being too high. Steps to reproduce ----- - Setup Sendcloud…
Issue ----- Traceback when trying to get a rate through the e-commerce if the order has to be split into multiple packages due to weight being too high. Steps to reproduce ----- - Setup Sendcloud delivery method - make it available in e-commerce - Create a 150kg product and publish it - Go to e-commerce - Add the product to cart - Checkout the cart > Traceback Cause ----- We retrieve the order's weight through the context. https://github.com/odoo/enterprise/blob/d9a9339e1f30f1e5cc37ebb88949451a6652f83b/delivery_sendcloud/models/delivery_carrier.py#L108 If the call to `_get_shipping_rate` returns that the delivery requires multiple packages, we go into https://github.com/odoo/enterprise/blob/d9a9339e1f30f1e5cc37ebb88949451a6652f83b/delivery_sendcloud/models/delivery_carrier.py#L126-L128 If `order_weight` was not present in the context, this will cause an error in `sendcloud_convert_weight` since it expects a numerical value but receives the `None` fallback. This context key is only present when going through `choose.delivery.carrier` (so not in the e-commerce flow). https://github.com/odoo/odoo/blob/058e640e6687ed3f709dc846f0fa7a1f45226849/addons/delivery/wizard/choose_delivery_carrier.py#L69 ----- Ticket: opw-6210398 Forward-Port-Of: odoo/enterprise#119186 Forward-Port-Of: odoo/enterprise#117028
This update resolves an issue where a validation error was incorrectly triggered when setting an intrastat code on product templates. The change now accurately checks for product templates with dynamic attributes and no variants, ensuring the error is raised only in the intended scenario. This improves data integrity and prevents unnecessary errors during product template creation.
Original PR description
Problem: When saving an intrastat code on a product template with no variants, an error should be raised because intrastat codes are stored on the product variants. However, the error gets raised when creating a product template with intrastat code set because the variants get created after the product template is created, so it doesn't find any variant although the default variant will be created right after saving the product template. Solution: The constraint should only be triggered when saving the intrastat code on a product template with dynamic attributes and no variants. Since dynamic attributes are the only ones that can lead to a product template with no variants, we can check if the product template has dynamic attributes and no variants before raising the error. Forward-Port-Of: odoo/enterprise#118986
This update corrects a minor error in the AI service that prevented the system from correctly handling responses from Google's Gemini models. Specifically, the code was incorrectly trying to access an ID field that wasn't always present, leading to a system error. This fix ensures consistent and reliable operation of the AI tool call functionality.
Original PR description
The functionCall parts returned by Gemini may or may not have an id depending on the LLM model used (Gemini 2.5 doesn't include an id in functionCall parts but Gemini 3 does). So, there is some code that checks whether there is an id and generates a uuid if none exists. This code had a bug because it was accessing the id directly on the functionCall part which may not exist and a keyerror was thrown in such cases. This commit solves the issue by using get instead of direct key access. Forward-Port-Of: odoo/enterprise#118837
A recent test failure related to demo data installation has been resolved. The fix ensures that a simulation offer is hidden during testing, preventing errors that occurred when expecting an empty list view. This improves the reliability of the system's testing process.
Original PR description
**Problem**: The test fails when demo data is installed because some steps expect an empty list view. **Fix**: Ensure the simulation offer is hidden by applying a custom filter on the simulation employee Task: 6246575 Forward-Port-Of: odoo/enterprise#119142 Forward-Port-Of: odoo/enterprise#118358
This update fixes an issue where auto-filling fields in sign requests was causing unintended side effects. The changes isolate the auto-fill functionality, preventing these unexpected behaviors and ensuring data integrity within the sign request process. This improves the reliability and accuracy of sign request creation.
Original PR description
task-6269354 Forward-Port-Of: odoo/enterprise#119148
This update fixes a bug in the Thai accounting localization module that prevented users from exporting the P.P.30 - VAT Report. The missing export buttons have been restored, allowing users to generate reports in various formats. This ensures accurate tax reporting compliance for Thai businesses.
Original PR description
Current behavior: -- Missing buttons in the P.P.30 report Expected behavior: -- When clicking on the wheel icon for the P.P.30 - VAT Report, the 3 buttons should show Export for RD Prep, Sales Tax Report, Purchase Tax Report Steps to reproduce: -- In Master version, 1.Install Thai accounting localization module. 2. Navigate to Accounting > Reporting > Tax Report. 3. Select Report: P.P. 30 - VAT Report (TH) from the report dropdown. 4. Click on the gear icon next to "Tax Return". 5. Observe that the export options are missing and only "Copy to Documents" and "Insert in article" are available. Cause of the issue: -- Wrongfully removed the buttons. Caused by commit: https://github.com/odoo/enterprise/commit/ccee902284ab2fd91217ae9a59c1557b7f49433f opw-6267145
This update resolves an issue where negative line items in Mexican CFDI invoices were incorrectly distributed across other lines. The change addresses a conflict introduced by new features like discounts and down payments, making the previous method for checking line types obsolete. This ensures accurate CFDI invoice processing.
Original PR description
In MX CFDI, negative lines are not allowed so they are distributed over other lines. But because this PR introduces some other `special_type` like `global_discount` and `down_payment`, it becomes useless to check `base_line['special_type'] == False`. Fix for https://github.com/odoo/odoo/pull/267435 task-5900496 --- I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr) Forward-Port-Of: odoo/enterprise#119327 Forward-Port-Of: odoo/enterprise#119254
This update addresses a technical issue related to the Spreadsheet Edition's pivot table layout configuration. The changes ensure compatibility with a recent update to the core Odoo spreadsheet functionality, resulting in a smoother and more reliable user experience. This primarily impacts how users customize and manage pivot table layouts.
This update resolves an issue where the Studio sidebar's checkboxes had a broken appearance due to a conflict with Bootstrap's styling. The fix globally applies a background image to indeterminate checkboxes, eliminating the need for a separate workaround and ensuring consistent display across the Enterprise module.
Original PR description
The Studio sidebar had its own `&:indeterminate { background-image: url(...) }` override to work around the broken Bootstrap indeterminate dash. This is now handled globally (see PR #268326 / master-fix-indeterminate-bg-image-jesc): `.form-check-input:indeterminate` sets `background-image` directly, bypassing the Bootstrap CSS variable that carries the broken `stroke='unset'`.
source: `web_enterprise/static/src/scss/bootstrap_overridden.scss` sets `$component-active-color: unset !default;` before `web/bootstrap_overridden.scss` in the bundle, so Bootstrap's indeterminate SVG compiles with `stroke='unset'` and the dash is invisible everywhere except where `background-image` is overridden directly.
fix: the global `.form-check-input:indeterminate { background-image: url(...) }` rule in `web/static/src/core/checkbox/checkbox.scss` now covers all checkboxes, making this local Studio override redundant.This update fixes an issue where the DIAN-compliant electronic invoices generated for Colombia were incorrectly using a generic line number instead of the correct document ID. This prevented the invoices from passing validation checks by the DIAN platform and external systems. The fix ensures invoices now accurately reflect the required document ID, resolving compatibility problems.
Original PR description
### Issue When generating the attached document (AttachedDocument) for Colombia, the parent document reference tag <cbc:ID> incorrectly exported a generic line counter instead of the actual document…
### Issue
When generating the attached document (AttachedDocument) for Colombia, the parent document reference tag <cbc:ID> incorrectly exported a generic line counter instead of the actual document identification number
While the DIAN platform itself accepted the file, this caused rejections in external validation tools and third-party software because they could not resolve the link back to the original invoice
DIAN Documentation: https://www.dian.gov.co/impuestos/factura-electronica/Documents/Anexo_tecnico_factura_electronica_vr_1_7_2020.pdf
On page 213 there is an example for ParentDocumentLineReference
On page 216 there is the specification that does not show any check
Example of the incorrect XML structure:
```xml
<cac:ParentDocumentLineReference>
<cbc:LineID>1</cbc:LineID>
<cac:DocumentReference>
<cbc:ID>1</cbc:ID>
</cac:DocumentReference>
</cac:ParentDocumentLineReference>
```
Expected XML structure:
```xml
<cac:ParentDocumentLineReference>
<cbc:LineID>1</cbc:LineID>
<cac:DocumentReference>
<cbc:ID>SETP990001021</cbc:ID>
</cac:DocumentReference>
</cac:ParentDocumentLineReference>
```
### Cause
In the template, the value for <cbc:ID> was retrieved using `parent_document.get('id')` which fetched the sequential loop index https://github.com/odoo/enterprise/blob/cd25713fd2c35737d98db29df72b2d07ae9146e8/l10n_co_dian/views/templates.xml#L272-L275
The dictionary parsing logic did not extract the true document identifier from the XML tree response or the original XML data https://github.com/odoo/enterprise/blob/13dc30679e382df5845993c880a97df600c39ed4/l10n_co_dian/models/l10n_co_dian_document.py#L429-L432
### Steps to reproduce
- Install `l10n_co_dian`
- Setup DIAN configuration
- Generate an attached document for a commercial event or invoice
- Open the generated XML file
Before the fix, the `<cac:ParentDocumentLineReference>/<cac:DocumentReference>/<cbc:ID>` tag contains a technical integer like "1" instead of the official document sequence number
opw-6164321
Forward-Port-Of: odoo/enterprise#118319This update corrects a previous issue where website forms were incorrectly translated into the user's language instead of the website's default language. Now, all forms displayed on the website will automatically use the website's language setting, ensuring a consistent and accurate experience for users regardless of their browser language.
Original PR description
When the website is in a different language A to the user language B, forms are translated into the language B of the builder. They should be in the website default language. Task-6171271
This update fixes a technical error that prevented refunds in the Colombian Point of Sale (PoS) system. The issue stemmed from outdated code referencing an old function name, which caused a traceback during the refund process. This change ensures refunds are processed correctly for Colombian customers.
Original PR description
**Steps to reproduce:** - Setup a columbian company, DIAN should be in demo mode - Go to the PoS and make a sale with a columbian customer - Refund it - A traceback appears **Why the fix:** Some legacy code was left untouched when we changed the old **get_partner()** to the new **getPartner()** so we got a traceback as this function does not exist anymore. We also change the **set_partner(partner)** to **setPartner(partner)** as it was also forgotten. opw-6231856 Forward-Port-Of: odoo/enterprise#118651 Forward-Port-Of: odoo/enterprise#118054
This update corrects a bug in the appointment Gantt view that caused new bookings to default to midnight instead of the intended start time. The fix replaces a mistaken override with the correct method, ensuring accurate booking start times are used.
Original PR description
The [commit] replaced the `onAddClicked` method with `_onNewClicked`, and updated all related calls and overrides accordingly. However, the appointment Gantt view override was mistakenly changed to override a non-existent `_onAddClicked` method, leaving the custom logic unused. As a result, bookings created through the `New` button in the Gantt view used midnight (12:00 AM) instead of the time derived from the custom logic as the default start datetime. This commit fixes the issue by correctly overriding `_onNewClicked`. [commit]: https://github.com/odoo/enterprise/commit/bc779c9ec5295f8d1fe06e8432c518c78c606ea2 Forward-Port-Of: odoo/enterprise#118799
This update resolves an issue where inserting a prompt banner using the `/prompt` command wouldn't allow users to undo the banner's creation. The fix ensures that undo functionality correctly removes prompt banners, improving usability and preventing unexpected content.
Original PR description
Problem: After inserting a prompt banner, undo does not remove it. Cause: History commands were ignored when the selection was inside the prompt banner, preventing undo from handling banner insertion. Solution: Handle history commands even when the selection is inside the prompt banner. Steps to reproduce: - Insert a prompt banner using `/prompt` + Enter. - Press Ctrl + Z. - Observe that the banner is not removed. task-6230530 Forward-Port-Of: odoo/enterprise#118248 Forward-Port-Of: odoo/enterprise#117845
This update fixes an issue where check amounts weren't being properly rounded in the Philippines (PH) version of Odoo. Previously, the check amount in words displayed with a decimal component and 'ONLY'. Now, the decimal is rounded, ensuring accurate check formatting and compliance with PH regulations.
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#117679 Forward-Port-Of: odoo/enterprise#116717
This update resolves an issue where the company's XBRL reports were failing validation by the NBB due to missing data disclosures. The changes add the necessary disclosures, ensuring reports pass validation and comply with regulatory requirements. This prevents potential delays or errors in report submission.
Original PR description
This commit adds missing explanatory disclosure datapoints to the generated XBRL report. The missing disclosures resulted in failing validation when report is submitted to NBB. The datapoints are only added if the original value was non-zero. For example, the tangible assets disclosures are only added if the tangible assets in balance sheet is non-zero. Additionally, only disclosures that were reported as causing a failing validation were added. task-5977199 Forward-Port-Of: odoo/enterprise#117853
This update corrects a bug that prevented quality checks from running correctly when a product's manufacturing operations were modified. The change adjusts how the system handles lot references, ensuring compatibility with recent Odoo updates. This resolves an error related to invalid data and improves the reliability of the quality control process.
Original PR description
## Steps to reproduce: - Install the `quality_mrp` module. - Create a new product. - Create a Quality Point with: Type: Measure, Control per: Product/Operation Operations: Manufacturing - Create and…
## Steps to reproduce: - Install the `quality_mrp` module. - Create a new product. - Create a Quality Point with: Type: Measure, Control per: Product/Operation Operations: Manufacturing - Create and confirm MO for the product. - Update the Quality Point: Remove the 'manufacturing' operation type and add 'receipts' type. Change Control per to 'Quantity'. - Open the MO and start a quality check. - Enter an invalid measure and try to validate it. ## Error: `AttributeError - 'mrp.production' object has no attribute 'lot_producing_id'` ## Cause: Since commit https://github.com/odoo/odoo/commit/4bb4e08066449177f89382718ceadd840ce90d0e, the `lot_producing_id` field on MO was replaced by the Many2many field `lot_producing_ids`. Invalid references to the removed field lead to an error. ## Fix: This commit uses the first lot/serial from the MO. Note: Multiple produced lots are only possible for serial-tracked products. sentry-7511513479 Forward-Port-Of: odoo/enterprise#119231
A recent update incorrectly removed filtering during automatic Stripe expense reconciliation, causing all expense lines to be incorrectly reconciled. This fix ensures that only the relevant transaction lines are reconciled, resolving a critical issue with Stripe expense reporting and preventing inaccurate financial records.
Original PR description
In 1f6f4ee3, the account reconciliation filtering was removed from the automatic reconciliation. This broke the reconciliation as all lines would be taken into the reconciliation after-hand Steps to reproduce: - Install `hr_expense_stripe_demo` - Create a Stripe account in the settings - Refresh the account status until validated - Top-up the account in the accounting dashboard - Create a virtual card and activate it - Simulate a transaction with capture - Submit the expense created after checking it has at least one tax - Approve and post the expense - Check the reconciled transaction in the stripe journal - All the lines of the expense move have been reconciled Forward-Port-Of: odoo/enterprise#119269
This update resolves an issue where users were blocked from uploading documents to requests linked to records they didn't have full access to. By adding a '.sudo()' function to the attachment creation process, users can now successfully upload documents, regardless of their access rights to the related record. This improves usability and ensures requests can be properly documented.
Original PR description
Issue: Users are currently blocked from uploading requested documents if the request is linked to a record they do not have access to (e.g., User A links Record X to a request assigned to User B, but User B lacks read/write access to Record X). The system throws an error because the user cannot create an attachment for that record. Fix: Add .sudo() on the attachment creation process. task-6107099 Forward-Port-Of: odoo/enterprise#113698
This update fixes an issue where payments for Mexican invoices were being sent to CFDI multiple times, leading to inaccurate reporting. The fix ensures the 'Update Payments' button only appears after the full invoice payment is reconciled, preventing duplicate submissions and maintaining accurate financial records.
Original PR description
Issue: Sending payments to SAT before its full amount is reconciled allow sending the same invoice payment several times to CFDI. Steps to reproduce: - In a Mexican company - Create an invoice A of…
Issue: Sending payments to SAT before its full amount is reconciled allow sending the same invoice payment several times to CFDI. Steps to reproduce: - In a Mexican company - Create an invoice A of $40 to Inmobiliaria CVA - Confirm and send to CFDI - Go to bank, create a new Bank transaction of $80 - reconcile with Invoice A - Go to invoice A => click on button "Update payments" (it doesn't appear in previous versions) - Then sheet CFDI and Download There is the first XML sent to CFDI with payment for invoice A - Create an invoice B of $40 to Inmobilira CVA - Confirm and send to CFDI - reconcile the transaction with Invoice B - Go to invoice B - Click on button "Update payments" - Then sheet CFDI and Download There is the second XML sent to CFDI with payment for invoices A and B Invoice A payment was sent twice to CFDI Expected behavior: - The "Update payment" button should appear only once the invoice payment is fully reconciled. Current behavior: - The update payment button appear once the invoice is reconciled with a payment. The method `_l10n_mx_edi_cfdi_invoice_get_payments_diff` is called twice, once to check whether it's needed to display the "Update button" and once when you try to update the payment (called only after clicking on said button). opw-5432421 Forward-Port-Of: odoo/enterprise#119244 Forward-Port-Of: odoo/enterprise#108355
This update fixes a calculation error in the Canadian Profit and Loss report. Previously, operating expenses were incorrectly added to gross profit, leading to inaccurate Net Operating Income figures. Now, the report correctly calculates Net Operating Income as Gross Profit minus Operating Expenses, ensuring accurate financial reporting.
Original PR description
Steps to reproduce: 1. Install the Accounting app with the Canadian localization (l10n_ca) 2. Open the Profit and Loss report 3. Review the Net Operating Income line Issue: The Net Operating Income value is incorrectly calculated; operating expenses are being added to gross profit instead of subtracted, producing an incorrect result. Expected behavior: Net Operating Income should equal Gross Profit - Operating Expenses opw-6265192 Forward-Port-Of: odoo/enterprise#119165
This update dynamically adjusts the number of pages processed when uploading PDFs to the AI chat feature. Previously, uploads were limited to 5 pages. Now, the system can handle larger documents, improving the efficiency of AI-powered conversations. This change ensures a smoother experience for agents and users.
Original PR description
Prior to this commit, when uploading a document (i.e. during a chat with an agent). Only a part of its pages would get parsed and sent to the API (5 pages). With this commit, the number of pages is made dynamic by the use of a new context key `ai_max_pdf_pages`. This variable is still set for the document autosorting features since it is not required to read the full document. Default value is None (no limit). Forward-Port-Of: odoo/enterprise#119452 Forward-Port-Of: odoo/enterprise#119338