Friday, January 16, 2026
37 changes · 19.0
Resolved issues and error corrections
This update fixes an issue where only the first attachment from an expense was included in the generated journal entry. The change ensures that all attachments associated with approved expenses are correctly copied, improving the accuracy of financial reporting. This prevents data loss and provides a more complete record of expenses.
Original PR description
**Steps to reproduce:** * Install **hr_expense** and **accounting** modules. * Create two or more expenses, each with **multiple attachments**. * Submit and approve the expenses. * Create the **journal entry** of all approved expenses. * Open the generated journal entry and review its attachments. **Observed behavior:** * Only the **first attachment** from each expense is present on the journal entry. * Additional attachments are missing. **Cause:** * while creating journal entry, the logic of expense iterate on `message_main_attachment_id`. * `message_main_attachment_id` stores only a **single attachment**, so only one file per expense is copied. **Fix:** * Iterate on `attachment_ids` instead of `message_main_attachment_id`. * Ensures **all attachments** from each expense are included in the generated journal entry. opw-5414834 Forward-Port-Of: odoo/odoo#243962 Forward-Port-Of: odoo/odoo#241044
This update fixes a bug where changes to analytic distribution weren't being saved correctly when editing a line in the Bank Reconciliation Widget. Now, when you leave the line editing field, the analytic widget automatically closes and retains your changes, mirroring the behavior of other widgets like invoices. This ensures data consistency and a smoother user experience.
Original PR description
**Issue** When editing a line on the reco widget, close and keep change on analytic widget on unfocus **Steps to Reproduce** 1. Activate Analytic Accounting 2. Go on the Bank Reconciliation Widget 3. Edit a line 4. Change the Analytic Distribution. 5. Click elsewhere. 6. The Analytic Widget should close and keep the changes. (as it does on invoices) **Fix** Properly detect the condition for closing the widget. task-5232476 Forward-Port-Of: odoo/odoo#234398
This update resolves an issue where applying a zero-amount discount in the sales order system would cause an error. The fix ensures the system handles zero discounts gracefully, preventing disruptions to the sales process. This improves the reliability of discount application.
Original PR description
The system raises an error when the user tries to apply a fixed amount discount of 0.0. **Steps to produce:** - Install `Sales` module with demo data. - From the settings enable `discount`. - Make a sale order with product > click on Discount > click Fixed Amount and set amount as `0.0` > click on apply. **Error:** `ZeroDivisionError : float division by zero` **Cause:** - When the discount amount is set to 0.0, at [1] we attempt to compute the factor, which causes an error due to a division by zero. **Solution:** - Added a condition to check that current_base_amount_currency is not zero, and if it is, set the factor to 0.0. [1]: https://github.com/odoo/odoo/blob/10887c3081afbfd0734c6a3ac24301c94d14bc24/addons/account/models/account_tax.py#L3718-L3720 **sentry-6967181350** I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233151
This update resolves an issue where users would encounter access errors when closing the 'Thank You' dialog after signing a document from a record they couldn't access. The fix ensures the system checks for read access to the related record before redirecting, eliminating these errors and improving the user experience.
Original PR description
Version: - 18.0 Steps to reproduce: - Send a signature request to an internal user from a record that the signer cannot access. - The user signs the document and then tries to close the Thank You dialog. Before: - When a user signs a document sent from a record they don’t have access to, closing the "Thank You" dialog triggers an access error. - This happens because the system tries to open the related record after signing, but the signer does not have permission to view that record. After: - Now the system first checks if the signer has read access to the related record before redirecting. Impact: - Users will not see an access error message after signing a document. task-5353126 Forward-Port-Of: odoo/enterprise#104161 Forward-Port-Of: odoo/enterprise#100961
This update fixes an issue where gift card PDFs were generated even after the card's points were fully used. The change ensures that PDFs are only created for gift cards with a remaining balance, streamlining the POS process and reducing unnecessary reports. This improves the user experience and prevents redundant document generation.
Original PR description
**Steps to produce:** - Install `pos_loyalty` module. - Go to POS > select clothes > Load sample data > Buy one gift card. - Now make another order > add product above 50 > use the gift card. -…
**Steps to produce:** - Install `pos_loyalty` module. - Go to POS > select clothes > Load sample data > Buy one gift card. - Now make another order > add product above 50 > use the gift card. - Complete payment. **Issue:** - Even when the gift card is fully consumed (its points are reduced to 0), a gift card PDF is still generated after the POS payment. **Root cause:** - In `_process_existing_gift_cards` ([1]), when a gift card is updated, it is always added to `updated_gift_cards` and returned. - Later, at [2], all gift cards in updated_gift_cards are used to generate and print PDFs, without checking whether the remaining points are 0. **Solution:** - Do not generate or print a PDF for gift cards whose points are 0 after being updated. Only gift cards with a positive remaining balance should be included for PDF generation. [1]https://github.com/odoo/odoo/blob/57206cc4e3dd988382a063517546ca5dcd74da58/addons/pos_loyalty/models/pos_order.py#L236-L237 [2]https://github.com/odoo/odoo/blob/57206cc4e3dd988382a063517546ca5dcd74da58/addons/pos_loyalty/models/pos_order.py#L132-L133 opw-5474006 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a visual glitch in Firefox where the page would jump after undoing actions involving tall snippets. The team adjusted how snippets are scrolled to the top, which is now the preferred behavior for larger snippets. This ensures a smoother and more consistent user experience.
Original PR description
Steps to reproduce: - On Firefox, drop a snippet taller than the page height. - Remove it. - Undo. => The page shows a white gap until you scroll again. Same issue when showing a hidden tall snippet. After investigation, no real explanation was found for this bug in Firefox. We only observed that changing the "center" parameter to "start" in the "scrollIntoView" function fixes the issue. In the end, this is not a bad idea, since scrolling a snippet to its beginning arguably makes more sense than centering it, especially when the snippet’s height is larger than the viewport. task-5194559 Forward-Port-Of: odoo/odoo#241518
This update fixes an issue where read-only accounting users couldn't access the 'Customer Statement' button within customer records. The change ensures that read-only users with accounting permissions can now view customer statements, improving usability for a wider range of users. This resolves a restriction in user access controls.
Original PR description
Steps to reproduce: - Have a user with Accounting rights set to 'Read-only' - Login with the user - Open customer record - Button 'Customer Statement' won't be there Analysis: This occurs because we restrict the button visibility to 'Invoicing' users, even if all fields and views are accessible also for 'Read-only' users. opw-5357692 Forward-Port-Of: odoo/enterprise#103148 Forward-Port-Of: odoo/enterprise#102683
This update removes a redundant CSS class from the Point of Sale module. The class was previously set to a maximum width but was no longer being used. This cleanup improves the codebase and reduces potential styling conflicts, ensuring a cleaner user interface.
Original PR description
The issue was to put the button css class at a max width of 200px. But it's not used anymore. So it can be deleted bug was created from this pr : https://github.com/odoo/odoo/pull/243770 task : 5493872 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243831
A customer modified gift card and e-wallet products to be tracked in stock, which caused a technical inconsistency. This fix prevents these products from being automatically converted back to service types, maintaining accurate stock levels. Given multiple similar requests, a broader solution is being considered.
Original PR description
The customer changed the service-type products “Gift Card” and “E-Wallet” to storable products and used them in stock. May be they could use as physical gift cards, and physical e-wallets for company. As a result, these products now have on-hand quantities, which creates an issue. After the upgrade, they will be converted back to service-type products, causing an on-hand quantity inconsistency in the test case. To avoid this error, we need to keep these products as storable. TO do that we have to mark them noupdate. This is a customer-specific change, but since we have received many similar requests, we should consider making a generic fix if possible. 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#242555 Forward-Port-Of: odoo/odoo#237517
This update resolves an issue where the USB printer functionality would stop working when a printer lid was open. The fix ensures the printer driver correctly handles situations where data isn't immediately available, preventing unexpected errors and maintaining reliable printing.
Original PR description
When using the `python-escpos` library with a USB printer, we had to patch the read method to retry due to the result not always being immediately available. However, in the case where all the retries are exhausted, it currently returns `None`, whereas the library always expects a `bytes` result. This commit fixes the issue by returning `b""` when no result can be read. This prevents the `python-escpos` functionality from being disabled when the printer lid is open. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244043
This update fixes a minor issue in the Point of Sale tour testing process. By adding a final check to ensure a paid order exists, the tour now reliably completes. This ensures that the testing process is consistent and accurate, preventing potential disruptions to the tour.
Original PR description
By adding a last step ( that check that there is at least one paid order), we ensure that the RPC is done before closing the tour. error-runbot-id~233511 error-runbot-id~232677 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 fixes an issue where numbers extracted from OCR boxes were incorrectly formatted due to language settings. The change simplifies the parsing process by consistently using a standard Javascript `Number` parser, ensuring accurate number representation regardless of the user's language. This improves data integrity for financial transactions.
Original PR description
When using a language that doesn't use a dot as decimal separator, the number parsed from the box content was incorrect. For example, if the content of the box was "1234.56", the parsed value would have been "123456". This happened because the float parser available through the registry takes into account the language of the user and its configured thousands/decimal separators. Since the content of the boxes are always formatted as "1234.56", without thousands separator and with a dot as decimal separator, the regular `Number` parser of Javascript can be used to get consistent results. opw-[5427979](https://www.odoo.com/odoo/49/tasks/5427979)
This update resolves an issue where gift cards were being printed repeatedly during point-of-sale transactions. Now, gift cards are only printed once at the time of creation, streamlining the process and reducing unnecessary printing. This improves efficiency and reduces waste.
Original PR description
*: pos_loyalty Gift card are now printed only one time at the creation not after each use.
This update corrects a bug in how the system determines if a stock location is a child of another. The change uses a more precise method (`indexOf`) to ensure accurate sublocation identification, preventing errors that could cause test failures. This improves the reliability of stock operations.
Original PR description
Previously, in the `_isSublocation`, to check if a location was a children of another location, we did that: ```javascript return childLocation.parent_path.includes(parentLocation.parent_path); ```…
Previously, in the `_isSublocation`, to check if a location was a children of another location, we did that: ```javascript return childLocation.parent_path.includes(parentLocation.parent_path); ``` The issue with that is, if locations' id are aligned, they can match even if they are not related. For example, imagine tested child location has ID 127 and the parent location has ID 7, we then check their `parent_path` (for example, '4/127/' for the child location and '7/' for the parent location), it can happen the child parent path can include the parent's parent path (in our example, '4/127/' includes '7/'.) To fix that, this commit replaces `includes` with `indexOf`, the result of the `indexOf` should always be 0 if the child location is indeed a sublocation of the parent location. Because of this issue, the second run of the tour `test_put_in_pack_new_lines` could sometime fail when the locations IDs are aligned. runbot build error: [233292](https://runbot.odoo.com/odoo/runbot.build.error/233292) Forward-Port-Of: odoo/enterprise#104350
This update corrects a bug in the HTML editor that was causing an error when attempting to remove formatting from cells with lingering colors. Previously, deleting text and leaving a colored cell would trigger an infinite loop. Now, users can reliably remove formatting from empty colored cells without encountering this issue.
Original PR description
**Current behavior before PR:** Steps to reproduce: - Create a m x n table - Write some text in a cell, apply color on text - Delete text and keep empty colored element - Select cell - Trying to remove format throws infinite loop error in removeAllColor **Desired behavior after PR is merged:** Clicking on remove format button should remove color from empty colored element without causing traceback. task-5454993 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242938 Forward-Port-Of: odoo/odoo#241829
This update fixes an issue where filtering work entries by country wasn't functioning properly, leading to errors. The fix ensures country-based searches and filters work as intended, resolving a technical problem that prevented accurate reporting and data management. This improves the reliability of our HR data.
Original PR description
Issue: The country_id related field on work entries was not stored, causing domain filters and search on this field to fail and triggering client-side errors. Fix: Use search parameter on field to write function so field can be used safely in search domains and filters. Impact: Country-based filtering now works correctly without triggering module loader errors. Task: 5406904 Forward-Port-Of: odoo/odoo#243428 Forward-Port-Of: odoo/odoo#239573
This update resolves a technical error that prevented users in India from successfully processing payments through Razorpay within the Point of Sale (POS) system. The issue stemmed from an attempt to use 'sudo' on a Razorpay-related object, which wasn't designed to support this function. Removing this unnecessary access ensures smooth payment processing.
Original PR description
Steps: - Configure a Razorpay payment method in POS with Indian localization. - Open a POS session and process an order. - Start the Razorpay transaction. Issue: - An error pop-up is shown: 'RazorpayPosRequest' object has no attribute 'sudo'. Cause: - The code attempts to call sudo() on RazorpayPosRequest, which is not a model and does not support sudo. Fix: - Remove the unnecessary sudo() access from RazorpayPosRequest. Task-5501634 Forward-Port-Of: odoo/odoo#244177
This update resolves an issue preventing stable IoT Box responses from being correctly read. By adding a check for a 'result' key in the data, the system now reliably processes data from these terminals, ensuring smoother operation. This enhances the overall stability and usability of the IoT integration.
Original PR description
We now read data in result key if it exists to ensure readability of stable IoT Box responses. Forward-Port-Of: odoo/enterprise#104360 Forward-Port-Of: odoo/enterprise#104113
This update fixes an issue where website location requests repeatedly failed for invalid warehouse addresses. Now, when geolocation fails for an address, it sets default coordinates, preventing endless attempts and improving the user experience. This ensures accurate location data is displayed on the website.
Original PR description
When a warehouse location had no coordinates, a request to geolocate the address was made to OpenStreetMap every time the location selector was open. However, when the address was invalid, the geolocation failed, and no coordinates were set, which caused further geolocation requests being continuously sent. This commit changes the geolocation behavior to set invalid coordinates for the address when the request fails, thus disabling future geolocation attempts for that address.
This update fixes a display issue in the Point of Sale product information popup. Previously, it only showed the first tax applied to a product. Now, it correctly displays all taxes, separated by commas, providing a more accurate and complete view for sales transactions.
Original PR description
Before this commit: --- - The POS product info popup displayed only the first tax from `tax_details`, which meant multiple applied taxes were not visible. - The logic fetched a single tax name instead of all tax applied to the product. After this commit: --- - The POS store sends a full list of tax names instead of a single name. - The popup template displays all tax names, comma-separated. task-5406826 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a problem in the payroll testing process where contract end dates weren't being calculated correctly. The fix ensures contracts automatically end after two years, aligning with standard payroll practices. This improves the reliability of payroll calculations and reporting.
Original PR description
### Cause: Apparently the contract ends automatically after a period if `contract_date_end == False` ### Solution: Set `contract_end_date` to ` Date.today() + relativedelta(years=2)` like in `hr_payroll/tests/common.py` error-237945
This update resolves a technical issue that was preventing the generation of follow-up reports for certain customer records. It now automatically sets ‘no_followup’ for general customer entries, ensuring accurate reporting. This change improves the reliability of customer statement and follow-up report generation.
Original PR description
* Fix traceback when opening the follow-up report and customer statement. * General(MISC) entries should be no_followup by default. Except entries coming from pos should not be excluded from follow-ups. Forward-Port-Of: odoo/enterprise#104500 Forward-Port-Of: odoo/enterprise#104433
This update removes a feature that allowed users to directly open folders from the sync configuration list. This change simplifies the process of selecting and editing configuration rows, leading to a more user-friendly experience. The removal addresses a usability issue that was causing confusion.
Original PR description
Previously, clicking a folder in the sync configuration list redirected the user to the folder view, which made it difficult to select or edit the configuration row. To improve usability, the ability to open folders directly from `documents_account.documents_folder_setting_view_list` has been removed. task-5212503
This update prevents notifications for other recipients from being incorrectly marked as 'bounced' when a single bounce notification is received. The fix addresses a technical issue where an outdated search domain incorrectly matched all notifications linked to a message, leading to inaccurate bounce reporting. This ensures more reliable notification tracking.
Original PR description
When a bounce is received for one recipient of a message sent to multiple partners, notifications for other recipients can be incorrectly marked as “bounced”. Reproduction Steps: 1. Configure an…
When a bounce is received for one recipient of a message sent to multiple partners, notifications for other recipients can be incorrectly marked as “bounced”. Reproduction Steps: 1. Configure an incoming mail server with a bounce alias. 2. Create multiple contacts with different email addresses. 3. Send a message that notifies multiple contacts. 4. Process a bounce email related to only one recipient. 5. Observe that notifications for other recipients of the same message are also marked as “bounced”. Root Cause: During bounce processing, `MailThread._routing_handle_bounce` builds a search domain to identify which `mail.notification` records should be updated. The original implementation constructed an `OR` domain that could include empty domain elements (`[]`) when some bounce identification data was missing. In Odoo’s domain logic, an empty domain represents a constant “match all” condition. When such a domain is included in an `OR`, the entire expression can match all notifications linked to the message, rather than only those related to the bounced recipient. Fix: The domain used to select bounced notifications is now built dynamically. Criteria are only added when the corresponding bounce identification data is present. opw-5349170
This update ensures that Odoo accurately flags modules imported with demo data. This improvement will enhance the reliability of industry testing by providing clearer information about which modules were initially populated with demo content. It resolves a previous oversight that impacted testing processes.
Original PR description
Currently even if a imported module was imported with demo data, the 'demo' field is not set to True. Setting this field proprely will allow to have a better handling of demo data in industry tests. Backport of https://github.com/odoo/odoo/pull/243032
This update resolves an issue where a deleted floor would reappear in the floor selector after a refund was processed on a related order. The fix filters out inactive floors, ensuring the floor selector accurately reflects available tables and improving the user experience. This prevents confusion and ensures data consistency.
Original PR description
Task: [#5421683](https://www.odoo.com/odoo/project/1737/tasks/5421683) --- **Steps to reproduce:** * Create a new floor with one table * Create and pay an order on that table * Delete the floor * Refund one line of the order ==> The deleted floor is shown again in the floor selector, without its table. This happens because the deleted floor is loaded when fetching the table of the order in the Ticket Screen. If an order is linked to a table that belonged to a deleted floor, that floor is loaded again and displayed in the floor selector. **Fix:** Filter out inactive floors from the floor selector.
This update resolves an issue where users received an error when attempting to unbuild tracked components in a manufacturing order. The fix ensures that component serial numbers are not reused, preventing validation errors and ensuring accurate inventory tracking. This improves the reliability of the manufacturing process.
Original PR description
Steps to reproduce the bug: - Create a storable product P1 - Tracking: Serial Number - BoM: Component: 1 unit of C1, tracked by Serial Number - Update the inventory of C1 - 1 unit with SN1 - 1 unit…
Steps to reproduce the bug:
- Create a storable product P1
- Tracking: Serial Number
- BoM: Component: 1 unit of C1, tracked by Serial Number
- Update the inventory of C1
- 1 unit with SN1
- 1 unit with SN2
- Create a Manufacturing Order to produce 2 units of P1
- Confirm and validate the MO using serials SN1-P1 and SN2-P1
- SN1 and SN2 of C1 are consumed
- Unbuild 1 unit of P1 with serial SN1-P1 Result: SN1 of C1 is correctly restored
- Unbuild 1 unit of P1 with serial SN2-P1
- Try to validate the unbuild
Problem:
A user error is raised:
"The serial number SN1 has already been assigned"
This happens because _action_unbuild attempts to reuse the same component serial number (SN1 of C1) without checking whether it has already been consumed by a previous unbuild operation on the same Manufacturing Order.
Solution:
This fix ensures that, when unbuilding tracked products, component serial numbers already used by previous unbuilds of the same MO are excluded from the candidate move lines.
This prevents reassigning the same serial number multiple times and avoids the validation error.
opw-5441256This update resolves an issue where Point of Sale orders with custom sequence prefixes were generating errors due to data type mismatches. The fix ensures that sequence numbers, including custom prefixes, are correctly stored and used, preventing order processing failures. This improves the stability and reliability of the POS system.
Original PR description
**Steps to reproduce:** - Go to the sequence interface, and chose the config number 1 for a pos.order - In the prefix field, enter something with characters that are not numbers - Go to a PoS with config number 1 active and make a purchase - A traceback appears saying that we can't convert the sequence to an Integer **Why the fix:** Having a custom prefix with letters used to work, but in version 19, we now store the sequence_number with the prefix, which can be composed of characters which can not be stored in an Integer field such as sequence_number. To prevent this error, we remove the prefix and the suffix (which has the same issue) from the sequence_number before storing it. We then add the prefix and the suffix back when computing the order's name, so that it's consistant with the prefix and the suffix the user chose. This is the way the order's name was computed before version 19.0, which saw the prefix and suffix disappear from the order's name. opw-5386575
This update fixes a problem where customers couldn't change product selections in the Point of Sale configurator when multiple attribute combinations were restricted. The issue was previously resolved but reintroduced. The fix removes code that incorrectly disabled options, allowing customers to freely select their desired product combinations.
Original PR description
Step to reproduce: - Create 2 attributes with 2 values each A1V1 A1V2 and A2V1 A2V2 - Create a product with these attributes and set the attribute exclusion so that only 2 valid combinations are possible. (ex: a1v1 excludes a2v2 and a1v2 excludes a2v1) - Open PoS and try to add the product to the cart. - The configurator popup will appear. Observation: - You will not be able to change the selection because the other combinations are not correct. Cause: - The issue was already fixed [1] but issue was reintroduced in [2] Fix: - Remove the code, which was causing the issue, we shouldn't disable an option and allow customer to change the combiantion [1] https://github.com/odoo/odoo/commit/5864780ed703f61d763e1b49c33da3bbf8ca32f2 [2] https://github.com/odoo/odoo/commit/6e7c663543ba2b219d492795971f42e3e2c1213e opw-5418977 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where cash order creation was missing essential information like company and user details. Previously, orders weren't properly linked, leading to potential data discrepancies. This change ensures cash orders are created with accurate context, improving order tracking and reporting within the Point of Sale system.
Original PR description
Before this commit, the order for cash moves was created without setting the session_id, company_id, and user_id fields. opw-5500966 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a scheduling issue in the autovacuum cron job that was causing delays in database maintenance. The change ensures the cron job correctly reports partial progress, triggering a faster reschedule. Additionally, the code has been simplified for better readability.
Original PR description
**NOTE** the problem regarding the auto-vacuum was fixed in 18.3 and above (including master) at https://github.com/odoo/odoo/pull/216483, this PR now solely exists for branlette intellectuelle. Have…
**NOTE** the problem regarding the auto-vacuum was fixed in 18.3 and above (including master) at https://github.com/odoo/odoo/pull/216483, this PR now solely exists for branlette intellectuelle. Have a ir cron action with the following code: time.sleep(MIN_TIME_PER_JOB) self.env['ir.cron']._commit_progress(remaining=1) return The code looks stupid, but we tracked down a bug we had in the autovacuum cron in 18.3, and the minimum code to reproduce the problem is that above line of code. Since there are remaining stuff to do, the cron worker should report a `PARTIALLY_DONE` status, and reschedule to call the cron action asap. But the system currently determine a `FULLY_DONE` status and reschedule the cron action *later* (next day for a cron with an interval of 1 day). It is pretty bad for the autovacuum cron in 18.3 We used the opportunity to rework the `status` computation to one big match-case, for extra readability. 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#216116
This update fixes a display issue where tax names and invoice labels were shown in English for Vietnamese users. By adding the necessary Vietnamese translation columns to the chart template CSV, the system now correctly displays tax information in Vietnamese, improving the user experience for Vietnamese-speaking businesses.
Original PR description
The `name` and `invoice_label` fields on `account.tax` are translatable fields (translate=True), but the Vietnamese chart template CSV was missing the corresponding translation columns. This caused…
The `name` and `invoice_label` fields on `account.tax` are translatable fields (translate=True), but the Vietnamese chart template CSV was missing the corresponding translation columns. This caused tax names and invoice labels to display in English even when the user's language was set to Vietnamese. By adding the `name@vi_VN` and `invoice_label@vi_VN` columns to the tax template CSV, taxes will now display with proper Vietnamese labels when the chart of accounts is installed for Vietnamese companies, improving the user experience for Vietnamese-speaking users. Technical details: - Added `name@vi_VN` and `invoice_label@vi_VN` columns to the CSV header - Added Vietnamese translations for all tax records in the template - Translations follow Vietnamese tax terminology conventions - The chart template loader automatically processes columns with `@lang` suffix and applies them as translations for translatable fields 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#242437 Forward-Port-Of: odoo/odoo#236502
This update fixes a data inconsistency in Odoo. Previously, Bulgaria was linked to the Bulgarian currency (BGN). Now, it’s correctly linked to the Euro (EUR) to reflect Bulgaria’s adoption of the Euro as its official currency on January 1, 2026. This ensures accurate financial reporting and data for businesses operating in Bulgaria.
Original PR description
Description of the issue/feature this PR addresses: Bulgaria adopted the euro as official currency as of 2026-01-01. Update the base country data accordingly. Current behavior before PR: In `res_country_data.xml`, Bulgaria is linked to BGN. Desired behavior after PR is merged: Bulgaria is linked to EUR in `res_country_data.xml`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241957
This update corrects an issue where payslip names were not being generated accurately for the Swiss (l10n_ch_hr_payroll) version of Odoo. The fix ensures that payslip names are now correctly formatted and displayed, improving the accuracy of payroll reports and data.
Original PR description
Forward-Port-Of: odoo/enterprise#104289
This update ensures that newly created General(MISC) entries in Odoo automatically have 'no followup' enabled. This simplifies reporting and reduces the risk of unnecessary follow-up actions for these types of transactions, improving data clarity and efficiency.
Original PR description
General(MISC) entries should be no_followup by default. task-5489772 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a bug where a project was automatically created when ordering 0 units of a prepaid service product within a quotation. The change ensures that projects are only generated when a valid quantity of the service is ordered, streamlining the invoicing process and preventing unnecessary project creation. This resolves an issue reported by users.
Original PR description
--- ## Short functional explanation of the error Let's say we have a prepaid service as a product, generating a project upon order. When we order 0 units of this product as an optional product, a project is still created. ## Reproduction Steps 1. Create a product of type Service. Set Project in the field Create On Order. Set the Invoicing Policy at Prepaid. 2. Create a quotation containing an optional product with 0 units of this service and click on confirm. ### Expected behavior The quotation is confirmed, but no project is created. ### Unexpected behavior A project linked to the product and the quotation is created. ## Origin of the issue When creating projects linked to order lines, we don't check if such projects are linked to optional products. opw-5406118
This update resolves a potential error in the accounting module that could occur when calculating tax distributions. The change ensures the system handles the rare scenario where all factors are zero, preventing a traceback and maintaining accurate calculations. This improves stability and reliability of financial transactions.
Original PR description
In 614dcf23b89 `_distribute_delta_amount_smoothly` was changed to use a half-up round rather than a ceiling, and incorporate an additional step of distributing any remaining cents. However, the step that distributes any remaining cents relies on the assumption that there are less remaining cents than the number of factors. This assumption generally holds true because most cents are already allocated in the first step which uses the `round` function; except in one edge case, which is if all factors are zero. In that case, the `_normalize_target_factors` method will return an all-zero list of normalized factors, and so no cents will be allocated in the first step. The fix is to change `_normalize_target_factors` so that in this edge case, the list of normalized factors allows most cents to get allocated in the first step. See #240136 task-none Forward-Port-Of: odoo/odoo#240616