Tuesday, March 4, 2025
4 changes · 18.0
Enhancements to existing features
Invoices now automatically use the salesperson assigned to the customer when one is set, rather than defaulting to the person creating the invoice. This helps keep sales ownership consistent from customer records through invoicing and improves reporting accuracy.
Original PR description
For `sale.order`, the salesperson (`user_id`) on the order is set to the partner's salesperson (`user_id` on `res.partner`) if set. Currently, `account.move` sets the salesperson (`invoice_user_id`) to the user creating the invoice. With this commit, `invoice_user_id` is set to the partner's salesperson if exists. task-4374265
Bill details fetched from Indian e-invoices are now handled more reliably, including portal attachment limits, reverse charge taxes, and taxes missing from the local setup. Temporary portal errors are also retried automatically, reducing manual follow-up and improving accounting completeness.
Original PR description
This PR introduces the following improvements: - **Attachment Name Update**: Restricts the attachment name to 45 characters to comply with e-invoice portal limitations. - **Handling Missing Taxes**: Includes journal items for taxes not found in the system to ensure proper accounting. - **Enhanced Tax Matching**: Updates the tax-finding mechanism to include RCM taxes when the bill transaction's `RegRev` parameter is marked as `Y`, in addition to regular taxes. - **Error handling**: Handle `EINV30109` error code to schedule a retry cron after 10 minutes and log a message.
Point of Sale now supports configurable limits for how many products and customers are loaded. This helps businesses tune POS performance and data availability based on their store size and operational needs.
Original PR description
- Introduced `ir.config_parameter` settings for product and customer limits in POS. - Refactored partner loading to use configurable customer limit. community PR: https://github.com/odoo/odoo/pull/199923 task-id: 4610131
Accounting report XLSX exports now include a separate currency code column next to foreign-currency amounts. This makes exported reports clearer and helps users identify the currency behind each amount after symbols are lost in spreadsheets.
Original PR description
Issue: When we export a report to xlsx containing some amounts in foreign currency, those amounts are exported as values in the file, and loose any kind of currency symbols. It then becomes impossible to know what currency they were expressed in. Solution: When a column has an expression label with the 'currency' word inside, adds a new column right next to it, with the currency 3 letters code as value. This is done in the accounting reports framework and so is used on all reports using a custom engine. task-4011008