Tuesday, October 29, 2024
6 changes · 17.0
Resolved issues and error corrections
This fix makes it possible again to customize what happens after a sales invoice is created. It helps businesses that rely on tailored invoicing workflows keep their processes working as expected after invoice generation.
Original PR description
opw-3971513
Invoice reports no longer show the extra “on X” wording when there is only one percentage-based tax group. This keeps printed invoice subtotals clearer and consistent with other versions, avoiding unnecessary detail when there is no ambiguity.
Original PR description
Steps to reproduce: - Invoice any product(s) with only one percent based tax - Print the invoice > Check subtotals The mention 'n% on X' appears but other versions don't display this text if only one tax group is applied (Since there is no ambiguity). opw-4110516 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents a spreadsheet crash when users try to view records from a pivot table that has been transformed by another formula, such as transposing it. Instead of using unreliable positions for manipulated pivot results, the option is disabled in those cases to keep spreadsheets stable.
Original PR description
Steps to reproduce: - insert a pivot with more rows than columns - write in a cell =TRANSPOSE(ODOO.PIVOT.TABLE(1)) - right-click on the grand total value => boom When computing which cell of the pivot table is clicked, we assume the matrix comes directly from the ODOO.PIVOT.TABLE(...) function to compute the offsets from the array formula. But it's completely wrong as the cell could at a completely different place if the matrix is manipulated by other functions before being outputted to the grid. Task: 4292134 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a small issue where expense receipt extraction could fail if currency information was not available. Expense processing is now more reliable for receipts that do not include or detect a currency value.
Original PR description
Fix a small issue in 03272333 where the key 'currency_id' is considered as always present, but it's not necessarily the case runbot-104842
This update resolves an issue where external tax calculators were incorrectly processing taxes on down payment invoices. To ensure accurate calculations, down payment invoices no longer send tax information to external calculators, reverting to a standard invoice calculation. This simplifies the process and avoids discrepancies due to tax rounding and exemptions.
Original PR description
This partially redoes odoo/enterprise#64900. Copying tax_ids from the sale order lines to the down payment line on the invoice doesn't work for external tax calculators. Tax percentages returned by…
This partially redoes odoo/enterprise#64900. Copying tax_ids from the sale order lines to the down payment line on the invoice doesn't work for external tax calculators. Tax percentages returned by tax calculators are only informational. When they return e.g. 5% tax, the actual amount can be different from 5% because of differences in rounding or (partial) exemptions. The authoritative tax is returned as a value amount (e.g. $10). Because of this, we cannot rely on Odoo to calculate the tax from account.tax records. It's not always going to match. It's not possible to fix this by externally calculating taxes on the down payment invoice. The single down payment line cannot accomodate all different tax categories. Creating a down payment line per tax category (e.g. avatax_category_id) was considered, but a specific down payment product would need to be created per used tax category which would clutter the database. On top of that, down payment products are removed in later versions [1] which would complicate this approach even further. This solves the issue by not calculating taxes on down payments at all. The down payment invoice will not be sent to external tax calculators. The resulting down payment lines on the SO won't have taxes set, and those lines will be excluded from the request to the external tax calculator. The final, "regular invoice" transaction will happen as if no down payments were made. The down payment lines won't be sent, so this will look like a regular invoice from the external calculator's view. By default, the downpayment lines equal the subtotal of the selected down payment amount. We remove tax_ids from the lines because we cannot count on calculating tax locally (see above). To keep the behavior analogous we override the downpayment wizard to create a single down payment line with a total equal to the entered total in the wizard. [1] odoo/odoo@9aa52dd6418e5881adc2d96d15d062b55d6150c5 opw-3971513
This update enhances the report editor's ability to display placeholder content for 't-out' fields. Previously, developers could manually adjust expressions to avoid placeholders, but now a new 'data-oe-demo' attribute provides a clearer signal for placeholder content within the studio environment, ensuring consistent and correct display.
Original PR description
Some reports have been edited to have qweb default content that was meant to only be used from within studio. ```xml <t t-field="some_field">studio placeholder</t> ``` This content is displayed if the evaluated value is either False or None. This can also happen outside studio, if the field is not required. An attribute `data-oe-demo` was introduced for t-fields. ```xml <t t-field="some_field" data-oe-demo="studio placeholder"/> ``` This attribute was introduced for t-field nodes in order to only display placeholder content inside the report editor. We didn't introduce it for `t-out` as it was possible to change the expression `<t t-out="obj.prop"/>` -> `<t t-out="obj.prop or ''"/>` While this definitely works, the attribute better signals the intent of the change. We thus add support for the attribute on t-out.