Daily updates from Odoo
Monday, December 23, 2024
7 changes · 17.0
New functionality added to Odoo
This update introduces a new payment method, 'RIBA,' to streamline the process for Italian customers to upload bank receipt data to their banks. It involves exporting data from payment batches to a specific RIBA text format, enabling compatibility with systems like FattureInCloud. This improves the integration with Italian banking systems.
Original PR description
Export from `account_batch_payment` to CBI's RIBA text file format, so that the customer can upload its requests for payment (bank receipts) to the bank. - New field: `l10n_it_sia_code`: Interbancary identifier given by SIA when signing a CBI contract to start doing Ri.Ba.s - New payment method: `RIBA` - Added the methods to read and write the Ri.Ba. text format, i.e. we are able to read an `example` created with FattureInCloud. - Implemented the flow by taking the data from payments and calling the export functions. - Built a test - Made some demo data - Added translation strings - Riba sequence number, it's created on export and persisted on the batch payment at the moment, so if you re-export, it won't change. It's not shown to the user though. Do we want that to be shown? Editable? Task [link](https://www.odoo.com/odoo/project/967/tasks/4254966) task-4254966 Forward-Port-Of: odoo/enterprise#74097
Resolved issues and error corrections
This update resolves a problem where two Datev export files had the same name, causing confusion and inefficiency. The change ensures distinct file names for each export, streamlining the process and improving data organization. This fix ensures accurate and reliable Datev reporting.
Original PR description
The 2 exports have the same name, which is impractical. Let's differentiate them task-4414223 Forward-Port-Of: odoo/enterprise#75907
This update corrects a minor issue where some labels were missing in English for the Mexican reports module. Specifically, the `l10n_mx_nationality` and `l10n_mx_type_of_operation` fields now have accurate English translations. This ensures proper reporting functionality for users in Mexico.
Original PR description
Add missing english labels for the `l10n_mx_nationality` and `l10n_mx_type_of_operation`fields.  task-no Forward-Port-Of: odoo/enterprise#76038
This update fixes a tax calculation issue in Odoo Enterprise related to sales orders using Avatax. The system now uses the sales order's warehouse for tax computation, providing a more accurate estimate. While this is a best-effort approach, it resolves discrepancies in tax rates observed during order validation and invoicing.
Original PR description
…ing taxes Steps to reproduce ================== - Create a company in Canada with the canadian fiscal localization - Configure the avatax sandbox credentials - Create a new fiscal position in the…
…ing taxes Steps to reproduce ================== - Create a company in Canada with the canadian fiscal localization - Configure the avatax sandbox credentials - Create a new fiscal position in the USA that uses the avatax API - Create a USD pricelist - Create a warehouse in Cleveland Ohio - Create a salesorder with an Ohio based customer and the USD pricelist - Select a storable product with an invoicing policy on delivered quantity - Set the avatax category of the product to "Hand tools" - Select the warehouse just created on the sales order - Click on the "Compute taxes" button => The tax is set to 1% - Confirm the sales order => The tax is still set to 1% - Validate the delivery and create + confirm a new invoice => The tax is now 2.25% Cause of the issue ================== When computing the addresses to send to Avatax, the stock move addresse was used, but at this point, they have not yet been created Solution ======== We now use the warehouse from the sales order. This is only a best-effort estimation of where the products will ship from. It's possible products ship from a different warehouse than warehouse_id. For example, you can change the default delivery route to pull from a source location in a different warehouse. However, this is probably not a common configuration. In the end, the only way to know for sure is to run the inventory-related code, which we want to avoid just for tax computation. Finally, it's also possible for users to change the warehouse manually after the order is confirmed. This can also potentially change taxes, and there's no way to anticipate this. The account.move code will continue to pull the warehouse from the stock.move, because we know it will be created before the invoice. Note that even on account.move the shipping address remains an estimation for products with an “invoice on ordered” invoicing policy. opw-4073701
This update corrects a bug where Mexican XML invoices were incorrectly displaying duplicate 8% tax amounts. The issue stemmed from a forward-porting error that was not properly addressed. The fix involves removing the problematic code and refactoring related components to ensure accurate tax calculations for Mexican invoices.
Original PR description
## Issue: - Uploading a Mexican XML file with an 8% tax results in the addition of an extra 8% tax. ## Steps to reproduce: - Create a new invoice and add a line with an 8% tax. - Validate the invoice…
## Issue: - Uploading a Mexican XML file with an 8% tax results in the addition of an extra 8% tax. ## Steps to reproduce: - Create a new invoice and add a line with an 8% tax. - Validate the invoice and export it as XML. - Upload the XML file as a vendor bill. - The vendor bill incorrectly shows two "8% taxes" instead of one. ## Solution: - The issue stems from a forward-port error from `saas-16.4` https://github.com/odoo/enterprise/commit/5681a8d5abee3a8787f3ee8612a8c3b18ed63ee6 to `17.0` https://github.com/odoo/enterprise/commit/56a2b66d84d8398ea870d559cd55cfeae44019d8 - In `17.0` we introduced this Extract method `_l10n_mx_edi_import_cfdi_get_tax_from_node` to refactor the `_l10n_mx_edi_import_cfdi_fill_invoice_line`. - We should have add the Exento checks in the new method however we mistakenly pushed code from `saas-16.4` to `17.0` without adapting it. - I removed the extra code introduced during the forward-porting. - Refactored the related code to ensure compatibility with the new changes in `17.0`. OPW-4198016
This update fixes a bug in the account reconciliation process. Previously, the system only flagged discrepancies when the ending balance didn't match the transaction sum. Now, it also identifies issues when the starting balance doesn't align with the previous statement's ending balance, ensuring more accurate reconciliation reports.
Original PR description
### Before The 'Invalid Statements' filter only considered the case of the Ending Balance not matching the Starting Balance + the sum of its transactions. We were not considering the case of the Starting Balance of the statement not matching the previous statement's Ending Balance. ### Now Fixed the condition of the filter to account for the second case. task-4397412
This update corrects a bug that prevented users from accessing CRM leads during testing. The fix ensures proper permission controls are enforced, preventing unauthorized access. This improves the reliability of our CRM test environment.
Original PR description
Fixing permission access error in the test (user does not have access to crm.lead). task-4380712 odoo/odoo#191319 Forward-Port-Of: odoo/enterprise#75965