Thursday, April 18, 2024
4 changes · 17.0
New functionality added to Odoo
This update adds tax calculation and electronic document interchange (EDI) capabilities for service transactions in Brazil, complementing the existing goods transaction support. Service invoices now go through an additional validation step and are tracked in a pending state until confirmed, with status checks performed automatically and on-demand. This enhancement enables Brazilian companies using Odoo to properly handle tax compliance and document submission for both goods and service-based invoices.
Original PR description
This adds tax calculation and EDI support for service transactions. All new functionality was added in new modules because this is taking place in a stable release. Avatax has different endpoints for…
This adds tax calculation and EDI support for service transactions. All new functionality was added in new modules because this is taking place in a stable release. Avatax has different endpoints for submitting and cancelling service invoices. These two endpoints have fairly similar payloads so various overrides were made to remove/add information from the goods payloads to make them compatible with the service endpoints. A new account.external.tax.mixin l10n_br_is_service_transaction field is used to determine whether to follow the old, existing goods flow or go through the new service flow. The biggest difference is that service invoices go through an extra, asynchronous validation step. To achieve this, invoices that are successfully submitted end up in a new "pending" state. After this, their status can be checked with button_l10n_br_edi_get_service_invoice(). This function is also called periodically with a cron. In master, these modules will be merged into the already existing modules and deleted. task-3660574
Enhancements to existing features
This update significantly speeds up the appointment booking system, particularly when managing multiple resources and capacity changes. The system now processes slot availability checks 5-7 times faster, reducing wait times from several seconds to under a second when updating booking capacities. This improvement enhances the user experience when managing complex appointment scenarios with many linked resources.
Original PR description
- Compute the best resources for a slot only for distinct capacity info and improve performance when updating table booking from 1 to 12 capacities with appointment type with a lot of linked…
Resolved issues and error corrections
This fix resolves installation and upgrade failures in the accounting module that occurred when certain required data identifiers were missing from the database. The issue prevented users from installing localization modules or upgrading to version 17.0 in some cases. By adding the missing data identifiers during module initialization, the installation process now completes successfully.
Original PR description
The post-init hook of this module runs `ChartTemplate._load_data` and that might reference the xmlid of a general journal from the company. If that xmlid is missing, it will fail with the error:
```
KeyError: ('ir.model.data', <function IrModelData._xmlid_lookup at 0x7f9ff24b1240>, 'account.1_general')
```
Steps to reproduce on a fresh 17.0 database:
- Install a localization module, eg `l10n_be`.
- This will create the necessary xmlids. Delete the `X_general` xmlids from the dabase.
- Install `account_accountant`. Installation will fail with the aforementioned error.
This also happens during upgrades:
- On a fresh 16.0 database, install module `l10n_uk`.
- The `X_general` xmlids are not created as they don't exist in this version.
- Upgrade to 17.0
- `l10n_uk` doesn't load data from its template, so the xmlids still don't exist.
- Module `account_accountant` is automatically installed, triggering the error.- Compute the best resources for a slot only for distinct capacity info and
improve performance when updating table booking from 1 to 12 capacities
with appointment type with a lot of linked resources (tested on Table Booking
without any event booked):
Before: ~105s (local time)
After: ~15s (local time)
This also allows the first slot computation to be a little faster (4s => 3s)
- Don't use intervals_overlap in _slot_availability_is_resource_available:
~15s => ~4s (local time)
It was called a lot because of the default resource calendar and the work intervals
computed from it.
- Single filtered on booking lines for _get_resources_remaining_capacity
Queries count (from profiler - local):
/appointment/4 : ~1500 => ~830
/appointment/4/update_available_slots (capacity -> 12) : ~7700 => ~455
/appointment/4/update_available_slots (capacity 12 -> 1) : ~1130 => ~430
/appointment/4/update_available_slots (capacity 1 -> 12) : ~7700 => ~455
Queries count (profiler - runbot):
/appointment/4/update_available_slots (capacity -> 12) : ~1190 => ~130
task-3640599This fix resolves an issue that prevented users from creating new companies when multi-step routes were configured as company-specific. Previously, the system would fail with a validation error when trying to link warehouse rules to routes belonging to different companies. The fix ensures that routes are properly matched to the correct company during the company creation process.
Original PR description
If the "generic" routes (i.e., the ones created from the master data) are company-specific, the user won't be able to create a new comapny anymore. To reproduce the issue: 1. In Settings, enable…
If the "generic" routes (i.e., the ones created from the master data)
are company-specific, the user won't be able to create a new comapny
anymore.
To reproduce the issue:
1. In Settings, enable "Multi-Step Routes"
2. Enable all companies
3. Inventory > Configuration > Rules:
- For each Manufacture rule:
- If its route does not have any company:
- Set the route's company equal to the one of the rule
4. Create a new company
Error: a Validation Error is raised: "Rule [...] (Production) belongs
to \<new company\> while the route belongs to \<an existing company\>."
Creating a company leads to the creation of the WH and its rules. At
some point, we create/update the global rules. Let's look at the
Manufacture one. We will provide all the required values for its
creation:
https://github.com/odoo/odoo/blob/270d8aa06bb37b4a01f01a7274062e3f88ca2a1c/addons/mrp/models/stock_warehouse.py#L112-L128
As you can see, for the `route_id` field, we try to find a global
route. But here is the issue: in this `_find_global_route`, we will
find the "generic" one thanks to the provided XML_ID. But, step 3,
we set a company on that route. As a result, here, we try to create
a rule for a company X linked to a route that belongs to a company Y,
hence the validation error:
https://github.com/odoo/odoo/blob/dc58d7913131f1f4dbeb0e3337e61e0b21f6f0d9/addons/stock/models/stock_rule.py#L107-L108
OPW-3790512
Forward-Port-Of: odoo/odoo#161888
Forward-Port-Of: odoo/odoo#161820