Monday, April 14, 2025
8 changes · saas-17.4
Miscellaneous changes
The demo product 'Drawer' was initially configured to be tracked by quantity, but a lot was incorrectly created, and the stock quant was subsequently created for the 'Drawer' with lot. Steps to reproduce =============== - Install the 'stock' module with demo data. - Navigate to Inventory > Products > Products and search for 'Drawer'. - Observe that 'Drawer' is set to track by quantity (Tracking field). - Check Inventory > Operations > Physical Inventory and locate the stock quant
Original PR description
The demo product 'Drawer' was initially configured to be tracked by quantity, but a lot was incorrectly created, and the stock quant was subsequently created for the 'Drawer' with lot. Steps to reproduce =============== - Install the 'stock' module with demo data. - Navigate to Inventory > Products > Products and search for 'Drawer'. - Observe that 'Drawer' is set to track by quantity (Tracking field). - Check Inventory > Operations > Physical Inventory and locate the stock quant for 'Drawer'. - Note that a lot exists and is linked to the product 'Drawer', despite the quantity tracking setting. This commit modifies the demo data to enable lot tracking for the product, aligning its configuration with the existing lot and stock quant data for consistency. Forward-Port-Of: odoo/odoo#204803
There has been a recent change to the specs where they changed the endpoint to send B2C invoices: `uploadb2c`. So now, - if an invoice is made to a commercial partner that is of type company, we keep sending it to the old endpoint (no change); - if it is made to a non-company customer, then we send to the new endpoint. task-4645442 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203743
Original PR description
There has been a recent change to the specs where they changed the endpoint to send B2C invoices: `uploadb2c`. So now, - if an invoice is made to a commercial partner that is of type company, we keep sending it to the old endpoint (no change); - if it is made to a non-company customer, then we send to the new endpoint. task-4645442 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203743
Description of the issue/feature this PR addresses: If we try to reload the template, an error is raised. So, we will raise the error if the change has some meaning Current behavior before PR: an Error is raised when updating a German plan Desired behavior after PR is merged: no Error is raised @alialfie --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205480
Original PR description
Description of the issue/feature this PR addresses: If we try to reload the template, an error is raised. So, we will raise the error if the change has some meaning Current behavior before PR: an Error is raised when updating a German plan Desired behavior after PR is merged: no Error is raised @alialfie --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205480
Currently, an error may occur when we try to export the trial balance with the SAT (XML) format. This is because a None id is used to browse the account, due to a more specific account_group. Steps to reproduce: - Install l10n_mx_reports. - Create an account_group with a more specific account, such as 401.01.01 - The 4, 401, and 401.01 groups are created with demo data. - Go to trial balance and try exporting with "SAT (XML)". An error will occur (`AttributeError: 'bool' object has
Original PR description
Currently, an error may occur when we try to export the trial balance with the SAT (XML) format. This is because a None id is used to browse the account, due to a more specific account_group.
Steps to reproduce:
- Install l10n_mx_reports.
- Create an account_group with a more specific account, such as 401.01.01
- The 4, 401, and 401.01 groups are created with demo data.
- Go to trial balance and try exporting with "SAT (XML)".
An error will occur (`AttributeError: 'bool' object has no attribute 'startswith'`) because the account is None, so account have no type.
opw-4716047
Forward-Port-Of: odoo/enterprise#83370
Forward-Port-Of: odoo/enterprise#83197### Steps to reproduce: - In the settings enable by products. - Create two products FP and SN where SN is tracked by serial numbers - Create and confirm an MO for FP where SN is a by product - Open the shopfloor > Register By-Product > generate serial numbers > input SN0012 > Generate > Save #### > your input was not taken into account, not lot was created. ### Cause of the issue: Clicking on `Register By-Product` and generate serial numbers will open the `stock.generate_serial_d
Original PR description
### Steps to reproduce: - In the settings enable by products. - Create two products FP and SN where SN is tracked by serial numbers - Create and confirm an MO for FP where SN is a by product - Open…
### Steps to reproduce: - In the settings enable by products. - Create two products FP and SN where SN is tracked by serial numbers - Create and confirm an MO for FP where SN is a by product - Open the shopfloor > Register By-Product > generate serial numbers > input SN0012 > Generate > Save #### > your input was not taken into account, not lot was created. ### Cause of the issue: Clicking on `Register By-Product` and generate serial numbers will open the `stock.generate_serial_dialog`. Clicking on Generate will then call the `_onGenerate` method and an rpc call of the `action_generate_lot_line_vals` will be made: https://github.com/odoo/odoo/blob/a0542b13f679d4dc20d61eb62e4eb5106d6abe5a/addons/stock/static/src/widgets/lots_dialog.xml#L12 https://github.com/odoo/odoo/blob/a0542b13f679d4dc20d61eb62e4eb5106d6abe5a/addons/stock/static/src/widgets/generate_serial.js#L34 However, if you triggered these actions from the shopfloor, you never provided a `default_picking_type_id` in the context so that the lot will never be created by any mean: https://github.com/odoo/odoo/blob/a0542b13f679d4dc20d61eb62e4eb5106d6abe5a/addons/stock/models/stock_move.py#L919-L927 https://github.com/odoo/odoo/blob/a0542b13f679d4dc20d61eb62e4eb5106d6abe5a/addons/stock/models/stock_move.py#L945-L948 opw-4544734 Forward-Port-Of: odoo/enterprise#82355
STEPS ------------ 0. You'll require IAP credit for PDF extraction 1. Create 1 POs (we'll call it PO-1) and set the vendor as the current company 2. Duplicate PO-1 (we'll call the duplicate PO-2) and change the amount value of one product 3. Create an invoice with the extact same values as PO-2 and set the customer reference (in the 'Other Info' tab) to "PO-2"; we'll call it INV-1 4. Create a bill and use the Auto-Complete field to manually select PO-1 5. Drag and drop INV-1 in the chatte
Original PR description
STEPS ------------ 0. You'll require IAP credit for PDF extraction 1. Create 1 POs (we'll call it PO-1) and set the vendor as the current company 2. Duplicate PO-1 (we'll call the duplicate PO-2) and change the amount value of one product 3. Create an invoice with the extact same values as PO-2 and set the customer reference (in the 'Other Info' tab) to "PO-2"; we'll call it INV-1 4. Create a bill and use the Auto-Complete field to manually select PO-1 5. Drag and drop INV-1 in the chatter -> IAP should trigger -> The chatter says ''' The invoice already contains lines, it was not updated from the attachment. ''' but yet, it updated the purchase reference to PO-2 and updated the lines OBJECTIVE ------------ If a bill has lines, it should not be updated with the content of the PO. task-4633298 Forward-Port-Of: odoo/enterprise#83246
Commits fc49984a and 2644a63b introduced changes to: - Prevent rejections for invoices older than 72 hours (error 301). - Use the correct partner/branch timezone when generating the CFDI. However, these changes also cause each re-stamping attempt to use the current timestamp, resulting in duplicates on the SAT if the first attempt times out or is lost (e.g., due to a disconnection). The PAC sees each request as a distinct CFDI if there is even a slight difference in the timestamp. This f
Original PR description
Commits fc49984a and 2644a63b introduced changes to: - Prevent rejections for invoices older than 72 hours (error 301). - Use the correct partner/branch timezone when generating the CFDI. However,…
Commits fc49984a and 2644a63b introduced changes to:
- Prevent rejections for invoices older than 72 hours (error 301).
- Use the correct partner/branch timezone when generating the CFDI.
However, these changes also cause each re-stamping attempt to use the current timestamp, resulting in duplicates on the SAT if the first attempt times out or is lost (e.g., due to a disconnection). The PAC sees each request as a distinct CFDI if there is even a slight difference in the timestamp.
This fix ensures that the same emission timestamp (stored in `l10n_mx_edi_post_time`) is reused for subsequent stamping attempts, producing an identical XML and preventing duplicates on the SAT.
Steps to reproduce the original issue:
1. Create and confirm an invoice.
2. Stamp the invoice.
3. Manually set the EDI status to “to_send”: ```python record.edi_document_ids.write({"state": "to_send"}) ```
4. Stamp again without persisting the emission timestamp => a new CFDI is generated.
Expected result after the fix:
- The system reuses the same emission timestamp (l10n_mx_edi_post_time) for each attempt, preventing duplicate CFDIs on the SAT.
According to the [SAT
documentation](http://omawww.sat.gob.mx/tramitesyservicios/Paginas/documentos/Anexo_20_Guia_de_llenado_CFDI.pdf)
the attribute `Fecha` must be the expedition date.
Forward-Port-Of: odoo/enterprise#83234
Forward-Port-Of: odoo/enterprise#81882Before this commit, the `/iot/get_handlers` endpoint was using the `text/html` mime type, even though it was sending a binary zip response. This was mostly harmless, however it could potentially cause issues if there was some service between the IoT box and DB that assumed it was safe to modify the "text" response in some way. opw-4718821 Forward-Port-Of: odoo/enterprise#83315
Original PR description
Before this commit, the `/iot/get_handlers` endpoint was using the `text/html` mime type, even though it was sending a binary zip response. This was mostly harmless, however it could potentially cause issues if there was some service between the IoT box and DB that assumed it was safe to modify the "text" response in some way. opw-4718821 Forward-Port-Of: odoo/enterprise#83315