Tuesday, July 8, 2025
13 changes · saas-18.4
New functionality added to Odoo
Adds a new Türkiye localization feature that creates e-Dispatch XML files from individual stock transfers. Businesses can upload these files to Nilvera to create compliant electronic dispatch records, reducing manual preparation work.
Original PR description
This PR adds a new module for Türkiye e-Dispatch. It generates an XML file for individual stock transfer which can be uploaded to Nilvera to create e-Dispatch records. TaskID:4270304 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#217614 Forward-Port-Of: odoo/odoo#194384
Enhancements to existing features
Colombian electronic invoicing now supports retrieving a customer's name and email from the DIAN service using only their identification type and number. This helps businesses comply with local rules that limit what customer information they may request directly.
Original PR description
The Colombian government restricts the information a company can ask from their customers to only their identification type and number. The other data (name and email) is required to be fetched from the DIAN service. task: 4796355 Forward-Port-Of: odoo/enterprise#86172
Resolved issues and error corrections
This fixes an issue where text entered in the website builder, such as “<br>”, could be incorrectly changed when saving translations, blog titles, or reusable blocks. Users can now save literal text with special characters without it turning into the wrong display or HTML behavior.
Original PR description
> 65. Special character written in translation are being converted into HTML Entity name like `<br> => <br>`
The dialog shown when an IoT Box is found has been updated to make the setup experience easier for users. This helps users understand the next steps more quickly when connecting IoT hardware.
Original PR description
We updated the IoT Box found dialog in order to ease user experience. Task: 4922620 Forward-Port-Of: odoo/enterprise#89608
This fixes an Inventory issue where reception reports and labels were downloaded as PDFs instead of being sent to the assigned IoT printer. The system now retrieves the proper report setup from the server, so warehouse teams can print reception documents through their configured devices as expected.
Original PR description
Steps to reproduce: 1. Connect IoT Box and any printer that accepts PDF 2. Turn on Reception Report option on Inventory Settings 3. Set configuration of Receipts to print out Reception Report and…
Steps to reproduce: 1. Connect IoT Box and any printer that accepts PDF 2. Turn on Reception Report option on Inventory Settings 3. Set configuration of Receipts to print out Reception Report and Label 4. Assign Reception Report and label to the printer 5. Create a PO and run through the Reception process (PO > Reception of Delivery) 6. Print the Reception Report under "Allocations" -> Result: Reception Report and label is downloaded as a PDF instead of being sent to the printer. The reason for this bug is that the report models were being constructed directly in the frontend, rather than being fetched from the backend. This didn't work with IoT printing because its override used to assign devices to reports is on the backend `ir.actions.report` model. The fix is to fetch the report from the backend when the component is loaded. This report is then passed down to the child components as well. opw-4790299 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#217693 Forward-Port-Of: odoo/odoo#215887
Point of Sale receipts now show the cashier who is active when the order is paid, rather than the cashier first assigned to the order. This prevents incorrect staff attribution on receipts when the cashier is changed during payment.
Original PR description
**Problem:** When cashier A is assigned to an order, then changed during the payment screen process to cashier B, the receipt will display Served by cashier A. It should be Served by cashier B as this is the one that closed the order. This used to work until 18.0. **Steps to reproduce:** - Add some employees to your PoS, using pos_hr - Select one of them, then change to another one during the payment screen, before paying - Pay for it, the receipt screen still displays the first cashier **Why the fix:** The receipt should first display the current cashier, not the order's cashier. It was done the other way around before this commit. We now first display the session's cashier, then if not available we display the order's cashier. opw-4868038 Forward-Port-Of: odoo/odoo#216339 Forward-Port-Of: odoo/odoo#215543
Fixed a Point of Sale loyalty issue where refunding an order paid with reward points could deduct those points a second time. Refund transactions now avoid recharging loyalty points, preventing customers from unfairly losing rewards.
Original PR description
**Problem:** When refunding an order that has been paid using a reward system, the points are deducted again as if the client made another purchase using those points. This means that in the case of a refund, the client would not only lose those points but have to spend them again. **Steps to reproduce:** - Make a purchase in POS using a reward such as $1 for every point - Refund this purchase - The points are deducted again **Why the fix:** The points do not need to be refunded after a refund, but they don't have to be paid again. The total point for this refund order is now set to zero in case of a refund. This means the transaction will not be visible on the Coupon Card in the Loyalty Program. opw-4771724 Forward-Port-Of: odoo/odoo#217010 Forward-Port-Of: odoo/odoo#212922
The IoT Wi-Fi status check now avoids triggering slow network scans when loading homepage data. This prevents occasional 5-15 second delays and gives users a faster, more consistent homepage experience.
Original PR description
Before this commit, the `get_current()` method in the wifi helper would occasionally run very slowly, taking 5-15 seconds. This is because the `nmcli` command it was calling would periodically re-scan the network so the information it returned was up-to-date. Because the homepage data controller used this method, it would also sometimes take 5-15 seconds to load, leading to a bad experience for the user. After this commit, the `get_current()` method uses a different `nmcli` command that only shows the status of the currently connected network, avoiding a re-scan and therefore always running quickly. task-4922640 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#217682
This fixes Planning so copied shifts calculate open shift hours correctly when an employee is on leave. It prevents lunch breaks from being counted as extra working time, improving schedule accuracy and avoiding overstated allocated hours.
Original PR description
**Issue:**
When a resource is on leave for a particular day, and an open shift is created for that day, the open shift includes lunch time, which causes the total allocated hours to be incorrect.
**Example:**
- Shift duration: 1 week (27th to 31st January)
- Resource on leave on 30th January
- Move to the next week and copy the previous week's shift
- New shift created:
- Monday to Wednesday and Friday assigned
- Open shift on Thursday (9 hours allocated)
However, 1 extra hour is added in the open shift.
**Steps to Reproduce:**
-Install the planning_holidays module.
- Create a shift for the week (27th to 31st January).
- Add leave for 6th February.
- Copy the previous week's shift.
- Check the allocated hours for 6th February.
task-4224781
Forward-Port-Of: odoo/enterprise#89502
Forward-Port-Of: odoo/enterprise#73478This fixes a validation error when using Sendcloud batch shipping for deliveries split into packages with average weights that are not whole numbers. The system now sends weights in the integer format required by Sendcloud, allowing affected deliveries to be validated successfully.
Original PR description
### Steps to reproduce: - Configure the sendcloud delivery method (for instance with Bpost @home for a belgian company) and enable the `Use Batch Shipping`` option on the delivery method. - Create a…
### Steps to reproduce:
- Configure the sendcloud delivery method (for instance with Bpost @home for a belgian company) and enable the `Use Batch Shipping`` option on the delivery method.
- Create a storable product with a weight of 1 kg and a positive volume.
- Create and confirm sale order for 4 units
- Add shipping -> chose sendcloud
- Separate the delivery of 4 kg in 3 packs:
- set quantity to 1 -> put in pack
- set quantity to 2 -> put in pack
- set the quantity to 4 -> put in pack
- Try to validate the delivery
#### > invalid operation: weight: "A valid integer is required."
### Cause of the issue:
Sendcloud's api only accept integer values for the weight:
However, to evaluate the price of the parcel accurately for a batch shipping we need to compute the average weigth to provide to sendcloud. Converted to grams we tehrefore provide a value of 1333.333333 to sendcloud which raises an invalid operation:
https://github.com/odoo/enterprise/blob/72b4a223ec4e2e09fc93bebd150923abba37a8df/delivery_sendcloud/models/sendcloud_service.py#L378-L379 https://github.com/odoo/enterprise/blob/72b4a223ec4e2e09fc93bebd150923abba37a8df/delivery_sendcloud/models/sendcloud_service.py#L205-L207 https://github.com/odoo/enterprise/blob/72b4a223ec4e2e09fc93bebd150923abba37a8df/delivery_sendcloud/models/sendcloud_service.py#L44
opw-4874063
Forward-Port-Of: odoo/enterprise#89495This fix ensures Odoo waits for the user to choose a printer before continuing with queued reception reports and labels. It prevents the printer selection window from closing too soon, so documents are correctly sent to the IoT-connected printer during inventory reception workflows.
Original PR description
Steps to reproduce: 1. Connect IoT Box and any printer that accepts PDF 2. Turn on Reception Report option on Inventory Settings 3. Set configuration of Receipts to print out Reception Report and…
Steps to reproduce: 1. Connect IoT Box and any printer that accepts PDF 2. Turn on Reception Report option on Inventory Settings 3. Set configuration of Receipts to print out Reception Report and Label 4. Assign Reception Report and label to the printer 5. Create a PO and run through the Reception process (PO > Reception of Delivery) 6. Validate the Reception of the order -> Result: Odoo will prompt the customer to select a printer, however we are not able to choose a printer in time as the process continues without selecting one. This in return does not send the report to the printer via IoT. The root cause of this bug is that the IoT report handler JS function returns too early, it resolves once the printer selection popup has appeared, instead of resolving once the printer has actually been selected and is starting to print. Therefore the multi-report printing code assumes the print is done and triggers the next print, which causes the popup to close before the user can select a printer. To solve this bug, we listen for a 'printer-selected' event in the handler, and resolve only once we have received this event. This fixes the flow, allowing a printer to be selected for each report that is being printed in sequence. opw-4790299 Forward-Port-Of: odoo/enterprise#89617 Forward-Port-Of: odoo/enterprise#88538
UPS deliveries to customers in Mexico can now be processed successfully because each package includes the required merchandise description. This prevents shipment validation failures caused by missing package-level information in the UPS REST connector.
Original PR description
**Current behavior:** Using the UPS rest connector and trying to process a delivery to a Mexico-based customer will fail with error code: `121984 - A package in a Mexico shipment must have a…
**Current behavior:** Using the UPS rest connector and trying to process a delivery to a Mexico-based customer will fail with error code: `121984 - A package in a Mexico shipment must have a Merchandise Description.` **Expected behavior:** Can process shipment. **Steps to reproduce:** 1. Create a UPS rest delivery option 2. Create an SO for some product to a Mexico-based client, add the UPS delivery, confirm, try to validate the delivery -> 400 **Cause of the issue:** For non-return shipments, the description in the Package object is `None`, but when the receiver is based in Mexico, this field is required. **Fix:** Create a package level description based on the one added here: https://github.com/odoo/enterprise/commit/a7b8673364e0ac626bcc8ded72501c4f2866564c To the UPS API spec here: https://developer.ups.com/tag/Shipping?loc=en_PE&tag=Rating#operation/Shipment!path=ShipmentRequest/Shipment/Package/Description&t=request opw-4508139 Forward-Port-Of: odoo/enterprise#86411
Credit notes in the Kenya eTIMS integration can now only be submitted when the related invoice has already been successfully submitted. This helps prevent rejected or invalid tax submissions and keeps credit notes properly tied to compliant invoice records.
Original PR description
To ensure credit notes are only submitted for invoices that have been submitted to eTIMS, we now restrict credit note submission to cases where the related invoice has already been successfully submitted. Forward-Port-Of: odoo/enterprise#89464 Forward-Port-Of: odoo/enterprise#89385