Friday, May 29, 2026
139 changes
4 changes
Resolved issues and error corrections
This update ensures that expenses are correctly linked to analytic accounting when required. Previously, users could post expenses without specifying an analytic distribution even when an analytic plan with a mandatory 'Expense' domain was set. This fix prevents incorrect accounting and ensures accurate tracking of expenses against specific budgets or cost centers.
Original PR description
When posting expenses, if the expense domain is set as mandatory in any of the analytic plans, users can still post expenses without entering an analytic distribution. Steps to reproduce: 1. Create an analytic plan with the "Expense" domain and set it as mandatory. 2. Create a new expense and submit it. 3. Don't enter any analytic distribution. 4. Post Journal Entries for the expense. 5. Notice how the expense is posted without any error message. Ticket [link](https://www.odoo.com/odoo/project.task/6187340) opw-6187340 Forward-Port-Of: odoo/odoo#266399
This update corrects a bug where table assignments weren't consistently syncing across different devices within a POS session. Now, when a waiter selects a table without an order, it correctly displays as occupied on all devices, ensuring accurate table management for staff and customers. This improves the overall POS experience and reduces potential errors.
Original PR description
When a waiter selects a table without adding any items and returns to the floor screen, the table appears as occupied (green) on their device but not on other devices in the same POS session. Steps to reproduce: ------------------- * Open POS session on device A * Open same POS session on device B * On device A: click a table, don't add items, go back to floor * On device B: observe the table does not appear as occupied > Observation: Empty table assignments were not being synced to the server, so other devices couldn't detect the table occupancy. Why the fix: ------------ Also treat orders with a table_id as pending so they sync immediately when a table is opened. The backend already supports this: pos.order can be created with just table_id, and pos_restaurant._get_open_order looks orders up by table_id for table-based sync. opw-5236119 Forward-Port-Of: odoo/odoo#259465 Forward-Port-Of: odoo/odoo#241321
This update optimizes a key query used to retrieve reconciliation models, resulting in significantly faster performance. By correcting a technical issue with how the database searches for matching records, the system now responds much quicker, particularly when the database's memory is not fully warmed up. This improves overall system responsiveness.
Original PR description
The CTE `model_fees` is supposed to get the reconciliation models that match conditions that involves a join with the ir.model.data table. One of these conditions is filtering based on the `name`…
The CTE `model_fees` is supposed to get the reconciliation models that match conditions that involves a join with the ir.model.data table. One of these conditions is filtering based on the `name` field with an `LIKE` operator. On databases that has a GIST index on the field `name`, the planner will prefer to filter the records based using the GIST index and add the extra filters as a filtering criteria after the index condition if the index-condition wasn't possible to be switched to a range-query. The condition is supposed to be a prefix-matching, which can be evaluated directly by a B-TREE if the field had an index and the planner can convert the condition to a range-query. Apparently the `_` in `account_reco_models_fees_%%` was evaluated as a wild-card, making the condition a substring-matching rather than direct prefix-matching. In this PR, I have modified the condition to escape the '_' wildcards. The benchmark done below was on a database that has around **10^7** `ir.model.data` records and 1K `account.reconciliation.model` records. I have split the benchmark into two cases, a case where the buffer-pool of postgres warmed-up and a case where it is not. After Worst case -> https://explain.dalibo.com/plan/975geg1f1h109d5c Before Worst case -> https://explain.dalibo.com/plan/0ce9bf3g0ad8f98b After Best Case -> https://explain.dalibo.com/plan/1a77459dadb0gfc4 Definition of ir_model_data_name_idx2 -> CREATE INDEX ir_model_data_name_idx2 ON public.ir_model_data USING gist (name gist_trgm_ops) Definition of ir_model_data_module_name_uniq_index -> CREATE UNIQUE INDEX ir_model_data_module_name_uniq_index ON public.ir_model_data USING btree (module, name) | PostgreSQL Buffer Pool Status | Before | After | | :--- | :--- | :--- | | Not warmed up (Cold) | 11s | 130ms | | Warmed up (Hot) | 0.022ms | 0.097ms | Forward-Port-Of: odoo/enterprise#117746
This update resolves an issue in the Italian annual tax report where incorrect values (both positive and negative) were displayed for tax lines. The fix ensures that only the positive balance for each pair of tax lines (VL3/VL4 and VL32/VL33) is shown, aligning with tax reporting requirements. This improves the accuracy of the report for Italian businesses.
Original PR description
### Issue In the Italian annual tax report, both VL3/VL4 and VL32/VL33 values could be displayed at the same time However, according to the report logic, only the positive balance should be shown for…
### Issue In the Italian annual tax report, both VL3/VL4 and VL32/VL33 values could be displayed at the same time However, according to the report logic, only the positive balance should be shown for each pair: - VL3 (Tax Due) or VL4 (Tax Credit) - VL32 (Tax Due) or VL33 (Tax Credit) The other one should stay 0 If the global balance is null, both can be 0 ### Cause The lines VL3, VL4, VL32, and VL33 were using the shortcut field `aggregation_formula` directly on the `account.report.line` record This shortcut format does not evaluate or support conditional subformulas like `if_above(EUR(0))` As a result, the report computed and displayed both lines of each pair without filtering out the negative or unwanted values ### Steps to reproduce - Install `l10n_it` and `accountant` and switch to IT Company - Create a balanced Journal Entry for any account - Add the Tax Grid v20 on one of the lines to impact the annual report - Open the `Annual Tax Report (IT)` - Go to the `VL` section - Check the value of VL3/VL4 and VL32/VL33 After the fix, only one value can be positive and the other 0 Ticket [link](https://www.odoo.com/odoo/project.task/6212694) opw-6212694 Forward-Port-Of: odoo/odoo#264294
4 changes
Resolved issues and error corrections
This update ensures that when an analytic plan with mandatory 'Expense' domains is set up, users must now correctly provide an analytic distribution when posting expenses. Previously, expenses could be posted without this distribution, leading to potential accounting discrepancies. This change improves data accuracy and compliance.
Original PR description
When posting expenses, if the expense domain is set as mandatory in any of the analytic plans, users can still post expenses without entering an analytic distribution. Steps to reproduce: 1. Create an analytic plan with the "Expense" domain and set it as mandatory. 2. Create a new expense and submit it. 3. Don't enter any analytic distribution. 4. Post Journal Entries for the expense. 5. Notice how the expense is posted without any error message. Ticket [link](https://www.odoo.com/odoo/project.task/6187340) opw-6187340 Forward-Port-Of: odoo/odoo#266399
8 changes
New functionality added to Odoo
This update adds crucial data fields – like price before tax, tax names, and supplier information – to the data sent to Pricer. This improves the accuracy of pricing calculations and supports more complete use cases within our point-of-sale system. The update also ensures Pricer tags are automatically updated when related product information changes.
Original PR description
We are currently missing some fields which must be sent to Pricer for some basic use-case scenarios This PR adds - Price before taxes - Taxes name (ex: 21%) - Supplier product code - Supplier reference - Units of measure of the product The PR also triggers the update of the pricer tags when the models indirectly related to Pricer are modified (taxes name / supplier reference / supplier product code) + cleans up the code a bit task-4506260 Forward-Port-Of: odoo/enterprise#93330 Forward-Port-Of: odoo/enterprise#78009
1 change
New functionality added to Odoo
This update adds crucial data fields – like price before taxes, tax names, and supplier information – to the data sent to Pricer. This enables more accurate pricing calculations for basic sales scenarios. The update also ensures Pricer tags are automatically updated when related product or tax information changes.
Original PR description
We are currently missing some fields which must be sent to Pricer for some basic use-case scenarios This PR adds - Price before taxes - Taxes name (ex: 21%) - Supplier product code - Supplier reference - Units of measure of the product The PR also triggers the update of the pricer tags when the models indirectly related to Pricer are modified (taxes name / supplier reference / supplier product code) + cleans up the code a bit task-4506260 Forward-Port-Of: odoo/enterprise#93330 Forward-Port-Of: odoo/enterprise#78009
4 changes
New functionality added to Odoo
This update expands the information sent to Pricer, including price before taxes, tax details, supplier product codes, and units of measure. This addition addresses critical use cases and ensures accurate pricing calculations within the Pricer system. The update also includes minor code cleanup and automated updates to Pricer tags based on related product and supplier information.
Original PR description
We are currently missing some fields which must be sent to Pricer for some basic use-case scenarios This PR adds - Price before taxes - Taxes name (ex: 21%) - Supplier product code - Supplier reference - Units of measure of the product The PR also triggers the update of the pricer tags when the models indirectly related to Pricer are modified (taxes name / supplier reference / supplier product code) + cleans up the code a bit task-4506260 Forward-Port-Of: odoo/enterprise#93330 Forward-Port-Of: odoo/enterprise#78009
3 changes
New functionality added to Odoo
This update expands the data sent to Pricer, including price before taxes, tax names, supplier product codes, and units of measure. This allows for more accurate pricing calculations and supports key business scenarios when using the Pricer integration. The update also ensures Pricer tags are automatically updated when related product information changes.
Original PR description
We are currently missing some fields which must be sent to Pricer for some basic use-case scenarios This PR adds - Price before taxes - Taxes name (ex: 21%) - Supplier product code - Supplier reference - Units of measure of the product The PR also triggers the update of the pricer tags when the models indirectly related to Pricer are modified (taxes name / supplier reference / supplier product code) + cleans up the code a bit task-4506260 Forward-Port-Of: odoo/enterprise#93330 Forward-Port-Of: odoo/enterprise#78009
1 change
Resolved issues and error corrections
This update resolves an issue in the Italian annual tax report where both positive and negative values for VL3/VL4 and VL32/VL33 were displayed simultaneously. The fix ensures that only the positive balance is shown for each pair, aligning with tax reporting logic and improving report accuracy. This change impacts the Italian tax reporting process.
Original PR description
This update resolves an issue where Odoo would crash when a customer canceled a Redsys payment and returned to the system. Previously, the system didn't handle missing payment details correctly, leading to an error. Now, Odoo gracefully handles payment cancellations, ensuring a smoother customer experience.
Original PR description
Description of the issue/feature this PR addresses: Prevent an internal server error when a customer cancels a Redsys payment and returns to Odoo. Current behavior before PR: When the customer…
Description of the issue/feature this PR addresses: Prevent an internal server error when a customer cancels a Redsys payment and returns to Odoo. Current behavior before PR: When the customer cancels the payment from the Redsys checkout page, Redsys redirects back to Odoo without the `Ds_MerchantParameters` parameter. The payment flow assumes the parameter is always present and tries to decode it unconditionally, causing an internal server error. Desired behavior after PR is merged: Odoo gracefully handles payment cancellations when `Ds_MerchantParameters` is missing from the callback parameters. The customer is redirected correctly without triggering a server error. Steps to reproduce: 1. Install the Redsys payment provider. 2. Configure a test environment. 3. Create a sales order or invoice. 4. Start the payment process. 5. Cancel the payment from the Redsys checkout page. 6. Return to Odoo. 7. Observe the internal server error caused by the missing `Ds_MerchantParameters` parameter. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#265655
This update resolves an issue where the Italian annual tax report incorrectly displayed both positive and negative values for related tax lines (VL3/VL4 and VL32/VL33). The fix ensures that only the positive balance is shown, aligning with the report's logic and improving data accuracy for Italian tax reporting.
Original PR description
### Issue In the Italian annual tax report, both VL3/VL4 and VL32/VL33 values could be displayed at the same time However, according to the report logic, only the positive balance should be shown for…
### Issue In the Italian annual tax report, both VL3/VL4 and VL32/VL33 values could be displayed at the same time However, according to the report logic, only the positive balance should be shown for each pair: - VL3 (Tax Due) or VL4 (Tax Credit) - VL32 (Tax Due) or VL33 (Tax Credit) The other one should stay 0 If the global balance is null, both can be 0 ### Cause The lines VL3, VL4, VL32, and VL33 were using the shortcut field `aggregation_formula` directly on the `account.report.line` record This shortcut format does not evaluate or support conditional subformulas like `if_above(EUR(0))` As a result, the report computed and displayed both lines of each pair without filtering out the negative or unwanted values ### Steps to reproduce - Install `l10n_it` and `accountant` and switch to IT Company - Create a balanced Journal Entry for any account - Add the Tax Grid v20 on one of the lines to impact the annual report - Open the `Annual Tax Report (IT)` - Go to the `VL` section - Check the value of VL3/VL4 and VL32/VL33 After the fix, only one value can be positive and the other 0 Ticket [link](https://www.odoo.com/odoo/project.task/6212694) opw-6212694 Forward-Port-Of: odoo/odoo#264294
This update resolves an issue preventing Belgian employees on flexible work schedules from requesting multi-day leave. The fix ensures that the system correctly handles flexible schedules, avoiding an error related to time credit attendance calculations. This enhancement improves the functionality for Belgian businesses using the l10n_be_hr_payroll module.
Original PR description
## Steps to reproduce: - Install l10n_be_hr_payroll module - Create a flexible working schedule and set the company to the Belgian company - Create an employee and assign the created schedule to him - Try to take a multi-day leave for this employee - Notice number of days is 0 - Try to validate the leave - An exception is raised 'The following employees are not supposed to work during that period' ## Cause: When fetching the work intervals for a belgian flexible employee we first fetch the normal work intervals then we call the same method but to filter the time credit attendance and since for the flexible employee there are not specific attendances we return the same normal work intervals and it will subtract those from the main work intervals which will result in an empty intervals to be returned ## Fix: Check if the working schedule is flexible and if so we don't check the time credit attendances at all. opw-6237642 Forward-Port-Of: odoo/enterprise#118528
Resolved issues and error corrections
This update fixes an issue where the point-of-sale system was only receiving webhooks from one of two configured Mercado Pago terminals. The change ensures that all webhook responses from each terminal are properly processed, improving the reliability of payment processing for multiple store locations. This prevents lost transactions and ensures accurate record-keeping.
Original PR description
Issue Upon initialization of the pos a PaymentInterface is constructed for every pos_payment_method (even archived pos payment methods ?!). [As we allow only one WebSocket subscription per…
Issue Upon initialization of the pos a PaymentInterface is constructed for every pos_payment_method (even archived pos payment methods ?!). [As we allow only one WebSocket subscription per channel](https://github.com/odoo/odoo/blob/4e1c89890c5fd54a79dcf5bf20268e51d8fe6e69/addons/point_of_sale/static/src/app/utils/payment/payment_interface.js#L100) for the PaymentInterface, all webhook responses will be linked to only one PaymentInterface. Meaning that when you have two Mercado Pago pos_payment_method terminals configured, only the first pos_payment_method (id=1) will be subscribed to the WebSocket and all the webhook responses from the second pos_payment_method terminal (id=2) will arrive to the PayementInterface of the first pos_payment_method (id=1). Where payload.payment_method_id (id=2) != this.payment_method_id.id (id=1). Solution - Only iterate and create a PaymentInterface for compatible pos_payment_methods which are active - Check if the webhook response is linked to the PendingPaymentLine opw-6069455 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures that expenses are correctly linked to analytic accounting when required. Previously, users could post expenses without specifying an analytic distribution even when an analytic plan with a mandatory 'Expense' domain was set. This fix prevents incorrect financial reporting by enforcing the required analytic distribution.
Original PR description
When posting expenses, if the expense domain is set as mandatory in any of the analytic plans, users can still post expenses without entering an analytic distribution. Steps to reproduce: 1. Create an analytic plan with the "Expense" domain and set it as mandatory. 2. Create a new expense and submit it. 3. Don't enter any analytic distribution. 4. Post Journal Entries for the expense. 5. Notice how the expense is posted without any error message. Ticket [link](https://www.odoo.com/odoo/project.task/6187340) opw-6187340 Forward-Port-Of: odoo/odoo#266399
This update resolves an issue where Odoo would crash when a customer canceled a Redsys payment and returned to the system. Previously, the system didn't properly handle missing payment details, leading to an error. Now, Odoo gracefully handles payment cancellations, ensuring a smoother customer experience.
Original PR description
Description of the issue/feature this PR addresses: Prevent an internal server error when a customer cancels a Redsys payment and returns to Odoo. Current behavior before PR: When the customer…
Description of the issue/feature this PR addresses: Prevent an internal server error when a customer cancels a Redsys payment and returns to Odoo. Current behavior before PR: When the customer cancels the payment from the Redsys checkout page, Redsys redirects back to Odoo without the `Ds_MerchantParameters` parameter. The payment flow assumes the parameter is always present and tries to decode it unconditionally, causing an internal server error. Desired behavior after PR is merged: Odoo gracefully handles payment cancellations when `Ds_MerchantParameters` is missing from the callback parameters. The customer is redirected correctly without triggering a server error. Steps to reproduce: 1. Install the Redsys payment provider. 2. Configure a test environment. 3. Create a sales order or invoice. 4. Start the payment process. 5. Cancel the payment from the Redsys checkout page. 6. Return to Odoo. 7. Observe the internal server error caused by the missing `Ds_MerchantParameters` parameter. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#265655
This update fixes a technical issue preventing AI responses from being correctly delivered when AI Livechat is embedded on another website. The fix involves changing how the AI response stream is handled, ensuring proper CORS routing and allowing the embedded Livechat to receive the necessary data. This improves the overall functionality and reliability of the embedded AI Livechat experience.
Original PR description
AI livechat embedded on another origin could not receive AI responses. The response stream is requested with fetch(), so it bypassed the livechat CORS routing that only wraps RPC calls. The matching CORS controller was also exposed as JSON-RPC, which cannot return the streamed HTTP response correctly. Expose the CORS endpoint as an HTTP stream, route the embedded fetch call to it, and pass the livechat guest token explicitly. task-id-6201054
This update resolves an error that prevented users from canceling draft POS orders. The issue stemmed from a recent code change that incorrectly returned order data. The fix removes this problematic code, restoring the ability to cancel draft orders as intended.
Original PR description
Currently an error is generated when the user tries to cancel a draft POS order as follows: - Install the `pos_enterprise` module with demo data - Open the register of `Furniture store` and select…
Currently an error is generated when the user tries to cancel a draft POS order as follows: - Install the `pos_enterprise` module with demo data - Open the register of `Furniture store` and select any product - Click on the `Upload` icon to save the draft order and go to the backend. - Navigate Orders > Orders > open Draft order - Click the `cog` icon and click `Cancel Order` >>> Error occurs This issue is caused by the recent refactor introduced in [1]. The `action_pos_order_cancel` action now returns the `order` (`pos.order` recordset) instead of default returning `None`. As a result, the `action` variable contains a `pos.order` recordset, and an error is raised at line [2] when `setdefault` is called on it, since `setdefault` expects a dictionary-like object. This commit fixes the above issue by removing the code that returns the `pos.order` object from the action. As a result, the action now behaves as expected and returns the default value (`None`). [1]: https://github.com/odoo/enterprise/commit/27f57036a1d0468efe6e68d7aceafe0f01b21f93 [2]: https://github.com/odoo/odoo/blob/48f93ca056633bd5cba36b66ee1008fb57ca666c/addons/web/controllers/utils.py#L24 Sentry-7354160052
This update corrects a reporting issue in the Italian annual tax report. Previously, both positive and negative values for VL3/VL4 and VL32/VL33 were displayed, which was incorrect according to tax regulations. The fix ensures only the positive balance is shown, aligning with the required reporting format.
Original PR description
### Issue In the Italian annual tax report, both VL3/VL4 and VL32/VL33 values could be displayed at the same time However, according to the report logic, only the positive balance should be shown for…
### Issue In the Italian annual tax report, both VL3/VL4 and VL32/VL33 values could be displayed at the same time However, according to the report logic, only the positive balance should be shown for each pair: - VL3 (Tax Due) or VL4 (Tax Credit) - VL32 (Tax Due) or VL33 (Tax Credit) The other one should stay 0 If the global balance is null, both can be 0 ### Cause The lines VL3, VL4, VL32, and VL33 were using the shortcut field `aggregation_formula` directly on the `account.report.line` record This shortcut format does not evaluate or support conditional subformulas like `if_above(EUR(0))` As a result, the report computed and displayed both lines of each pair without filtering out the negative or unwanted values ### Steps to reproduce - Install `l10n_it` and `accountant` and switch to IT Company - Create a balanced Journal Entry for any account - Add the Tax Grid v20 on one of the lines to impact the annual report - Open the `Annual Tax Report (IT)` - Go to the `VL` section - Check the value of VL3/VL4 and VL32/VL33 After the fix, only one value can be positive and the other 0 Ticket [link](https://www.odoo.com/odoo/project.task/6212694) opw-6212694 Forward-Port-Of: odoo/odoo#264294
This update fixes a critical issue where users could accidentally add snoozed products to orders, leading to order inaccuracies. The changes now include warnings before adding snoozed items and improved detection across all POS and self-order flows, ensuring orders are built correctly and preventing user errors.
Original PR description
### Before this commit: - Snoozed products could still be selected from the product screen and combo configurator without any warning. - Users could add snoozed products to the order by mistake. - In self-order, snoozed products were still selectable in combo items. - Snooze checking was only based on product template id. For product variants (`product.product`), the `product_tmpl_id` was not checked. ### After this commit: - Add a `canAddProductToCurrentOrder` method to show a warning before adding a snoozed product. - Apply this check in the product screen and combo configurator. - Improve snooze detection by supporting both `product.template` and `product.product` (via `product_tmpl_id`). - In self-order, If a product is snoozed, show it as 'Out of stock'. - If a product is not available in self-order, do not show it in the list. - Fix the radio input attribute in the snooze dialog. Task:6012412
Resolved issues and error corrections
This update fixes an issue where vendor bills weren't automatically attaching the embedded PDF from Peppol/UBL XML files received via email. The fix ensures that PDFs are correctly extracted and attached to vendor bills, streamlining invoice processing and improving data accuracy. This resolves a previous problem impacting invoice delivery.
Original PR description
When receiving a Peppol/UBL XML file containing an embedded PDF via an email alias, the PDF is not extracted and attached to the resulting vendor bill. Steps to reproduce: - Set up a BE Company - Configure an incoming mail server - Set up an email alias for the Vendor Bill journal - Receive a Peppol XML with embedded PDF via alias - Check the created Bill Issue: PDF has not been extracted from the xml This occurs because the received xml is set as main attachment for the record and in this case we skip extraction opw-6075250 Forward-Port-Of: odoo/odoo#262724 Forward-Port-Of: odoo/odoo#262047
This update corrects a reporting issue in the Italian annual tax report. Previously, both positive and negative tax values (VL3/VL4 and VL32/VL33) were displayed simultaneously. Now, only the positive balance is shown, ensuring accurate reporting according to Italian tax regulations.
Original PR description
### Issue In the Italian annual tax report, both VL3/VL4 and VL32/VL33 values could be displayed at the same time However, according to the report logic, only the positive balance should be shown for…
### Issue In the Italian annual tax report, both VL3/VL4 and VL32/VL33 values could be displayed at the same time However, according to the report logic, only the positive balance should be shown for each pair: - VL3 (Tax Due) or VL4 (Tax Credit) - VL32 (Tax Due) or VL33 (Tax Credit) The other one should stay 0 If the global balance is null, both can be 0 ### Cause The lines VL3, VL4, VL32, and VL33 were using the shortcut field `aggregation_formula` directly on the `account.report.line` record This shortcut format does not evaluate or support conditional subformulas like `if_above(EUR(0))` As a result, the report computed and displayed both lines of each pair without filtering out the negative or unwanted values ### Steps to reproduce - Install `l10n_it` and `accountant` and switch to IT Company - Create a balanced Journal Entry for any account - Add the Tax Grid v20 on one of the lines to impact the annual report - Open the `Annual Tax Report (IT)` - Go to the `VL` section - Check the value of VL3/VL4 and VL32/VL33 After the fix, only one value can be positive and the other 0 Ticket [link](https://www.odoo.com/odoo/project.task/6212694) opw-6212694 Forward-Port-Of: odoo/odoo#264294
This update resolves an issue where branch users without access to a parent company couldn't create transactions in the parent company's currency. The fix ensures accurate currency conversion by temporarily elevating permissions during the transaction process, allowing branch users to manage transactions in parent company journals.
Original PR description
**Problem:** When a branch user with no access to the parent company tries to create a transaction for a parent company's journal with a foreign currency set, this will raise an access error. **Steps…
**Problem:** When a branch user with no access to the parent company tries to create a transaction for a parent company's journal with a foreign currency set, this will raise an access error. **Steps to Reproduce:** - Make a branch of "My Company (San Francisco)" - Set user "Marc Demo" to only have access to the branch - Add a new bank journal set to "EUR" currency - Switch to Marc Demo - Try to add a transaction in the new bank journal **Root Cause:** When a transaction is created, Odoo determines the amount in company currency by converting it from the foreign currency. The method to convert currency uses "with_company()" to use the company's rates, but the allowed companies of the branch user does not have access to the parent company, causing an access error. **Solution:** Call the currency conversion with sudo() to ensure access to the relevant companies. Ticket [link](https://www.odoo.com/odoo/project.task/6186901) opw-6186901 Forward-Port-Of: odoo/odoo#263668 Forward-Port-Of: odoo/odoo#263425
Resolved issues and error corrections
This update resolves a critical issue where the Swedish SIE 4 report export would crash due to excessive memory usage. By optimizing the database query and using efficient data processing techniques, the export now handles large datasets quickly and reliably, significantly improving performance.
Original PR description
### Description of the issue/feature this PR addresses: Prevent Out of Memory (OOM) crashes and drastically improve execution speed when generating the Swedish SIE4 verification export for massive…
### Description of the issue/feature this PR addresses: Prevent Out of Memory (OOM) crashes and drastically improve execution speed when generating the Swedish SIE4 verification export for massive datasets. ### Current behavior before PR: When exporting a large volume of journal entries (e.g., 190,000+ account moves), the `_export_l10n_se_sie4_verification` method relies on iterating through heavy ORM recordsets and accessing relational child fields (move.line_ids) inside a loop. This triggers a severe N+1 query problem, maxing out server RAM and causing an OOM crash. ### Desired behavior after PR is merged: The method now utilizes a hybrid data extraction approach: - The ORM is used strictly to safely evaluate domains (multi-company rules, dates, states) and fetch a lightweight list of valid move_ids. - A single SQL query with JOIN statements fetches all parent moves, child lines, and account codes in exactly one database query. - itertools.groupby chunks the flat, lightweight dictionary results back into their respective journal entries. The export now handles massive datasets in seconds with minimal memory overhead, while remaining perfectly secure. ### Benchmark: For Memory: | # Input Data | Before PR | After PR | | -------- | -------- | -------- | | ~190,000 moves | MemoryError | 407MB| | ~200,000 moves | 1.8GB | 174.8 MB| For Speed: | # Input Data | Before PR | After PR | | -------- | -------- | -------- | | ~190,000 moves | MemoryError | 5.10s | | ~200,000 moves | 1m29s| 5.3s| ### Reference: opw-6067999 Forward-Port-Of: odoo/enterprise#117577 Forward-Port-Of: odoo/enterprise#113227
This update resolves an issue where appointment scheduling displayed 'no slots available' for future-starting appointments. The fix accurately calculates the displayed month based on the appointment's start date, ensuring correct slot availability is shown in the calendar. This improves the user experience for scheduling appointments that begin in a later month.
Original PR description
The "show only 1 month at a time" optimization computes the navigated month as datetime.now() + month_id, so the controller passes that (month, year) tuple to _get_appointment_slots:…
The "show only 1 month at a time" optimization computes the navigated month as datetime.now() + month_id, so the controller passes that (month, year) tuple to _get_appointment_slots: https://github.com/odoo/enterprise/blob/57ec37b74a60c7e879a8afa66df5ab22a92c5bcd/appointment/models/appointment_type.py#L833 For a punctual appointment whose Allow Bookings range starts in a future month, the first displayed month is start_datetime.month, so the (month, year) tuple doesn't match the month the visitor is looking at. The model fills an empty month and the recovery loop refills the first displayed month (where slots actually live): https://github.com/odoo/enterprise/blob/57ec37b74a60c7e879a8afa66df5ab22a92c5bcd/appointment/models/appointment_type.py#L973-L988 The calendar the visitor just navigated to comes back empty. Compute the navigation base from start_datetime when it lies in the future and keep datetime.now() otherwise. month_id is added on top of that base so it always matches the displayed month index. Introduced by https://github.com/odoo/enterprise/commit/664857dd2c4ae2bc0dde8f44cb94136659ed2fe2 Steps to reproduce: 1. Open the Appointments app 2. Open an appointment type and set Schedule to Weekly and Allow Bookings to On specific dates with a range starting in a future month (for example 1 September to 31 December) 3. Save and click the Preview button in the header 4. Pick a staff member to reach the calendar 5. Click the right arrow to navigate to the next month => the next month shows "Sorry, we have no more slots available for this month" opw-6206293
### Issue In the Italian annual tax report, both VL3/VL4 and VL32/VL33 values could be displayed at the same time However, according to the report logic, only the positive balance should be shown for…
### Issue In the Italian annual tax report, both VL3/VL4 and VL32/VL33 values could be displayed at the same time However, according to the report logic, only the positive balance should be shown for each pair: - VL3 (Tax Due) or VL4 (Tax Credit) - VL32 (Tax Due) or VL33 (Tax Credit) The other one should stay 0 If the global balance is null, both can be 0 ### Cause The lines VL3, VL4, VL32, and VL33 were using the shortcut field `aggregation_formula` directly on the `account.report.line` record This shortcut format does not evaluate or support conditional subformulas like `if_above(EUR(0))` As a result, the report computed and displayed both lines of each pair without filtering out the negative or unwanted values ### Steps to reproduce - Install `l10n_it` and `accountant` and switch to IT Company - Create a balanced Journal Entry for any account - Add the Tax Grid v20 on one of the lines to impact the annual report - Open the `Annual Tax Report (IT)` - Go to the `VL` section - Check the value of VL3/VL4 and VL32/VL33 After the fix, only one value can be positive and the other 0 Ticket [link](https://www.odoo.com/odoo/project.task/6212694) opw-6212694 Forward-Port-Of: odoo/odoo#264294