Thursday, October 31, 2024
14 changes
1 change
Resolved issues and error corrections
This update improves manufacturing planning and shop floor workflows by making replenishment needs and work order filters behave as expected. Teams can more reliably identify products that still need replenishment and find the right shop floor work orders without manual workarounds.
Original PR description
Description of the issue/feature this PR addresses: This PR fixes three Shop Floor and MPS bugs provided in task [4104208](https://www.odoo.com/odoo/project/966/tasks/4104208). Current behavior…
Description of the issue/feature this PR addresses: This PR fixes three Shop Floor and MPS bugs provided in task [4104208](https://www.odoo.com/odoo/project/966/tasks/4104208). Current behavior before PR: 1. Shop Floor ignores the `workcenter_id` context parameter and the user always lands on the same workcenter (the first one in defined). 2. Products that are marked as replenished won't appear under the 'to replenish' filter even if the replenishment is insufficient due to later demand. (underreplenishment) 3. The max replenish option is remains off even if a max replenish quantity is already set. 4. WO filters in Shop Floor for the waiting, pending and done states don't work as intended. 5. Accessing the Shop Floor directly from an MO lands the user in an empty workcenter if All MO isn't enabled. Desired behavior after PR is merged: 1. ~~The user lands on the 'All MO' virtual workcenter if they access Shop Floor through the button in an MO.~~ Nixed. 2. Replenished products will still appear under the 'to replenish' filter if the replenishment turns out to be insufficient. 3. The max replenish option gets automatically toggled on if a max replenish quantity is already specified (ie nonzero), mainly if the product record was added bypassing the form (API, import etc). 4. WO filters are properly implemented. Filtering by the ready and progress states is the default. ~~Entering the Shop Floor through an MO no longer filters by This Station.~~ 5. ~~All MO is temporarily enabled if Shop Floor is accessed through an MO and All MO is not enabled. It's also checked on by default in the workcenter selection menu.~~ Nixed. Task ID: [4104208](https://www.odoo.com/odoo/project/966/tasks/4104208)
8 changes
Resolved issues and error corrections
Odoo Community now automatically creates the needed payment accounting entry when a payment is recorded. This ensures invoices show the correct paid status and remaining amount without requiring bank reconciliation or Enterprise-only journal account setup.
Original PR description
In Odoo Community, bank reconciliation is not available. For that reason, when recording a Payment, this should be enough to fully recognize the payment of the invoice, as there is no second "reconciliation step". In this case, we always want a "behind-the-scene" entry to be created to compute the amount_residual and the status of the invoice accordingly. After the Payments rework, the problem is that by default, no Outstanding account is set up on basic Payment Methods, not triggering any entry and messing up the computation of the invoice status. On top of that, the user shouldn't even have to configure accounts on journals, as this is a pure Accounting work. task-4224553 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
5 changes
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
The combo product configurator has been adjusted to work better on mobile screens. This makes it easier for shoppers and sales users to view product options and adjust quantities without layout issues.
Original PR description
This commit fix usability issues related to the layout of the combo configurator on mobile. task-4243795 | Before | After | |--------|--------| | <img width="507" alt="Capture d’écran 2024-10-22 à 13 28 53" src="https://github.com/user-attachments/assets/cac3aa9b-165e-49e6-98e3-3dd1eb2d8d9b"> | <img width="489" alt="Capture d’écran 2024-10-22 à 13 30 14" src="https://github.com/user-attachments/assets/fc0da502-291f-4154-af5e-df1e74c8c61f"> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Customer and contact lists can now be ordered alphabetically by name, making it easier for users to browse and find records. This fixes a limitation caused by sorting on a non-stored display field and improves day-to-day usability in customer management views.
Original PR description
Steps to reproduce: Go to Accounting > Customers > Customers. Current behavior: The contact list cannot be ordered alphabetically by name. The `Name` field is `display_name`, a computed field in `res.partner` that is not stored, preventing alphabetical sorting. In future versions (starting from saas-17.2), `display_name` will be replaced by `complete_name`, a stored field containing the full name of the customer, which supports alphabetical ordering. opw-4262464 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Manufacturing overview's Plan Orders button now opens the relevant work orders for the selected work center and its alternatives, instead of sending users to an unrelated manufacturing order or broad work order list. This helps planners find the right operational tasks faster and reduces confusion when managing work center capacity.
Original PR description
The 'PLAN ORDERS' button in the Manufacturing overview now leads to the list of all WOs regardless of workcenter and status. Task ID: [4154879](https://www.odoo.com/odoo/966/tasks/4154879)
Customers checking out on Argentina- or Brazil-localized websites can now edit their address without the checkout failing. The fix ensures the required local address fields are handled properly, reducing purchase interruptions for public web shop users.
Original PR description
- Change the company of the first website to the localized company - Open web shop as public user - Make a purchase - Checkout and fill the address - Edit the address - Confirm Issue: Traceback will raise because of the missing localization fields opw-4232531
This fix ensures sales orders with down payments show the correct remaining amount to invoice. It helps prevent billing mistakes and gives sales and accounting teams more reliable invoice information.
Original PR description
task-4213628 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
New portal users can complete appointment bookings more easily when they do not yet have a phone number. The flow now encourages sign-in, updates missing phone details for logged-in users, and avoids carrying appointment form data into ecommerce in ways that could alter booking details.
Original PR description
As new portal users usually have no phone, let us ease their booking flow while ensuring correct data. Their phone will be updated if logged and not set. Encourage them to sign in with a new Sign In button. Also remove propagation to ecommerce flow so that we make sure appointment form data is kept as is and description remains correct. A test and pot files are adapted accordingly. Task-4207064
This fixes an appointment payment flow where paid invoices did not always create the related meeting because payments were no longer consistently linked to accounting entries. Meetings are now created when the invoice is posted, whether that happens automatically after payment processing or manually by staff.
Original PR description
ISSUE Introduced in odoo/odoo@01b87f1230beac0568f4e3b1b76e547909506892 the payments are not always linked to account moves. As the invoicing + appointment flow was creating the meeting on reconciliation between the invoice account move line and the payment account move line, using the _invoice_paid_hook method, the flow does not work out of the box anymore. FIX Let us align ourselves to what we do with eCommerce. As the only time we create a link between the invoice and the booking is using the flow, we are creating the invoice in draft at that time, we can consider that posting the invoice is either a manual action, either done automatically when post processing transactions, which would restore the previous flow, and also give more flexibility in the backend, as manually posting the invoice will also create the meeting. Task-4251392
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