Friday, May 16, 2025
43 changes · saas-18.1
Enhancements to existing features
Resolved issues and error corrections
This fixes how validity dates are read when an Indian e-waybill is generated through IRN. Businesses get the correct “valid until” date shown and processed, reducing compliance and logistics errors.
Original PR description
Before this commit: We did not handle the date format in case the ewaybill is generated through IRN. After this commit: We handle the format where the ewaybill is generated through IRN --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
moving it to the module mrp_subcontracting_purchase is the correct module, as it depends on the override of _get_resupply_availability happening in mrp_subcontracting_purchase module accorinding to this PR (https://github.com/odoo/odoo/pull/144702/files#diff-54bc40f604ca24cec75d6f7473d21d1d2d0300576456026fe63164daf7cd5149) and fails as a single app test in mrp_subcontracting build_error-163126 Forward-Port-Of: odoo/odoo#206513 Forward-Port-Of: odoo/odoo#206078
Original PR description
moving it to the module mrp_subcontracting_purchase is the correct module, as it depends on the override of _get_resupply_availability happening in mrp_subcontracting_purchase module accorinding to this PR (https://github.com/odoo/odoo/pull/144702/files#diff-54bc40f604ca24cec75d6f7473d21d1d2d0300576456026fe63164daf7cd5149) and fails as a single app test in mrp_subcontracting build_error-163126 Forward-Port-Of: odoo/odoo#206513 Forward-Port-Of: odoo/odoo#206078
AttachedDocuments are a wrapper filetype in the UBL 2.0/2.1 specification that allows for multiple documents to be bundled together. Colombia uses it as a way to return back values from the EDI but it is in the standard and can therefore be used by any UBL 2.0/2.1 compliant system. To be able to parse the documents inside correctly, we must obtain the original record which is stored in the outermost Attachment node either under the EmbeddedDocumentBinaryObject element or the ExternalReference
Original PR description
AttachedDocuments are a wrapper filetype in the UBL 2.0/2.1 specification that allows for multiple documents to be bundled together. Colombia uses it as a way to return back values from the EDI but it is in the standard and can therefore be used by any UBL 2.0/2.1 compliant system. To be able to parse the documents inside correctly, we must obtain the original record which is stored in the outermost Attachment node either under the EmbeddedDocumentBinaryObject element or the ExternalReference/Description node. Once we find it we send it to the normal decoder process. Specification: https://docs.oasis-open.org/ubl/os-UBL-2.1/mod/summary/reports/UBL-AttachedDocument-2.1.html task-4299222 Forward-Port-Of: odoo/odoo#208953
Consumption taxes are required for alcohol and other products, withthe POS module for Colombia coming out soon it's necessary to support such taxes out of the box for when it's released. A migration script has been added to automatically load these new taxes and accounts that will be necessary. task-4634313 Enterprise PR: https://github.com/odoo/enterprise/pull/84717 Forward-Port-Of: odoo/odoo#208500
Original PR description
Consumption taxes are required for alcohol and other products, withthe POS module for Colombia coming out soon it's necessary to support such taxes out of the box for when it's released. A migration script has been added to automatically load these new taxes and accounts that will be necessary. task-4634313 Enterprise PR: https://github.com/odoo/enterprise/pull/84717 Forward-Port-Of: odoo/odoo#208500
After this commit, the full width of the Activities column in a list view will be clickable, for ease of use. task-4525830 Forward-Port-Of: odoo/odoo#210169
Original PR description
After this commit, the full width of the Activities column in a list view will be clickable, for ease of use. task-4525830 Forward-Port-Of: odoo/odoo#210169
Description of the issue/feature this PR addresses: Task ID: 4636082 Current Behavior before PR: - When printing an invoice with a currency that is different than the company's currency. The amount value of each line is only printed in the invoice's currency and not the company's currency. - As per the FTA article 59, the line amount should also be expressed in AED. - The tax excluded amount was also always printed regardless of the company's setting. (something that was fixed in https:
Original PR description
Description of the issue/feature this PR addresses: Task ID: 4636082 Current Behavior before PR: - When printing an invoice with a currency that is different than the company's currency. The amount value of each line is only printed in the invoice's currency and not the company's currency. - As per the FTA article 59, the line amount should also be expressed in AED. - The tax excluded amount was also always printed regardless of the company's setting. (something that was fixed in https://www.odoo.com/odoo/project.task/4625855?debug=1 but there seems to be no intention to backport this to 18.0). Desired behavior after PR is merged: - Add a new column to print the line amount in the company's currency if the invoice has a different currency than the company. - Print tax excluded/include amount based on company's setting. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207633
This commit removes a useless break line added to the end of chat ratign. Break line is used to put the reason on a different line than the rating smiley but is useless when no reason is passed. task-4791376 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#209776 Forward-Port-Of: odoo/odoo#20
Original PR description
This commit removes a useless break line added to the end of chat ratign. Break line is used to put the reason on a different line than the rating smiley but is useless when no reason is passed. task-4791376 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#209776 Forward-Port-Of: odoo/odoo#209571
Before this commit: - In the bank reconciliation model form view, under the "Counterpart Items" section, the "Taxes" column displayed only the tax name. - Taxes were not distinguished between Sales and Purchase types, making it difficult to identify their type. After this commit: - The "Taxes" column now displays the tax type beside the tax name, making it easier to distinguish between them. task-4752604 Forward-Port-Of: odoo/odoo#207870
Original PR description
Before this commit: - In the bank reconciliation model form view, under the "Counterpart Items" section, the "Taxes" column displayed only the tax name. - Taxes were not distinguished between Sales and Purchase types, making it difficult to identify their type. After this commit: - The "Taxes" column now displays the tax type beside the tax name, making it easier to distinguish between them. task-4752604 Forward-Port-Of: odoo/odoo#207870
Versions -------- - 17.0+ Steps ----- 1. Set up a Next Order Coupon program; 2. add Free Shipping as a reward; 3. create a coupon for current user with enough points to claim reward; 4. add a product to your cart; 5. go to check out; 6. claim Free Shipping. Issue ----- Free Shipping is still displayed as claimable Cause ----- The `_get_claimable_and_showable_rewards` method does not factor in whether the rewards have already been claimed on the current order. For discoun
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Set up a Next Order Coupon program; 2. add Free Shipping as a reward; 3. create a coupon for current user with enough points to claim reward; 4. add a product to your cart; 5. go to check out; 6. claim Free Shipping. Issue ----- Free Shipping is still displayed as claimable Cause ----- The `_get_claimable_and_showable_rewards` method does not factor in whether the rewards have already been claimed on the current order. For discounts & free products, this isn't an issue, as claiming them will use as many points as possible, meaning there's no points left to claim more, but free shipping can only be claimed once per order. Solution -------- Filter out rewards that have already been claimed. opw-4784359 Forward-Port-Of: odoo/odoo#209739 Forward-Port-Of: odoo/odoo#209508
The Customer Lot Report displays all SN delivered to a partner. To do so, the SQL query is mainly based on SML. The problem is that it only considers SML linked to a picking through the field `picking_id`. However, this field is not required and it is possible to have an SML without any value for that field, still linked to a picking through its SM (RPC, data import...) This commit therefore add a `join` on the SM, so we can find the picking in all cases. Moreover, [1] has been merge
Original PR description
The Customer Lot Report displays all SN delivered to a partner. To do so, the SQL query is mainly based on SML. The problem is that it only considers SML linked to a picking through the field `picking_id`. However, this field is not required and it is possible to have an SML without any value for that field, still linked to a picking through its SM (RPC, data import...) This commit therefore add a `join` on the SM, so we can find the picking in all cases. Moreover, [1] has been merged to get the customer of a dropshipping (tldr: the partner of a dropship is the supplier). However, now that we have the SM of the SML, we can simplify a lot the code and rather use the partner of the SM: https://github.com/odoo/odoo/blob/24235855d01e52df314479e0437c0308864edc23/addons/stock/models/stock_move.py#L95-L99 [1] https://github.com/odoo/odoo/commit/bace02e0355f3ed657421ca452af0b17ef4886bc OPW-4559129 Forward-Port-Of: odoo/odoo#209884
Tests were failing because of smooth scrolling. runbot-103421 Forward-Port-Of: odoo/odoo#210009
Original PR description
Tests were failing because of smooth scrolling. runbot-103421 Forward-Port-Of: odoo/odoo#210009
After 18.0, the Product form has changed and the Purchase taxes field was moved on the main tab. By doing so, we removed the "Purchase" checkbox (as the tab would have been empty), but by doing so we lost the ability to tell that a product can be purchased or not. Now when account is installed we make the checkbox visible on the Product form even without the Purchase app, the tab will then only be visible if both the Purchase app is installed and the checkbox is ticked. task- 4742975 For
Original PR description
After 18.0, the Product form has changed and the Purchase taxes field was moved on the main tab. By doing so, we removed the "Purchase" checkbox (as the tab would have been empty), but by doing so we lost the ability to tell that a product can be purchased or not. Now when account is installed we make the checkbox visible on the Product form even without the Purchase app, the tab will then only be visible if both the Purchase app is installed and the checkbox is ticked. task- 4742975 Forward-Port-Of: odoo/odoo#207089
When the test DB includes all demo data, sometimes the corrected tours took the wrong products This commit makes the selection of products in test tours more precise, just as it is the case for some other selectors. runbot-error-161984 runbot-error-108034 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-Por
Original PR description
When the test DB includes all demo data, sometimes the corrected tours took the wrong products This commit makes the selection of products in test tours more precise, just as it is the case for some other selectors. runbot-error-161984 runbot-error-108034 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#210118
Commit d69541efbe3 added `cumulatedStart` property on charts but the property was not exported. Steps to reproduce: - open CRM - switch to the graph view - Check the "cumulative" checkbox - Group by create date: month - Filter on March and April (the last 2 months in the filter) - insert in spreadsheet - reload => the chart data changed. It now includes historical data Task-4792009 Description of the issue/feature this PR addresses: Current behavior before PR: Desired be
Original PR description
Commit d69541efbe3 added `cumulatedStart` property on charts but the property was not exported. Steps to reproduce: - open CRM - switch to the graph view - Check the "cumulative" checkbox - Group by create date: month - Filter on March and April (the last 2 months in the filter) - insert in spreadsheet - reload => the chart data changed. It now includes historical data Task-4792009 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#209976 Forward-Port-Of: odoo/odoo#209637
For proper provision management we introduce accounts 2350 and 2351 task-4797323 Forward-Port-Of: odoo/odoo#210062
Original PR description
For proper provision management we introduce accounts 2350 and 2351 task-4797323 Forward-Port-Of: odoo/odoo#210062
__Current behavior before commit:__ The QR code on the payment page is cropped when the Pending Message of the payment provider has a long line. __Description of the fix:__ Set `flex-shrink-0` to the QR code card so it doesn't shrink. __Steps to show the cropped QR code:__ 1. Install sale_management and website 2. Set company currency to EUR 3. Enable QR Codes under Customer Payments in Settings 4. Enable Online Payment (and disable Online Signature) under Quotations & Orders 5. In
Original PR description
__Current behavior before commit:__ The QR code on the payment page is cropped when the Pending Message of the payment provider has a long line. __Description of the fix:__ Set `flex-shrink-0` to the QR code card so it doesn't shrink. __Steps to show the cropped QR code:__ 1. Install sale_management and website 2. Set company currency to EUR 3. Enable QR Codes under Customer Payments in Settings 4. Enable Online Payment (and disable Online Signature) under Quotations & Orders 5. In Payment Providers, install SEPA Direct Debit. Select Test mode, check Enable QR Codes, and publish it. 6. **In Messages tab, put a very long line as Pending Message** 7. Go to the Journal "Bank" and set a random IBAN as Account number 8. Create a new Quote with a non 0 price and click on Preview and pay the order 9. The QR code is cropped opw-4735003 Forward-Port-Of: odoo/odoo#209686
### Issue In project sharing, tasks in the "Done" and "Approved" stages were not shown with distinct progress in the Kanban progress bar. As a result, users were unable to identify the task status easily. ### Reason: The color class was set incorrectly. ### Fix: We have updated the color class in this commit to correctly reflect the task stages. issue-https://github.com/odoo/odoo/commit/1a44b849970d3e39111a99ea35db5b586b184dd3 ### Steps to Reproduce: - Create a projec
Original PR description
### Issue
In project sharing, tasks in the "Done" and "Approved" stages were not shown with distinct progress in the Kanban progress bar. As a result, users were unable to identify the task status easily.
### Reason:
The color class was set incorrectly.
### Fix:
We have updated the color class in this commit to correctly reflect the task stages.
issue-https://github.com/odoo/odoo/commit/1a44b849970d3e39111a99ea35db5b586b184dd3
### Steps to Reproduce:
- Create a project with 2 tasks:
- Task 1 in the "Done" stage
- Task 2 in the "Approved" stage
- Share the project with a portal user
- Open the project in the portal
- Navigate to the project sharing Kanban view and check the progress bar
task-4551177
Forward-Port-Of: odoo/odoo#206031Scenario: - add a cover snippet with 100% height at the top of the page - open the page on a mobile (eg. safari on iOS) - scroll down the page Result: there is a vertical jittering of the content of cover snippet when going down. Cause: we are setting the size in pixel to {viewport height} - {height of stuff (menu, logged in user bar, ...)} but the mobile browser changes the viewport height when going down and hiding the address bar UI, so the fixed pixel height is only updated wh
Original PR description
Scenario:
- add a cover snippet with 100% height at the top of the page
- open the page on a mobile (eg. safari on iOS)
- scroll down the page
Result: there is a vertical jittering of the content of cover snippet
when going down.
Cause: we are setting the size in pixel to {viewport height} - {height
of stuff (menu, logged in user bar, ...)} but the mobile browser changes
the viewport height when going down and hiding the address bar UI, so
the fixed pixel height is only updated when the code is called again
instead of being adapted smoothly.
Fix: set the height of the cover using 100dvh minus the size of the
content, so the height is increased/decreased smoothly by the
application of CSS.
opw-4575726
Forward-Port-Of: odoo/odoo#209926The selectionchange event is triggered in the next microtask tick. Any test that relies on the effect of a selectionchange but does not explicitely wait for it before running its step function or checking its expected result is likely to fail non-deterministically on newer versions of Chrome. This is basically a generalized version of the fix at https://github.com/odoo/odoo/pull/206969. Forward-Port-Of: odoo/odoo#209907 Forward-Port-Of: odoo/odoo#209844
Original PR description
The selectionchange event is triggered in the next microtask tick. Any test that relies on the effect of a selectionchange but does not explicitely wait for it before running its step function or checking its expected result is likely to fail non-deterministically on newer versions of Chrome. This is basically a generalized version of the fix at https://github.com/odoo/odoo/pull/206969. Forward-Port-Of: odoo/odoo#209907 Forward-Port-Of: odoo/odoo#209844
Some services or applications (Outlook, Google Messages) display previews of links sent through messages or email. In an effort to strengten user privacy, these services fetch the previews from their own servers rather than from the user's device. Since these services' requests had not been added to the list of known bot identifiers, they generate parasite "clicks" which don't match their user. This commit adds identifiers for the Outlook and Google Messages service requests to the l
Original PR description
Some services or applications (Outlook, Google Messages) display previews of links sent through messages or email. In an effort to strengten user privacy, these services fetch the previews from their own servers rather than from the user's device. Since these services' requests had not been added to the list of known bot identifiers, they generate parasite "clicks" which don't match their user. This commit adds identifiers for the Outlook and Google Messages service requests to the list of known bot IDs, thereby preventing the parasite clicks from generating. task-3672491 Forward-Port-Of: odoo/odoo#200148 Forward-Port-Of: odoo/odoo#167799
To reproduce: ============= - have an employee with a working schedule of night shifts like 18:00 to 00:00 break to 01:00 then continue to 03:00 - create payslip for this employee for January 2025 - print the payslip, the working hours will be 183.9936 The problem: ============ 00:00 is represented as 23:59:59.99999 in python, that missing microsecond impacts the computation of the duration of the work entry. The solution: ============= round the total seconds opw-4702410 ---
Original PR description
To reproduce: ============= - have an employee with a working schedule of night shifts like 18:00 to 00:00 break to 01:00 then continue to 03:00 - create payslip for this employee for January 2025 - print the payslip, the working hours will be 183.9936 The problem: ============ 00:00 is represented as 23:59:59.99999 in python, that missing microsecond impacts the computation of the duration of the work entry. The solution: ============= round the total seconds opw-4702410 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208811
**Steps to reproduce:** - Install account - Go to "Invoicing / Configuration / Accounting / Journals" - Create a "Credit Card" type journal - In "Incoming Payments" tab (or "Outgoing Payments"), try to add a line **Issue:** There is no option for "Payment Method" select field. If the default "Manual Payment" line is removed, it's not possible to add it again. **Cause:** The list of available payment methods for credit card journal is empty. The method that is computing the available
Original PR description
**Steps to reproduce:** - Install account - Go to "Invoicing / Configuration / Accounting / Journals" - Create a "Credit Card" type journal - In "Incoming Payments" tab (or "Outgoing Payments"), try to add a line **Issue:** There is no option for "Payment Method" select field. If the default "Manual Payment" line is removed, it's not possible to add it again. **Cause:** The list of available payment methods for credit card journal is empty. The method that is computing the available payment methods is always returning False for credit card journals, but it should not. **Solution:** Compute the available payment methods normally as it is the case for bank and cash journals. opw-4754110 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209438
Fixes an issue where copying an account report correctly update the formulas of the report but not the subformulas. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209742 Forward-Port-Of: odoo/odoo#208071
Original PR description
Fixes an issue where copying an account report correctly update the formulas of the report but not the subformulas. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209742 Forward-Port-Of: odoo/odoo#208071
Fixes an issue when issuing self-billed invoices to the platform. So far we have been using Odoo's bill name as ID, but we should instead use the bill reference (if set) to use the supplier number. task-4777585 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208721
Original PR description
Fixes an issue when issuing self-billed invoices to the platform. So far we have been using Odoo's bill name as ID, but we should instead use the bill reference (if set) to use the supplier number. task-4777585 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208721
Steps to reproduce: - Install Discuss, events and contacts app - Set a partner langage to another langage - Open the event app and select an event - Select 'Attendees' in the smart buttons and click on New - In the 'Booked by' field, select the partner with the foreign langage - Save Current Behavior: A registration email is created but the body of the email is not translated to the language of the partner Expected Behavior: The body of the registration email should be translate
Original PR description
Steps to reproduce: - Install Discuss, events and contacts app - Set a partner langage to another langage - Open the event app and select an event - Select 'Attendees' in the smart buttons and click…
Steps to reproduce: - Install Discuss, events and contacts app - Set a partner langage to another langage - Open the event app and select an event - Select 'Attendees' in the smart buttons and click on New - In the 'Booked by' field, select the partner with the foreign langage - Save Current Behavior: A registration email is created but the body of the email is not translated to the language of the partner Expected Behavior: The body of the registration email should be translated in the language of the partner Cause of the issue: In order for the translation to happen inside _render_field() the variable 'equality' has to be True Link 1: https://github.com/odoo/odoo/blob/40b819ded20f769b0a63b73abfefebbdaca390df/addons/mail/models/mail_composer_mixin.py#L180 Because field is equal to 'body' the value of equality is the value of self.body_has_template_value Link 2:https://github.com/odoo/odoo/blob/40b819ded20f769b0a63b73abfefebbdaca390df/addons/mail/models/mail_composer_mixin.py#L168 self.body_has_template_value is computed by checking if the 'body' attribute of self (self is an instance of mail.compose.message) is either equal to self.template_id.body_html or tools.html_sanitize(self.template_id.body_html) Link3: https://github.com/odoo/odoo/blob/40b819ded20f769b0a63b73abfefebbdaca390df/addons/mail/models/mail_composer_mixin.py#L70 In this case, self.body has been computed using html_sanitize(self.template_id_html) Link4: https://github.com/odoo/odoo/blob/40b819ded20f769b0a63b73abfefebbdaca390df/odoo/fields.py#L2231 so self.body_has_template_value shoud be True The reason it's False is that when computing the value of self.body (Link4) the method html_sanitize is used with an argument (**sanitize_vals) which is not the case when comparing self.body to html_sanitize(self.template_id.body_html) (Link3) As a result self.body and html_sanitize(self.template_id.body_html) are not equal which makes self.body_has_template_value be False which makes equality be equal to False which makes the translation not happening Fix : Inside _compute_body_has_template_value() I made the method also return True if self.body is equal to html_sanitize(self.template_id.body_html,**sanitize_vals) with santize_vals having the same value as when self.body is computed opw-4349122 Forward-Port-Of: odoo/odoo#200187
Steps to reproduce: (thanks to TBS for investigating + writing the test) 1. Have a MX company with Quadrum or SwSapien 2. Create a USD bank transaction with `13220.00 USD` and `305147.51 MXN` 3. Create a USD invoice for `13220.00 USD` and send CFDI 4. Reconcile transaction and invoice 5. Click "Update payments" on the invoice => CRP20211 Looks like it comes from this rounding difference Rate is computed by odoo using `305147.51 MXN / 13220.0 USD = 23.082262481 ≃ 23.082262 MXN/USD`
Original PR description
Steps to reproduce: (thanks to TBS for investigating + writing the test) 1. Have a MX company with Quadrum or SwSapien 2. Create a USD bank transaction with `13220.00 USD` and `305147.51 MXN` 3.…
Steps to reproduce: (thanks to TBS for investigating + writing the test) 1. Have a MX company with Quadrum or SwSapien 2. Create a USD bank transaction with `13220.00 USD` and `305147.51 MXN` 3. Create a USD invoice for `13220.00 USD` and send CFDI 4. Reconcile transaction and invoice 5. Click "Update payments" on the invoice => CRP20211 Looks like it comes from this rounding difference Rate is computed by odoo using `305147.51 MXN / 13220.0 USD = 23.082262481 ≃ 23.082262 MXN/USD` PAC verify the amount paid using `13220.0 USD * 23.082262 MXN/USD = 305147.50 MXN` which is not `305147.51 MXN` Solution: There is no solution by adapting the rate: - quadrum restricts the rate to 6 decimals; - rounding the rate differently (e.g. to `23.082263`) would not help because `13220.0 USD * 23.082263 MXN/USD = 305147.52 MXN` which again is not `305147.51 MXN`. So, the only solution that I can think of is to adapt the amount in company currency so that it is exactly `round(amount_in_payment_curr / rate_rounded_to_6_decimals)`, i.e. in the example, change it to `305147.50 MXN`. In tests, both Quadrum and SwSapien seem to accept this. We don't perform the modification for Solucion Factible (the other PAC). opw-4222310 Forward-Port-Of: odoo/enterprise#85602 Forward-Port-Of: odoo/enterprise#83499
AttachedDocument is a specific XML format used in Colombia, generated by the DIAN regulatory body. These Documents are commonly received from vendors as they contain complete billing information. While Odoo 18.0+ can generate AttachedDocument records for outgoing invoices, it lacks import functionality. This document format contains nested XML documents that represent related records such as DIAN responses, Commercial Events data, and the orignal vendor invoice. The DIAN specifications state
Original PR description
AttachedDocument is a specific XML format used in Colombia, generated by the DIAN regulatory body. These Documents are commonly received from vendors as they contain complete billing information. While Odoo 18.0+ can generate AttachedDocument records for outgoing invoices, it lacks import functionality. This document format contains nested XML documents that represent related records such as DIAN responses, Commercial Events data, and the orignal vendor invoice. The DIAN specifications state that for an AttachedDocument with specified DocumentType must contain the original invoice within the top-most <cac:Attachment> node. (All other documents attached with this file are wrapped in <cac:ParentDocumentLineReference> tags which differentiates it) Specifications: https://www.dian.gov.co/impuestos/factura-electronica/Documents/Anexo-Techico-Factura-Electronica-de-Venta-vr-1-9.pdf task-4299222 Forward-Port-Of: odoo/enterprise#84374
## Version: 17.0+ ## Issue: Test (introduced by task 4457038) fails on Single App because of missing dependency. Relies on SHIF_AMOUNT https://github.com/odoo/enterprise/blob/ffb0aa8d7aad913328bb0b585197172da4e838b3/l10n_ke_hr_payroll_shif/data/hr_salary_rule_data.xml#L46C1-L47C1 runbot-159825 Forward-Port-Of: odoo/enterprise#85021
Original PR description
## Version: 17.0+ ## Issue: Test (introduced by task 4457038) fails on Single App because of missing dependency. Relies on SHIF_AMOUNT https://github.com/odoo/enterprise/blob/ffb0aa8d7aad913328bb0b585197172da4e838b3/l10n_ke_hr_payroll_shif/data/hr_salary_rule_data.xml#L46C1-L47C1 runbot-159825 Forward-Port-Of: odoo/enterprise#85021
This is a fix-of-fix. #### Explanation of the first fix Before the fix abb3194e190abae023ac2d794e631f38945d5f0d the invoice date was controlling the date that appears in the `Fecha` field of the CFDI, except if the invoice date was set to today or was in the future: in that case, the current time would be used. However, there would be cases where the CFDI would be successfully sent to the PAC but not registered as successfully sent in Odoo because of a timeout or disconnection. In those
Original PR description
This is a fix-of-fix. #### Explanation of the first fix Before the fix abb3194e190abae023ac2d794e631f38945d5f0d the invoice date was controlling the date that appears in the `Fecha` field of the…
This is a fix-of-fix. #### Explanation of the first fix Before the fix abb3194e190abae023ac2d794e631f38945d5f0d the invoice date was controlling the date that appears in the `Fecha` field of the CFDI, except if the invoice date was set to today or was in the future: in that case, the current time would be used. However, there would be cases where the CFDI would be successfully sent to the PAC but not registered as successfully sent in Odoo because of a timeout or disconnection. In those cases, using the current time is a problem because we will try to retry sending the CFDI to the PAC, with a new time, which would be recognised as a new invoice. To solve that issue, that fix set the Fecha to always be the `l10n_mx_edi_post_time` which is the time of posting of the invoice. However, that isn't okay for many Mexican users who expect that the CFDI date must be the same as the invoice date on the PDF (of course, except if the invoice date is in the future). #### The fix-of-fix (this PR) To solve both those issues, here is what we do: - now, the `l10n_mx_edi_post_time` is set when we first try to *send* the CFDI (rather than when we post it), and then stays the same unless the invoice is reset to draft (which ensures that if we must retry several times to resend the CFDI, the sending time won't change). - if the invoice date is older than the `l10n_mx_edi_post_time`, it will be used as the CFDI's Fecha. This ensures that users can control the Fecha using the invoice date. If the user modifies the invoice date, they will need to reset the invoice to draft, so the `l10n_mx_edi_post_time` will be reset too. task-none Forward-Port-Of: odoo/enterprise#85136
Like the sugar tax, alcohol is also taxed differently in Colombia such that we need a special case for how to compute it. The Per Unit Amount is the total tax amount divided by the alcohol percentage. To facilitate this change, the field that was previously used for the volume in ml for sugary drinks has been made into a generic "Specific Component Nominal Tax" field which can be used for any extra tax data depending on what type of tax is on the product. Comm PR: https://github.com/odoo/o
Original PR description
Like the sugar tax, alcohol is also taxed differently in Colombia such that we need a special case for how to compute it. The Per Unit Amount is the total tax amount divided by the alcohol percentage. To facilitate this change, the field that was previously used for the volume in ml for sugary drinks has been made into a generic "Specific Component Nominal Tax" field which can be used for any extra tax data depending on what type of tax is on the product. Comm PR: https://github.com/odoo/odoo/pull/208500 task-4634313 Forward-Port-Of: odoo/enterprise#84717
The aim of this commit is to: - avoid reporting negative amount in a 281.50 form which are rejected by the administration. - avoid reporting form with 0 value everywhere which are rejected by the administration. - avoid reporting a form with an amount < 250 EUR Context: The administration stated that we don't need to make any report that would be above 250 EUR. (art. 57, al. 3 CIR 92 et art. 30 AR/CIR 92) https://www.wolterskluwer.com/fr-be/expert-insights/tax-form-281-50
Original PR description
The aim of this commit is to: - avoid reporting negative amount in a 281.50 form which are rejected by the administration. - avoid reporting form with 0 value everywhere which are rejected by the…
The aim of this commit is to:
- avoid reporting negative amount in a 281.50 form which are rejected by the administration.
- avoid reporting form with 0 value everywhere which are rejected by the administration.
- avoid reporting a form with an amount < 250 EUR
Context:
The administration stated that we don't need to make any report that would be above 250 EUR.
(art. 57, al. 3 CIR 92 et art. 30 AR/CIR 92)
https://www.wolterskluwer.com/fr-be/expert-insights/tax-form-281-50 https://travaillerensociete.indicator.be/main/newsadvice/52784/news/52785/news_story/533/ https://www.monastucesetconseils.be/2025-04/fiches-fiscales-281-50-pour-le-29-juin-2025-WAACPCAR_EU33150802
Before this commit:
Odoo could create a form with a negative amount as commission/fee/... This could result in the administration software converting the xml into a BOW file to generated an error and a file that will be rejected by Belcotax.
Same for form with 0 everywhere.
Also, accountants always end up deleting the 281.50 form below 250 EUR as those don't need to be reported.
After this commit:
Odoo don't report negative or null total amount as commission/fee/... and doesn't create any form if the total amounts are below 250 EUR saving accountants the burden to remove them.
task-id: None
This was discussed and done with TSB and DELC and is also the result of our past experiences reporting 281.50 forms which also involved CAHE, MAKR and CAL.
Forward-Port-Of: odoo/enterprise#85508**Steps** 1. Upload a PDF & Sign > Upload PDF 2. Add a text item 3. Sign Now > Sign Now 4. Enter 123456789123456789 as text 5. Validate & Send Completed Document 6. Go to Documents > All Documents > Open the Document The number displayed is wrong by a small amount (123456789123456780). This happens because the number is bigger than Javascript's MAX_SAFE_INTEGER. Other problematic example: a sign item with "false" as text. **Solution** We can avoid parsing the text of the sign item.
Original PR description
**Steps** 1. Upload a PDF & Sign > Upload PDF 2. Add a text item 3. Sign Now > Sign Now 4. Enter 123456789123456789 as text 5. Validate & Send Completed Document 6. Go to Documents > All Documents > Open the Document The number displayed is wrong by a small amount (123456789123456780). This happens because the number is bigger than Javascript's MAX_SAFE_INTEGER. Other problematic example: a sign item with "false" as text. **Solution** We can avoid parsing the text of the sign item. opw-4479406 Forward-Port-Of: odoo/enterprise#77422
Before this commit: Some of the names in the stock_type list were wrong, causing an invalid type error when validating delivery. After the commit: Added a lookup table to update the incorrect names to match names in FedEx documentation. Fedex docs: https://developer.fedex.com/api/en-is/catalog/ship/docs.html opw-4725488 Forward-Port-Of: odoo/enterprise#84762
Original PR description
Before this commit: Some of the names in the stock_type list were wrong, causing an invalid type error when validating delivery. After the commit: Added a lookup table to update the incorrect names to match names in FedEx documentation. Fedex docs: https://developer.fedex.com/api/en-is/catalog/ship/docs.html opw-4725488 Forward-Port-Of: odoo/enterprise#84762
…line are postpaid Forward-Port-Of: odoo/enterprise#73731
Original PR description
…line are postpaid Forward-Port-Of: odoo/enterprise#73731
For proper provision management we introduce accounts 2350 and 2351 task-4797323 Forward-Port-Of: odoo/enterprise#85574
Original PR description
For proper provision management we introduce accounts 2350 and 2351 task-4797323 Forward-Port-Of: odoo/enterprise#85574
Fix a bug where account moves paid with cash appears in a line with full 0 in the boe export of mod347 tax report. But it shouldn't create a line at all, so this commit remove the lines in this case. task-4613012 Forward-Port-Of: odoo/enterprise#84317
Original PR description
Fix a bug where account moves paid with cash appears in a line with full 0 in the boe export of mod347 tax report. But it shouldn't create a line at all, so this commit remove the lines in this case. task-4613012 Forward-Port-Of: odoo/enterprise#84317
When the `marketing_automation_whatsapp` module is installed, if a user **without** the "Marketing Automation / User" group but **with** the "WhatsApp / Administrator" group sends a WhatsApp message, the "WhatsApp: Send In Queue Messages" cron may crash with an access error. This happens because the system tries to access marketing traces with the user that sent the message. However, marketing traces are restricted to Marketing Automation users. As a result, all WhatsApp messages in the same
Original PR description
When the `marketing_automation_whatsapp` module is installed, if a user **without** the "Marketing Automation / User" group but **with** the "WhatsApp / Administrator" group sends a WhatsApp message, the "WhatsApp: Send In Queue Messages" cron may crash with an access error. This happens because the system tries to access marketing traces with the user that sent the message. However, marketing traces are restricted to Marketing Automation users. As a result, all WhatsApp messages in the same batch are blocked indefinitely, even those that could otherwise be sent successfully. opw-4678339 Forward-Port-Of: odoo/enterprise#84386
compute imp & assert deduplicate Forward-Port-Of: odoo/enterprise#84842
Original PR description
compute imp & assert deduplicate Forward-Port-Of: odoo/enterprise#84842
When timezone of user is empty and the user clicks on Add Closing Day(s) button, a traceback will appear. Steps to reproduce the error: - Open Profile > Preferences > Select empty in timezone > Save - Install ``Appointments`` - Go to Appointments > Schedule > Resource Bookings > Add Closing Day(s) Traceback: ``` File "/home/odoo/src/enterprise/appointment/wizard/appointment_manage_leaves.py", line 19, in <lambda> leave_start_dt = fields.Datetime('Start Date', required=True, defa
Original PR description
When timezone of user is empty and the user clicks on Add Closing Day(s) button, a traceback will appear. Steps to reproduce the error: - Open Profile > Preferences > Select empty in timezone > Save…
When timezone of user is empty and the user clicks on Add Closing Day(s) button,
a traceback will appear.
Steps to reproduce the error:
- Open Profile > Preferences > Select empty in timezone > Save
- Install ``Appointments``
- Go to Appointments > Schedule > Resource Bookings > Add Closing Day(s)
Traceback:
```
File "/home/odoo/src/enterprise/appointment/wizard/appointment_manage_leaves.py", line 19, in <lambda>
leave_start_dt = fields.Datetime('Start Date', required=True, default=lambda self: self._default_time(0, 0))
File "/home/odoo/src/enterprise/appointment/wizard/appointment_manage_leaves.py", line 14, in _default_time
user_timezone = pytz.timezone(self.env.user.tz or self.env.context.get('tz', 'utc'))
File "/home/odoo/src/odoo/odoo/_monkeypatches/pytz.py", line 129, in timezone
return original_pytz_timezone(name)
File "__init__.py", line 183, in timezone
if zone.upper() == 'UTC':
AttributeError: 'bool' object has no attribute 'upper'
```
https://github.com/odoo/enterprise/blob/2c938b66fc1b526a360f4b199a47bcc53991bcb9/appointment/wizard/appointment_manage_leaves.py#L14
When the user selects an empty timezone, tz will be False.
So, It will lead to the above traceback.
Forward port https://github.com/odoo/enterprise/pull/64948 was closed in master,
so the issue is still present in saas-17.4 and all later versions.
sentry-6537084290
Forward-Port-Of: odoo/enterprise#83363This commit will do a backport of the python change made in this commit: https://github.com/odoo/enterprise/pull/77565/commits/7f26eefa932ec09297fbc4b8256ebe0b2976b231 task-4476707 Forward-Port-Of: odoo/enterprise#84728
Original PR description
This commit will do a backport of the python change made in this commit: https://github.com/odoo/enterprise/pull/77565/commits/7f26eefa932ec09297fbc4b8256ebe0b2976b231 task-4476707 Forward-Port-Of: odoo/enterprise#84728
- 18.0 **Steps to Reproduce:** - Create a subscription with a custom end date (e.g., 2025-04-09). - Manually generate an invoice covering a specific period (e.g., March 10 to April 9). - Wait until after the end date has passed (e.g., run expiration cron on 10 April or later). - The expiration cron triggers and overwrites the manually set end_date with the current date **Issue:** - The expiration cron overrides the existing end_date of the subscription. **Cause:** - The _get_c
Original PR description
- 18.0 **Steps to Reproduce:** - Create a subscription with a custom end date (e.g., 2025-04-09). - Manually generate an invoice covering a specific period (e.g., March 10 to April 9). - Wait until after the end date has passed (e.g., run expiration cron on 10 April or later). - The expiration cron triggers and overwrites the manually set end_date with the current date **Issue:** - The expiration cron overrides the existing end_date of the subscription. **Cause:** - The _get_closing_end_date method sets the end_date unconditionally during closure, even when an end_date is already defined. **Solution:** - Update the _get_closing_end_date logic to return the existing end_date if it is already set and valid, preventing it from being overridden when called by the expiration cron. task-4703577 Forward-Port-Of: odoo/enterprise#84475
Forward-Port-Of: odoo/enterprise#84190 Forward-Port-Of: odoo/enterprise#77188
Original PR description
Forward-Port-Of: odoo/enterprise#84190 Forward-Port-Of: odoo/enterprise#77188