Tuesday, June 16, 2026
10 changes · saas-18.4
Resolved issues and error corrections
Polish electronic invoices now keep more decimal places for unit prices, preventing mismatches between unit price, quantity, and line totals. This makes exported KSeF invoice XMLs clearer and more consistent, even though the previous files were technically accepted.
Original PR description
**STEP TO REPRODUCE** 1. Create an invoice with a unit price of 10.005 and qty of 2. 2. Send the invoice to ksef. 3. Open the xml and notice P_9A (unit price) is 10.00 and P_11 (total without tax) is 20.01 Which is inconsistent (10.00 * 2 =/= 20.01). This PR increase the decimal places of P_9A to 8 digits which is the maximum allowed by the FA(3) format. Note that Ksef doesn't verify the untaxed unit price * quantity = total without tax, so the invoice we send are technically valid. However, it's best to generate invoice where the numbers add-up. opw-6203896 Forward-Port-Of: odoo/odoo#263812
Point of Sale receipts now show customer change as a positive amount when the customer pays more than the order total. This avoids confusing or misleading printed receipts and helps customers clearly understand the cash returned.
Original PR description
**Issue:** The printed receipt in Point of Sale displayed a negative change amount when the customer paid more than the order total. **Before:** The receipt showed the change as a negative value…
**Issue:** The printed receipt in Point of Sale displayed a negative change amount when the customer paid more than the order total. **Before:** The receipt showed the change as a negative value (e.g., `-$5,504.00`), which was misleading for customers. **After:** The receipt now correctly displays the change as a positive value (e.g., `$5,504.00`). **Steps to Reproduce:** 1. Open a Point of Sale session 2. Add products to the cart (example total: `$49,496.00`) 3. Select the **Cash** payment method 4. Enter an amount greater than the order total (example: `$55,000.00`) 5. Observe that the **Change** field displays a negative value 6. Confirm the payment 7. Print the receipt and observe that the change amount is also negative **Root Cause:** The issue was caused by an unnecessary negation in the `export_for_printing()` method in `pos_order.js`. The `get_change()` method already returns the correct positive change amount. However, the code applied an extra negation (`-this.get_change()`), which converted the value into a negative amount before rendering it on the receipt. **Fix:** Removed the unnecessary negation in `export_for_printing()` so the receipt now displays the correct positive change amount. Video reproducing the issue: [[Click here to view the video](https://drive.google.com/file/d/1QnQ47qlTFvv98K0J_NzreBVeIh-J2XcF/view?usp=sharing)] opw-6211988 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#269966 Forward-Port-Of: odoo/odoo#264681
This fixes a crash that could occur when the website editor compares an empty history entry. Users can now review history differences more reliably without encountering an unexpected error.
Original PR description
If, for whatever reason, the history we try to compare is an empty string, we might get a value error thrown. We guard the code to avoid the error. see :https://github.com/odoo/odoo/issues/269149 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#269722
The shop page editor's Fill setting now correctly changes product thumbnail display between cropped and contained views. This ensures website editors see the expected visual result when adjusting product card images.
Original PR description
**Problem:** On the /shop page, the "Fill" option in the web editor (cover/contain toggle on product card images) appears clickable but has no visible effect on the product thumbnails. **Steps to…
**Problem:**
On the /shop page, the "Fill" option in the web editor (cover/contain toggle on product card images) appears clickable but has no visible effect on the product thumbnails.
**Steps to reproduce:**
1. Install website_sale and open /shop.
2. Open the web editor and select the shop page.
3. Locate the "Fill" button group in the right panel (with the two svg icons).
4. Click the alternate option to switch between cover and contain.
5. Observe that the product card thumbnails do not change appearance.
**Current behavior:**
The toggle flips the `o_wsale_context_thumb_cover` class on the products table (and the activation of the `products_thumb_cover` view), but the product images keep rendering with `object-fit: contain` regardless of the toggle state.
**Expected behavior:**
The image fill mode follows the toggle:
- "cover" option active → product image uses `object-fit: cover`
- "cover" option inactive → product image uses `object-fit: contain`
**Cause of the issue:**
The product image template renders the img with the `object-fit-contain` utility class, and the local SCSS rule declares
`.object-fit-contain { object-fit: contain !important; }`. The CSS variable `--o-wsale-card-thumb-fill-mode` (set to `cover` by `.o_wsale_context_thumb_cover`) does cascade down to the img, but the non-variable, `!important` rule on the utility class always wins, so the variable-driven rule
`object-fit: var(--o-wsale-card-thumb-fill-mode, contain)` is silently overridden and the toggle becomes inert.
**Fix:**
Making the `.object-fit-contain` rule read the same CSS variable lets the existing toggle mechanism take effect without changing any template or removing the utility class. Outside the `.o_wsale_context_thumb_cover` context the variable is undefined, so the `var(..., contain)` fallback preserves the prior `contain` behavior for any other consumer of the class. This keeps the change to a single SCSS line, with no XML touched and no other CSS class semantics altered.
opw-6231432
Forward-Port-Of: odoo/odoo#268302
Forward-Port-Of: odoo/odoo#266717Product images in the self-order flow now keep their proper proportions instead of appearing stretched or distorted. This improves the ordering experience by making menu items easier to recognize across cart, product, combo, and list pages.
Original PR description
In this commit: ------------------- - Applied `object-fit: scale` to ensure product images are fully visible and properly displayed without distortion. task: [6260046](https://www.odoo.com/odoo/project.task/6260046)
The Luxembourg accounting setup now uses the correct inventory asset account for stock valuation instead of an expense account. This helps companies using Luxembourg localization keep automatic stock accounting aligned with expected financial reporting.
Original PR description
**Problem:** Valuation account for luxembourg is currently 60761 Merchandise which is incorrect because it's an expense account. We should rather use a current asset account like 301 Inventories of raw materials **Steps to reproduce on a fresh db:** - create a new db with modules stock_account and accountant (without demo data) - On the 'fiscal localization setting' set the package as 'Luxembourg' and save - ativate the automatic accounting setting **Current Behavior:** The 'stock valuation account' appearing below the automatic accounting setting is : 60761 Merchandise **Expected behaviour:** It should be 301 Inventories of raw materials Forward-Port-Of: odoo/odoo#269469
This fix prevents Jordanian e-invoices from failing when an invoice includes a line with zero quantity. Businesses can now send these invoices through JoFotara without seeing a divide-by-zero error popup.
Original PR description
Steps to reproduce: - Ensure Jordanian e-invoicing is installed - Create an invoice where one of the lines has a 0 quantitiy - Send the e-invoice JoFotara (Jordan EDI) Current Behavior: You will get a divide by 0 error popup Expected Behavior: No error and the invoice is sent opw-6262469 Forward-Port-Of: odoo/odoo#269382 Forward-Port-Of: odoo/odoo#269341
French PDP e-invoicing now checks the main company record when an invoice is sent to an invoice-specific contact. This prevents valid invoices from being blocked because the contact address itself does not store the required Peppol identifiers.
Original PR description
…cial partner **STEP TO REPRODUCE** 1. Install l10n_fr_pdp. 2. On the demo FR company contact, create a new contact of type invoice address. 3. Create an invoice with this new contact, and try send the invoice. 4. The pdp invoice constraints checking for pdp identifiers fails. **CAUSE** We use the partner to retrieve the peppol_eas and peppol_endpoint field values, but for subcontact, those field are empty. We should use the commercial_partner_id which correspond to the company we try to invoice instead. opw-6235830 Forward-Port-Of: odoo/odoo#270014
This fix makes the French PDP registration process use the company record for connection URL handling instead of a temporary registration record. This reduces the risk of setup problems if temporary registration data is removed and makes the process more stable for businesses using French e-invoicing services.
Original PR description
The aim of this commit is to move _get_iap_url on res.company model instead of pdp.regitration. This move is made for 2 reasons: 1. PDP registration is a transient model which means that the object could be deleted in the time. 2. PDP registration implementation was using the model (api.model) and the record (self.edi_mode) which is a bad implementation. So by moving this function on company, we ensure that we always have a record to call the function and then the function is no longer an api.model. no task id --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#270345
Miscellaneous changes
No description available.