Wednesday, February 14, 2024
2 changes · 17.0
Enhancements to existing features
This update speeds up the Shop Floor app by caching barcode information instead of recalculating it repeatedly. Users will experience significantly faster loading times, especially when managing large numbers of manufacturing orders—reducing load time from 140 seconds to under 3 seconds in some cases and preventing browser crashes.
Original PR description
## Description When a user opens the Shop Floor app, each MrpDisplayRecord will compute the barcode target record based on the admin ID. This can lead to slow computations and make the browser crash when there are many records. ## Analysis The barcode target record ID will always be the same as long as the admin ID doesn't change. ### Before this commit All MrpDisplayRecord are recomputing the barcode target record. ### After this commit We cache the admin ID and the barcode target record ID to avoid recomputing it if unecessary. ## Benchmarks Computing the barcode target records when opening the Shop Floor app: | Relevant MO | Before | After | |-------------|---------|--------| | 80 | 0.9 s | 0.6 s | | 400 | 23.2 s | 1.8 s | | 879 | 140 s / Browser crash | 2.8 s | ## References opw-3721896 opw-3741051 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This fix resolves issues where AvaTax rejects invoices due to invalid state transitions, which can occur when system errors or concurrent access problems interrupt normal invoice processing. By switching to AvaTax's more flexible "create or adjust" endpoint, Odoo now treats itself as the source of truth for invoice states, preventing errors that could break automatic subscription renewals and other critical workflows.
Original PR description
Avatax doesn't allow all state transitions. For example, if an invoice is committed it can't be committed again. If an invoice is voided, it can't be committed. These state transitions shouldn't…
Avatax doesn't allow all state transitions. For example, if an invoice is committed it can't be committed again. If an invoice is voided, it can't be committed. These state transitions shouldn't happen in Odoo when things go well, but bugs and concurrent access errors can stop any of our normal flows at any point. For example, a subscription gets automatically charged, does the payment, generates the invoice and commits the invoice in Avatax. However, the transaction fails to commit in Odoo because of a concurrent access error. Next time an invoice with the same Avatax Code is generated the tax calculation will fail with this error: odoo.exceptions.UserError: Odoo could not fetch the taxes related to Draft Invoice (* 123456) (M123456). Please check the status of `Journal Entry 123456` in the AvaTax portal. DocStatus is invalid for this operation. Errors like this can then break the automatic subscription renewal. Since there's many reasons a flow can crash it's better to make Avatax as idempotent as possible. The source of truth for invoice state is Odoo, regardless of what's in Avatax. To achieve this we'll fully switch to the createoradjust [1] endpoint that was previously introduced for test environments [2]. This endpoint allows almost all state transitions and should avoid the majority of blocking errors. [1] https://developer.avalara.com/api-reference/avatax/rest/v2/methods/Transactions/CreateOrAdjustTransaction [2] 12039763a3a8f27a1d69bebb6d661ad20ce3537b cc @tfr-odoo