Daily updates from Odoo
Monday, September 15, 2025
13 changes · 17.0
Resolved issues and error corrections
Steps to reproduce: 1. Add language Spanish(AR) 2. Go to Inventory (Inventario) > Operations (Operaciones) 3. Deliveries (Entregas) > Open any record. 4. Click ⚙ > Print (Imprimir) > Delivery Slip (Recibo de entrega) Issue: - The translation of "Delivery Slip" in Spanish (es_419) shows as "Recibo de entrega", which is incorrect for Argentina. Cause: - Odoo currently labels document as “Recibo de entrega”, but legally it must be “Remito de entrega”. According to AFIP General
Original PR description
Steps to reproduce: 1. Add language Spanish(AR) 2. Go to Inventory (Inventario) > Operations (Operaciones) 3. Deliveries (Entregas) > Open any record. 4. Click ⚙ > Print (Imprimir) > Delivery Slip (Recibo de entrega) Issue: - The translation of "Delivery Slip" in Spanish (es_419) shows as "Recibo de entrega", which is incorrect for Argentina. Cause: - Odoo currently labels document as “Recibo de entrega”, but legally it must be “Remito de entrega”. According to AFIP General Resolution 1415/2003(Arts. 28–30) a REMITO “R” or “X” must explicitly include “DOCUMENTO NO VÁLIDO COMO FACTURA” and follow the mandatory structure and data placement defined by law. Go through : https://www.odoo.com/mail/message/848099710 Solution: - Updated the translation from "Recibo de entrega" to "Remito de entrega" opw-5004345
Issue: - The translation of "Delivery Slip" in Spanish (es_419) shows as "Recibo de entrega", which is incorrect for Argentina. Cause : - Odoo currently labels document as “Recibo de entrega”, but legally it must be “Remito de entrega”. According to AFIP General Resolution 1415/2003(Arts. 28–30) a REMITO “R” or “X” must explicitly include “DOCUMENTO NO VÁLIDO COMO FACTURA” and follow the mandatory structure and data placement defined by law. Go through : https://www.odoo.com/mai
Original PR description
Issue: - The translation of "Delivery Slip" in Spanish (es_419) shows as "Recibo de entrega", which is incorrect for Argentina. Cause : - Odoo currently labels document as “Recibo de entrega”, but legally it must be “Remito de entrega”. According to AFIP General Resolution 1415/2003(Arts. 28–30) a REMITO “R” or “X” must explicitly include “DOCUMENTO NO VÁLIDO COMO FACTURA” and follow the mandatory structure and data placement defined by law. Go through : https://www.odoo.com/mail/message/848099710 Solution: - Updated the translation from "Recibo de entrega" to "Remito de entrega" opw-5004345
This fix ensures Odoo returns the nearest main view ID when a request starts from an extension view. It helps avoid mismatches between the displayed screen layout and the view identifier used by customizations or integrations.
Original PR description
Before this commit, when executing `ir.ui.view.get_view(view_id)` where view_id points to an extension view, the method return the correct arch but the inherited view's id. After this commit, it returns the id of the closest primary view. opw-4930800 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
The subscription portal no longer offers advance payment when there is nothing currently due to invoice. This prevents customers from attempting a zero-value payment and seeing an avoidable payment error.
Original PR description
## Issue: When you create a Subscription for a product that should be invoiced after Delivery with Required Payment, you can Anticipate the payment even if the amount to invoice is 0.0 When you do that, a payment error will be displayed ## Cause: The Anticipate Payment session is displayed based on the `invoice.amount_total` instead of the `invoice.amount_to_invoice` In 18.0, the session is hidden because it use a adapted version of the amount to invoice: https://github.com/odoo/enterprise/blob/2f3698b250092ad376344e959d46bdc0eebf1a81/sale_subscription/views/sale_subscription_portal_templates.xml#L262 ## Steps to reproduce: - Create a Product (Invoicing Policy: Delivered Quantity) - Add it to a New Subscription - Set the Recurring Plan to Monthly - In the Other Info tab, disable Online Payment - Send by Email and open the link in a Private Broser - Sign the Subscription - The Anticipate Payment is available for 0.0 opw-4914578
The printer interface now handles errors from the printing system when adding a printer, such as invalid printer names or read-only storage. Instead of stopping, it logs the issue and keeps the printer service running, improving reliability for connected printing devices.
Original PR description
Before this commit, if CUPS raised an error when adding a printer in the `supported()` method of the printer driver, the exception would not be caught causing the printer interface to stop. This can happen for example if the filesystem is read-only or the printer has an invalid name. After this commit, we catch any CUPS errors and log them, allowing the printer interface to continue running. We also enter write mode before adding the printer to prevent any read-only errors. task-5086036 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue where FedEx Home Delivery shipments could fail when generating return labels because the recipient address was not marked as residential. This helps businesses using FedEx Home Delivery avoid blocked delivery validation and return label creation errors.
Original PR description
**PROBLEM** When selecting FedEx Home Delivery service, and enabling the return label generation, we got the error `RECIPIENT.ADDRESS.ERROR`. **STEPS TO REPRODUCE** 1. Install delivery_fedex_rest (use the new fedex credentials). 2. On the FedEx US shipment method (demo data) select FedEx home delivery service, and check the `Generate Return Label` option. 3. Create a SO, add shipping with FedEx US, validate the SO. 4. Validate the delivery order, and notice the FedEx API return an error. **CAUSE** For Home Delivery Service, the recipient address need to have the `residential` flag set to true. In `_return_package()`, the request sent doesn't include this flag, leading to an error. **FIX** Fix `_return_package()` query to include the `residential` flag. opw-4939065
This update corrects a date used in an automated product margin test. It helps keep quality checks reliable without changing how users work with product margins.
Original PR description
runbot-230719 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an error that blocked users from logging timesheets on projects shared across multiple companies. When no company is set on the project, the system now uses the user's current company so the correct employee record is found.
Original PR description
steps to reproduce: ------------------- 1. Install Employees, Timesheets, Projects 2. Create 2 companies 3. On each company, create an employee for the same related user 4. Create a project without…
steps to reproduce: ------------------- 1. Install Employees, Timesheets, Projects 2. Create 2 companies 3. On each company, create an employee for the same related user 4. Create a project without setting a company (making it a global project). 5. Enable both companies in the systray 6. Try to log a timesheet on the global project. issue: ------ A ValidationError is raised: "Timesheets must be created with an active employee in the selected companies." cause: ------ During `vals_list` preparation, the `company_id` value is overwritten here: https://github.com/odoo/odoo/blob/605e47a85561614c17fe2e6f59618610f87c69bb/addons/hr_timesheet/models/hr_timesheet.py#L381 If the project has no company set, `company_id `becomes **False**. This condition fails if the user has two employees and no company set (or if it is missing): https://github.com/odoo/odoo/blob/d3c7e51e94d98da9086a3817b157c4e125c80790/addons/hr_timesheet/models/hr_timesheet.py#L211-L215 solution: --------- Use `self.env.company` if company_id is missing(or False) in the vals. opw-4892449 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Shiprocket Cash on Delivery shipments now correctly include coupon discount amounts when orders are sent to Shiprocket. This helps ensure the amount collected from customers reflects promotional discounts, avoiding overcharging and reconciliation issues.
Original PR description
Issue ----- When using Shiprocket with the "Cash On Delivery", the request sent to the Shiprocket API doesn't contain the amounts discounted by coupons. Steps to reproduce ----- - Set an Indian…
Issue
-----
When using Shiprocket with the "Cash On Delivery", the request sent to the Shiprocket API doesn't contain the amounts discounted by coupons.
Steps to reproduce
-----
- Set an Indian company up (with valid address and some dummy mail & phone)
- Create a customer "IN Cust" (with valid address and some dummy mail & phone)
- Create a product "IN Prod"
- Sale price: 1000 INR
- Weight: 100g
- Set some reference, eg "INPROD"
- Create a Shiprocket delivery method
- Payment Method: COD
- Set some "Shiprocket Channel"
- Enable Debug requests
- In settings, enable "Promotions, Loyalty & Gift Card"
- Go to Sales > Products > Discount & Loyalty
- Create a new program
- Name: 50% off
- Program Type: Coupons
- Change the existing reward to 50% discount on order
- Generate some coupon
- Copy the code of the generated coupon
- Create a SO our product and customer
- Use the coupon code & apply the 50% discount
- Add shipping
- Shiprocket COD
- Get rate
- Confirm the SO
- Go to the picking & validate it
- Open logs (Settings/Technical/Database Structure/Logging)
- Open the "shiprocket_request_external/shipments/create/forward-shipment" log
--> total_discount is 0
Cause
-----
The problem comes from
https://github.com/odoo/enterprise/blob/a971f55e736f9645eda137fd6dcb574483886483/delivery_shiprocket/models/shiprocket_request.py#L301
There are 2 issues here.
The first and most important one is how we find the discount lines.
https://github.com/odoo/enterprise/blob/a971f55e736f9645eda137fd6dcb574483886483/delivery_shiprocket/models/shiprocket_request.py#L320
Discounts from coupons don't use the `sale_discount_product_id`. We can use the `_can_be_invoiced_alone` function to find both regular and loyalty discounts
https://github.com/odoo/odoo/blob/ee63fe7863dfa0083674dc927c1aa67c9e36c481/addons/sale/models/sale_order_line.py#L1033-L1041
def _can_be_invoiced_alone(self):
""" Whether a given line is meaningful to invoice alone.
It is generally meaningless/confusing or even wrong to invoice some specific SOlines
(delivery, discounts, rewards, ...) without others, unless they are the only left to invoice
in the SO.
"""
self.ensure_one()
return self.product_id.id != self.company_id.sale_discount_product_id.id
https://github.com/odoo/odoo/blob/ee63fe7863dfa0083674dc927c1aa67c9e36c481/addons/sale_loyalty/models/sale_order_line.py#L50-L51
def _can_be_invoiced_alone(self):
return super()._can_be_invoiced_alone() and not self.is_reward_line
We just have to be careful not to accidentally include delivery fees because of
https://github.com/odoo/odoo/blob/ee63fe7863dfa0083674dc927c1aa67c9e36c481/addons/delivery/models/sale_order_line.py#L18-L19
def _can_be_invoiced_alone(self):
return super()._can_be_invoiced_alone() and not self.is_delivery
The second issue is that we use the untaxed discount amount.
https://github.com/odoo/enterprise/blob/a971f55e736f9645eda137fd6dcb574483886483/delivery_shiprocket/models/shiprocket_request.py#L321
This leads to an incoherent total amount, since the tax is computed on the products' full prices. We should instead be forwarding the total discount value (with tax included to offset the taxes applied on the full product price).
-----
Community PR:
https://github.com/odoo/odoo/pull/223517
Ticket:
opw-4755357This fix ensures coupon and loyalty discounts are properly recognized on sales orders so Shiprocket Cash on Delivery requests include the correct discounted amounts. It also prevents manually created discount lines from being reset to zero when their quantity changes, improving order total accuracy.
Original PR description
Issue ----- When using Shiprocket with the "Cash On Delivery", the request sent to the Shiprocket API doesn't contain the amounts discounted by coupons. Steps to reproduce ----- - Set an Indian…
Issue ----- When using Shiprocket with the "Cash On Delivery", the request sent to the Shiprocket API doesn't contain the amounts discounted by coupons. Steps to reproduce ----- - Set an Indian company up (with valid address and some dummy mail & phone) - Create a customer "IN Cust" (with valid address and some dummy mail & phone) - Create a product "IN Prod" - Sale price: 1000 INR - Weight: 100g - Set some reference, eg "INPROD" - Create a Shiprocket delivery method - Payment Method: COD - Set some "Shiprocket Channel" - Enable Debug requests - In settings, enable "Promotions, Loyalty & Gift Card" - Go to Sales > Products > Discount & Loyalty - Create a new program - Name: 50% off - Program Type: Coupons - Change the existing reward to 50% discount on order - Generate some coupon - Copy the code to the generated coupon - Create a SO our product and customer - Use the coupon code & apply the 50% discount - Add shipping - Shiprocket COD - Get rate - Confirm the SO - Go to the picking & validate it - Open logs (Settings/Technical/Database Structure/Logging) - Open the "shiprocket_request_external/shipments/create/forward-shipment" log --> total_discount is 0 Cause ----- The problem comes from https://github.com/odoo/enterprise/blob/a971f55e736f9645eda137fd6dcb574483886483/delivery_shiprocket/models/shiprocket_request.py#L301 There are 2 issues here. The first and most important one is how we find the discount lines. https://github.com/odoo/enterprise/blob/a971f55e736f9645eda137fd6dcb574483886483/delivery_shiprocket/models/shiprocket_request.py#L320 Discounts from coupons don't use the `sale_discount_product_id`, we'll have to define a new function to override in `sale_loyalty` for this. The second issue is that we use the untaxed discount amount. https://github.com/odoo/enterprise/blob/a971f55e736f9645eda137fd6dcb574483886483/delivery_shiprocket/models/shiprocket_request.py#L321 This leads to an incoherent total amount, since the tax is computed on the products' full prices. We should instead be forwarding the total discount value (with tax included to offset the taxes applied on the full product price). ----- Enterprise PR: https://github.com/odoo/enterprise/pull/92310 Ticket: opw-4755357
The data merge process now ignores company differences when a database only uses one company. This lets users find and merge duplicate records that were previously missed, improving data cleanup accuracy.
Original PR description
**Issue** In single company databases, it wasn't possible to find duplicate records with different `company_id` values to merge them (in multi company databases, it is possible to enable the "Cross-Company" option on the deduplication rule). **Change** Always ignore the company field in single company databases. opw-4794408
The appointment booking page now shows the correct maximum number of people based on all available resources, rather than being limited by the first resource found. This prevents customers from seeing too few available spots and helps businesses make full use of their appointment capacity.
Original PR description
**How to reproduce:** - Create an appointment with availability assigned to a resource. - Enable 'Manage Capacity' - Set the capacity of the first resource lower than the second one. - Open the appointment's booking page. **Technical Reason:** If appointment is scheduled based on 'resource_time' then resource_default is updated as the first value of resource_possible. Related PR: https://github.com/odoo/enterprise/pull/47059 **After this PR:** 'Number of people' dropdown will display the maximum capacity from all available resources. Task-4664393
Customers who paid an invoice can now update their billing address when no country was previously set, even if VAT details are locked. This prevents them from being stuck with incomplete billing information in the portal.
Original PR description
After paying an invoice, a customer without a billing country cannot update the country in their billing address because the form is disabled by the VAT edition rule. **Steps to reproduce:** 1.…
After paying an invoice, a customer without a billing country cannot update the country in their billing address because the form is disabled by the VAT edition rule. **Steps to reproduce:** 1. Create a customer without a billing country. 2. Generate an invoice for that customer. 3. Pay the invoice (possible with some payment providers). 4. Go to the customer portal and try to update the billing address. The country field is disabled if VAT is not editable, preventing the customer from setting their country. This fix ensures that if the partner has no country set, the field remains editable even when the VAT field is locked. NOTE: Some payment providers indeed do not allow paying an invoice or a sale order without a country being set, but when this situation occurs the portal must still allow the customer to complete their billing address afterwards. **NOTE: This fix is applied starting from Odoo 17, but the issue mainly affects later versions in the `website_sale` module, where the country field is blocked in the checkout form.** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr