Tuesday, December 24, 2024
10 changes · saas-17.2
Miscellaneous changes
Steps to reproduce: - Open Expenses. - Upload a sample expense pdf. The blue ribbon shows up saying “” - Do not click on the refresh button. Instead, put in some value for the amount and submit and approve the expense. - Go back to the expenses list view Issue: Notice this expense is at the top of the list and grayed out Cause: The order is determined by the extract_state_processed field: https://github.com/odoo/enterprise/blob/ba06e216ab73c73e3a67fd917623c6ad357b869f/hr_expense_ext
Original PR description
Steps to reproduce: - Open Expenses. - Upload a sample expense pdf. The blue ribbon shows up saying “” - Do not click on the refresh button. Instead, put in some value for the amount and submit and…
Steps to reproduce: - Open Expenses. - Upload a sample expense pdf. The blue ribbon shows up saying “” - Do not click on the refresh button. Instead, put in some value for the amount and submit and approve the expense. - Go back to the expenses list view Issue: Notice this expense is at the top of the list and grayed out Cause: The order is determined by the extract_state_processed field: https://github.com/odoo/enterprise/blob/ba06e216ab73c73e3a67fd917623c6ad357b869f/hr_expense_extract/models/hr_expense.py#L21 An expense is muted when this field is set to `True`: https://github.com/odoo/enterprise/blob/1df090289f3c45c200d133734989a6d9a8073145/hr_recruitment_extract/views/hr_applicant_views.xml#L67 Solution: We override `iap_extract` method https://github.com/odoo/enterprise/blob/2e3113562309bf4d440e12ab09eaf94d0b302f1f/iap_extract/models/extract_mixin.py#L69 If the expense is not in draft, it indicates that the process continued without waiting for the extraction process to complete (values were manually entered). To ensure a consistent extraction state, we extend the "Check OCR Status" logic to prevent an infinite waiting_extraction status. opw-4239404 Forward-Port-Of: odoo/enterprise#75202
## Issue: - Uploading a Mexican XML file with an 8% tax results in the addition of an extra 8% tax. ## Steps to reproduce: - Create a new invoice and add a line with an 8% tax. - Validate the invoice and export it as XML. - Upload the XML file as a vendor bill. - The vendor bill incorrectly shows two "8% taxes" instead of one. ## Solution: - The issue stems from a forward-port error from `saas-16.4` https://github.com/odoo/enterprise/commit/5681a8d5abee3a8787f3ee8612a8c3b18ed63ee6 to
Original PR description
## Issue: - Uploading a Mexican XML file with an 8% tax results in the addition of an extra 8% tax. ## Steps to reproduce: - Create a new invoice and add a line with an 8% tax. - Validate the invoice…
## Issue: - Uploading a Mexican XML file with an 8% tax results in the addition of an extra 8% tax. ## Steps to reproduce: - Create a new invoice and add a line with an 8% tax. - Validate the invoice and export it as XML. - Upload the XML file as a vendor bill. - The vendor bill incorrectly shows two "8% taxes" instead of one. ## Solution: - The issue stems from a forward-port error from `saas-16.4` https://github.com/odoo/enterprise/commit/5681a8d5abee3a8787f3ee8612a8c3b18ed63ee6 to `17.0` https://github.com/odoo/enterprise/commit/56a2b66d84d8398ea870d559cd55cfeae44019d8 - In `17.0` we introduced this Extract method `_l10n_mx_edi_import_cfdi_get_tax_from_node` to refactor the `_l10n_mx_edi_import_cfdi_fill_invoice_line`. - We should have add the Exento checks in the new method however we mistakenly pushed code from `saas-16.4` to `17.0` without adapting it. - I removed the extra code introduced during the forward-porting. - Refactored the related code to ensure compatibility with the new changes in `17.0`. OPW-4198016 Forward-Port-Of: odoo/enterprise#74602
Before this commit, when the content of the expense is updated by OCR, the author might not be "OdooBot". This happened because while filling the document with results (in hr_expense._predict_product) there is a savepoint that removes the author. This commit sets the OCR note author after filling the document with results, which makes sure that the correct author (i.e., OdooBot) is always set. Moreover, if the expense receipt has a dot in its name, the _predict_product was never visited.
Original PR description
Before this commit, when the content of the expense is updated by OCR, the author might not be "OdooBot". This happened because while filling the document with results (in hr_expense._predict_product) there is a savepoint that removes the author. This commit sets the OCR note author after filling the document with results, which makes sure that the correct author (i.e., OdooBot) is always set. Moreover, if the expense receipt has a dot in its name, the _predict_product was never visited. So, the attachment name extraction is fixed to make sure that only file extension was removed. This commit also adds unit tests to expense and invoice OCR extract to make sure that their notes are authored by OdooBot. The test was not introduced in hr.applicant, however, since OCR does not change any tracked fields (i.e., OCR never logs a note on the chatter). task-4197413 Forward-Port-Of: odoo/enterprise#75756
Export from `account_batch_payment` to CBI's RIBA text file format, so that the customer can upload its requests for payment (bank receipts) to the bank. - New field: `l10n_it_sia_code`: Interbancary identifier given by SIA when signing a CBI contract to start doing Ri.Ba.s - New payment method: `RIBA` - Added the methods to read and write the Ri.Ba. text format, i.e. we are able to read an `example` created with FattureInCloud. - Implemented the flow by taking the data from payments and
Original PR description
Export from `account_batch_payment` to CBI's RIBA text file format, so that the customer can upload its requests for payment (bank receipts) to the bank. - New field: `l10n_it_sia_code`: Interbancary identifier given by SIA when signing a CBI contract to start doing Ri.Ba.s - New payment method: `RIBA` - Added the methods to read and write the Ri.Ba. text format, i.e. we are able to read an `example` created with FattureInCloud. - Implemented the flow by taking the data from payments and calling the export functions. - Built a test - Made some demo data - Added translation strings - Riba sequence number, it's created on export and persisted on the batch payment at the moment, so if you re-export, it won't change. It's not shown to the user though. Do we want that to be shown? Editable? Task [link](https://www.odoo.com/odoo/project/967/tasks/4254966) task-4254966 Forward-Port-Of: odoo/enterprise#76051 Forward-Port-Of: odoo/enterprise#74097
Steps to reproduce the bug: - Enable “Subcontracting” and “Expiration Date” in MRP settings. - Create a storable product “P1” with the following configurations: - tracked by: LOT - Expiration date: True - BoM: - BoM type: subcontracting - subcontractor: Azure interior - Create a lot “L1” with an expiration date set to 01-01-2026. - Expiration date: 01-01-2026 - Configure the operation type:: - Receipt: - use existing SN: True - Crea
Original PR description
Steps to reproduce the bug: - Enable “Subcontracting” and “Expiration Date” in MRP settings. - Create a storable product “P1” with the following configurations: - tracked by: LOT - Expiration date:…
Steps to reproduce the bug:
- Enable “Subcontracting” and “Expiration Date” in MRP settings.
- Create a storable product “P1” with the following configurations:
- tracked by: LOT
- Expiration date: True
- BoM:
- BoM type: subcontracting
- subcontractor: Azure interior
- Create a lot “L1” with an expiration date set to 01-01-2026.
- Expiration date: 01-01-2026
- Configure the operation type::
- Receipt:
- use existing SN: True
- Create a receipt:
- Receive from: Azure interior
- Product: one unit of P1
- Mark it as todo
- Open the detailed operation:
- Set the “L1”
- Record production
- Reopen the detailed operation
Problem:
The expiration date in the stock.move.line is set to today’s date instead of the lot’s expiration date.
Cause:
When marking the receipt as “To Do,” the SML is created. Since no lot_id is initially set, today’s date is assigned, thanks to the _compute_expiration_date method:
https://github.com/odoo/odoo/blob/9f1d555ac2d9b6e9d3d0d723d4f042eb44cf30b7/addons/product_expiry/models/stock_move_line.py#L37-L40
But When the lot_id is later set, the compute method is triggered again. However, since the SML already contains a date, the expiration date is not updated to match the lot’s expiration date.
opw-4394662
Forward-Port-Of: odoo/odoo#190747For an expense report paid by an employee, the bank account set on the employee form should be used to create the Journal Entry and as a default bank account in Register Payment Wizard. task-4379148 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191416 Forward-Port-Of: odoo/odoo#189967
Original PR description
For an expense report paid by an employee, the bank account set on the employee form should be used to create the Journal Entry and as a default bank account in Register Payment Wizard. task-4379148 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191416 Forward-Port-Of: odoo/odoo#189967
Tax included in price were not taken into account when using a loyalty program applying on the cheapest product. Steps to reproduce: ------------------- * Create a loyalty program that apply 10% reward on cheapest product * Create a product A that has 10% tax included in price * Open PoS and add this product to the order (make sure this is the cheapest in the order) > Observation: The discount is not taking the tax into account opw-4243827 Forward-Port-Of: odoo/odoo#189612
Original PR description
Tax included in price were not taken into account when using a loyalty program applying on the cheapest product. Steps to reproduce: ------------------- * Create a loyalty program that apply 10% reward on cheapest product * Create a product A that has 10% tax included in price * Open PoS and add this product to the order (make sure this is the cheapest in the order) > Observation: The discount is not taking the tax into account opw-4243827 Forward-Port-Of: odoo/odoo#189612
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 Forward-Port-Of: odoo/odoo#191594
Original PR description
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 Forward-Port-Of: odoo/odoo#191594
Backport commit 454f861 by @svs-odoo. Versions affected: - 16.0 - 17.0 Before this commit, the `product.template` constrains `_check_sale_product_company` didn't work if the recordset contains products from different companies, causing a traceback. How to reproduce: - Create multiple products at once in different companies. For example, in the shell of a newly created DB: - company_b, company_a = self.env["res.company"].search([]) - products = self.env["product.product"].create([ {'n
Original PR description
Backport commit 454f861 by @svs-odoo.
Versions affected:
- 16.0
- 17.0
Before this commit, the `product.template` constrains `_check_sale_product_company` didn't work if the recordset contains products from different companies, causing a traceback.
How to reproduce:
- Create multiple products at once in different companies. For example, in the shell of a newly created DB: - company_b, company_a = self.env["res.company"].search([]) - products = self.env["product.product"].create([ {'name': "prod1", 'company_id': company_a.id}, {'name': "prod2", 'company_id': company_b.id}]) -> Traceback.
To fix this issue, this commit groups products by their company in `_check_sale_product_company`.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#191553
Forward-Port-Of: odoo/odoo#191522Issue: In the task action view of the sale order, the task ID is passed in the action domain, which results in showing only old tasks. Newly created tasks are not visible because their IDs are not included in the domain. Solution: Instead of passing task ids, we now check for project_id, sale_order_id, or sale_line_id to ensure the new tasks are properly displayed. Steps to Reproduce: - Install the sale_project module. - Create a Sale Order (SO). - Add a product con
Original PR description
Issue: In the task action view of the sale order, the task ID is passed in the action domain, which results in showing only old tasks. Newly created tasks are not visible because their IDs are not included in the domain. Solution: Instead of passing task ids, we now check for project_id, sale_order_id, or sale_line_id to ensure the new tasks are properly displayed. Steps to Reproduce: - Install the sale_project module. - Create a Sale Order (SO). - Add a product configured to create a project with tasks. - Click on the "Tasks" smart button from the SO. - Go to the Kanban view. - Create a new task and give a name. - Reload the page. - Check if the task is visible (the issue was that new tasks were not visible). Affected PR: https://github.com/odoo/odoo/pull/135771/files task-4224564 Forward-Port-Of: odoo/odoo#191586 Forward-Port-Of: odoo/odoo#184879