Daily updates from Odoo
Tuesday, January 20, 2026
32 changes · saas-18.3
Resolved issues and error corrections
This update resolves an issue that occurred when users attempted to 'Show', 'Force CFDI', or 'Retry' operations on MX electronic invoices. The problem stemmed from a system error when payments were cancelled or deleted, leading to incorrect invoice data. This fix ensures a smoother process for generating and submitting CFDI invoices.
Original PR description
When user is clicking any of the `Show`, `Force CFDI`, or `Retry` buttons in l10n_mx_edi.document error occurs. Steps to reproduce: - Install `l10n_mx_edi` module > Switch to `MX Company` - Setup `MX Electronic invoicing` in settings - Create a New Invoice > Send > Select `CFDI` > `Pay` > `Update Payments` - Payment > Cancel that Payment > Back to Invoice > CFDI(Notebook page) > Click on `Show` or `Force CFDI` or `Retry` Traceback: `ValueError: Expected singleton: account.move()` This error occurs when a payment is created and later deleted or cancelled, which results in an empty `move_id` in l10n_mx_edi.document. sentry-7113267386 Forward-Port-Of: odoo/enterprise#102248
This update fixes a technical issue that caused errors when Odoo servers were stopped. Specifically, the server shutdown process was incorrectly closing database connections before the system was fully ready, leading to errors. This change ensures a smoother and more reliable server shutdown process.
Original PR description
When the server stops, pool errors can occur. It's due to the server stop function calling `sql_db.py@close_all()`. If this occurs before the dispatcher loop wakes up, the `__exit__` function of the cursor context manager will raise an error, because the connection has already been popped from the pool. As for interface errors in [1], pool errors should be ignored during server shutodwn. runbot-229800 [1]: https://github.com/odoo/odoo/pull/99849 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#244481
This update corrects a technical issue related to canned response testing in the live chat feature. Previously, outdated tests were causing problems. This PR removes these unnecessary tests, ensuring the live chat functionality operates smoothly and reliably.
Original PR description
In [1], auto focus was removed for canned responses in the navigable list. The intent was to avoid conflicts with emojis. In [2], the shortcut for canned response was changed to `::` and the auto focus behavior was restored. However, tests added in [1] were not removed. Since they were fragile (negative assertion), they are passing most of the time. This PR removes the tests that are now outdated. runbot-233358 [1]: https://github.com/odoo/odoo/pull/170900 [2]: https://github.com/odoo/odoo/pull/192953 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#244472
This update resolves an issue where full payments on invoices with installment tax terms resulted in incorrect and duplicated cash basis tax calculations. The fix ensures that only the remaining balance's tax is recorded when a full payment is made, aligning with the intended batch processing functionality. This improves the accuracy of financial reporting.
Original PR description
**Steps to reproduce:** 1. Install the `Accounting` module. 2. Enable cash basis taxes in `Accounting → Configuration → Settings → Taxes → Cash Basis`. 3. Create a tax, set `Tax Exigibility` to…
**Steps to reproduce:** 1. Install the `Accounting` module. 2. Enable cash basis taxes in `Accounting → Configuration → Settings → Taxes → Cash Basis`. 3. Create a tax, set `Tax Exigibility` to `Based on Payment`, and assign a `Cash Basis Transition Account`. 4. Create an invoice with the cash basis tax and a payment term such as `30% now, balance in 60 days`. 5. Record a full payment on the invoice instead of just the first installment. 6. Review the generated cash basis journal entries. **Observed behavior:** * Cash basis entries are created for the full tax amount, not proportionally. * Paying the full invoice with payment terms causes duplicated tax entries. This came from the fact that we didn't consider a move would be fully paid by several lines at the same time, like with installments. We now only put the leftover amount when the move is fully paid and we're on the last partial. Also fix the fact that paying 2 invoices at the same time in full does not benefit from the batches opw-5061136 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a technical issue related to how Odoo processes multiple payment moves during payroll registration. The fix ensures that payments are handled efficiently, improving the reliability of payroll calculations. This change impacts the HR Payroll module.
Original PR description
There was an error where we weren't batching when we were selecting several moves at the same time when registering a payment. We fixed that and this test needs to be adapted.
This update corrects a technical issue where Saudi partner address data was being unintentionally cleared when related contacts were created or updated. The fix prevents data loss by stopping the propagation of incorrect values from related contacts to the main partner record. This ensures accurate address information for all Saudi partners.
Original PR description
All Saudi partners use the saudi_o_address_format. As a result, contacts created from a company partner also inherit this address format, which includes fields such as street, city, zip, and state. These fields are set as read-only by the address format. When child_ids are written on the parent partner, those read-only fields are written with False values. Due to the address field synchronization between parent and related contacts, these False values are then propagated back to the parent partner, causing its address data to be cleared. This fix prevents address fields from being unintentionally reset when related contacts are created or updated. task-5349050 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where foreign currency rates weren't correctly applied during Datev CSV report exports. Previously, invoices wouldn't reflect the intended currency rates. Now, the system ensures accurate currency conversion is used when generating these reports, improving data accuracy for Datev.
Original PR description
When we set the foreign currency rate on invoices, it won't be used when exporting the report. Make sure to use the correct currency rate. task-5404816 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239649
This update fixes an issue where foreign currency rates weren't correctly applied when generating Datev CSV reports. Now, the correct currency rates from invoices are used, ensuring accurate financial reporting for German customers. This improves the reliability of data exported to Datev.
Original PR description
When we set the foreign currency rate on invoices, it won't be used when exporting the report. Make sure to use the correct currency rate. task-5404816 Forward-Port-Of: odoo/enterprise#101910
This update prevents errors when creating inter-company invoices by ensuring payment terms are compatible with the receiving company. Previously, invoices automatically used the payment term of the originating company, causing posting failures. Now, the system correctly applies company-specific payment terms.
Original PR description
**Steps to reproduce:** * Install `Accounting` and `sales` modules. * Create two companies and enable **Inter-Company Transactions** with **Synchronize invoices/bills** in settings for both…
**Steps to reproduce:** * Install `Accounting` and `sales` modules. * Create two companies and enable **Inter-Company Transactions** with **Synchronize invoices/bills** in settings for both companies. * Create a **payment term** assigned to **Company A**. * Create a **sale order** from Company A to Company B using that payment term. * Confirm the sale order and create the **invoice**. * Post the invoice to trigger the inter-company vendor bill. **Observed behavior:** * The generated **vendor bill** for Company B uses **Company A’s payment term**. * Posting fails because the payment term is incompatible with Company B. **Cause:** * Inter-company document creation reuses payment terms without checking whether they belong to the **target company**. * Payment terms from the source company can be propagated to the destination document. **Fix:** * Ensure only **company-compatible** payment terms are applied when creating inter-company sale orders, purchase orders, and invoices. * Payment terms belonging to a different company are now ignored. **NOTE**: test is not implemented due to technical limitations. Inter-company invoice synchronization relies on UI context propagation that cannot be replicated in unit tests. The payment term validation logic depends on web client context flags that are only set during real UI interactions, not programmatic execution. opw-5392745 Forward-Port-Of: odoo/enterprise#102986
This update resolves an issue that prevented users from exporting SAFT reports for Austrian companies without defined contacts. The fix eliminates a redundant check, ensuring the system correctly validates contact information before generating the SAFT file. This improves the reliability of the SAFT export process for Austrian businesses.
Original PR description
[FIX] l10n_at_saft: saft export traceback When no contacts is defined on the company and the user tries to download the SAFT to XML, a traceback is shown Steps to reproduce the traceback: - Install l10n_at_saft module and create an Austrian company with no contacts - Create a few invoices for this company - Open the General Ledger report and export SAFT to XML, the traceback should appear no-task Forward-Port-Of: odoo/enterprise#104633 Forward-Port-Of: odoo/enterprise#104144
This update resolves a compatibility problem between shipping carriers and shipping partners within the Odoo website's sales functionality. Previously, certain carriers weren't correctly recognized, leading to potential errors during order processing. This fix ensures all shipping carriers are properly supported, improving the reliability of the online sales experience.
Original PR description
Forward-Port-Of: odoo/odoo#244300 Forward-Port-Of: odoo/odoo#244035
This update fixes an error in the Vietnam tax reports that was causing incorrect calculations for key balance sheet codes (420.1 and 420.2). The changes ensure accurate reporting of undistributed profit, improving the reliability of financial data for Vietnamese businesses using Odoo Enterprise.
Original PR description
The formulas for 'Undistributed profit after tax brought forward' (420.1) and 'Undistributed profit after tax for the current year' (420.2) were calculating incorrect values. Issues fixed: - Changed date_scope from `from_fiscalyear`/`to_beginning_of_fiscalyear` to `from_beginning` where historical cumulative values are needed. - Added missing negative signs to account code formulas (`-4211`, `-4212`, `-911`) to correctly display credit balances as positive equity. - Removed unnecessary `py_balance` expression with conditional logic. - Added subtraction of `UPATCY.balance` from `UPATBF.balance` to prevent double-counting when aggregating to parent line 420. - Added missing `py_account_codes` expression (`-4212`) to `UPATCY`. task-5492884 Forward-Port-Of: odoo/enterprise#104373
This update resolves an issue where printers would become unavailable for extended periods after disconnecting, leading to user errors and double printing. The change introduces a safeguard to only remove printers from the system after multiple disconnection attempts, ensuring printers are reliably available and jobs are printed correctly.
Original PR description
On the iot box we check the number of printers connected rarely to avoid spamming the network. This leads to some situations where if a printer is disconnected it becomes unusable for the next 2…
On the iot box we check the number of printers connected rarely to avoid spamming the network. This leads to some situations where if a printer is disconnected it becomes unusable for the next 2 minutes or even more if it disconnects again just before the next get_devices call in the interface. The printers are often not listed by cups for short time which currently leads to them being deleted from our list of connected devices on the iot box. However in reality the printer reconnects faster than 2 minutes and often becomes available again within a couple of seconds. Currently if you print something on it you will get an error when checking the job status but the job will still be queud and printed whenever it reconnects. The user in pos can then press "retry" which will lead to a double printing. This PR adds a counter for the printer disconnections and only removes the printer from our list if it wasn't detected 3 times in a row by cups. Now since not deleted from cups the print job is queud and whenever the printer reconnects it's printed. The user will not get an error anymore which will avoid double printing and the printer will remain available unless it's really disconnected Forward-Port-Of: odoo/odoo#244076
This update resolves an issue where the Amazon connector wasn't correctly identifying key delivery modules for UPS, FedEx, USPS, and DHL. By mapping these modules, the connector now functions properly with these major shipping carriers, ensuring accurate order processing and fulfillment within the Amazon integration.
Original PR description
Amazon connector did not recognize the _rest delivery modules (ups_rest, fedex_rest, usps_rest, dhl_rest). This maps them to the correct carrier names, consistent with existing mappings. Forward-Port-Of: odoo/enterprise#102606
This update resolves an issue where embedded buttons in the Odoo Control Panel were getting cropped due to incorrect height calculations during dragging. The fix ensures that the buttons display their actual size, preventing visual distortion and improving the user experience. This change improves the overall usability of the Control Panel.
Original PR description
The `o_embedded_actions` buttons are getting cropped when they are long enough. This is due to the `overflow-hidden` property which is now applied when no element are actively dragged. When an element is dragged after a css transformation, eg. the `o_dragged_embedded_action`, `getBoundingClientRect()` is returning the element height with the transformation. This creates an excess height on the `o_embedded_actions` due to the placeholder button having it's transformed height instead of the button height. Using offsetHeight returns the element size without the transform. Note this is not done on the width, because the width without the transform can lead to text-truncation. task-5225696 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234120
This update fixes an issue where tax calculations were inaccurate for taxes with negative rates, and prevented errors related to missing payment method information. This ensures accurate financial reporting and avoids potential payment processing problems within the Odoo Enterprise system.
Original PR description
This PR complete the fix in the following PR: https://github.com/odoo/enterprise/pull/104619 The TTC value was incorrect for taxes with negative tax rate An error may be raised if bill_data['payment_method'] is None opw-5002779 Forward-Port-Of: odoo/enterprise#104731
This update fixes a test that was intermittently failing due to inconsistencies in how inbox messages are marked as read. The change ensures the test waits for the initial message fetch, preventing a common failure scenario and improving the reliability of inbox read marking. This enhances the overall stability of the Odoo messaging system.
Original PR description
The `Opening thread with needaction messages should mark all messages of thread as read` ensures that opening a channel marks the related inbox messages as read. However, this test can fail in a non-deterministic fashion. There are two flows that can mark inbox messages as read: fetching the messages or a manual request after opening the channel. The test expects the rpc to be issued, but if the messages are fetched before, it won't happen thus making the test fail. This commit awaits the initial fetch to prevent this issue. As a bonus, the second flow is also tested. runbot-237970 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 update ensures that optional product images are only shown when the system is configured to display them. Previously, images were always shown, even when disabled, leading to a cluttered user experience. Now, a placeholder is used when no image is available, aligning the display with the 'Show product images' setting.
Original PR description
Before this commit: =================== - When the `Show product images` setting was disabled, the optional products UI still displayed product images. - If an optional product did not have an image, the UI displayed the image's alt text - Also when the product don't have image, the combo popup and product card just display the product name. After this commit: ================== - Optional product images are displayed only when the `Show product images` configuration is enabled. - If the optional product doesn't have an image, we will display an image placeholder instead of alt text. - If there is no product image, the combo popup and product card will display the image placeholder. Task: 5480181 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a problem where the payer company was incorrectly identified in the 1099 report when using multiple companies. The fix ensures that each 1099 report accurately reflects the correct payer company for each invoice, improving report accuracy and compliance. This impacts users with multi-company configurations.
Original PR description
When generating 1099 report with multicompany setup, the payer company is wrongly assigned in the csv file. Steps: - Have 2 companies - Make one bill per company with one different 1099 vendor for each one - With both companies selected, generate the 1099 report - open the csv file -> Payer name is the same for both line opw-5442190 Forward-Port-Of: odoo/enterprise#104660 Forward-Port-Of: odoo/enterprise#103805
This update ensures that admin users cannot modify course ratings left by other users. Previously, edits to course reviews could unintentionally alter the original ratings. This change prevents data inconsistencies and maintains the integrity of course feedback.
Original PR description
*: website_slides The default values for the admin user should not be changed by editing or deleting others' messages in courses. task-5326273 **Note:** Following the first commit in this PR, the fix in PR #239554 is no longer required. So the second commit here reverts commit 89f4d0365b05b4a51c6017d5b3b67bd8e7b829ff, ensuring that the fix remains within the portal_rating module and preventing duplicate code for the same issue. See [this](https://github.com/odoo/odoo/pull/236475#issuecomment-3749796345) for more information. Forward-Port-Of: odoo/odoo#243314 Forward-Port-Of: odoo/odoo#236475
This update fixes a potential issue with Turkish invoice documents (l10n_tr_nilvera) by correcting the default journal type. Previously, the default was set incorrectly, which could have led to improper accounting. Now, the default is set to 'purchase' to ensure accurate and compliant document handling.
Original PR description
…hing The default value of the journal type parameter was incorrectly set to a move type (`in_invoice`). Although all current callers explicitly pass the correct journal type, the default value has been corrected to `purchase` to avoid potential misuse. no task-id Forward-Port-Of: odoo/odoo#242865
This update removes incorrect integer rounding from monthly VAT reports for Italian businesses (l10n_it). Previously, rounding was applied to monthly reports due to a change made in a previous update. This change ensures accurate monthly VAT reporting, aligning with Italian tax regulations. This fix resolves an issue impacting financial reporting accuracy.
Original PR description
**Description of the issue/feature this PR addresses**: Integer rounding is only required on annual l10n_it VAT reports. It appears that it was incorrectly added to the monthly report when the two were split in #193662. **Current behavior before PR**: Integer rounding on monthly l10n_it tax reports. **Desired behavior after PR is merged**: No more integer rounding on monthly l10n_it tax reports. [opw-5292310](https://www.odoo.com/odoo/project.task/project.task/5292310) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243671 Forward-Port-Of: odoo/odoo#243100
This update removes unnecessary integer rounding from the monthly Italian VAT reports. The rounding was mistakenly carried over from annual reports due to a previous split in the codebase. This ensures accurate VAT reporting for Italian businesses.
Original PR description
Integer rounding is only required on annual l10n_it VAT reports. It appears that it was incorrectly added to the monthly report when the two were split in [#193662](https://github.com/odoo/odoo/pull/193662). [opw-5292310](https://www.odoo.com/odoo/project.task/project.task/5292310) Forward-Port-Of: odoo/enterprise#104228 Forward-Port-Of: odoo/enterprise#103852
This update fixes a potential issue where users could create duplicate tax names in different branches of Odoo. Previously, the system only checked for duplicates within the branches a user could access. Now, Odoo checks all branches to guarantee unique tax names, preventing conflicts and ensuring data accuracy across the entire organization.
Original PR description
**Description of the issue/feature this PR addresses:** In companies with many branches, a user could create a tax name that already exists in another branch. This happened because Odoo only checked for duplicates in the branches the user could see. To reproduce: 1. Create `Branch A` and `Branch B`. 2. A user with access ONLY to `Branch A` creates "Tax 1". 3. A user with access ONLY to `Branch B` creates "Tax 1". 4. Both are saved, creating a duplicate name. This fix adds sudo() to the check. Now, Odoo will check all branches to make sure the name is unique, even if the user cannot see the other branches. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243185
This update fixes a layout issue with image galleries containing many images, preventing indicator crowding. It also addresses a laggy feeling in image galleries due to lazy loading, improving the overall user experience by preloading carousel images and optimizing image loading timing.
Original PR description
## [FIX] website: add versioning for GallerySlider interaction The GallerySlider interaction (and its edit mode counterpart) is not up to date: the logic is still written for old snippets (before…
## [FIX] website: add versioning for GallerySlider interaction
The GallerySlider interaction (and its edit mode counterpart) is not up
to date: the logic is still written for old snippets (before [9042b1c],
so before 18.0).
In the meantime, the pagination for the indicators was lost, meaning
that if you add too many images, the indicators will have less and less
space.
Steps to reproduce:
- Drop an Image Gallery snippet
- Set the indicators to squared or rounded miniatures
- Add 15 or more images
=> All the indicators are crammed into the same line.
With this commit, we deprecate the old `GallerySlider` interaction and
create a `GallerySlider001` for the snippets dropped since 18.0.
For the indicators, instead of a pagination, we now use a horizontal
scrolling container which centers on the active indicator.
[9042b1c]: https://github.com/odoo/odoo/commit/9042b1c
## [FIX] website: preload available carousel images
As images are lazy loaded, it means that in the context of a carousel or
an image gallery, they only start loading once the user clicks either on
its indicator or on the previous / next button (or after completing an
auto-slide). While Chrome seems to optimize that to make it seemless, on
Firefox this causes the carousel slide to appear blank for a moment
before the image suddenly pops up, as the sliding animation arrives to
its end.
In effect, this causes a flicker and a feeling that the carousels, and
especially the gallery, is extremely laggy.
To mitigate that while trying to keep the advantages of image lazy
loading, this commit partially backports [08d837e], which loads the
images of the next and the previous carousel items.
Additionally, we prefetch the target images on pointerdown / keydown on
an indicator. That may seem like too small of a difference to be
interesting, but it actually gives a little bit of time between the
pointerdown and pointerup (which triggers the slide event) to start
loading the images, which with a correct connexion already goes a long
way towards mitigating the laggy feeling.
[08d837e]: https://github.com/odoo/odoo/commit/08d837e70f28a84a9bd97974f5d15d387a42b7c0
task-5245513
Forward-Port-Of: odoo/odoo#232147This update resolves an issue where GS1 barcodes triggered a validation error, preventing users from scanning products correctly. The fix allows the system to gracefully handle GS1 barcodes that are misinterpreted as dates, ensuring consistent product scanning functionality within the Odoo Enterprise system.
Original PR description
Steps to reproduce: - Activate the GS1 nomenclature - Create a product with barcode: 15099590483921 - Scan the product from the Barcode app main menu Problem: A ValidationError is raised: "A GS1…
Steps to reproduce: - Activate the GS1 nomenclature - Create a product with barcode: 15099590483921 - Scan the product from the Barcode app main menu Problem: A ValidationError is raised: "A GS1 barcode nomenclature pattern was matched. However, the barcode failed to be converted to a valid date." Explanation: GS1 barcodes must follow a strict nomenclature based on well-defined rules. For example, a GS1 product barcode should start with the Application Identifier 01 followed by 14 digits. The GS1 parser processes the barcode rule by rule and applies the first matching rule. In this case, the barcode 15099590483921 is interpreted as a date because it starts with "15", which corresponds to a GS1 Application Identifier for a date. As a result, the parser attempts to convert the first six digits into a date and raises a ValidationError. Solution: Catch the ValidationError raised during GS1 date parsing in main_menu and explicitly reset parsed_results to False, allowing the normal main menu resolution logic to continue. This prevents GS1 parsing errors from blocking valid barcodes and ensures that product, picking, or location detection still works as expected. opw-5357611 Forward-Port-Of: odoo/enterprise#104641
This update fixes a bug that occurred when users tried to change a tax lock date to a past date. The change prevents the system from generating incorrect default values for reports, ensuring accurate financial reporting. This resolves a potential error that could have impacted data accuracy.
Original PR description
To reproduce the issue, on a company in Luxembourg: 1) Set a tax lock date to November 30th 2) Attempt to change the tax lock date to November 15th ===> Lock date violation error. This happens because _generate_default_external_values still gets called in case the lock date is set back in the past (since _get_current_period_dates call in _create_default_report_external_values returns a tuple basically containing (former lock date + 1 day, new lock date)). Doing so, it tries generating a default external value with a value of 0 (because no data will ever be available in such an impossible date interval), but the previously set lock date prevents it, and raises the error. opw-5383010 Forward-Port-Of: odoo/enterprise#102756
This update resolves an issue where Time-Off Responsibles lacked the necessary permissions to refuse approved leave requests. The fix ensures they can properly manage leave by correctly handling access rights during the refusal process, preventing access errors.
Original PR description
****Behavior:**** When a user who is Time off Responsible but not Officer or Admin and is marked as responsible for an employee tries to refuse a fully accepted leave an access error occurs. This…
****Behavior:**** When a user who is Time off Responsible but not Officer or Admin and is marked as responsible for an employee tries to refuse a fully accepted leave an access error occurs. This occurs because approving a leave creates a resource.calendar.leave linked to the hr.leave, and when refusing it, the system will try to unlink it. https://github.com/odoo/odoo/blob/72e8a29dd0edb0ca3d464142ce869f38f96c730a/addons/hr_holidays/models/hr_leave.py#L896-L901 According to access rules of r.calendar.leaves, Time-off Responsibles are not allowed any access for entries of other employees. Approving them doesn't cause an error because the create operation uses sudo(), assuming that the user must have had valid rights to access the function. This is not the case for the unlink. **Solution:** This fix checks wether the user has write access to the related hr.leave record, then uses sudo(). The idea is that if they are allowed to modify the state of the leave, they can refuse the leave, and therefore should be able to go through the following operations. This is in a similar fashion as the behavior for approving the leaves. ****Steps to Reproduce:**** - Create a Leave Type that requires validation from a manager, and assign one to an employee. - Remove any access rights to Time-Off for the user, but leave Time off Responsible checked. - Assign the user as time-off responsible for the employee - Log in as the user and approve the leave - When refusing the leave, you should get an access error. opw-5178783 Forward-Port-Of: odoo/odoo#238205
This update fixes an error in how price differences are calculated for subcontracted products. Previously, the system incorrectly compared costs in different currencies, leading to inaccurate price difference invoices. Now, the system automatically converts component costs to the invoice currency, ensuring correct price difference calculations and accurate reporting.
Original PR description
Problem: When computing the price difference on a vendor bill for a subcontracted product, the component cost is considered in the company's currency regardless of the currency of the invoice. This…
Problem: When computing the price difference on a vendor bill for a subcontracted product, the component cost is considered in the company's currency regardless of the currency of the invoice. This means the price difference calculation directly compares two different currencies without converting them, resulting in some incorrect values for the price difference invoice lines. Solution: We will convert the component cost to the invoice currency when computing price difference. Steps to reproduce (runbot 18): - Product with - Standard price auto - BoM: sbc, one component with nonzero value (e.g. $1) - Nonzero value (e.g. $5) - Another currency 1. Create a PO for the subcontracted product 2. Set the Invoice currency to something other than the company default 3. Confirm the PO and validate the sbc and receipt 4. Create the vendor bill, and bill for the correct value (Whatever $4 is in the invoice currency) A price difference line will be erroneously generated for some nonsense value, when we expect 0 price difference. opw-5232917 Forward-Port-Of: odoo/odoo#243801 Forward-Port-Of: odoo/odoo#238428
This update fixes a critical issue where the Moroccan tax report XML export incorrectly reflected all bills in a period, ignoring the default cash basis accounting. The fix uses a new SQL query to accurately calculate taxes, ensuring consistent and reliable data in the export. This improves data accuracy and efficiency.
Original PR description
[FIX] l10n_ma_reports: tax report: properly consider cash basis taxes in the XML export Moroccan taxes are cash basis by default. The former version of the XML generation completely disregarded that,…
[FIX] l10n_ma_reports: tax report: properly consider cash basis taxes in the XML export Moroccan taxes are cash basis by default. The former version of the XML generation completely disregarded that, and always reported all bills in the period. Solving this requires using an SQL query so that cash basis can be properly computed, like in the report. This also makes the export much more efficient, and resilient to bigger amount of data. Steps to reproduce: - Install `l10n_ma_reports` and switch to the MA company - Create and confirm a bill: Bill Date: 10/01/2025 Vendor: Azure Interior Invoice Lines: Price 100, Taxes 20% (S 140) - Go to `Bank Reconciliation` - Add a transaction (Vendor: Azure Interior, Amount: -120 DH, any Memo) - Select the transaction and the invoice, then click Validate - Open the Tax Return for November. Section D should show data linked to the created invoice - Export the XML using the Gear → XML The created bill is missing in the XML and others may be present, showing inconsistent data opw-5002779 [IMP] l10n_ma_reports: call the report to compute the prorata value Searching explicitly for external values is a bad practice ; calling the report ensures consistency between the data displayed, and the one exported into the file. Forward-Port-Of: odoo/enterprise#104619
This update corrects a bug where the 'Import Bank Statement' action incorrectly selected a journal in multi-company environments due to elevated server permissions. The fix ensures the action now filters by the currently chosen company, preventing incorrect journal selection and improving data accuracy. A new test confirms the fix's reliability.
Original PR description
Issue: when using the server action 'Import Bank Statement' the code would not filter on the currently selected company for choosing the journal on which to encode the bank statement and simply take the first result. Because the server action is running with sudo rights, in a multi-company environment more then one journals are found and the selected one is often wrong. Solution: filter on company during the selection of the journal. Note: a test was added in which we run the function with sudo rights to ensure an error is raised when the journal does not exist on the currently selected company, even if it is present on another company. Task-5494685 Forward-Port-Of: odoo/enterprise#104326
This update fixes an issue where product names on invoices were being incorrectly combined, leading to unreadable output. The change replaces newlines with spaces, ensuring names and descriptions remain clear and adhere to API specifications, improving the accuracy of VAT processing for Vietnamese businesses.
Original PR description
Before: SInvoice was stripping newlines from the `itemName` field. Since we were directly using `line.name` (which contains a `\n` between product name and description), the content ended up concatenated without any separation. After: Now we replace the newline with a space before sending the value, so the name and description remain readable once processed by SInvoice and set limit to 500 characters as per API specs. task-5498120 Forward-Port-Of: odoo/odoo#243994