Wednesday, May 21, 2025
29 changes · saas-17.4
Enhancements to existing features
Resolved issues and error corrections
Users without Time Off access rights can now open the Overview page without encountering an error. The update adds a safeguard so restricted leave information is handled properly instead of breaking the page.
Original PR description
Steps to reproduce: -login as marc demo or any other user with no time off rights -Navigate to the Time Off app. -Click on "Overview." Issue: A traceback error is encountered. Cause: The leave_id is restricted based on user group, resulting in a false value. In the _fetch_query function, it attempts to use split() or strip() on the name which causes the error because these methods cannot be applied to a boolean value. Solution: check the validation of name before split and strip task-4384350
This update fixes an internal test for the Mail app so it more accurately confirms the number of starred messages after one is deleted. It helps prevent false test results and supports more reliable quality checks without changing user-facing behavior.
Original PR description
Before this PR, the test introduced in 4c9c4a3333b016eaeeac3618c4b9c1c96ab35a69 does not accurately check that the number of starred messages is correct, as it only checks that the shown number of starred messages is 2 not taking into account the possibility of it decrementing subsequently. This PR fixes the issue by introducing a delay that ensures all effects are completed before checking the number of starred messages.
The activity overview no longer shows a filter for completed activities, because completed activities are automatically removed and cannot be listed. This avoids sending users to an empty or misleading result when managing activities.
Original PR description
Removed the "done" filter from the activity view as it does not make sense to filter by activities marked as "done." In Odoo, done activities are automatically deleted https://github.com/odoo/odoo/blob/d2909a47911146f9c45bdea0f927d4132b61879b/addons/mail/models/mail_activity.py#L559 making it impossible to list them when applying this filter. This change prevents confusion for users. Steps to reproduce: Activate developer mode settings/technical/activity overview Filter by "Done" activities opw-4257104 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The marketing automation email template editor now displays correctly when opened from a dialog. This removes an extra scrollbar and lets the snippets panel extend properly, making template creation smoother for users.
Original PR description
How to reproduce ----------------- 1. Inside the marketing automation module, enter any campaign. 2. Click on the title of any of the hierarchy card. 3. From the dialog box, type a new name and then select `Create and edit`. 4. In the `Create Marketing Template` dialog box opened, select the `Event Promo` template. 5. Scroll on the outer scroll bar of the dialog box and you will notice the snippets' box height does not extend to the bottom. Issue ----- - The height of the main marketing template is not set, hence an extra scroll bar appears on the dialog box.  Fix --- - We modify the condition to not set the height attribute when in Dialog box. Task-4137980
This update adjusts spreadsheet-related testing assets to correct a reported issue in the saas-17.4 branch. It helps keep spreadsheet behavior reliable for users by ensuring the underlying test coverage matches the expected behavior.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Subscription invoices now show product names in journal item descriptions again, matching the behavior used for regular sales and purchases. This helps customers and accounting teams more easily understand what each invoice line refers to.
Original PR description
Following odoo/odoo@cf7290cbd8cc the product name have been added back to journal item description, and was updated for sale & purchase module in odoo/odoo@089d96cc3ed2 This commit revert odoo/enterprise@6ba740c2dcd4 so that we follow the same rule and add product name back to subscription's journal items opw-4119507
The Journal Report now displays the account name in the Account column, making entries easier to identify and review. This helps accounting users read reports more clearly without needing to look up account details separately.
Original PR description
The purpose of this pr is to add account name in the Account column of the Journal Report. OPW : 4702276
Miscellaneous changes
## Issue: When converting a lead to an opportunity, a wizard (`crm.lead2opportunity.partner`) is shown. This allows merging duplicated leads. However, if the most recently created lead is selected as the primary, the wizard record may be deleted unexpectedly. This usually goes unnoticed in the UI, as the wizard disappears after the operation. The issue becomes critical when overriding the conversion flow via a custom module or in future changes to the core logic. In those cases, t
Original PR description
## Issue: When converting a lead to an opportunity, a wizard (`crm.lead2opportunity.partner`) is shown. This allows merging duplicated leads. However, if the most recently created lead is selected as…
## Issue: When converting a lead to an opportunity, a wizard (`crm.lead2opportunity.partner`) is shown. This allows merging duplicated leads. However, if the most recently created lead is selected as the primary, the wizard record may be deleted unexpectedly. This usually goes unnoticed in the UI, as the wizard disappears after the operation. The issue becomes critical when overriding the conversion flow via a custom module or in future changes to the core logic. In those cases, the deletion of the wizard can lead to empty recordsets and errors. #### Affected versions: 16.0 and later. ## Explanation The `crm.lead2opportunity.partner` model has a `Many2one` field `lead_id` that is being deleting on cascade which is the default for m2o fields on transient models. During lead conversion, action_apply() calls _action_merge() or _action_convert(). In _action_merge(), non-primary leads are unlinked. If the primary lead is the last created one, it differs from the one referenced by the wizard. This causes lead_id to be unset, triggering the cascade and deleting the wizard. ## Impact: If a custom module overrides action_apply() or _action_merge() and calls super() first, it may operate on an empty recordset, leading to failures when trying to access data or call methods. ## To reproduce: With debugger: - Set a breakpoint on the unlink call inside _action_merge - After unlink, calling self.exists() on the wizard will return an empty recordset With a custom module: - Override action_apply() or _action_merge() - Call super() first - Try to merge leads and select the most recent one as primary - The wizard record will be deleted before your custom logic executes, and will raise a "Record does not exist or has been deleted." OPW-4773172 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209795
Steps to reproduce: - Create a quotation in the Sales app. - Apply a coupon with any discount. - Modify the description of the discount SO line. - Confirm the sale order. - The discount line's description is reset. Root Cause: - `_get_reward_values_discount` recomputes discount line values, resetting the description. Fix: - Preserve the manually set name field to prevent unintended recomputation. Affected version-17.0 opw-4653070 Forward-Port-Of: odoo/odoo#203411
Original PR description
Steps to reproduce: - Create a quotation in the Sales app. - Apply a coupon with any discount. - Modify the description of the discount SO line. - Confirm the sale order. - The discount line's description is reset. Root Cause: - `_get_reward_values_discount` recomputes discount line values, resetting the description. Fix: - Preserve the manually set name field to prevent unintended recomputation. Affected version-17.0 opw-4653070 Forward-Port-Of: odoo/odoo#203411
\*: website_mail This PR addresses several issues in the blog module, including: Commit [1]: retain follow-us input button when logged in. - Steps to reproduce: 1. Go to any blog post. 2. Enable the sidebar. 3. Select any category (e.g., Travel). Issue: A subscribe button appears in the 'Follow Us' section. - Solution: Currently, the input field is only shown to public users. This happens because the input element is restricted by the `base.groups_public` group in the XML code. S
Original PR description
\*: website_mail This PR addresses several issues in the blog module, including: Commit [1]: retain follow-us input button when logged in. - Steps to reproduce: 1. Go to any blog post. 2. Enable the…
\*: website_mail This PR addresses several issues in the blog module, including: Commit [1]: retain follow-us input button when logged in. - Steps to reproduce: 1. Go to any blog post. 2. Enable the sidebar. 3. Select any category (e.g., Travel). Issue: A subscribe button appears in the 'Follow Us' section. - Solution: Currently, the input field is only shown to public users. This happens because the input element is restricted by the `base.groups_public` group in the XML code. Since this is an XML change in v17.0 (stable version), we need to implement the fix in JS instead. After that, we will adapt the code from the master branch. Commit [2]: remove unnecessary months from blog category. - Steps to reproduce: 1. Have a blog post in a category (e.g., Astronomy) published in Feb-2025. 2. In another category (e.g., Travel), have blog posts in both Jan-2025 and Feb-2025. 3. When selecting the Astronomy category, the sidebar `Archives` filter shows all months, even if no blog post exists in Jan 2025. - Solution: It will now show only months that contain blog posts for the selected category. Filter out from the backend according to their publishing date. [1]: https://github.com/odoo/odoo/pull/197172/commits/b844accf13899bd2dbfca6c7592cda092df45bec [2]: https://github.com/odoo/odoo/pull/197172/commits/91cb63ffdad0d18a0c3e2105b978e5107ff3ab99 task-4546888 Forward-Port-Of: odoo/odoo#197172
Problem: In `getAdjacentCharacter`, accessing `focusNode.textContent[focusOffset - 1]` directly fails when there are child nodes between text nodes. Example: Given `<p>ab<span>\u0009</span>\u200B[]</p>`: - `focusNode.childNodes` → [text("ab"), span, text("\u200B")] - `focusNode.textContent` → ["a", "b", "/TAB/", "/ZWS/"] - `focusOffset` → 3 (nodes offset not text offset) - Accessing `focusNode.textContent[2]` is wrong because `focusOffset` counts nodes, not characters, it should return
Original PR description
Problem:
In `getAdjacentCharacter`, accessing `focusNode.textContent[focusOffset - 1]` directly fails when there are child nodes between text nodes.
Example:
Given `<p>ab<span>\u0009</span>\u200B[]</p>`:
- `focusNode.childNodes` → [text("ab"), span, text("\u200B")]
- `focusNode.textContent` → ["a", "b", "/TAB/", "/ZWS/"]
- `focusOffset` → 3 (nodes offset not text offset)
- Accessing `focusNode.textContent[2]` is wrong because `focusOffset` counts nodes, not characters, it should return `/ZWS/` not `/TAB/`.
Solution:
Align with 18.0+ (`html_editor`) behavior by calling `getDeepestPosition(focusNode, focusOffset)` inside `getAdjacentCharacter`.
Steps to reproduce:
1. Type `ab`
2. Press `Tab`
3. Press `Arrow Left` → Caret does not move left as expected.
opw-4720904
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#205745**Description of the issue/feature this PR addresses:** Sets aggregator=None on ir.cron's priority field since aggregating this by summing it up (sum is the default aggregator on Integer fields) gives us no useful information. Removing it has a very minimal performance improvement and would partly address the issue where this field's aggregated value clips over the grouped by field Prior to https://github.com/odoo/odoo/commit/3d9a6ac the width of the first column would be increased in case
Original PR description
**Description of the issue/feature this PR addresses:** Sets aggregator=None on ir.cron's priority field since aggregating this by summing it up (sum is the default aggregator on Integer fields)…
**Description of the issue/feature this PR addresses:** Sets aggregator=None on ir.cron's priority field since aggregating this by summing it up (sum is the default aggregator on Integer fields) gives us no useful information. Removing it has a very minimal performance improvement and would partly address the issue where this field's aggregated value clips over the grouped by field Prior to https://github.com/odoo/odoo/commit/3d9a6ac the width of the first column would be increased in case of grouping list views. This would make the label of the grouped field visible by expanding the first column. However after the mentioned commit, we restrict the min and max widths of the columns which leads to the value of this grouped by field getting clipped by the aggregated column's value. Although the issue primarily exists in 17.4, prior stable versions (16.0 and up) could also benefit from this. **Current behavior before PR:** In 17.4 onwards, the grouped field's table row is clipped by the priority field that gets aggregated   **Desired behavior after PR is merged:** The priority field in `ir.cron` is no longer aggregated thus it does not clip the grouped field.  opw-4536133 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#200943
**Steps to Reproduce:** 1. Install Sales module 2. Create a new quotation in mobile view **Issue:** - The input field of contact is displayed twice due to a missing `t-else` condition, causing both fields to appear simultaneously. **Solution:** - Added the missing `t-else` condition to ensure that only one input field is displayed as intended. opw-4767186 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209017
Original PR description
**Steps to Reproduce:** 1. Install Sales module 2. Create a new quotation in mobile view **Issue:** - The input field of contact is displayed twice due to a missing `t-else` condition, causing both fields to appear simultaneously. **Solution:** - Added the missing `t-else` condition to ensure that only one input field is displayed as intended. opw-4767186 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209017
In this commit, we have addressed a crucial issue related to translation. We discovered that certain key terms in our application were not properly marked for translation, resulting in a lack of support for different languages. To rectify this, we have implemented the necessary changes to make these terms translatable. By doing so, we have successfully resolved the language compatibility problem and improved the overall internationalization of our application. This commit ensures that all terms
Original PR description
In this commit, we have addressed a crucial issue related to translation. We discovered that certain key terms in our application were not properly marked for translation, resulting in a lack of support for different languages. To rectify this, we have implemented the necessary changes to make these terms translatable. By doing so, we have successfully resolved the language compatibility problem and improved the overall internationalization of our application. This commit ensures that all terms, previously overlooked or untranslatable, are now fully accessible for translation, enhancing the localization experience for our users across the globe. task:3358438 Forward-Port-Of: odoo/odoo#210553 Forward-Port-Of: odoo/odoo#127190
<b>Steps to reproduce:</b> 1. Go to Sales > Create a Quotation 2. Add Customer > Set Customer's lang to French or German 3. Add a product, confirm the quotation 4. Click "Create Invoice" > Select "Down Payment (percentage)" 5. Set amount (e.g., 20.5%) and create the invoice <b>Issue:</b> - When creating a down payment invoice using the "percentage" option, description text is translated correctly to partner's language (e.g., French or German), but amount in description remains f
Original PR description
<b>Steps to reproduce:</b> 1. Go to Sales > Create a Quotation 2. Add Customer > Set Customer's lang to French or German 3. Add a product, confirm the quotation 4. Click "Create Invoice" > Select "Down Payment (percentage)" 5. Set amount (e.g., 20.5%) and create the invoice <b>Issue:</b> - When creating a down payment invoice using the "percentage" option, description text is translated correctly to partner's language (e.g., French or German), but amount in description remains formatted using English conventions (e.g. "20.5%" instead of "20,5 %" in French or German). <b>Cause:</b> - This happens because the amount is inserted as a raw float without localization. <b>Solution:</b> - This fix uses `formatLang()` with the correct context to format the percentage amount according to the partner's language (i.e., proper decimal separator). <b>opw-4743326</b> Forward-Port-Of: odoo/odoo#210570
Default code 'OO99999999999' should only be used if no VAT number is present. Task [link](https://www.odoo.com/odoo/project/967/tasks/4724520) task-4724520 Forward-Port-Of: odoo/odoo#207850
Original PR description
Default code 'OO99999999999' should only be used if no VAT number is present. Task [link](https://www.odoo.com/odoo/project/967/tasks/4724520) task-4724520 Forward-Port-Of: odoo/odoo#207850
The failing step is creating a new website, which could take a long time. Increasing the timeout for the next step should prevent the error. runbot-error-104332 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#210121
Original PR description
The failing step is creating a new website, which could take a long time. Increasing the timeout for the next step should prevent the error. runbot-error-104332 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#210121
Run any test of the `TestAnalyticAccount` class in single app: analytic. > Error in the single app setup. ### Cause of the issue: Since neither `account.account` nor the `hr_timesheet` is installed, these lines will crash:https://github.com/odoo/odoo/blob/786cc72a58079dd87f536cedf5c8b9098ff2b885/addons/analytic/tests/test_analytic_account.py#L76-L78 because `core_group_ids` is cls.env['ir.rule'] and `cls.env.user.groups_id` is a `res.groups` record set. runbot-223137 and 223138 --- I
Original PR description
Run any test of the `TestAnalyticAccount` class in single app: analytic. > Error in the single app setup. ### Cause of the issue: Since neither `account.account` nor the `hr_timesheet` is installed, these lines will crash:https://github.com/odoo/odoo/blob/786cc72a58079dd87f536cedf5c8b9098ff2b885/addons/analytic/tests/test_analytic_account.py#L76-L78 because `core_group_ids` is cls.env['ir.rule'] and `cls.env.user.groups_id` is a `res.groups` record set. runbot-223137 and 223138 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#210523
Werkzeug historically prevented sending the same header twice[^1] but a refactor done with Werkzeug 2.0.0 removed that code[^2]. Additionnally `http.server.BaseHTTPRequestHandler.send_response`[^3] always send both the `Server` and `Date` header, no matter if those headers are actually present in the response already. The Werkzeug team is aware (issue 2500) of this issue but they considere **rightfuly** that (1) we shouldn't be using their builtin http server, and (2) that it is a problem to be
Original PR description
Werkzeug historically prevented sending the same header twice[^1] but a refactor done with Werkzeug 2.0.0 removed that code[^2]. Additionnally `http.server.BaseHTTPRequestHandler.send_response`[^3]…
Werkzeug historically prevented sending the same header twice[^1] but a refactor done with Werkzeug 2.0.0 removed that code[^2]. Additionnally `http.server.BaseHTTPRequestHandler.send_response`[^3] always send both the `Server` and `Date` header, no matter if those headers are actually present in the response already. The Werkzeug team is aware (issue 2500) of this issue but they considere **rightfuly** that (1) we shouldn't be using their builtin http server, and (2) that it is a problem to be solved upstream in CPython. We usually don't send those two headers, and let werkzeug/http.server send them for us. But when using `Response.make_conditional`, Werkzeug is gonna force a Date header with the response. This is desirable because the Date is very when doing conditional requests, as the resource might have been created in the past but be still fresh. The result is that when using `Response.make_conditional`, there are 2 Date headers in the response. This is not a problem when the two Date headers have the same value, but nginx is still sending warnings. The operational team here at Odoo wants to get rid of those silly warnings. In this work we silently discard the second Date/Server header in case it has the same value as the first one. And we emit a warning may those two values be different. Note that the header that is discard is the one from the response, and not the one that http.server always send with `send_response`. Ideally we should do the contrary: discard the one of `send_response` and keep the one from the response, but that's more complicated, and we don't need it at the moment. [^1]: pallets/werkzeug:37b3fcc [^2]: pallets/werkzeug:d062807 [^3]: https://github.com/python/cpython/blob/f1967e72498209e42f7cf5eeff0cd84d1ec10d18/Lib/http/server.py#L499-L510 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203422
Related to https://github.com/odoo/enterprise/pull/85952 Forward-Port-Of: odoo/odoo#210767
Original PR description
Related to https://github.com/odoo/enterprise/pull/85952 Forward-Port-Of: odoo/odoo#210767
Steps to Reproduce: --- 1. Create a tax with the following settings: > - Rate: 12% > - Price Included: True > - Affect Base of Subsequent Taxes: False. 2. Create another tax with the following settings: > - Type: Python Code > - Code: result = 22.503 > - Price Included: True > - Affect Base of Subsequent Taxes: False. > - Ensure the sequence of this tax is greater than the 12% tax (this tax is after the 12% tax in order). 3. Create a product with a sales price of 516.00 and
Original PR description
Steps to Reproduce: --- 1. Create a tax with the following settings: > - Rate: 12% > - Price Included: True > - Affect Base of Subsequent Taxes: False. 2. Create another tax with the following…
Steps to Reproduce: --- 1. Create a tax with the following settings: > - Rate: 12% > - Price Included: True > - Affect Base of Subsequent Taxes: False. 2. Create another tax with the following settings: > - Type: Python Code > - Code: result = 22.503 > - Price Included: True > - Affect Base of Subsequent Taxes: False. > - Ensure the sequence of this tax is greater than the 12% tax (this tax is after the 12% tax in order). 3. Create a product with a sales price of 516.00 and assign both taxes to it. 4. Create a new invoice and add the product to the invoice. The total will show an extra 0.01 due to rounding. Cause: --- When applying price-included taxes with multiple taxes, the rounding difference is carried to the last tax to ensure the total matches the product's tax-included price. However, cached values for Python code taxes were used even for the last tax, preventing the rounding correction from being applied. Fix: --- An additional condition was added to ensure cached values are only used when there is no price total checkpoint, allowing the rounding correction to be applied to the last tax. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207665
Suppose an invoice line of 11.0 with 21% tax. The total of the invoice is 13.31. With a cash rounding of 0.05 UP, the total of the invoice becomes 13.35. If we apply an early payment discount of 2% on payments, we expect a discount of 0.25 because 13.35 * 0.98 = 13.08 but 13.10 with the cash rounding. 13.35 - 13.10 = 0.25 However, the cash rounding of the payment register wizard is computed from the total invoice instead of taking the amount stored on the accounting item. Then, he was computi
Original PR description
Suppose an invoice line of 11.0 with 21% tax. The total of the invoice is 13.31. With a cash rounding of 0.05 UP, the total of the invoice becomes 13.35. If we apply an early payment discount of 2% on payments, we expect a discount of 0.25 because 13.35 * 0.98 = 13.08 but 13.10 with the cash rounding. 13.35 - 13.10 = 0.25 However, the cash rounding of the payment register wizard is computed from the total invoice instead of taking the amount stored on the accounting item. Then, he was computing an early payment of 13.35 * 0.02 = 0.27 instead. At the end, the invoice was still open with a residual amount of 0.02. opw-4730764 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207049
Sendcloud and ups_rest miss the override to allow sending the actual type of the carrier (in a recognizable way) to Amazon. opw-4771192 Forward-Port-Of: odoo/enterprise#85993 Forward-Port-Of: odoo/enterprise#84772
Original PR description
Sendcloud and ups_rest miss the override to allow sending the actual type of the carrier (in a recognizable way) to Amazon. opw-4771192 Forward-Port-Of: odoo/enterprise#85993 Forward-Port-Of: odoo/enterprise#84772
Related to https://github.com/odoo/odoo/pull/210767 Forward-Port-Of: odoo/enterprise#85952
Original PR description
Related to https://github.com/odoo/odoo/pull/210767 Forward-Port-Of: odoo/enterprise#85952
Description ----------- Installing the `helpdesk_timesheet` module on databases with millions of `account.analytic.lines` would reach the default memory limit of 2 GiB due to excessive ORM caching. The main memory consumption came from `_check_no_link_task_and_ticket` and `_compute_helpdesk_ticket_id` methods loading large amounts of records into the ORM cache. This commit adds manual column initialization and optimizes constraints to reduce ORM cache memory usage. Reference ------
Original PR description
Description ----------- Installing the `helpdesk_timesheet` module on databases with millions of `account.analytic.lines` would reach the default memory limit of 2 GiB due to excessive ORM caching. The main memory consumption came from `_check_no_link_task_and_ticket` and `_compute_helpdesk_ticket_id` methods loading large amounts of records into the ORM cache. This commit adds manual column initialization and optimizes constraints to reduce ORM cache memory usage. Reference --------- opw-4743742 Forward-Port-Of: odoo/enterprise#85974
In this commit, we have addressed a crucial issue related to translation. We discovered that certain key terms in our application were not properly marked for translation, resulting in a lack of support for different languages. To rectify this, we have implemented the necessary changes to make these terms translatable. By doing so, we have successfully resolved the language compatibility problem and improved the overall internationalization of our application. This commit ensures that all terms
Original PR description
In this commit, we have addressed a crucial issue related to translation. We discovered that certain key terms in our application were not properly marked for translation, resulting in a lack of support for different languages. To rectify this, we have implemented the necessary changes to make these terms translatable. By doing so, we have successfully resolved the language compatibility problem and improved the overall internationalization of our application. This commit ensures that all terms, previously overlooked or untranslatable, are now fully accessible for translation, enhancing the localization experience for our users across the globe. task:3358438 Forward-Port-Of: odoo/enterprise#85864 Forward-Port-Of: odoo/enterprise#43574
NSSF report columns "NSSF Amount Employee" and "NSSF Amount Employer" display pre-computation values which is the amount of payslip lines instead of total amount after the computation of 6% rate. task-4724292 Forward-Port-Of: odoo/enterprise#83613
Original PR description
NSSF report columns "NSSF Amount Employee" and "NSSF Amount Employer" display pre-computation values which is the amount of payslip lines instead of total amount after the computation of 6% rate. task-4724292 Forward-Port-Of: odoo/enterprise#83613
- Generate a new invoice in the menu ‘Accounting > Customers > Invoices’. - Add any product line. - Additionally, add a line of a Note and a line of Section - Confirm the invoicea and send it to CFDI - Click on the option ‘Cancellation request’ and select the reason ‘01’. Click on ‘Create corrective invoice’. The section and note lines disappear from the newly created invoice. In the action_create_replacement_invoice only the lines with display type product are carried over. After this
Original PR description
- Generate a new invoice in the menu ‘Accounting > Customers > Invoices’. - Add any product line. - Additionally, add a line of a Note and a line of Section - Confirm the invoicea and send it to CFDI - Click on the option ‘Cancellation request’ and select the reason ‘01’. Click on ‘Create corrective invoice’. The section and note lines disappear from the newly created invoice. In the action_create_replacement_invoice only the lines with display type product are carried over. After this commit we also include the notes and the sections. opw-4726350 Forward-Port-Of: odoo/enterprise#83578