Monday, September 15, 2025
9 changes · 17.0
Enhancements to existing features
This update adds SUNAT refund reason 13 for Peruvian electronic credit notes. Businesses can now issue compliant credit notes when correcting outstanding payment amounts, due dates, or installment amounts.
Original PR description
In Peru, electronic invoicing requires refund reasons (motivos de nota de crédito) defined by SUNAT. The current implementation includes codes 01–12, but is missing code 13, which is mandatory in…
In Peru, electronic invoicing requires refund reasons (motivos de nota de crédito) defined by SUNAT. The current implementation includes codes 01–12, but is missing code 13, which is mandatory in some scenarios. **Before this PR** - Only refund reasons 01 to 12 are available in the selection field "Refund Reason" on credit notes. - Users cannot issue a credit note with reason 13: "Correction of the outstanding net amount to be paid and/or the due date(s) of the single payment or the installments and/or the amounts corresponding to each installment, if applicable." **After this PR** - Refund reason 13 is added to the selection field in `account.move`. - Users can issue credit notes with this refund reason, and the value is exported correctly in the XML according to SUNAT requirements. - Translation updated in `es_419.po`. This ensures that credit notes with this refund reason can be issued in compliance with SUNAT regulations. [Task](https://www.odoo.com/odoo/project/809/tasks/5091062)
Resolved issues and error corrections
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 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