Daily updates from Odoo
Thursday, February 26, 2026
40 changes · 18.0
New functionality added to Odoo
This update incorporates exchange rates from the Central Bank of Cuba (BCC), expanding Odoo's currency coverage. This allows businesses operating in or trading with Cuba to accurately reflect currency conversions, improving financial reporting and transaction accuracy. The change was made to support a wider range of international business operations.
Original PR description
This commit introduces a new exchange rate provider for the Central Bank of Cuba (BCC). - Implement new exchange rate provider for Central Bank of Cuba (BCC) - Retrieve rates from official BCC source - Reference: https://www.bc.gob.cu/tasas-de-cambio (official published data and documentation) - Parse and normalize published currency values - Support multiple rate types (official, public, special)" Forward-Port-Of: odoo/enterprise#108367
Enhancements to existing features
This update streamlines bank account creation for trusted partners, prompting manual verification to ensure accuracy and prevent errors. It simplifies the process by automatically finding suitable bank accounts and preventing duplicate entries, improving reconciliation and payment accuracy.
Original PR description
Forward-Port-Of: odoo/odoo#249983
This update optimizes how Odoo handles locale data, reducing unnecessary file searches. Previously, Odoo was repeatedly checking for locale files even when the data wasn't being used, leading to slower performance. This change adds a caching mechanism to avoid these redundant checks, improving overall system speed.
Original PR description
`babel.Locale.parse` checks if a locale is valid by calling `os.path.exists` on the resolved filename for the locale (this is done in `babel.localedata.exists`). Babel does have a locale cache which it checks, but currently that cache is only populated when the locale is actually loaded[^1], therefore in cases where we instantiate a significant number of locales but never actually need to load locale data (e.g. formatting a significant number of datetimes, in qweb, using only non-localised patterns) this results in severe FS traffic for no reason. [^1]: python-babel/babel#1254 has been submitted to fix this issue Forward-Port-Of: odoo/odoo#249795
This update reduces the time and resources used by Odoo's automated tests. By consolidating setup steps and suppressing unnecessary logging, the changes improve test execution speed and stability. This translates to faster development cycles and more reliable test results.
Original PR description
- move a bunch of expensive setUp to setUpClass - backport #152378 to avoid password keying in 17.0 also Forward-Port-Of: odoo/odoo#250667
This update streamlines the initial setup process for tests across several core Odoo modules, including accounting, payroll, and timesheets. By centralizing this setup, the team has improved the reliability and consistency of test results, leading to faster identification and resolution of potential issues. This change enhances the overall quality and stability of the Odoo Enterprise platform.
Original PR description
Forward-Port-Of: odoo/enterprise#108739
This update incorporates changes required by the Uruguayan tax authority (DGI) regarding Electronic Fiscal Document (CFE) reporting. Specifically, a new selection option is added for export transactions, and the transmission of key invoice details (date, amount, currency, and exchange rate) from existing account moves is now mandatory to ensure legal compliance.
Original PR description
Purpose: The DGI introduced changes in CFE version 25. The following changes below needs to be implemented for legal compliance.
Required Changes:
- Introduce a new selection value,("91", "Export under Mandate")for field, l10n_uy_edi_cfe_sale_mode. This option is required when documenting export operation performed as a mandating entity, where the definitive export will be carried out by a third party.
- The reference document(credit note or debit note) of an existing account move will need to send:
- Amount (MntCFEref)
- Currency (TpoMonedaRef)
- Exchange Rate (TpoCambioRef) if the currency is not Uruguayan Pesos
task-5419331
task-5419331
Forward-Port-Of: odoo/enterprise#103881Resolved issues and error corrections
This update resolves an issue where the delivery screen would unexpectedly gain focus when no delivery location was selected. This improvement ensures a smoother user experience for delivery personnel, preventing distractions and improving efficiency. It corrects a minor usability problem.
This update fixes an issue where sales order statuses were displayed in an incorrect alphabetical order within the Kanban view. The change ensures that statuses appear in the logical order (Cancelled, Quotation, Sale Order, Quotation Sent) as expected, improving the user experience and data clarity. This was a minor visual inconsistency resolved through a code adjustment.
Original PR description
Steps to produce: --- - Install sales module. - Open sales module > orders > switch to kanban view. - Then make it group by status. Observation: --- - The order of status is not proper. - It comes as…
Steps to produce: --- - Install sales module. - Open sales module > orders > switch to kanban view. - Then make it group by status. Observation: --- - The order of status is not proper. - It comes as Cancelled, Quatation, Sale order, Quatation sent. Root cause: --- - When we perform Group By > Status, the method `web_read_group()` is executed. then in chain `_web_read_group()` calls `read_group()` without providing any explicit `orderby`. Inside `read_group()`, if orderby is not provided, it sets the order to the grouped field itself. - Inside `_read_group()`, the SQL query constructed with an order by clause on the grouped field (state). Therefore, the values are retrieved in alphabetical order as `cancel, draft, sale, sent`. Solution: --- - Define `group_expand` on the `state` field. During `read_group()`, `_read_group_fill_results()` calls this method and reorders the groups accordingly. - This overrides the alphabetical SQL order returned by `_read_group()` and ensures the correct logical status order in Kanban view. opw-5497664 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248776
This update fixes a recurring issue where posting multiple images to Instagram failed due to delays in the image carousel processing. The change ensures Odoo waits for the carousel to fully load before posting, aligning with Facebook's documentation. This improves the reliability of Instagram posting for users.
Original PR description
Bug === When posting many images on Instagram, it fails most of the time. The reason is that Instagram takes some times to process our carousel, and according to the documentation we can wait for it to be ready. See https://developers.facebook.com/docs/instagram-platform/content-publishing#carousel-posts Task-5972197
This update resolves an issue where the ZATCA XML file generation would fail when an order was fully discounted and had no associated payment. This change ensures that ZATCA reporting continues to function correctly, even in scenarios with zero payment amounts, avoiding potential reporting delays.
Original PR description
Before this commit, when an order was fully discounted and therefore had no payment, the generation of the XML file for ZATCA would fail. opw-5928185 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249233
This update resolves an issue causing table menu buttons to appear incorrectly or not at all within the HTML Editor. The fix ensures proper display and positioning of these buttons, improving the user experience when working with tables.
Original PR description
Description of the issue: Commit [1] replaces `overlay` with `localOverlay` for the table menu. However, studio uses its own `wysiwyg` instance and config, which does not define `localOverlayContainers`, causing a traceback when `table_menu` accesses `this.config.localOverlayContainers.key`. Solution: - Define `localOverlayContainers` and its corresponding key in studio’s `wysiwyg` config. - Additionally, adjust the table menu position calculation when the table cell is inside an iframe. ENT PR: https://github.com/odoo/enterprise/pull/108724 [1]: https://github.com/odoo/odoo/commit/7d523d6402c9bff3c2e4bcd0329f486a2d0f45ec
This update resolves an issue preventing power buttons from appearing in Odoo Studio reports. The fix defines a necessary configuration element within the Studio interface, ensuring correct functionality and a smoother report editing experience. It also includes minor adjustments for table menu positioning.
Original PR description
Description of the issue: Commit [1] replaces `overlay` with `localOverlay` for the table menu. However, studio uses its own `wysiwyg` instance and config, which does not define `localOverlayContainers`, causing a traceback when `table_menu` accesses `this.config.localOverlayContainers.key`. Solution: - Define `localOverlayContainers` and its corresponding key in studio’s `wysiwyg` config. - Additionally, adjust the table menu position calculation when the table cell is inside an iframe. - Also Before `localOverlayContainers` was not defined in studio, so power buttons did not appear in studio reports. Now that `localOverlayContainers` is defined, power buttons must be excluded from the main plugin to prevent them from appearing inside studio. Community PR: https://github.com/odoo/odoo/pull/250645 [1]: https://github.com/odoo/odoo/commit/7d523d6402c9bff3c2e4bcd0329f486a2d0f45ec
This update resolves an issue where rejected E-Faturas (Romania's electronic invoices) couldn't be corrected or resubmitted to the SPV. Now, if an invoice is flagged as invalid by the SPV, users can reset the invoice to draft and re-send it, streamlining the invoicing process and reducing manual intervention.
Original PR description
**Steps to reproduce:** - Install Accounting and l10n_ro_edi - Switch to a Romanian company (e.g. RO Company) - In Accounting settings, configure Romanian E-Factura - Create an invoice for a Romanian customer - Confirm the invoice - Send E-Factura to SPV **Issue:** If the document is rejected by SPV due to a validation error, it is not possible to: 1) reset the invoice to draft in order to fix the error in the invoice because the button is hidden 2) resend the new E-Factura to SPV because the option is disabled **Solution:** Check if there are Romanian E-Factura documents linked to the invoice and if they are all rejected. If it is the case, then allow to reset the invoice to draft and to resend E-Factura to SPV. opw-5936668 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures that attachments sent via mass emails (like event invitations) are correctly linked to the corresponding event record. Previously, users lacked access to download these attachments, creating a workaround needed with system rights. This fix resolves a data access issue, ensuring consistent functionality.
Original PR description
**Steps to reproduce:** - Install Event app - Log as a user with Events/Administrator rights - Ensure its Administration rights are not set to Settings - Go to an open Event - Add a new attendee with mail - Ticket is automatically sent, and logged in chatter - User doesn't have the rights to download the file from the chatter **Issue:** User has no 'read' access to `ir.attachment` due to a missing related record (res_model and res_id are set to "mail.message" and 0 instead of the `event.registration` record). It can be bypassed when the user also has system rights (or is the sender) and it works properly when sending manually the mail. **Fix:** Reapply the fix used in 19.0+. (We could also hide the attachment in chatter when it is not linked properly) related: https://github.com/odoo/odoo/commit/19c78b2585cec9473ad2d2ab9101235c45a03314 opw-5349820
A customer reported a significant delay (8 minutes) when adding attribute values to products. This update replaces inefficient code with faster filtering methods, reducing the process to 2-3 minutes. This improves performance for users managing large numbers of product attributes.
Original PR description
opw-4876370 Issue: A customer who uses many attribute values complained that the "add to products" button on product attribute values in their database was really slow (8 minutes or so). Upon investigation I found parts of the involved functions used iteration over a set of records, which proved notably slower to psql searches. Fix: Replacing the code with what I believe is equivalent operations making use of the `search` method to filter through the sets much quicker. Behaviour after fix: The process takes 2-3 minutes when running this commit on the aforementioned database, but it's still a major improvement compared to the previous time. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where newly hired employees were incorrectly inheriting their private email address as their work email. The solution ensures the employee's work email field is cleared during the contract signing process, preventing this duplication. This ensures accurate email data for new employees.
Original PR description
**Steps to Reproduce:** 1. Send an offer to an applicant. 2. The applicant submits their details via the salary configurator and enters their private email in the Email field. 3. Once the offer and contract are signed, an employee record is created in Odoo. 4. In the created employee record, the `work_email` field is populated with the email entered in the salary configurator. This same value is also present in `private_email`, which is correct. **Reason:** - The email entered in the salary configurator is stored on the partner and represents the applicant's private email. - The employee's `work_email` field is linked to the partner's email via compute and inverse methods, causing it to inherit the private email value when the employee record is created. **Solution:** - Explicitly clear the employee's work_email field when the applicant sign. task: 5502797 Forward-Port-Of: odoo/enterprise#108698 Forward-Port-Of: odoo/enterprise#106974
This update fixes inaccuracies in the Bulgarian tax settings within Odoo. Specifically, it corrects incorrect tax names and changes the default purchase tax rate from 20% PTC to the standard 20% FTC, aligning with current Bulgarian regulations. This ensures accurate tax calculations for Bulgarian businesses using the Odoo system.
Original PR description
Fixing incorrect tax names and changing the default purchase tax to 20% FTC instead of 20% PTC. task-5935754 Forward-Port-Of: odoo/odoo#249269
This update resolves an issue where rapidly clicking the 'Back' button during barcode internal transfer creation resulted in duplicated quantities being added to the transfer. The fix ensures that multiple 'Back' clicks don't trigger redundant saving operations, preventing incorrect quantity calculations.
Original PR description
**Steps to reproduce:** * Install `stock` module. * Go to the > Settings*, enable *Packages* and *Storage Locations*(warehouse). * Create a storable product and set *Tracking Inventory* to **By…
**Steps to reproduce:** * Install `stock` module. * Go to the > Settings*, enable *Packages* and *Storage Locations*(warehouse). * Create a storable product and set *Tracking Inventory* to **By Quantity** and set some *barcode* * Update the on-hand quantity for the product and assign it to one packages. * Open *Barcode > Operations > Internal Transfer* and create a new transfer. * Click the *gear icon* in the top-right corner to open the barcode scanning flow. * manually enter the created product barcode and apply it. * Click the **Back** button multiple times in quick succession. * Go to the backend and open the created internal transfer. **Observed behavior:** * The internal transfer is created with *double quantities* compared to what was added in the barcode interface. **Cause:** * When clicking the *Back* button, the following flow is triggered: `exit()` → `beforeQuit()` → `save()`. https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/components/main.js#L406-L414 https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/models/barcode_model.js#L473-L475 https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/models/barcode_picking_model.js#L828-L832 https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/models/barcode_model.js#L477-L483 * If the button is clicked multiple times rapidly, `exit()` is called again before the previous `save()` RPC completes. * This results in multiple `save()` calls being executed, causing duplicated quantities on the picking. reference - https://github.com/odoo/enterprise/pull/103999/changes/b791239c154deb6a25f85d65ebc72e3ac53b6c74 **Fix:** * Prevent rapidly clicking the Back button multiple times does not multiply quantities. --- opw-5375899 Forward-Port-Of: odoo/enterprise#103130
This update quietly handles errors that occur during tour termination, specifically 'AssetsLoadingError' which represents lazy-loaded assets. This prevents disruptive error messages from appearing to users and ensures a smoother experience after tours have finished. It's a refinement of previous work to manage asset loading failures.
Original PR description
Similarly to commit https://github.com/odoo/odoo/commit/493bab4f460dd4069d5cb6805933b8088067ff17 hiding "failed to fetch" errors, this commit adds AssetsLoadingError as those represents "just" another category of failed assets request (i.e. lazy loaded) after tour termination. runbot-233826 Forward-Port-Of: odoo/odoo#248003
This update fixes an issue where sales team members couldn't see stages they were assigned to within their CRM pipeline. The change ensures that team-specific stages are correctly displayed for all users, improving workflow visibility and collaboration within the sales process. This resolves a previous limitation where only administrators could view these stages.
Original PR description
**Steps to reproduce:** 1. Install `crm` 2. Assign a user to the sales team from crm > sales team 3. Now, create a stage and add that team to this stage from crm > Stages **Issue:** - The stage assigned to a Sales Team is not visible in "My Pipeline" for users belonging to that team. The stage is only visible to admin users if they have records **Cause:** - The stage domain in the pipeline view only considers the `default_team_id` from the context. This ignores the Sales Teams of the current user, causing team-specific stages to be incorrectly filtered out for non-admin users. **Solution:** - Extend the stage domain to include all Sales Teams of the current user when explicitly requested via context. like we did in v19 https://github.com/odoo/odoo/commit/0c0ccde96facfd6c4f823da33c52e3994b36a028 opw-5444009 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a bug in the web editor that prevented users with RTL languages (like Arabic) from dropping snippets outside of designated dropzones. The fix adjusts the detection logic to account for the sidebar's left-aligned positioning in RTL layouts, ensuring proper functionality across all language settings.
Original PR description
When dropping outside a dropzone but still on the page, the code checks if the drop happened well outside of the sidebar (so on its left). However, in RTL languages, the sidebar is positioned on the left, so we need to check if the drop is on the right side of it instead. The fix checks if the sidebar is at the left edge (the body of the document should have the `o_rtl` class) and verifies the drop position is on the right of the sidebar. Steps to reproduce: - Set your profile to Arabic - Drag and drop a snippet outside of a dropzone => It's not dropped, but it should, as it would with an LTR language. task-5484936
This update corrects a Peppol invoice validation error caused by an incorrect code scheme identifier for UNSPSC products. The fix ensures invoices comply with Peppol standards, preventing rejection by external systems. This improves the reliability of our Peppol-compliant invoices.
Original PR description
**Steps to reproduce:** * Install the **product_unspsc** module. * Create a product with a **UNSPSC category**. * Create and post an invoice for this product. * Send the invoice via **Peppol**.…
**Steps to reproduce:** * Install the **product_unspsc** module. * Create a product with a **UNSPSC category**. * Create and post an invoice for this product. * Send the invoice via **Peppol**. **Observed behavior:** * Peppol validation fails with error **[BR-CL-13]**: *“Item classification identifier identification scheme identifier MUST be coded using one of the UNTDID 7143 list.”* * The XML uses `listID='UNSPSC'` in `cbc:ItemClassificationCode`. **Cause:** * The `listID` attribute was set to the literal string **'UNSPSC'**. * According to the **UNCL7143** code list, the correct scheme identifier for UNSPSC is **'TST'**, not 'UNSPSC'. **Fix:** * Replace `listID='UNSPSC'` with `listID='TST'` when generating the commodity classification node. * Update and extend tests to validate the correct scheme identifier. * Same for CPV code from the documentation i's code is also changed to 'STI'. ref: https://docs.peppol.eu/poacc/billing/3.0/codelist/UNCL7143/ opw-5948723
This update resolves inconsistencies in how bank accounts are created and found within Odoo. The changes streamline the process, ensuring accurate bank account management across key modules like invoicing and payments. This improves data reliability and simplifies financial operations.
Original PR description
*: account_invoice_extract,hr_constract_salary,payment_sepa_direct_debit Forward-Port-Of: odoo/enterprise#108238
This update fixes an issue where SII invoices weren't correctly formatted, preventing successful transmission of invoices. The update replaces specific XML elements in the DTE template to align with SII's requirements, ensuring invoices are accepted by the SII system. This ensures compliance with Chilean tax regulations.
Original PR description
Link to SII API Documentation: https://www.sii.cl/factura_electronica/formato_dte.pdf Problem: The DTE template was using incorrect XML elements for withholdings when confirming an invoice with SII. This fix replaces: ImptRetOtrMnda -> ImpRetOtrMnda ValorImpOtrMnda -> VlrImpOtrMnda so the generated DTE matches SII specifications. OPW-5437484 Forward-Port-Of: odoo/enterprise#105152
This update resolves a technical issue that prevented e-invoices from being correctly generated for individual customers in Romania. The problem stemmed from incorrect VAT number data being stored, leading to a traceback. This fix ensures accurate e-invoice creation for all customer types.
Original PR description
Issue: Sending e-Invoice for a customer as individual (no VAT) creates a traceback. Steps to reproduce: - In Romania company (l10n_ro_edi) - Create a partner as Individual - Create an invoice for this partner - Confirm it - Send it to SPV => Traceback Cause: Individuals don't have VAT numbers. It's stored as '/' or as False. If it's False it creates a traceback. opw-5967012 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects an issue where time tracking data wasn't properly handling time zones, leading to potential inaccuracies in employee attendance records. The fix ensures all time entries are consistently recorded with the correct time zone, improving the reliability of HR data and reporting. This enhances the accuracy of payroll and workforce management.
Original PR description
TODO
This update corrects a visual issue in the planning app and related modules where employees with flexible calendars incorrectly displayed unavailable days. The fix ensures that flexible resources are shown as available unless public holidays or leaves are present, improving accuracy and usability. This resolves a discrepancy in how Odoo interprets work schedules.
Original PR description
### Issue: When an employee has a flexible calendar, its gantt view in planning and other modules, like project or time off, shows incorrect grayed-out days. In general, employees with a flexible…
### Issue:
When an employee has a flexible calendar, its gantt view in planning and other modules, like project or time off, shows incorrect grayed-out days. In general, employees with a flexible calendar should not have any grayed out days other than public holidays.
### Steps to reproduce:
- Create a new work schedule:
- Flexible Hours
- 24 hours per week
- 8 average hours per day
- Create an employee with this work schedule
- Open Planning app
- Only the three first days of the week are not grayed out
### Cause:
With 24 hours per week, the worked time can be done in three days. Odoo considers that the first three days of the given time frame are worked, but the others aren't. This result is returned by `_work_intervals_batch()`. In `_unavailable_intervals_batch()` we then build the unavailabilities by taking the inverse of the work intervals. The only exception was for fully flexible resources (i.e. without a calendar).
### Solution:
The case we need to consider is for flexible resources: they are available anytime, all week long except on public holidays and leaves.
To do this we fix the method `_unavailable_intervals_batch()` which is then called by each module. If the resource is flexible, then we only return the interval of the public holidays overlapping with the time frame.
Works in `appointment`, `hr_holiday_gantt`and `project_enterprise`.
In `planning`, we need to skip the case where nothing is returned in `leaves_mapping` otherwise it will consider the `company_leaves` during weeks with no public holiday or leaves.
In `hr_attendances_gantt`, `_unavailable_intervals_batch()` is not called. So we change the way the unavailabilities were computed to call `_unavailable_intervals_batch()` instead.
opw-4879481This update fixes an issue where flexible calendar employees were incorrectly displaying unavailable days in planning and related modules. The change ensures that only public holidays are reflected as unavailable, providing a more accurate representation of employee availability. This improves the usability of the planning app for employees with flexible work schedules.
Original PR description
### Issue: When an employee has a flexible calendar, its gantt view in planning and other modules, like project or time off, shows incorrect grayed-out days. In general, employees with a flexible…
### Issue:
When an employee has a flexible calendar, its gantt view in planning and other modules, like project or time off, shows incorrect grayed-out days. In general, employees with a flexible calendar should not have any grayed out days other than public holidays.
### Steps to reproduce:
- Create a new work schedule:
- Flexible Hours
- 24 hours per week
- 8 average hours per day
- Create an employee with this work schedule
- Open Planning app
- Only the three first days of the week are not grayed out
### Cause:
With 24 hours per week, the worked time can be done in three days. Odoo considers that the first three days of the given time frame are worked, but the others aren't. This result is returned by `_work_intervals_batch()`. In `_unavailable_intervals_batch()` we then build the unavailabilities by taking the inverse of the work intervals. The only exception was for fully flexible resources (i.e. without a calendar).
### Solution:
The case we need to consider is for flexible resources: they are available anytime, all week long except on public holidays and leaves.
To do this we fix the method `_unavailable_intervals_batch()` which is then called by each module. If the resource is flexible, then we only return the interval of the public holidays overlapping with the time frame.
Works in `appointment`, `hr_holiday_gantt`and `project_enterprise`.
In `planning`, we need to skip the case where nothing is returned in `leaves_mapping` otherwise it will consider the `company_leaves` during weeks with no public holiday or leaves.
In `hr_attendances_gantt`, `_unavailable_intervals_batch()` is not called. So we change the way the unavailabilities were computed to call `_unavailable_intervals_batch()` instead.This update resolves a potential issue in the live chat service by switching from a complex Promise-based system to a simpler, more reliable Deferred approach. This change enhances the overall stability and performance of live chat interactions for users. It’s a routine maintenance update focused on best practices.
Original PR description
In [1], the live chat service uses `Promise.resolvers` to avoid duplicated chat creation. However, there is no polyfill in this version. It's better to stick to the `Deferred` class. [1]: https://github.com/odoo/odoo/pull/250374 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
This update enhances the reliability of self-order transactions within Odoo Point of Sale. By aligning the data validation rules with standard POS orders, the system now catches more errors and ensures data accuracy for self-order processes. This improves the overall customer experience and reduces potential issues during transactions.
Original PR description
*: pos_online_payment_self_order, pos_restaurant, pos_self_order This commit improves the data validation of pos self order by using the same validation as the one used for regular pos order.
This update fixes a validation issue in the self-order point of sale module by aligning its data checks with the standard point of sale system. This ensures greater data accuracy and reliability for self-order transactions, reducing potential errors and improving the overall customer experience.
Original PR description
This commit improves the data validation of pos self order by using the same validation as the one used for regular pos order.
This update fixes a bug where employees with future attendance records couldn't check out. The fix ensures that only past attendance records are considered when determining the employee's status, preventing incorrect 'checked-out' states. This improves the kiosk experience and prevents workflow disruptions.
Original PR description
### Issue: When having an attendance in the future, the employee cannot checkout anymore. ### Steps to reproduce: - In Attendances, create an attendance in the future for an employee - Go in the kiosk mode - Manually select the employee to check in - Do the same to check out - An error pops up ### Cause: The field `last_attendance_id` of the employee contains his future attendance. The field `attendance_state` use `last_attendance_id` in its computation, so it's always "checked_out", even if an attendance is curently open for the employee. So when trying to check out an exception is raised in [`_check_validity()`](https://github.com/odoo/odoo/blob/fee6b32a8a57577bd8229c80dff6f93964f9f556/addons/hr_attendance/models/hr_attendance.py#L224-L234). ### Solution: Add a condition in the domain of `_compute_last_attendance_id()` to only consider the last **past** attendance. opw-5491867
This update fixes a confusing error message users received when generating leads without sufficient credits. Instead of a generic message, the system now correctly indicates when credits are unavailable, providing a clearer experience for users. This ensures a smoother process for lead generation activities.
Original PR description
Before this commit, when the user uses CRM to generate new leads and does not have credits, the error message they would get is "Your request did not return any result (no credits were used). Try removing some filters." This commit fixes this in _perform_request by instead of expecting InsufficientCreditError raised it now expects the credit_error flag to be set. task-5925047 Forward-Port-Of: odoo/odoo#250433
This update corrects a technical issue in the Spanish reporting module (l10n_es_reports) where an unnecessary date scope was added. This removal ensures accurate report generation and aligns with standard reporting practices. The fix was implemented as a bug fix to maintain data integrity.
Original PR description
In the Forward Port of this PR: https://github.com/odoo/enterprise/pull/108575 A date_scope was wrongly added opw-5363664
This update resolves an issue where users wouldn't receive a helpful error message when attempting to process after departure payments. Now, the system displays a clear validation error if a previous payslip isn't linked, ensuring accurate payroll processing and preventing potential data discrepancies.
Original PR description
For after departure payment to work, a previous payslip is required in the system. So, instead of having a traceback, display an informative message to the user. task-5933607
This update corrects an issue with how VAT tax schemes are calculated for Romanian customers. Previously, an empty company registry caused calculation failures. The fix re-introduces specific logic for Romanian CIUSRO invoices, ensuring accurate VAT scheme determination based on the default VAT setting.
Original PR description
Problem --------- If the customer has not VAT set up on it record, we use the DEFAULT_VAT value. However, the scheme to be used is computed using the partner company_registry (which might be empty), which fails. Secondly, the piece of logic that compute the VAT/NON_EU_VAT for the Tax Scheme node was removed during the refactor. However, this is needed in Romania. Solution --------- Compute the scheme using the DEFAULT_VAT and add back the VAT/NON_EU_VAT logic for the Romanian CIUSRO only. no-task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where Avatax taxes weren't being correctly calculated during Stripe Express Checkout, particularly when using Google Pay. The fix ensures that all applicable taxes, including those from Avatax, are accurately reflected in the order total, improving payment accuracy and financial reporting. This impacts sales transactions utilizing the Stripe payment gateway.
Original PR description
## Versions 17.0+ ## Issue Avataxes are not computed during express checkout leading to discrepancies between customer payments and effective price including Avalara taxes. ## Steps to reproduce…
## Versions
17.0+
## Issue
Avataxes are not computed during express checkout leading to discrepancies between customer payments and effective price including Avalara taxes.
## Steps to reproduce
*Ensure the Stripe account has activated Google Pay* *This requires a complete Google profile on Google Chrome (with a valid payment method)*
- Setup Stripe payment method in test mode with Express Checkout;
- In the Settings, in the Accounting section:
- Setup Avatax;
- Set main Sales/Purchase taxes to 0.
- Create a new product with 0% selling taxes and any Avatax category;
- Activate fiscal position and enable automatic detection;
- Open a Chrome session with the Google profile:
- Go to the shop;
- Add the product you created to the cart;
- Enter the cart;
- Click the "Buy with GPay" button:
- The amount is equal to the sales price excluding taxes.
- Go to the Sales app and open the newly created order:
- The total amount differs from the amount paid (cf. transaction).
opw-5020793
Forward-Port-Of: odoo/enterprise#101579This update resolves an issue where users were encountering errors when processing after-departure payments. Now, the system clearly displays a validation error if a previous payslip isn't linked, guiding users to correctly complete the payment process. This improves user experience and data accuracy.
Original PR description
For after departure payment to work, a previous payslip is required in the system. So, instead of having a traceback, display an informative message to the user. task-5933607 Forward-Port-Of: odoo/enterprise#107801
This update fixes a technical issue that was disrupting automated payment flows within Odoo. The previous version was encountering errors due to uncertain data, which has now been resolved by simply removing the problematic information. This ensures smoother and more reliable processing of incoming payments.
Original PR description
The last iteration[^1] was preventing automated flows from running smoothly because it was raising an error. Instead, we now just remove the unsure data. [^1]: 1794fce234735ed174599891435d4e2accc1632 Forward-Port-Of: odoo/odoo#250941
This update fixes an issue where the calculation of 'sandwich leave' (leave periods surrounding holidays) was incorrect. Specifically, when leave was approved and then modified, the surrounding leave days weren't properly recomputed, leading to an inaccurate leave count. This change ensures that leave durations are calculated correctly, aligning with the intended business rules.
Original PR description
## Steps to reproduce:- 1. Apply Friday to Monday leave and Tuesday is Public holiday and again apply single leave on Wednesday. - According to the sandwich leave rule, the leave should be counted as 6 days (Friday to Wednesday, including weekend and holiday). 2. Now refuse the Friday to Monday leave and re-approve again. 3. Now the leave count is updated to 5 days as it should be 6 days! ## Root cause:- On approve and reset actions the neighbor leaves where not recomputed. ## Fix:- - Override `_l10n_in_update_neighbors_duration_after_change` on approve and reset actions. - Updated `_l10n_in_update_neighbors_duration_after_change` so that current and neighbors both leaves are recomputed. task-[5446346](https://www.odoo.com/odoo/action-4043/5446346) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr