@zeniai/client-epic-state 5.0.90-betaAR2 → 5.0.90-betaAR4

package/lib/esm/view/spendManagement/billPay/billPayReview/billPayReviewSelector.js

@@ -52,6 +52,12 @@ export const getReviewPageBillDetail = (state, billId) => {
     let recurringConfig;
     let billPayInfo;
     let isBillMarkedForRetry = false;
+    // Bill-level accounting class id. Approval Rules 3.0 'department'
+    // criteria match against this. Sourced from BillTransaction so
+    // any selector that needs it (e.g. creator-as-approver lookup)
+    // can read it off the view rather than reaching into
+    // 'state.billTransactionState' itself.
+    let classId;
     const zeniAssistRetryStatus = billId != null
         ? billDetailViewState.billDetailById[key].zeniAssist.retryStatus
         : undefined;
@@ -62,6 +68,13 @@ export const getReviewPageBillDetail = (state, billId) => {
             transaction?.billPayInfo.isCollectToAccountInfoFromVendorContact ?? false;
         isRecurring = transaction?.isRecurring ?? false;
         billPayInfo = transaction?.billPayInfo;
+        // Normalise empty-string to undefined so downstream readers
+        // treat "no class" uniformly regardless of whether the wire
+        // used '' or omitted the field.
+        classId =
+            transaction?.classId != null && transaction.classId !== ''
+                ? transaction.classId
+                : undefined;
         if (isRecurring &&
             transaction?.recurringBillConfigId != null &&
             transaction.recurringBillInstance != null) {
@@ -178,5 +191,6 @@ export const getReviewPageBillDetail = (state, billId) => {
         zeniAssistRetryStatus,
         billPayInfo,
         outsideZeniPaymentInfo,
+        classId,
     };
 };

package/lib/esm/view/spendManagement/billPay/billPaySetupApproverView/billPaySetupApproverViewReducer.js

@@ -165,13 +165,23 @@ const billPaySetupApproverView = createSlice({
         reorderBillPayApprovalRules: {
             reducer(draft, action) {
                 const { approvalRuleIds } = action.payload;
+                const wasReorderInFlight = draft.reorderStatus.fetchState === 'In-Progress';
                 draft.reorderStatus = { fetchState: 'In-Progress', error: undefined };
                 // Stash the pre-reorder order so 'Failure' can restore it
                 // synchronously. The epic's refetch on failure remains as a
                 // safety net (covers cases where the server's truth has
                 // drifted from the local snapshot), but the snappy UX path
                 // is the in-memory rollback.
-                draft.reorderRollbackIds = draft.approvalRuleIds;
+                //
+                // Only capture a fresh snapshot when no reorder is already in
+                // flight. If a second drag fires before the first PUT lands,
+                // the existing snapshot already holds the last server-backed
+                // order; overwriting it with the first reorder's optimistic
+                // result would mean a Failure rolls back to an uncommitted
+                // intermediate order instead of the last good list.
+                if (!wasReorderInFlight) {
+                    draft.reorderRollbackIds = draft.approvalRuleIds;
+                }
                 // Optimistic: render new order immediately. On failure, the
                 // reducer restores 'reorderRollbackIds' and the epic refetch
                 // reconciles any drift.

package/lib/esm/view/spendManagement/billPay/billPaySetupApproverView/types/commonPayload.js

@@ -91,15 +91,20 @@ export const toApprovalChangableInfoPayload = (approverViewUpdateData) => {
     return payload;
 };
 /**
- * V1 wire mapper — used when `approval_rule_v3_config` resolves to OFF
- * for the current tenant. Translates the form-side amount criteria into
- * the legacy `{rangeType, rangeEntity, range: {min, max}}` shape. The
- * V1 backend does not understand vendor / department criteria or the
- * rule-level 3.0 fields, so those are dropped on the wire.
+ * V1 wire mapper — used when 'approval_rule_v3_config' resolves to OFF
+ * for the current tenant. Emits the legacy snake_case array shape that
+ * '/approval-rules' historically consumed (see the V1 fixture in
+ * 'entity/entityApprovalStatus/__mocks__/json/entityApprovalStatusPayload.json'):
+ *   criteria: [{type: 'range', range_entity: 'currency', min, max,
+ *               currency_code, currency_symbol}]
  *
- * The form-side amount slot is always read as a `range`-style criteria
- * here: V1 schemas only supported ranges, so an absent `min` or `max`
- * falls back to `0` / `Number.MAX_SAFE_INTEGER`.
+ * Open-ended semantics are preserved on the wire: an absent 'min' or
+ * 'max' is sent as 'null' rather than synthesised to '0' or
+ * 'MAX_SAFE_INTEGER', so a 'greater_than' / 'less_than' rule stays
+ * one-sided after rollback rather than collapsing into a closed range.
+ *
+ * The V1 backend does not understand vendor / department criteria or
+ * the rule-level 3.0 fields, so those are dropped on the wire.
  */
 export const toApprovalChangableInfoPayloadV1 = (approverViewUpdateData) => {
     const amount = approverViewUpdateData.criteria?.amount;
@@ -125,25 +130,18 @@ export const toApprovalChangableInfoPayloadV1 = (approverViewUpdateData) => {
         };
     });
     const isUpdate = approverViewUpdateData.approvalRuleId != null;
+    const criteriaEntry = {
+        type: 'range',
+        range_entity: 'currency',
+        min: minAmount?.amount ?? null,
+        max: maxAmount?.amount ?? null,
+        currency_code: currencyCode,
+        currency_symbol: currencySymbol,
+    };
     const payload = {
         steps,
         is_applicable_on_pending_approval_entity: approverViewUpdateData.isApplicableOnPendingApprovalEntity ?? true,
-        criteria: {
-            rangeType: 'range',
-            rangeEntity: 'currency',
-            range: {
-                min: {
-                    amount: minAmount?.amount ?? 0,
-                    currencyCode,
-                    currencySymbol,
-                },
-                max: {
-                    amount: maxAmount?.amount ?? Number.MAX_SAFE_INTEGER,
-                    currencyCode,
-                    currencySymbol,
-                },
-            },
-        },
+        criteria: [criteriaEntry],
     };
     if (isUpdate) {
         payload.approval_rule_id = approverViewUpdateData.approvalRuleId;

package/lib/esm/view/spendManagement/billPay/editBillView/editBillViewSelector.js

@@ -1,6 +1,6 @@
 import recordGet from 'lodash/get';
 import has from 'lodash/has';
-import { getAmountCriteria } from '../../../../entity/approvalRule/approvalRuleSelector';
+import { getAmountCriteria, getDepartmentCriteria, getVendorCriteria, } from '../../../../entity/approvalRule/approvalRuleSelector';
 import { reduceFetchState } from '../../../../commonStateTypes/reduceFetchState';
 import { getBankAccountByBankAccountId, getBankAccountsByBankAccountIds, } from '../../../../entity/bankAccount/bankAccountSelector';
 import { getContactById, getContactsByIds, } from '../../../../entity/billPay/contact/contactSelector';
@@ -357,6 +357,14 @@ export const getEditBillDetail = (state, isVendorRecommendationFeatureEnabled, i
         isDeleted,
         showAutofill,
         addBillAutoFields,
+        // Bill-level accounting class. Approval Rules 3.0 'department'
+        // criteria match against this. Lives on BillTransaction; not on
+        // any sub-section. Empty-string is normalised to 'undefined'
+        // so downstream readers treat "no class" uniformly regardless
+        // of whether the wire used '' or omitted the field.
+        classId: transaction?.classId != null && transaction.classId !== ''
+            ? transaction.classId
+            : undefined,
         billStage,
         deleteStatus,
         billActivities,
@@ -679,16 +687,59 @@ export const getDefaultWithdrawFromAccount = (state, depositAccounts, companyId,
     }
     return undefined;
 };
-export const checkIfCreatorIsApprover = (billAmount, approvalRules, signedInUser) => {
+export const checkIfCreatorIsApprover = (billAmount, approvalRules, signedInUser, billVendorId, billDepartmentId) => {
     let isCreatorAlsoApprover = false;
+    // Approval Rules 3.0 — a rule applies to a bill only when all of
+    // its present criteria are satisfied. Criteria not declared on
+    // the rule are treated as "no narrowing on this axis".
+    //
+    // Strict-match semantics for vendor / department: if the rule
+    // narrows by an axis but the bill has no value on that axis, the
+    // rule does NOT apply (an absent bill-side value can't satisfy
+    // either 'is' or 'is_not'). Amount is always present on a rule
+    // (the form enforces this), but bounds may be one-sided.
     const approvalRule = approvalRules.find((rule) => {
+        const vendorCriteria = getVendorCriteria(rule.criteria);
+        if (vendorCriteria != null) {
+            if (billVendorId == null) {
+                return false;
+            }
+            const includesVendor = vendorCriteria.vendorIds.includes(billVendorId);
+            if (vendorCriteria.operator === 'is' && !includesVendor) {
+                return false;
+            }
+            if (vendorCriteria.operator === 'is_not' && includesVendor) {
+                return false;
+            }
+        }
+        const departmentCriteria = getDepartmentCriteria(rule.criteria);
+        if (departmentCriteria != null) {
+            if (billDepartmentId == null) {
+                return false;
+            }
+            const includesDepartment = departmentCriteria.departmentIds.includes(billDepartmentId);
+            if (departmentCriteria.operator === 'is' && !includesDepartment) {
+                return false;
+            }
+            if (departmentCriteria.operator === 'is_not' && includesDepartment) {
+                return false;
+            }
+        }
         const amountCriteria = getAmountCriteria(rule.criteria);
-        if (amountCriteria?.min == null) {
+        if (amountCriteria == null) {
+            // The form guarantees an amount criterion on every rule, so
+            // this branch is defensive against backend drift. Keep
+            // pre-3.0 behaviour: a rule that doesn't declare amount
+            // doesn't participate here.
             return false;
         }
+        // Bounds use the wire's inclusive 'gte' / 'lte' semantics, and
+        // either side may be absent for a one-sided 'greater_than' /
+        // 'less_than' rule.
         const { min, max } = amountCriteria;
-        return (billAmount > min.amount &&
-            (max?.amount != null ? billAmount <= max.amount : true));
+        const matchesMin = min == null || billAmount >= min.amount;
+        const matchesMax = max == null || billAmount <= max.amount;
+        return matchesMin && matchesMax;
     });
     if (approvalRule != null) {
         const requireApprovalSteps = approvalRule.steps.filter((step) => step.action === 'require_approval');

package/lib/esm/view/spendManagement/reimbursement/remiSetupApproverView/remiSetupApproverViewReducer.js

@@ -182,10 +182,15 @@ const remiSetupApproverView = createSlice({
         reorderRemiApprovalRules: {
             reducer(draft, action) {
                 const { approvalRuleIds } = action.payload;
+                const wasReorderInFlight = draft.reorderStatus.fetchState === 'In-Progress';
                 draft.reorderStatus = { fetchState: 'In-Progress', error: undefined };
                 // Stash the pre-reorder order for synchronous rollback on
-                // 'Failure'. See the BillPay reducer for the rationale.
-                draft.reorderRollbackIds = draft.approvalRuleIds;
+                // 'Failure'. See the BillPay reducer for the rationale,
+                // including the in-flight guard: a second drag before the
+                // first PUT lands must not overwrite the snapshot.
+                if (!wasReorderInFlight) {
+                    draft.reorderRollbackIds = draft.approvalRuleIds;
+                }
                 draft.approvalRuleIds = approvalRuleIds;
             },
             prepare(approvalRuleIds, useV3 = false) {

package/lib/view/spendManagement/billPay/billPayReview/billPayReviewSelector.d.ts

@@ -24,6 +24,13 @@ export interface BillPayReviewSelectorView extends SelectorView {
     vendor: Vendor | undefined;
     zeniAssistRetryStatus: FetchStateAndError | undefined;
     billPayInfo?: BillPayInfo;
+    /**
+     * Bill-level accounting class id. Approval Rules 3.0 'department'
+     * criteria match against this — readers needing it (e.g. the
+     * creator-as-approver lookup) should read it off the view rather
+     * than digging through 'state.billTransactionState'.
+     */
+    classId?: ID;
     invoiceNumber?: string;
     isBillMarkedForRetry?: boolean;
     outsideZeniPaymentInfo?: OutsideZeniPaymentLocalData;

package/lib/view/spendManagement/billPay/billPayReview/billPayReviewSelector.js

@@ -59,6 +59,12 @@ const getReviewPageBillDetail = (state, billId) => {
     let recurringConfig;
     let billPayInfo;
     let isBillMarkedForRetry = false;
+    // Bill-level accounting class id. Approval Rules 3.0 'department'
+    // criteria match against this. Sourced from BillTransaction so
+    // any selector that needs it (e.g. creator-as-approver lookup)
+    // can read it off the view rather than reaching into
+    // 'state.billTransactionState' itself.
+    let classId;
     const zeniAssistRetryStatus = billId != null
         ? billDetailViewState.billDetailById[key].zeniAssist.retryStatus
         : undefined;
@@ -69,6 +75,13 @@ const getReviewPageBillDetail = (state, billId) => {
             transaction?.billPayInfo.isCollectToAccountInfoFromVendorContact ?? false;
         isRecurring = transaction?.isRecurring ?? false;
         billPayInfo = transaction?.billPayInfo;
+        // Normalise empty-string to undefined so downstream readers
+        // treat "no class" uniformly regardless of whether the wire
+        // used '' or omitted the field.
+        classId =
+            transaction?.classId != null && transaction.classId !== ''
+                ? transaction.classId
+                : undefined;
         if (isRecurring &&
             transaction?.recurringBillConfigId != null &&
             transaction.recurringBillInstance != null) {
@@ -185,6 +198,7 @@ const getReviewPageBillDetail = (state, billId) => {
         zeniAssistRetryStatus,
         billPayInfo,
         outsideZeniPaymentInfo,
+        classId,
     };
 };
 exports.getReviewPageBillDetail = getReviewPageBillDetail;

package/lib/view/spendManagement/billPay/billPaySetupApproverView/billPaySetupApproverViewReducer.js

@@ -169,13 +169,23 @@ const billPaySetupApproverView = (0, toolkit_1.createSlice)({
         reorderBillPayApprovalRules: {
             reducer(draft, action) {
                 const { approvalRuleIds } = action.payload;
+                const wasReorderInFlight = draft.reorderStatus.fetchState === 'In-Progress';
                 draft.reorderStatus = { fetchState: 'In-Progress', error: undefined };
                 // Stash the pre-reorder order so 'Failure' can restore it
                 // synchronously. The epic's refetch on failure remains as a
                 // safety net (covers cases where the server's truth has
                 // drifted from the local snapshot), but the snappy UX path
                 // is the in-memory rollback.
-                draft.reorderRollbackIds = draft.approvalRuleIds;
+                //
+                // Only capture a fresh snapshot when no reorder is already in
+                // flight. If a second drag fires before the first PUT lands,
+                // the existing snapshot already holds the last server-backed
+                // order; overwriting it with the first reorder's optimistic
+                // result would mean a Failure rolls back to an uncommitted
+                // intermediate order instead of the last good list.
+                if (!wasReorderInFlight) {
+                    draft.reorderRollbackIds = draft.approvalRuleIds;
+                }
                 // Optimistic: render new order immediately. On failure, the
                 // reducer restores 'reorderRollbackIds' and the epic refetch
                 // reconciles any drift.

package/lib/view/spendManagement/billPay/billPaySetupApproverView/types/commonPayload.d.ts

@@ -30,42 +30,51 @@ interface ApprovalUpdatableInfoPayload {
 }
 /**
  * V1 / pre-3.0 wire shape. Kept so the rollback flag (gated by
- * `approval_rule_v3_config` dynamic config) can target the original
- * `/approval-rules` endpoint with the legacy `{rangeType, rangeEntity, range}`
- * criteria. None of the 3.0 rule-level fields are sent.
+ * 'approval_rule_v3_config' dynamic config) can target the original
+ * '/approval-rules' endpoint with the legacy snake_case array of
+ * range entries. None of the 3.0 rule-level fields are sent.
+ *
+ * Reference: 'entityApprovalStatusPayload.json' fixture, which carries
+ * a real V1 approval rule from the legacy backend:
+ *   criteria: [{type: 'range', range_entity: 'currency',
+ *               min, max, currency_code, currency_symbol}]
+ * with 'min' / 'max' as scalar numbers and 'null' representing an
+ * absent bound for one-sided rules. The read-side mapper in
+ * 'approvalRulePayload.ts' (see 'LegacyAmountRangeCriterionPayload')
+ * decodes the same shape — write-side has to match.
  */
+interface ApprovalUpdatableInfoPayloadV1CriterionEntry {
+    currency_code: string;
+    currency_symbol: string;
+    /** Upper bound. 'null' for a 'greater_than' (open-upper) rule. */
+    max: number | null;
+    /** Lower bound. 'null' for a 'less_than' (open-lower) rule. */
+    min: number | null;
+    range_entity: 'currency';
+    type: 'range';
+}
 interface ApprovalUpdatableInfoPayloadV1 {
-    criteria: {
-        range: {
-            max: {
-                amount: number;
-                currencyCode: string;
-                currencySymbol: string;
-            };
-            min: {
-                amount: number;
-                currencyCode: string;
-                currencySymbol: string;
-            };
-        };
-        rangeEntity: 'currency';
-        rangeType: 'range';
-    };
+    criteria: ApprovalUpdatableInfoPayloadV1CriterionEntry[];
     is_applicable_on_pending_approval_entity: boolean;
     steps: ApproverViewStepPayload[];
     approval_rule_id?: ID;
 }
 export declare const toApprovalChangableInfoPayload: (approverViewUpdateData: ApprovalRuleUpdateData | ApprovalRuleCreateData) => Partial<ApprovalUpdatableInfoPayload>;
 /**
- * V1 wire mapper — used when `approval_rule_v3_config` resolves to OFF
- * for the current tenant. Translates the form-side amount criteria into
- * the legacy `{rangeType, rangeEntity, range: {min, max}}` shape. The
- * V1 backend does not understand vendor / department criteria or the
- * rule-level 3.0 fields, so those are dropped on the wire.
+ * V1 wire mapper — used when 'approval_rule_v3_config' resolves to OFF
+ * for the current tenant. Emits the legacy snake_case array shape that
+ * '/approval-rules' historically consumed (see the V1 fixture in
+ * 'entity/entityApprovalStatus/__mocks__/json/entityApprovalStatusPayload.json'):
+ *   criteria: [{type: 'range', range_entity: 'currency', min, max,
+ *               currency_code, currency_symbol}]
+ *
+ * Open-ended semantics are preserved on the wire: an absent 'min' or
+ * 'max' is sent as 'null' rather than synthesised to '0' or
+ * 'MAX_SAFE_INTEGER', so a 'greater_than' / 'less_than' rule stays
+ * one-sided after rollback rather than collapsing into a closed range.
  *
- * The form-side amount slot is always read as a `range`-style criteria
- * here: V1 schemas only supported ranges, so an absent `min` or `max`
- * falls back to `0` / `Number.MAX_SAFE_INTEGER`.
+ * The V1 backend does not understand vendor / department criteria or
+ * the rule-level 3.0 fields, so those are dropped on the wire.
  */
 export declare const toApprovalChangableInfoPayloadV1: (approverViewUpdateData: ApprovalRuleUpdateData | ApprovalRuleCreateData) => Partial<ApprovalUpdatableInfoPayloadV1>;
 export {};

package/lib/view/spendManagement/billPay/billPaySetupApproverView/types/commonPayload.js

@@ -95,15 +95,20 @@ const toApprovalChangableInfoPayload = (approverViewUpdateData) => {
 };
 exports.toApprovalChangableInfoPayload = toApprovalChangableInfoPayload;
 /**
- * V1 wire mapper — used when `approval_rule_v3_config` resolves to OFF
- * for the current tenant. Translates the form-side amount criteria into
- * the legacy `{rangeType, rangeEntity, range: {min, max}}` shape. The
- * V1 backend does not understand vendor / department criteria or the
- * rule-level 3.0 fields, so those are dropped on the wire.
+ * V1 wire mapper — used when 'approval_rule_v3_config' resolves to OFF
+ * for the current tenant. Emits the legacy snake_case array shape that
+ * '/approval-rules' historically consumed (see the V1 fixture in
+ * 'entity/entityApprovalStatus/__mocks__/json/entityApprovalStatusPayload.json'):
+ *   criteria: [{type: 'range', range_entity: 'currency', min, max,
+ *               currency_code, currency_symbol}]
  *
- * The form-side amount slot is always read as a `range`-style criteria
- * here: V1 schemas only supported ranges, so an absent `min` or `max`
- * falls back to `0` / `Number.MAX_SAFE_INTEGER`.
+ * Open-ended semantics are preserved on the wire: an absent 'min' or
+ * 'max' is sent as 'null' rather than synthesised to '0' or
+ * 'MAX_SAFE_INTEGER', so a 'greater_than' / 'less_than' rule stays
+ * one-sided after rollback rather than collapsing into a closed range.
+ *
+ * The V1 backend does not understand vendor / department criteria or
+ * the rule-level 3.0 fields, so those are dropped on the wire.
  */
 const toApprovalChangableInfoPayloadV1 = (approverViewUpdateData) => {
     const amount = approverViewUpdateData.criteria?.amount;
@@ -129,25 +134,18 @@ const toApprovalChangableInfoPayloadV1 = (approverViewUpdateData) => {
         };
     });
     const isUpdate = approverViewUpdateData.approvalRuleId != null;
+    const criteriaEntry = {
+        type: 'range',
+        range_entity: 'currency',
+        min: minAmount?.amount ?? null,
+        max: maxAmount?.amount ?? null,
+        currency_code: currencyCode,
+        currency_symbol: currencySymbol,
+    };
     const payload = {
         steps,
         is_applicable_on_pending_approval_entity: approverViewUpdateData.isApplicableOnPendingApprovalEntity ?? true,
-        criteria: {
-            rangeType: 'range',
-            rangeEntity: 'currency',
-            range: {
-                min: {
-                    amount: minAmount?.amount ?? 0,
-                    currencyCode,
-                    currencySymbol,
-                },
-                max: {
-                    amount: maxAmount?.amount ?? Number.MAX_SAFE_INTEGER,
-                    currencyCode,
-                    currencySymbol,
-                },
-            },
-        },
+        criteria: [criteriaEntry],
     };
     if (isUpdate) {
         payload.approval_rule_id = approverViewUpdateData.approvalRuleId;

package/lib/view/spendManagement/billPay/editBillView/editBillViewSelector.d.ts

@@ -100,6 +100,13 @@ export interface EditBillDetailSelectorView extends SelectorView {
     withdrawFromList: FundingAccount[];
     billPayInfo?: BillPayInfo;
     bookCloseDate?: ZeniDate;
+    /**
+     * Bill-level accounting class id. Approval Rules 3.0 'department'
+     * criteria match against this — selectors needing to evaluate a
+     * department-narrowed rule against the current bill should read
+     * this rather than digging through 'state.billTransactionState'.
+     */
+    classId?: ID;
     createTime?: ZeniDate;
     editBillInitialDetails?: EditBillInitialDetails;
     internationalWireOnboardingStatus?: AllowedValueWithCode;
@@ -157,4 +164,4 @@ export declare const getDefaultWithdrawFromAccount: (state: RootState, depositAc
     accountId: ID;
     accountType: AccountTypeSubConfigCodeKeyType;
 }) => FundingAccount | undefined;
-export declare const checkIfCreatorIsApprover: (billAmount: number, approvalRules: ApprovalRuleWithUser[], signedInUser?: LoggedInUser) => boolean;
+export declare const checkIfCreatorIsApprover: (billAmount: number, approvalRules: ApprovalRuleWithUser[], signedInUser?: LoggedInUser, billVendorId?: ID, billDepartmentId?: ID) => boolean;

package/lib/view/spendManagement/billPay/editBillView/editBillViewSelector.js

@@ -366,6 +366,14 @@ const getEditBillDetail = (state, isVendorRecommendationFeatureEnabled, isZeniAc
         isDeleted,
         showAutofill,
         addBillAutoFields,
+        // Bill-level accounting class. Approval Rules 3.0 'department'
+        // criteria match against this. Lives on BillTransaction; not on
+        // any sub-section. Empty-string is normalised to 'undefined'
+        // so downstream readers treat "no class" uniformly regardless
+        // of whether the wire used '' or omitted the field.
+        classId: transaction?.classId != null && transaction.classId !== ''
+            ? transaction.classId
+            : undefined,
         billStage,
         deleteStatus,
         billActivities,
@@ -696,16 +704,59 @@ const getDefaultWithdrawFromAccount = (state, depositAccounts, companyId, lastSe
     return undefined;
 };
 exports.getDefaultWithdrawFromAccount = getDefaultWithdrawFromAccount;
-const checkIfCreatorIsApprover = (billAmount, approvalRules, signedInUser) => {
+const checkIfCreatorIsApprover = (billAmount, approvalRules, signedInUser, billVendorId, billDepartmentId) => {
     let isCreatorAlsoApprover = false;
+    // Approval Rules 3.0 — a rule applies to a bill only when all of
+    // its present criteria are satisfied. Criteria not declared on
+    // the rule are treated as "no narrowing on this axis".
+    //
+    // Strict-match semantics for vendor / department: if the rule
+    // narrows by an axis but the bill has no value on that axis, the
+    // rule does NOT apply (an absent bill-side value can't satisfy
+    // either 'is' or 'is_not'). Amount is always present on a rule
+    // (the form enforces this), but bounds may be one-sided.
     const approvalRule = approvalRules.find((rule) => {
+        const vendorCriteria = (0, approvalRuleSelector_1.getVendorCriteria)(rule.criteria);
+        if (vendorCriteria != null) {
+            if (billVendorId == null) {
+                return false;
+            }
+            const includesVendor = vendorCriteria.vendorIds.includes(billVendorId);
+            if (vendorCriteria.operator === 'is' && !includesVendor) {
+                return false;
+            }
+            if (vendorCriteria.operator === 'is_not' && includesVendor) {
+                return false;
+            }
+        }
+        const departmentCriteria = (0, approvalRuleSelector_1.getDepartmentCriteria)(rule.criteria);
+        if (departmentCriteria != null) {
+            if (billDepartmentId == null) {
+                return false;
+            }
+            const includesDepartment = departmentCriteria.departmentIds.includes(billDepartmentId);
+            if (departmentCriteria.operator === 'is' && !includesDepartment) {
+                return false;
+            }
+            if (departmentCriteria.operator === 'is_not' && includesDepartment) {
+                return false;
+            }
+        }
         const amountCriteria = (0, approvalRuleSelector_1.getAmountCriteria)(rule.criteria);
-        if (amountCriteria?.min == null) {
+        if (amountCriteria == null) {
+            // The form guarantees an amount criterion on every rule, so
+            // this branch is defensive against backend drift. Keep
+            // pre-3.0 behaviour: a rule that doesn't declare amount
+            // doesn't participate here.
             return false;
         }
+        // Bounds use the wire's inclusive 'gte' / 'lte' semantics, and
+        // either side may be absent for a one-sided 'greater_than' /
+        // 'less_than' rule.
         const { min, max } = amountCriteria;
-        return (billAmount > min.amount &&
-            (max?.amount != null ? billAmount <= max.amount : true));
+        const matchesMin = min == null || billAmount >= min.amount;
+        const matchesMax = max == null || billAmount <= max.amount;
+        return matchesMin && matchesMax;
     });
     if (approvalRule != null) {
         const requireApprovalSteps = approvalRule.steps.filter((step) => step.action === 'require_approval');

package/lib/view/spendManagement/reimbursement/remiSetupApproverView/remiSetupApproverViewReducer.js

@@ -186,10 +186,15 @@ const remiSetupApproverView = (0, toolkit_1.createSlice)({
         reorderRemiApprovalRules: {
             reducer(draft, action) {
                 const { approvalRuleIds } = action.payload;
+                const wasReorderInFlight = draft.reorderStatus.fetchState === 'In-Progress';
                 draft.reorderStatus = { fetchState: 'In-Progress', error: undefined };
                 // Stash the pre-reorder order for synchronous rollback on
-                // 'Failure'. See the BillPay reducer for the rationale.
-                draft.reorderRollbackIds = draft.approvalRuleIds;
+                // 'Failure'. See the BillPay reducer for the rationale,
+                // including the in-flight guard: a second drag before the
+                // first PUT lands must not overwrite the snapshot.
+                if (!wasReorderInFlight) {
+                    draft.reorderRollbackIds = draft.approvalRuleIds;
+                }
                 draft.approvalRuleIds = approvalRuleIds;
             },
             prepare(approvalRuleIds, useV3 = false) {

package/package.json

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