Thursday, January 30, 2025
7 changes · 18.0
Resolved issues and error corrections
This fixes Spanish TicketBAI reporting for Bizkaia so vendor bills send the supplier reference instead of the internal invoice name. It helps ensure submitted invoice data matches official supplier documents and supports correcting or cancelling invoices created with the previous numbering behavior.
Original PR description
… ref, not the name 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
Point of Sale now treats an order as a refund only when every line is negative, rather than when just some lines are negative. This prevents loyalty rewards from being incorrectly affected on mixed orders that include both sales and negative lines.
Original PR description
Assuming that an order is a refund with the presence of some negative lines is not compatible with the current implementation of pos_loyalty rewards. In this PR, we make an assumption that is valid in most cases than previous, such that an order is a refund if all of its lines are negative.
Manufacturing order overviews now calculate expected bill of materials costs using the same workcenter assumptions as the bill of materials overview. This makes planned versus actual production cost comparisons more reliable by including time efficiency, setup time, and cleanup time.
Original PR description
Steps to reproduce the bug:
- Create a workcenter “WC1”:
- Cost by hour: 60
- Setup time: 10 min
- Cleanup time: 10 min
- Time Efficiency: 85
- Create a storable product “P1” with the following BoM:
- Operation: OP1 -> 60 min in WC1
- Create a MO to produce one unit of P1:
- Confirm the MO
- Go to the MO overview
Problem:
Time Efficiency, setup, and cleanup times are not taken into account in
the BoM Cost calculation.
The calculation should be the same as in the BoM overview. The purpose
of the BoM cost in the MO overview is to provide information for
comparison with the real cost, in case the user has modified certain
parameters during production.
Attention: There may be a slight difference in the calculation of
"mo_cost" and "bom_cost" because the expected duration is rounded to
two digits in the work order. This affects the mo_cost calculation
since it relies directly on this field,
opw-4478070This fix prevents an error when receiving a purchased kit product that includes a lot-tracked component. Businesses can now validate these receipts reliably, ensuring inventory and costing updates complete without interruption.
Original PR description
Steps to reproduce the bug: - Create a storable product “P1”: - Product category: “AVCO” - BoM: - Type: Kit - Components: - C1: Tracked by lot and valuated by lot - C2 - Create a purchase order: - 1…
Steps to reproduce the bug:
- Create a storable product “P1”:
- Product category: “AVCO”
- BoM:
- Type: Kit
- Components:
- C1: Tracked by lot and valuated by lot
- C2
- Create a purchase order:
- 1 unit of P1 → Price: $10
- Confirm the PO
- Go to the reception:
- Set a new lot (Lot_1) for C1
- Validate the reception
Problem:
A traceback is triggered:
```
new_std_price = move_cost[lot]
~~~~~~~~~^^^^^ KeyError: stock.lot(19,)"
```
When validating the picking, the moves will first be validated, and then
the product price will be updated before the move is marked as done:
https://github.com/odoo/odoo/blob/168f4d75ef724ee99ffaf7884730facd8ed936bb/addons/stock_account/models/stock_move.py#L387-L388
The move cost is retrieved using the _get_price_unit function:
https://github.com/odoo/odoo/commit/2d933b83613ad52d76ab457201adecac6fcf184b#diff-ad6229e976ce0bd1592e805b88e9813ac4e3f6fb989d3dfb8dfb8b70af03cd58R403
However, since move.product_id is different from move.purchase_line,
the parent product will be treated as a kit, and the unit price of the
kit product will be used instead: https://github.com/odoo/odoo/blob/17.0/addons/purchase_mrp/models/stock_move.py#L19
Based on this, the unit price for each component is calculated using
the cost_share and the bom_lines quantities. This is then stored in a
dictionary with an empty record of the ```”stock.lot”``` model:
When attempting to access the dictionary using the lot key from the move,
no result is returned, leading to an error.
https://github.com/odoo/odoo/blob/2d933b83613ad52d76ab457201adecac6fcf184b/addons/stock_account/models/stock_move.py#L425
Solution:
The process should account for the fact that the move product is a
component of a kit. Therefore, the price should be directly retrieved
from the dictionary without requiring a key.
opw-4434390This fix restores subtotal information in Ecuadorian electronic withholding documents after a previous issue was resolved. Businesses using Ecuador localization should see more complete withholding records and fewer errors when reviewing related accounting documents.
Original PR description
We uncomment the subtotals because there was an error about withhold subtotals dict. Now the error has been resolved related: https://github.com/odoo/enterprise/pull/76330
Deleting a website no longer causes related documents to be deleted unintentionally. This protects business files from accidental loss while still allowing documents to remain linked to the correct website when appropriate.
Original PR description
Due to an oversight when migrating documents share to documents in Sharepocalypse, documents were being deleted when their related website was deleted. This is not a desired behavior. Even though setting the "correct" website is possible (and desired) when there is a `company_id`, there is no problem with having empty `website_id` in the other case. opw-4494091
Creating a loan could fail for companies with existing accounting activity because the system unnecessarily tried to update and recalculate a very large volume of accounting data. This fix prevents that costly recalculation while still allowing the loan form to show the correct currency information.
Original PR description
### Description: When creating a loan, users encounter a memory error if they have used accounting. This occurs because the `currency_id` field is related to the company's `currency_id` and is not…
### Description: When creating a loan, users encounter a memory error if they have used accounting. This occurs because the `currency_id` field is related to the company's `currency_id` and is not readonly, causing the ORM to perform an inverse related and update the company's `currency_id`. This is problematic since changing the currency triggers a massive recompute of nearly all accounting records unnecessarily. For example, in the case of this customer, it was trying to update 191219 account.analytic.line, which caused this memory error. The initial design aimed to show the monetary symbol on the form when the `onchange` in `web/models/models.py` was triggered, but this approach led to the issue. ### Fix: By adding `company_id` to the view as an invisible field, the onchange can retrieve it to display the monetary symbol without triggering the problem. This change is backward-compatible; customers who haven't updated their views will only miss the monetary symbols on the form view until the record is saved. ### Reference: opw-4486739