@zeniai/client-epic-state 5.2.54 → 5.2.56-betaRD1

package/lib/view/expenseAutomationView/selectors/jeSchedulesViewSelector.js

@@ -225,7 +225,7 @@ function getExpenseAutomationJESchedulesView(state) {
     const accruedSchedules = [];
     const oneTimeAccruals = [];
     const { accountState, accountListState, classState, classListState, expenseAutomationJESchedulesViewState, expenseAutomationViewState, monthEndCloseChecksState, } = state;
-    const { jeScheduleTransactionKeysByPeriodAndTab, jeScheduleAccruedKeysByPeriodAndTab, jeScheduleOneTimeAccrualKeysByPeriodAndTab, failedJeScheduleTransactionKeysByPeriodAndTab, jeScheduleLocalDataById, postStatusById, ignoreStatusById, revertStatusById, oneTimeAccrualActionStatusById, uiState, error, fetchState, refreshStatus, newSchedule, } = expenseAutomationJESchedulesViewState;
+    const { jeScheduleTransactionKeysByPeriodAndTab, jeScheduleAccruedKeysByPeriodAndTab, jeScheduleOneTimeAccrualKeysByPeriodAndTab, failedJePostings, jeScheduleLocalDataById, postStatusById, ignoreStatusById, revertStatusById, oneTimeAccrualActionStatusById, uiState, error, fetchState, refreshStatus, newSchedule, } = expenseAutomationJESchedulesViewState;
     const accountSettingsView = (0, jeAccountSettingsViewSelector_1.getJEAccountSettingsView)(state);
     const newScheduleView = newSchedule.selectedDetailScheduleType === 'fixed_assets' ||
         newSchedule.selectedDetailScheduleType === 'prepaid_expenses'
@@ -264,15 +264,11 @@ function getExpenseAutomationJESchedulesView(state) {
     const jeScheduleTransactionKeysForSelectedTab = selectedPeriodTabKey != null
         ? jeScheduleTransactionKeysByPeriodAndTab[selectedPeriodTabKey]
         : undefined;
-    const failedJeScheduleTransactionKeysForSelectedTab = selectedPeriodTabKey != null
-        ? failedJeScheduleTransactionKeysByPeriodAndTab[selectedPeriodTabKey]
-        : undefined;
     // Distinguishes "this tab has never been fetched for this period" from "fetched and genuinely
     // empty". Without it the page cannot tell a first visit from a real empty state, and renders an
     // empty table where it should render a skeleton.
     const hasLoadedForSelectedTab = jeScheduleTransactionKeysForSelectedTab != null;
     const jeScheduleTransactionKeys = jeScheduleTransactionKeysForSelectedTab ?? [];
-    const failedJeScheduleTransactionKeys = failedJeScheduleTransactionKeysForSelectedTab ?? [];
     const jeScheduleAccruedKeys = (selectedPeriodTabKey != null
         ? jeScheduleAccruedKeysByPeriodAndTab[selectedPeriodTabKey]
         : undefined) ?? [];
@@ -295,24 +291,57 @@ function getExpenseAutomationJESchedulesView(state) {
             accruedSchedules.push(accruedScheduleDetails);
         }
     });
-    failedJeScheduleTransactionKeys.forEach((jeScheduleKey) => {
-        const jeScheduleDetails = (0, jeSchedulesSelector_1.getJEScheduledTransactionByJEScheduleTransactionKey)(jeScheduleKey, state);
-        failedJeScheduledTransaction.push(jeScheduleDetails);
+    // Sourced from the tenant-wide bucket, not the per-period one: a failed posting belongs to no
+    // close month, and windowing it is what kept older failures off the only tab that can resolve
+    // them.
+    failedJePostings.jeScheduleTransactionKeys.forEach((jeScheduleKey) => {
+        // getJEScheduledTransactionByJEScheduleTransactionKey throws three different ways: it
+        // destructures the result of recordGet without a null check, and it raises explicitly for a
+        // missing vendor and for a missing base transaction. Catching rather than pre-checking each
+        // one keeps this correct if a fourth is added, and none of the three is recoverable here --
+        // the row cannot be drawn either way.
+        //
+        // This matters more for this bucket than anywhere else on the page. It is tenant-wide, so it
+        // names schedules the close-month list never loaded, and the group is defined by deleted
+        // vendors and deleted categories -- precisely the rows whose entities are most likely to be
+        // missing. Unguarded, one such key takes down the whole JE tab instead of dropping one row.
+        try {
+            failedJeScheduledTransaction.push((0, jeSchedulesSelector_1.getJEScheduledTransactionByJEScheduleTransactionKey)(jeScheduleKey, state));
+        }
+        catch {
+            // Intentionally swallowed: a failed posting we cannot resolve is one missing row, and the
+            // alternative is a blank page for every other row too.
+        }
     });
+    // What the endpoint last reported as failing. The entity store keeps every month a schedule
+    // has and an entry resolved by someone else keeps its old `error` array, so `error` alone would
+    // leave a Retry button on a posting that is no longer failing.
+    const failedScheduledJournalEntryIDs = new Set(failedJePostings.scheduledJournalEntryIDs);
     const { sortKey, sortOrder, selectedJETypeFilter } = uiState;
+    const matchesTypeFilter = (schedule) => selectedJETypeFilter == null ||
+        getJEScheduleRowType(schedule) === selectedJETypeFilter;
     const unsortedResolveSchedules = [];
     failedJeScheduledTransaction.forEach((schedule) => {
-        schedule.scheduledJournalEntry.forEach((journalEntry) => {
+        // Only the entries that actually carry an error. The schedule's entry array is shared state:
+        // opening a schedule's detail page or Quick View replaces it with every month the schedule
+        // has, posted ones included, so fanning out over all of them turned one failed posting into a
+        // row per month -- and a month that never failed has nothing to resolve, so it rendered with
+        // an empty action column.
+        //
+        // Intersected with the ids the endpoint actually returned, not just `error`: the entry array
+        // is a cache of every month, and an entry whose failure someone else resolved keeps its stale
+        // error array until something overwrites it. Only what the last fetch named is still failing.
+        schedule.scheduledJournalEntry
+            .filter((journalEntry) => journalEntry.error.length > 0 &&
+            failedScheduledJournalEntryIDs.has(journalEntry.scheduledJournalEntryID))
+            .forEach((journalEntry) => {
             unsortedResolveSchedules.push({
                 ...schedule,
                 scheduledJournalEntry: journalEntry,
             });
         });
     });
-    const resolveSchedules = sortJEScheduledTransactions(unsortedResolveSchedules, sortKey, sortOrder);
-    const validResolveForPending = unsortedResolveSchedules.filter((r) => jeScheduleLocalDataById[r.scheduledJournalEntry.scheduledJournalEntryID] != null);
-    const matchesTypeFilter = (schedule) => selectedJETypeFilter == null ||
-        getJEScheduleRowType(schedule) === selectedJETypeFilter;
+    const resolveSchedules = sortJEScheduledTransactions(unsortedResolveSchedules.filter(matchesTypeFilter), sortKey, sortOrder);
     const isCreatedStatus = (schedule) => {
         // An accrual is "created" once it is not review work: posted, reversing, reversed, or in a
         // transient posting claim.
@@ -330,7 +359,6 @@ function getExpenseAutomationJESchedulesView(state) {
     ];
     const pendingReviewSchedules = sortJEScheduledTransactions([
         ...allScheduleRows.filter((schedule) => isPendingReviewRow(schedule) && matchesTypeFilter(schedule)),
-        ...validResolveForPending,
     ], sortKey, sortOrder);
     const createdSchedules = sortJEScheduledTransactions(allScheduleRows.filter((schedule) => isCreatedStatus(schedule) && matchesTypeFilter(schedule)), sortKey, sortOrder);
     // KPI summary — derived from unfiltered schedules so counts are always accurate
@@ -449,6 +477,13 @@ function getExpenseAutomationJESchedulesView(state) {
         kpiSummary,
         pendingReviewSchedules,
         pendingReviewTotal,
+        failedPostings: resolveSchedules,
+        // Exposed so a consumer can tell "still loading" and "the lookup failed" from "nothing has
+        // failed". The bucket keeps its rows on failure precisely so an error can be shown beside
+        // them, which is only possible if the state travels with them.
+        failedPostingsFetchState: failedJePostings.fetchState,
+        // Deprecated alias of failedPostings. Still read by the section's footer-form effect and by
+        // app-ui analytics; remove once both are repointed.
         resolveSchedules: resolveSchedules,
         accountSettingsView,
         newScheduleView,

package/lib/view/expenseAutomationView/types/jeSchedulesViewState.d.ts

@@ -19,6 +19,7 @@ export type JESchedulePeriodTabKey = `${JEPageTab}_${MonthYearPeriodId}`;
 export declare const getJESchedulePeriodTabKey: (selectedPageTab: JEPageTab, monthYearPeriodId: MonthYearPeriodId) => JESchedulePeriodTabKey;
 export interface JESchedulesViewUIState {
     createdGroupCollapsed: boolean;
+    failedGroupCollapsed: boolean;
     pendingGroupCollapsed: boolean;
     scrollPosition: {
         scrollTop: number;
@@ -41,8 +42,23 @@ export interface JEScheduleLocalData {
     updatedClassId?: ID;
     updatedVendor?: VendorBase;
 }
+/**
+ * The Failed Postings bucket, and the only list on this page that is not scoped to a period.
+ *
+ * A failed posting is broken until someone resolves it, whatever month it belongs to, so windowing
+ * it the way the schedule lists are windowed is what hid a March failure from the September close.
+ * It therefore has no period-tab key, and its own fetch state rather than the slice's: the list is
+ * fetched separately from `/1.0/expenses_automation/failed_je_postings`, so a slow or failing
+ * lookup here must not blank the schedules table, or vice versa.
+ */
+export interface FailedJePostingsState {
+    fetchState: FetchStateAndError;
+    jeScheduleTransactionKeys: JEScheduleTransactionKey[];
+    scheduledJournalEntryIDs: ID[];
+}
 export interface JESchedulesViewState extends FetchedState {
     accountSettings: AccountSettingsState;
+    failedJePostings: FailedJePostingsState;
     failedJeScheduleTransactionKeysByPeriodAndTab: Record<JESchedulePeriodTabKey, JEScheduleTransactionKey[]>;
     ignoreStatusById: Record<JEScheduleTransactionKey, FetchStateAndError>;
     jeScheduleAccruedKeysByPeriodAndTab: Record<JESchedulePeriodTabKey, JEScheduleKey[]>;

package/lib/view/spendManagement/billPay/billDetailView/billDetailViewPayload.d.ts

@@ -1,3 +1,5 @@
+import { RecommendationPayload } from '../../../../commonPayloadTypes/recommendationPayload';
+import { ID } from '../../../../commonStateTypes/common';
 import { AccountPayload } from '../../../../entity/account/accountPayload';
 import { ApprovalRulePayload } from '../../../../entity/approvalRule/approvalRulePayload';
 import { BankAccountPayload } from '../../../../entity/bankAccount/bankAccountPayload';
@@ -28,6 +30,22 @@ export interface BillDetailViewPayload extends ApproveOrRejectBillPayload {
     transaction: BillTransactionPayload;
     vendors: VendorPayload[];
 }
+/**
+ * Wire shape of the dedicated recommendations endpoint
+ * `GET /1.0/bills/transactions/{transaction_id}/recommendations`.
+ *
+ * `recommendations` is flat here, not nested under `transaction` the way the
+ * bill detail response carries it, and is per line — positionally aligned with
+ * `transaction.lines` from the bill detail response. The element is the same
+ * shape the bill detail response nests under `transaction.recommendations`.
+ *
+ * Both fields are optional: a bill with nothing to recommend is a success, not
+ * an error.
+ */
+export interface BillRecommendationsPayload {
+    recommendations?: RecommendationPayload[];
+    transaction_id?: ID;
+}
 export interface EligibleActionsPayload {
     is_refund_eligible: boolean | null;
     is_retry_eligible: {
@@ -41,6 +59,7 @@ export interface BillDetailQuery {
     transaction_type: string;
 }
 export type BillDetailViewResponse = ZeniAPIResponse<BillDetailViewPayload>;
+export type BillRecommendationsResponse = ZeniAPIResponse<BillRecommendationsPayload>;
 export type EligibleActionsResponse = ZeniAPIResponse<EligibleActionsPayload>;
 export type ApproveOrRejectBillResponse = ZeniAPIResponse<ApproveOrRejectBillPayload>;
 export interface PreviousBillsPayload {

package/lib/view/spendManagement/billPay/billDetailView/billDetailViewReducer.d.ts

@@ -8,7 +8,16 @@ export declare const fetchBillDetail: import("@reduxjs/toolkit").ActionCreatorWi
     isShowDeletedBillsEnabled: boolean;
     hasZeniAssistAccess: boolean;
     cacheOverride: any;
-}, "billDetailView/fetchBillDetail", never, never>, updateBillDetail: import("@reduxjs/toolkit").ActionCreatorWithPayload<{
+}, "billDetailView/fetchBillDetail", never, never>, fetchBillRecommendations: import("@reduxjs/toolkit").ActionCreatorWithPreparedPayload<[billId: string, cacheOverride?: any], {
+    billId: string;
+    cacheOverride: any;
+}, "billDetailView/fetchBillRecommendations", never, never>, fetchBillRecommendationsSuccess: import("@reduxjs/toolkit").ActionCreatorWithPreparedPayload<[billId: string, didWriteRecommendations?: any], {
+    billId: string;
+    didWriteRecommendations: any;
+}, "billDetailView/fetchBillRecommendationsSuccess", never, never>, fetchBillRecommendationsFailure: import("@reduxjs/toolkit").ActionCreatorWithPreparedPayload<[billId: string, error: ZeniAPIStatus<Record<string, unknown>>], {
+    billId: string;
+    error: ZeniAPIStatus<Record<string, unknown>>;
+}, "billDetailView/fetchBillRecommendationsFailure", never, never>, updateBillDetail: import("@reduxjs/toolkit").ActionCreatorWithPayload<{
     billDetail: BillDetailViewPayload;
     billId: ID;
 }, "billDetailView/updateBillDetail">, updateBillDetailFetchState: import("@reduxjs/toolkit").ActionCreatorWithPreparedPayload<[billId: string, fetchState: FetchState, error?: ZeniAPIStatus<Record<string, unknown>> | undefined, vendorId?: string | undefined], {

package/lib/view/spendManagement/billPay/billDetailView/billDetailViewReducer.js

@@ -4,7 +4,7 @@ var __importDefault = (this && this.__importDefault) || function (mod) {
 };
 var _a;
 Object.defineProperty(exports, "__esModule", { value: true });
-exports.retryOrRefundBillFailure = exports.retryOrRefundBillSuccess = exports.retryOrRefundBill = exports.updateFetchEligibleActionsFailureState = exports.updateEligibleActionsForBill = exports.fetchEligibleActionsForBill = exports.waitForVendorByNameThenUpdateBillDetail = exports.cancelAndDeleteBillSuccessOrFailure = exports.cancelAndDeleteBill = exports.updateApprovalStatusOnSuccess = exports.approveOrRejectBillFailure = exports.approveOrRejectBillSuccess = exports.approveOrRejectBill = exports.deleteBillSuccessOrFailure = exports.deleteBill = exports.removeBillDetail = exports.updateBillDetailFetchState = exports.updateBillDetail = exports.fetchBillDetail = exports.initialState = void 0;
+exports.retryOrRefundBillFailure = exports.retryOrRefundBillSuccess = exports.retryOrRefundBill = exports.updateFetchEligibleActionsFailureState = exports.updateEligibleActionsForBill = exports.fetchEligibleActionsForBill = exports.waitForVendorByNameThenUpdateBillDetail = exports.cancelAndDeleteBillSuccessOrFailure = exports.cancelAndDeleteBill = exports.updateApprovalStatusOnSuccess = exports.approveOrRejectBillFailure = exports.approveOrRejectBillSuccess = exports.approveOrRejectBill = exports.deleteBillSuccessOrFailure = exports.deleteBill = exports.removeBillDetail = exports.updateBillDetailFetchState = exports.updateBillDetail = exports.fetchBillRecommendationsFailure = exports.fetchBillRecommendationsSuccess = exports.fetchBillRecommendations = exports.fetchBillDetail = exports.initialState = void 0;
 const toolkit_1 = require("@reduxjs/toolkit");
 const get_1 = __importDefault(require("lodash/get"));
 const rootActions_1 = require("../../../../rootActions");
@@ -25,6 +25,12 @@ const billDetailView = (0, toolkit_1.createSlice)({
                     detail.fetchState !== 'In-Progress') {
                     draft.billDetailById[key] = {
                         ...billDetailViewState_1.initialBillDetailView,
+                        // Deliberately independent of the detail fetch: recommendations
+                        // are requested separately and must not be reset by a detail
+                        // refresh, which on the edit route lands right after the
+                        // recommendations request has already started.
+                        recommendationsFetchStatus: detail?.recommendationsFetchStatus ??
+                            billDetailViewState_1.initialBillDetailView.recommendationsFetchStatus,
                     };
                 }
             },
@@ -76,6 +82,86 @@ const billDetailView = (0, toolkit_1.createSlice)({
                 };
             },
         },
+        fetchBillRecommendations: {
+            reducer(draft, action) {
+                const key = (0, billDetailViewState_1.getBillTransactionDetailKey)(action.payload.billId);
+                // The edit route can mount before the bill detail entry exists — its
+                // screen dispatches this before the parent requests the detail. Seed
+                // the entry rather than bailing, or the status would sit at
+                // `Not-Started` for the whole wait and round trip.
+                const detail = (0, get_1.default)(draft.billDetailById, key, undefined) ?? {
+                    ...billDetailViewState_1.initialBillDetailView,
+                    billId: action.payload.billId,
+                };
+                const { fetchState } = detail.recommendationsFetchStatus;
+                // Both screens dispatch once per bill — on mount, keyed by bill id,
+                // not on every render — so this guard is not what prevents a render
+                // loop; the epic's per-bill `exhaustMap` is what collapses the two
+                // sites' dispatches into one request.
+                //
+                // `Error` is deliberately allowed through: a bill whose fetch failed
+                // must be able to try again when the screen is next opened.
+                if (action.payload.cacheOverride === true ||
+                    (fetchState !== 'In-Progress' && fetchState !== 'Completed')) {
+                    draft.billDetailById[key] = {
+                        ...detail,
+                        recommendationsFetchStatus: {
+                            fetchState: 'In-Progress',
+                            error: undefined,
+                        },
+                    };
+                }
+            },
+            prepare(billId, cacheOverride = false) {
+                return {
+                    payload: { billId, cacheOverride },
+                };
+            },
+        },
+        fetchBillRecommendationsSuccess: {
+            reducer(draft, action) {
+                const key = (0, billDetailViewState_1.getBillTransactionDetailKey)(action.payload.billId);
+                const detail = (0, get_1.default)(draft.billDetailById, key, undefined);
+                if (detail != null) {
+                    draft.billDetailById[key] = {
+                        ...detail,
+                        recommendationsFetchStatus: {
+                            fetchState: 'Completed',
+                            error: undefined,
+                        },
+                    };
+                }
+            },
+            // `didWriteRecommendations` is false on the skip paths, which resolve
+            // the status without fetching anything. Consumers that react by
+            // recomputing local state must not run then — there is nothing new to
+            // apply, and recomputing would reset the line's "update to" selections.
+            prepare(billId, didWriteRecommendations = false) {
+                return {
+                    payload: { billId, didWriteRecommendations },
+                };
+            },
+        },
+        fetchBillRecommendationsFailure: {
+            reducer(draft, action) {
+                const key = (0, billDetailViewState_1.getBillTransactionDetailKey)(action.payload.billId);
+                const detail = (0, get_1.default)(draft.billDetailById, key, undefined);
+                if (detail != null) {
+                    draft.billDetailById[key] = {
+                        ...detail,
+                        recommendationsFetchStatus: {
+                            fetchState: 'Error',
+                            error: action.payload.error,
+                        },
+                    };
+                }
+            },
+            prepare(billId, error) {
+                return {
+                    payload: { billId, error },
+                };
+            },
+        },
         deleteBill: {
             reducer(draft, action) {
                 const key = (0, billDetailViewState_1.getBillTransactionDetailKey)(action.payload.billId);
@@ -469,5 +555,5 @@ const billDetailView = (0, toolkit_1.createSlice)({
         });
     },
 });
-_a = billDetailView.actions, exports.fetchBillDetail = _a.fetchBillDetail, exports.updateBillDetail = _a.updateBillDetail, exports.updateBillDetailFetchState = _a.updateBillDetailFetchState, exports.removeBillDetail = _a.removeBillDetail, exports.deleteBill = _a.deleteBill, exports.deleteBillSuccessOrFailure = _a.deleteBillSuccessOrFailure, exports.approveOrRejectBill = _a.approveOrRejectBill, exports.approveOrRejectBillSuccess = _a.approveOrRejectBillSuccess, exports.approveOrRejectBillFailure = _a.approveOrRejectBillFailure, exports.updateApprovalStatusOnSuccess = _a.updateApprovalStatusOnSuccess, exports.cancelAndDeleteBill = _a.cancelAndDeleteBill, exports.cancelAndDeleteBillSuccessOrFailure = _a.cancelAndDeleteBillSuccessOrFailure, exports.waitForVendorByNameThenUpdateBillDetail = _a.waitForVendorByNameThenUpdateBillDetail, exports.fetchEligibleActionsForBill = _a.fetchEligibleActionsForBill, exports.updateEligibleActionsForBill = _a.updateEligibleActionsForBill, exports.updateFetchEligibleActionsFailureState = _a.updateFetchEligibleActionsFailureState, exports.retryOrRefundBill = _a.retryOrRefundBill, exports.retryOrRefundBillSuccess = _a.retryOrRefundBillSuccess, exports.retryOrRefundBillFailure = _a.retryOrRefundBillFailure;
+_a = billDetailView.actions, exports.fetchBillDetail = _a.fetchBillDetail, exports.fetchBillRecommendations = _a.fetchBillRecommendations, exports.fetchBillRecommendationsSuccess = _a.fetchBillRecommendationsSuccess, exports.fetchBillRecommendationsFailure = _a.fetchBillRecommendationsFailure, exports.updateBillDetail = _a.updateBillDetail, exports.updateBillDetailFetchState = _a.updateBillDetailFetchState, exports.removeBillDetail = _a.removeBillDetail, exports.deleteBill = _a.deleteBill, exports.deleteBillSuccessOrFailure = _a.deleteBillSuccessOrFailure, exports.approveOrRejectBill = _a.approveOrRejectBill, exports.approveOrRejectBillSuccess = _a.approveOrRejectBillSuccess, exports.approveOrRejectBillFailure = _a.approveOrRejectBillFailure, exports.updateApprovalStatusOnSuccess = _a.updateApprovalStatusOnSuccess, exports.cancelAndDeleteBill = _a.cancelAndDeleteBill, exports.cancelAndDeleteBillSuccessOrFailure = _a.cancelAndDeleteBillSuccessOrFailure, exports.waitForVendorByNameThenUpdateBillDetail = _a.waitForVendorByNameThenUpdateBillDetail, exports.fetchEligibleActionsForBill = _a.fetchEligibleActionsForBill, exports.updateEligibleActionsForBill = _a.updateEligibleActionsForBill, exports.updateFetchEligibleActionsFailureState = _a.updateFetchEligibleActionsFailureState, exports.retryOrRefundBill = _a.retryOrRefundBill, exports.retryOrRefundBillSuccess = _a.retryOrRefundBillSuccess, exports.retryOrRefundBillFailure = _a.retryOrRefundBillFailure;
 exports.default = billDetailView.reducer;

package/lib/view/spendManagement/billPay/billDetailView/billDetailViewSelector.d.ts

@@ -42,6 +42,7 @@ export interface BillDetailViewSelector extends SelectorView {
     outsideZeniPaymentInfo?: OutsideZeniPaymentLocalData;
     paymentInstrument?: PaymentInstrument;
     paymentMethodType?: BillPayConfig;
+    recommendationsFetchStatus?: FetchStateAndError;
     recurringBillConfigDetail?: RecurringBillConfig;
     recurringBillInstances?: RecurringBillData[];
     transactionDetails?: BillTransaction;

package/lib/view/spendManagement/billPay/billDetailView/billDetailViewSelector.js

@@ -226,6 +226,7 @@ const getBillDetailView = (state, billId) => {
         fetchState: fetchState.fetchState,
         error: fetchState.error,
         version: 0,
+        recommendationsFetchStatus: billTransactionDetails?.recommendationsFetchStatus,
         transactionDetails: transaction,
         createdBy,
         bankAccount,

package/lib/view/spendManagement/billPay/billDetailView/billDetailViewState.d.ts

@@ -11,6 +11,13 @@ export interface BillDetailView extends FetchedState {
     deleteStatus: FetchStateAndError;
     entityApprovalIds: ID[];
     eventIds: ID[];
+    /**
+     * Status of the standalone recommendations fetch for this bill.
+     * Deliberately NOT folded into `fetchState` (or any `reduceFetchState` list)
+     * so a slow or failing recommendations call can never hold back — or error
+     * out — the bill detail / bill edit screens.
+     */
+    recommendationsFetchStatus: FetchStateAndError;
     zeniAssist: ZeniAssistForBills;
     billId?: ID;
     vendorId?: ID;

package/lib/view/spendManagement/billPay/billDetailView/billDetailViewState.js

@@ -34,6 +34,10 @@ exports.initialBillDetailView = {
         fetchState: 'Not-Started',
         error: undefined,
     },
+    recommendationsFetchStatus: {
+        fetchState: 'Not-Started',
+        error: undefined,
+    },
     billId: undefined,
     eventIds: [],
     entityApprovalIds: [],

package/lib/view/spendManagement/billPay/billDetailView/epics/fetchBillRecommendationsEpic.d.ts

@@ -0,0 +1,37 @@
+import { ActionsObservable, StateObservable } from 'redux-observable';
+import { Observable } from 'rxjs';
+import { updateBillTransactionRecommendations } from '../../../../../entity/billPay/billTransaction/billTransactionReducer';
+import { RootState } from '../../../../../reducer';
+import { ZeniAPI } from '../../../../../zeniAPI';
+import { fetchBillRecommendations, fetchBillRecommendationsFailure, fetchBillRecommendationsSuccess, updateBillDetail, updateBillDetailFetchState } from '../billDetailViewReducer';
+export type ActionType = ReturnType<typeof fetchBillRecommendations> | ReturnType<typeof fetchBillRecommendationsSuccess> | ReturnType<typeof fetchBillRecommendationsFailure> | ReturnType<typeof updateBillDetail> | ReturnType<typeof updateBillDetailFetchState> | ReturnType<typeof updateBillTransactionRecommendations>;
+/**
+ * Standalone recommendations fetch for a bill, so neither the bill detail nor
+ * the bill edit screen waits on recommendation composition.
+ *
+ * Which bills need it is decided from the bill's stage: an approval-stage bill
+ * gets them from the dedicated endpoint
+ * (`GET /1.0/bills/transactions/{transaction_id}/recommendations`), while a
+ * draft gets them on the bill detail response itself. The platform makes that
+ * split from the bill's status, so neither request carries a flag asking for
+ * one behaviour or the other.
+ *
+ * Only `recommendations` is read — per line, and what drives the "Update to X"
+ * checkbox and the Recommended group in the category/class dropdowns. The
+ * endpoint returns no entity-level recommendation and the edit form does not
+ * render one.
+ *
+ * Failure is confined to `recommendationsFetchStatus` — no bill-detail action
+ * is emitted, so a failed or slow recommendations fetch can neither block nor
+ * error out either screen.
+ *
+ * @precondition Every site dispatching `fetchBillRecommendations` must also
+ * cause the bill detail to be requested for that bill. This epic waits for the
+ * detail when it is not already in the store, and that wait settles only on a
+ * detail write or a detail error. A caller that dispatches without one would
+ * leave the wait open, and the per-bill `exhaustMap` would then drop later
+ * retries for that bill. Both current callers satisfy this: the bill detail
+ * route dispatches `fetchBillDetail` alongside, and the edit route reaches it
+ * through `fetchEditBillDetailPage`.
+ */
+export declare const fetchBillRecommendationsEpic: (actions$: ActionsObservable<ActionType>, state$: StateObservable<RootState>, zeniAPI: ZeniAPI) => Observable<ActionType>;

package/lib/view/spendManagement/billPay/billDetailView/epics/fetchBillRecommendationsEpic.js

@@ -0,0 +1,104 @@
+"use strict";
+var __importDefault = (this && this.__importDefault) || function (mod) {
+    return (mod && mod.__esModule) ? mod : { "default": mod };
+};
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.fetchBillRecommendationsEpic = void 0;
+const get_1 = __importDefault(require("lodash/get"));
+const rxjs_1 = require("rxjs");
+const operators_1 = require("rxjs/operators");
+const responsePayload_1 = require("../../../../../responsePayload");
+const billDetailViewReducer_1 = require("../billDetailViewReducer");
+const billDetailViewState_1 = require("../billDetailViewState");
+const fetchRecommendationsForBill_1 = require("./fetchRecommendationsForBill");
+/**
+ * Standalone recommendations fetch for a bill, so neither the bill detail nor
+ * the bill edit screen waits on recommendation composition.
+ *
+ * Which bills need it is decided from the bill's stage: an approval-stage bill
+ * gets them from the dedicated endpoint
+ * (`GET /1.0/bills/transactions/{transaction_id}/recommendations`), while a
+ * draft gets them on the bill detail response itself. The platform makes that
+ * split from the bill's status, so neither request carries a flag asking for
+ * one behaviour or the other.
+ *
+ * Only `recommendations` is read — per line, and what drives the "Update to X"
+ * checkbox and the Recommended group in the category/class dropdowns. The
+ * endpoint returns no entity-level recommendation and the edit form does not
+ * render one.
+ *
+ * Failure is confined to `recommendationsFetchStatus` — no bill-detail action
+ * is emitted, so a failed or slow recommendations fetch can neither block nor
+ * error out either screen.
+ *
+ * @precondition Every site dispatching `fetchBillRecommendations` must also
+ * cause the bill detail to be requested for that bill. This epic waits for the
+ * detail when it is not already in the store, and that wait settles only on a
+ * detail write or a detail error. A caller that dispatches without one would
+ * leave the wait open, and the per-bill `exhaustMap` would then drop later
+ * retries for that bill. Both current callers satisfy this: the bill detail
+ * route dispatches `fetchBillDetail` alongside, and the edit route reaches it
+ * through `fetchEditBillDetailPage`.
+ */
+const fetchBillRecommendationsEpic = (actions$, state$, zeniAPI) => actions$.pipe((0, operators_1.filter)(billDetailViewReducer_1.fetchBillRecommendations.match), 
+// The bill detail route requests these and the edit screen asks again on
+// every mount, so repeats are normal. Drop the ones whose bill is already
+// done before they reach the request.
+(0, operators_1.filter)((action) => action.payload.cacheOverride === true ||
+    areRecommendationsAlreadyFetched(state$.value, action.payload.billId) === false), 
+// Per bill, then `exhaustMap` rather than `switchMap`: a repeat that
+// arrives while the request (or the wait for the bill detail) is still
+// running is ignored, where `switchMap` would cancel the in-flight one and
+// re-issue it. `groupBy` keeps that per bill, so navigating to another
+// bill mid-flight still fetches for the new one.
+(0, operators_1.groupBy)((action) => action.payload.billId), (0, operators_1.mergeMap)((actionsForBill$) => actionsForBill$.pipe((0, operators_1.exhaustMap)((action) => {
+    const { billId, cacheOverride } = action.payload;
+    if (isBillReadyForRecommendations(state$.value, billId)) {
+        return (0, fetchRecommendationsForBill_1.fetchRecommendationsForBill)(state$.value, billId, zeniAPI, cacheOverride);
+    }
+    // The edit route can mount before the bill detail response lands,
+    // and the request needs the vendor / line ids / amount from it. Wait
+    // for the detail write for this bill rather than dropping the fetch,
+    // and settle on a detail error too.
+    //
+    // A leftover `Error` on the bill detail is deliberately NOT treated
+    // as terminal here. On the edit route this action is dispatched
+    // before the parent screen re-requests the detail — React runs the
+    // child's effect first — so failing on the stale error would leave
+    // recommendations failed even though the detail is about to succeed.
+    //
+    // The invariant this relies on: every dispatch site also causes the
+    // bill detail to be requested. Both do today. A future site that
+    // does not would leave this waiting, and `exhaustMap` would drop
+    // later retries for that bill.
+    const billDetailSettled$ = actions$.pipe((0, operators_1.filter)((waited) => {
+        if (billDetailViewReducer_1.updateBillDetail.match(waited)) {
+            return waited.payload.billId === billId;
+        }
+        return (billDetailViewReducer_1.updateBillDetailFetchState.match(waited) &&
+            waited.payload.fetchState === 'Error' &&
+            waited.payload.billId === billId);
+    }), (0, operators_1.take)(1) // don't listen forever! IMPORTANT!
+    );
+    return billDetailSettled$.pipe((0, operators_1.mergeMap)((waited) => {
+        if (billDetailViewReducer_1.updateBillDetail.match(waited)) {
+            return (0, fetchRecommendationsForBill_1.fetchRecommendationsForBill)(state$.value, billId, zeniAPI, cacheOverride);
+        }
+        // Bill detail failed; there is nothing to recommend against.
+        return (0, rxjs_1.of)((0, billDetailViewReducer_1.fetchBillRecommendationsFailure)(billId, waited.payload.error ??
+            (0, responsePayload_1.createZeniAPIStatus)('Unexpected Error', 'Bill detail fetch failed before recommendations could be requested')));
+    }));
+}))));
+exports.fetchBillRecommendationsEpic = fetchBillRecommendationsEpic;
+/**
+ * Helper functions
+ */
+function areRecommendationsAlreadyFetched(state, billId) {
+    const billDetail = (0, get_1.default)(state.billDetailViewState.billDetailById, (0, billDetailViewState_1.getBillTransactionDetailKey)(billId), undefined);
+    return billDetail?.recommendationsFetchStatus.fetchState === 'Completed';
+}
+function isBillReadyForRecommendations(state, billId) {
+    const billDetail = (0, get_1.default)(state.billDetailViewState.billDetailById, (0, billDetailViewState_1.getBillTransactionDetailKey)(billId), undefined);
+    return (billDetail?.fetchState === 'Completed' &&
+        (0, fetchRecommendationsForBill_1.getBillTransaction)(state, billId) != null);
+}

package/lib/view/spendManagement/billPay/billDetailView/epics/fetchRecommendationsForBill.d.ts

@@ -0,0 +1,24 @@
+import { Observable } from 'rxjs';
+import { ID } from '../../../../../commonStateTypes/common';
+import { updateBillTransactionRecommendations } from '../../../../../entity/billPay/billTransaction/billTransactionReducer';
+import { BillTransaction } from '../../../../../entity/billPay/billTransaction/billTransactionState';
+import { RootState } from '../../../../../reducer';
+import { ZeniAPI } from '../../../../../zeniAPI';
+import { fetchBillRecommendationsFailure, fetchBillRecommendationsSuccess } from '../billDetailViewReducer';
+/**
+ * What the request itself can emit. `fetchBillRecommendationsEpic` widens this
+ * with the actions it consumes; keeping the narrower union here is what lets
+ * this module stay free of any import from the epic.
+ */
+export type FetchRecommendationsForBillActionType = ReturnType<typeof fetchBillRecommendationsSuccess> | ReturnType<typeof fetchBillRecommendationsFailure> | ReturnType<typeof updateBillTransactionRecommendations>;
+/**
+ * Requests the recommendations for one bill and maps them onto the transaction
+ * entity, or resolves without a request for a bill that does not need them.
+ *
+ * Only `recommendations` is read from the response — per line, and what drives
+ * the "Update to X" checkbox and the Recommended group in the category/class
+ * dropdowns. The endpoint returns no entity-level recommendation and the edit
+ * form does not render one.
+ */
+export declare function fetchRecommendationsForBill(state: RootState, billId: ID, zeniAPI: ZeniAPI, cacheOverride?: boolean): Observable<FetchRecommendationsForBillActionType>;
+export declare function getBillTransaction(state: RootState, billId: ID): BillTransaction | undefined;

package/lib/view/spendManagement/billPay/billDetailView/epics/fetchRecommendationsForBill.js

@@ -0,0 +1,92 @@
+"use strict";
+var __importDefault = (this && this.__importDefault) || function (mod) {
+    return (mod && mod.__esModule) ? mod : { "default": mod };
+};
+Object.defineProperty(exports, "__esModule", { value: true });
+exports.fetchRecommendationsForBill = fetchRecommendationsForBill;
+exports.getBillTransaction = getBillTransaction;
+const get_1 = __importDefault(require("lodash/get"));
+const rxjs_1 = require("rxjs");
+const operators_1 = require("rxjs/operators");
+const recommendationPayload_1 = require("../../../../../commonPayloadTypes/recommendationPayload");
+const billTransactionReducer_1 = require("../../../../../entity/billPay/billTransaction/billTransactionReducer");
+const responsePayload_1 = require("../../../../../responsePayload");
+const billDetailViewReducer_1 = require("../billDetailViewReducer");
+/**
+ * Requests the recommendations for one bill and maps them onto the transaction
+ * entity, or resolves without a request for a bill that does not need them.
+ *
+ * Only `recommendations` is read from the response — per line, and what drives
+ * the "Update to X" checkbox and the Recommended group in the category/class
+ * dropdowns. The endpoint returns no entity-level recommendation and the edit
+ * form does not render one.
+ */
+function fetchRecommendationsForBill(state, billId, zeniAPI, cacheOverride = false) {
+    const transaction = getBillTransaction(state, billId);
+    const lineIds = transaction?.lines?.map((line) => line.id) ?? [];
+    if (transaction == null ||
+        shouldSkipRecommendations(transaction, cacheOverride)) {
+        return (0, rxjs_1.of)((0, billDetailViewReducer_1.fetchBillRecommendationsSuccess)(billId));
+    }
+    // The bill is scoped by the path, so this endpoint takes no query — there is
+    // no `is_include_*` flag to turn off the way the bill detail request has.
+    return zeniAPI
+        .getJSON(`${zeniAPI.apiEndPoints.spendManagementMicroServiceBaseUrl}/1.0/bills/transactions/${billId}/recommendations`)
+        .pipe((0, operators_1.mergeMap)((response) => {
+        if (!(0, responsePayload_1.isSuccessResponse)(response) || response.data == null) {
+            return (0, rxjs_1.of)((0, billDetailViewReducer_1.fetchBillRecommendationsFailure)(billId, response.status));
+        }
+        const actions = [];
+        // Positional line <-> recommendation mapping, matching
+        // `getRecommendationsPerLine` — the mapping the recommendations went
+        // through while the bill detail response still carried them. This
+        // endpoint returns them flat, not nested under `transaction`.
+        const recommendationPayloads = response.data.recommendations ?? [];
+        // The pairing is a convention shared with the platform, not
+        // something the payload enforces, so a mismatch would otherwise
+        // mis-assign or silently drop recommendations. Degrade safely —
+        // extra entries are ignored and unmatched lines get none — but say
+        // so, because it means the two sides have diverged.
+        if (recommendationPayloads.length !== lineIds.length) {
+            console.warn(`Bill ${billId}: ${recommendationPayloads.length} recommendation entries for ${lineIds.length} lines. ` +
+                'They are paired by position, so this bill may be scored incorrectly.');
+        }
+        const recommendationByLineId = {};
+        lineIds.forEach((lineId, index) => {
+            const recommendationPayload = recommendationPayloads[index];
+            if (recommendationPayload != null) {
+                recommendationByLineId[lineId] = (0, recommendationPayload_1.transformRecommendation)(recommendationPayload);
+            }
+        });
+        actions.push((0, billTransactionReducer_1.updateBillTransactionRecommendations)(billId, recommendationByLineId));
+        // Entity writes first, then the view status, so consumers reading on
+        // the status flip already see the recommendations.
+        actions.push((0, billDetailViewReducer_1.fetchBillRecommendationsSuccess)(billId, true));
+        return (0, rxjs_1.from)(actions);
+    }), (0, operators_1.catchError)((error) => (0, rxjs_1.of)((0, billDetailViewReducer_1.fetchBillRecommendationsFailure)(billId, (0, responsePayload_1.createZeniAPIStatus)('Unexpected Error', `Fetch bill recommendations REST API call errored out ${error}`)))));
+}
+function getBillTransaction(state, billId) {
+    return (0, get_1.default)(state.billTransactionState.transactionById, billId, undefined);
+}
+/**
+ * Helper functions
+ */
+// Awaiting-approval bills are the only ones this request exists for. A draft
+// opens the edit form directly, so its recommendations ride along on the bill
+// detail response; `paid` bills cannot reach the form at all. The platform
+// decides which of those two it is from the bill's status, which is why the
+// request carries no flag asking for either.
+function shouldSkipRecommendations(transaction, cacheOverride) {
+    return (transaction.billPayInfo.stage.code !== 'pending_approval' ||
+        transaction.isDeleted === true ||
+        // No vendor (a draft carrying only a candidate vendor name) means no
+        // entity to recommend against — the vendor-selection flow covers that.
+        Boolean(transaction.vendor?.id) === false ||
+        // The bill detail response already carried them. `toVendorTransaction`
+        // maps them straight onto the entity, so requesting again would only
+        // re-fetch what is here — this is what lets the platform move the line
+        // between embedded and on-demand without a client change. A forced
+        // refresh is the one case that still goes to the endpoint.
+        (cacheOverride === false &&
+            Object.keys(transaction.recommendations ?? {}).length > 0));
+}