Daily updates from Odoo
Tuesday, August 5, 2025
11 changes · 18.0
Enhancements to existing features
Xendit credit card payments now support the required customer authentication flow. After an initial authorized transaction, recurring purchases can use Xendit's merchant-initiated transaction support, improving reliability for repeat payments while aligning with Xendit's requirements.
Original PR description
By default, Xendit will require authentication for all credit card payment. Previously, we assume that optional 3DS is easily configurable for each user which will omit authentication for tokenization flow. Turns out, this configuration requires permission from Xendit. Instead of that, Xendit provides the Merchant Initiated Transactions (MIT) which allow users to purchase without authorization as long as the first transaction was already authorized successfully. To accomodate this, we need to support authentication flow and adding extra parameter `is_recurring` in the payload, --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Opening the customer list in Point of Sale is now much faster when many customers are loaded and the cart has several items. The system avoids repeating the same total calculation while the list is open, reducing wait times for cashiers and improving checkout flow.
Original PR description
Before this commit, opening the customer list in PoS could be slow when many customers were loaded (common in active PoS environments) and the current order had numerous orderlines. This performance hit was due to repeated recalculations of `get_total_with_tax`. This commit resolves the issue by storing the `get_total_with_tax` value of the current order when the customer list is opened. This value remains constant while the customer list is active, eliminating unnecessary recalculations. Performance Impact: With 500 customers loaded and 20 orderlines in the cart, opening the customer list improved from 5 seconds to 200 ms. opw-4921262
Resolved issues and error corrections
The invoicing dashboard now uses customer credit notes, rather than vendor credit notes, when calculating top countries, categories, products, and salespeople. It also excludes draft and cancelled entries when users open the Top Invoices view, improving the accuracy of reported sales information.
Original PR description
Problem:- In Invoicing Dashboard, in some parts we get wrong values because of wrongly set domain making dashboard consider Vendor Credit Note instead of Customer Credit Note. Before this commit:- - In Invoicing Dashboard, reports Top Countries, Top Categories, Top Products, and Top Salespeople considers Customer Invoice and Vendor Credit Note. - When clicked on Top Invoices, moves in draft and cancel state are also displayed. After this commit:- - In Invoicing Dashboard, reports Top Countries, Top Categories, Top Products, and Top Salespeople considers Customer Invoice and Customer Credit Note only. - When clicked on Top Invoices, moves in draft and cancel state are not displayed. task-4851920 Forward-Port-Of: odoo/odoo#213723
Point of Sale now blocks duplicate orders, order lines, and payments when requests happen at the same time. This helps keep sales records accurate and avoids duplicate charges or reporting errors.
Original PR description
Before this commit, it was possible for concurrent requests to create duplicate PoS orders, order lines, and payments. This was due to the absence of unique identifiers at the database level for these records during their creation. This commit addresses the issue by adding SQL unique constraints on the UUID fields for the `pos.order`, `pos.order.line`, and `pos.payment`. These database-level constraints ensure that any attempt to insert a duplicate record (based on its unique UUID) will be rejected, thereby preventing data duplication and maintaining transactional integrity. opw-4899804 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Grouped vendor bill payments made by check now keep each journal entry label aligned with its actual check number. This avoids duplicate or misleading check references in accounting records, improving payment traceability and reconciliation accuracy.
Original PR description
Steps to reproduce: 1. Install `accounting` and `account_check_printing` modules. 2. Configure a bank journal: - Enable the `Manual Numbering` option for checks. - Set an `Outstanding Payments…
Steps to reproduce: 1. Install `accounting` and `account_check_printing` modules. 2. Configure a bank journal: - Enable the `Manual Numbering` option for checks. - Set an `Outstanding Payments Account` for checks under the `outgoing payments` tab on the journal. - Ensure the Check Sequence is properly configured. 3. Create three vendor bills (two for the same vendor and one for a different vendor). 4. Go to the list view of vendor bills and select all three of them. 5. Click the `Pay` button and in the payment wizard: - Enable the `Group Payments` option. - Choose `Checks` as the payment method. - Confirm the wizard to register the payment. Observed Behavior: - Multiple payments are created simultaneously. - Each payment has its own check number (e.g., 0001, 0002), correctly assigned. - However, all the related journal entries (account.move) have journal item labels that incorrectly use the same check number (e.g., all journal items have label Check - 0001 instead of Check - 0001, Check - 0002, etc.). Issue: - Journal entries are created during payment creation `create()`, at which point the payments are still in draft state. - The check_number is only computed and the check sequence is incremented when the payment is posted `action_post()`. - As a result, all journal entries generated during draft state receive the same initial check number. Solution: - Override the `_get_trigger_fields_to_synchronize` method to include the `check number`, ensuring that any updates to the check number on a payment are also reflected in the related journal entries. opw-4886452
Survey timers now account for smaller differences between a user's device clock and the server clock. This prevents surveys from being submitted too early or accepted too late, reducing confusing errors and keeping timed surveys fair for all participants.
Original PR description
Description of the issue/feature this PR addresses: This commit addresses early submissions of surveys due to timer expiry. Differences in server/client clocks can leave the survey in an incorrect…
Description of the issue/feature this PR addresses: This commit addresses early submissions of surveys due to timer expiry. Differences in server/client clocks can leave the survey in an incorrect state. Current behavior before PR: The server, seeing a submission come before the time limit that was triggered by the client timer, lets the survey continue. Clients are receiving error messages when trying to do more submissions, which bump against the cheating prevention. This is true if the client is "ahead" of the server. Currently, a difference would only be addressed if above 5 s. This is not enough as the client being "ahead" by 1 s can cause this issue. This was detected in real use. Looking at server logs has led me to this cause. Here's a diagram that could help understand the issue with the current behaviour: <img width="455" alt="Survey Timer bug" src="https://github.com/user-attachments/assets/1804f848-ad4b-4b8a-97fe-7562b76ea66c" /> The above diagram shows how, for a survey with a 30 min timer, a 1 sec difference between the clocks can lead to an early submission. Desired behavior after PR is merged: The fix here is to tighten when to apply the time difference to when it is above 500 ms. This should help avoid the early submission bug but conversely also not allow late submissions, even below 5 s, making the timer fair across users. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#220431 Forward-Port-Of: odoo/odoo#207485
Opening a payment link for an unpaid invoice could fail because the payment amount was handled incorrectly. This update corrects that handling so customers can open payment links and proceed with payment without encountering an error.
Original PR description
Versions
--------
- 18.0+
Steps
-----
1. Go to Accounting/Invoicing;
2. open an unpaid invoice;
3. generate payment link;
4. open payment link.
Issue
-----
Traceback on a `ValueError`.
Cause
-----
Commit 5697493e00915 added a `amount and float('amount')`, trying to convert a string into a float.
Solution
--------
Convert the variable into a float instead.
opw-4996783Products received from purchase orders with a 100% discount are now valued at zero instead of using the product's standard price. This keeps inventory valuation aligned with the actual purchase cost and prevents overstated stock value.
Original PR description
**Current behavior:** Receiving some real-time valuated, non-standard cost product from an order with 100% discount will value the product at its `standard_price`. **Expected behavior:** Valuated at 0. **Steps to reproduce:** 1 Create an average cost, real-time valuated product with non-zero `standard_price` 2. Create a purchase order for some of the avco product, confirm and receive 3. Create and post the bill -> check valuation from inventory **Cause of the issue:** Currently from 6ba1106ae we will ignore a 100% discount in calculating `_get_gross_unit_price()`. **Fix:** Return 0 in this method if we are in a 100% discount case. opw-4862883 Forward-Port-Of: odoo/odoo#217726
Bank reconciliation now applies the configured analytic distribution when an early payment discount is recorded. This keeps discount-related accounting lines consistent with manually registered payments and improves accuracy of analytic reporting.
Original PR description
# Steps to reproduce: - Configure an early discount payment term (e.g., 2/7 Net 30). - Configure the analytic distribution model with the account used when a discount is granted (e.g., 657000 on the…
# Steps to reproduce: - Configure an early discount payment term (e.g., 2/7 Net 30). - Configure the analytic distribution model with the account used when a discount is granted (e.g., 657000 on the BE fiscal position). - Create an invoice using the early discount payment term. - On bank reconciliation, register the transaction taking into account the early payment discount (e.g., 98% of the invoice amount_total). On the third line with account 657000, corresponding to the early discount payment, the analytic distribution model does not apply. In contrast, when manually registering a payment for the invoice, the analytic is correctly applied. When the bank reconciliation lines are created, _lines_check_apply_early_payment_discount gets its values for the early payment lines from _get_invoice_counterpart_amls_for_early_payment_discount_per_payment_term_line, which does not check if there is an analytic distribution model. enterprise pr: https://github.com/odoo/enterprise/pull/90641 opw-4868986 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#217933
The online shop now disables the Add to Cart button and shows a loading state while an item is being added. This helps prevent customers from accidentally adding the same product multiple times, reducing order mistakes and support issues.
Original PR description
This PR prevent users from clicking the "Add to Cart" button multiple times by adding a loading effect and disabling the button while the request is in progress. task-4979205
A small rounding difference could make eWallet payments appear slightly underpaid in Mexican point of sale orders, blocking users from reaching the payment screen. The fix treats tiny rounding differences correctly so valid payments can proceed as expected.
Original PR description
Before this commit, paying an order with eWallet could result in a small negative residual amount (due to tax calculation), instead of zero. This prevented users from proceeding to the payment screen. With this commit, the "lt" function is used to compare amounts while taking rounding precision into account, ensuring the residual is treated as zero when appropriate. opw-4867365