- Consider negative opening stock in logic and neutralise it with +ve stock
- minor code refactor: class for FIFOSlots to generate chronological FIFO queue
When making a backdated transactions current balance qty depends on
evaluation of whole ledger inbetween, instead of doing that just fetch
the last sle's qty_after_transaction when future transactions are
detected against SLE
fix: don't update bin's actual_qty
1. it's already updated by repost_current_voucher
2. update if future sle exists
mysql is generally smart enough to figure out which index is better
based on cardinality of index. While posting sort index is better for
low item high # of SLE scenario it's bad for high item variety each with
lower count of SLEs.
* fix: reservation for production incorrect
The query uses case to decide what fields to compute reservation on,
this case is outermost case hence the very first Work order's "Skip
transfer" is considered for ALL work orders.
Solution: move the case inside Sum.
Steps to reproduce:
1. Make work order for more than 1 qty (with | without skip transfer)
2. Create manufacture and transfer entries.
3. Keep checking reserved quantities during this process.
* test: use default warehouse for testing reservation
* fix: misleading "Set Default X" fields after saving
* refactor: remove unncessary code and minor formatting
* fix: extend to more doctypes and correct fieldnames
Co-authored-by: Ankush Menat <ankush@frappe.io>
This check was only checking total sum, which is problamatic when making
backdated entries that can cause intermediate values to go negative
while overall values stay positive.
batch's ledger is only maintained in form of `actual_qty` on batch's
SLEs. To validate if batch has any negative qty in future, cumulative
total of `actual_qty` is required to ensure it never goes negative.
Using basic idea that repost with older posting date will also take care
of subsequent posting dates...
When Item-WH reposts are queued:
1. If another repost with same item-wh but older posting date exists
then skip current one.
2. If another repost with same item-wh but newer posting date exists
then skip another one.
Item-WH based reposting requires querying existing similar repost.
Assuming there is only 1 max extra entry with same params just indexing
item-WH is sufficient to speed up the query.
In current implementation selecting Item-Warehouse based reposting is
better for few users, who don't use depenent SLEs but have frequent
transactions involving same items.
This change lets them switch to item-warehouse based reposting if
required.
Only use this if you understand technicalities of stock reposting. This
is experimental but will become mainstream in coming days.
- System cant differentiate between scrap and FG when WO is absent, so dont auto set
- User must set it manually
- `validate_finished_goods` checks this
If user reached this code then they already have permission to create
stock transaction, hence ignore permission checks while
creating/cancelling repost item valuation entries.
- Fix Server side PR test
- linter: re-arrange imports
- sider: avoid single line multi statement
- Code cleanup: Improve code readability and avoid horizontal scroll in test_purchase_receipt
- Removed unused variables in test_purchase_receipt
- remove extra space (sider)
- PR: Bring rejected qty in grid view
- PI: Rename `Stock Qty` to `Accepted Qty in Stock UOM`
- PI: Move `Accepted Qty in Stock UOM` under Stock UOM
Negative stock can be toggled back after queuing transactions, this
causes failure when repost is executed.
Now allow_negative_stock stock is set at time of queuing the repost job.
This means setting changes done afterwards won't affect already
submitted reposts.
- Fixed transferred qty not back updating on JC if partial transfer
- Partial transfer not mapping pending qty from JC correctly in SE
- tests for above cases
- minor code cleanup
