fix(cashier): fix Share account lookup false-negative in Transaction Entry

The partial/suffix match fallback was gated on "exactly one row came
back from the list endpoint", but Share's /accounts/share list has no
accountNo server-side filter at all — it always returns the full
unfiltered list, so that guard could never pass and any non-exact
account number search (e.g. shortened digits) reported "Account not
found" even when the account existed. This fix (present on dev, lost
in the earlier dev-merge's silent auto-resolve) drops the count gate
and tries suffix-match then substring-match unconditionally.
This commit is contained in:
2026-08-06 15:23:28 +05:30
parent 89bb76455e
commit 13333088d7
@@ -1633,12 +1633,14 @@ export class TransactionEntryComponent implements OnInit, OnDestroy {
if (token !== this.searchToken) return; // stale result — newer search started
const allItems: any[] = res?.pageItems ?? (Array.isArray(res) ? res : []);
const f = cfg.matchField;
// Exact match first, then suffix/partial match (backend may return by last-N-digits)
// Exact match first, then suffix/partial match. Some account types (e.g. Share — its
// list endpoint only accepts offset/limit, no accountNo filter at all) always return the
// FULL unfiltered list rather than a server-side-narrowed one, so a partial match can't be
// gated on "exactly one row came back" — it never would be for those types.
const exactMatch = allItems.find((x: any) => x[f] === acNo);
const partialMatch =
!exactMatch && allItems.length === 1
? allItems.find((x: any) => x[f]?.endsWith(acNo) || x[f]?.includes(acNo))
: null;
const partialMatch = !exactMatch
? (allItems.find((x: any) => x[f]?.endsWith(acNo)) ?? allItems.find((x: any) => x[f]?.includes(acNo)))
: null;
const match = exactMatch ?? partialMatch ?? null;
if (match?.id) {
const clientIdFromSearch = acTyp !== 'GL' && match.clientId != null ? String(match.clientId) : null;