Tuesday, December 23, 2025
8 changes · saas-18.3
Resolved issues and error corrections
This update fixes an issue where manually adjusted prices on customer invoices were being reset when the invoice's fiscal position was changed. The fix ensures that prices remain as the user intended, mirroring the behavior of Sale Orders. This improves accuracy and reduces manual intervention for users.
Original PR description
**Steps to reproduce:** * Install the **Accounting** module. * Create a customer invoice with at least one product line. * Manually adjust the **price_unit** on the invoice line. * Change the fiscal position on the invoice. * Click the **Update Taxes and Accounts** button. **Observed behavior:** * The manually adjusted price is reset to the product’s default sales price (e.g., 1000). * This occurs even though neither the product nor the UoM changed. * In contrast, **Sale Orders correctly preserve** manually edited prices in the same situation. **Cause:** * `action_update_fpos_values` method call the recomputation of unit price each time when we click update taxes and accounts button on invoice. **Fix:** * Add a condition to **skip price recomputation** when fiscal position changes. * This preserves manual prices when only the fiscal position changes. opw-5252832 Forward-Port-Of: odoo/odoo#240813 Forward-Port-Of: odoo/odoo#237914
This update allows businesses using the Mexican tax reporting (MX) module to define a custom sequence prefix for GI CFDI invoices issued on branch offices. Previously, the system always used the root company's sequence, which is now configurable to ensure accurate tax reporting for branch operations. This change improves compliance and reduces potential errors related to invoice numbering.
Original PR description
Add a way to set a custom prefix for GI sequences on the settings for MX. Get this sequence first on the branch before looking to the one on root company. opw-5096687 Forward-Port-Of: odoo/enterprise#100017
This update fixes an issue where invoice due dates were incorrectly calculated when users had their timezones set to UTC. The change removes a timezone conversion step, ensuring due dates are accurately displayed based on the user's local time. This prevents discrepancies and ensures invoices are presented with the correct payment deadlines.
Original PR description
This commit fixes the incorrect due date calculation of invoices. If user timezone is set to any UTC-* timezone, then the due date is calculated as the previous day to the actual due date. This is because the function `deserializeDateTime` was used, which considers the input date as UTC timezone and converts it to system timezone. For example, if the due date is "2025-11-20 00:00:00" and the system timezone is UTC-3, then the calculated due date is "2025-11-19 21:00:00". So when getting the difference from today's date (assuming today is "2025-11-20"), the difference is 1 day (which is not the expected value). This commit replaces the call of `deserializeDateTime` with `deserializeDate`, which removes the system timezone conversion. opw-5160764 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240785 Forward-Port-Of: odoo/odoo#236769
This update resolves critical issues preventing incorrect credit note submissions to the Kenya Revenue Authority (KRA). Specifically, the system now validates that credit notes match the original invoice's customer PIN and that the credit note date is not before the invoice date, ensuring accurate tax reporting.
Original PR description
* Prevent credit note with customer PIN different than the submitted invoice. * Prevent credit note to be dated before the original invoice date. task-5160113 Forward-Port-Of: odoo/enterprise#102475 Forward-Port-Of: odoo/enterprise#100480
This update resolves a validation error that occurred when starting work orders with flexible resources, particularly when the time was set to a late part of the day. The fix ensures that attendance intervals are correctly aligned, preventing the 'start date' from being after the 'end date' and improving the accuracy of time tracking for flexible workers.
Original PR description
**Steps to reproduce** On a local DB, with demo data: - Change your machine's time to a late part of the day (e.g. 6pm) - Install `mrp_workorder` - Set the "Standard 40 hours/week" (used by a…
**Steps to reproduce** On a local DB, with demo data: - Change your machine's time to a late part of the day (e.g. 6pm) - Install `mrp_workorder` - Set the "Standard 40 hours/week" (used by a workcenter) as flexible. - From the Shop Floor, start the "WH/MO/00003 - Manual Assembly" workorder. "Validation Error: The start date of the time off must be earlier than the end date." **Cause** `_calculate_date_finished` in mrp is calling `plan_hours` and under certain conditions with a flexible resource, it is possible for `plan_hours` to return a datetime before the `day_dt` parameter. This happens because for flexible resources, `_attendance_intervals_batch` can return attendance intervals with start or end datetimes outside of the start_dt -> end_dt window. For example, a flexible calendar with 8h/day will return the 8:00->16:00 interval, even if start_dt is later than 8:00. **Change** Don't return attendance intervals outside of the [start_dt, end_dt] interval by shifting them if necessary. opw-5123230 Forward-Port-Of: odoo/odoo#233169
This update fixes an issue where multiple loyalty programs on a single order weren't always applied correctly. The fix uses a locking mechanism to ensure only one update process runs at a time, guaranteeing all loyalty discounts are applied consistently. This improves the accuracy of POS order calculations.
Original PR description
When adding a lot of loyalty programs with discounts to an order the updatePrograms method could be called multiple times in parallel, that would cause an issue where some of the programs were not…
When adding a lot of loyalty programs with discounts to an order the updatePrograms method could be called multiple times in parallel, that would cause an issue where some of the programs were not applied correctly. Steps to reproduce: ------------------- * Create 7 loyalty programs that apply on the same product, each with a discount reward of 10%. (Give them different name) * Create a POS order with 1 unit of that product. > Observation: Only the 6 first programs are applied. Why the fix: ------------ The issue is happening because the updatePrograms is called multiple times in parallel, and when coming to this block of code : https://github.com/odoo/odoo/blob/f3e74f9b840efef7c567ba31acd6ac61c79b5d6d/addons/pos_loyalty/static/src/overrides/models/pos_store.js#L182-L188 The last program has 2 coupons in the `couponPointChanges`, so it will proceed to delete all the coupons of the concerned program. To avoid this we use a mutex to ensure that only one call to updatePrograms is happening at a time. opw-4974788 Forward-Port-Of: odoo/odoo#240639 Forward-Port-Of: odoo/odoo#239662
This update fixes an issue where the total price in Point of Sale orders was incorrect when using products tracked by 'LOT' with groupable UoMs. The fix ensures that the price unit is consistently applied to the converted quantity, accurately calculating the order total. This improves the reliability of sales transactions.
Original PR description
Steps to reproduce ------------------ 1. Make a product tracked by 'LOT' and having a groupable in pos UoM 2. Make a SO with that product, choosing another UoM from the same category (if we chose Kg in first step, choose gram here, etc) 3. Settle the order in PoS. We observe that the order's total amount is totally off, we explain why below. Why it's happening ------------------ The `lot_remaining_quantity` is quantity after converting to the original UoM (that of step 1, not that of step 2). We are using that quantity for lines having products tracked by 'LOT' and a groupable UoM; however, we are keeping price unit as if we are using the quantity before conversion, i.e. the quantity in the UoM of step 2. That creates a mismatch between the UoM and thus we miscalculte the total price. The fix ------- When using the converted quantity, also use the converted price unit. opw-5144326 Forward-Port-Of: odoo/odoo#240956 Forward-Port-Of: odoo/odoo#239858
This update fixes a critical bug that caused Odoo to crash when sending invoices via Peppol with invoice lines lacking a product name. Now, the system gracefully displays an error message, guiding users to ensure each invoice line has a product or label before sending. This improves invoice processing reliability and prevents data loss.
Original PR description
Before this commit: When sending an invoice via Peppol with an invoice line that has no product name, the system crashes with a TypeError instead of showing a error message. Steps to reproduce: 1. Go to Accounting 2. Navigate to Customers > Invoices 3. Create a new invoice 4. Add an invoice line without entering a product name 5. Click 'Send' 6. Select 'by Peppol (Demo)' 7. Click 'Send' -> TypeError: 'NoneType' object is not subscriptable After this commit: System validates that the product name exists before accessing its text content. Users see a clear, error message: `Each invoice line should have a product or a label.` task-5432061 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240908