Thursday, June 26, 2025
26 changes · saas-18.1
Enhancements to existing features
The IoT box image now includes additional tools to help diagnose network setup issues. This makes it easier for support and technical teams to identify device connectivity problems during configuration or troubleshooting.
Original PR description
Network scan/analysis tools can be useful when debugging configurations., so we added `arp-scan` and `mtr`.
Miscellaneous changes
For Jordan E-invoicing, the reason for return of a credit note is mandatory in the XML. Before this commit, if the return reason (`ref`) was empty in a credit note, an error from JoFotara pops up during validation. This commit makes sure the user is notified of missing `ref` before submitting the XML to JoFotara. task-4869028 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#215542
Original PR description
For Jordan E-invoicing, the reason for return of a credit note is mandatory in the XML. Before this commit, if the return reason (`ref`) was empty in a credit note, an error from JoFotara pops up during validation. This commit makes sure the user is notified of missing `ref` before submitting the XML to JoFotara. task-4869028 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#215542
<b>Steps to reproduce :</b> 1) Install the Purchase module 2) Create and confirm a Purchase Order with a product and quantity 3) From the Purchase Order, open the product and archive it <b>Issue:</b> Before archiving the product, the `Purchased` smart button correctly displays the total purchased quantity. However, after archiving the product template, this smart button displays `0.0`, even though purchases exist. Additionally, clicking the button opens a blank purchase order
Original PR description
<b>Steps to reproduce :</b> 1) Install the Purchase module 2) Create and confirm a Purchase Order with a product and quantity 3) From the Purchase Order, open the product and archive it <b>Issue:</b>…
<b>Steps to reproduce :</b> 1) Install the Purchase module 2) Create and confirm a Purchase Order with a product and quantity 3) From the Purchase Order, open the product and archive it <b>Issue:</b> Before archiving the product, the `Purchased` smart button correctly displays the total purchased quantity. However, after archiving the product template, this smart button displays `0.0`, even though purchases exist. Additionally, clicking the button opens a blank purchase order line view instead of showing related records if the product is archived. <b>Cause:-</b> Archiving a product template sets active=False on the template and its variants. The computed field `purchased_product_qty` relies on the variants to calculate the total. Because the variants are inactive post-archival, the compute method sees no records, resulting in a displayed value of 0.0. Similarly, the smart button action uses the active variants in its domain, so it fails to find any related purchase order lines. <b>Solution:</b> The context is now explicitly set with active_test=False when computing the purchased_product_qty and when generating the domain for the smart button action. This ensures that even inactive variants are included in the calculation and the view logic, preserving the correct purchased quantity and showing the relevant purchase lines after archival. opw-4781578 Forward-Port-Of: odoo/odoo#213484 Forward-Port-Of: odoo/odoo#209955
In lxml from 4.6.0 to 5.2.0: [1] introduces an issue where "style" tags will always be cleaned if there is more than one data url inside it (the regex is too greedy) in 4.6.0 [2] fixes the issue in the lxml_html_clean module version 0.1.1 which is the dependency that replaces lxml.html.clean from lxml 5.2.0 and up We apply the fix from [2] in odoo directly. With many checks to ensure we don't override any potential deviation from the original regex. The issue only appear from 18.
Original PR description
In lxml from 4.6.0 to 5.2.0: [1] introduces an issue where "style" tags will always be cleaned if there is more than one data url inside it (the regex is too greedy) in 4.6.0 [2] fixes the issue in the lxml_html_clean module version 0.1.1 which is the dependency that replaces lxml.html.clean from lxml 5.2.0 and up We apply the fix from [2] in odoo directly. With many checks to ensure we don't override any potential deviation from the original regex. The issue only appear from 18.0 onwards, as that's when "email_outgoing" sanitation started being applied [3] [1]: https://github.com/lxml/lxml/commit/73778681f14359fe6d16644e69aaca276eba525a [2]: https://github.com/fedora-python/lxml_html_clean/commit/97402b5f6e94583c8f1c3f6070ef19ce1df90da8 [3]: https://github.com/odoo/odoo/commit/24731938f75358fd3c72b91465b72ab80d62d208 runbot-105525 Forward-Port-Of: odoo/odoo#213393
## Version 18.0+ ## Issue When an animation is set on wishlist button icon, only one product appears per eCommerce page. Same behavior for compare and add-to-cart buttons. ## Steps to reproduce - Enable wishlists from `Settings` App; - Go to shop frontend view in edit mode: - Select a wishlist button icon on any product by clicking on it; - From editor's view, move to `Icon` section: - Add an animation (e.g. `On Appearance`). - Save and refresh; - Move to any shop pag
Original PR description
## Version
18.0+
## Issue
When an animation is set on wishlist button icon, only one product appears per eCommerce page.
Same behavior for compare and add-to-cart buttons.
## Steps to reproduce
- Enable wishlists from `Settings` App;
- Go to shop frontend view in edit mode:
- Select a wishlist button icon on any product by clicking on it;
- From editor's view, move to `Icon` section:
- Add an animation (e.g. `On Appearance`).
- Save and refresh;
- Move to any shop page and see only 1 product.
> [!important]
> Not reproducible in FireFox or Safari.
opw-4784323
Forward-Port-Of: odoo/odoo#213773<b>Steps to reproduce:</b> 1. Go to Sales > Configuration > Product Categories 2. Select All / Saleable, and set Costing Method to FIFO 3. Go to Products > New 4. Fill in Name , set Track Inventory True and add Cost, then save the product 5. Change the Category to All / Saleable 6. Navigate to Attributes & Variants, add attribute Leg, and add values Steel and Aluminium <b>Issue :</b> - When modifying a product template with FIFO costing by adding multiple attributes, the system may d
Original PR description
<b>Steps to reproduce:</b> 1. Go to Sales > Configuration > Product Categories 2. Select All / Saleable, and set Costing Method to FIFO 3. Go to Products > New 4. Fill in Name , set Track Inventory True and add Cost, then save the product 5. Change the Category to All / Saleable 6. Navigate to Attributes & Variants, add attribute Leg, and add values Steel and Aluminium <b>Issue :</b> - When modifying a product template with FIFO costing by adding multiple attributes, the system may delete and recreate product variants. This causes "missing record" error during stock valuation replenishment, as the code tries to access deleted product variants. <b>Solution :</b> - After calling super().write(vals), the original products recordset may contain deleted records due to variant regeneration. A check was added to verify if the variants still exist, If not, then continues. <b>opw-4741530</b> Forward-Port-Of: odoo/odoo#209513
When there is invalid characters in the field, sending may lead to unexpected behaviour. normalize and keep only the first one Task-id: 4894083 Forward-Port-Of: odoo/odoo#215784 Forward-Port-Of: odoo/odoo#215580
Original PR description
When there is invalid characters in the field, sending may lead to unexpected behaviour. normalize and keep only the first one Task-id: 4894083 Forward-Port-Of: odoo/odoo#215784 Forward-Port-Of: odoo/odoo#215580
In this commit, we add a step to ensure that the popover comparator is visible in the DOM before moving on to the next check step. 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#215810
Original PR description
In this commit, we add a step to ensure that the popover comparator is visible in the DOM before moving on to the next check step. 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#215810
The "Alert Date Reached" activity was not correctly assigning the activity to the "Default User" specified in the `mail.activity.type` settings. This did not align with user expectations that the activity type's default user should be primarily considered. To reproduce the issue: 1. Configure a "Default User" (e.g., User A) for the Alert Date Reached activity type. 2. Create a product tracked by lots. Ensure its "Responsible User" (on the product's Inventory tab) is either not set or is a d
Original PR description
The "Alert Date Reached" activity was not correctly assigning the activity to the "Default User" specified in the `mail.activity.type` settings. This did not align with user expectations that the…
The "Alert Date Reached" activity was not correctly assigning the activity to the "Default User" specified in the `mail.activity.type` settings. This did not align with user expectations that the activity type's default user should be primarily considered. To reproduce the issue: 1. Configure a "Default User" (e.g., User A) for the Alert Date Reached activity type. 2. Create a product tracked by lots. Ensure its "Responsible User" (on the product's Inventory tab) is either not set or is a different user (e.g., User B). 3. Receive the product with a lot number and set its alert date to be in the past. 4. Trigger the scheduler for checking lot expirations (via Operations > Run Scheduler). 5. The generated "Alert Date Reached" activity would be assigned to User B (if set) or the superuser, incorrectly ignoring User A. This commit rectifies this behavior by modifying the user assignment logic for these lot expiry alerts. The new priority for determining the assignee is: 1. The "Default User" configured on the "Alert Date Reached" activity type. 2. If no default user is set on the activity type, then the "Responsible User" defined on the related product. 3. If neither is set, the activity is assigned to SUPERUSER. [opw-4640027](https://www.odoo.com/odoo/project.task/4640027) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#214165 Forward-Port-Of: odoo/odoo#212154
This commit fixes the `second tab still receives notifications after main pagehide` test. This test simulates the main tab being closed. As a result, the main tab unregister itself from the worker. Upon message reception, the worker would try to access client's specific data such as channels or debug mode which are supposed to be available. However, since the client was unregistered, an error occurred. runbot-75372 Description of the issue/feature this PR addresses: Current behavior bef
Original PR description
This commit fixes the `second tab still receives notifications after main pagehide` test. This test simulates the main tab being closed. As a result, the main tab unregister itself from the worker. Upon message reception, the worker would try to access client's specific data such as channels or debug mode which are supposed to be available. However, since the client was unregistered, an error occurred. runbot-75372 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#214729
This PR changes the sales and purchase taxes for Cyprus when selling/purchasing within the EU. - All sales taxes changed to 0% when selling to country within the EU. - All purchase taxes changed to 19% when buying from country within the EU. However, a second tax repartition line is added at -100% of the tax. The tax is effectively applied and deducted at the same time. - Redundant taxes were removed like zero rate taxes and taxes with reverse charge. task-4488340 Current behavior be
Original PR description
This PR changes the sales and purchase taxes for Cyprus when selling/purchasing within the EU. - All sales taxes changed to 0% when selling to country within the EU. - All purchase taxes changed to…
This PR changes the sales and purchase taxes for Cyprus when selling/purchasing within the EU. - All sales taxes changed to 0% when selling to country within the EU. - All purchase taxes changed to 19% when buying from country within the EU. However, a second tax repartition line is added at -100% of the tax. The tax is effectively applied and deducted at the same time. - Redundant taxes were removed like zero rate taxes and taxes with reverse charge. task-4488340 Current behavior before PR: - When selling to other EU countries, a 19% sales tax is added to goods and services. - When buying with other EU countries, a 0% VAT tax is added to goods and a 19% VAT tax is added to services. Desired behavior after PR is merged: - When selling to other EU countries, a 0% sales tax is added to goods and services. - When buying with other EU countries, a 19% VAT tax is added to goods and services, and a second tax repartition line is added at -100% of the tax effectively making it 0. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#211746
Before this commit: 1. Insert an image and add a link to it. 2. Click on the image and remove it by clicking the remove button in the toolbar. 3. The link popover remains open and only disappears after clicking away. This occurs because the default behavior of a link with text preserves the link element to allow the possibility of completely changing the label of the link directly in the editing area. After this commit: The link popover is properly closed when an image link is remove
Original PR description
Before this commit: 1. Insert an image and add a link to it. 2. Click on the image and remove it by clicking the remove button in the toolbar. 3. The link popover remains open and only disappears after clicking away. This occurs because the default behavior of a link with text preserves the link element to allow the possibility of completely changing the label of the link directly in the editing area. After this commit: The link popover is properly closed when an image link is removed, and the link element is removed when the link element associated with the image is empty. task-4805029 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213955
Steps to reproduce: 1. Set company warehouse to two-step manufacturing. 2. Create products: X, A, B, C. 3. Add on-hand quantities: A = 10, C = 5. 4. Create a BOM for X with A and B as components. 5. Create and confirm a MO for X in the two-step warehouse. 6. Check product B's forecast report → shows -1. 7. Add a reordering rule for B → forecast shows -1. 8. Edit X’s BOM: remove B and add C instead. 9. Update the MO using the `update_bom` button. 10. Check MO components. 11. Check WH/P
Original PR description
Steps to reproduce: 1. Set company warehouse to two-step manufacturing. 2. Create products: X, A, B, C. 3. Add on-hand quantities: A = 10, C = 5. 4. Create a BOM for X with A and B as components. 5.…
Steps to reproduce: 1. Set company warehouse to two-step manufacturing. 2. Create products: X, A, B, C. 3. Add on-hand quantities: A = 10, C = 5. 4. Create a BOM for X with A and B as components. 5. Create and confirm a MO for X in the two-step warehouse. 6. Check product B's forecast report → shows -1. 7. Add a reordering rule for B → forecast shows -1. 8. Edit X’s BOM: remove B and add C instead. 9. Update the MO using the `update_bom` button. 10. Check MO components. 11. Check WH/Preprod transfer → B is still there. 12. Re-check steps 6 and 7. **Issue**: In two-step manufacturing, two stock moves are created: - move1: WH/Stock → WH/Preprod - move2: WH/Preprod → Virtual/Production The forecast report uses the company warehouse (WH) as the location domain and includes move2. It calculates: forecast = qty_available - demand = 0 - 1 = -1 The reordering rule uses WH/Stock (its default location) and includes move1, resulting in the same forecast: -1. After updating the BOM to remove B: - move2 is deleted correctly. - move1 remains on the pre-production transfer. This causes an inconsistency: - Forecast report (based on move2) → shows 0 - Reordering rule (based on move1) → still shows -1 We set the product_uom_qty to 0 of the prepoduction moves so procurement runs with negative qty move and it is merged with the existing ones in the preproduction picking. This will make the moves in the preprod picking be 0 and not deleted to avoid deleting manually added moves from the client in the preproduction picking. **Limitation** The current setup will update the pre_prod_pick moves with 0 demand, but for the post_prod_pick moves there is no pull rule that will trigger a procurement with -ve old demand to update the post_prod_pick move leaving it not updated to the bom changes. This will not be an issue in 18.0+ because of changing to push rules as the post_prod_pick will not be there unless the MO is done, so BoM updates will not be needed to be reflected. opw-4746230 Forward-Port-Of: odoo/odoo#215693 Forward-Port-Of: odoo/odoo#209642
@moduon MT-10568 MT-10569 MT-10567 MT-10566 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#214739
Original PR description
@moduon MT-10568 MT-10569 MT-10567 MT-10566 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#214739
Prior to this commit, when a sale order was created with some service products configured to generate projects at SO confirmation, we would generate an analytic account per project instead of just one for all the generated projects. As a result, we would get redundant analytic accounts, which is not desirable. This is because we were creating the new projects without specifying the analytic account that would be set to it (because we would assume that the project would be first created withou
Original PR description
Prior to this commit, when a sale order was created with some service products configured to generate projects at SO confirmation, we would generate an analytic account per project instead of just one for all the generated projects. As a result, we would get redundant analytic accounts, which is not desirable. This is because we were creating the new projects without specifying the analytic account that would be set to it (because we would assume that the project would be first created without AA, then we would populate it later). The issue is that if `hr_timesheet` is installed, every new project is by default timesheetable, so that it generates an AA automatically at creation of the project (see `create()` method of `hr_timesheet`) To mitigate that, we now specify the analytic account to be used when creating the projects that have to be generated from `_timesheet_create_project()`. version-18.0 task-4854817 Forward-Port-Of: odoo/odoo#215616
Description of the issue/feature this PR addresses: if 2 concurrent requests are generating a sequence number on a sequence that requires a new range odoo will create 2 ranges with the same start and end date. Both request will then return the same sequence number. Current behavior before PR: Duplicated sequence numbers are generated Desired behavior after PR is merged: Raise an error if two date ranges for the same sequence with the same date range are created and avoid sequence number
Original PR description
Description of the issue/feature this PR addresses: if 2 concurrent requests are generating a sequence number on a sequence that requires a new range odoo will create 2 ranges with the same start and…
Description of the issue/feature this PR addresses:
if 2 concurrent requests are generating a sequence number on a sequence that requires a new range odoo will create 2 ranges with the same start and end date. Both request will then return the same sequence number.
Current behavior before PR:
Duplicated sequence numbers are generated
Desired behavior after PR is merged:
Raise an error if two date ranges for the same sequence with the same date range are created and avoid sequence number duplication
Script I used to reproduce the issue:
```python
import threading
import xmlrpc.client
url = 'http://localhost:8069'
db = 'db_name'
username = 'admin'
password = 'admin'
common = xmlrpc.client.ServerProxy('{}/xmlrpc/2/common'.format(url))
uid = common.authenticate(db, username, password, {})
models = xmlrpc.client.ServerProxy('{}/xmlrpc/2/object'.format(url))
models.execute_kw(db, uid, password, 'ir.sequence', 'unlink', [models.execute_kw(db, uid, password, 'ir.sequence', 'search', [[('code', '=', 'test.sequence')]])])
models.execute_kw(db, uid, password, 'ir.sequence', 'create', [{
'name': 'Test Sequence',
'code': 'test.sequence',
'prefix': 'TEST-',
'suffix': '/%(month)s/%(range_year)s/10001',
'padding': 1,
'number_increment': 1,
'use_date_range': True,
}])
def get_sequence_number():
return models.execute_kw(db, uid, password, 'ir.sequence', 'next_by_code', ['test.sequence'])
for i in range(5):
threading.Thread(target=get_sequence_number).start()
```
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#210277**Steps to reproduce:** - For simplicity, create a new account. - Create a new journal entry, with one line on the newly created account. - Set the date to today or older. - Set auto-post to "At date". - Make sure the journal has autocheck_on_post set to True. - Keep the journal entry in draft, and duplicate it until you have 100 copies. (Make sure auto-post is set to "At date" on all of the copies aswell) - Set the newly created account to 'Deprecated'. - Manually execute the scheduled
Original PR description
**Steps to reproduce:** - For simplicity, create a new account. - Create a new journal entry, with one line on the newly created account. - Set the date to today or older. - Set auto-post to "At…
**Steps to reproduce:** - For simplicity, create a new account. - Create a new journal entry, with one line on the newly created account. - Set the date to today or older. - Set auto-post to "At date". - Make sure the journal has autocheck_on_post set to True. - Keep the journal entry in draft, and duplicate it until you have 100 copies. (Make sure auto-post is set to "At date" on all of the copies aswell) - Set the newly created account to 'Deprecated'. - Manually execute the scheduled action "Account: Post draft entries with auto_post enabled and accounting date up to today" **Issue:** The scheduled action fails and then falls into an infinte loop, and logs an error on the chatter every minute, which could lead to thousands of mail_message records beign created. **Cause:** If the autopost scheduled action fails on a certain move, it marks it as 'move.checked = False'. So that when it is calls itself again (if the number of moves to post is greater than or equal to 100), it won't fetch the same move and fail again. But having 'journal_id.autocheck_on_post = True' in the search domain allows autopost to fetch the same move it marked before (if the journal allows it), which leads to an infinite loop. **Solution:** If autopost fails on a move, set 'auto_post' to 'no' so it won't be fetched again. opw-4815790 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213642
If a bank account is already linked to a partner, display a non-blocking warning on the bank account creation form, containing a link to the other partner. task-4431041 Forward-Port-Of: odoo/odoo#198127
Original PR description
If a bank account is already linked to a partner, display a non-blocking warning on the bank account creation form, containing a link to the other partner. task-4431041 Forward-Port-Of: odoo/odoo#198127
Before this commit, there could be a race condition where the peer connection gets closed while an offer is being negotiated. This could happen for example when offers are being sent to establish a p2p connection and the fallback to the SFU kicks in and clears the connection. This would lead to a traceback but no functional issue. Forward-Port-Of: odoo/odoo#215995
Original PR description
Before this commit, there could be a race condition where the peer connection gets closed while an offer is being negotiated. This could happen for example when offers are being sent to establish a p2p connection and the fallback to the SFU kicks in and clears the connection. This would lead to a traceback but no functional issue. Forward-Port-Of: odoo/odoo#215995
### Steps to reproduce: - Ensure Recruitment and Referral modules are installed - Create a job application and set a value in source field - Save and notice the source field got deleted ### Cause: This is happening as in hr_referral we are setting the source_id to be the referral user's source. https://github.com/odoo/enterprise/blob/18cc5b67095d304d514a362c5f02d8426b4a3697/hr_referral/models/hr_applicant.py#L65-L67 ### Fix: If there is not referral user we should keep the value
Original PR description
### Steps to reproduce: - Ensure Recruitment and Referral modules are installed - Create a job application and set a value in source field - Save and notice the source field got deleted ### Cause: This is happening as in hr_referral we are setting the source_id to be the referral user's source. https://github.com/odoo/enterprise/blob/18cc5b67095d304d514a362c5f02d8426b4a3697/hr_referral/models/hr_applicant.py#L65-L67 ### Fix: If there is not referral user we should keep the value set by the user and not override it with False opw-4677023 Forward-Port-Of: odoo/enterprise#88298 Forward-Port-Of: odoo/enterprise#83036
Before this commit, when one tries to upload a file to a document request for the first time it does nothing. This is caused by an async memoize call which causes the file to be cleared between the memoize rpc call and the file processing after that call... After that first call the user can upload a new file without issue but it's still annoying. This commit fix this issue by storing the file in a variable before doing the memoize rpc call. Task-4778429 Forward-Port-Of: odoo/enterpri
Original PR description
Before this commit, when one tries to upload a file to a document request for the first time it does nothing.
This is caused by an async memoize call which causes the file to be cleared between the memoize rpc call and the file processing after that call... After that first call the user can upload a new file without issue but it's still annoying.
This commit fix this issue by storing the file in a variable before doing the memoize rpc call.
Task-4778429
Forward-Port-Of: odoo/enterprise#86002When printing a report with an IoT Box, we send a longpolling request from the client. The UI was not blocking doing so, so a fast user could leave the view before the request ended, resulting in a traceback: Component is destroyed. opw-4812421 Forward-Port-Of: odoo/enterprise#88493
Original PR description
When printing a report with an IoT Box, we send a longpolling request from the client. The UI was not blocking doing so, so a fast user could leave the view before the request ended, resulting in a traceback: Component is destroyed. opw-4812421 Forward-Port-Of: odoo/enterprise#88493
Adds a tour that ensure date-based rental durations are set correctly, i.e. renting from 2025-01-01 to 2025-01-02 should result in a rental period of 2 days. This should prevent commits like 574e111 (reverted by 5982e11) from introducing faulty logic. Forward-Port-Of: odoo/enterprise#88264
Original PR description
Adds a tour that ensure date-based rental durations are set correctly, i.e. renting from 2025-01-01 to 2025-01-02 should result in a rental period of 2 days. This should prevent commits like 574e111 (reverted by 5982e11) from introducing faulty logic. Forward-Port-Of: odoo/enterprise#88264
This commit solves the following bugs in Norwegian saft as per customer feedback: 1. Removed the StandardAccountID 2. Added the CreditAmount tag value to the XML file if the both debit and credit values is 0 for an entry The latter point in needed because the SAF-T XML validator expects CreditAmount/DebitAmount tag even if the entry is empty. This case may happen if, for example, we have an exchange rate entry = $0.000001. Since the journal entry is approximating to only 2 decimal places,
Original PR description
This commit solves the following bugs in Norwegian saft as per customer feedback: 1. Removed the StandardAccountID 2. Added the CreditAmount tag value to the XML file if the both debit and credit values is 0 for an entry The latter point in needed because the SAF-T XML validator expects CreditAmount/DebitAmount tag even if the entry is empty. This case may happen if, for example, we have an exchange rate entry = $0.000001. Since the journal entry is approximating to only 2 decimal places, the amounts on the entry end up being 0s. task-4714764 Forward-Port-Of: odoo/enterprise#88580 Forward-Port-Of: odoo/enterprise#83963
Essentially a copy of the l10n_us_check_printing module, adjusted to work with DO stuff. The layouts is adjusted to qualify as 'vaguely matching the target check layout', which I was told is enough. Concern: I can't fit the layout closer without being able to overlay it over an example blank check background. Concern: The width of partner address lines (ckdo_payee_addr class in print_check.xml) is a bit too limited (so even Azure Interior's ordinary address turns into a vertical mess) by the g
Original PR description
Essentially a copy of the l10n_us_check_printing module, adjusted to work with DO stuff. The layouts is adjusted to qualify as 'vaguely matching the target check layout', which I was told is enough.
Concern: I can't fit the layout closer without being able to overlay it over an example blank check background.
Concern: The width of partner address lines (ckdo_payee_addr class in print_check.xml) is a bit too limited (so even Azure Interior's ordinary address turns into a vertical mess) by the generic address line widget ir_qweb_widget_templates.xml -> <template id="contact">. Adding a width parameter directly to .ckdo_payee_addr{} in report_check_*.scss solves this, but it doesn't seem like the correct solution.
task-4290725
Forward-Port-Of: odoo/enterprise#75498This commit will change the condition of display of the coda_split_transactions allowing users to choose whether transactions are imported individually or in batch. opw-4873108 Forward-Port-Of: odoo/enterprise#88370
Original PR description
This commit will change the condition of display of the coda_split_transactions allowing users to choose whether transactions are imported individually or in batch. opw-4873108 Forward-Port-Of: odoo/enterprise#88370