a dunning was resolved as soon as the invoiced sum was settled, because the
status was derived from the invoice outstanding alone. paying an invoice
without the interest and fee therefore closed the dunning and lost the
interest: a fresh dunning finds nothing overdue to charge it on.
the dunning amount is never a receivable, it only reaches the ledger as a
negative deduction on a payment entry made from the dunning. link that row
to the dunning so what has been collected is known, and resolve a dunning
only once the invoiced sum and the dunning amount are both paid. a dunning
resolved by hand keeps its status, so waiving the interest stays possible.
the deduction is a company currency field, so book and measure the dunning
amount through base_dunning_amount instead of the transaction currency one.
an interest-only payment leaves every invoice outstanding untouched, so
update the linked dunnings from the payment entry itself instead of relying
on the outstanding amount to change. such a payment also has to be built
from what is left to collect, not from the totals the dunning was raised
with, which are stale by then.
(cherry picked from commit d5a9d158f9)
paying a dunned invoice without its interest and fee marks the dunning
resolved, and the interest can no longer be collected.
(cherry picked from commit fa89552d10)
* fix(bank reconciliation): match Payment Entries on the bank-side amount (#57740)
* fix(bank reconciliation): match Payment Entries on the bank-side amount
get_pe_matching_query() ranked and filtered on pe.paid_amount while the
match card displayed pe.base_paid_amount_after_tax, so the amount used for
the exact match never matched the amount shown.
Both now use the amount that actually hits the bank account, in that
account's currency: received_amount_after_tax when the bank account is
paid_to (deposit) and paid_amount_after_tax when it is paid_from
(withdrawal). This is the same convention as the Bank Reconciliation
Statement report and matches the bank GL entry that reconciliation
allocates against.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* test(bank reconciliation): cover bank-side amount matching
Two cases the previous behaviour got wrong or could regress on:
- A deposit from an internal transfer where the paid and received sides
differ by a charge. The match must show, and compare against, the
amount that reached this bank account.
- A withdrawal, which still matches on the paid side.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
(cherry picked from commit 154c6fb943)
# Conflicts:
# erpnext/accounts/doctype/bank_reconciliation_tool/test_bank_reconciliation_tool.py
* fix: conflicts
* fix: add missing import
* chore: linting
---------
Co-authored-by: Hussain Nagaria <34810212+NagariaHussain@users.noreply.github.com>
Co-authored-by: Nikhil Kothari <nik.kothari22@live.com>
fix(banking): UI cleanup and better statement parsing (#58817)
* fix(banking): reset scroll on searching accounts
* fix(banking): show only past dates in date filter
* fix(banking): clean up line heights and remove beta badge
* fix(banking): show accurate count of import progress
fix(banking): show latest 20 imports instead of 10
* fix(banking): layout sizing needs to be preserved on page change
* fix(banking): cleaner bank balance UI
* fix(banking): correctly parse Cr/Dr values in statement importer
* Update banking/src/components/features/BankReconciliation/BankBalance.tsx
---------
(cherry picked from commit ebe5decb96)
Co-authored-by: Nikhil Kothari <nik.kothari22@live.com>
Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>
fix: user not able to set valuation rate zero in stock reco (#58800)
* fix: user not able to set valuation rate zero in stock reco
* fix: wrong difference amount when valuation rate is zero
* fix: blank valuation rate should not be treated as a change
(cherry picked from commit e85e300f8f)
Co-authored-by: rohitwaghchaure <rohitw1991@gmail.com>
* fix: round purchase quantities up to minimum order qty
Backport #57883 to version-16-hotfix. Adapt the purchase quantity conversion to the monolithic Production Plan controller and retain the Purchase Order rounding notice.
Add coverage for the complete Production Plan to Material Request to supplier-selected Purchase Order flow.
* fix(buying): skip rounding notice for mixed UOM increments
Require one shared rounding increment across the Purchase Order rows for each item before attributing the total excess to UOM rounding.
Cover mixed UOMs in both row orders, three mixed rows, and matching UOM rows that still require the notice.
refresh() loops over every row in the accounts child table and calls
set_exchange_rate() for each one. On v16 that function ended with
refresh_field("exchange_rate", cdn, "accounts"), which only takes the
cheap per-field path when the row is currently rendered. For every row
outside the visible page grid_rows_by_docname has no entry, so the
helper falls back to a full grid.refresh(): header, pagination and the
whole current page get rebuilt once per off-screen row.
Use grid.refresh_row(cdn) instead, which re-renders only the row that
actually changed and is a no-op for rows outside the current page. This
also matches what develop does after #58328.
Measured on a 1000-row Journal Entry (v16.local, Chromium): 950 of the
1000 rows triggered a full grid rebuild before, none after. Time to
first rendered row ~5.3s to ~1.7s, time to network-idle ~5.9s to ~2.3s,
and the set_exchange_rate loop itself ~4.7s to ~1.3s.
As a side effect the visible row now stays in sync: previously only the
exchange_rate cell was repainted, so the debit/credit columns that
set_debit_credit_in_company_currency had just recomputed kept showing
stale amounts.
Co-authored-by: jatin3128 <jatinsarna64@gmail.com>
* fix: check write permission in whitelisted document methods
* test: permission coverage for production plan status roll-ups
* fix: add type hints to whitelisted arguments and submit MR in test
