Odoo Changelog — 2025-03-24

Monday, March 24, 2025

42 changes · saas-18.1

Bug Fixes(2)

Resolved issues and error corrections

[FIX] point_of_sale: order time zone in a POS session

PR #199038

Coresaas-18.1point_of_sale

Order dates and times in Point of Sale sessions now display using the user's configured time zone instead of GMT/UTC. This prevents confusion for staff reviewing orders and makes session records easier to interpret accurately.

Original PR description

The date and time displayed in the order section of a POS session were always shown in GMT,
ignoring the user's time zone.

![image](https://github.com/user-attachments/assets/c5644bc7-7a12-4e69-93b9-a7eaceac5532)

opw-4416447

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

#pos#timezone#orders

[FIX] point_of_sale: Include company name in receipt header

PR #202971

Coresaas-18.1point_of_sale

Point of Sale receipts now use the available company name when building the receipt header. This prevents the company name from being missing or causing issues after a recent receipt data change, helping customers receive correctly branded receipts.

Original PR description

Issue:
order.company.partner_id[1] is undefined during the change to use `order` object as props component. in this PR: #189446

Purpose of this PR:
use order.company.name if it exists to include into the receipt header.

opw-4654437

I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

#receipts#company name#point of sale

Other(40)

Miscellaneous changes

[FW][PERF] stock: prevent unecessary writes

PR #202967

Coresaas-18.1stock

Original PR description

When putting products in pack from the picking FormView `picking._put_in_pack` is eventually called. This method does a few things, amongst those is a write on picking.move_line_ids and another is…

When putting products in pack from the picking FormView `picking._put_in_pack` is eventually called. This method does a few things, amongst those is a write on picking.move_line_ids and another is the creation of a new package level. Both
of these can be a bit slow when the picking's number of move_lines gets bigger. This can happen for SN tracked products for instance. In a database with 1800 move_lines, each _put_in_pack call takes around 1.5s, which can become cumbersome when customers are using multiple packages.

Most of this slowness is coming from two things. The first one is stock.quants synchronization when writing on move.lines. The propose solution in this commit is to skip this synchronization when the only value in the vals dict is `result_package_id`. We can do that because this value is not used in the first quants synchronization of the write method.

The second one is a write of `location_dest_id` on the picking's move_ids and move_line_ids in `package_level.create`. Since the package_level.location_dest_id value is coming from the `move_line_ids` value in `_put_in_pack`, this commit adds a context key to skip this write in case we're coming from `picking._put_in_pack`

#### speedup

In a 17.4 customer database, putting in pack for a picking with 1800 move_lines: 1.5s -> 90ms


---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#200767

The date and time displayed in the order section of a POS session were always shown in GMT, ignoring the user's time zone. ![image](https://github.com/user-attachments/assets/c5644bc7-7a12-4e69-93b9-a7eaceac5532) opw-4416447 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Issue: order.company.partner_id[1] is undefined during the change to use `order` object as props component. in this PR: #189446 Purpose of this PR: use order.company.name if it exists to include into the receipt header. opw-4654437 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

When putting products in pack from the picking FormView `picking._put_in_pack` is eventually called. This method does a few things, amongst those is a write on picking.move_line_ids and another is the creation of a new package level. Both of these can be a bit slow when the picking's number of move_lines gets bigger. This can happen for SN tracked products for instance. In a database with 1800 move_lines, each _put_in_pack call takes around 1.5s, which can become cumbersome when customers are using multiple packages. Most of this slowness is coming from two things. The first one is stock.quants synchronization when writing on move.lines. The propose solution in this commit is to skip this synchronization when the only value in the vals dict is `result_package_id`. We can do that because this value is not used in the first quants synchronization of the write method. The second one is a write of `location_dest_id` on the picking's move_ids and move_line_ids in `package_level.create`. Since the package_level.location_dest_id value is coming from the `move_line_ids` value in `_put_in_pack`, this commit adds a context key to skip this write in case we're coming from `picking._put_in_pack` #### speedup In a 17.4 customer database, putting in pack for a picking with 1800 move_lines: 1.5s -> 90ms --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#200767

Issue ===== When product's code is computed, which is depend of the product's suppliers since each supplier can have a specific code, the first supplier is taken regardless if this supplier info is specific to another product variant which can cause to use the wrong code if there is multiple supplier with the same vendor but for different variants of the same product template. How to reproduce ================ 1. Install Puchase and Barcode; 2. Create a product with at least 2 variants; 3. In the "Purchase" tab of this product, add two vendor pricelists with the same vendor but each for a different product variant and each with a different code; 4. Go in Purchase, create a new RFQ for this vendor, add a PO line for each variant and confirm the order; 5. Go in Barcode and open the PO's receipt -> You can see both lines have the same vendor's code (from the first pricelist) regardless the pricelist's product variant. Cause of the issue ================== In `_compute_product_code`, it uses the first product (template) supplier info regardless the product variant. Solution ======== In `_compute_product_code`, we skip a supplier info if it concerns another variant, and we break the supplier info loop only if it concerns the current product variant. Miscellaneous ============= The check of the `product.supplierinfo` `read` access right is moved outside of the loop so it is done only one time. [OPW-4589073](https://www.odoo.com/odoo/project/49/tasks/4589073) Forward-Port-Of: odoo/odoo#202592 Forward-Port-Of: odoo/odoo#201753

- In POS, open a register and add Product A with a price of 100. Proceed with the payment using a card. - Close the register, increase the cash count by 20, and reduce the card count to 80. In the session report, the difference in the card payment is not displayed correctly. It shows the expected amount as 100 and the counted amount as 100, whereas it should be expected at 100 and counted at 80. Commit https://github.com/odoo/odoo/commit/01b87f1230beac0568f4e3b1b76e547909506892#diff-143d17de807d23650088a8c12f0a5b5cc2246b1b51e0bb7634e85247b6e535ea made journal entry optional for payments and removed the `synchronize_from_moves` method from `account_payment`. This mean that there is no longer a synchronization between account_payment and its potential journal entries. The source (here pos_session) is now responsible for creating and linking the moves to the payment. The amount field of account_payment, which is used to construct the session report and created in `_create_combine_account_payment` was not updated with the new balance created in `_apply_diff_on_account_payment_move`. opw-4494656 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196253

Steps to reproduce: - In any of the SOL Many2one field with create=True. - Create a SOL using create option in dropdown. Issue: - A SOL is created without product. Reason: - Incorrect SQL constraint passed . Fix: - Adding a validation error which is tapped in if Many2one quick create i.e., Create option fails and opens the Many2X form. - We cant change the SQL contraint because it is only applied when module is intalled/updated/reinstalled. --- Why the SQL contsraint fails "CHECK(display_type IS NOT NULL OR is_downpayment OR (product_id IS NOT NULL AND product_uom IS NOT NULL))" Also is_downpayment doesnt have a default value. Here consider we dont event send a single value all as nulls then result would be CHECK(NULL IS NOT NULL OR NULL OR (NULL IS NOT NULL AND NULL IS NOT NULL)) CHECK(FALSE OR NULL OR (FALSE AND FALSE) CHECK(FALSE OR NULL OR FALSE) CHECK(NULL) SQL doesn't categorize NULL into truthy or falsy value. For example a SQL constraint as CHECK (row1 NOT NULL OR row2 ...(and N number of conditions)) -- will always pass the check (even if you pass all the rows as NULL) NULL OR NULL -- TRUE (passes the empty NULL column value as [null]) FALSE OR NULL -- TRUE (passes the empty NULL column value as [null]) TRUE OR NULL -- TRUE It there is another column which has value it glady create a row with values and [null]/empty value for others. task-4441043 Co-Authored By - @xavierbol Forward-Port-Of: odoo/odoo#202769 Forward-Port-Of: odoo/odoo#192464

#### This PR addresses 2 issues with the update of Manufacturing Order with kit products in the BoM (and subsequent bugs). Please see commits for details on the issues. Issue 1 ----- When using the "Update BOM" button for a confirmed manufacturing order, quantities for components derived from kit products are incorrectly updated to the kit product's bom instead of the new required quantity. Issue 2 ----- When using the "Update BOM" button for a confirmed manufacturing order, components used to produce a specific variant of a kit product are not added to the MO consumables. Commit breakdown ----- - Commit 1 (handle component quantities - first ticket): - use the correct exploded value for the quantity (divided by the original quantity as the ratio isn't done for the top-level bom) - update test_update_mo_from_bom_with_kit with correct values - extend test_update_mo_from_bom_with_kit for when the kit components' quantities are updated - Commit 2 (handle components for specific variants - second ticket): - adapt the filtering of bom lines to keep them based on the kit's attribute instead of the end product one's - add a new test_update_mo_from_bom_with_kit_vraiants - Commit 3 (handle confusion of multi-variants/UoM kits - additional issues): - change bom_lines_by_id to a defaultdict to consolidate quantity of components - update test_update_mo_from_bom_with_kit to test for multiple UoMs - update test_update_mo_from_bom_with_kit_variants to test for multiple variants ----- Tickets: opw-4473337 opw-4480039 Forward-Port-Of: odoo/odoo#196227

[[FIX] account_batch_payment: show correct amount in reconciled batch payments](https://github.com/odoo/enterprise/pull/80862/commits/d9f837d4bb459a10e74b65c10204e2c31573e7a5) **Issue:** When reconciling a batch payment, its amount is incorrectly displayed as zero in the list view. **Steps to Reproduce:** 1. Install the Accounting app. 2. Navigate to Accounting > Customers > Payments. 3. Create or select two payments, then click Create Batch. 4. Validate the batch payment. 5. Go to Dashboard > Transactions. 6. Create a new transaction with the same value as the batch payment. 7. Click on the transaction, select the batch payment, and click Validate to reconcile them. 8. Navigate to Customers > Batch Payments. 9. Observe that the batch payment in the list view shows an amount of zero. Expected Behavior: The list view should display the sum of the payments included in the batch. Actual Behavior: The amount displayed in the list view is always zero after reconciliation. **Root Cause** During reconciliation, when execution reaches line 138 in account_batch_payment.py https://github.com/odoo/enterprise/blob/08084d8423a7d75c1ee2647256e01a464eec0b14/account_batch_payment/models/account_batch_payment.py#L137 , the batch payments are already in the paid state. However, _valid_payment_states() https://github.com/odoo/enterprise/blob/08084d8423a7d75c1ee2647256e01a464eec0b14/account_batch_payment/models/account_batch_payment.py#L69-L70 calls _get_invoice_in_payment_state(), which returns "in_payment". As a result, _valid_payment_states() only returns "in_process", excluding payments in the "paid" state from the computation. Consequently, in _compute_from_payment_ids(), the loop over valid payments is skipped, leaving the amount variable at its initial value of zero. https://github.com/odoo/enterprise/blob/08084d8423a7d75c1ee2647256e01a464eec0b14/account_batch_payment/models/account_batch_payment.py#L132-L162 **Fix** Always compute `amount`. Skip `amount_residual` and `amount_residual_currency` for valid payment states. Opw-4585624 Forward-Port-Of: odoo/enterprise#80862

Currently an error occurs when the user tries to uninstall `Sales` or `helpdesk_sale_timesheet` after creating a helpdesk ticket. Steps to generate an error: - Create a database without a demo and install helpdesk_sale_timesheet. - Create a helpdesk ticket. - Now try to uninstall sale_management (Sales). Error `KeyError: 'helpdesk.ticket.sale_line_id'` This issue was generated because in the helpdesk ticket we have the `use_helpdesk_sale_timesheet` field (see [1]), which is a depends field of the `compute_sale_line_id` method, which is the compute method of the field sale_line_id (see [2] and [3]) in the helpdesk ticket. In helpdesk code line [4] tries to update the value of the field `use_helpdesk_sale_timesheet` since this field is related to the helpdesk ticket (see [1]) value of this field also changed in the helpdesk ticket, and the value was changed the compute method trigger because this field depends on the compute method. This commit will solve the above issue by executing an SQL query instead of writing the team field so it doesn't trigger depending on that field. [1]- https://github.com/odoo/enterprise/blob/1619b74b7895108a80d466c57972fc97923c860c/helpdesk_sale_timesheet/models/helpdesk_ticket.py#L27 [2]- https://github.com/odoo/enterprise/blob/1619b74b7895108a80d466c57972fc97923c860c/helpdesk_sale_timesheet/models/helpdesk_ticket.py#L31-L38 [3]- https://github.com/odoo/enterprise/blob/1619b74b7895108a80d466c57972fc97923c860c/helpdesk_sale_timesheet/models/helpdesk_ticket.py#L77-L78 [4]- https://github.com/odoo/enterprise/blob/1619b74b7895108a80d466c57972fc97923c860c/helpdesk/models/ir_module.py#L15 sentry-6308112739 Forward-Port-Of: odoo/enterprise#81008

Bug Fixes(2)

[FIX] point_of_sale: order time zone in a POS session

[FIX] point_of_sale: Include company name in receipt header

Other(40)

[FW][PERF] stock: prevent unecessary writes

Bug Fixes(2)

[FIX] point_of_sale: order time zone in a POS session

[FIX] point_of_sale: Include company name in receipt header

Other(40)

[FW][PERF] stock: prevent unecessary writes

[FW][FIX] account_payment: payment.transaction reference

[FW][FIX] pos_self_order: prevent adding to cart if option not selected

[FW][IMP] l10n_es: 0.5% recargo should go into 168/170

[FW][FIX] website_sale: hide internal product reference on eCommerce

[FW][FIX] product: wrong supplier code

[FW][PERF] account: Speed-up duplicate bills lookup in list view

[FW][IMP] point_of_sale: set default outstanding account

[FW][FIX] pos_self_order: combo product quantity mismatch issues

[FW][FIX] spreadsheet: reload cumulative data

[FW][FIX] sale: fix tour 'mail_attachment_removal_tour'

[FW][FIX] mail: discuss sidebar channel thread line style

[FW] PRHOOT 29

[FW][FIX] mrp: Improve UI of Manufactured smart button

[FW][FIX] point_of_sale: fix incorrect count in session report

[FW][FIX] stock: Hide Lot/SN column on Detailed Operations

[FW][FIX] hr_expense: prevent access error when checking vendor bill warning

[FW][FIX] website_sale: price unit computation in mobile

[FW][FIX] point_of_sale: print canceled order

[FW][IMP] sale,website_sale: improve product/combo configurator

[FW][FIX] sale_project: fix issue with SQL constraint causing to create SOL without product

[FW][IMP] l10n_be: handle VAT for belgium

[FW][FIX] mrp: correctly update MO consumption on kit BoM update

[FW][CLA] Signing Odoo Individual CLA

[FW][FIX] account: changed the name of fields in invoice_report read_group

[FW][FIX] account: fix traceback when the user removes the date value

[FW][FIX] documents_project: prevent projects from having no folder

[FW][ADD] l10n_my_hr_payroll(_account): New payroll localization

[FW][FIX] sign: translate model description in rendered mail templates

[FW][FIX] (documents_)spreadsheet(_edition): insert multi-line list cells

[FW][PERF] account_followup: speedup _compute_unpaid_invoices

[FW] PRHOOT 29

[FW][FIX] website_documents: don't throw AccessError in sudo mode

[FW][FIX] planning: fix inconsistent visibility of I take it button across view

[FW][FIX] frontdesk: keep "Welcome to" together for translations

[FW][FIX] account_reports: fix access error in multi branch environment

[FW][IMP] l10n_be_reports: Remove VAT report for warnings

[FW][FIX] account_batch_payment: show correct amount in reconciled batch …

[FW][FIX] account_asset: Correct depreciation computation by considering prorata date for disposed assets

[FW][FIX] helpdesk: prevent error while uninstalling module