Monday, December 22, 2025
7 changes · saas-18.4
New functionality added to Odoo
This update adds support for Guatemalan tax regulations, specifically related to Factura Especial (FESP) requirements. It includes new accounts and tax groups for withholding VAT and ISR taxes, ensuring accurate reporting for Guatemalan businesses using Odoo.
Original PR description
**PURPOSE** - In Guatemala, a Factura Especial (FESP) is a legal mechanism established in Art. 52 of the VAT Law. - To achieve this functionality, we need to create withholding taxes. **SPECIFICATION** - Added new accounts for VAT and ISR withholdings. - Added new tax groups for VAT and ISR. - Added new taxes with negative values in withholding. task-5026698 see - https://github.com/odoo/enterprise/pull/96007 Forward-Port-Of: odoo/odoo#229493
This update adds support for FESP (Factura Especial) invoices in Guatemala, a legal requirement for certain purchase registrations. It automatically handles the necessary data and tax withholdings, ensuring accurate accounting and compliance with SAT regulations. Users can now generate and submit FESP documents directly within Odoo.
Original PR description
### PURPOSE - In Guatemala, a Factura Especial (FESP) is a legal mechanism established in Art. 52 of the VAT Law. - Generate Factura Especial (FESP) when registering a purchase without a supplier…
### PURPOSE - In Guatemala, a Factura Especial (FESP) is a legal mechanism established in Art. 52 of the VAT Law. - Generate Factura Especial (FESP) when registering a purchase without a supplier invoice. - Include all required data: supplier as receiver, transaction details, and the retention complement (100% VAT + ISR withholding). - Ensure proper accounting: supplier payable = net after retentions, taxes withheld = recorded as liabilities to be paid to SAT. - Fulfill FEL technical requirements (DTE XML, mandatory phrase, retention complement, see example attached). ### SPECIFICATION - Added flow for FESP (Factura Especial) document type in vendor bills. - Automatically added Phrase Type 5, Scenario 1 (as required by SAT). - Enforced mandatory data by raising UserError if FESP is selected but no withholding taxes are set on the product lines. - Added complement generation for withheld taxes (IVA, ISR) with base, rate, and amounts. - Allow users to send a document to SAT in case of FESP. - Added required details in FEL XML for FESP. task-5026698 see - https://github.com/odoo/odoo/pull/229493 Forward-Port-Of: odoo/enterprise#96007
Resolved issues and error corrections
This update resolves an issue where portal users couldn't update lead data after a recent security change. The team implemented a temporary workaround using 'sudo()' to allow authorized portal users to modify leads, ensuring seamless data updates from the customer portal. This maintains consistent data across all channels.
Original PR description
## Steps to reproduce: - Install 'website_crm_partner_assign' module. - Create a partner X with a partner level. - Save and go to "Opportunities". - Create an new opportunity. - Edit it and set the…
## Steps to reproduce: - Install 'website_crm_partner_assign' module. - Create a partner X with a partner level. - Save and go to "Opportunities". - Create an new opportunity. - Edit it and set the partner X as the assigned partner - Grant the partner x portal access and change his password. - Logout then login with the partner X credentials. - Go to "My account" page and click on "Opportunities" - Select the opportunity Y and edit the revenue or another field. - Traceback on save. (Or no reaction, popup traceback from notification) ### Issue: Since the commit ed94e84, we've removed the write access for portal partner users to the leads to avoid unexpected behaviors. However, this is provoking `update_lead_portal` to not be able to update the lead anymore, since we will not have direct access to modify the lead. ### Solution: To fix this, we will follow same approach as in `update_contact_details_from_portal` and use `sudo()` to update the lead from the portal. We are already checking the portal access at the beginning of the method as `self._assert_portal_write_access()`, so we are sure that only authorized users will be able to update the lead. opw-2764563 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237599
This update corrects a previous issue where newly created serial numbers within the Barcode app were automatically assigned to the current company. This prevented proper use of serial numbers across different companies. Now, serial numbers are created without a company association, allowing for seamless intercompany tracking and aligning with existing inventory update methods.
Original PR description
## Context In the barcode app (`stock_barcode`), users can update inventory counts by scanning a product's barcode or by manually entering the barcode. ## Issue When the barcode is entered manually,…
## Context In the barcode app (`stock_barcode`), users can update inventory counts by scanning a product's barcode or by manually entering the barcode. ## Issue When the barcode is entered manually, the lot/serial number is created with the *Company* field set to the current company. This causes issues when working with intercompany flows, because lots with a company assigned cannot be used by other companies. This behavior is also inconsistent with the other ways of updating a company's inventory. In fact, the following flows create serial/lot numbers with no company assigned: - Inventory / Products / Products / *Forecasted Report* or *On Hand* - Inventory / Operations / Adjustments / Physical Inventory - Barcode / Inventory Count / Add product (add the serial number from the *Inventory Count* screen, **not** by clicking on the cogwheel in the top-right corner) ## Cause The line assigning a `company_id` was added by https://github.com/odoo/enterprise/commit/c0151bce3c60c69e7cadeb719a81c4a702b71c34. At the time, that behavior was consistent with the backend behavior, as the `company_id` of a lot/serial number would always be set to `self.env.company`. In fact, the feature allowing a lot/serial to be shared among multiple companies was introduced later, in saas-17.2 (https://github.com/odoo/odoo/commit/99b39b72c7e65e85af6f06dcb6b02867623f3f69). This last commit adds a compute method for the `stock.lot.company_id` field: https://github.com/odoo/odoo/blob/6026866900fd0ac1bf6495ae249cd08f56c85342/addons/stock/models/stock_lot.py#L130-L136 Since then, lot/serial numbers shouldn't be created with a `company_id`, as this restrict other companies to use those numbers. Users can always add a company to a lot/serial number later if necessary. ## Solution The line assigning a `company_id` to the `stock.lot` can be removed, as it does not reflect the current behavior (saas-17.2+). Nowadays, a `company_id` should be set **only** if the user wants a lot/serial number to be used by a specific company; it should not be the default behavior. ## Steps to reproduce 1. Install *Barcode* (`stock_barcode`). 2. In Inventory / Configuration / Settings, enable *Lots & Serial Numbers*. 3. In Settings / Users & Companies / Companies, create a second company. Use either company for the following steps. 4. Create a product tracked *By Unique Serial Number*. 5. Open the Barcode app, then click *Inventory Count*. 6. Scan your product (or add it manually, but **do not** set the *Serial/Lot Number*). 7. Scan "SN001" (or add it manually through the cogwheel menu), then click *Apply*. 8. Go to Inventory / Products / Lots / Serial Numbers. 9. The serial number created from the Barcode app is assigned to the current company. opw-5264216 Forward-Port-Of: odoo/enterprise#102130
This update ensures that only administrator users can override the maximum closing difference when closing a point-of-sale session. Previously, users connected to the backend could override this setting, leading to potential discrepancies. This change enhances data accuracy and control within the POS system.
Original PR description
Currently, the behavior of the "Maximum closing difference" feature with employees depends on the user connected in the backend and not the employee using the pos. Steps to reproduce:…
Currently, the behavior of the "Maximum closing difference" feature with employees depends on the user connected in the backend and not the employee using the pos. Steps to reproduce: ------------------- * Set max closing difference as 0 * Have 1 admin user and 1 pos user * Have 2 employees * Set admin user and employee 1 as advanced employees of the pos * Set pos user and employee 2 as basic employees Steps with admin: * Make sure you are logged as the admin in the database * Open pos (could be a session opened by other user) * Log in with Admin user * Try to close the pos with a difference of 10 -> You can, ok * Log in with employee 1 (advanced) * Try to close the pos with a difference of 10 -> You ca but shouldn't Steps with pos user * Now log in the database as pos user * Open pos (could be a session opened by other user * Log in with employee 1 (advanced) * Try to close the pos with a difference of 10 -> You cannot, ok * Log in with Admin user * Try to close the pos with a difference of 10 -> you cannot but should Why the fix: ------------ Employees that have no linked user should not ba able to override the max difference. Employees who have a connected user should only be able to override the max difference if their user is admin of the pos. opw-5184041 Forward-Port-Of: odoo/odoo#239770 Forward-Port-Of: odoo/odoo#235356
This update optimizes the way Odoo calculates stock quantities, specifically for databases with many products. By streamlining the computation process, the system now runs significantly faster – reducing processing time by over 40% when dealing with a large number of products. This improves overall system responsiveness and efficiency.
Original PR description
In databases with a large number of products, most of them will have 0 quantities on hand. This commit fast-tracks the computation of 0 qty products, skipping unnecessary `uom_id` and `float_round()` computations in _compute_quantities_dict and skipping unnecessary `__set_item__` in _compute_quantities. Benchmark | `product.product` count | Before this PR | After this PR | | ----------------------- | -------------- | ------------- | | 700,000 | 52.84s | 28.33s | opw-4930856 Forward-Port-Of: odoo/odoo#239918 Forward-Port-Of: odoo/odoo#239687
This update corrects an issue where multiple stock lines were incorrectly linked to the wrong picking during the 'put in pack' process for batch transfers. The fix ensures that each batch transfer results in a single line per picking, accurately reflecting the delivered quantity. This resolves a discrepancy in reported stock levels.
Original PR description
**Steps to reproduce:** - enable "packages" and "batch transfers" settings - open wharehouse management/operation type - select internal transfer - check "automatic batch" and group by "contact" -…
**Steps to reproduce:** - enable "packages" and "batch transfers" settings - open wharehouse management/operation type - select internal transfer - check "automatic batch" and group by "contact" - create two storable product with an on hand quantity of 10 - create a an internal transfer for the first product for a qty of 10 - mark it as to do - do the same for the second product and make sure that it's the same contact - open barcode and select batches - select the last batch created - scan WH-STOCK - enter and confirm a quantity of 4 for each line - click on put in pack (at this step we can already see that the two new lines created are associated wit the second picking, even though it should be one line per picking) - click on the +6 on each line and click on put in pack - validate **Current behavior:** - a back order has been created for the first picking - the first internal transfer has only delivered 4 units of the first product - the second internal transfer has delivered 10 of the second product and 5 of the first product **Expected behavior:** both pickings should have delivered 10 of their product **Cause of the issue:** The lines created when clicking on "put in pack" for the first time are both associated with the second picking because the line split: https://github.com/odoo/enterprise/blob/898e3e47cfe3b86230da2b146960983d7ad144d0/stock_barcode/static/src/models/barcode_picking_model.js#L514 and the picking_id of the new line is set to the values provided by the `_getNewLineDefaultValues` as the picking_id of the last selected `line`: https://github.com/odoo/enterprise/blob/24b4e49dbe16cb8bd40170abfc089dd64c3f34dd/stock_barcode_picking_batch/static/src/models/barcode_picking_batch_model.js#L280-L281 rather than from the values of the initial line it is split from. opw-4952964 Forward-Port-Of: odoo/enterprise#102508 Forward-Port-Of: odoo/enterprise#91378