Daily updates from Odoo
Monday, August 10, 2026
30 changes · saas-19.3
Resolved issues and error corrections
TikTok Shop orders that arrive without a payment time, such as cash-on-delivery orders, can now be created and synchronized instead of failing. The system uses the order creation time temporarily and updates it once TikTok confirms payment, helping businesses avoid missing orders.
Original PR description
**Issue**
- TikTok Shop orders may be received without any `paid_time` value in the returned API data, particularly for _Cash On Delivery ([COD](https://seller-ph.tiktok.com/university/essay?knowledge_id=10004482&lang=en)) payments.
- When creating the order, `_create_order_from_data` accessed `order_data[‘paid_time’]` directly, which triggered a `KeyError` and prevented all orders from being fully synchronised.
**Changes**
- When creating an order, if `paid_time` is missing from the data provided by TikTok:
-> `date_order` is initialised with `create_time` as a fallback
-> The new field `tiktok_payment_pending` is set to `True` to mark the order as awaiting payment confirmation.
- During subsequent synchronisations, if `paid_time` is now provided by TikTok for a pending order,
-> `date_order` is updated with the new provided timestamp and the `tiktok_payment_pending` flag is reset.
opw-6440127
Forward-Port-Of: odoo/enterprise#126797This fix prevents field service tasks from getting stuck when marking them as done after a delivery, return, and re-delivery flow. It avoids repeated stock movement checks that could exhaust memory, improving reliability for service teams handling product returns.
Original PR description
## **Steps to reproduce:** 1. Create a Service product with Create on Order set to Task and Project set to Field service project. 2. Create a Sales Order containing a storable product and a service…
## **Steps to reproduce:** 1. Create a Service product with Create on Order set to Task and Project set to Field service project. 2. Create a Sales Order containing a storable product and a service product. 3. Confirm the Sales Order to generate the project, task, and delivery order. 4. Validate the delivery order. 5. Create and validate a return for the delivery. 6. Create a return of the return to deliver the products again, but do not validate this new delivery. 7. Open the related task and click on Mark as Done button. ## **Issue:** In a delivery -> return -> return of return workflow, the stock move goes into this code https://github.com/odoo/enterprise/blob/59b86f106862c3a364ba633a1580d9051f2fe7ca/industry_fsm_stock/models/project_task.py#L89-L90 the traversal repeatedly revisits the same stock moves through move_dest_ids, causing the loop to alternate between the same move recordsets indefinitely. As a result, the loop never terminates, eventually exhausting the memory and raising a `MemoryError`. ## **Solution:** Track the stock moves that have already been visited and continue the traversal only with unseen destination moves. Runbot Video : [Video](https://drive.google.com/file/d/1wiqggjx8T-Mtl4T1JgCsfwBbgQU18nYF/view?usp=drive_link) OPW - 6420961 Forward-Port-Of: odoo/enterprise#125962
The EPF Summary report now calculates EPS contributions using the employee's basic salary, capped at ₹15,000, instead of using the EPF amount. This helps Indian payroll reports reflect the correct statutory contribution and reduces the risk of inaccurate compliance reporting.
Original PR description
**Steps to Reproduce** - Create an Indian employee. - Create a payslip for this employee. - Go to **Payroll > Reporting > EPF-ECR Report**. - Create a new report with the report type **EPF Summary**. **Before This Commit** - For the EPS contribution, we were calculating `min(15,000, EPF)` and then applying **8.33%** to the resulting amount. - This resulted in an incorrect EPS contribution amount. **After This Commit** - According to Indian payroll rules, the EPS contribution is calculated as 8.33% of `min(15,000, Basic Salary)`, rather than `8.33% of the EPF amount`. - This commit corrects the EPS contribution calculation accordingly. Task: [6442399](https://www.odoo.com/odoo/project/1251/tasks/6442399) Forward-Port-Of: odoo/enterprise#126608
The self-order test flow was updated to reflect that takeaway is now selected automatically when it is the only option. This keeps the point-of-sale messaging and WhatsApp validation aligned with the current customer experience and avoids false test failures.
Original PR description
In this commit: - The takeaway preset is now automatically selected when it is the only available option. Remove the explicit "Takeaway" selection step from the tour to match the updated behavior. Task:6217791 Community PR : https://github.com/odoo/odoo/pull/274301 Forward-Port-Of: odoo/enterprise#126777 Forward-Port-Of: odoo/enterprise#122979
Portal users now see their to-sign count decrease after they complete their part of a signature request. This prevents completed documents from appearing as still awaiting action, making the portal status clearer and more reliable.
Original PR description
Version: 18.0 Steps to reproduce: - Create a sign request with two signers. - Assign the first signature to a portal user. - Log in as the portal user and sign the document. Issue: After signing, the to-sign count in the portal does not decrease. This is because the query only checks the overall sign request state instead of the individual signer's item state, so the count remains unchanged Fix: Added an item level state check to the count query so it only counts items that are still pending for that specific user. Task ID: 6412976 Forward-Port-Of: odoo/enterprise#126962 Forward-Port-Of: odoo/enterprise#125632
Bank reconciliation now handles imported payment references that contain only spaces without crashing. This makes reconciliation more reliable when statement data comes from imports or integrations rather than direct UI entry.
Original PR description
When reconciling bank statements with an account, the system will look for past statement lines already reconciled with that account and create a reconciliation model based on common substring in…
When reconciling bank statements with an account, the system will look for past statement lines already reconciled with that account and create a reconciliation model based on common substring in payment_ref. If this payment refs contains only spaces (eg. ' '), it will trigger an index out of range traceback. This is explained by the fact that spaces are striped then '' is considered as False in some filtering leaving the list empty. From the UI, putting ' ' is not supposed to be possible because spaces are striped before write but there is many ways to import statement lines which may lead to this hence the decision of handling this scenario to make the code more robust. Steps to reproduce: 1/ Create two statement lines with payment_ref as ' ' (you can force it using a write) 2/ Click "Set account" on first one and pick 100000 Issued Capital 3/ Do the same for the second statement line => Traceback In this commit, we do not check for common substring if there is less than two labels. opw-6379977 Forward-Port-Of: odoo/enterprise#126729 Forward-Port-Of: odoo/enterprise#125779
The Timesheet Assistant now combines similar selected suggestions into one natural description, such as “Discussing with A and B” instead of repeating the same phrase with semicolons. This makes generated timesheet entries easier to read and reduces manual cleanup for users.
Original PR description
In this task, we improved the Timesheet Assistant by merging descriptions generated from the same rule templates. When multiple suggestions are selected that use the same rule template, the assistant now combines them into a single timesheet description instead of joining with ';' Example: Rule template: `Discussing with $1` Before: Discussing with A; Discussing with B After: Discussing with A and B Task-6348575 Forward-Port-Of: odoo/enterprise#126157
Tax return deadline dates in account reports emails are now shown using each user's regional date format. This reduces confusion for businesses operating across different locales and helps recipients read deadlines correctly.
Original PR description
The date was not formatted according to the user's locale. Forward-Port-Of: odoo/enterprise#127317
Fixed an issue that could interrupt Belgian payroll processing when voluntary overtime was recorded across multiple work days. This helps payroll teams calculate affected employee salaries without encountering an error in that scenario.
This fixes an issue where Kenyan POS receipts could miss the official SCU details and QR code even after the tax authority response was received. Receipts can now generate the verification QR code when the required signature is available, improving customer receipt completeness and compliance visibility.
Original PR description
The original issue coudn't be reproduced. But based on what was reported on the ticket, this should improve the behavior of the order receipt. Steps to reproduce: ------------------- * Setup the…
The original issue coudn't be reproduced. But based on what was reported on the ticket, this should improve the behavior of the order receipt. Steps to reproduce: ------------------- * Setup the l10n_ke module in 'production' mode * Make an order in POS and validate it > Observation: The receipt doesn't contain the SCU information and QR Why the fix: ------------ Based on the receipt screenshot shared on the ticket (from Odoo 19.3) we can see that some informations are shown on the ticket. The information shown are the one received from the etims api, it means the call went through and the response was received. As the qrCode URL only needs `l10n_ke_oscu_signature` to be generated, we can assume that if this field is set we can safely generate the URL and generate the QR code. https://github.com/odoo/enterprise/blob/ee7e6894ed313db844aeff5ba5e19de3ad94898e/l10n_ke_edi_oscu_pos/models/pos_order.py#L252-L256 Based on this assumption we can change the condition to return the URL or not based on the presence of `l10n_ke_oscu_signature` instead of the state of the order being `sent`. In 19.0, the receipt is showing no info at all (when 19.3 is showing some info like the signature). This is also happening because the URL was falsy. And when that is the case we do not show any SCU information https://github.com/odoo/enterprise/blob/ee7e6894ed313db844aeff5ba5e19de3ad94898e/l10n_ke_edi_oscu_pos/static/src/overrides/components/order_receipt/order_receipt.xml#L56 opw-6352120 Forward-Port-Of: odoo/enterprise#127045
DHL Express deliveries with multiple packages through EasyPost are no longer blocked by an informational carrier message. This lets valid international shipments proceed while still stopping genuine carrier errors.
Original PR description
Steps to reproduce --- 1. Configure a `delivery_easypost` shipping method using the DHL Express carrier. 2. On an international delivery, use Put in Pack to create two or more packages. 3. Validate…
Steps to reproduce --- 1. Configure a `delivery_easypost` shipping method using the DHL Express carrier. 2. On an international delivery, use Put in Pack to create two or more packages. 3. Validate the delivery. Issue --- Validation is blocked with `DHLExpress: rate_error -- DHLExpress multi-shipment rate includes this shipment.` For an EasyPost multi-shipment order, DHL Express returns the aggregate rate on the first (master) shipment only and adds an informational `rate_error` on the order stating that this rate already covers the whole order, so the remaining shipments carry no rate of their own. The message is not a real error, but `send_shipping` raises on any carrier message whose type is not exempt: https://github.com/odoo/enterprise/blob/534b42def8ae5dc884da4398377f828c49557d6e/delivery_easypost/models/easypost_request.py#L359-L364 `_post_process_ship_response` already detects and clears exactly this harmless message, but only for a hardcoded carrier allowlist introduced in a2de5bc5a14 (`Purolator`, `DPD UK`, `UPS`) that was never extended to DHL Express, so for DHL Express the message survives, reaches the raise, and aborts an otherwise valid shipment: https://github.com/odoo/enterprise/blob/a2de5bc5a14f99b8674c3ee234e4d221b406da0f/delivery_easypost/models/easypost_request.py#L416-L434 `DHL Express` is added to that allowlist so the harmless multi-shipment `rate_error` is posted on the picking and cleared instead of raised. The guard still requires a single `rate_error` carrying the "multi-shipment rate includes this shipment." text with the rate present only on the master shipment, so genuine DHL Express errors keep blocking validation. opw-6450365 Forward-Port-Of: odoo/enterprise#127164
Vendor bill product suggestions based on line labels now respect the existing setting that lets businesses turn this behavior on or off. This prevents unwanted product predictions for users who disabled the feature, while keeping the default prediction behavior for community users.
Original PR description
Context: There was an enterprise field `predict_bill_product` allowing users to toggle product prediction based on line label. Before this commit, product prediction by name was running without taking into account the value of this field, which could confuse users who had disabled the feature in settings. This commit makes product prediction by name depend on this field. For community users, the prediction will run by default. no-task --- I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr) Forward-Port-Of: odoo/enterprise#126529
This fix ensures India-specific payroll fields are only calculated and tracked for employees using the Indian localization. It prevents irrelevant Indian payroll information from appearing when Belgian payroll is active, reducing confusion in employee records and change history.
Original PR description
[FIX] l10n_in: fix some l10n_in fields computed for other localizations
Bug reproduction:
1 - in localhost install below modules:
→ l10n_in_hr_payroll,l10n_be_hr_payroll,l10n_be_hr_contract_salary
2 - Select BE, IN localizations, but as active one select Belgium. 3 - Go to employee, Laura.
4 - Change her wage to 8000
5 - In the chatter, you will see some indian fields are tracked.
→ Shouldn't be, Laura is Belgium, only BE fields should be tracked
Bug cause:
1 - In the hr.version of l10n_in_hr_payroll:
→ there isn't enough caution in compute methods for other l18ns.
→ e.g., _l10n_in_get_montly_wage returns self.wage
→ self.wage is 8000 and that function leads to positive computations
Bug solution:
1 - Non-indian versions are carefully handled in compute methods
task-6411960
Forward-Port-Of: odoo/enterprise#125350Sales users without accounting permissions can now view their accessible invoices without being blocked by missing access to Kenya tax codes. The change grants regular internal users read-only access to these non-confidential codes, improving day-to-day invoice visibility.
Original PR description
The KE codes are used in invoices and when sales people who do not have accounting access, but still can see their own invoices open an invoice, right now they will have an access error because they do not have read access to the codes. So, we should just apply the same logic as is done in edi.documents and give base.group_user read access to those codes, which are not confidential anyways.
Belgian payroll now automatically applies the legal minimum employee contribution for meal vouchers when a lower amount is configured. HR managers also see a non-blocking payslip warning so they know the amount was adjusted for compliance.
Original PR description
**What:** - Refactored the meal voucher salary rule computation to take the maximum between the configured employee share and the parameter-defined minimum threshold (€1.09). - Added a non-blocking warning message on the payslip to notify HR managers when an employee's configured share is below the legal minimum and has been automatically adjusted. task-6428585
Rejection notification emails now show the name of the person who declined to sign, rather than the recipient of the email. This makes signing updates clearer for everyone involved and avoids confusion about who rejected a document.
Original PR description
**Description of the issue/feature this PR addresses:** When a document is rejected by a signer, the notification email sent to other involved parties incorrectly displays the recipient's name in the…
**Description of the issue/feature this PR addresses:** When a document is rejected by a signer, the notification email sent to other involved parties incorrectly displays the recipient's name in the subject line instead of the person who actually refused to sign. This occurs because the subject string was using `partner.name` (the current email recipient) instead of `refuser.name`. This commit updates the string to reference the refuser, ensuring the subject accurately identifies the individual who rejected the document. **Steps to reproduce:** - Sign > upload any PDF > add signature request for 2 different signers > Send > choose signers, e.g. Abigail Carter and Marc Demo > Send - Settings > Technical > Emails > Emails - Select one of the sent emails > Sign document > sign > Validate & Send Completed Document - Select the other email > Sign document > top-right dropdown arrow > Decline to sign > Decline - Settings > Technical > Emails > Emails - Observe that all emails sent state that the recipient of the email rejected the signing **Current behavior before PR:** - Rejection email subject states that the recipient refused to sign **Desired behavior after PR is merged:** - Rejection email subject states that the refuser refused to sign opw-6421188 Forward-Port-Of: odoo/enterprise#126412
MyInvois expects the CountrySubentityCode to be fixed as '17' for customers located outside Malaysia, since Malaysian state codes don't apply to them. Set it to '17' instead of the raw state name for non-Malaysian customers. task-6388521 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#281095 Forward-Port-Of: odoo/odoo#280550
Original PR description
MyInvois expects the CountrySubentityCode to be fixed as '17' for customers located outside Malaysia, since Malaysian state codes don't apply to them. Set it to '17' instead of the raw state name for non-Malaysian customers. task-6388521 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#281095 Forward-Port-Of: odoo/odoo#280550
In this commit: - When only one preset remains available after filtering table identifier in self-order mode, automatically select it and skip the preset selection page. - This avoids showing a location selection page when there is no actual choice available to the customer. Task:6217791 Enterprise PR : https://github.com/odoo/enterprise/pull/122979 Forward-Port-Of: odoo/odoo#280579 Forward-Port-Of: odoo/odoo#274301
Original PR description
In this commit: - When only one preset remains available after filtering table identifier in self-order mode, automatically select it and skip the preset selection page. - This avoids showing a location selection page when there is no actual choice available to the customer. Task:6217791 Enterprise PR : https://github.com/odoo/enterprise/pull/122979 Forward-Port-Of: odoo/odoo#280579 Forward-Port-Of: odoo/odoo#274301
### Issue: In the tax report, lines `E5`, `F3`, `F4`, `F7`, `F8` and `F9` show 0 when using a tax with the corresponding tax grid ### Cause: In 19.0, the +/- tax grids were replaced by a single unsigned tax grid The E and F formulas were not updated accordingly, causing their values to be negative instead of positive ### Fix: The formulas have been updated based on the official documentation to correctly separate Sales and Purchases lines: https://www.impots.gouv.fr/sites/default/file
Original PR description
### Issue: In the tax report, lines `E5`, `F3`, `F4`, `F7`, `F8` and `F9` show 0 when using a tax with the corresponding tax grid ### Cause: In 19.0, the +/- tax grids were replaced by a single unsigned tax grid The E and F formulas were not updated accordingly, causing their values to be negative instead of positive ### Fix: The formulas have been updated based on the official documentation to correctly separate Sales and Purchases lines: https://www.impots.gouv.fr/sites/default/files/formulaires/3310-ca3-sd/2026/3310-ca3-sd_5426.pdf ### Steps to reproduce: - Install `l10n_fr_account` - Create a Tax (Amount: 1.75%, Base Tax Grids: E5 and F3) - Create an invoice (any amount, Tax: created tax) - Open the Tax Report for this month Before the fix, E5 and F3 lines are empty opw-6357703 Forward-Port-Of: odoo/odoo#278635
## Steps to reproduce: ## Why the fix: opw-6428369
Original PR description
## Steps to reproduce: ## Why the fix: opw-6428369
On python 3.10.12 `test_export_translatable_resources` fails. This is fixed in this commit build-944659 I only tested it on 17.0 since we do not seem to have the build error on higher versions. But the minimum python version is 3.10 until [excluding saas-19.1](https://github.com/odoo/odoo/blob/11ee42b4bf70a1008b06d13a48263e42c381aeed/odoo/release.py#L39) Forward-Port-Of: odoo/odoo#281294 Forward-Port-Of: odoo/odoo#280927
Original PR description
On python 3.10.12 `test_export_translatable_resources` fails. This is fixed in this commit build-944659 I only tested it on 17.0 since we do not seem to have the build error on higher versions. But the minimum python version is 3.10 until [excluding saas-19.1](https://github.com/odoo/odoo/blob/11ee42b4bf70a1008b06d13a48263e42c381aeed/odoo/release.py#L39) Forward-Port-Of: odoo/odoo#281294 Forward-Port-Of: odoo/odoo#280927
Currently, l10n_vn_edi_unit_price and unit_price have the same label, triggering a warning. This commit changes the field name of l10n_vn_edi_price_unit to avoid the conflict. Backport of https://github.com/odoo/odoo/pull/260550 task-260550
Original PR description
Currently, l10n_vn_edi_unit_price and unit_price have the same label, triggering a warning. This commit changes the field name of l10n_vn_edi_price_unit to avoid the conflict. Backport of https://github.com/odoo/odoo/pull/260550 task-260550
In ubuntu 26.04 the time zone database contents changed. A couple of timezone names are not available anymore, causing runtime exceptions. This mapping links old with new time zone naming conventions to prevent future (test) breakdown. The mapping WET to Europe/Lisbon is imperfect, and the localizations for the fixed date inside the test did not match. There exists no better nor correct mapping for WET. The mapping to Europe/Lisbon comes from the IANA tzdb-2026c and is official, so it
Original PR description
In ubuntu 26.04 the time zone database contents changed. A couple of timezone names are not available anymore, causing runtime exceptions. This mapping links old with new time zone naming conventions to prevent future (test) breakdown. The mapping WET to Europe/Lisbon is imperfect, and the localizations for the fixed date inside the test did not match. There exists no better nor correct mapping for WET. The mapping to Europe/Lisbon comes from the IANA tzdb-2026c and is official, so it is kept unchanged. The fixed date inside the test is changed to a recent one that aligns the test outcome with expectations: - Offsets match for recent history and future time - Match daylight savings time (DST) observation --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#280691
When importing a UBL bill, if a price-included tax is used, we need to adjust the unit price by adding the tax amount per unit. When a discount is added to the line, the unit price doesn't reflect it, but the raw_tax_amount_currency does. As a result, we add the reduced tax amount to the original unit price. We propose to compute the raw tax amount before the discount to adjust the unit price. opw-6242701 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.
Original PR description
When importing a UBL bill, if a price-included tax is used, we need to adjust the unit price by adding the tax amount per unit. When a discount is added to the line, the unit price doesn't reflect it, but the raw_tax_amount_currency does. As a result, we add the reduced tax amount to the original unit price. We propose to compute the raw tax amount before the discount to adjust the unit price. opw-6242701 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#278659
**Steps to reproduce:** 1. Install eCommerce, l10n_be, payment_stripe and switch to belgian company 2. Switch the admin user's company to the belgian one, and update their contact address to be in Belgium 3. Create a website for the belgian company and enable stripe payment provider 4. Add SEPA payment method in stripe configuration 5. Open the website, add any product to cart, go to checkout and make a payment using SEPA **Issue:** - Check the transaction in Stripe dashboard: the order
Original PR description
**Steps to reproduce:** 1. Install eCommerce, l10n_be, payment_stripe and switch to belgian company 2. Switch the admin user's company to the belgian one, and update their contact address to be in…
**Steps to reproduce:** 1. Install eCommerce, l10n_be, payment_stripe and switch to belgian company 2. Switch the admin user's company to the belgian one, and update their contact address to be in Belgium 3. Create a website for the belgian company and enable stripe payment provider 4. Add SEPA payment method in stripe configuration 5. Open the website, add any product to cart, go to checkout and make a payment using SEPA **Issue:** - Check the transaction in Stripe dashboard: the order reference is currently sent only in the `Description` field which is for internal information and is not shown to customers on their bank statements. Customers only see "MACKNET", so they cannot identify which order the payment relates to. **Expected behavior:** - Should also send the order reference to Stripe's `statement_descriptor` field, which is the field used for the customer-facing bank statement reference. - The `statement_descriptor` value must comply with Stripe's requirements: Must not contain <, >, \, ', ", or * Must contain at least one letter Maximum 22 characters **Fix:** - Pass the order reference, which should already satisfy the first two requirements based on Odoo order/invoice naming conventions opw-6424994 Forward-Port-Of: odoo/odoo#280985
Steps: - Install l10n_co module. - Set `CO company` on user. - Go to address page on portal address. - Set `Company Name`, `ID Type` and `ID Number` on the address page. Issue: - Not able to save address without any error message on the address page and in logger it raise validation error. Cause: - In address we actually do vat validation before creation/updation and if there is any issue with vat number then add it into invalid_fields instead raising any validation error, so here wh
Original PR description
Steps: - Install l10n_co module. - Set `CO company` on user. - Go to address page on portal address. - Set `Company Name`, `ID Type` and `ID Number` on the address page. Issue: - Not able to save…
Steps: - Install l10n_co module. - Set `CO company` on user. - Go to address page on portal address. - Set `Company Name`, `ID Type` and `ID Number` on the address page. Issue: - Not able to save address without any error message on the address page and in logger it raise validation error. Cause: - In address we actually do vat validation before creation/updation and if there is any issue with vat number then add it into invalid_fields instead raising any validation error, so here when user set `Company name` on address it try to create parent company and again do vat validation and it raise validation error because `ID Type` on customer is not propagated to parent when creating parent company from portal. Fix: - Skip vat validation on parent company creation from address. To-do: We also need to pass `ID type` and other accounting related values when creating parent company from customer or make them dependent like `Vat`. Issued PR: https://github.com/odoo/odoo/pull/264356 opw-6434127 Forward-Port-Of: odoo/odoo#280859
- Some clients does not know that they can skip the feedback screen timeout by clicking on the screen. So we decrease the timeout to 1.5 seconds to avoid that they wait too much time. - This timeout was already reduced in version `saas-19.1` to 1 second (see PR: github.com/odoo/odoo/issues/235316) - We now set it to 1.5 seconds (because 1 second is not enough for the paid animation to finish on the feedback screen). task-id: 6425204 --- I confirm I have signed the CLA and read the PR gu
Original PR description
- Some clients does not know that they can skip the feedback screen timeout by clicking on the screen. So we decrease the timeout to 1.5 seconds to avoid that they wait too much time. - This timeout was already reduced in version `saas-19.1` to 1 second (see PR: github.com/odoo/odoo/issues/235316) - We now set it to 1.5 seconds (because 1 second is not enough for the paid animation to finish on the feedback screen). task-id: 6425204 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#279444 Forward-Port-Of: odoo/odoo#278841
When making a downpayment in the PoS on a sale order that already contained another downpayment, there would be multiple downpayment lines created in the PoS order (1 positive and 1 negative). Steps to reproduce: ------------------- * Create a sale order in the sales app * Make a downpayment in the sales app * Open the PoS and make a downpayment on the same sale order > Observation: Two lines are added to the order, 1 negative and 1 positive Why the fix: ------------ When creatin
Original PR description
When making a downpayment in the PoS on a sale order that already contained another downpayment, there would be multiple downpayment lines created in the PoS order (1 positive and 1 negative). Steps to reproduce: ------------------- * Create a sale order in the sales app * Make a downpayment in the sales app * Open the PoS and make a downpayment on the same sale order > Observation: Two lines are added to the order, 1 negative and 1 positive Why the fix: ------------ When creating the baseLines for the downpayment we should not consider the previous downpayments and only consider the other lines. opw-6354823 Forward-Port-Of: odoo/odoo#275653
The test `waitForAnimationFrame does not trigger update if interaction is not ready yet` fails randomly (and seldom). The timeout and animation frame are treated together and appear at the same time in the verified steps. This is likely due to the timeout being too close to the animation frame and the task queue resolving them back to back. Giving a larger timeout (1s instead of 100ms) should solve the issue. runbot-939992 Forward-Port-Of: odoo/odoo#280708
Original PR description
The test `waitForAnimationFrame does not trigger update if interaction is not ready yet` fails randomly (and seldom). The timeout and animation frame are treated together and appear at the same time in the verified steps. This is likely due to the timeout being too close to the animation frame and the task queue resolving them back to back. Giving a larger timeout (1s instead of 100ms) should solve the issue. runbot-939992 Forward-Port-Of: odoo/odoo#280708
This commit fixes the verification JSON. For OSS taxes no_sujeto_loc and no_sujeto, CuotaTotal and ImporteTotal must Only include the base amount, not the tax amount. See the chatter in the task for AEAT guidelines. Also removed the validation error blocking no_sujeto_loc taxes with a non-zero amount, since OSS taxes legitimately have one in Odoo accounting (e.g. 22% IT VAT) even though it is excluded from the Veri*Factu json. upgrade :- https://github.com/odoo/upgrade/pull/10799 tas
Original PR description
This commit fixes the verification JSON. For OSS taxes no_sujeto_loc and no_sujeto, CuotaTotal and ImporteTotal must Only include the base amount, not the tax amount. See the chatter in the task for AEAT guidelines. Also removed the validation error blocking no_sujeto_loc taxes with a non-zero amount, since OSS taxes legitimately have one in Odoo accounting (e.g. 22% IT VAT) even though it is excluded from the Veri*Factu json. upgrade :- https://github.com/odoo/upgrade/pull/10799 task-5411766 Forward-Port-Of: odoo/odoo#281384 Forward-Port-Of: odoo/odoo#272068