@zeniai/client-epic-state 5.0.90-betaAR7 → 5.0.90-betaAR9

package/lib/esm/view/expenseAutomationView/transactionFilterHelpers.js

@@ -153,14 +153,17 @@ const getLineClassIdentifiersForTransaction = (transaction) => {
     return [];
 };
 /**
- * Type-narrowing guard for the three persisted line shapes that carry an
- * `account` + `class`. Kept as a single helper so the type list stays in
- * one place if a new categorizable line variant is added.
+ * Type-narrowing guard for the three persisted line shapes that extend
+ * `TransactionWithAccountAndClassLine` — they carry an `account` + `class`
+ * AND `vendor` + `customer` as optional per-line fields. Kept as a single
+ * helper so the type list stays in one place if a new categorizable
+ * line variant is added; reused by the category, class, and payee
+ * per-line resolvers below.
  *
- * Typed against the union element produced by indexing `lines[number]` on
- * the broader transaction type — the parameter is permitted to be
- * `undefined` so callers can pass a possibly-sparse `lines` element
- * without an extra null check.
+ * Typed against a structural `{type?: string}` shape rather than the
+ * concrete `Line` union so callers can pass a possibly-sparse element
+ * without an extra null check. The cast to
+ * `TransactionWithAccountAndClassLine` happens at the call sites.
  */
 const isAccountAndClassLine = (line) => line?.type === 'transaction_with_account_and_class_line' ||
     line?.type === 'transaction_with_product_or_service_line' ||
@@ -204,14 +207,112 @@ const resolveClassIdentifier = (classData) => {
     }
     return undefined;
 };
+/**
+ * Resolve a single line's payee name. Vendor wins over customer
+ * (preserved from the single-scalar predecessor — TC transactions are
+ * overwhelmingly expense-side). `isNonEmptyString` so an empty-string
+ * placeholder on `vendor.name` falls through to `customer.name` rather
+ * than shadowing it.
+ */
+const resolveLineLevelPayee = (vendor, customer) => {
+    if (isNonEmptyString(vendor?.name)) {
+        return vendor?.name;
+    }
+    if (isNonEmptyString(customer?.name)) {
+        return customer?.name;
+    }
+    return undefined;
+};
+/**
+ * All payee names that could legitimately identify a transaction, across
+ * every place TC stores payee data:
+ *
+ *   • localData `lineItemById[*].vendor` / `.customer` — per-line
+ *     vendor/customer the user has tagged in the grid. Populated for
+ *     JEs (where the row reads per-line vendor) and sometimes for
+ *     vendor-typed transactions too (e.g. when an AI vendor
+ *     recommendation lands on a line).
+ *   • Persisted `transaction.lines[*].vendor` / `.customer` — same
+ *     fields on the server snapshot of each line.
+ *   • localData transaction-level `vendor` / `customer` — what the row
+ *     displays for vendor-typed transactions (Bills / Expenses /
+ *     Checks).
+ *   • Top-level `transaction.vendorName` / `customerName` — pre-edit
+ *     server snapshot.
+ *
+ * The function collects names from ALL of these into a single set
+ * rather than picking exclusively from the highest-priority source.
+ * Two reasons:
+ *
+ *   1. Different transaction types put the displayed payee in different
+ *      places. JEs put it on the line; Bills put it at the transaction
+ *      level. A strict-precedence rule that returns early on the first
+ *      non-empty source ends up missing the OTHER place when both have
+ *      data with different values — which is exactly the
+ *      production failure mode that motivated this fix (a Bill whose
+ *      localData line item carried an AI-recommended vendor name was
+ *      excluded because the recommendation won priority over the
+ *      tx-level "Amazon" the row actually displayed).
+ *   2. The single-scalar predecessor missed JE rows entirely because
+ *      it only looked at the tx level. Unioning the line-level sources
+ *      in fixes that without re-introducing the "first source wins"
+ *      brittleness.
+ *
+ * False positives are bounded: a transaction matches `payee = X` only
+ * if `X` literally appears in one of its stored payee fields. Stale
+ * recommendation data being included means the filter is slightly more
+ * lenient than what the row displays, not arbitrary.
+ *
+ * Returns `[]` when no source carries any name; the caller falls back
+ * to the absent-value contract (only `not_equal` matches; every other
+ * operator excludes).
+ */
+const getLinePayeesForTransaction = (transaction) => {
+    const localData = transaction?.transactionLocalData?.transactionReviewLocalData;
+    // Set used to dedupe — the same vendor name often appears in multiple
+    // sources (e.g. localData mirror of a persisted line) and we don't
+    // want it to be over-counted in the match list. Iteration order is
+    // insertion-order; `.some()` doesn't depend on order so this is fine.
+    const payees = new Set();
+    const addIfPresent = (name) => {
+        if (isNonEmptyString(name)) {
+            payees.add(name);
+        }
+    };
+    // localData per-line vendor / customer
+    if (localData?.lineItemById != null) {
+        Object.values(localData.lineItemById).forEach((lineItem) => {
+            addIfPresent(resolveLineLevelPayee(lineItem?.vendor, lineItem?.customer));
+        });
+    }
+    // Persisted per-line vendor / customer (only on the three line
+    // shapes that actually carry them — see `isAccountAndClassLine`).
+    if (transaction?.transaction?.lines != null &&
+        transaction.transaction.lines.length > 0) {
+        transaction.transaction.lines.forEach((line) => {
+            if (!isAccountAndClassLine(line)) {
+                return;
+            }
+            const typedLine = line;
+            addIfPresent(resolveLineLevelPayee(typedLine.vendor, typedLine.customer));
+        });
+    }
+    // Transaction-level: localData first so unsaved grid edits make it
+    // into the match set, then the pre-edit server fields.
+    addIfPresent(localData?.vendor?.name);
+    addIfPresent(localData?.customer?.name);
+    addIfPresent(transaction?.vendorName);
+    addIfPresent(transaction?.customerName);
+    return Array.from(payees);
+};
 /**
  * Resolve the comparable value for a transaction against a given filter field.
  * Returns undefined when the transaction doesn't carry the field — callers
  * decide whether absence counts as a match (for 'not_equal' it does).
  *
- * NOTE: the `'amount'`, `'category'`, and `'class'` fields are NOT handled
- * here. All three use per-line matching via the corresponding
- * `getLine*ForTransaction` helper and an early-return in
+ * NOTE: the `'amount'`, `'category'`, `'class'`, and `'payee'` fields
+ * are NOT handled here. All four use per-line matching via the
+ * corresponding `getLine*ForTransaction` helper and an early-return in
  * `transactionMatchesCategory` — they would otherwise need to return a
  * non-scalar value that doesn't fit this helper's contract. Cases are
  * preserved so the switch stays exhaustive over `TransactionFilterCategoryField`.
@@ -224,46 +325,9 @@ const getCategoryValueForTransaction = (key, transaction) => {
             return undefined;
         }
         case 'payee': {
-            /*
-             * localData wins over the top-level transaction fields. Two reasons:
-             *
-             *   1. Matches what the row renders. `TransactionCategorizationListRow`
-             *      reads `transaction.transactionReviewLocalData.vendor?.name` as
-             *      its canonical payee source — not `transaction.vendorName`. If
-             *      the user has manually picked a vendor in the grid (still
-             *      unsaved), the row updates immediately but the pre-fix filter
-             *      kept comparing against the stale top-level value, so filtering
-             *      "Acme" against a row the user just relabeled to "Acme" would
-             *      silently exclude it.
-             *
-             *   2. Brings payee in line with the other content-bearing fields.
-             *      After this change, every field that has a localData mirror
-             *      (`amount`, `category`, `class`, `payee`) reads localData
-             *      first. The remaining fields (`payment_account_name`,
-             *      `payment_account_type`) don't have a localData equivalent
-             *      yet — when they do, this precedence becomes the universal
-             *      rule.
-             *
-             * vendor is checked before customer at each level — TC transactions
-             * are overwhelmingly expense-side, so vendor is the common case. A
-             * transaction with both a vendor AND a customer locally set is rare
-             * and the existing behavior (vendor wins) is preserved.
-             */
-            const localData = transaction.transactionLocalData?.transactionReviewLocalData;
-            const localVendorName = localData?.vendor?.name;
-            if (isNonEmptyString(localVendorName)) {
-                return localVendorName;
-            }
-            const localCustomerName = localData?.customer?.name;
-            if (isNonEmptyString(localCustomerName)) {
-                return localCustomerName;
-            }
-            if (isNonEmptyString(transaction.vendorName)) {
-                return transaction.vendorName;
-            }
-            if (isNonEmptyString(transaction.customerName)) {
-                return transaction.customerName;
-            }
+            // Handled per-line in `transactionMatchesCategory` — see
+            // `getLinePayeesForTransaction`. The transaction-level localData /
+            // top-level chain lives inside that helper's priority-3 fallback.
             return undefined;
         }
         case 'payment_account_name': {
@@ -339,6 +403,29 @@ const matchAmount = (amount, category) => {
     return op === 'not_equal' ? !matched : matched;
 };
 const transactionMatchesCategory = (transaction, category) => {
+    if (category.field === 'payee') {
+        // Per-line matching for payee — mirrors the amount / category /
+        // class pattern. The row's display reads `line.vendor?.name` for
+        // non-vendor-typed transactions (Journal Entries, etc.), so the
+        // filter has to look at line-level payee data too or it silently
+        // misses every JE whose vendor lives on the line. See the JSDoc
+        // on `getLinePayeesForTransaction` for the full precedence.
+        //
+        // `not_equal` reads the same way it does for category/class:
+        // "at least one line's payee is NOT one of the filter values".
+        // A JE with lines [Amazon, Acme] matches `payee != Amazon` via
+        // the Acme line; a bill or JE whose every line says "Amazon"
+        // does not match `payee != Amazon`.
+        const linePayees = getLinePayeesForTransaction(transaction);
+        if (linePayees.length === 0) {
+            return category.matchingOperator === 'not_equal';
+        }
+        const filterValuesAsStrings = new Set(category.values.map((v) => v.toString()));
+        return linePayees.some((name) => {
+            const inList = filterValuesAsStrings.has(name);
+            return category.matchingOperator === 'not_equal' ? !inList : inList;
+        });
+    }
     if (category.field === 'category' || category.field === 'class') {
         // Per-line matching for category / class — mirrors the amount
         // pattern below. A multi-line transaction surfaces when ANY of its

package/lib/view/expenseAutomationView/transactionFilterHelpers.js

@@ -156,14 +156,17 @@ const getLineClassIdentifiersForTransaction = (transaction) => {
     return [];
 };
 /**
- * Type-narrowing guard for the three persisted line shapes that carry an
- * `account` + `class`. Kept as a single helper so the type list stays in
- * one place if a new categorizable line variant is added.
+ * Type-narrowing guard for the three persisted line shapes that extend
+ * `TransactionWithAccountAndClassLine` — they carry an `account` + `class`
+ * AND `vendor` + `customer` as optional per-line fields. Kept as a single
+ * helper so the type list stays in one place if a new categorizable
+ * line variant is added; reused by the category, class, and payee
+ * per-line resolvers below.
  *
- * Typed against the union element produced by indexing `lines[number]` on
- * the broader transaction type — the parameter is permitted to be
- * `undefined` so callers can pass a possibly-sparse `lines` element
- * without an extra null check.
+ * Typed against a structural `{type?: string}` shape rather than the
+ * concrete `Line` union so callers can pass a possibly-sparse element
+ * without an extra null check. The cast to
+ * `TransactionWithAccountAndClassLine` happens at the call sites.
  */
 const isAccountAndClassLine = (line) => line?.type === 'transaction_with_account_and_class_line' ||
     line?.type === 'transaction_with_product_or_service_line' ||
@@ -207,14 +210,112 @@ const resolveClassIdentifier = (classData) => {
     }
     return undefined;
 };
+/**
+ * Resolve a single line's payee name. Vendor wins over customer
+ * (preserved from the single-scalar predecessor — TC transactions are
+ * overwhelmingly expense-side). `isNonEmptyString` so an empty-string
+ * placeholder on `vendor.name` falls through to `customer.name` rather
+ * than shadowing it.
+ */
+const resolveLineLevelPayee = (vendor, customer) => {
+    if (isNonEmptyString(vendor?.name)) {
+        return vendor?.name;
+    }
+    if (isNonEmptyString(customer?.name)) {
+        return customer?.name;
+    }
+    return undefined;
+};
+/**
+ * All payee names that could legitimately identify a transaction, across
+ * every place TC stores payee data:
+ *
+ *   • localData `lineItemById[*].vendor` / `.customer` — per-line
+ *     vendor/customer the user has tagged in the grid. Populated for
+ *     JEs (where the row reads per-line vendor) and sometimes for
+ *     vendor-typed transactions too (e.g. when an AI vendor
+ *     recommendation lands on a line).
+ *   • Persisted `transaction.lines[*].vendor` / `.customer` — same
+ *     fields on the server snapshot of each line.
+ *   • localData transaction-level `vendor` / `customer` — what the row
+ *     displays for vendor-typed transactions (Bills / Expenses /
+ *     Checks).
+ *   • Top-level `transaction.vendorName` / `customerName` — pre-edit
+ *     server snapshot.
+ *
+ * The function collects names from ALL of these into a single set
+ * rather than picking exclusively from the highest-priority source.
+ * Two reasons:
+ *
+ *   1. Different transaction types put the displayed payee in different
+ *      places. JEs put it on the line; Bills put it at the transaction
+ *      level. A strict-precedence rule that returns early on the first
+ *      non-empty source ends up missing the OTHER place when both have
+ *      data with different values — which is exactly the
+ *      production failure mode that motivated this fix (a Bill whose
+ *      localData line item carried an AI-recommended vendor name was
+ *      excluded because the recommendation won priority over the
+ *      tx-level "Amazon" the row actually displayed).
+ *   2. The single-scalar predecessor missed JE rows entirely because
+ *      it only looked at the tx level. Unioning the line-level sources
+ *      in fixes that without re-introducing the "first source wins"
+ *      brittleness.
+ *
+ * False positives are bounded: a transaction matches `payee = X` only
+ * if `X` literally appears in one of its stored payee fields. Stale
+ * recommendation data being included means the filter is slightly more
+ * lenient than what the row displays, not arbitrary.
+ *
+ * Returns `[]` when no source carries any name; the caller falls back
+ * to the absent-value contract (only `not_equal` matches; every other
+ * operator excludes).
+ */
+const getLinePayeesForTransaction = (transaction) => {
+    const localData = transaction?.transactionLocalData?.transactionReviewLocalData;
+    // Set used to dedupe — the same vendor name often appears in multiple
+    // sources (e.g. localData mirror of a persisted line) and we don't
+    // want it to be over-counted in the match list. Iteration order is
+    // insertion-order; `.some()` doesn't depend on order so this is fine.
+    const payees = new Set();
+    const addIfPresent = (name) => {
+        if (isNonEmptyString(name)) {
+            payees.add(name);
+        }
+    };
+    // localData per-line vendor / customer
+    if (localData?.lineItemById != null) {
+        Object.values(localData.lineItemById).forEach((lineItem) => {
+            addIfPresent(resolveLineLevelPayee(lineItem?.vendor, lineItem?.customer));
+        });
+    }
+    // Persisted per-line vendor / customer (only on the three line
+    // shapes that actually carry them — see `isAccountAndClassLine`).
+    if (transaction?.transaction?.lines != null &&
+        transaction.transaction.lines.length > 0) {
+        transaction.transaction.lines.forEach((line) => {
+            if (!isAccountAndClassLine(line)) {
+                return;
+            }
+            const typedLine = line;
+            addIfPresent(resolveLineLevelPayee(typedLine.vendor, typedLine.customer));
+        });
+    }
+    // Transaction-level: localData first so unsaved grid edits make it
+    // into the match set, then the pre-edit server fields.
+    addIfPresent(localData?.vendor?.name);
+    addIfPresent(localData?.customer?.name);
+    addIfPresent(transaction?.vendorName);
+    addIfPresent(transaction?.customerName);
+    return Array.from(payees);
+};
 /**
  * Resolve the comparable value for a transaction against a given filter field.
  * Returns undefined when the transaction doesn't carry the field — callers
  * decide whether absence counts as a match (for 'not_equal' it does).
  *
- * NOTE: the `'amount'`, `'category'`, and `'class'` fields are NOT handled
- * here. All three use per-line matching via the corresponding
- * `getLine*ForTransaction` helper and an early-return in
+ * NOTE: the `'amount'`, `'category'`, `'class'`, and `'payee'` fields
+ * are NOT handled here. All four use per-line matching via the
+ * corresponding `getLine*ForTransaction` helper and an early-return in
  * `transactionMatchesCategory` — they would otherwise need to return a
  * non-scalar value that doesn't fit this helper's contract. Cases are
  * preserved so the switch stays exhaustive over `TransactionFilterCategoryField`.
@@ -227,46 +328,9 @@ const getCategoryValueForTransaction = (key, transaction) => {
             return undefined;
         }
         case 'payee': {
-            /*
-             * localData wins over the top-level transaction fields. Two reasons:
-             *
-             *   1. Matches what the row renders. `TransactionCategorizationListRow`
-             *      reads `transaction.transactionReviewLocalData.vendor?.name` as
-             *      its canonical payee source — not `transaction.vendorName`. If
-             *      the user has manually picked a vendor in the grid (still
-             *      unsaved), the row updates immediately but the pre-fix filter
-             *      kept comparing against the stale top-level value, so filtering
-             *      "Acme" against a row the user just relabeled to "Acme" would
-             *      silently exclude it.
-             *
-             *   2. Brings payee in line with the other content-bearing fields.
-             *      After this change, every field that has a localData mirror
-             *      (`amount`, `category`, `class`, `payee`) reads localData
-             *      first. The remaining fields (`payment_account_name`,
-             *      `payment_account_type`) don't have a localData equivalent
-             *      yet — when they do, this precedence becomes the universal
-             *      rule.
-             *
-             * vendor is checked before customer at each level — TC transactions
-             * are overwhelmingly expense-side, so vendor is the common case. A
-             * transaction with both a vendor AND a customer locally set is rare
-             * and the existing behavior (vendor wins) is preserved.
-             */
-            const localData = transaction.transactionLocalData?.transactionReviewLocalData;
-            const localVendorName = localData?.vendor?.name;
-            if (isNonEmptyString(localVendorName)) {
-                return localVendorName;
-            }
-            const localCustomerName = localData?.customer?.name;
-            if (isNonEmptyString(localCustomerName)) {
-                return localCustomerName;
-            }
-            if (isNonEmptyString(transaction.vendorName)) {
-                return transaction.vendorName;
-            }
-            if (isNonEmptyString(transaction.customerName)) {
-                return transaction.customerName;
-            }
+            // Handled per-line in `transactionMatchesCategory` — see
+            // `getLinePayeesForTransaction`. The transaction-level localData /
+            // top-level chain lives inside that helper's priority-3 fallback.
             return undefined;
         }
         case 'payment_account_name': {
@@ -342,6 +406,29 @@ const matchAmount = (amount, category) => {
     return op === 'not_equal' ? !matched : matched;
 };
 const transactionMatchesCategory = (transaction, category) => {
+    if (category.field === 'payee') {
+        // Per-line matching for payee — mirrors the amount / category /
+        // class pattern. The row's display reads `line.vendor?.name` for
+        // non-vendor-typed transactions (Journal Entries, etc.), so the
+        // filter has to look at line-level payee data too or it silently
+        // misses every JE whose vendor lives on the line. See the JSDoc
+        // on `getLinePayeesForTransaction` for the full precedence.
+        //
+        // `not_equal` reads the same way it does for category/class:
+        // "at least one line's payee is NOT one of the filter values".
+        // A JE with lines [Amazon, Acme] matches `payee != Amazon` via
+        // the Acme line; a bill or JE whose every line says "Amazon"
+        // does not match `payee != Amazon`.
+        const linePayees = getLinePayeesForTransaction(transaction);
+        if (linePayees.length === 0) {
+            return category.matchingOperator === 'not_equal';
+        }
+        const filterValuesAsStrings = new Set(category.values.map((v) => v.toString()));
+        return linePayees.some((name) => {
+            const inList = filterValuesAsStrings.has(name);
+            return category.matchingOperator === 'not_equal' ? !inList : inList;
+        });
+    }
     if (category.field === 'category' || category.field === 'class') {
         // Per-line matching for category / class — mirrors the amount
         // pattern below. A multi-line transaction surfaces when ANY of its

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@zeniai/client-epic-state",
-  "version": "5.0.90-betaAR7",
+  "version": "5.0.90-betaAR9",
   "description": "Shared module between Web & Mobile containing required abstractions for state management, async network communication. ",
   "main": "lib/index.js",
   "module": "lib/esm/index.js",