the existing test_cost_center_for_manufacture only checks a raw material
row against an item-level override, which is set independently of the
":company" default guard and never exercised the bug.
(cherry picked from commit a168bb7ea4)
the ":company" default pre-filled every row before set_default_cost_center()
ran, so its "if not row.cost_center" guard was always false and the
project/item group/brand priority chain in get_default_cost_center()
never ran.
(cherry picked from commit edfa0a7a1d)
# Conflicts:
# erpnext/stock/doctype/stock_entry_detail/stock_entry_detail.json
Backport of #41024. Fixed-asset items now resolve expense_account from
the asset category (CWIP account when CWIP accounting is enabled,
otherwise the fixed asset account) for Purchase Receipt, Purchase Order
and Material Request, matching v16 behavior. v15 previously did this only
for Purchase Invoice.
When a reconciled voucher (Payment Entry / Journal Entry / Purchase
Invoice / Sales Invoice) is cancelled, amended and resubmitted, the
stale clearance date was carried into the amended draft because the
framework ignores `no_copy` while amending.
Add a shared `before_insert` hook on AccountsController that clears
`clearance_date` (top-level field and Sales Invoice `payments` rows)
on amendment. Reconciliation still sets the value post-submit via
`frappe.db.set_value`, which bypasses this path.
Manual backport of #55947 to version-15-hotfix (Mergify's auto-backport
#55972 committed conflict markers; this replaces it).
An incoming SLE without resolvable serial/batch details hit the
negative-head branch in _compute_incoming_stock even when the head was
a batch slot, because flt() on the batch number string returns 0.0.
_add_to_negative_fifo_head then crashed with
"TypeError: can only concatenate str (not 'float') to str".
Guard the branch with is_qty_slot, mirroring the existing check in
_add_transfer_slot_to_fifo_queue.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
(cherry picked from commit c47a95a4d2)
* fix: validate reverse GL entries on current date under immutable ledger (#56709)
* fix: validate reverse GL entries on current date under immutable ledger
When Immutable Ledger is enabled, the reverse GL entry is posted on the
current date, but the closed-period checks in make_reverse_gl_entries still
validate against the original (backdated) posting date. This blocks cancelling
a backdated voucher, such as a suspense Journal Entry for a migrated NPA loan,
with a books-closed error even though the reverse entry lands in an open period.
Validate both check_freezing_date and validate_against_pcv against the current
date when Immutable Ledger is enabled. When it is disabled, behaviour is
unchanged.
Follow-up to #55268.
* test: reset frozen till date after reverse entry test
The freeze date set on the company was not reset, so it leaked into the next
test which posts entries in that period. Reset it in a finally block.
* fix: prefer explicit posting_date under immutable ledger
Prefer the posting_date argument before frappe.form_dict and getdate, at both
the validation and the GL entry site, so an explicit date passed by the caller
is honoured and validation still matches the posted date.
(cherry picked from commit cab1b129c0)
# Conflicts:
# erpnext/accounts/general_ledger.py
* fix: resolved conflicts
Removed outdated check for freezing date in general ledger validation.
* fix: Update check_freezing_date function call parameters
* fix: accounts_frozen_till_date to acc_frozen_upto
* test: acc_frozen_upto setting in test_period_closing_voucher
---------
Co-authored-by: Nihantra C. Patel <141945075+Nihantra-Patel@users.noreply.github.com>
fix(stock): value batch/serial return from ledger when original receipt has no bundle (#56631)
* fix(stock): value batch/serial return from ledger when original receipt has no bundle
* test(stock): add test to validate the valuation of serial/batch for return when original receipt has no bundle
(cherry picked from commit 6184c057db)
Co-authored-by: Sudharsanan Ashok <135326972+Sudharsanan11@users.noreply.github.com>
rfq_transaction_list had two defects introduced when it was converted to the query
builder:
1. `party.supplier == party[0]` compared supplier to a column literally named "0"
(a stray index on the DocType, not the intended `parties[0]` value). This renders
as `supplier = \`0\`` / `supplier = "0"` and errors on BOTH engines
(MariaDB: Unknown column '0'; Postgres: column "0" does not exist), so the
supplier portal RFQ list was completely broken.
2. SELECT DISTINCT ordered by `creation`, which is not in the select list. Postgres
rejects this ("for SELECT DISTINCT, ORDER BY expressions must appear in select list").
Compare against `parties[0]` and add `creation` to the select list.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
(cherry picked from commit a7d9078bf4)
# Conflicts:
# erpnext/controllers/tests/test_website_list_for_contact.py
fix: carry item-level project to Purchase Receipt GL entries (#56568)
Purchase Receipt stock and asset GL lines used the item row's cost center
but always fell back to the document-level project, unlike Purchase Invoice
which uses the item-level project. add_gl_entry accepted a project argument
but never wrote it to the GL dict, so the inward, Stock Received But Not
Billed, landed cost, divisional loss, sub-contracting and exchange rate
lines dropped the row's project.
Write project into the GL dict and pass project=item.project on the entries
that were missing it, so project behaves like cost center and matches
Purchase Invoice.
Ticket: 72523
(cherry picked from commit 6f97c7199c)
Co-authored-by: Jatin3128 <140256508+Jatin3128@users.noreply.github.com>
The v15 backport (#55776) of #55774 dropped the stock_balance.py changes.
A separate backport left an inline version that sorts/filters the FIFO queue
by itemgetter(1) *before* normalizing, so for batchwise valuation slots
itemgetter(1) reads the count flag instead of the posting date. The queue is
then ordered wrong and earliest_age/latest_age come out swapped.
Extract get_stock_ageing_data, which normalizes before sorting/filtering so
itemgetter(1) is always the posting date, and add the regression test.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
