- This was done due to stale reads while the background jobs tried updating status of the log
- Added a table where all bom jobs within log will be tracked with what level they are processing
- Cron job will check if table jobs are all processed every 5 mins
- If yes, it will prepare parents and call `process_boms_cost_level_wise` to start next level
- If pending jobs, do nothing
- Current BOM Level is being tracked that helps adding rows to the table
- Individual bom cost jobs (that are queued) will process and update boms > will update BOM Update Batch table row with list of updated BOMs
* fix: Auto Insert Item Price If Missing when discount and blank UOM
fixes wrong item price insert when discount is used and adds uom=stock_uom instead of blank as price is converted to stock uom
* unit tests added for item with discount
I have added test for auto_insert_price where discount is used.
* unit test issue fixed
fixed make_sales_order as some of the test that depended on it were failing due to passing of incorrect parameters.
Co-authored-by: Ankush Menat <me@ankush.dev>
- If `Update Cost` job is ongoing, then block creation of new ones since all BOMs are updated
- `db_update` in `calculate_rm_cost` only if changed values to reduce redundant row updates
- Misc: Use variable for batch size
This is broken again after serializing scan actions, which causes
selector to trigger before batch_no is set.
Solution: for duration of scan disable the selector
Profitability Analysis includes 'is_cancelled' GL Entries which means that the profit numbers are incorrect. This change will ensure that the profit figures ignore cancelled GL Entries.
* fix: resolve row after model is updated.
* fix: wait for all fields in the model to be updated.
* fix: sider
* pref: clear scanned code after capturing value
* fix: use frappe.run_serially
- Separate getting dependants and checking if they are valid (loop within loop led to redundant processing that slowed down function)
- Adding to above, the same dependant(parent) was repeatedly processed as many children shared it. Expensive.
- Use a parent-child map similar to child-parent map to check if all children are resolved
- `map.get()` reduced time: 10 mins -> 0.9s~1 second (as compared to `get_cached_doc` or query)
- Total time: 17 seconds to process 6599 leaf boms and 4.2L parent boms
- Previous Total time: >10 mins (I terminated it due to not wanting to waste time XD)
