Daily updates from Odoo
Sunday, January 18, 2026
33 changes
2 changes
Resolved issues and error corrections
This update fixes a technical issue where a new fiscal reform field was incorrectly used in the POS module. The change ensures the module aligns with recent legal requirements and automatically installed features. The fix moves the logic to the correct module for optimal functionality and compliance.
Original PR description
`l10n_br_operation_type_pos_id` is a new field introduced in the fiscal reform [1] in saas-18.4. It's added in `l10n_br_edi_pos_fiscal_reform`, but is mistakenly used in `l10n_br_edi_pos`. Because the modules are legally required since the beginning of January and auto-installed it wasn't notice until now. This reverts the change to `l10n_br_edi_pos` and moves the logic to an override in `l10n_br_edi_pos_fiscal_reform`. Additionally, we only do it if the fiscal reform is enabled on the database with `l10n_br_is_icbs`, like we do for all other fiscal reform features. Thanks to ANDG for pointing it out. [1] odoo/enterprise#102835
This update addresses several minor issues within the l10n_hr_edi module, primarily focused on improving the reliability and user experience of fiscal document processing. Specifically, it enhances error handling related to MER API interactions and clarifies settings for multi-company environments, ensuring smoother operations.
Original PR description
- Adjusting error handling for receiving an empty response from MER for a document fiscalization status. - Adding additional checks for running multi-company-wide MER API methods. - Adjusting how approval API call is handled when confirming a bill. - Adding a tooltip about Company BU in MER settings and missing "company dependent" indicators for the credentials. Continuation of task-4925745 Related to opw-5477846 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244357 Forward-Port-Of: odoo/odoo#244023
1 change
Resolved issues and error corrections
This update addresses several minor issues within the l10n_hr_edi module, primarily focused on improving the reliability and usability of the document fiscalization process. Specifically, the system now handles empty responses from the MER API more gracefully and includes enhancements to multi-company operations and approval workflows.
Original PR description
- Adjusting error handling for receiving an empty response from MER for a document fiscalization status. - Adding additional checks for running multi-company-wide MER API methods. - Adjusting how approval API call is handled when confirming a bill. - Adding a tooltip about Company BU in MER settings and missing "company dependent" indicators for the credentials. Continuation of task-4925745 Related to opw-5477846 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244357 Forward-Port-Of: odoo/odoo#244023
4 changes
Resolved issues and error corrections
This update addresses several small issues within the l10n_hr_edi module, primarily focused on improving the reliability and user experience of fiscal document processing. Specifically, it enhances error handling related to API responses and clarifies settings for multi-company environments, ensuring smoother operations.
Original PR description
- Adjusting error handling for receiving an empty response from MER for a document fiscalization status. - Adding additional checks for running multi-company-wide MER API methods. - Adjusting how approval API call is handled when confirming a bill. - Adding a tooltip about Company BU in MER settings and missing "company dependent" indicators for the credentials. Continuation of task-4925745 Related to opw-5477846 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244023
This update ensures that the 'Activity' column in the Follow-up Levels list view only displays when 'Schedule Activity' is enabled. Previously, it incorrectly showed activity even when the option was disabled, leading to potentially confusing data. This change improves the clarity and accuracy of the follow-up level information.
Original PR description
Currently, follow-up levels display an `activity` in the list view even when the `Schedule Activity` option is not enabled on the record. **Steps to reproduce:** - Install the `account_followup`…
Currently, follow-up levels display an `activity` in the list view even when the `Schedule Activity` option is not enabled on the record. **Steps to reproduce:** - Install the `account_followup` module. - Navigate to Accounting > Configuration > Invoicing > Follow-up Levels. - Click `New` and enter a `description`. - Open the `Activity tab`, `enable` Schedule Activity, set an Activity Type and Summary, then `save`. - `Disable` Schedule Activity, `save` the record again, and return to the `list view`. - Observe the `Activity` for the newly created follow-up level. **Observation:** The Activity column still shows a value in the list view, even though Schedule Activity is unchecked. **Root Cause:** At [1], `activity_type_id` is always shown in the list view without considering `create_activity`, causing the `activity` to remain visible even when `Schedule Activity` is `disabled`. **Fix:** This commit ensures that the `Activity` is displayed in the list view only when `Schedule Activity` (`create_activity`) is enabled for the record. [1]: https://github.com/odoo/enterprise/blob/d7882a8f97802d7302d81c1fa375a81bb4ca4717/account_followup/views/account_followup_line_views.xml#L13 opw-5476176 Forward-Port-Of: odoo/enterprise#104427
This update resolves an issue where a warning about eTIMS configuration was incorrectly displayed for companies outside of Kenya. The fix ensures that eTIMS validation only applies to Kenyan companies, improving the user experience and preventing unnecessary alerts.
Original PR description
**Steps to reproduce:** * Install the **l10n_ke_edi_oscu** module. * Use a **non-Kenyan company** (e.g., “My Company (San Francisco)”). * Open any invoice for that company. **Observed behavior:** * A warning about **incomplete eTIMS configuration** is shown on invoices, even though the company is not based in Kenya. **Cause:** * The eTIMS validation logic runs for **all companies**. * Non-Kenyan companies, which do not require eTIMS setup, are still evaluated and trigger the warning. **Fix:** * Run the eTIMS validation only for **Kenyan companies**. * Suppress the warning for companies outside Kenya. opw-5435558 Forward-Port-Of: odoo/enterprise#103158
This update removes an unnecessary restriction that prevented users from inserting records into lists grouped by many2many fields. The change clarifies the process for inserting records from these lists, improving usability and functionality. This resolves a previous bug that was blocking users without a clear reason.
Original PR description
When we introduced the record-specific insertion from a list, we added a limitation on lists grouped by many2many fields but this limitation makes no sense, it only blocks the users without any clear reason. Task: 5267035 Forward-Port-Of: odoo/enterprise#103161
21 changes
Resolved issues and error corrections
This update fixes an issue where appointment dates were displayed out of order in the online booking cart. The problem stemmed from reversing a list of dates, which unintentionally reordered them. The fix ensures dates are formatted correctly for accurate display.
Original PR description
**Steps to produce:** - Install `appointment,website_sale` modules. - Go to website > appointment > Online Cooking Lesson. - Book a slot > Proceed to payment. - Open the cart. **Issue:** - The…
**Steps to produce:** - Install `appointment,website_sale` modules. - Go to website > appointment > Online Cooking Lesson. - Book a slot > Proceed to payment. - Open the cart. **Issue:** - The appointment dates are displayed in an incorrect order in the cart. **Root cause:** - In the linked commit, the logic reverses the `self.name` lines to fix a display issue. - However, since appointment dates are split across multiple lines, reversing the list also unintentionally reverses the appointment date order. **Solution:** - Ensure that the appointment dates are formatted to appear on a single line, preventing them from being split into multiple list entries and incorrectly reordered when the lines are reversed. [commit]: https://github.com/odoo/odoo/pull/223433/changes/5b69176e64e6a4cc46966a8c41b675ed3d98dd0a Before: <img width="554" height="138" alt="image" src="https://github.com/user-attachments/assets/3e13a2a5-61d5-48c5-8e6a-85f313f7b6ca" /> After: <img width="566" height="120" alt="image" src="https://github.com/user-attachments/assets/f0b04592-7fd4-4104-b200-cf9b6f080962" /> opw-5420805 --- Forward-Port-Of: odoo/enterprise#104536 Forward-Port-Of: odoo/enterprise#104100
This update resolves an issue where the system wasn't always creating new VoIP calls when a matching record wasn't found. Now, the system reliably creates a new call if one doesn't already exist, ensuring accurate call tracking and management within the Enterprise module. This improves the overall reliability of our VoIP functionality.
This update ensures that payment terminal responses sent via websocket include a necessary 'session_id'. This resolves an issue where the system couldn't properly track payment sessions, leading to potential errors. The fix improves the reliability of payment processing.
Original PR description
We provide the request data to the payment terminal response to ensure `session_id` exists in the response sent through websocket. Forward-Port-Of: odoo/odoo#244264
This update ensures that manually set currency rates on customer invoices (especially in Germany and Hungary) are correctly applied during the invoice posting process. Previously, the system automatically replaced these rates with standard currency rates, leading to potential inaccuracies. This change maintains the user's intended rate, improving financial reporting.
Original PR description
Initial setup: Install l10n_hu_edi and l10n_de. When creating a customer invoice DE in a foreign currency, a manually edited currency rate was overridden at posting time with the rate from the currency table. Reason: l10n_de overrides `move._post` to assign the `delivery_date`. l10n_hu_edi recompute currency rates when the `delivery_date` changes. Ensure that any manually entered rate is preserved during posting by making sure that l10n_hu_edi override only affect HU moves. task-5391774 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242192
This update corrects a misleading warning displayed on invoices for companies outside of Kenya. The fix ensures that eTIMS validation only applies to companies based in Kenya, preventing unnecessary alerts and improving the user experience. This change simplifies invoice processing for all businesses.
Original PR description
**Steps to reproduce:** * Install the **l10n_ke_edi_oscu** module. * Use a **non-Kenyan company** (e.g., “My Company (San Francisco)”). * Open any invoice for that company. **Observed behavior:** * A warning about **incomplete eTIMS configuration** is shown on invoices, even though the company is not based in Kenya. **Cause:** * The eTIMS validation logic runs for **all companies**. * Non-Kenyan companies, which do not require eTIMS setup, are still evaluated and trigger the warning. **Fix:** * Run the eTIMS validation only for **Kenyan companies**. * Suppress the warning for companies outside Kenya. opw-5435558 Forward-Port-Of: odoo/enterprise#103158
This update corrects a display issue in the Follow-up Levels list view. Previously, an 'Activity' was always shown even when 'Schedule Activity' was disabled. Now, the Activity column only appears when 'Schedule Activity' is actively enabled, ensuring a cleaner and more accurate view of follow-up level details.
Original PR description
Currently, follow-up levels display an `activity` in the list view even when the `Schedule Activity` option is not enabled on the record. **Steps to reproduce:** - Install the `account_followup`…
Currently, follow-up levels display an `activity` in the list view even when the `Schedule Activity` option is not enabled on the record. **Steps to reproduce:** - Install the `account_followup` module. - Navigate to Accounting > Configuration > Invoicing > Follow-up Levels. - Click `New` and enter a `description`. - Open the `Activity tab`, `enable` Schedule Activity, set an Activity Type and Summary, then `save`. - `Disable` Schedule Activity, `save` the record again, and return to the `list view`. - Observe the `Activity` for the newly created follow-up level. **Observation:** The Activity column still shows a value in the list view, even though Schedule Activity is unchecked. **Root Cause:** At [1], `activity_type_id` is always shown in the list view without considering `create_activity`, causing the `activity` to remain visible even when `Schedule Activity` is `disabled`. **Fix:** This commit ensures that the `Activity` is displayed in the list view only when `Schedule Activity` (`create_activity`) is enabled for the record. [1]: https://github.com/odoo/enterprise/blob/d7882a8f97802d7302d81c1fa375a81bb4ca4717/account_followup/views/account_followup_line_views.xml#L13 opw-5476176 Forward-Port-Of: odoo/enterprise#104427
This update fixes an issue where placeholder hint text in the HTML editor would awkwardly wrap onto multiple lines when the screen was narrow. Now, the text is correctly truncated when space is limited, ensuring a cleaner and more professional appearance for users.
Original PR description
Description of the issue this PR addresses: - The placeholder hint text wraps onto multiple lines when the cell width is reduced. - When there is insufficient horizontal space, the text should be truncated rather than wrapped. task-5480080 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244178 Forward-Port-Of: odoo/odoo#243006
This update prevents notifications for other recipients from being incorrectly marked as ‘bounced’ when a single bounce email is received. The issue stemmed from an outdated search domain that matched all notifications linked to a message, even when bounce data was incomplete. This fix ensures accurate notification tracking and avoids unnecessary confusion.
Original PR description
When a bounce is received for one recipient of a message sent to multiple partners, notifications for other recipients can be incorrectly marked as “bounced”. Reproduction Steps: 1. Configure an…
When a bounce is received for one recipient of a message sent to multiple partners, notifications for other recipients can be incorrectly marked as “bounced”. Reproduction Steps: 1. Configure an incoming mail server with a bounce alias. 2. Create multiple contacts with different email addresses. 3. Send a message that notifies multiple contacts. 4. Process a bounce email related to only one recipient. 5. Observe that notifications for other recipients of the same message are also marked as “bounced”. Root Cause: During bounce processing, `MailThread._routing_handle_bounce` builds a search domain to identify which `mail.notification` records should be updated. The original implementation constructed an `OR` domain that could include empty domain elements (`[]`) when some bounce identification data was missing. In Odoo’s domain logic, an empty domain represents a constant “match all” condition. When such a domain is included in an `OR`, the entire expression can match all notifications linked to the message, rather than only those related to the bounced recipient. Fix: The domain used to select bounced notifications is now built dynamically. Criteria are only added when the corresponding bounce identification data is present. opw-5349170 Forward-Port-Of: odoo/odoo#242650
This update resolves a potential error in the accounting system that could occur when calculating tax distributions. The change ensures the system handles the rare scenario where all factors are zero, preventing a traceback and maintaining accurate calculations. This improves system stability and reliability.
Original PR description
In 614dcf23b89 `_distribute_delta_amount_smoothly` was changed to use a half-up round rather than a ceiling, and incorporate an additional step of distributing any remaining cents. However, the step that distributes any remaining cents relies on the assumption that there are less remaining cents than the number of factors. This assumption generally holds true because most cents are already allocated in the first step which uses the `round` function; except in one edge case, which is if all factors are zero. In that case, the `_normalize_target_factors` method will return an all-zero list of normalized factors, and so no cents will be allocated in the first step. The fix is to change `_normalize_target_factors` so that in this edge case, the list of normalized factors allows most cents to get allocated in the first step. See #240136 task-none Forward-Port-Of: odoo/odoo#240616
This update prevents unnecessary requests to OpenStreetMap when warehouse location addresses are invalid. Previously, failed geolocation attempts led to a continuous loop of requests. Now, the system sets default coordinates for invalid addresses, streamlining the location process and improving overall efficiency.
Original PR description
When a warehouse location had no coordinates, a request to geolocate the address was made to OpenStreetMap every time the location selector was open. However, when the address was invalid, the geolocation failed, and no coordinates were set, which caused further geolocation requests being continuously sent. This commit changes the geolocation behavior to set invalid coordinates for the address when the request fails, thus disabling future geolocation attempts for that address. Forward-Port-Of: odoo/odoo#243523
This update resolves an issue where users without administrator privileges couldn't archive channels due to access restrictions. By allowing the use of 'sudo', this change now enables all users to archive channels, streamlining channel management. This improves usability and reduces the need for administrator intervention.
Original PR description
**Purpose of this PR:-** Allow users to archive channels using `sudo` so the action is not blocked by missing discuss role access error. task-5478832 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244247
This update corrects a data inconsistency within Odoo. Previously, Bulgaria was linked to the Bulgarian Lev (BGN). Now, with Bulgaria adopting the Euro as its official currency on January 1, 2026, this PR ensures Bulgaria is correctly linked to the Euro (EUR) within Odoo's system data.
Original PR description
Description of the issue/feature this PR addresses: Bulgaria adopted the euro as official currency as of 2026-01-01. Update the base country data accordingly. Current behavior before PR: In `res_country_data.xml`, Bulgaria is linked to BGN. Desired behavior after PR is merged: Bulgaria is linked to EUR in `res_country_data.xml`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241957
This update fixes a reporting issue where live chat response times incorrectly continued after a customer closed the conversation. The change ensures response times stop when the chat is closed, providing more accurate reporting data. This improves the reliability of live chat performance metrics.
Original PR description
Before this commit, the response time for a live chat conversation did not stop until the operator leaves the conversation, even if the customer had already closed it. This leads to response times that are longer than the conversation duration. The reason for this behavior is that the response time is indiscriminately checking for the first agent message. If the live chat gets closed by the customer without answer, the first message will be "Agent left the channel", posted upon the agent leaving the conversation. Once the conversations is closed the response time should stop as it can be expected that an operator does not pay attention to already closed chats This commit fixes the issue by setting the `time_to_answer` to NULL if the first message is posted after the live chat is closed. task-5117556 Forward-Port-Of: odoo/odoo#244119 Forward-Port-Of: odoo/odoo#242895
This update resolves a test failure within the 'test_discuss_full' module, ensuring accurate time zone handling. The fix explicitly sets the time zone for a test record, preventing a previous assertion error and improving the reliability of our automated tests.
Original PR description
This commit fixes a failing assert in `test_10_init_store_data`. The test fails since [1] due to asserting the value of the OdooBot time zone as False. This commit explicitely sets the time zone of the OdooBot partner record and asserts it. [1] https://github.com/odoo/odoo/pull/210094 runbot-237777 Forward-Port-Of: odoo/odoo#244192
This update fixes a scheduling issue with the autovacuum cron job in Odoo, preventing it from being delayed unnecessarily. The change ensures the cron job correctly reports partial progress, allowing for quicker rescheduling and optimal performance. This improves the efficiency of database maintenance.
Original PR description
**NOTE** the problem regarding the auto-vacuum was fixed in 18.3 and above (including master) at https://github.com/odoo/odoo/pull/216483, this PR now solely exists for branlette intellectuelle. Have…
**NOTE** the problem regarding the auto-vacuum was fixed in 18.3 and above (including master) at https://github.com/odoo/odoo/pull/216483, this PR now solely exists for branlette intellectuelle. Have a ir cron action with the following code: time.sleep(MIN_TIME_PER_JOB) self.env['ir.cron']._commit_progress(remaining=1) return The code looks stupid, but we tracked down a bug we had in the autovacuum cron in 18.3, and the minimum code to reproduce the problem is that above line of code. Since there are remaining stuff to do, the cron worker should report a `PARTIALLY_DONE` status, and reschedule to call the cron action asap. But the system currently determine a `FULLY_DONE` status and reschedule the cron action *later* (next day for a cron with an interval of 1 day). It is pretty bad for the autovacuum cron in 18.3 We used the opportunity to rework the `status` computation to one big match-case, for extra readability. 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#216116
This update resolves an issue where read-only accounting users couldn't access customer statements. The fix corrects a restriction in the system's access controls, ensuring that all authorized users, regardless of their permissions, can view customer statements. This improves usability for a wider range of users.
Original PR description
Steps to reproduce: - Have a user with Accounting rights set to 'Read-only' - Login with the user - Open customer record - Button 'Customer Statement' won't be there Analysis: This occurs because we restrict the button visibility to 'Invoicing' users, even if all fields and views are accessible also for 'Read-only' users. opw-5357692 Forward-Port-Of: odoo/enterprise#103715 Forward-Port-Of: odoo/enterprise#102683
This update resolves a technical issue that caused a traceback error when employees removed their selected pay category in the payroll settings. The fix ensures the system handles the removal of pay category selections correctly, preventing errors and improving payroll stability.
Original PR description
Fixed a traceback bug that appears when removing unselecting the Pay Category in the Employee's form payroll tab Steps to reproduce: - Select a pay category for an employee - Delete your selection - Traceback appears Cause: _compute_display_be checks on the name of the structure_type_id without checking that this field is not null, producing a bug when its value is removed task-5453432 Forward-Port-Of: odoo/enterprise#104422
This update ensures that survey data exports retain the original formatting of answers, even after question types are changed. Previously, modifying a question type could cause issues with existing data exports. Now, the system consistently uses the stored answer type's formatting, guaranteeing accurate historical reporting.
Original PR description
Current behavior before PR: - Survey spreadsheet export derived date and datetime formatting from the current question type. - Changing a question type after submission (date to datetime) could lead to incorrect formatting or export errors for existing answers. Desired behavior after PR is merged: - Spreadsheet export now derives value conversion and formatting from the stored answer type instead of the question definition. - Historical answers keep their original date or datetime format, even if the question type is modified later. Task: [5410758](https://www.odoo.com/odoo/project/2328/tasks/5410758) Forward-Port-Of: odoo/enterprise#104472 Forward-Port-Of: odoo/enterprise#102930
This update resolves a display problem in the General Ledger report when using analytic accounting. Previously, the report showed incorrect information and linked to the wrong journal entries. The fix ensures the General Ledger accurately reflects analytic distributions and provides the correct journal entry links.
Original PR description
Issue: Inconsistent use of line ID in the general ledger between account_move_line.id and account_analytic_line.id Step to reproduce: - Activate analytic accounting - Go to Accounting Report ->…
Issue: Inconsistent use of line ID in the general ledger between account_move_line.id and account_analytic_line.id Step to reproduce: - Activate analytic accounting - Go to Accounting Report -> General Ledger -> Options - Activate "Analytic Group By" - Create an invoice - add a line with an analytic account - Confirm the Invoice - Duplicate the invoice - Confirm the second invoice - Go to the General Ledger - Group By the analytic account you used Current Behavior: General Ledger display 2 lines per journal entry being part of the analytic distribution used for the group by. The first line displays the part related to the analytic group by, while the second line display infos for global general ledger. Clicking on the dots of the first line -> "View Journal Entry" send you to an unrelated entry. Expected behavior: - "View Journal Entry" should send to the right entry Proposed Solution: To proceed to the group_by, `_prepare_lines_for_analytic_groupby` create a temporary SQL table. This table uses the account_analytic_line.id as if it was the account_move_line.id. This commit fixes this and goes back to account_move_line.id. However, lines are merged into only one single line. opw-5267981 Forward-Port-Of: odoo/enterprise#104314 Forward-Port-Of: odoo/enterprise#103169
This update streamlines the process for inviting users to channels. The redundant 'Invite People' button has been removed from channel types with member lists, consolidating the invitation option within the member list panel. This improves the user experience by reducing clutter and ensuring a consistent flow.
Original PR description
*=im_livechat Previously, channels with `memberList` had two ways to invite new users — one through the header action button and another via the member list panel. This caused redundancy since both performed the same action. This commit removes the header invite button for channel types that already have a member list and keeps only the invite option inside the member list panel. The behavior for chat-type channels remains unchanged. In addition, the invite button in the member list panel now opens a proper dialog instead of a popover. Invite buttons in other areas, such as the sidebar and chat window actions, remains unchanged for ease of access enterprise: https://github.com/odoo/enterprise/pull/98457 Task-5406953 Forward-Port-Of: odoo/odoo#233389
This update streamlines the process of inviting new users to WhatsApp channels by utilizing the existing member list panel invite button. Previously, a separate invite action was causing issues, and this change ensures a more consistent and reliable user experience. It resolves a technical bug identified in a related update.
Original PR description
After https://github.com/odoo/odoo/pull/233389, we rely on the member list panel's invite button to invite any new user and remove the dedicated invite action form the thread header action list for all channel type that have member list. This commit adapts the failing test for the same. community: https://github.com/odoo/odoo/pull/233389 Task-5406953 Forward-Port-Of: odoo/enterprise#98457
3 changes
Resolved issues and error corrections
This update resolves an issue where Odoo's PWA support was failing in certain customized browsers like Wecom and DingTalk. The fix ensures Odoo correctly identifies Safari versions, allowing for smoother PWA functionality across a wider range of user environments. This enhances the overall user experience for Odoo users on these platforms.
Original PR description
Desired behavior after PR is merged: In some customized browsers, such as Wecom and DingTalk, the userAgent may not contain the Version information, resulting in an error. 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
Issue: When using negative amounts, for example to explicitly show a discount, the tax calculation is incorrect due to the application of the `abs` function. Furthermore, the way to find out if a tax is of the withholding type is based on the sign of the value, which can lead to error in these cases. Cause: A previous change (#237235) added the `abs` function so the 'TotalTaxesWithheld' would be always with positive value. But this also affects the calculation of taxes 'TotalTaxOutputs'
Original PR description
Issue: When using negative amounts, for example to explicitly show a discount, the tax calculation is incorrect due to the application of the `abs` function. Furthermore, the way to find out if a tax…
Issue:
When using negative amounts, for example to explicitly show a discount, the tax calculation is incorrect due to the application of the `abs` function. Furthermore, the way to find out if a tax is of the withholding type is based on the sign of the value, which can lead to error in these cases.
Cause:
A previous change (#237235) added the `abs` function so the 'TotalTaxesWithheld' would be always with positive value. But this also affects the calculation of taxes 'TotalTaxOutputs' in some cases, such as if the invoice line has negative values.
Steps to reproduce:
- Install `l10n_es_edi_facturae`
- With the ES company, create an invoice with some standard lines and one line with negative amounts, as an explicit discount
- Confirm the invoice and send (facturae)
- Open the XML attached in the chatter
- Observe that the taxes amounts (VAT and WITHHOLDING) are erroneous
A correct invoice should be for example:
```
Product Price Taxes Amount
---------------------------------------------
PRODUCT-A 1000 21%VAT 15%WHI 1000
Discount -100 21%VAT 15%WHI -100
---------------------------------------------
Untaxed amount 900
Withholding 15% -135
VAT 21% 189
-----------------------
TOTAL 954
```
---
I confirm I have signed the [CLA](https://github.com/odoo/odoo/pull/157955) and read the PR guidelines at www.odoo.com/submit-prThis update addresses minor issues within the l10n_hr_edi module, specifically improving the handling of fiscalization requests and multi-company API calls. The changes enhance the system's reliability and accuracy when processing invoices, particularly related to approval workflows and company configurations.
Original PR description
- Adjusting error handling for receiving an empty response from MER for a document fiscalization status. - Adding additional checks for running multi-company-wide MER API methods. - Adjusting how approval API call is handled when confirming a bill. - Adding a tooltip about Company BU in MER settings and missing "company dependent" indicators for the credentials. Continuation of task-4925745 Related to opw-5477846 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244357 Forward-Port-Of: odoo/odoo#244023
2 changes
Resolved issues and error corrections
This update corrects a display issue in the Follow-up Levels list view. Previously, an 'Activity' was shown even when 'Schedule Activity' was disabled. Now, the Activity column only appears when 'Schedule Activity' is actively enabled, ensuring a cleaner and more accurate view of follow-up level details.
Original PR description
Currently, follow-up levels display an `activity` in the list view even when the `Schedule Activity` option is not enabled on the record. **Steps to reproduce:** - Install the `account_followup`…
Currently, follow-up levels display an `activity` in the list view even when the `Schedule Activity` option is not enabled on the record. **Steps to reproduce:** - Install the `account_followup` module. - Navigate to Accounting > Configuration > Invoicing > Follow-up Levels. - Click `New` and enter a `description`. - Open the `Activity tab`, `enable` Schedule Activity, set an Activity Type and Summary, then `save`. - `Disable` Schedule Activity, `save` the record again, and return to the `list view`. - Observe the `Activity` for the newly created follow-up level. **Observation:** The Activity column still shows a value in the list view, even though Schedule Activity is unchecked. **Root Cause:** At [1], `activity_type_id` is always shown in the list view without considering `create_activity`, causing the `activity` to remain visible even when `Schedule Activity` is `disabled`. **Fix:** This commit ensures that the `Activity` is displayed in the list view only when `Schedule Activity` (`create_activity`) is enabled for the record. [1]: https://github.com/odoo/enterprise/blob/d7882a8f97802d7302d81c1fa375a81bb4ca4717/account_followup/views/account_followup_line_views.xml#L13 opw-5476176 Forward-Port-Of: odoo/enterprise#104427
This update enhances the clarity of expense bills by leveraging payment reference notes. Previously, payment term line names were blank for company account expenses. Now, user-entered notes from the payment reference field are displayed, providing better context and traceability in accounting records. This aligns with standard invoice practices.
Original PR description
Currently, when creating a bill from an expense with payment_mode='company_account', the payment term line's name is set to an empty string because expenses are immediate payment expenses. However, users may enter notes in the payment_reference field. The account.move.line's `_compute_name` ([1](https://github.com/odoo/odoo/blob/3f4e45ecaca46a98c904536658728a1f1571bdbd/addons/account/models/account_move_line.py#L520)) method uses payment_reference to compute the name for payment term lines. By setting the name in needed_terms from payment_reference, the payment term line will display the user's notes, providing better context and traceability in the accounting entries. This change ensures consistency with the standard invoice behavior where payment_reference is used to populate the payment term line name. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241353