update_qc_reference() writes the QI link and bumps the reference
document's modified timestamp via raw db writes, which emit no realtime
event. A reference form (Purchase Receipt, Delivery Note, Stock Entry,
Job Card) still open in the browser keeps the old timestamp and fails
the timestamp conflict check on the next save/submit, forcing a manual
refresh after every QI submit/cancel/delete.
Calling notify_update() on the reference publishes the standard
doc_update event, so an open, unedited form silently reloads and syncs
its timestamp. get_lazy_doc skips child table loading since
notify_update only needs the parent row.
(cherry picked from commit 647452c95b)
covers the case where the percentages are correct but the accumulated
sum is 100.00000000000001. two rows can never drift, since the second
reconstructs exactly as 100 - first, so the case needs three rows.
(cherry picked from commit 4afba94d1c)
# Conflicts:
# erpnext/selling/doctype/sales_order/test_sales_order.py
the total of allocated_percentage was compared to 100 with exact float
equality, so a correct allocation could be rejected when the sum drifts
in binary floating point (10.0 + 58.02 + 31.98 -> 100.00000000000001).
round the total to the field precision before comparing, in both
SellingController.calculate_contribution and Customer.validate.
(cherry picked from commit f7b2775829)
* feat: sync serial no status from stock ledger in Stock Qty vs Serial No Count report
* fix: pick last bundle move in SQL ordered by posting datetime and SLE creation
* fix: derive synced serial no status from stock ledger helper and validate sync args
When the in-memory running rate is zero, the fallback went through
get_incoming_rate, whose previous-SLE lookup matches the same
posting_datetime and can land on a sibling line of the voucher being
replayed. Replace it with get_previous_sle_of_current_voucher excluding
the current voucher, keeping the get_valuation_rate chain when no
previous entry exists. get_incoming_rate is no longer used in this
module.
Reposting a return that removes most of the stock across several lines
of the same item must keep every line at the running average and produce
identical results on a second repost. Before the fix the first repost
already drifted, seeding each line from a sibling row of the same
voucher.
During repost, a return line with recalculate_rate resolved its moving
average rate through get_incoming_rate -> get_previous_sle, which matches
posting_datetime <= and orders by creation desc. For a multi-line return
of the same item, every line shares one posting_datetime, so the query
landed on a sibling line of the same voucher whose stored valuation_rate
was still the previous repost run's output, not the rate before the
voucher.
Each repost run therefore re-seeded the voucher from its own prior
output. The error gain per run is (qty returned at the stale rate) /
(qty remaining after the return), so whenever a return removes most of
the stock the loop diverges instead of converging, alternating sign and
growing until stock_value overflows decimal(21,9) and the repost dies
with 'Out of range value for column stock_value'.
Use the in-memory running valuation rate that update_entries_after
already tracks for the warehouse at this point in the repost. It is the
authoritative pre-entry state, is immune to sibling rows, and makes the
repost idempotent. The database lookup is kept only as a fallback for a
zero in-memory rate, preserving the existing zero-rate fallback chain.
The inverse (1 / value) and intermediate-UOM branches of
get_uom_conv_factor returned raw float quotients like
0.4535922921968971, bypassing the precision the docfields now declare.
Same for the client-side back-calculation from an edited stock qty.
Round both to the UOM Conversion Factor value precision.
(cherry picked from commit ca5a673409)
The Float control parses values with the field precision, falling back
to the global float precision when the docfield declares none
(frappe ControlFloat.parse / get_precision). On a site with float
precision 2, a fetched UOM factor of 0.453592292 was written back to
the model as 0.45, silently corrupting every derived quantity by 0.8
percent. A ratio must not inherit display precision meant for
quantities, so declare the same precision 9 the UOM Conversion Factor
master already uses on every transaction-level conversion_factor
field.
(cherry picked from commit 69a35a12cb)
# Conflicts:
# erpnext/accounts/doctype/pos_invoice_item/pos_invoice_item.json
# erpnext/accounts/doctype/purchase_invoice_item/purchase_invoice_item.json
# erpnext/accounts/doctype/sales_invoice_item/sales_invoice_item.json
# erpnext/buying/doctype/request_for_quotation_item/request_for_quotation_item.json
# erpnext/manufacturing/doctype/bom_secondary_item/bom_secondary_item.json
# erpnext/selling/doctype/quotation_item/quotation_item.json
# erpnext/selling/doctype/sales_order_item/sales_order_item.json
# erpnext/stock/doctype/delivery_note_item/delivery_note_item.json
# erpnext/stock/doctype/packed_item/packed_item.json
# erpnext/stock/doctype/pick_list_item/pick_list_item.json
# erpnext/stock/doctype/purchase_receipt_item/purchase_receipt_item.json
# erpnext/stock/doctype/stock_entry_detail/stock_entry_detail.json
# erpnext/subcontracting/doctype/subcontracting_receipt_item/subcontracting_receipt_item.json
# erpnext/subcontracting/doctype/subcontracting_receipt_supplied_item/subcontracting_receipt_supplied_item.json
Covers the _add_remaining_purchase_request path: partial stock in
another warehouse is allocated as a transfer and the residual purchase
qty goes through the second rounding site.
(cherry picked from commit 75145cc72c)
The stock-UOM qty is rounded in _accumulate_so_items, but the purchase
UOM conversion divided it by the conversion factor without re-rounding,
storing values like 5738748.300863984 in mr_items.quantity. The raw
value flowed into Material Request qty and the raw materials CSV, and
make_material_request compares quantity to requested_qty with exact
float equality, so any rounding downstream left dust quantities.
(cherry picked from commit ffc515f046)
The division by conversion_factor in _adjust_required_qty_for_uom sits
directly after frappe.throw inside the same block, so it can never run.
It has been dead since commit 2a8cd05b44 (#27278) re-indented it into
the throw branch; the actual purchase-UOM conversion happens in
_material_request_item_row via _mr_purchase_conversion_factor.
(cherry picked from commit 44260b469f)
# Conflicts:
# erpnext/manufacturing/doctype/production_plan/services/material_request.py
* fix: use current batch avg rate for outward returns of batchwise valuation batches
* fix: honor zero batch average and avoid duplicate batch classification query
frm.toggle_display("update_stock", ...) unconditionally forced the
field visible based only on has_subcontracted, overwriting whatever
Customize Form had set on every refresh. OR it with the field's
original (property-setter-driven) hidden value instead.
Backport of #57818.
* feat: validate stock value and stock closing entry before period closing
(cherry picked from commit 20450bd4ec)
* fix: do not accept scoped stock closing entries as period closing prerequisite
(cherry picked from commit 359a347be2)
* feat: seed batch valuation from stock closing balance and freeze closed-period stock
(cherry picked from commit 49a127d59c)
