@zeniai/client-epic-state 5.2.28 → 5.2.30-betaRD0

package/lib/entity/jeSchedules/jeSchedulesState.d.ts

@@ -145,9 +145,16 @@ export interface JEAccruedScheduledTransactionState extends Omit<JEScheduledTran
 export interface OneTimeAccrualEdits {
     expectedReversalDate?: ZeniDate;
     jeCreditAccountId?: ID;
+    /**
+     * Carried beside the id, not derived from it later: the accrual document stores the name too, so
+     * an id sent without its name leaves the row displaying the account the user just moved away
+     * from.
+     */
+    jeCreditAccountName?: string;
     jeDebitAccountId?: ID;
     jeDebitAccountingClassId?: ID;
     jeDebitAccountingClassName?: string;
+    jeDebitAccountName?: string;
     memo?: string;
     /**
      * The Auto Reversal toggle, modelled as the same boolean the New form and the create payload use

package/lib/esm/view/expenseAutomationView/epics/jeSchedule/fetchJeSchedulesEpic.js

@@ -9,6 +9,18 @@ import { clearAll } from '../../../../rootActions';
 import { date } from '../../../../zeniDayJS';
 import { SERVICE_MONTH_FORMAT, } from '../../payload/jeSchedulesPayload';
 import { fetchJeSchedules, fetchJeSchedulesFailure, fetchJeSchedulesSuccess, initializeJeScheduleLocalData, } from '../../reducers/jeSchedulesViewReducer';
+/**
+ * How far back to look for accrued schedules, matching the Vendors page
+ * (`getDefaultSelectedTimeframeForScheduleType`, 'accrued_expenses'), which queries the same
+ * start_date filter through /1.0/schedules.
+ */
+const ACCRUED_LOOKBACK_MONTHS = 24;
+/**
+ * One-time accruals keep their own, narrower lookback. Unlike an accrued schedule they belong to
+ * exactly one service month and never span months, so the reason the accrued window has to reach
+ * back does not apply to them -- widening it would only add older history to the Existing tab.
+ */
+const ONE_TIME_ACCRUAL_LOOKBACK_MONTHS = 12;
 export const fetchJeSchedulesEpic = (actions$, state$, zeniAPI) => actions$.pipe(filter(fetchJeSchedules.match), mergeMap((action) => {
     const state = state$.value;
     const { expenseAutomationViewState: { selectedPeriodByTenantId }, } = state;
@@ -30,15 +42,21 @@ export const fetchJeSchedulesEpic = (actions$, state$, zeniAPI) => actions$.pipe
     const endDate = isClosePeriodTab || existingEndDate == null
         ? toString(period.end)
         : toString(existingEndDate);
-    // Accrued rows are windowed on the schedule's own start_date rather than a transaction date,
-    // so they get their own bounds. Review wants the month being closed; Existing wants the year
-    // up to endDate, snapped to the 1st — the same window the server used to compute for itself.
-    const accruedStartDate = isClosePeriodTab
-        ? toString(period.start)
-        : date(endDate)
-            .subtract(1, 'year')
-            .startOf('month')
-            .format(DEFAULT_DATE_FORMAT);
+    // Accrued rows are windowed on the schedule's own start_date -- its FIRST posting date --
+    // rather than a transaction date, so the lower bound has to reach back past the start of
+    // every accrual still running in this period, not just the ones that began in it. Review
+    // used to send the close month itself, which returned only accruals whose first posting fell
+    // in that month and hid every longer-running one.
+    const parsedEndDate = date(endDate);
+    const accruedStartDate = parsedEndDate
+        .subtract(ACCRUED_LOOKBACK_MONTHS, 'month')
+        .startOf('month')
+        .format(DEFAULT_DATE_FORMAT);
+    // Formatted as a service month, not a date: that is the only thing it is sent as.
+    const oneTimeAccrualServiceMonthStart = parsedEndDate
+        .subtract(ONE_TIME_ACCRUAL_LOOKBACK_MONTHS, 'month')
+        .startOf('month')
+        .format(SERVICE_MONTH_FORMAT);
     const queryParam = {
         base_transaction_end_date: endDate,
         end_date: endDate,
@@ -59,8 +77,8 @@ export const fetchJeSchedulesEpic = (actions$, state$, zeniAPI) => actions$.pipe
                 filter_failed_je_postings_by_date: true,
             }
             : {
-                one_time_accrual_service_month_start: date(accruedStartDate).format(SERVICE_MONTH_FORMAT),
-                one_time_accrual_service_month_end: date(endDate).format(SERVICE_MONTH_FORMAT),
+                one_time_accrual_service_month_start: oneTimeAccrualServiceMonthStart,
+                one_time_accrual_service_month_end: parsedEndDate.format(SERVICE_MONTH_FORMAT),
                 // Existing lists what actually reached the books.
                 one_time_accrual_statuses: ['posted'],
                 // A failed posting from an earlier month still needs to surface here, so this list

package/lib/esm/view/expenseAutomationView/epics/jeSchedule/oneTimeAccrualActionsEpic.js

@@ -73,17 +73,39 @@ export const promoteOneTimeAccrualEpic = (actions$, state$, zeniAPI) => actions$
     const debitClassId = edits?.jeDebitAccountingClassId ?? accrual?.jeDebitAccountingClassId;
     const debitClassName = edits?.jeDebitAccountingClassName ??
         accrual?.jeDebitAccountingClassName;
+    // The accrual document stores names alongside ids, so every id below travels with its name.
+    // Sending an id on its own leaves the stored row -- and the JE posted from it -- naming the
+    // account the user just moved away from. Create has always sent the full set; promote did
+    // not, which is the difference the two paths were showing.
+    const debitAccountName = edits?.jeDebitAccountName ?? accrual?.jeDebitAccountName;
+    const creditAccountName = edits?.jeCreditAccountName ?? accrual?.jeCreditAccountName;
+    // Credit-side class is never edited on this form -- the liability side is the Balance Sheet
+    // class the draft was born with -- so it is echoed straight back from the draft.
+    const creditClassId = accrual?.jeCreditAccountingClassId;
+    const creditClassName = accrual?.jeCreditAccountingClassName;
     const payload = {
         amount,
         memo: edits?.memo ?? accrual?.memo ?? '',
         je_debit_account_id: debitAccountId,
         je_credit_account_id: creditAccountId,
+        ...(debitAccountName != null
+            ? { je_debit_account_name: debitAccountName }
+            : {}),
+        ...(creditAccountName != null
+            ? { je_credit_account_name: creditAccountName }
+            : {}),
         ...(debitClassId != null
             ? { je_debit_accounting_class_id: debitClassId }
             : {}),
         ...(debitClassName != null
             ? { je_debit_accounting_class_name: debitClassName }
             : {}),
+        ...(creditClassId != null
+            ? { je_credit_accounting_class_id: creditClassId }
+            : {}),
+        ...(creditClassName != null
+            ? { je_credit_accounting_class_name: creditClassName }
+            : {}),
         // Mirrors the create payload: reverse_next_month alone decides the policy, and the date is
         // only meaningful when it is true -- agent-je derives the reversal from the bill otherwise.
         reverse_next_month: reverseNextMonth,

package/lib/view/expenseAutomationView/epics/jeSchedule/fetchJeSchedulesEpic.js

@@ -12,6 +12,18 @@ const rootActions_1 = require("../../../../rootActions");
 const zeniDayJS_1 = require("../../../../zeniDayJS");
 const jeSchedulesPayload_1 = require("../../payload/jeSchedulesPayload");
 const jeSchedulesViewReducer_1 = require("../../reducers/jeSchedulesViewReducer");
+/**
+ * How far back to look for accrued schedules, matching the Vendors page
+ * (`getDefaultSelectedTimeframeForScheduleType`, 'accrued_expenses'), which queries the same
+ * start_date filter through /1.0/schedules.
+ */
+const ACCRUED_LOOKBACK_MONTHS = 24;
+/**
+ * One-time accruals keep their own, narrower lookback. Unlike an accrued schedule they belong to
+ * exactly one service month and never span months, so the reason the accrued window has to reach
+ * back does not apply to them -- widening it would only add older history to the Existing tab.
+ */
+const ONE_TIME_ACCRUAL_LOOKBACK_MONTHS = 12;
 const fetchJeSchedulesEpic = (actions$, state$, zeniAPI) => actions$.pipe((0, operators_1.filter)(jeSchedulesViewReducer_1.fetchJeSchedules.match), (0, operators_1.mergeMap)((action) => {
     const state = state$.value;
     const { expenseAutomationViewState: { selectedPeriodByTenantId }, } = state;
@@ -33,15 +45,21 @@ const fetchJeSchedulesEpic = (actions$, state$, zeniAPI) => actions$.pipe((0, op
     const endDate = isClosePeriodTab || existingEndDate == null
         ? (0, timePeriod_2.toString)(period.end)
         : (0, timePeriod_2.toString)(existingEndDate);
-    // Accrued rows are windowed on the schedule's own start_date rather than a transaction date,
-    // so they get their own bounds. Review wants the month being closed; Existing wants the year
-    // up to endDate, snapped to the 1st — the same window the server used to compute for itself.
-    const accruedStartDate = isClosePeriodTab
-        ? (0, timePeriod_2.toString)(period.start)
-        : (0, zeniDayJS_1.date)(endDate)
-            .subtract(1, 'year')
-            .startOf('month')
-            .format(timePeriod_1.DEFAULT_DATE_FORMAT);
+    // Accrued rows are windowed on the schedule's own start_date -- its FIRST posting date --
+    // rather than a transaction date, so the lower bound has to reach back past the start of
+    // every accrual still running in this period, not just the ones that began in it. Review
+    // used to send the close month itself, which returned only accruals whose first posting fell
+    // in that month and hid every longer-running one.
+    const parsedEndDate = (0, zeniDayJS_1.date)(endDate);
+    const accruedStartDate = parsedEndDate
+        .subtract(ACCRUED_LOOKBACK_MONTHS, 'month')
+        .startOf('month')
+        .format(timePeriod_1.DEFAULT_DATE_FORMAT);
+    // Formatted as a service month, not a date: that is the only thing it is sent as.
+    const oneTimeAccrualServiceMonthStart = parsedEndDate
+        .subtract(ONE_TIME_ACCRUAL_LOOKBACK_MONTHS, 'month')
+        .startOf('month')
+        .format(jeSchedulesPayload_1.SERVICE_MONTH_FORMAT);
     const queryParam = {
         base_transaction_end_date: endDate,
         end_date: endDate,
@@ -62,8 +80,8 @@ const fetchJeSchedulesEpic = (actions$, state$, zeniAPI) => actions$.pipe((0, op
                 filter_failed_je_postings_by_date: true,
             }
             : {
-                one_time_accrual_service_month_start: (0, zeniDayJS_1.date)(accruedStartDate).format(jeSchedulesPayload_1.SERVICE_MONTH_FORMAT),
-                one_time_accrual_service_month_end: (0, zeniDayJS_1.date)(endDate).format(jeSchedulesPayload_1.SERVICE_MONTH_FORMAT),
+                one_time_accrual_service_month_start: oneTimeAccrualServiceMonthStart,
+                one_time_accrual_service_month_end: parsedEndDate.format(jeSchedulesPayload_1.SERVICE_MONTH_FORMAT),
                 // Existing lists what actually reached the books.
                 one_time_accrual_statuses: ['posted'],
                 // A failed posting from an earlier month still needs to surface here, so this list

package/lib/view/expenseAutomationView/epics/jeSchedule/oneTimeAccrualActionsEpic.js

@@ -76,17 +76,39 @@ const promoteOneTimeAccrualEpic = (actions$, state$, zeniAPI) => actions$.pipe((
     const debitClassId = edits?.jeDebitAccountingClassId ?? accrual?.jeDebitAccountingClassId;
     const debitClassName = edits?.jeDebitAccountingClassName ??
         accrual?.jeDebitAccountingClassName;
+    // The accrual document stores names alongside ids, so every id below travels with its name.
+    // Sending an id on its own leaves the stored row -- and the JE posted from it -- naming the
+    // account the user just moved away from. Create has always sent the full set; promote did
+    // not, which is the difference the two paths were showing.
+    const debitAccountName = edits?.jeDebitAccountName ?? accrual?.jeDebitAccountName;
+    const creditAccountName = edits?.jeCreditAccountName ?? accrual?.jeCreditAccountName;
+    // Credit-side class is never edited on this form -- the liability side is the Balance Sheet
+    // class the draft was born with -- so it is echoed straight back from the draft.
+    const creditClassId = accrual?.jeCreditAccountingClassId;
+    const creditClassName = accrual?.jeCreditAccountingClassName;
     const payload = {
         amount,
         memo: edits?.memo ?? accrual?.memo ?? '',
         je_debit_account_id: debitAccountId,
         je_credit_account_id: creditAccountId,
+        ...(debitAccountName != null
+            ? { je_debit_account_name: debitAccountName }
+            : {}),
+        ...(creditAccountName != null
+            ? { je_credit_account_name: creditAccountName }
+            : {}),
         ...(debitClassId != null
             ? { je_debit_accounting_class_id: debitClassId }
             : {}),
         ...(debitClassName != null
             ? { je_debit_accounting_class_name: debitClassName }
             : {}),
+        ...(creditClassId != null
+            ? { je_credit_accounting_class_id: creditClassId }
+            : {}),
+        ...(creditClassName != null
+            ? { je_credit_accounting_class_name: creditClassName }
+            : {}),
         // Mirrors the create payload: reverse_next_month alone decides the policy, and the date is
         // only meaningful when it is true -- agent-je derives the reversal from the bill otherwise.
         reverse_next_month: reverseNextMonth,

package/lib/view/expenseAutomationView/payload/jeSchedulesPayload.d.ts

@@ -119,8 +119,10 @@ export interface PromoteOneTimeAccrualPayload {
     je_debit_account_id: ID;
     memo: string;
     expected_reversal_date?: string;
+    je_credit_account_name?: string;
     je_credit_accounting_class_id?: ID;
     je_credit_accounting_class_name?: string;
+    je_debit_account_name?: string;
     je_debit_accounting_class_id?: ID;
     je_debit_accounting_class_name?: string;
     reverse_next_month?: boolean;

package/package.json

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