Syncing from upstream odoo/odoo (tmp.18.0) #34178
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Keep the original session id that initialised the http request. task-4922056
Before this commit an error can appear if there two delivery line. Use method in delivery module to compute delivery amont. This method can compute if there are two line with delivery https://github.com/odoo/odoo/blob/18.0/addons/delivery/models/sale_order.py#L27 closes #217624 Signed-off-by: Antoine Vandevenne (anv) <[email protected]>
Steps to reproduce: - Navigate to a Project > View (Timesheets) - Open studio and add x_plan2_id for example to the view - Try creating a new timesheet and set a value for the field we added using studio - Save and notice the field doesn't keep its value Cause: This is mainly happening because when getting the plan_ids for the account we are gonna fill we just get the account in the distribution and ignore if the user is setting another value Fix: We check the create vals_list if a plan has value we set it before setting the account in the distribution opw-4716041 closes #214865 Signed-off-by: Xavier Bol (xbo) <[email protected]>
Before this commit: When calculating the `price_unit` for stock moves from purchase order lines, the `remaining_qty` and `remaining_value` could be imprecise. Standard float comparisons for these remaining amounts could lead to incorrect `price_unit` calculations if, for example, `remaining_qty` was a very small float near zero. This could result in inaccurate stock valuations, particularly when currency conversions were involved or when landed costs were applied. For example, 70.00000003 is rounded **up** to 70.00001 (with 5 digits), resulting in a quantity difference of 0.00001, which incorrectly inflates the unit cost. After this commit: Change the rounding method to 'HALF-UP' instead of the default 'UP' to improve precise result for quantities. Steps to reproduce: 1. Configure a product with AVCO real time. Set decimal precision for price and UoM to 5 digits. 2. Create a Purchase Order (e.g., 190 units @ $110/unit). 3. Receive 70 units and create a backorder 4. Create and post a bill for the initially received quantity. 5. Apply a landed cost to the picking of the first 70 units. 6. Create a draft bill for the remaining quantity on the PO. 7. Receive the remaining 120 units from the backorder. 8. The product's cost explodes opw-4705224 closes #216919 X-original-commit: e828faa Signed-off-by: Tiffany Chang (tic) <[email protected]> Signed-off-by: Walravens Mathieu (wama) <[email protected]>
…move to sale_order Step to reproduce: - Enable Analytic accounting in Accounting settings - Create a sale order - Show Analytic Distribution - Create an expense and put this sale order in the "Customer to Reinvoice" field. - Add an Analytic Distribution - Create Report - Submit to Manager - Approve - Post Journal Entries Curent behavior: - No analytic_distribution on the sale_order Expected behavior: - analytic_distribution form the expense should be copied to the sale_order Cause: analytic_distribution wasn't set at the creation of the sale order from the account_move closes #216291 Signed-off-by: Xavier Bol (xbo) <[email protected]>
Steps to reproduce: 1. Connect IoT Box and any printer that accepts PDF 2. Turn on Reception Report option on Inventory Settings 3. Set configuration of Receipts to print out Reception Report and Label 4. Assign Reception Report and label to the printer 5. Create a PO and run through the Reception process (PO > Reception of Delivery) 6. Print the Reception Report under "Allocations" -> Result: Reception Report and label is downloaded as a PDF instead of being sent to the printer. The reason for this bug is that the report models were being constructed directly in the frontend, rather than being fetched from the backend. This didn't work with IoT printing because its override used to assign devices to reports is on the backend `ir.actions.report` model. The fix is to fetch the report from the backend when the component is loaded. This report is then passed down to the child components as well. opw-4790299 closes #216121 X-original-commit: e9c7f03 Related: odoo/enterprise#88656 Signed-off-by: Louis Travaux (lotr) <[email protected]> Signed-off-by: Max Whale (mawh) <[email protected]>
The test in this module imports a common setup from account_reports which is not a dependency, and is not auto installed when the test runs with comunity modules only. This fix replaces the setup by the community one AccountTestInvoicingCommon. closes #217681 Signed-off-by: Jinane Maksoud (maji) <[email protected]>
In 0f3a9de we added helpers to create test taxes in `AccountTestInvoicingCommon`, not realizing that they were already in `TestTaxCommon`. This commit removes them from `TestTaxCommon` to avoid the duplication. task-none closes #217553 Signed-off-by: Laurent Smet (las) <[email protected]>
Before, the previous document chaining was not sent in the XML because with the t-if, if the variable name is unknown, it will not complain and just see it as False. (like for the first invoice that has no previous) Now, passing the correct variable name, the previous document will be included opw-4814241 closes #217685 Signed-off-by: Ruben Gomes (rugo) <[email protected]>
…tInvoicingCommon closes #215588 Related: odoo/enterprise#88357 Signed-off-by: Claire Bretton (clbr) <[email protected]>
Currently, with an MTSO rule, the smart button from the Sale Order
to the Manufacturing Order was available. However, the reverse link
(from the MO to the SO) was missing.
But they share the same link between object and people don't
understand. So we copy the condition to have the same SO<->MO
link.
It was missing the sale_id on the procurement group itself. Before
production.procurement_group_id.move_dest_ids.group_id.sale_id
was enough since mtso share move links but with the new MTSO it's
not the case anymore. But the sale_id is copied from a procurement
to the new ones.
Steps to reproduce:
- Enable multi-step routes in Inventory settings
- Unarchive the MTO route:
- Select the rule with the production usage
- Set its supply method to "MTSO"
- Create a storable product “P1”:
- routes: MTO + Manufacture
- Create and confirm a Sale Order with one unit of P1
- Confirm the SO
Problem:
The smart button from the SO to the MO appears correctly,
but the reverse link from the MO to the SO is missing.
opw-4619136
opw-4557138
opw-4875937
opw-4854581
opw-4887746
closes #204276
Signed-off-by: Steve Van Essche <[email protected]>
Otherwise, it causes it fails to assign value to certain records, which is unadvised. closes #217713 Signed-off-by: Nicolas Viseur (vin) <[email protected]>
Issue --> The final step of the `_action_merge` method updates the `code` field of the account onto which the other accounts are merged. During the write call on `code`, a dependent field `always_tax_exigible` on `account.move` gets added to the compute chain. This causes a fetch of all `account.move` records related to journal items related to the account that is getting updated. This can lead to a MemoryError on databases with large `account.move` tables. Solution --> We delegate the write of the `code` field to SQL. In the account merge wizard, accounts that can be grouped are grouped by the keys --> `'account_type', 'non_trade', 'currency_id', 'reconcile', 'deprecated','name'`. Therefore, the `account_type` does not change after the merge. We can safely assume that any fields dependent on `account_type` do not need recomputation and hence, bypass the ORM for this update. Additional change --> Disable the prefetcher in the write call in `account.account` to optimize memory usage on databases with a large number of journal items/journal entries when writing on `code` or `account_type` in general. opw-4839985 closes #216768 Signed-off-by: Thomas Becquevort (thbe) <[email protected]>
This commit applies the necessary changes to make the json_activity_data field of account.journal extensible. The field computation needed to be extended in account_reports to make dashboard activities styling more dynamic. More details can be found in the enterprise PR: odoo/enterprise#89331 backport of: dce24cd task-4370133 task-4458309 closes #217213 Related: odoo/enterprise#89331 Signed-off-by: Florian Gilbert (flg) <[email protected]> Signed-off-by: Hesham Saleh (hsal) <[email protected]>
…sons Steps to reproduce: - In the settings enable by-products - Create a product FP with a bill of material: - 1 operation: op 1 - 1 By-product line: cost share 3.3%, produced in op 1 - Create aand confirm an MO for 1 unit of FP - On the by product line produce 10 instead of 1 - Produce All > 19 units of by products were produced: The initial by-product move > was validated for 10 units and an extra move with a quantity of 9 > was automatically created and validated aswell. Cause of the issue: Since the quantity of the by-product move exceed its initial demand, its validation will create an extra move that is expected to be merge into the main move during its confirmation: https://github.com/odoo/odoo/blob/474ac02d03c17af0274422ecb1e97ca14a3e80e7/addons/stock/models/stock_move.py#L1922 https://github.com/odoo/odoo/blob/474ac02d03c17af0274422ecb1e97ca14a3e80e7/addons/stock/models/stock_move.py#L1844-L1865 However, while `cost_share` value of the original move floats is correctly encoded as 3.3, the copied value of the extra is 3.3000000000000003. This discrepency is a well known issue of the way the orm handles float and convert them to cache as it calls the `float_round` method, which can effectively change its value: https://github.com/odoo/odoo/blob/8c22e358840f02c5b1596e1fbe0d6cf7315754f7/odoo/fields.py#L1553-L1557 In particular, the `cost_share` of both moves differs in terms of strict equality and the move will not be merged with its extra move. Note: The issue should not be reproducible in saas17.4+ because the float_round issues have been erased by commit 784f151 opw-4846289 closes #216916 X-original-commit: 3964f17 Signed-off-by: Quentin Wolfs (quwo) <[email protected]> Signed-off-by: Lancelot Semal (lase) <[email protected]>
…rt layout Steps to Reproduce: 1. Go to Settings > Companies > Configure Document Layout. 2. Choose layout Boxed or any layout that horizontally places the company logo and address. 3. Edit the address block choose long string. 4. Save the layout and click Preview Document or print SO or invoice. Issue: Observe in PDF output the long text overlaps into logo or extend outside the layout bound(differ in layouts) — even though enough space is visually available Cause: A previous change in PR #201198 added the text-nowrap class to address blocks to fix a minor wrapping issue. However, this unintentionally caused layout overflow issues with long lines. Solution: - Added width to the address block to ensure balanced layout structure. - Removed text-nowrap from all layouts, as the original issue is now resolved by applying proper width sizing. - Removed float-end from Boxed layout, as it was contributing to misalignment. Additional Notes: All behaviors addressed by PR #201198 were re-tested to ensure this fix does not reintroduce previous issues. opw-4764975 closes #216876 Signed-off-by: Bastien Fafchamps (bafa) <[email protected]>
Issue: Copying a bom with an operation will not reassign the copied operation to the by product lines. Steps to reproduce: - In the settings enable operations and by-products - Create a bom with an operation op1 and a by product produced in op1 - Copy the bom > The copied by product line refer to the operation of the original bom > this can be checked by archiving the copied operation which should > erase its link with the copied by product line but will not Cause of the issue: When a bom is copied, the new operation is reassigned to the new bom lines by these lines: https://github.com/odoo/odoo/blob/9cb4230a6b2252243a8e0546a1a8f5bc52e74009/addons/mrp/models/mrp_bom.py#L230-L247 However, nothing is made for the by product lines. opw-4788252 closes #217319 X-original-commit: eabb3fc Signed-off-by: William Henrotin (whe) <[email protected]> Signed-off-by: Lancelot Semal (lase) <[email protected]>
…ed from sale In Hungary the rate of the currency of an invoice is based on the delivery date. When creating an invoice from Sale, the `currency_rate` of the lines is the one of the invoice date not of the delivery. Steps to reproduce: - Install l10n_hu_edi and witch to Hungarian company - Have two different rates for EUR<->HUF - Create a pricelist in EUR - Create a quotation with the pricelist and confirm - Validate the delivery on another date (which has a different rate from today) - In the sale order click "Create Invoice" - The generated invoice has lines using the rate for today Cause: The field `delivery_date` is `precompute=True` but on creation of the invoice, at the time of the precompute, `line_ids` is still `False`. So the invoice is first computed without the delivery date, the currency rate used is the one of the invoice date. When the delivery date is written on the invoice, the line balance is not recomputed as the field `balance` is marked as `protected`. Solution: As the field `delivery_date` was implemented in `account_move` for localizations including l10n_hu, there are no reason to contain the fix only to l10n_hu. So we add the value of `delivery_date` in the dictionnary used to create a new invoice from sale with the method `_create_invoices`. This way the delivery date is there on creation of the invoice and is used for the currency rate. opw-4756568 closes #209095 Signed-off-by: Ruben Gomes (rugo) <[email protected]>
closes #217664 X-original-commit: 027d07d Signed-off-by: Ruben Gomes (rugo) <[email protected]> Signed-off-by: Josse Colpaert (jco) <[email protected]>
When creating a sale order through crm, default_user_id was being passed through the context. This was causing issues when confirming the sale orders when quality checks were enabled as the user on the quality checks would be set as the user from the CRM lead. Removing this from the context before confirming and thus creating any linked records avoids this issue. opw-4658850 closes #216712 X-original-commit: 1540c30 Signed-off-by: Ryan Cen (ryce) <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
bt_gitbot