* fix(stock): keep manufactured item rate at zero when inputs are free
when a finished item is produced from raw materials consumed at zero
valuation, the incoming rate fell back to the item's own valuation
rate (or BOM cost), valuing free inputs as output and inflating the fg
value on every production run.
add has_consumption_basis() to detect when the consumed cost is known
even if it is zero (consumed rows present, or a consumption entry
exists for the work order). when it is, skip the get_valuation_rate and
BOM-cost fallbacks so a real cost of zero is preserved.
* test(stock): cover manufacture rate for zero-valued raw materials
- manufacture from a free input keeps fg basic_rate and sle
incoming_rate/stock_value_difference at zero even when the fg already
carries a valuation in the target warehouse
- material consumption on with no consumption entry does not fall back
to bom/price-list rate for free inputs
- zero-valued consumption entry keeps the manufacture entry's fg rate
at zero
(cherry picked from commit 73224d3650)
# Conflicts:
# erpnext/stock/doctype/stock_entry/stock_entry.py
# erpnext/stock/doctype/stock_entry/test_stock_entry.py
* fix: Incorrect creation time at the time cancelling an entry causing an issue especially same posting datetime (#57380)
* fix: shift same-timestamp sibling SLEs when cancelling an entry
update_qty_in_future_sle compared against the reversal SLE's own
creation and skipped same-posting_datetime siblings on cancel, leaving
their qty_after_transaction stale and causing false negative stock
errors.
* fix: revert update_qty_in_future_sle cancel tie-break, it double-counted
(cherry picked from commit 8c0ec3c179)
# Conflicts:
# erpnext/stock/doctype/stock_ledger_entry/test_stock_ledger_entry.py
* chore: fix conflicts
Fix test cases related to stock ledger entry cancellations and ensure correct handling of same timestamp entries.
* test: use named item in test_cancel_shifts_same_timestamp_delivery_notes
* chore: fix typo
---------
Co-authored-by: rohitwaghchaure <rohitw1991@gmail.com>
fix(stock): narrow legacy serial ledger lookup by item (#57499)
Filter legacy Stock Ledger Entry lookups by item code so the existing
item and warehouse index can reduce rows scanned during serial valuation.
(cherry picked from commit 425191e57e)
Co-authored-by: Sudharsanan Ashok <135326972+Sudharsanan11@users.noreply.github.com>
A batch is one valuation pool, so any per-slot value difference within a
batch is stale detail from the report's own age slots, not real valuation.
The rebalance only ran when consumption had already driven a slot negative,
so a batch whose receipts landed at different rates kept a skewed split
across age buckets (one bucket free, another double-priced) while the total
stayed correct.
Drop the negative-slot precondition and always spread a batch's pooled value
over its slots in proportion to qty. Redistribution preserves group totals,
so buckets still sum to Stock Balance; only the split across ages changes.
(cherry picked from commit cedaaa3a00)
close a partially-received sco with a reserve warehouse and assert the
raw-material reservation is released and projected qty recovers.
(cherry picked from commit e4b8065a69)
the bin reserved-qty recalc filtered out closed purchase orders but not
closed subcontracting orders, so closing a partially-received sco kept the
reservation for the unreceived qty and left projected qty understated.
apply the same closed-status filter to the subcontracting order path.
(cherry picked from commit db91a79d31)
# Conflicts:
# erpnext/stock/doctype/bin/bin.py
use frappe.get_list instead of frappe.get_all in get_dashboard_info so
the company list honors user permissions. previously, a party with
invoices across multiple companies would raise "User don't have
permissions to select/read this account" for users restricted to a
subset of companies, since get_party_account was called for companies
the user could not access.
fixesfrappe/erpnext#57428
(cherry picked from commit 903c87bcaa)
sort on (expiry is none, expiry) so a null expiry_date is never
order-compared against a datetime.date, which raised typeerror in
python 3 when a warehouse held both dated and never-expiring batches.
(cherry picked from commit 62c9f8ee3e)
A batch is one valuation pool, so consumption is valued at the pooled
rate while slots may carry stale intra-batch detail (e.g. units
reconciled at zero and later merged). Consuming such a slot leaves a
negative value on positive qty. Spread the pool value across the
batch's slots when that happens; non-batchwise slots pool per
warehouse.
On cancel, update_entries_after replays every live SLE at the voucher's
posting datetime, but get_previous_sle_of_current_voucher seeded the
replay with the reversal SLE's creation, which resolves to the bucket's
own closing row. The bucket's net qty got double-counted into every
same-datetime row, so later submissions passed negative stock validation
against inflated balances, and the queued repost then rewrote correct
values with allow_negative_stock forced on, silently creating negative
stock. Backports the missing guard from eca71dce54.
Stock Balance builds stock ageing by passing its own SLE rows into
FIFOSlots, whose gates read row.has_batch_no and row.has_serial_no.
The query never selected has_batch_no at all, and read has_serial_no
from the SLE column, which is unset on rows predating v15's bundle
migration (no backfill patch exists). With the flags falsy, incoming
batch/serial stock was queued as plain qty slots while outgoing was
consumed batch/serial-wise, so the shapes never consume each other,
and bundle-based rows resolved no batch details, letting the plain
consume path overwrite batch slots in place (flt(batch_no) reads as
qty 0). Besides wrong ageing figures, sorting the resulting queue
crashed with TypeError: '<' not supported between 'int' and
'datetime.date'.
Select both flags from Item, matching Stock Ageing's own query. Only
this report is affected; develop dropped the sle_entries pass-in in
#44489.
get_single_value inside _revalue_reconciled_batch_slots runs while
rows stream through the unbuffered cursor on MariaDB, killing the
active iterator. Resolve it once in generate() with the other
prefetches.
