Daily updates from Odoo
Friday, July 19, 2024
19 changes · 17.0
Resolved issues and error corrections
This fix resolves an issue where the Credit Notes button in helpdesk tickets was showing an empty list when both the helpdesk_account and helpdesk_sale_timesheet modules were installed together. The problem was caused by conflicting action names between the two modules, which has now been corrected by renaming the actions in helpdesk_account to prevent the conflict.
Original PR description
Steps to Reproduce: ----------- Install the helpdesk_account and helpdesk_sale_timesheet module. Go to the ticket form view. Perform a refund or reverse action. Click on the 'Credit Notes' stat button. Observe that the list view of credit notes is empty. Cause: ---------- When the helpdesk_sale_timesheet module is installed, the action_view_invoices method gets overridden. Fix: --------- We have renamed the actions in the helpdesk_account module to avoid conflicts. task-3972344
Fixed an issue where custom tax group labels (Preceding Subtotal values) were not displaying correctly on printed AvaTax invoices. When using AvaTax for automatic tax calculation, invoices now properly show the configured tax group names instead of generic "Untaxed Amount" labels, ensuring consistent invoice formatting across different tax configurations.
Original PR description
…invoices Steps to Reproduce on Runbot: 1. Set up AvaTax in Accounting settings 2. Make sure that the “Use AvaTax API” field is checked for the fiscal position named “Automatic Tax Mapping (AvaTax)”…
…invoices Steps to Reproduce on Runbot: 1. Set up AvaTax in Accounting settings 2. Make sure that the “Use AvaTax API” field is checked for the fiscal position named “Automatic Tax Mapping (AvaTax)” 3. Go to “Tax Groups” and for the record called “Tax 15%”, add “Test” to the field called “Preceding Subtotal” 4. Go to the Product Category called “All” and choose any selection for the field called “AvaTax Category” 5. Make an invoice and add the fiscal position named “Automatic Tax Mapping (AvaTax)” 6. Save then print the invoice. Notice on the printed invoice that above the box called “Total”, the box called “Untaxed Amount” shows up with no tax box. 7. Uncheck the “Use AvaTax API” field for the fiscal position named “Automatic Tax Mapping (AvaTax)” (This step is basically the inverse of step 2) 8. Print the invoice again and notice this time that the box will instead be called “Test” (which we set in step 3) and that a box showing the tax amount will show up. This commit fixes the issue so that the value in "Preceding subtotal" is shown for printed Avatax invoices too. opw-4027280
This fix resolves an issue where new helpdesk tickets displayed "name - #False" in the title bar instead of just "name" when the ticket reference number hadn't been assigned yet. After saving, the ticket reference will display correctly. This improves the user experience by removing confusing placeholder text from the interface.
Original PR description
How to reproduce (on 17.0 onwards): - Helpdesk -> new ticket form - set the name of the ticket (do not save the record) - then, set a partner to a existing partner - The display_name on the top displays 'name - #False' Expeceted behavior: - instead of displaying 'name - #False', it should display 'name' if the ticket_ref is not defined yet. After this commit, the display_name only displays the ticket_ref (#ID) if it exists. Test have been added for this purpose. Task: 3893076
This update fixes three issues in the Barcode App that affect warehouse operations: (1) When scanning lots across multiple pickings in a batch, the system now correctly stays focused on the current picking until it's completed, preventing lots from being assigned to the wrong picking; (2) The quantity increment buttons now show accurate remaining quantities even when non-reserved lots are scanned; (3) Line sorting is improved to prevent duplicate entries when lines are split. These fixes ensure accurate inventory tracking and a smoother warehouse workflow.
Original PR description
**[FIX] stock_barcode_picking_batch: scan lots with multiple pickings** > How to reproduce: > - Create a product tracked by lots and set a barcode for this product; > - Create a receipt for this…
**[FIX] stock_barcode_picking_batch: scan lots with multiple pickings** > How to reproduce: > - Create a product tracked by lots and set a barcode for this product; > - Create a receipt for this product, with at least 2 quantities and confirm it; > - Create a second similar receipt (you can duplicate the first one) and confirm it; > - Add these two receipt in a new batch and confirm the batch; > - Go in the Barcode App and open the batch, you should have two lines, one for each picking; > - Scan the product -> the first line should be selected; > - Scan a lot -> the lot is set on the first line and its qty is incremented; > - Scan another lot -> the lot is set on the second line and its qty is incremented. That's the issue. > > Expected behavior: When another lot is scanned after the first one, since we are picking quantity for the first picking, the line for the second picking shouldn't be selected until the first one is processed. To fix that, the search for a line following the scan will avoid to take a tracked line if its `picking_id` is not the same than the selected line and if the selected line is not completed. **[FIX] stock_barcode: increment right qty** > When a product tracked by lots is reserved and multiple lots are reserved, in the Barcode App, each line has a "+ qty" button where the quantity is the remaining quantity. That said, this remaining quantity was always computed regarding the difference between the move line's done and reserved quantity which means if the user scans a not reserved lot, those buttons aren't reliable anymore. > > How to reproduce: > - Create a product tracked by lots and set a barcode; > - Update the quantity on hand for this product like following: > - 3x lot1 > - 3x lot2 > - 3x lot3 > - Create a delivery for 6x this product and confirm it; > - Open the delivery in the Barcode App, unfold the line for the tracked product, you should have: > - 0/3 lot1, [+3] > - 0/3 lot2, [+3] > - Scan lot1 one time and lot3 three times, you now have: > - 3 lot3, [+1] > - 1/3 lot1, [+2] > - 0/3 lot2, [+3] > -> Since the total demand is 6 and 4 quantities have been processed, no button should display a quantity greater than 2 since it's the remaining quantity. > > To fix that, the quantity used by the increment button is also computed regarding the parent line's quantity. task-3688770 Community PR: odoo/odoo#173521 Forward-Port-Of: odoo/enterprise#64042 Forward-Port-Of: odoo/enterprise#54589
This update hides Kenya-specific eTIMS (electronic Tax Invoice Management System) fields and buttons from companies that don't operate in Kenya. This reduces clutter and confusion for international users by only showing relevant features when Kenya is set as the company's fiscal country. The change applies across invoicing, products, stock management, and configuration screens.
Original PR description
Where possible, we make the eTIMS-specific fields and buttons invisible unless the company has Kenya as fiscal country. Exceptions to this are: - the buttons on partner and user form views. We don't have a way of showing them only if the currently selected company is Kenyan. However, they are already visible only in debug mode, so this isn't too much of a problem. - the 'Custom Imports' menuitem - we don't have a way of making it conditionally visible.
This update improves the user experience by hiding the Field Service section in project forms when it contains no relevant settings. The section now only appears in debug mode when using the basic Field Service module, but displays normally when the Field Service Reports module is installed with additional settings available.
Original PR description
When `industry_fsm` is installed, the form of `project.project` contains a section `Field Service` with only one setting (`is_fsm`). This option is only visible in only visible in debug mode, so the whole section should be displayed only under this conditon. => The group `base.group_no_one` has been added to the section. When `industry_fsm_report` is installed, another setting appears under that section (`worksheet_template_id`), so the section should be displayed. => The group that is added in `industry_fsm` is removed then. task-3916982
This fix improves the user experience when connecting bank accounts by updating consent expiration dates immediately after successful synchronization, rather than making users wait up to 24 hours for the next automatic refresh. This ensures users see their updated consent status right away, making the system feel more responsive and reliable.
Original PR description
The aim of this commit is reverting a part of this commit [1]. We have to do that because by removing the call to consent expiring date after the sucess, users don't receive the new consent date directly. Users have to wait until the next call to the refresh token and this call is made every 24h so users have the feeling that the consent wasn't updated. In one case, we don't have the consent expiring date provided by the TPP directly. For that case, we keep the call after the renew token. [1]: https://github.com/odoo/enterprise/commit/25ec0ba479372126f84fd1ece6f34aea7b1eb829 Forward-Port-Of: odoo/enterprise#65408
A recent change to how French tax reports calculate values inadvertently broke the ability to audit tax line details. This fix restores the audit functionality by adjusting how the system identifies and displays the underlying journal entries for tax calculations, ensuring proper financial record-keeping and compliance.
Original PR description
This [commit](https://github.com/odoo/odoo/commit/12477a5401c4d0eaf39c87c17afc7f82d9018986) changed the way the French tax report computes its value to make sure they are rounded to the unit. It also unintentionally broke the auditing of the tax lines since tax tags are no longer used. The fix consists in adjusting the `expression_label` in the action in order to target the expression that uses the `tax_tags` engine, allowing to display the expected journal items. opw-3999520
This update adds missing safety protections to the French tax reporting module to prevent test databases from accidentally sending real data to external systems. This ensures that when support teams create copies of production databases for investigation purposes, those copies cannot inadvertently impact customers or the live production environment.
Original PR description
This commit adds the missing neutralization necessary for the l10n_fr_reports module introduced in 06f32096749a8df29b248f29698226cf996e9106 The purpose of the standard neutralization framework is to allow us to create database copies that will not interact with external systems in ways that could impact the production database (or if it is not possible to prevent the interactions, make sure that they are benign or won't result in actual changes), or impact the customers of the operator of the production database. This is mainly useful to allow safe support investigation on database duplicates. opw-3928199
This fix resolves an issue in the consolidated trial balance report where users couldn't properly expand or collapse consolidation groups. The problem was caused by incorrect data being passed when building the report hierarchy, which has now been corrected to ensure the report displays and functions as intended.
Original PR description
…roup when opening the consolidated trial balance report, the folding/unfolding or consolidation groups were not working correctly. This was because the parent_line_id wasn't correctly passed in _get_generic_line_id opw-ticket: 4046553
This update fixes compatibility issues across multiple localization modules (Argentina, Chile, Mexico, Netherlands, Philippines, and Thailand) by updating code to work with newer versions of external libraries. The changes address deprecated methods and removed features in libraries like urllib3, zeep, cryptography, xlsxwriter, and openpyxl, ensuring the system continues to function properly with current software versions.
Original PR description
backport of #66166 Conflict notes: - ccfdc06546828868bfcfbe64f6f9c68914d96220 was dropped since the module does not exist in 17.0 (created in 17.3) - 2d58ab9042d823743bf9b0534d4572b88a30dc58 import adapted - 1728d1e448f90d3e32fc135de2370e054d0216f5 was dropped since the module does not exist in 17.0 (created in 17.2)
This fix corrects how package weight limits are handled when calculating shipping rates through Sendcloud. Previously, weight measurements were inconsistent—stored in kilograms but sent to Sendcloud as grams—causing shipping rates to be calculated incorrectly and appear unusually high. The fix ensures all weight values are properly converted to grams before being sent to Sendcloud, resulting in accurate shipping rate quotes.
Original PR description
Steps to reproduce: - Create a shipping method with sendcloud as provider. - In the field 'Default package type' create a package type and set 'Max Weight'(e.g 1kg). - Create a sales order, Add…
Steps to reproduce: - Create a shipping method with sendcloud as provider. - In the field 'Default package type' create a package type and set 'Max Weight'(e.g 1kg). - Create a sales order, Add shipping, and select sendcloud. - Add 'Total order weight'(e.g 0.5kg) - Click 'Get rate' Returned rate for shipping is unusually big ammout. Before this commit: For sendcloud shipping if sendcloud_default_package_type_id is set, max_weight is stored in kilograms. When checking if the package needs to be splitted, the target_weight is not being converted whereas the total_weight is.(check link at the bottom for details) Also in shipping rate request for sendcloud `max_weight` was sent in kilograms with `unit` being 'gram'. After this commit: `max_weight` is converted into grams before adding to the shipping rate request. split shipping code: https://github.com/odoo/enterprise/blob/d3b39fe78bc0ae366d32e80e325e89d2a4bb353c/delivery_sendcloud/models/sendcloud_service.py#L160-L162 opw-4035569
Fixed an issue where manually modified tax closing entries were being erased when posted. The system now preserves user changes to closing entries and properly handles dependent company closings within tax units. This ensures that accountants' manual adjustments to tax closing documents are retained during the posting process.
Original PR description
Before this commit, when posting a manually modified closing entry, the entire move would be refreshed, and all user-modified information would be erased. This occurred because, when accessing the action_periodic_vat_entries, the current tax closing move was overwritten. This commit changes this behavior by adding a flag to the method, indicating whether it is called from the _close_tax_period function. If so, it only updates moves that are different from the tax closing of the current company. Additionally, when selecting only one company within a tax unit, it sometimes happened that, when closing the main company, the dependent closings to post (depending_closings_to_post) were empty because the moves were not generated yet for the other companies. Task: 3987807
Fixed an issue where follow-up reports and printed PDFs were missing overdue invoices from branch companies. The system now correctly includes invoices from both the parent company and all its branches when generating follow-up reports, ensuring complete visibility of all outstanding invoices across your organization.
Original PR description
To reproduce: Create a branch for your company On this branch, create an overdue invoice for a partner. Change company for the parent company. Go to Follow-up Reports Go on this partner. You see the invoice appearing in the list Click on Follow-up and print => The pdf does not contain the invoice from the branch The issue is that we check on company and not on the company and branches. opw-3988003
A test for knowledge base access controls was using the wrong user type for validation. The test now correctly uses an internal employee user instead of a portal user, ensuring that access control rules are properly tested for the intended user category. This fix ensures the security testing is accurate.
Original PR description
This commit changes the user for the test `:TestWKnowledgeSecurity.test_models_as_user` which should test ACLs for internal users. Initially it used `portal_user`, which is not internal but portal. It is now replaced by `employee`. task-4059967 Forward-Port-Of: odoo/enterprise#66869
This fix corrects a calculation error that occurred when processing down payment invoices in Mexico's CFDI system. When a 90% down payment was applied to an invoice, the system incorrectly calculated negative base amounts on invoice lines, causing CFDI validation to fail. The fix ensures that discount amounts from down payments are properly distributed across invoice lines with accurate calculations.
Original PR description
**Steps to reproduce:** - Install Accounting, Sales, l10n_mx_edi - Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE) - Create a SO: * Customer: [a Mexican customer] (e.g. INMOBILIARIA CVA) *…
**Steps to reproduce:**
- Install Accounting, Sales, l10n_mx_edi
- Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE)
- Create a SO:
* Customer: [a Mexican customer] (e.g. INMOBILIARIA CVA)
* Order Lines:
Product | Quantity | Unit Price | Taxes
---------------|----------------|----------------|----------
Product A | 1.00 | 1000.00 | 16%
Product B | 1.00 | 1500.00 | 16%
Product C | 1.00 | 3000.00 | 16%
- Confirm the SO
- Create a 90% down payment
- Confirm down payment and generate CFDI via "Send & Print" button
- Create a regular invoice for the remaining amount
- Confirm the invoice and generate CFDI
**Issue:**
The verification of the CDFI fails because there is one line with a negative base amount.
**Cause:**
The down payment line has a negative amount.
This negative amount is dispatched between the other lines and the "base" and "importe" values of these other lines are recomputed depending on the amount that is deducted from it.
However, the computation is based on a ratio computed from the price subtotal of the negative line, but the ratio is then applied to the remaining "base" amount of the negative line, which decreases for each deducted line.
This generates incorrect values in "transferred_values_list" field for the the second line and the following ones on which some amount is dispatched.
The issue only happens on the last line on which some amount has been dispatched because it receives the remaining amount that is too high due to the values deducted by the other lines being lower than what it should has been.
**Solution:**
The ratio should be computed from the remaining "base" amount of the negative line.
opw-4033979This fix resolves an issue where confirmation messages were not appearing when employees validated their timesheets in the pivot and kanban views. The problem was caused by mismatched parameters in the validation action, and this update ensures users receive proper feedback when submitting timesheets for approval.
Original PR description
### **Steps to reproduce:** - install Timesheets module. - Go to To Validate. - Click on All Timesheets. ### **Issue:** - The notification message is not displaying when clicking on validate in pivot and kanban views ### **Solution:** - The problem seems to be from a mismatch in parameters when triggering the validation action. PR-https://github.com/odoo/enterprise/pull/44455 task-3925639
Fixed incorrect calculation formulas in Austrian financial reports that were broken during a previous code refactoring. The formulas now correctly match the verified calculations from the previous stable version, ensuring accurate tax reporting for Austrian accounting customers who work with tax lawyers and auditors.
Original PR description
After finally checking with a full-fledged accounting customer which is verified by tax lawyers and auditors these changes are needed to show the exact same result as left behind battle tested in `15.0` - `PCVIII` is a sum of `PCVIII3` + `PCVIII4` and those can be part of `PCVIII1` or `PCVIII2` This needs also be reflected in `ABII4` if the balance needs to be mirrored. Actually it should be similar presented in `ABII4`, but was not yet done. This might need some account tags to be adapted in Odoo Community `l10n_at` CoA, but let's start from here as it is secured and tested information. Info: @wt-io-it
This fix resolves a problem in the consolidated trial balance report where users couldn't properly expand or collapse consolidation groups. The issue was caused by incorrect data being passed when organizing the report hierarchy, which has now been corrected to ensure the report displays and functions as intended.
Original PR description
when opening the consolidated trial balance report, the folding/unfolding or consolidation groups were not working correctly. This was because the parent_line_id wasn't correctly passed in _get_generic_line_id opw-ticket: 4046553