Monday, October 28, 2024
34 changes · saas-17.4
Resolved issues and error corrections
The Employee Expense Journal setting now limits choices to purchase journals only. This prevents users from selecting an unsuitable journal and helps keep expense accounting setup accurate.
Original PR description
## Steps: 1- Expenses 2- Settings 3- Employee Expense Journal: all the journals can be selected. It should be only "Purchase" journals. This PR adds a filtering domain to the `expense_journal_id` field to filter out non 'purchase' journals. opw-4251517 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users can now expand subcontracting lines in the Bill of Materials overview without seeing an error pop-up. This improves reliability for manufacturing teams reviewing subcontracted components and keeps the BoM overview usable.
Original PR description
Whe the user clicks on a subcontracting line in the BOM overview, an error is raised. This occurs because we are passing false when subcontracting lines are not folded, but a function is expected. The solution is to pass a function, which should be a void function when toggleFolded is false. Steps to reproduce: 1. Go to the Manufacturing app. 2. Enable the Subcontracting feature in the Setting tab. 3. Navigate to the BoM overview in the Products tab. 4. Open a BoM that includes subcontracting. 5. Click to expand the subcontracting line. Previous behaviour: An error pop-up appears. Current behaviour: Opens without any error. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where horizontal divider lines could display incorrectly in generated reports. The change helps keep printed or PDF reports visually consistent after the underlying styling framework update.
Original PR description
Since 058212e12b5079eba870bde9775fe98f27928935 Bootstrap's version is 5.3 Many more style is set by CSS Custome properties which wkhtmltopdf does not support This fixes the <hr /> case. opw-4265150 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
This fixes a problem where changing font size did not apply when users selected text across table cells in the web editor. The editor now keeps the table selection intact during the formatting process, so the chosen font size is applied as expected.
Original PR description
Issue: ===== FontSize isn't being applied on table selection. Steps to reproduce the issue: ============================= - Create a new to do - Add a table - Add content in some cells - Select from the middle of the content of the first cell to the middle of the content of the last cell - Apply font size - Nothing happens Origin of the issue: ==================== When we have `useResponsiveFontSizes` enabled, we first set the fontSize with undefined and then we set the fontSizeClassName, but in the first execCommand we trigger `historyStep` event. The event is handled by the `html_field` and it will check if the field is dirty. In the process of checking we call `getValue` of `Wysiwyg`. `getValue` will run `cleanForSave` on the editor which will deselect tables. Solution: ========= We reset the selection after the first execCommand. opw-4237983
The Website field on pricelists now says “Select a website” instead of implying that leaving it blank applies the pricelist to all websites. This helps users avoid misconfiguring pricelists by making the empty-field behavior clearer.
Original PR description
**Prior to this commit:** - While configuring a pricelist, if we don't select any website in the Website field, the placeholder let us think that it should be applied on 'All websites'. **Post this commit:** - The placeholder is renamed as 'Select a website' as the pricelist doesn't apply to any website when the field is empty. **Affected version:** saas-17.4~master **opw**-4256656
Website forms that do not ask for an email address can now be submitted successfully by logged-in users. This prevents valid forms, such as job application forms customized without an email field, from failing unnecessarily.
Original PR description
Since [1] e-mails from forms are compared to the logged in user's e-mail when a website form is submitted. Because of this forms without e-mail cannot be used anymore when the user is not logged in. This commit removes this comparison for forms that do not contain an e-mail field. Steps to reproduce: - Install website_hr_recruitment - Drop a form into the home page - Set the form action to "Apply for a Job" - Remove the e-mail field - Save - Submit the form => An error occurred [1]: https://github.com/odoo/odoo/commit/1aa5cbb06be85e94c01f8f55ef57b9415b9bb50f task-4282750
A maintenance module test was corrected so its calendar can reliably move to the next week during automated checks. This helps prevent false test failures, especially around Saturdays, supporting more stable releases without changing user-facing features.
Original PR description
In commit 9f4f1d8e92d0dc68b5628194d9da56d346e708f6, "Move to next week" step is not being processed because of missing `run` argument. It is necessary for the test to work on saturday and was the main reason of the previous commit being deployed. runbot-error-65494
Fixes an issue that caused an error when duplicating saved user-defined filters. This restores the expected copy behavior, helping users and administrators manage filters without interruption.
Original PR description
**Current behavior:** Duplicating a user-defined filter will fail and trigger an exception. **Expected behavior:** Record duplicates. **Steps to reproduce:** 1. Go to some menu, create a filter 2. In technical settings, go to user-defined-filters menu 3. Select one and duplicate it -> Exception **Cause of issue:** The SQL constraint check_res_id_only_when_embedded_action is triggering because `embedded_parent_res_id` is an Integer type field which, when NULL in postgres, will be interpreted by the ORM as 0 when the record we want to duplicate has its values copied. **Fix:** In the copy_data override for `ir.filters`, delete the key, value pair for `embedded_parent_res_id` if its value is 0. The only case this problem arises in, is when we copy values from an existing filter record and directly use them for creating a new one- i.e., on duplication/copy. opw-4234421
The chart configuration panel now refreshes the stacked option label when users switch chart types. This prevents confusing or outdated wording and helps users configure spreadsheet charts more reliably.
Original PR description
This PR addresses an issue where the stacked checkbox label in the chart config panel was not updating when the chart type was changed. Task: 4251670
The bank reconciliation screen now keeps its two-column layout even when there are no transactions to show. This avoids a confusing empty-state layout and helps users keep the same visual structure while waiting for activity.
Original PR description
We want to keep the two columns layout when there is no transaction yet. Task-id: 4150010
Restaurant floor table setup now includes the appointment resource information needed when bookings are enabled. This restores access to an important booking configuration that became unavailable after the table list was made editable directly.
Original PR description
Steps to reproduce: 1. Install Restaurant and Appointments 2. in PoS's Settings, enable booking 3. go to PoS -> Configurations -> Floor plans 4. Select a floor There is no "Appointment resource" field in the tree view. Initially in 17.2, the tree items in the floor page (the tables) were not editable in place, so clicking on a table opened the form view where we could change the "Appointment resource". However, in 17.4, the tree was made editable in place, but we've missed adding the "Appointment resource" field. This PR adds back the field "Appointment resource" (as hidden field) to the floor tables tree view. The changes in this PR were copied from version 18.0, where this bug was already fixed by commit https://github.com/odoo/enterprise/commit/f240b921dd3548b5f91d947354abc85f947f486b opw-4237285
Miscellaneous changes
Issue --> A noticeable amount of time is spent in the method `_get_outgoing_incoming_moves` when doing the `OR` operation on the stock.move recordsets when there is a large number of moves to iterate through. Solution --> Replace the odoo recordset operations with set operations. Benchmarks --> | # of moves | Before | After | |--------|--------|--------| | 32000 | 24.08s | 1.43s | | 7300 | 1.74s | 0.40s | opw-4220302 Forward-Port-Of: odoo/odoo#185251 Forward-Port-Of: odoo/
Original PR description
Issue --> A noticeable amount of time is spent in the method `_get_outgoing_incoming_moves` when doing the `OR` operation on the stock.move recordsets when there is a large number of moves to iterate through. Solution --> Replace the odoo recordset operations with set operations. Benchmarks --> | # of moves | Before | After | |--------|--------|--------| | 32000 | 24.08s | 1.43s | | 7300 | 1.74s | 0.40s | opw-4220302 Forward-Port-Of: odoo/odoo#185251 Forward-Port-Of: odoo/odoo#183671
When the language is not in the context the report will always show the en_US version. opw-4220270 Description of the issue/feature this PR addresses: Current behavior before PR: - translation is bypassed Desired behavior after PR is merged: - report will be shown in the correct language --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184538
Original PR description
When the language is not in the context the report will always show the en_US version. opw-4220270 Description of the issue/feature this PR addresses: Current behavior before PR: - translation is bypassed Desired behavior after PR is merged: - report will be shown in the correct language --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184538
Versions -------- - 16.0 up to saas-17.4 Steps ----- 1. Add one or more lines to an SO with the same tax; 2. apply a discount coupon. Issue ----- Tax gets mentioned in the discount line name, even though it isn't really necesarry in this scenario. Cause ----- When generating the discount line description, a `tax_desc` gets added for any tax with a name. Solution -------- Only add `tax_desc` if there's more than one discount line being generated due to multiple taxes. op
Original PR description
Versions -------- - 16.0 up to saas-17.4 Steps ----- 1. Add one or more lines to an SO with the same tax; 2. apply a discount coupon. Issue ----- Tax gets mentioned in the discount line name, even though it isn't really necesarry in this scenario. Cause ----- When generating the discount line description, a `tax_desc` gets added for any tax with a name. Solution -------- Only add `tax_desc` if there's more than one discount line being generated due to multiple taxes. opw-4072437 Forward-Port-Of: odoo/odoo#183686
When typing '>:)' in the composer, it should be replaced by '😈'. The problem is that the emoji generator doesn't work with '<', '>' because the text is escaped and the '<', '>'is replaced by '<', '>'. In this case, the regrex doesn't match. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185332 Forward-Port-Of: odoo/odoo#185091
Original PR description
When typing '>:)' in the composer, it should be replaced by '😈'. The problem is that the emoji generator doesn't work with '<', '>' because the text is escaped and the '<', '>'is replaced by '<', '>'. In this case, the regrex doesn't match. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185332 Forward-Port-Of: odoo/odoo#185091
Currently when settling a customer account, we try to create a simplified invoice which is nt possible since we do not have products in the order. Users using the Spanish localization cannot settle customer accounts. Steps to reproduce: ------------------- * Install **l10n_es_pos** and switch to the ES Company * Open shop session * Add products to the order, select any customer, pay with customer account * Select **New order** * Select the previous customer and select **Settle due accou
Original PR description
Currently when settling a customer account, we try to create a simplified invoice which is nt possible since we do not have products in the order. Users using the Spanish localization cannot settle…
Currently when settling a customer account, we try to create a simplified invoice which is nt possible since we do not have products in the order. Users using the Spanish localization cannot settle customer accounts. Steps to reproduce: ------------------- * Install **l10n_es_pos** and switch to the ES Company * Open shop session * Add products to the order, select any customer, pay with customer account * Select **New order** * Select the previous customer and select **Settle due accounts** * Select any payment method * Validate order -> Yes > Observation: Cannot invoice empty order Why the fix: ------------ Spain requires to invoice all orders. In Pos, everything is considered as an order but settling customer accounts does not fall under the definition of an order outside of Odoo (no transfer of product, amount=0). Therefore when we settle customer account we skip the automatic invoicing and fallback on the pos bahavior without the localization. opw-4185144 Enterprise PR: https://github.com/odoo/enterprise/pull/71958 Forward-Port-Of: odoo/odoo#185159 Forward-Port-Of: odoo/odoo#183682
If the bank account number is not in a valid format, it is rejected by `NAV`. When that happened we returned a `(None) None: None` error message, which is not very useful. This was due to an error in xml namespace when looking for the error message. Now, we return the proper error message. We also check that the bank account number is in a valid format before sending it to `NAV` and **warn** the user. The user is still free to send the document anyway. Task-id: 4254627 --- I confirm
Original PR description
If the bank account number is not in a valid format, it is rejected by `NAV`. When that happened we returned a `(None) None: None` error message, which is not very useful. This was due to an error in xml namespace when looking for the error message. Now, we return the proper error message. We also check that the bank account number is in a valid format before sending it to `NAV` and **warn** the user. The user is still free to send the document anyway. Task-id: 4254627 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184470
**[FIX] l10n_in: Remove Enterprise Widget from Indian Electronic Waybill** **Description of the issue/feature this PR addresses:** System shows Enterprise Widget on Indian Electronic Waybill module. Although Indian Electronic Waybill is available in community addons . **Impacted versions:** * 17.0 * 18.0 **Steps to Reproduce :** - Install l10n_in module. - Now Go to the invoicing --> Configuration --> Setting. - See the Enterprise Widget is on Indian Electronic Waybill. **Curr
Original PR description
**[FIX] l10n_in: Remove Enterprise Widget from Indian Electronic Waybill** **Description of the issue/feature this PR addresses:** System shows Enterprise Widget on Indian Electronic Waybill module. Although Indian Electronic Waybill is available in community addons . **Impacted versions:** * 17.0 * 18.0 **Steps to Reproduce :** - Install l10n_in module. - Now Go to the invoicing --> Configuration --> Setting. - See the Enterprise Widget is on Indian Electronic Waybill. **Current behaviour before PR:** Enterprise Widget Should not show on Indian Electronic Waybill as it is available in community addons. **Desired behaviour after PR is merged:** After this PR merge, System will allow to install Indian Electronic Waybill module in community version. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184401
* STEP TO REPRODUCE: create a new uom category and add a new line -> Save. Then delete one line (uom_ids) -> raise UserError because the system force an uom category need to have at least one reference unit. * Fix by allowing to delete uom categ when it only has one single line of reference (by first delete the line and then delete the category), just like behaviour in v15 when we just make a user warning and still allow user to delete it Related forum issue: https://www.odoo.com/forum/
Original PR description
* STEP TO REPRODUCE: create a new uom category and add a new line -> Save. Then delete one line (uom_ids) -> raise UserError because the system force an uom category need to have at least one reference unit. * Fix by allowing to delete uom categ when it only has one single line of reference (by first delete the line and then delete the category), just like behaviour in v15 when we just make a user warning and still allow user to delete it Related forum issue: https://www.odoo.com/forum/help-1/unit-of-measure-categories-archive-option-255227 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#173990
Before this commit: Steps 1) Switch to DE company 2) Upload invoice using corrupted PDF (size = 0 KB) 3) Delete that invoice => It shows an error with a traceback File "/data/build/odoo/addons/l10n_de/models/ir_attachment.py", line 17, in <lambda> and guess_mimetype(attachment.raw) in ( File "/data/build/odoo/odoo/tools/mimetypes.py", line 156, in _odoo_guess_mimetype if bin_data.startswith(signature): AttributeError: 'bool' object has no attribute 'startswith' After this commit:
Original PR description
Before this commit: Steps 1) Switch to DE company 2) Upload invoice using corrupted PDF (size = 0 KB) 3) Delete that invoice => It shows an error with a traceback File "/data/build/odoo/addons/l10n_de/models/ir_attachment.py", line 17, in <lambda> and guess_mimetype(attachment.raw) in ( File "/data/build/odoo/odoo/tools/mimetypes.py", line 156, in _odoo_guess_mimetype if bin_data.startswith(signature): AttributeError: 'bool' object has no attribute 'startswith' After this commit: Invoices in l10n_de with corrupted attachments will be deleted without errors screen recording: https://drive.google.com/file/d/1TMjkwYbLZwEXyLfbSzjmDaO6jOrRk2RO/view?usp=sharing opw-4115496 Forward-Port-Of: odoo/odoo#183768
Bug introcued by this commit: https://github.com/odoo/odoo/pull/174984/commits/7bcfc3a1107650deff9dd8af02a3717304cb7d4e Steps to reproduce the bug: - Create a storable product “P1” tracked by serial number - update the qty with SN1 - Create a delivery order with SN1 - Validate it - go to the product and come back to the delivery - click on detailed operation in the move line Problem: “Unnamed” is displayed instead of the display_name of the quant opw-4279953 opw-4277630 opw-42
Original PR description
Bug introcued by this commit: https://github.com/odoo/odoo/pull/174984/commits/7bcfc3a1107650deff9dd8af02a3717304cb7d4e Steps to reproduce the bug: - Create a storable product “P1” tracked by serial number - update the qty with SN1 - Create a delivery order with SN1 - Validate it - go to the product and come back to the delivery - click on detailed operation in the move line Problem: “Unnamed” is displayed instead of the display_name of the quant opw-4279953 opw-4277630 opw-4276882 opw-4276058 opw-4252901 Forward-Port-Of: odoo/odoo#184920
Steps to reproduce: ------------------- * Make sure you have atleast 2 companies created * Create atleast one PoS in each company * Go in one of the company settings and look for Trusted Point of sale > Observation: You are able to select the PoS from the other company Why the fix: ------------ Adapt the domain to filter out PoS that are not part of the current company opw-4161351 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Por
Original PR description
Steps to reproduce: ------------------- * Make sure you have atleast 2 companies created * Create atleast one PoS in each company * Go in one of the company settings and look for Trusted Point of sale > Observation: You are able to select the PoS from the other company Why the fix: ------------ Adapt the domain to filter out PoS that are not part of the current company opw-4161351 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184882 Forward-Port-Of: odoo/odoo#184466
*l10n_din5008, l10n_din5008_purchase, l10n_din5008_repair, l10n_din5008_sale, l10n_din5008_stock Related to: https://github.com/odoo/enterprise/pull/72707 Forward-Port-Of: odoo/odoo#184181 Forward-Port-Of: odoo/odoo#183268
Original PR description
*l10n_din5008, l10n_din5008_purchase, l10n_din5008_repair, l10n_din5008_sale, l10n_din5008_stock Related to: https://github.com/odoo/enterprise/pull/72707 Forward-Port-Of: odoo/odoo#184181 Forward-Port-Of: odoo/odoo#183268
The `move.reversed_move_id` field only represents the credit note that the user has manually created to revert a move, entirely or partially, but it doesn't take into consideration all moves reconciled through other means. We now use the method `move._get_reconciled_invoices()` which goes through all the partials to retrieve them instead. This enables also the reconciliation with the outstanding credits case to be covered. Closed 16.0 PR: odoo/odoo#119132 Task [link](https://www.odoo
Original PR description
The `move.reversed_move_id` field only represents the credit note that the user has manually created to revert a move, entirely or partially, but it doesn't take into consideration all moves reconciled through other means. We now use the method `move._get_reconciled_invoices()` which goes through all the partials to retrieve them instead. This enables also the reconciliation with the outstanding credits case to be covered. Closed 16.0 PR: odoo/odoo#119132 Task [link](https://www.odoo.com/odoo/project/967/tasks/3281816) task-3281816 Forward-Port-Of: odoo/odoo#184783
How to reproduce: - Create a product P, storable, uom=Units - Create Receipt for 12 units of P, Confirm - Change the operation line from 12 Units to 1 Dozen - Validate Receipt => Valuation layer for 12 Units created (OK) - Unlock Receipt - Change the operation line from 1 to 2 Dozens - Save Receipt => Valuation layer for 1 Unit created (Should be 12) OPW-4204420 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#1848
Original PR description
How to reproduce: - Create a product P, storable, uom=Units - Create Receipt for 12 units of P, Confirm - Change the operation line from 12 Units to 1 Dozen - Validate Receipt => Valuation layer for 12 Units created (OK) - Unlock Receipt - Change the operation line from 1 to 2 Dozens - Save Receipt => Valuation layer for 1 Unit created (Should be 12) OPW-4204420 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184881 Forward-Port-Of: odoo/odoo#182502
Steps to reproduce: ==== - Create a quotation and confirm it. - Open Point of Sale. - Load the order in POS. - Choose option Apply a down payment(percentage). - Insert 50. - Do payment and again place new order. - Select the same Quotation and do same 50% down payment. Issue: ==== - Next time value should be calculated from due balance not from initial total amount of the quotation. Fix: ==== - Instead of total_amount , now amount_unpaid is used. task- 4231244 Forward-Port-
Original PR description
Steps to reproduce: ==== - Create a quotation and confirm it. - Open Point of Sale. - Load the order in POS. - Choose option Apply a down payment(percentage). - Insert 50. - Do payment and again place new order. - Select the same Quotation and do same 50% down payment. Issue: ==== - Next time value should be calculated from due balance not from initial total amount of the quotation. Fix: ==== - Instead of total_amount , now amount_unpaid is used. task- 4231244 Forward-Port-Of: odoo/odoo#185022 Forward-Port-Of: odoo/odoo#182542
**Current behavior:** Using the DHL delivery shipping module, if you complete a sale order's delivery and then add new product to the order and, again, validate the new delivery, the shipping chatter will be posted in all of the sale order's pickings. **Expected behavior:** The chatter should only be posted in the picking which was actually validated. **Steps to reproduce:** *Install delivery_dhl and l10n_be_hr_payroll* *Swap to My Belgian Company* *Duplicate the My Belgian Compan
Original PR description
**Current behavior:** Using the DHL delivery shipping module, if you complete a sale order's delivery and then add new product to the order and, again, validate the new delivery, the shipping chatter…
**Current behavior:** Using the DHL delivery shipping module, if you complete a sale order's delivery and then add new product to the order and, again, validate the new delivery, the shipping chatter will be posted in all of the sale order's pickings. **Expected behavior:** The chatter should only be posted in the picking which was actually validated. **Steps to reproduce:** *Install delivery_dhl and l10n_be_hr_payroll* *Swap to My Belgian Company* *Duplicate the My Belgian Company partner record, giving it new unique values where necessary (VAT, address, etc.)* 1. Create a new sale order to the copied Belgian company 2. Add some storable product and add DHL EU shipping to the order (only DHL connector working) 3. Confirm the order, and validate the delivery 4. Back on the sale order, add another order line and save 5. Validate the new delivery, see that the delivery chatter is posted on both deliveries **Cause of the issue:** The message is currently logged on `sale_id.picking_ids`. **Fix:** Change the line in question to only log the message on the currently iterated over picking, as well as any relevant, previously created ones (e.g., in a multistep route context). opw-4059145 Forward-Port-Of: odoo/enterprise#72730 Forward-Port-Of: odoo/enterprise#71441
### Steps to reproduce: - Create a product with a bom and an operation op1 - Create and confirm an MO for 1 unit of that product - Go to the shopfloor > on the operation > 3 dots > Add component - Add a component to be consumed in that operation #### > While the componenet was correctly added to the MO and linked to the WO it is not visible on hte shopfloor. ### Cause of the issue: The only moves that are visible on "MrpDisplayRecord"'s are the move that are in `manual_consumption = T
Original PR description
### Steps to reproduce: - Create a product with a bom and an operation op1 - Create and confirm an MO for 1 unit of that product - Go to the shopfloor > on the operation > 3 dots > Add component -…
### Steps to reproduce: - Create a product with a bom and an operation op1 - Create and confirm an MO for 1 unit of that product - Go to the shopfloor > on the operation > 3 dots > Add component - Add a component to be consumed in that operation #### > While the componenet was correctly added to the MO and linked to the WO it is not visible on hte shopfloor. ### Cause of the issue: The only moves that are visible on "MrpDisplayRecord"'s are the move that are in `manual_consumption = True` see: https://github.com/odoo/enterprise/blob/88a092acd261db8f3a8ee1f0cf8174c3d7089472/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L188-L191 However, when a product is added via the `action_add_component` > `add_product`, the `manual_consumption` of the move is computed as if it was added to the MO without being linked to a `bom_line_id`: https://github.com/odoo/enterprise/blob/88a092acd261db8f3a8ee1f0cf8174c3d7089472/mrp_workorder/wizard/additional_product.py#L36-L46 https://github.com/odoo/odoo/blob/2d652f42f63c2501b1a9feb7a4830ea3d7d05f51/addons/mrp/models/mrp_production.py#L1198 As a result the move_raw is added as a manual_consumption = False. ### Note: Thank to Commit eb751b5f861b25205dbb0b0fb90ddcdbbcd10f55 , the issue is not reproducible in 18.0 anymore. This was soved in the same manner: https://github.com/odoo/enterprise/blob/2a0ccbe7058f8d4383a63ed1897945bec3a1cec3/mrp_workorder/models/mrp_production.py#L36-L38 https://github.com/odoo/enterprise/blob/2a0ccbe7058f8d4383a63ed1897945bec3a1cec3/mrp_workorder/models/mrp_production.py#L107-L114 opw-4199156 Forward-Port-Of: odoo/enterprise#72330 Forward-Port-Of: odoo/enterprise#71803
Let's say you have: - One statement line of 3000 USD / 1000 MXN (rate 1:3) - Three invoices of 1000 USD / 500MXN (rate 1:2) => If you reconcile in the bank widget, the statement entry amounts will be divided by 3 ending with 3 lines of 1000 USD and 333.33 MXN leaving a 0.01 unmatched. This can be an issue for the validation of payment EDI for localizations like Mexican one. This PR gives more flexibility to user when dealing when bank reconciliation in multiple currencies by allowing to
Original PR description
Let's say you have: - One statement line of 3000 USD / 1000 MXN (rate 1:3) - Three invoices of 1000 USD / 500MXN (rate 1:2) => If you reconcile in the bank widget, the statement entry amounts will be divided by 3 ending with 3 lines of 1000 USD and 333.33 MXN leaving a 0.01 unmatched. This can be an issue for the validation of payment EDI for localizations like Mexican one. This PR gives more flexibility to user when dealing when bank reconciliation in multiple currencies by allowing to edit amounts on generated exchange moves to allocate this small difference. opw-4128899 Forward-Port-Of: odoo/enterprise#72212
This commit introduces an easy way to recognize "orders" which are intended to settle customer accounts. opw-4185144 Community PR: https://github.com/odoo/odoo/pull/183682 Forward-Port-Of: odoo/enterprise#72726 Forward-Port-Of: odoo/enterprise#71958
Original PR description
This commit introduces an easy way to recognize "orders" which are intended to settle customer accounts. opw-4185144 Community PR: https://github.com/odoo/odoo/pull/183682 Forward-Port-Of: odoo/enterprise#72726 Forward-Port-Of: odoo/enterprise#71958
When generating either a PO or SO from one company to another, currently the commitment date of a Sale Order or the Expected Arrival of a Purchase Order are not used to generate their counter-part in the other company. This means that if you set the expected arrival of the PO in Company A to 10 days in the future, the SO generated in Company B will still try to deliver it as soon as possible, regardless of the date set. Forward-Port-Of: odoo/enterprise#72716 Forward-Port-Of: odoo/enterprise#
Original PR description
When generating either a PO or SO from one company to another, currently the commitment date of a Sale Order or the Expected Arrival of a Purchase Order are not used to generate their counter-part in the other company. This means that if you set the expected arrival of the PO in Company A to 10 days in the future, the SO generated in Company B will still try to deliver it as soon as possible, regardless of the date set. Forward-Port-Of: odoo/enterprise#72716 Forward-Port-Of: odoo/enterprise#72586
Steps to reproduce the bug: - Create a storable product “P1”: - Tracked with SN - Create a BoM: - no need to component - Add an operation “OP1” with steps - Control by product - Create a manufacturing order for one unit of P1 - Confirm the MO - Go to the shop floor and process “OP1” - Validate the MO - Go to the SN of P1 Problem: The quality check smart button is not displayed, while the SN is linked to a QC. opw-4189396 Forward-Port-Of: odoo/e
Original PR description
Steps to reproduce the bug:
- Create a storable product “P1”:
- Tracked with SN
- Create a BoM:
- no need to component
- Add an operation “OP1” with steps
- Control by product
- Create a manufacturing order for one unit of P1
- Confirm the MO
- Go to the shop floor and process “OP1”
- Validate the MO
- Go to the SN of P1
Problem:
The quality check smart button is not displayed, while the SN is linked to a QC.
opw-4189396
Forward-Port-Of: odoo/enterprise#72693*l10n_din5008_account_followup,l10n_din5008_industry_fsm, l10n_din5008_sale_renting Related to https://github.com/odoo/odoo/pull/184790
Original PR description
*l10n_din5008_account_followup,l10n_din5008_industry_fsm, l10n_din5008_sale_renting Related to https://github.com/odoo/odoo/pull/184790
X-original-commit: 698b81c Forward-Port-Of: odoo/enterprise#72859
Original PR description
X-original-commit: 698b81c Forward-Port-Of: odoo/enterprise#72859