Tuesday, April 15, 2025
11 changes · 18.0
Enhancements to existing features
Saudi e-invoicing now treats certain ZATCA rejection responses consistently, preserving the right audit trail and invoice sequence behavior. Rejected invoices keep their original confirmation time, are stored as protected attachments, and show clearer error details for users.
Original PR description
But also: - not 400/500 should keep the chain index (each sequential number should have a corresponding invoice) - confirmation datetime should stay the same when the invoice was rejected - Before, the response could get complicated where the json was stringified in the json, while here it is all in the json itself. And so the 400 should be treated the same as other errors. 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
Resolved issues and error corrections
Cancelled point-of-sale restaurant orders are now kept in the correct cancelled state when synced to the server. This prevents empty orders from being treated as paid, avoiding fiscal data errors during session closing in affected localizations.
Original PR description
Before this commit, if the state of an order was set to 'cancel' and then the order was synced to the server, it would incorrectly be saved as 'paid'. This could happen in a POS restaurant environment, for example, when releasing a table. As a result, empty orders would appear as paid, which is incorrect. This behavior was particularly problematic in certain localizations where such empty, paid orders lacked required fiscal data, leading to errors during session closing. opw-4714877 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Touchscreen devices are now properly recognized when Chromium runs in kiosk mode on Wayland. This ensures kiosk experiences, such as self-order screens, can apply touch-specific behavior like hiding the cursor.
Original PR description
Before this commit, when Chromium was running in kiosk mode under Wayland, it would not detect that the input device was a touchscreen. This resulted in touchscreen-specific code (such as hiding the cursor in the self-order kiosk) not working. After this commit, we pass the `--touch-events` flag to Chromium when running in kiosk mode, which forces touch events to be enabled. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Changing the journal on a draft payment now also updates the related journal entry and its numbering. This keeps accounting records aligned with the selected journal and prevents mismatched references before payments are posted.
Original PR description
When changing the journal on a draft payment, the linked journal entry was not updated. This caused two issues: The journal entry kept the old journal. The sequence (move name) was not updated to match the new journal. Now, when the journal is changed on a draft payment, both the journal and its sequence are correctly updated. task-4688823 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
This fixes an issue where replacing an event ticket in a Point of Sale order after selecting online payment could block order validation. Businesses can now adjust event ticket lines during checkout and complete the sale using another payment method without errors.
Original PR description
Before this commit, deleting a synced orderline linked to an event registration and then adding a new event product to the same order could cause an error when validating the order. Steps to reproduce: 1. Enable Events with PoS 2. Enable Online Payment 3. Add a ticket product to the order 4. Proceed to the payment screen, and select online payment 4. Delete the ticket line and add a different one 5. Complete the order using cash or another offline payment method opw-4714193 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Archived PEPPOL EDI proxy users are now ignored when Odoo looks for the active electronic invoicing user for a company. This prevents save errors in contact and invoicing settings when a company has both an archived and an active PEPPOL user record.
Original PR description
In lots of places within peppol we suppose that we only have one edi user, but we can end up in a situation where this is not the case by archiving a user. In some cases, where there is `active_test…
In lots of places within peppol we suppose that we only have one edi user, but we can end up in a situation where this is not the case by archiving a user. In some cases, where there is `active_test = False`, we can end up in a situation with a traceback because there are multiple edi users if you count archived users
Steps to reproduce:
- Select company BE Company CoA
- Open Settings > Accounting > PEPPOL Electronic Invoicing
- Activate Electronic Invoicing (if is not activated)
- Go to Accounting / Configuration / EDI Proxy Users
- Select the unique record (demo2peppol)
- Edit the id_client of the record to another one (this must need Odoo Studio or Odoo Inspector > Write > {"id_client": "another"})
- Go to tree view of EDI Proxy Users
- Archive it
- Open Settings > Accounting > PEPPOL Electronic Invoicing
- Remove from PEPPOL (archived record will not be deleted)
- Activate Electronic Invoicing Again (now you have one record active and another not)
- Go to Contacts > Search "BE Company CoA" > Select Contact
- Go to Accounting Tab > Customer Invoices section > Enable eInvoice Format (BIS Billing 3.0)
- Go to Contact & Addresses Tab
- Try to add a new Contact type (error while saving)
opw-4572074When dropshipping is turned off, the related operation type is now archived instead of remaining active and causing errors. This reduces disruption for businesses that enable and later disable dropshipping, while preserving linked historical records such as purchase orders and rules.
Original PR description
Steps to reproduce the bug: - Go to inventory settings and enable dropshipping option -> the operation type: dropship in created - Disable the drop-shipping option in the settings -> The module is uninstalled, but the operation type is not archived so it can cause a traceback if using it. Problem: The best solution, is to remove completely the picking type, but as is linked to several other records, like rule or purchase order, it will be impossible to delete everything related, so the best solution is to archive it, so we can limit the impact of the uninstallation. opw-4690502
The spreadsheet component was updated to the latest version with fixes for clipboard paste behavior and data validation handling. Users should see more reliable formatting when pasting borders and smoother autofill performance in spreadsheets.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/f56013312 [REL] 18.0.23 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/f56013312 [REL] 18.0.23 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/117329171 [FIX] clipboard: huge revision on pasting borders [Task: 4718522](https://www.odoo.com/odoo/2328/tasks/4718522) https://github.com/odoo/o-spreadsheet/commit/68931ee59 [FIX] clipboard: duplicated `range` in data validation command [Task: 4718522](https://www.odoo.com/odoo/2328/tasks/4718522) https://github.com/odoo/o-spreadsheet/commit/648c77801 [PERF] autofill: improve command dispatching [Task: 4718202](https://www.odoo.com/odoo/2328/tasks/4718202) Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Mehdi Rachico (mera) <mera@odoo.com> Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Italian point of sale receipts now send global discounts to the fiscal printer in the correct format. This prevents validation errors when applying an overall discount and helps cashiers complete discounted sales normally.
Original PR description
### Before this PR - Go on point of sale (with pos_discount installed) - Click on Action - Click on Discount - Write a discount percentage - Click OK - Validate POS An error appear because the negative price should be a printRecItemAdjustment with type 3 ### After this PR the right printRecitemAdjustiment is sent to printer
Users scrapping products from the Barcode app can now see and change the source location. This helps ensure inventory is removed from the correct shelf or child location, reducing stock accuracy issues.
Original PR description
**Problem:** When doing a scrap from the barcode app, the source location field is not accessible. The default source location of the scrap will be the one of the stock move, this could be a problem…
**Problem:** When doing a scrap from the barcode app, the source location field is not accessible. The default source location of the scrap will be the one of the stock move, this could be a problem if the product is located in a child location. For instance if confirming a sale order for product A (which is stored in WH/stock/Shelf 1), the pick generated by the sale order will be from WH/Stock to WH/Output (default pick values). In the barcode app, if doing a scrap from this picking, the source location will be WH/stock and the client will not be able to change that because the field does not appear. **Steps to reproduce:** - From the inventory app dashboard select "internal transfer" - Create a new internal transfer - Enter a storable product - Set a demand quantity - Click on "Mark as Todo" - Open the barcode app - Click on operations - Select "Internal Operations" - Select the transfer you just created - Click on the gear icon on the top right and select "scrap" **Current Behavior:** The source location field is not visible **Expected Behavior:** The source location field should be visible and editable **Cause of the issue:** The source location field is not in the view https://github.com/odoo/enterprise/blob/a9334bb551606d0151d8fc7a8f3393c3a6e312b9/stock_barcode/views/stock_scrap_views.xml#L68 **Fix:** I added the source location field in the view opw-4489401
Italian point-of-sale receipts with a 100% discount can now be completed even when the final amount is zero. This prevents fiscal printer blocking and supports valid checkout flows for fully discounted sales.
Original PR description
### Before this PR Try to do a receipt with a product, then a full discount of this product. You can't do a receipt with 0.0 as the amount because it is missing printRecTotal ### After this PR: You can do receipt with an amount of 0.0 This PR depends from odoo/enterprise#80951 (i can't create draft PR, but when that PR will be merged i will rebase)