Monday, August 25, 2025
2 changes · 18.0
New functionality added to Odoo
Adds a new connector to bring TikTok and Tokopedia Shop orders into Odoo from multiple seller accounts. Businesses can match marketplace orders to Odoo products, handle both platform-fulfilled and seller-fulfilled orders, and keep delivery and stock information synchronized.
Original PR description
- Import orders from multiple accounts - Orders are matched with Odoo products based on their internal reference (item_id or SKU ID in Tokopedia | Shop) - Support for both Fulfillment by TikTok/Tokopedia | Shop (FBT), Fulfillment by Seller (FBS): - FBT: Importing the completed orders - FBS: Delivery information is fetched from Tokopedia | Shop, track and synchronize the stock level to Tokopedia | Shop Task ID: 3690836
Enhancements to existing features
This update makes product quantity calculations much faster when working with very large product catalogs, especially when manufacturing kits are involved. Businesses with hundreds of thousands of products should see significantly shorter search and inventory availability response times.
Original PR description
In the stock module one of the bottleneck of the `_compute_quantities` is the call to `product.update`. While this is not really an issue when the number of products is small, it becomes slow when…
In the stock module one of the bottleneck of the `_compute_quantities` is the call to `product.update`. While this is not really an issue when the number of products is small, it becomes slow when this number grows above 100 000 products. This can happen when searching on one of the computed non-stored fields for instance. In this case, the underlying issue is the unbatched call to `__setitem__` that calls `Float.convert_to_cache` that calls `get_digits` and `float_round`. These two methods are not that costly for small recordsets but can take a bit of time for larger ones. The solution proposed in this commit is to grouped the quantities_dict by values then call update on batches of product.products. This leads to a noticeable speedup, mostly for the > 100 000 records recordsets. Another bottleneck appears when the mrp module is installed. When there's a lot of products, the calls to `mrp.bom.explode` can stack up and lead to slow execution. A solution for this is to memoize the exploded values of the boms. We can do that because this value is actually independent of the current product, as we are not using the first list returned by the `explode` method. This leads to a noticeable speedup, especially in database where there are a small number of boms for a large number of product.products. speedup Time to search for products with `free_qty` > 0.0. Database with mrp installed and kit boms. Most of the kit boms are for templates. 800 000 products in the db, 15 000 templates. | Total number of products | Before PR | After PR | |:------------------------:|:---------:|:---------:| | 100 | 51ms | 48ms | | 1000 | 220ms | 200ms | | 10000 | 1.2s | 900ms | | 100000 | 10s | 5.77s | | 800000 | 15min | 1min15s | The customer database has 3 boms for templates that have more than 20 000 variants each. In this case, memoizing the explode gives a significant speedup. That's what happens in the 800 000 case above. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr