Thursday, October 31, 2024
7 changes · 17.0
Enhancements to existing features
This update enhances the depreciation board by visually distinguishing cancelled depreciation entries in grey. Additionally, users can now properly dispose of assets through hashed journals, resolving a previous error that prevented disposal. This improves asset management workflows.
Original PR description
This commit makes cancelled depreciation entries appear in grey in the depreciation board. It also turns the the depreciation entry's name into a link towards the move's form view.
The system now automatically selects the correct document type (e-Factura or e-Ticket) based on the partner's identification type in Uruguay. When a partner has a RUT/RUC identification, the system defaults to e-Factura, which is the correct choice in 95% of cases. This reduces manual adjustments while still allowing users to override the selection when needed.
Original PR description
Description of the Issue/Feature Addressed by This PR: The current system sets the default document type to e-Ticket, regardless of the partner's identification type. However, for usability purposes, if the identification type is RUT/RUC, the document type should default to e-Factura, as this is the correct choice in 95% of cases. Current Behavior Before PR: The default document type is always set to e-Ticket, irrespective of the identification type. Desired Behavior After PR: The system will automatically select the appropriate document type (either e-Factura or e-Ticket) in the account.move module, based on the partner's identification type (RUT/RUC or other). This will reduce the need for manual adjustments. Users will still have the flexibility to select other document types to account for any exceptions. Latam-task: 1273 Adhoc-side-task: 44194
Resolved issues and error corrections
This update fixes an issue where delivery guides for Mexican customers were incorrectly using the customer's main address instead of their specified delivery address. This ensures accurate delivery information for Mexican tax reporting (CFDI) and avoids potential errors in shipping. The change was triggered by a bug in the delivery address handling process.
Original PR description
**Steps to reproduce:** - Install l10n_mx_edi_stock_extended_31 - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - In Accounting settings, enable "Customer Addresses" - Add a delivery address to a Mexican contact (e.g. INMOBILIARIA CVA) - Create a SO: * Customer: [INMOBILIARIA CVA] * Delivery Address [Delivery address of INMOBILIARIA CVA] * Product: [any product with an UNSPSC category] - Confirm the SO - Go to the created delivery (Its delivery address is the delivery address of INMOBILIARIA CVA) - Edit the delivery: * Transport Type: [Federal Transport] * Vehicule Setup: [any] * Gross Vehicule Weight: [any] * Distance to Destination (KM): [any] - Validate the delivery - Generate Delivery Guide - Check the generated delivery guide xml **Issue:** The destination address in the xml is the address of the main contact. It should be its delivery address. opw-4151229
This update fixes an issue where asset calculations in Uruguay were inaccurate due to foreign currency tax values not being properly converted. The change ensures that non-deductible tax values are stored in the asset's currency, leading to correct original value calculations and improved financial reporting. This impacts users in Uruguay utilizing the accounting module.
Original PR description
…pany currency Problem: When calculating the non_deductible_tax_value on an asset the non_deductible_tax_value of the original move lines are not converted into the asset's/company's currency. This…
…pany currency Problem: When calculating the non_deductible_tax_value on an asset the non_deductible_tax_value of the original move lines are not converted into the asset's/company's currency. This is used when calculating the original_value of the asset and can cause incorrect calculations. Purpose of this PR: To make sure the non_deductible_tax_value is stored in the asset's currency How to reproduce: 1- install: Uruguay - Accounting 2 - change company country to Uruguay 3- settings -> accounting -> taxes -> Fiscal Country: Uruguay. 4- create a new tax and make sure that the accounts on % of tax are expenses account so that the tax in non-deductible tax. 5- make sure to select the right tax group and country = Uruguay in the advanced options of tax. 6- create new product, and in accounting tap set the fixed asset account to the expenses account. and in the purchase tap make sure that the vendor taxes is set to the tax created before. 7- create a new vendor bill with the currency set to UYU. and confirm the bill. make sure that the fixed assets account is selected. 8- go to assets and create a new asset, in bills tab add the created bill. the asset will be created and the Original Value filed will contain the wrong amount. When calculating the non_deductible_tax_value for an asset, if there are original move lines in a foreign currency they won't be converted into the assets currency opw-4089386 Forward-Port-Of: odoo/enterprise#70268
This update resolves an issue where stock quantities weren't correctly updated after changing the lot number in the shopfloor process. The fix ensures that stock levels are accurately reflected, preventing incorrect location assignments for materials. This improves inventory accuracy and reduces potential errors in production workflows.
Original PR description
### Steps to reproduce: - In the settings Enable Multi-steps route - Create a product FP with a BOM: - 1 component: 1 x COMP (tracked by SN) - 1 operation: "Register SN on COMP" - Add an instruction…
### Steps to reproduce:
- In the settings Enable Multi-steps route
- Create a product FP with a BOM:
- 1 component: 1 x COMP (tracked by SN)
- 1 operation: "Register SN on COMP"
- Add an instruction on your op:
- type: "Register consumed component"
- Product To Register: COMP
- Put 2 SN for COMP:
- SN01 in Stock/Shelf1
- SN02 in Stock/Shelf2
- Create and confirm an MO for 1 Unit of FP
> SN01 is reserved on the COMP raw move.
- Go to the shopfloor > "Register SN on COMP"
- Change the SN of the COMP from SN01 to SN02
#### > Go back to the MO the incorrect location was used
### Cause of the issue:
While the lot is correctly updated by the action here: https://github.com/odoo/enterprise/blob/e90cf74be3945d1f1256d398ca9c4b61bc35ed08/mrp_workorder/models/quality.py#L485-L507 The associated quant is not set and hence the move location_id, package, ... are not updated with it.
### Fix:
We take advantage of the `quant_id` dummy field of the `stock.move.line` to update the info to write thanks to the write override: https://github.com/odoo/odoo/blob/09cac8b9e6d2db46dadece0442a8a947a49c9de7/addons/stock/models/stock_move_line.py#L85 https://github.com/odoo/odoo/blob/09cac8b9e6d2db46dadece0442a8a947a49c9de7/addons/stock/models/stock_move_line.py#L399-L400 https://github.com/odoo/odoo/blob/09cac8b9e6d2db46dadece0442a8a947a49c9de7/addons/stock/models/stock_move_line.py#L911-L920
### Note:
Unfortunately, the Dialog opened when clicking on the the quality check from the shopfloor:
https://github.com/odoo/enterprise/blob/34ab94cdcc49f4ade66953874a03f2988b2b4317/mrp_workorder/static/src/mrp_display/dialog/mrp_quality_check_confirmation_dialog.js#L12
is not embedded in a form view so that the onchange:
https://github.com/odoo/odoo/blob/366676cafdce00d55823c6daf41452b0c2373e4d/addons/stock/models/stock_move_line.py#L185-L192
is not triggered by our change of "lot_id".
opw-4149941
---This update fixes an issue where printed Chilean invoices displayed inconsistent currency rates for each line item. The change ensures that all invoice lines use a consistent currency rate, improving invoice accuracy and compliance. The fix corrects a calculation error related to rounding within the Chilean currency system.
Original PR description
**Steps to reproduce:** - Install l10n_cl - Switch to a Chilean company (e.g. CL Company) - Activate a foreign currency (e.g. USD) - Make sure that the rate of the foreign currency is not 1 For…
**Steps to reproduce:** - Install l10n_cl - Switch to a Chilean company (e.g. CL Company) - Activate a foreign currency (e.g. USD) - Make sure that the rate of the foreign currency is not 1 For example: * Unit per CLP: 0.001057876419 * CLP per Unit:945.29 - Create an invoice in USD with 2 lines having different amount: * 15.80 * 15.00 - Save the invoice - Print the invoice **Issue:** On the printed invoice, a slightly different currency rate is displayed for each invoice line. **Cause:** The currency rate to display is computed for each invoice line, based on the following formula: abs(self.balance) / self.price_subtotal However, the value of balance is rounded to the unit because of the CLP currency and therefore it generates a different rate when trying to compute it. **Solution:** Compute the rate from the total values instead of the subtotal of each line. The real rate configured on the currency cannot be used because it can be modified after the creation of the invoice. opw-4242448 Linked community PR: https://github.com/odoo/odoo/pull/185230 Forward-Port-Of: odoo/enterprise#73035
This update fixes an issue where invoices for subscription orders weren't accurately calculating amounts due, particularly when down payments were involved. The change ensures that invoice amounts are correctly calculated by using the appropriate data for recurring products, resolving discrepancies and improving invoice accuracy.
Original PR description
### Steps to reproduce the issue: 1. Create a Sale Order with a recurring product and a non-recurring product and Confirm 2. Create a Down Payment Invoice and Confirm It 3. Try creating a new Invoice…
### Steps to reproduce the issue: 1. Create a Sale Order with a recurring product and a non-recurring product and Confirm 2. Create a Down Payment Invoice and Confirm It 3. Try creating a new Invoice 4. The Already invoiced and Amount to invoice values are incorrect ### Explanation: When calculating `amount_to_invoice` in `sale.order` with `is_subscription=True`, the calculation of the non-recurring lines is calculated using their `price_total`, `qty_to_invoice` and `product_uom_qty`. Down Payment lines do not have `price_total`. ### Fix reasoning: In `odoo/addons/sale`, the calculation of `amount_to_invoice` uses `account.move._get_sale_order_invoiced_amount`. https://github.com/odoo/odoo/blob/6a5a94b1cc5556371ea94a17624c534086a2a6e1/addons/sale/models/sale_order.py#L643-L647 https://github.com/odoo/odoo/blob/b5d02cc72543b36c7e5e620a3a579f15c88baed6/addons/sale/models/account_move.py#L157-L166 Modifying this code in order to only calculate using non-recurring `order_line` and adapting already existing test to include down payment possibility. opw-4052417