Thursday, July 3, 2025
4 changes · 18.0
Enhancements to existing features
This update improves the performance of replenishment planning by processing reorder point calculations in batches. It also corrects related purchasing logic so purchase requests are counted accurately and unnecessary database-wide searches are avoided.
Original PR description
The method `orderpoint._compute_qty_order_computed` was batched in commit 17a2de9 then reverted in commit a58b995 because of a bug introduced when purchase_stock is installed. It should still be beneficial performance-wise to batch the calls to `orderpoint._quantity_in_progress` so this commit reintroduces the batching. The part that led to the issue was the override of `_quantity_in_progress` in the purchase_stock module. In this commit we fix the `_quantity_in_progress` method. Thanks to that, the test introduced in 606dc71 is passing even with the batched version of `_compute_qty_to_order_computed`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Aged Partner reports now retrieve invoice dates from the existing accounting line data instead of scanning the related invoice table. This reduces unnecessary database work and can significantly speed up large Aged Receivable or Payable reports, with observed savings of around 10 minutes on very large datasets.
Original PR description
The Aged Partner reports query in `_aged_partner_report_custom_engine_common` is joining on the `account_move` table solely to get the `invoice_date` column. As this `invoice_date` is aggregated in `ARRAY_AGG(DISTINCT invoice_date)` and there's already a denormalized field `invoice_date` on `account_move_line` that is a related stored field, we can drop the join and use this field instead. This saves us the need to scan the account.move table when running the reports query. In a database with 37M amls, 10M account.move (and a really bad correlation for account_move_line.move_id), this saves us around 10 minutes for the Aged Receivable report's query.
The budget generation wizard now lets users choose whether new budgets are for revenue, expenses, or both. This helps companies create budgets that better match their financial planning structure, while keeping the change limited to the wizard workflow.
Original PR description
### Description of the Issue/Feature The budget split wizard currently does not allow the user to specify the type of budget being created, which limits its usability for companies that distinguish…
### Description of the Issue/Feature The budget split wizard currently does not allow the user to specify the type of budget being created, which limits its usability for companies that distinguish between revenue and expense budgeting. ### Current Behavior The wizard generates budgets without considering the nature (type) of the budget. ### Desired Behavior after PR A new field `budget_type` is introduced as a required selection in the wizard, with the options: - Revenue - Expense - Both The selected type is propagated to the resulting `budget.analytic` records. ### Changes Made - Added a `budget_type` selection field to `budget.split.wizard` - Extended `action_budget_split` to store this value on created budgets - Updated the form view to include the new field ### How to Test 1. Open the *Generate Budget* wizard. 2. Select a date range, a period, and one or more analytic plans. 3. Select a budget type. 4. Click "Split". 5. Confirm that created budgets reflect the selected type. ### Notes This change is backward-compatible and isolated to the wizard. It does not modify any core models or affect other modules.
Document requests can now be linked to the correct company when created. This improves accuracy for organizations using multiple companies by ensuring requested documents are assigned to the right business entity by default.
Original PR description
[IMP] documents: Add `company_id` field to the document request wizard This pull request introduces the following improvements to the `documents` module: - Added a `company_id` field to the `documents.request_wizard` model, allowing users to specify the company associated with a document request. - The `company_id` field is set to default to the current company if not provided. - Updated the form view to support multi-company functionality for the `company_id` field. - Incorporated the `company_id` in the document creation process within the `request_document` method, ensuring that documents are associated with the correct company. Related Issues: N/A Task: N/A Technical Review: - The change ensures that documents can now be correctly associated with the company where the request originates, improving the handling of multi-company environments. - No backward compatibility issues are expected as `company_id` is optional and defaults to the current company.