Daily updates from Odoo
Tuesday, March 18, 2025
55 changes · 18.0
Enhancements to existing features
Point of Sale orders can now be marked as eligible for mailing, allowing the system to send related communications when needed. This is a small internal improvement that supports better integration with Odoo's messaging features without changing the checkout experience.
Original PR description
Add `_mailing_enabled` flag on `pos.order` model to enable sending it. taskId: 4564577
Point of Sale payment methods linked to bank journals now automatically use the appropriate outstanding account. This reduces manual setup work and helps keep payment accounting consistent.
Original PR description
- Automatically assigns the outstanding account for payment methods using bank journals. task-id: 4600008 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
The self-ordering interface now appears in the language chosen by the user instead of always using the default language. This improves the experience for customers and staff using point-of-sale self-ordering in multilingual environments.
Original PR description
Before this commit, the interface was always shown in the default language. This fix ensures that the UI is displayed according to the user’s selected language. task-4609518 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change prevents the live chat interface from appearing twice on website pages. Visitors now see a single, clean chat entry point, reducing confusion and improving the support experience.
Original PR description
The live chat module the chat hub inside its shadow root. Do avoid duplicate, it used to remove the chat hub from the main components inside `boot_service.js` file. However, since [1], chat hub is added by a service. As a result, the code that used to removed the chat hub is executed too early resulting in two chat hubs being displayed. This PR fixes the issue by patching the service responsible for adding the chat hub to the main components registry. [1]: https://github.com/odoo/odoo/pull/201771
This fix prevents the web interface from crashing when a record contains a related record ID but is missing the related model information. Instead of failing, Odoo now treats the missing relationship as no related record, improving reliability for affected users.
Original PR description
Having a record with set res_id but no res_model doesn't mean much, but we can consider, in web_read, that it means that there is no related record to avoid crashes. opw-4527152
Sales orders with down payments taken through Point of Sale now correctly show the amount already invoiced when creating the final invoice. This prevents staff from seeing a zero value in the invoicing wizard and helps avoid billing confusion or duplicate charges.
Original PR description
Currently when invoicing a SO which has a downpayment made in Pos this downpayment is not reflected in the wizard. Steps to reproduce: ------------------- * Create an SO * Open pos session and make a downpayment for the SO * Close register * Go back to the SO * Deliver the items * Select the invoice > Observation: Amount already invoiced is at 0 Why the fix: ------------ There was a previous fix at the same place previously: https://github.com/odoo/odoo/commit/f613b87c38d208730ba2470e0a26a110c2089b66 However the wizard had changed and instead of showing `amount_to_invoice` we now show `amount_invoiced` opw-4585413
Users who have been granted access to bills of material can now open them without hitting an attachment-related error. This makes custom access setups more reliable without requiring extra development work.
Original PR description
### Steps to reproduce 1. Create a new group 2. Give the group access to the following models: - `mrp.bom` - `mrp.bom.line` - `mrp.routing.workcenter` - `product.document` 3. Create a new menu using studio to access `mrp.bom` directly 4. Create a new user with the newly created group 5. Sign-in with this user and go on a BoM 6. AccessError ### Before this commit: Users without the `mrp.group_mrp_user` group cannot display bills of material, even if we add the necessary access rights. The record loads without issue, but the chatter displays an error when loading the attachments, due to strict group access on the field `attached_on_mrp`. ### After this commit: Remove the group from the field and move it into the view. This allows easier and more flexible access rights to the BoM without writing any custom code. opw-4538532
Fixed a configuration issue in the Indian withholding tax module that was causing automated validation to fail. This helps keep the module stable and prevents avoidable deployment or upgrade blockers.
Original PR description
In this commit-
We fix the [runbot error](https://runbot.odoo.com/runbot/build/76662614)
```py
Please indicate why the always invisible fields are present in the view, or remove the field tag.
Addon: 'l10n_in_withholding'
View: tds_entry_view_form
Fields:
<field name="currency_id" column_invisible="True"/>
```
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prWhen workers add or increase components on a manufacturing order that is already in progress, the related stock transfer is now updated correctly. This helps ensure the right materials are moved to production and reduces the risk of shortages or manual corrections on the shop floor.
Original PR description
### Steps to reproduce: - In the settings, enable multi-step routes. - Set Warehouse to 2-step Manufacturing - Create a BoM with an operation and one move raw: 1 x COMP - Create confirm, plan and…
### Steps to reproduce: - In the settings, enable multi-step routes. - Set Warehouse to 2-step Manufacturing - Create a BoM with an operation and one move raw: 1 x COMP - Create confirm, plan and **start** an MO with that bom. - Through Shop Floor, on your operation > Wheel > add components - Set the quantity of COMP to 10 instead of 1. #### > In the backend, observe that the picking Stock -> Pre-Prod has not been updated ### Cause of the issue: Adding a product already referenced as a raw material via the catalog will trigger a call of the `_update_order_line_info` which will update the demand of the move raw: https://github.com/odoo/odoo/blob/38821f7ffae0aa15c10f3e6972b01aafade6bc60/addons/mrp/models/mrp_production.py#L2895-L2898 https://github.com/odoo/odoo/blob/38821f7ffae0aa15c10f3e6972b01aafade6bc60/addons/mrp/models/mrp_production.py#L2913-L2914 If you did not start the MO, this would run the procurement to update the demand and thus update the picking: https://github.com/odoo/odoo/blob/38821f7ffae0aa15c10f3e6972b01aafade6bc60/addons/mrp/models/stock_move.py#L434-L438 However, since the MO was started the state of the MO is 'in_progress' instead of 'confirmed'. Note: The issue was not reproducible before 18.0. Since adding a component was done via a call that would create and confirm a new move (hence running the procurements): https://github.com/odoo/enterprise/blob/b3febe5a1afd5c1c8fd598db95e8c58fa4131563/mrp_workorder/wizard/additional_product.py#L63-L68 Enterprise: https://github.com/odoo/enterprise/pull/81361 opw-4638371 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where manually created company-specific fields did not keep their company-dependent behavior. Businesses using custom fields can now rely on values being stored separately per company as intended.
Original PR description
The field attribute `company_dependent` is not passed when instanciating manual fields so they do not get created as jsonb columns and lose the company dependent property. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Delivered and received quantities now update correctly for kit products in intercompany sales and purchases. The change ensures transfers through transit locations are counted, giving teams accurate order fulfillment and receipt information.
Original PR description
Problem: The delivered and received quantities on sale order and purchase order lines don’t get updated during intercompany transactions for kit products. This is because the transit location is used…
Problem: The delivered and received quantities on sale order and purchase order lines don’t get updated during intercompany transactions for kit products. This is because the transit location is used instead of the supplier and customer locations. Purpose: Updating the filter to include transit locations will allow stock moves to and from the transit locations to be included in the delivered and received quantities. Steps to Reproduce on Runbot: 1. Enable Inter-Company Transactions for both companies, with Generate Sales Orders, Generate Purchase Orders, and Synchronize Deliveries to your Receipts selected. 2. Create a product and create a kit type bill of materials for it. Remove the company from the bill of materials so it is available for both companies. 3. Create a sale order for this kit product with the customer set to another one of your companies. 4. Confirm the sale order and validate the picking. 5. Observe the delivered quantity on the sale order line is still 0. 6. Switch to the company you sold the kit to. 7. Navigate to the purchase order that was created and confirm it. 8. Validate the picking. 9. Observe the received quantity is still 0. opw-4536144 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The portal signing flow now handles customers or contacts that do not have a standard name without failing. This prevents users from hitting an error when previewing and signing sales quotations for such contacts.
Original PR description
Steps: - install `contacts` and `sale_management` - Open a contact in a form view and add a sub-contact - Don't fill contact name field - Save & Close - Go to Quotations - Select this new contact as Customer (it should have a name like Parent contact, Other Address) - Add any product - Save - Click on `Preview` - Click on `Sign & Pay` - Traceback When there is no signature name, `NameAndSignature` does not set `resetSignature` and `getSignatureImage` on `this.signature`. So after `SignatureForm` initialization, `onMounted` raise a traceback, because it calls directly `this.signature.resetSignature`. This commit adds default functions to `resetSignature` and `getSignatureImage` to prevent the crash. opw-4504223
This fixes an issue where loyalty points could be changed for multiple open POS orders when only one order was paid. Loyalty balances are now updated only for processed orders, preventing incorrect point deductions or awards for customers with draft orders.
Original PR description
Currently, when having multiple orders opened, when validating one, the points will be granted for all opened orders. Steps to reproduce: ------------------- * Have a loyalty progam with * 1point per $ spent * 5% on order in exchange of 200 points * Have 2 customers A and B with 300 each on their loyalty card * Open pos shop * On the order, select customer A, add items and select the reward * Open a new floating order, do the same but for customer B * Pay the order related to customer B * Go in the backend and check the loyalty card of customer A > Observation: Point have been modifyed * Back in the shop, pay order related to cusotmer A * Go in the backend and check the loyalty card of customer A > Observation: points have been modifyed twice Why the fix: ------------ Only processed orders should modify the points available on the loyalty card in the backend. opw-4539274
Exporting products by category with only the external ID field selected no longer causes an error. This keeps product data exports reliable for users who need external IDs for integrations or reporting.
Original PR description
Steps: - Install sales app. - Go to product menu and group list view by category - Export products with only `Product/Product/External ID` Issue: - Traceback. Cause: - Directly try to access `type` key from dict without checking dict contain `type` key or not. Before [this] PR we were checking if it contain type or not. Fix: - Check dictionary contain `type` or not. [this]: https://github.com/odoo/odoo/pull/178214 opw-4585879
This fixes automated web tours so steps using shared helper actions still perform the expected page-unload safety check. It helps make tour execution more reliable and reduces missed issues during automated testing.
Original PR description
If an action is defined in a step with a string (and therefore is an action that comes from tour_helpers) there is no check on the beforeUnload event that is done. In this commit, we fix this. 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
Portal shoppers can now configure combo products that include unpublished configurable items when those items belong to a published combo product. This prevents checkout disruption while keeping unpublished combo items unavailable for direct selection from the cart.
Original PR description
_* : website_sale Steps: - Create a combo product with combo items containing unpublished configurable product - on /shop as portal user add the combo product and try to configure any unpublished product Issue: - access error Cause: - The product configurator doesn't sudo the product which is being configured Fix: - if the product for product_configurator is part of published combo product, it will be sudo'ed opw: 4567008 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix stops Italian electronic invoicing from automatically treating negative invoice lines as discounts. It avoids confusion for businesses where negative lines represent other accounting situations, making invoice exports better match user intent.
Original PR description
Feedbacks given talked about the fact the negative lines were wrong and should be considered as discounts. But that's not the case for every user and is more confusing than anything else. So we remove this logic from Italy. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Spanish SII electronic invoicing demo certificates were replaced because the previous ones had expired and were causing automated validation tests to fail. This keeps the demo/test setup working reliably and aligns certificate naming with related Spanish localization components.
Original PR description
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 fix helps accounting keep zero-value tax lines when they are needed for correct tax repartitioning. It reduces the risk of missing tax details in invoices or accounting entries, supporting more accurate reporting and compliance workflows.
Original PR description
opw-4493544 ## PR note Alternative to https://github.com/odoo/enterprise/pull/80095.
Some internal system labels in the Base module were incorrectly eligible for translation. This fix keeps those strings unchanged across languages, reducing confusion in configuration screens and ensuring consistent technical labels.
Original PR description
The point of sale now keeps the cashier on the payment screen if the session becomes idle during an online payment. This prevents the active order from losing its context, avoiding confusing empty tickets or unfinished orders after the customer completes payment.
Original PR description
Description of the issue/feature this PR addresses: When doing online payment in POS, customer may take some time and the POS may go to idle state. This causes when it goes to idle and back to alive,…
Description of the issue/feature this PR addresses: When doing online payment in POS, customer may take some time and the POS may go to idle state. This causes when it goes to idle and back to alive, it will direct to the first screen. Steps to reproduce: - Create POS & setup POS online payment (use Demo online payment) - Open POS, add a product, go to payment screen, select the online payment method - Let it go to idle state (triggered by useIdleTimer) - Move the cursor, or at least make it back to active state - You'll see the screen be redirected to first screen - Do the payment, it will redirect to TicketScreen with empty order info, and when you click new order the previous one is still hanging there Alternatively take a look at the recording: https://github.com/user-attachments/assets/b8e8ae81-df04-41e0-b122-002413714735 Current behavior before PR: - Because it bounces to first screen, when attempting payment the pos does not have the order state Desired behavior after PR is merged: - Do not redirect if in payment screen, so that order context won't be lost --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When operators add or increase components on a manufacturing order that is already in progress, Odoo now updates the related stock transfer to pre-production. This prevents missing material moves in two-step manufacturing flows and keeps shop floor changes aligned with warehouse operations.
Original PR description
### Steps to reproduce: - In the settings, enable multi-step routes. - Set Warehouse to 2-step Manufacturing - Create a BoM with an operation and one move raw: 1 x COMP - Create confirm, plan and…
### Steps to reproduce: - In the settings, enable multi-step routes. - Set Warehouse to 2-step Manufacturing - Create a BoM with an operation and one move raw: 1 x COMP - Create confirm, plan and **start** an MO with that bom. - Through Shop Floor, on your operation > Wheel > add components - Set the quantity of COMP to 10 instead of 1. #### > In the backend, observe that the picking Stock -> Pre-Prod has not been updated ### Cause of the issue: Adding a product already referenced as a raw material via the catalog will trigger a call of the `_update_order_line_info` which will update the demand of the move raw: https://github.com/odoo/odoo/blob/38821f7ffae0aa15c10f3e6972b01aafade6bc60/addons/mrp/models/mrp_production.py#L2895-L2898 https://github.com/odoo/odoo/blob/38821f7ffae0aa15c10f3e6972b01aafade6bc60/addons/mrp/models/mrp_production.py#L2913-L2914 If you did not start the MO, this would run the procurement to update the demand and thus update the picking: https://github.com/odoo/odoo/blob/38821f7ffae0aa15c10f3e6972b01aafade6bc60/addons/mrp/models/stock_move.py#L434-L438 However, since the MO was started the state of the MO is 'in_progress' instead of 'confirmed'. ### Note: The issue was not reproducible before 18.0. Since adding a component was done via a call that would create and confirm a new move (hence running the procurements): https://github.com/odoo/enterprise/blob/b3febe5a1afd5c1c8fd598db95e8c58fa4131563/mrp_workorder/wizard/additional_product.py#L63-L68 Community: https://github.com/odoo/odoo/pull/201592 opw-4638371
The Documents file viewer now stays correctly positioned when users scroll horizontally, including in grouped views. This prevents misplaced previews and provides a more consistent document viewing experience.
Original PR description
Previously, the file viewer was misaligned when scrolling horizontally, causing incorrect placement. This fix ensures that the file viewer remains properly positioned, even when scrolling, for a consistent viewing experience. Task-4531591
Invoices using external tax calculators can now keep expected zero-value tax lines so they can be updated with the correct externally calculated tax. This prevents missing journal tax lines on fully discounted invoices where tax is still due, improving accounting accuracy for Avatax and similar integrations.
Original PR description
Tax lines are not created in cases where Odoo expects them to be $0 [1]. This is problematic for cases where tax is computed externally and the tax is not in fact $0. There is now no tax line to…
Tax lines are not created in cases where Odoo expects them to be $0 [1]. This is problematic for cases where tax is computed externally and the tax is not in fact $0. There is now no tax line to adjust to the right amount. To reproduce: 1. Configure Avatax 2. Configure the Discount product to have the "Non-taxable product" Avatax category 2. Create an invoice to Azure Interior 3. Select the Avatax fiscal position 3. Add 1 FURN_6667 with default unit price $295 4. Add 1 Discount with unit price -$295 5. Click "Compute Taxes" The invoice is fully discounted but $30.24 tax must still be paid. This is correct. It's reflected in the invoice total, but the tax lines are not in the journal items. `_set_external_taxes()` goes through the summary to set the right tax amounts, but cannot find the line. This solves the issue by using a new hook in accounting that prevents these $0 tax lines from being excluded. opw-4493544 ## PR note Alternative to https://github.com/odoo/enterprise/pull/80095.
The automated test for the signing flow now closes the final confirmation window instead of trying actions that trigger a download or do not fit the test purpose. This prevents timeout failures and keeps the signing process validation stable after related platform changes.
Original PR description
In this commit, we fix the latest step of tour. We can't click on primary or secondary button ... make no sense. As the primary button download the pdf file and there is no test to ensure the file is well downloaded, it make more sense to click on close the modal. With the fix in https://github.com/odoo/odoo/pull/202089 and without the correction, the tour was timeout exceeded.
Fixes subscription churn reporting when a renewed subscription has different discount terms than the original. Churn amounts are now based on previous monthly recurring revenue logs, preventing misleading negative revenue figures after cancellations.
Original PR description
Steps to reproduce: - Install `sale_subscription` - Create a sub with a discount - Confirm and invoice it - Renew the sub without the discount - Confirm the renewal - Remove the discount on the original sub via the shell since it's locked (simulate first year discount removal) - Cancel the renewal Issue: MRR log is now negative, this is due to how the way `amount_signed` is computed during the churn event creation. Recurring monthly is now greater because we deleted the first year discount, which results in negative MRR. https://github.com/odoo/enterprise/blob/5a7b55f9e059c3b54492e184d1e2429779399d08/sale_subscription/models/sale_order_log.py#L174 Solution: Compute `amount_signed` using the sum of the previous logs.
This update resolves several issues affecting accounting, manufacturing, field service, delivery tests, and regional reporting. It also adds Spain's Modelo 130 tax report and improves Belgian CodaBox workflows, helping users get more accurate reports, clearer screens, and fewer posting errors.
Payment notification emails for SEPA Direct Debit are now sent in the customer’s preferred language instead of always defaulting to English. This helps customers receive clearer, localized communication when direct debit payments are processed.
Original PR description
Direct Debit payment notification email was always sent in english regardless of customer language. **Steps to reproduce:** * Configure SDD creditor identifier in accounting settings * Bank Journal should have valid bank account * Customer record have different language than user's language and have valid IBAN bank account * Create Direct Debit mandate for this customer * Pay an invoice for this customer with SDD payment method * Create batch payment for this payment and validate it. * The payment notification email should be sent on payment chatter with wrong language. Video: https://drive.google.com/file/d/1jzlALs4SJRtOA5gPBt_xo0m8r7kpZd_m/view opw-4552438
Code cleanup and technical improvements
This draft pull request appears to reorganize or clean up internal code related to Brol. No specific user-facing changes or affected Odoo modules are provided, so the expected business impact is limited until more details are available.
Miscellaneous changes
Steps to reproduce: - Go to Accounting > Customers > Invoices - Insert the list into a spreadsheet - in any cell, type `=ODOO.LIST(1,1,"company_currency_id")` => the currency is not displayed. The reason is that the `company_currency_id` is fetched as part of a monetary field. When the new `=ODOO.LIST(1,1,"company_currency_id")` is typed, the list data source thinks it has the data, but actually the `dislay_name` is missing. Task: 4633078 --- I confirm I have signed the CLA and
Original PR description
Steps to reproduce: - Go to Accounting > Customers > Invoices - Insert the list into a spreadsheet - in any cell, type `=ODOO.LIST(1,1,"company_currency_id")` => the currency is not displayed. The reason is that the `company_currency_id` is fetched as part of a monetary field. When the new `=ODOO.LIST(1,1,"company_currency_id")` is typed, the list data source thinks it has the data, but actually the `dislay_name` is missing. Task: 4633078 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#200886 Forward-Port-Of: odoo/odoo#200663
- On a view with a company-dependent field with a `many2many_tags` widget, where the `edit_tags` option is set to `true`; - Click on a tag; - Change the company; - Save the tag; - Open the same tag again; A traceback error is displayed. This error occurs because, since [1], when loading the form view the access errors are handled, the company is added to the selected companies and the record is reloaded. The issue is that this cannot be done with a dialog form view, not only is an unreach
Original PR description
- On a view with a company-dependent field with a `many2many_tags` widget, where the `edit_tags` option is set to `true`; - Click on a tag; - Change the company; - Save the tag; - Open the same tag again; A traceback error is displayed. This error occurs because, since [1], when loading the form view the access errors are handled, the company is added to the selected companies and the record is reloaded. The issue is that this cannot be done with a dialog form view, not only is an unreachable action service function is called, but also the dialog is not reopened when reloading. In this commit, we fix this by showing the access error. Forward-Port-Of: odoo/odoo#202222
When manually adding a byproduct to a MO, the warehouse is not set because `default_warehouse_id` is missing from the context. This means that the push move from post-prod to stock is never created and the byproduct is stuck in post-production location. This fix adds the context key in the MO form view. Steps: - Activate routes & by-product in the main settings - Activate manufacturing in 3 steps on the warehouse - Create manufacturing order for a product and add a by-product with a positi
Original PR description
When manually adding a byproduct to a MO, the warehouse is not set because `default_warehouse_id` is missing from the context. This means that the push move from post-prod to stock is never created and the byproduct is stuck in post-production location. This fix adds the context key in the MO form view. Steps: - Activate routes & by-product in the main settings - Activate manufacturing in 3 steps on the warehouse - Create manufacturing order for a product and add a by-product with a positive quantity - Confirm manufacturing order - Pick components - Produce & close MO opw-4620008 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202159 Forward-Port-Of: odoo/odoo#201619
- Create an invoice and set its delivery date to a date other than today. - Generate the cii facturx xml. Under <ram:ActualDeliverySupplyChainEvent>, the date is incorrectly set to today instead of the invoice's delivery date. This commit applies the same treatment as https://github.com/odoo/odoo/commit/dda560005b2372ed8f6fa0cf3fd6c6f7ca0d1fe3 but for account_edi_xml_cii_facturx. opw-4531928 Description of the issue/feature this PR addresses: Current behavior before PR: Desi
Original PR description
- Create an invoice and set its delivery date to a date other than today. - Generate the cii facturx xml. Under <ram:ActualDeliverySupplyChainEvent>, the date is incorrectly set to today instead of the invoice's delivery date. This commit applies the same treatment as https://github.com/odoo/odoo/commit/dda560005b2372ed8f6fa0cf3fd6c6f7ca0d1fe3 but for account_edi_xml_cii_facturx. opw-4531928 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#201680 Forward-Port-Of: odoo/odoo#201230
When creating a partner with an italian VAT number in the backend, the field Codice Fiscale is automatically computed from the Tax ID. However, when a partner is created from the eCommerce of an italian company and the partner's VAT is filled, the Codice Fiscale is not filled in the newly created partner. We extend WebsiteSale to add `computeCodiceFiscale`, which will be triggered when the input field VAT or the select field Country change in the Address form. The function fills the Codice Fi
Original PR description
When creating a partner with an italian VAT number in the backend, the field Codice Fiscale is automatically computed from the Tax ID. However, when a partner is created from the eCommerce of an italian company and the partner's VAT is filled, the Codice Fiscale is not filled in the newly created partner. We extend WebsiteSale to add `computeCodiceFiscale`, which will be triggered when the input field VAT or the select field Country change in the Address form. The function fills the Codice Fiscale if the VAT field is filled, and it starts with 'IT' or the country selected is Italy. Task [link](https://www.odoo.com/odoo/project/967/tasks/4596227) task-4596227 Forward-Port-Of: odoo/odoo#202046 Forward-Port-Of: odoo/odoo#199876
Before this commit, if an IoT connected customer display was activated without a valid HTTPS certificate, it would fail as the IoT box would not trust accessing its own endpoint, due to the request using https://<iot_box_ip>. After this commit, the proxy display instead uses http://localhost, so the certificate is not requirec and the customer display functions as expected. task-4648702 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr For
Original PR description
Before this commit, if an IoT connected customer display was activated without a valid HTTPS certificate, it would fail as the IoT box would not trust accessing its own endpoint, due to the request using https://<iot_box_ip>. After this commit, the proxy display instead uses http://localhost, so the certificate is not requirec and the customer display functions as expected. task-4648702 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202023
Issue ----- When the user clicks on "Continue Shopping" without providing a value for the selected variant, they get a Traceback. Steps to reproduce ----- - Install the ECommerce app - Create an "Att" attribute - Set its' Display Type to "Select" - Add 2 values, 1 & 2 - Set value 1 to Free text - Create a new product "Trace" - Add "Att" as an attribute with values 1 & 2 - Go to the Website - Open the Shop page - Edit the page to add the cart button to pro
Original PR description
Issue ----- When the user clicks on "Continue Shopping" without providing a value for the selected variant, they get a Traceback. Steps to reproduce ----- - Install the ECommerce app - Create an…
Issue
-----
When the user clicks on "Continue Shopping" without providing a value for the
selected variant, they get a Traceback.
Steps to reproduce
-----
- Install the ECommerce app
- Create an "Att" attribute
- Set its' Display Type to "Select"
- Add 2 values, 1 & 2
- Set value 1 to Free text
- Create a new product "Trace"
- Add "Att" as an attribute with values 1 & 2
- Go to the Website
- Open the Shop page
- Edit the page to add the cart button to products & Save
- Click on the cart button of the "Trace" product
- Select the 1 variant
- Click the "Continue Shopping" button without entering a custom value
-> Traceback
Cause
-----
In website_sale_product_configurator, we append to the attribute array even when
there is no custom value provided by the user. When the Python code tries to
access the value, it creates an error because there is no 'custom_value' key.
Solution
-----
Only search for a product template attribute variant when a value is provided.
-----
Ticket:
opw-4535469
Forward-Port-Of: odoo/odoo#197657Since https://github.com/odoo/odoo/pull/103510 , _read_group raises a StopIteration error if there are duplicate groupby specifications. This is because `groupby_terms` has become a `dict` which doesn't allow duplication but we are still looping on the `groupby` list to retrieve columns, leading to raise a StopIteration error when we try to retrieve the last column. Fix this by creating `groupby_terms` with `groupby` instead of values from the dict. Forward-Port-Of: odoo/odoo#202162 Forward-
Original PR description
Since https://github.com/odoo/odoo/pull/103510 , _read_group raises a StopIteration error if there are duplicate groupby specifications. This is because `groupby_terms` has become a `dict` which doesn't allow duplication but we are still looping on the `groupby` list to retrieve columns, leading to raise a StopIteration error when we try to retrieve the last column. Fix this by creating `groupby_terms` with `groupby` instead of values from the dict. Forward-Port-Of: odoo/odoo#202162 Forward-Port-Of: odoo/odoo#202115
Versions -------- - 16.0+ Steps ----- 1. Have a internal user with only Sales: Own Documents access; 2. assign them as salesperson to a sales order with two lines; 3. create an draft invoice for one line; 4. assign admin as salesperson on the invoice; 5. as user, create a draft invoice for the other line (optional); 6. as user, cancel the sales order. Issue ----- If no second draft invoice was created, there's no warning displayed that a draft invoice exists. If one was creat
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Have a internal user with only Sales: Own Documents access; 2. assign them as salesperson to a sales order with two lines; 3. create an draft invoice for one line; 4. assign admin as salesperson on the invoice; 5. as user, create a draft invoice for the other line (optional); 6. as user, cancel the sales order. Issue ----- If no second draft invoice was created, there's no warning displayed that a draft invoice exists. If one was created, trying to cancel will say you're not allowed to read journal entries. You are supposed to get an error when trying to modify journal entries. Cause ----- The cancel wizard doesn't check the order's invoices using sudo. Solution -------- Check the order's invoices using sudo. opw-4554639 Forward-Port-Of: odoo/odoo#201785
**Current behavior before PR:** prior to this PR after posting an attachment, if the attachment box was opened it closes after the reload. **Desired behavior after PR is merged:** this PR addresses this issue by updating the behavior to ensure that the attachment box remains open even after the reload. task-4161477 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201903 Forward-Port-Of: odoo/odoo#179345
Original PR description
**Current behavior before PR:** prior to this PR after posting an attachment, if the attachment box was opened it closes after the reload. **Desired behavior after PR is merged:** this PR addresses this issue by updating the behavior to ensure that the attachment box remains open even after the reload. task-4161477 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#201903 Forward-Port-Of: odoo/odoo#179345
The navigation buttons on the cart were repositioned on the screen for mobile view by setting position to absolute. However this causes an issue if a user adds blocks from the editor below the checkout screen, since disregards the height of the element. To fix this the height of the element is set on the placeholder element to which the navigation buttons are anchored. opw-4498660 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Por
Original PR description
The navigation buttons on the cart were repositioned on the screen for mobile view by setting position to absolute. However this causes an issue if a user adds blocks from the editor below the checkout screen, since disregards the height of the element. To fix this the height of the element is set on the placeholder element to which the navigation buttons are anchored. opw-4498660 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#200821 Forward-Port-Of: odoo/odoo#195305
When producing a MO with components and the components don't have any available quantity, there are no direct link between the MO and the stock move lines of its move_raw_ids. This causes issues when filtering on MO in the Moves History report. This is because the link is only done at the reservation of the SMLs, which can't happen without available qty. This fix ensures that the MO is added at the SML creation. opw-4545828 --- I confirm I have signed the CLA and read the PR guideli
Original PR description
When producing a MO with components and the components don't have any available quantity, there are no direct link between the MO and the stock move lines of its move_raw_ids. This causes issues when filtering on MO in the Moves History report. This is because the link is only done at the reservation of the SMLs, which can't happen without available qty. This fix ensures that the MO is added at the SML creation. opw-4545828 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202055
**Steps to reproduce:** - Install Accounting and l10n_it_edi_withholding - Switch to an Italian company (e.g. IT Company) - Import an electronic Italian invoice (XML) containing an element like: ```xml <DettaglioLinee> <NumeroLinea>2</NumeroLinea> <Descrizione>Contributo ENASARCO</Descrizione> <PrezzoUnitario>0.00</PrezzoUnitario> <PrezzoTotale>0.00</PrezzoTotale> <AliquotaIVA>22.00</AliquotaIVA> <AltriDatiGestionali> <TipoDato>CASSA-PREV</TipoDato>
Original PR description
**Steps to reproduce:** - Install Accounting and l10n_it_edi_withholding - Switch to an Italian company (e.g. IT Company) - Import an electronic Italian invoice (XML) containing an element like:…
**Steps to reproduce:**
- Install Accounting and l10n_it_edi_withholding
- Switch to an Italian company (e.g. IT Company)
- Import an electronic Italian invoice (XML) containing an element like:
```xml
<DettaglioLinee>
<NumeroLinea>2</NumeroLinea>
<Descrizione>Contributo ENASARCO</Descrizione>
<PrezzoUnitario>0.00</PrezzoUnitario>
<PrezzoTotale>0.00</PrezzoTotale>
<AliquotaIVA>22.00</AliquotaIVA>
<AltriDatiGestionali>
<TipoDato>CASSA-PREV</TipoDato>
<RiferimentoTesto>TC07 - ENASARCO</RiferimentoTesto>
<RiferimentoNumero>10.03</RiferimentoNumero>
</AltriDatiGestionali>
</DettaglioLinee>
```
**Issue:**
1) When the above ENASARCO element is present and its unit price is 0, we consider that the ENASARCO tax should be applied to each line. We try to retrieve the percentage of the ENASARCO tax used by computing it from the amount from <RiferimentoNumero> element and the untaxed amount of the invoice.
Then the ENASARCO tax is applied on all the current move lines. However, it is possible that all the move lines have not been imported yet and the tax will not be applied on all the lines.
2) If a ENASARCO tax has been set on a particular move line with a unit price of 0, the tax is applied to all the move lines, but it shouldn't.
3) When a global ENASARCO element is found in a move line, this move line is deleted, which can cause an error if the ENASARCO tax cannot be found in the database because a message is logged with the move line name.
**Solution:**
1-2. In "_l10n_it_edi_import_line" method, we had the ENASARCO tax to the current line by computing the tax rate with the unit price of the line if it is not 0.
Then, in "_l10n_it_edi_import_invoice" method, we parse the XML to check if there was a unique ENASARCO element with an amount and without unit price.
If it is the case, we considered the ENASARCO tax as global. Instead of using the untaxed amount of the invoice to compute the rate of the ENASARCO tax used, we should be able to retrieve the real taxable amount in a <DatiRiepilogo> element.
There should be an element like:
```xml
<DatiRiepilogo>
<AliquotaIVA>22.00</AliquotaIVA>
<ImponibileImporto>117.97</ImponibileImporto>
<Imposta>25.95</Imposta>
<EsigibilitaIVA>I</EsigibilitaIVA>
</DatiRiepilogo>
```
from which we sum all the "ImponibileImporto" values.
3) Only remove the line if the ENASARCO tax is global and can be found in the database.
Ref old fix: https://github.com/odoo/odoo/pull/197456
Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4555966)
opw-4555966
Forward-Port-Of: odoo/odoo#202044
Forward-Port-Of: odoo/odoo#200774Versions -------- - 17.0+ Enterprise PR: https://github.com/odoo/enterprise/pull/81461 Steps ----- 1. Have a internal user with only Sales: Own Documents access; 2. assign the user to a subscription; 3. as admin, create an invoice for the subscription; 4. assign yoursel as salesman on the invoice; 5. confirm the invoice; 6. log in as the other user; 7. try to create an invoice for the subscription assigned to you. Issue ----- Access error. Cause ----- Unlike the the oth
Original PR description
Versions -------- - 17.0+ Enterprise PR: https://github.com/odoo/enterprise/pull/81461 Steps ----- 1. Have a internal user with only Sales: Own Documents access; 2. assign the user to a subscription;…
Versions -------- - 17.0+ Enterprise PR: https://github.com/odoo/enterprise/pull/81461 Steps ----- 1. Have a internal user with only Sales: Own Documents access; 2. assign the user to a subscription; 3. as admin, create an invoice for the subscription; 4. assign yoursel as salesman on the invoice; 5. confirm the invoice; 6. log in as the other user; 7. try to create an invoice for the subscription assigned to you. Issue ----- Access error. Cause ----- Unlike the the other `_compute_amount_*` methods of sale.order, `_compute_amount_invoiced` isn't computed with `sudo`. This isn't an issue when just using `sale`, as it's computed with only sale order fields, but if an override attempts to check `invoice_ids`, it will throw an error if it has an invoice you don't have access to. Solution -------- In `sale`: - The bring the compute method in line with other `_compute_amount_*` methods, add `compute_sudo=True` to the `amount_invoiced` field. In `sale_subscription`: - Add a test to prevent regression. opw-4554639 Forward-Port-Of: odoo/odoo#201768
Currently if a user has "Read-Only" access in Accounting and any level of access in Timesheets (even "All Documents"), they won’t be able to export journal item analytical lines. This is inconsistent, as having more access in Timesheets should not restrict access in Accounting. Steps to Reproduce: - Create an invoice with analytic distribution. - Go to Journal Items. - Export the journal item, including analytic lines fields Issue: The user will not be able to export the data from thes
Original PR description
Currently if a user has "Read-Only" access in Accounting and any level of access in Timesheets (even "All Documents"), they won’t be able to export journal item analytical lines. This is…
Currently if a user has "Read-Only" access in Accounting and any level of access in Timesheets (even "All Documents"), they won’t be able to export journal item analytical lines. This is inconsistent, as having more access in Timesheets should not restrict access in Accounting. Steps to Reproduce: - Create an invoice with analytic distribution. - Go to Journal Items. - Export the journal item, including analytic lines fields Issue: The user will not be able to export the data from these fields. It occurs because timesheet users are restricted by ir-rules that allows access only to users owning the record or associated with a related project/task https://github.com/odoo/odoo/blob/34947c01623a9fc753197bd55d6121d9c6fa682f/addons/hr_timesheet/security/hr_timesheet_security.xml#L52 Solution is to add an ir-rule in account to allow read access to read-only users Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4586096) opw-4586096 Forward-Port-Of: odoo/odoo#202080 Forward-Port-Of: odoo/odoo#201365
Current behavior before PR: `isTalking` status displayed who was talking even when the user had deafened themselves. Desired behavior after PR is merged: `isTalking` status no longer shows who is talking if the user has deafened themselves. Task-id:[4609755](https://www.odoo.com/odoo/project.task/4609755) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#200875
Original PR description
Current behavior before PR: `isTalking` status displayed who was talking even when the user had deafened themselves. Desired behavior after PR is merged: `isTalking` status no longer shows who is talking if the user has deafened themselves. Task-id:[4609755](https://www.odoo.com/odoo/project.task/4609755) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#200875
When sending an invoice to Viettel, we currently raise an error in Odoo if the address information of the customer is not set. If the VAT is not set, it is the api raising an error. In both case, the information is optional, and we should be able to invoice. For the address information the validation in Odoo is removed, and for the VAT the json will now contain '' if it is not set instead of False Also make sure that the json file is attached to the chatter if it has been generate
Original PR description
When sending an invoice to Viettel, we currently raise an error in Odoo if the address information of the customer is not set. If the VAT is not set, it is the api raising an error. In both case, the information is optional, and we should be able to invoice. For the address information the validation in Odoo is removed, and for the VAT the json will now contain '' if it is not set instead of False Also make sure that the json file is attached to the chatter if it has been generated for audit purpose task-4405507 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196547
Currently, a traceback is occurring when the user clicks the `Done & Schedule Next` button without having the due date. To reproduce this issue: 1) Install Sales 2) Open any sale order and in the chatter, schedule an activity 3) Remove the `Due date` and click the `Done & Schedule Next` button Error:- ``` TypeError: unsupported operand type(s) for +: 'NoneType' and 'relativedelta' ``` This traceback is occurring because `date_deadline` is not a required field. So the user can re
Original PR description
Currently, a traceback is occurring when the user clicks the `Done & Schedule Next` button without having the due date. To reproduce this issue: 1) Install Sales 2) Open any sale order and in the…
Currently, a traceback is occurring when the user clicks the `Done & Schedule Next` button without having the due date. To reproduce this issue: 1) Install Sales 2) Open any sale order and in the chatter, schedule an activity 3) Remove the `Due date` and click the `Done & Schedule Next` button Error:- ``` TypeError: unsupported operand type(s) for +: 'NoneType' and 'relativedelta' ``` This traceback is occurring because `date_deadline` is not a required field. So the user can remove it. If there is no `date_deadline`, the context contains key with no value from the line below. https://github.com/odoo/odoo/blob/da7f89d5683c0718644b5ca9fdf5adb86b54fb81/addons/mail/models/mail_activity.py#L510 But here we are only checking the presence of the key in the context; If yes, the base is calculated based on the context value(None in this case). https://github.com/odoo/odoo/blob/da7f89d5683c0718644b5ca9fdf5adb86b54fb81/addons/mail/models/mail_activity.py#L204-L208 This will lead to the above traceback. sentry-6347875218 Forward-Port-Of: odoo/odoo#201674 Forward-Port-Of: odoo/odoo#199915
Adds easier management of foreign partners that are both suppliers and customers by automatically selecting the correct generic TIN if the one set on the partner is also a generic TIN. Also adds some logic that allows to tag a credit note as 'refund' if it matches some conditions. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199150
Original PR description
Adds easier management of foreign partners that are both suppliers and customers by automatically selecting the correct generic TIN if the one set on the partner is also a generic TIN. Also adds some logic that allows to tag a credit note as 'refund' if it matches some conditions. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199150
Ensure unique line IDs when the same country appears in both sales and purchase sections of the OSS report. Steps to reproduce: - Create a Belgium company - Install OSS Reports - Update OSS Fiscal Position (Refresh tax mapping in settings) - Duplicate an OSS tax (e.g., 20.0% FR VAT) - Change its type to Purchase - Add it to the FR fiscal position - Create an invoice with a tax 20% FR VAT (Sales) - Create a bill with a tax 20% FR VAT (Purchase) - Try to open OSS Sales report in tax re
Original PR description
Ensure unique line IDs when the same country appears in both sales and purchase sections of the OSS report. Steps to reproduce: - Create a Belgium company - Install OSS Reports - Update OSS Fiscal Position (Refresh tax mapping in settings) - Duplicate an OSS tax (e.g., 20.0% FR VAT) - Change its type to Purchase - Add it to the FR fiscal position - Create an invoice with a tax 20% FR VAT (Sales) - Create a bill with a tax 20% FR VAT (Purchase) - Try to open OSS Sales report in tax return - An error occurs due to duplicate line IDs Issue originates from `append_country_and_taxes_lines`, which appends a new line with incorrect markup (using new line markup instead of the last line markup). opw-4629989 Forward-Port-Of: odoo/enterprise#81641
**Problem**: When archiving the only pos config linked to the preparation display, the configuration of the preparation display shows that no pos config is linked to it (it's linked to all pos configs). However, when pos config starts, it doesn't load the preparation display on _load_model as the domain for it is to load when the specific pos config is linked, or no configs are linked. This confuses the clients as the archived pos will not be seen in the preparation display configuration. Ad
Original PR description
**Problem**: When archiving the only pos config linked to the preparation display, the configuration of the preparation display shows that no pos config is linked to it (it's linked to all pos…
**Problem**:
When archiving the only pos config linked to the preparation display, the configuration of the preparation display shows that no pos config is linked to it (it's linked to all pos configs). However, when pos config starts, it doesn't load the preparation display on _load_model as the domain for it is to load when the specific pos config is linked, or no configs are linked. This confuses the clients as the archived pos will not be seen in the preparation display configuration.
Additionally, there is another issue related to live synchronization in version 18.0. When clicking the "Order" button, the request is sent only if the file is linked to a preparation display see here https://github.com/odoo/enterprise/blob/18.0/pos_preparation_display/static/src/override/point_of_sale/pos_store.js#L37.
As a result, if the display is linked to an archived POS config, live synchronization will not function correctly.
- How to reproduce:
* Assign one pos config to preparation display
* Archive the assigned config
* Open another pos config.
* Kitchen display is not loaded
**Solution**:
Change the domain to include displays with no configs, or with no active config.
opw-4504623
Forward-Port-Of: odoo/enterprise#81251
Forward-Port-Of: odoo/enterprise#80117To reproduce the issue: 1) Install l10n_es_reports 2) Configure the taxes WHI 15% and IVA 21% purchase taxes to include analytic (checkbox on the form view) 3) Create an invoice with two lines of 100€, so that - both lines use both IVA21% and WHI 1% taxes - one of those lines defines an anlaytic distribution while the other doesn't 4) Open the generic tax report, and generate the VAT Record Books XLSX export ===> In that file, the amount of withholding is 15€. It should be 30€
Original PR description
To reproduce the issue:
1) Install l10n_es_reports
2) Configure the taxes WHI 15% and IVA 21% purchase taxes to include analytic (checkbox on the form view)
3) Create an invoice with two lines of 100€, so that
- both lines use both IVA21% and WHI 1% taxes
- one of those lines defines an anlaytic distribution while the other doesn't
4) Open the generic tax report, and generate the VAT Record Books XLSX export
===> In that file, the amount of withholding is 15€. It should be 30€.
The same issue can be reproduced for surcharge taxes, in the same way.
This is due to the fact different analytic distributions between base lines will trigger the creation of different tax lines for the same tax (one for each distribution). The code handling the export "saw" both lines, but ovewrote the total instead of summing all the values.
opw-4471253
Forward-Port-Of: odoo/enterprise#81375- Sign > Documents > Click on any of the Kanban record - Reload the view (either reload the browser, or activate the debug, or change to dark mode on the user menu). Before this commit, on reloading the sign document page user was redirected back to kanban view. This occurs because, the client action 'sign.Document' requires attributes which are found in the context - { id, token, create_uid, state, request_item_states} that was lost when reloading. Now, { id, token, create_uid, state,
Original PR description
- Sign > Documents > Click on any of the Kanban record
- Reload the view (either reload the browser, or activate
the debug, or change to dark mode on the user menu).
Before this commit, on reloading the sign document page user was redirected back to kanban view. This occurs because, the client action 'sign.Document' requires attributes which are found in the context - { id, token, create_uid, state, request_item_states} that was lost when reloading.
Now, { id, token, create_uid, state, request_item_states} is put in the query string of the URL, in that way, when reloading, the client action 'sign.Document' will have the needed attributes. Note that, this is also the behavior of the base_import 'ImportAction' action [1].
task-4391729
[1] : https://github.com/odoo/odoo/pull/182744/commits/a6801ce4aa65cd023e2a762ab5c42755a4599c95
Forward-Port-Of: odoo/enterprise#77399Versions -------- - 17.0+ Community PR: https://github.com/odoo/odoo/pull/201768 Steps ----- 1. Have a internal user with only Sales: Own Documents access; 2. assign the user to a subscription; 3. as admin, create an invoice for the subscription; 4. assign yoursel as salesman on the invoice; 5. confirm the invoice; 6. log in as the other user; 7. try to create an invoice for the subscription assigned to you. Issue ----- Access error. Cause ----- Unlike the the other `_c
Original PR description
Versions -------- - 17.0+ Community PR: https://github.com/odoo/odoo/pull/201768 Steps ----- 1. Have a internal user with only Sales: Own Documents access; 2. assign the user to a subscription; 3. as…
Versions -------- - 17.0+ Community PR: https://github.com/odoo/odoo/pull/201768 Steps ----- 1. Have a internal user with only Sales: Own Documents access; 2. assign the user to a subscription; 3. as admin, create an invoice for the subscription; 4. assign yoursel as salesman on the invoice; 5. confirm the invoice; 6. log in as the other user; 7. try to create an invoice for the subscription assigned to you. Issue ----- Access error. Cause ----- Unlike the the other `_compute_amount_*` methods of sale.order, `_compute_amount_invoiced` isn't computed with `sudo`. This isn't an issue when just using `sale`, as it's computed with only sale order fields, but if an override attempts to check `invoice_ids`, it will throw an error if it has an invoice you don't have access to. Solution -------- In `sale`: - Bring the compute method in line with other `_compute_amount_*` methods, add `compute_sudo=True` to the `amount_invoiced` field. In `sale_subscription`: - Add a test to prevent regression. opw-4554639 Forward-Port-Of: odoo/enterprise#81461
it could happen that odoo does not receive DIAN's response because of internet loss while the document is being sent to dian for example. The move form will then display the edi state as being rejected while in reality DIAN has successfully processed the move. If the user where to send the move to DIAN again, they would get an error message saying the move has already been processed. the fix: when the move is sent to DIAN again after getting out of sync, DIAN will send the error explained abo
Original PR description
it could happen that odoo does not receive DIAN's response because of internet loss while the document is being sent to dian for example. The move form will then display the edi state as being rejected while in reality DIAN has successfully processed the move. If the user where to send the move to DIAN again, they would get an error message saying the move has already been processed. the fix: when the move is sent to DIAN again after getting out of sync, DIAN will send the error explained above which contains the identifier of the move. We now save this identifier and use it in the automatic GetStatus call to get odoo and DIAN back in sync. ticket: 4569829 Forward-Port-Of: odoo/enterprise#81350
…rate The current implementation to handle the rate for multi-currency entries in CAMT creates problems when fetching the source rate from the file: the source rate can be taken from the SrcCcy or the TrgtCcy node, which should be compared with the source currency and target currency respectively. It is not done that way and is too restrictive (when the SrcCcy is found, it is always compared to the target currency, which leads to an incorrect transaction amount). Moreover, when the currenc
Original PR description
…rate The current implementation to handle the rate for multi-currency entries in CAMT creates problems when fetching the source rate from the file: the source rate can be taken from the SrcCcy or the TrgtCcy node, which should be compared with the source currency and target currency respectively. It is not done that way and is too restrictive (when the SrcCcy is found, it is always compared to the target currency, which leads to an incorrect transaction amount). Moreover, when the currency conversion introduces a exchange loss/gain, it is put back on the largest transaction of the entry. opw-4393164 Forward-Port-Of: odoo/enterprise#80622 Forward-Port-Of: odoo/enterprise#76828