[15.0][REF] product_cost_price_avco_sync: Refactoring for handling all the changes at once #1697
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The current problem is that when there are crossed changes between products (like in MRP, having changes in components that affect manufactured products), a lot of writes are done, as each product is processed separately, and thus, there can be continuous resync between them.
With this new method, we can process the whole sync in one step, blocking it till pending data is processed, avoiding continuos sync triggerings.
Main changes:
Extract the processing code corresponding to one SVL to the method
_process_avco_sync_one
.Include all the state variables - previous_unit_cost, previous_qty, inventory_processed and unit_cost_processed - into a super-structure (called
svls_dic
, which previously holds the SVL values for the product being synchronized). This super-structure is a dictionary having as keys the pair (product, company), and the value another dictionary with such state variables and storing the SVL values in "svls" key.2 main loops for iterating in the elements to sync, one for the pair (product, company), and other inside for the SVLs to sync. First
while
loop is driven by these control variables:The second one uses the value inside "to_sync" key of the super-structure to know which is the SVL to sync currently, and when processed, we dynamically look for the next one.
_preprocess_main_svl_line
and_preprocess_rest_svl_to_sync
dissapears in favor of one control method:_is_avco_sync_processable
, which can return a falsy value if we can't sync that SVL.We add extra things to sync modifying the super-structure in
_process_avco_sync_one
- add new (product, company) keys or change "to_sync" value -.All the AVCO sync methods have been converted to private.
The processing of the SVLs previous to the one to sync is done in a light way, but using the same code of
_process_avco_sync_one
. After obtaining the state variables, the SVLs dict is discarded for saving memory.@Tecnativa TT50028