@zeniai/client-epic-state 5.2.41-beta5MM → 5.2.41-beta7MM

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/selectors/transactionCategorizationSelector.js

@@ -182,18 +182,35 @@ function getExpenseAutomationTransactionView(state) {
         review: monthYearPeriodId != null ? totalCountByReview[monthYearPeriodId] : 0,
         autoCategorized: monthYearPeriodId != null ? totalCountByAutoCat[monthYearPeriodId] : 0,
     };
-    // Parent-tab badge counts. Sourced from `parent_tab_total_count` in the
-    // listing response and used exclusively by the navbar / tab strip badges.
-    // Independent of which Completed sub-tab is active so the badge stays
-    // stable across sub-tab switches.
+    // Tab badge counts, used exclusively by the navbar / tab strip badges. Both
+    // tabs are counted under the filters applied to the list, so a badge always
+    // equals the number of rows that tab shows.
+    //
+    // The ACTIVE tab prefers its own list count: the two are the same number (the
+    // backend's parent_tab_total_count mirrors total_count), but `uiState.totalCount`
+    // is restored by every cache path that skips a fetch -- switching back to an
+    // already-loaded period, or to a cached Completed sub-tab -- whereas the stored
+    // badge is only written when a response lands, so on those paths it would keep
+    // showing whatever was fetched last.
+    //
+    // The `in` check is load-bearing, not defensive: `totalCount` is a per-period
+    // map typed as `Record<MonthYearPeriodId, number>`, so indexing it is typed
+    // `number` but is `undefined` for any period the active (sub-)tab has not
+    // loaded -- the window between switching to a fresh sub-tab and its response
+    // landing. Falling back to the stored badge there keeps a real number in the
+    // label instead of blanking it.
     const parentTotalCountByTab = expenseAutomationTransactionsViewState.parentTotalCountByTab;
+    const storedBadgeByTab = (tab) => monthYearPeriodId != null
+        ? (parentTotalCountByTab[tab][monthYearPeriodId] ?? 0)
+        : 0;
+    const badgeForTab = (tab, listCountByPeriod) => selectedTransactionCategorizationTab === tab &&
+        monthYearPeriodId != null &&
+        monthYearPeriodId in listCountByPeriod
+        ? listCountByPeriod[monthYearPeriodId]
+        : storedBadgeByTab(tab);
     const parentTabTotalCountByTab = {
-        review: monthYearPeriodId != null
-            ? (parentTotalCountByTab.review[monthYearPeriodId] ?? 0)
-            : 0,
-        autoCategorized: monthYearPeriodId != null
-            ? (parentTotalCountByTab.autoCategorized[monthYearPeriodId] ?? 0)
-            : 0,
+        review: badgeForTab('review', totalCountByReview),
+        autoCategorized: badgeForTab('autoCategorized', totalCountByAutoCat),
     };
     const fetchStateByTab = {
         review: {

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/expenseAutomationView/types/transactionsViewState.d.ts

@@ -139,11 +139,14 @@ export type TransactionsViewState = {
      */
     autoCategorizedSubTabCache: Partial<Record<CompletedSubTab, AutoCategorizedSubTabSnapshot>>;
     /**
-     * Period-keyed parent tab counts, scoped per {@link TransactionsTab}.
-     * Sourced from the listing response's `parent_tab_total_count` and used
-     * exclusively to drive the parent tab badges on the UI — every other
-     * count consumer (pagination, sub-tab chips, in-tab "showing X of Y")
-     * keeps reading from {@link TransactionsViewUIState.totalCount}.
+     * Period-keyed tab badge counts, scoped per {@link TransactionsTab}. Every
+     * count here is taken under the filters currently applied to the list
+     * (`transaction_group` + Completed `sub_tab` + search), so a badge always
+     * matches the rows that tab renders. The active tab is filled from the
+     * listing response's `parent_tab_total_count` and the inactive one from its
+     * `other_tab_total_count`. Used exclusively to drive the tab badges — every
+     * other count consumer (pagination, in-tab "showing X of Y") keeps reading
+     * from {@link TransactionsViewUIState.totalCount}.
      */
     parentTotalCountByTab: Record<TransactionsTab, Record<MonthYearPeriodId, number>>;
     selectedTransactionCategorizationCompletedSubTab: CompletedSubTab;

package/lib/view/invoicing/createInvoice/createInvoiceSelector.d.ts

@@ -9,8 +9,13 @@ import { InvoicingCreateInvoiceFormLocalData } from './createInvoiceState';
  * One catalog plan price, split into its two naming parts so consumers can
  * compose the label themselves (the plan family name and the price point/price
  * name are separate columns in the catalog). `price` is the price point's
- * catalog price in whole USD (never minor units), absent when the catalog
- * carries no price for it.
+ * per-unit amount in whole USD (never minor units): the service-computed
+ * single-unit display price, falling back to the configured price for
+ * responses predating it. It is absent when the catalog carries no price for
+ * it, and deliberately absent for tiered, volume and stairstep price points —
+ * their single-unit figure is a step/band fee, not a rate, so multiplying it
+ * by a quantity (which is what the Create Invoice line prefill does) would
+ * produce a plausible-looking wrong total. Those lines start unpriced.
  */
 export interface InvoicingPlanNameOption {
     planName: string;

package/lib/view/invoicing/createInvoice/createInvoiceSelector.js

@@ -2,10 +2,37 @@
 Object.defineProperty(exports, "__esModule", { value: true });
 exports.getCreateInvoiceFormView = void 0;
 const addressSelector_1 = require("../../../entity/address/addressSelector");
+const planSelector_1 = require("../../../entity/invoicing/plan/planSelector");
 const invoicingCatalogListViewSelector_1 = require("../invoicingCatalogListView/invoicingCatalogListViewSelector");
 const invoicingConfigViewSelector_1 = require("../invoicingConfigView/invoicingConfigViewSelector");
 const invoicingCustomerListViewSelector_1 = require("../invoicingCustomerListView/invoicingCustomerListViewSelector");
 const settingsViewSelector_1 = require("../settingsView/settingsViewSelector");
+/**
+ * Pricing models whose single-unit amount is a true per-unit rate — the only
+ * ones a Create Invoice line may be prefilled from. Typed against the entity
+ * union so a misspelt member fails to compile; a model added to the union
+ * still has to be classified here by hand (it is left out, so it fails closed:
+ * no prefill). The complement is `isTieredCatalogPricingModel`.
+ */
+const PER_UNIT_RATE_PRICING_MODELS = [
+    'per_unit',
+    'flat_fee',
+];
+/**
+ * Whether a price point's single-unit amount is a per-unit rate. A missing
+ * model means per-unit: the service defaults `pricing_model` to `per_unit`
+ * and older records may omit it.
+ */
+const hasPerUnitRate = (pricingModel) => pricingModel == null ||
+    pricingModel === '' ||
+    PER_UNIT_RATE_PRICING_MODELS.some((model) => model === pricingModel);
+/**
+ * The amount to prefill on a Create Invoice line for a price point, or
+ * `undefined` when there is no safe per-unit rate to prefill.
+ */
+const planNamePrefillPrice = (pricePoint) => hasPerUnitRate(pricePoint.pricingModel)
+    ? (0, planSelector_1.invoicingPricePointDisplayAmount)(pricePoint)?.amount
+    : undefined;
 /**
  * Display name for a customer option: company, else the full name, else the
  * email, else the raw id.
@@ -50,7 +77,7 @@ const getCreateInvoiceFormView = (state) => {
             .filter((subFamily) => (subFamily.name ?? '') !== '')
             .map((subFamily) => ({
             planName: plan.name ?? '',
-            price: subFamily.price?.amount,
+            price: planNamePrefillPrice(subFamily),
             subFamilyName: subFamily.name ?? '',
         }))),
         products: (0, invoicingCatalogListViewSelector_1.getInvoicingCatalogPrices)(catalogListView.products),

package/lib/view/invoicing/editInvoicingCatalogItemDetailView/editInvoicingCatalogItemDetailViewPayload.d.ts

@@ -1,10 +1,33 @@
 import { AccountBase } from '../../../entity/account/accountState';
 import { ClassBase } from '../../../entity/class/classState';
 import { InvoicingPlanPayload } from '../../../entity/invoicing/plan/planPayload';
-import { InvoicingProductPayload } from '../../../entity/invoicing/product/productPayload';
+import { InvoicingAccountingDetailPayload, InvoicingProductPayload } from '../../../entity/invoicing/product/productPayload';
 import { ZeniAPIResponse } from '../../../responsePayload';
 import { InvoicingCatalogItemFormLocalData } from './editInvoicingCatalogItemDetailViewState';
 export type SaveInvoicingCatalogItemResponse = ZeniAPIResponse<InvoicingPlanPayload>;
+/**
+ * The price-point half of a save body. `InvoicingProductPayload` is the shape
+ * the service returns; a save differs in that a field is cleared by sending an
+ * explicit `null`, since an absent key reads as "leave it alone".
+ */
+export type InvoicingCatalogSubFamilySavePayload = Omit<Partial<InvoicingProductPayload>, 'accounting_detail' | 'description' | 'invoice_notes'> & {
+    accounting_detail?: InvoicingAccountingDetailPayload | null;
+    description?: string | null;
+    invoice_notes?: string | null;
+};
+/**
+ * The catalog-item save body: the item the service returns, minus the fields it
+ * assigns itself.
+ *
+ * Price points travel under `sub_families`, the name they are read back under,
+ * and differ only in allowing the cleared forms above. An update addresses them
+ * by id, so a price point added on the form — which has none yet — is created
+ * by its own request instead; see
+ * `localDataToCreateInvoicingCatalogProductPayloads`.
+ */
+export type InvoicingCatalogItemSavePayload = Omit<Partial<InvoicingPlanPayload>, 'sub_families'> & {
+    sub_families?: InvoicingCatalogSubFamilySavePayload[];
+};
 /**
  * Resolves the QuickBooks ids the pickers submit back to the entities they name.
  * The payload carries the whole account and class, so the ids alone are not
@@ -20,12 +43,30 @@ export interface InvoicingCatalogAccountingFields {
     accountingCode: string;
     sku: string;
 }
-export declare const buildAccountingDetail: (subFamily: InvoicingCatalogAccountingFields, lookup: InvoicingCatalogAccountingLookup) => Record<string, unknown> | undefined;
+export declare const buildAccountingDetail: (subFamily: InvoicingCatalogAccountingFields, lookup: InvoicingCatalogAccountingLookup) => InvoicingAccountingDetailPayload | undefined;
+/**
+ * Build the parent catalog-item request body from the form draft. Every field
+ * the form holds is sent, so a value cleared on the form is cleared on the
+ * item: the service reads an absent key as "leave it alone", which is why
+ * `description` travels as an empty string and `applicable_items` as an empty
+ * list rather than being dropped. Fields the form does not collect
+ * (`external_name`, `item_family_id`, `metadata`, …) stay off the body so an
+ * edit cannot overwrite them with a value nobody chose.
+ */
+export declare const localDataToSaveInvoicingCatalogItemPayload: (localData: InvoicingCatalogItemFormLocalData, isCreate: boolean, lookup: InvoicingCatalogAccountingLookup) => InvoicingCatalogItemSavePayload;
 /**
- * Build the parent catalog-item request body from the form draft. Creates omit
- * both parent and price point IDs; edits retain returned price point IDs.
+ * The bodies that create the price points added on an edit form, one per
+ * request to `/catalog/products`.
+ *
+ * An update cannot carry them: it addresses price points by id, and these have
+ * none until the service assigns one. They are bound to their item by
+ * `item_id`, so this needs the saved item's id and runs after the item itself
+ * is saved.
+ *
+ * Empty values are left off rather than sent as `null`: there is nothing on a
+ * price point that does not exist yet to clear.
  */
-export declare const localDataToSaveInvoicingCatalogItemPayload: (localData: InvoicingCatalogItemFormLocalData, isCreate: boolean, lookup: InvoicingCatalogAccountingLookup) => Record<string, unknown>;
+export declare const localDataToCreateInvoicingCatalogProductPayloads: (localData: InvoicingCatalogItemFormLocalData, itemId: string, lookup: InvoicingCatalogAccountingLookup) => InvoicingCatalogSubFamilySavePayload[];
 export type RunInvoicingCatalogPlanActionResponse = ZeniAPIResponse<InvoicingPlanPayload>;
 export type RunInvoicingCatalogProductActionResponse = ZeniAPIResponse<InvoicingProductPayload>;
 export type InvoicingCatalogItemDetailResponse = ZeniAPIResponse<InvoicingPlanPayload>;

package/lib/view/invoicing/editInvoicingCatalogItemDetailView/editInvoicingCatalogItemDetailViewPayload.js

@@ -1,12 +1,11 @@
 "use strict";
 Object.defineProperty(exports, "__esModule", { value: true });
-exports.localDataToSaveInvoicingCatalogItemPayload = exports.buildAccountingDetail = void 0;
+exports.localDataToCreateInvoicingCatalogProductPayloads = exports.localDataToSaveInvoicingCatalogItemPayload = exports.buildAccountingDetail = void 0;
 const accountPayload_1 = require("../../../entity/account/accountPayload");
 const classPayload_1 = require("../../../entity/class/classPayload");
 const invoicingCatalogItemFormHelper_1 = require("./invoicingCatalogItemFormHelper");
 const CURRENCY_CODE = 'USD';
 const trimOrUndefined = (value) => value.trim() !== '' ? value.trim() : undefined;
-const trimOrNull = (value) => value.trim() !== '' ? value.trim() : null;
 const toProductCode = (value) => value
     .trim()
     .toLowerCase()
@@ -95,13 +94,24 @@ const buildSubFamilyPayload = (localData, subFamily, clearEmptyValues, lookup) =
 /** `unit` is the item's unit of measure, not a currency; `CURRENCY_CODE` above prices Price points. */
 const DEFAULT_CATALOG_ITEM_UNIT = 'USD';
 /**
- * Build the parent catalog-item request body from the form draft. Creates omit
- * both parent and price point IDs; edits retain returned price point IDs.
+ * Build the parent catalog-item request body from the form draft. Every field
+ * the form holds is sent, so a value cleared on the form is cleared on the
+ * item: the service reads an absent key as "leave it alone", which is why
+ * `description` travels as an empty string and `applicable_items` as an empty
+ * list rather than being dropped. Fields the form does not collect
+ * (`external_name`, `item_family_id`, `metadata`, …) stay off the body so an
+ * edit cannot overwrite them with a value nobody chose.
  */
 const localDataToSaveInvoicingCatalogItemPayload = (localData, isCreate, lookup) => {
-    const description = trimOrUndefined(localData.description);
     const productCode = trimOrUndefined(localData.productCode) ?? toProductCode(localData.name);
     const itemPayload = {
+        // `applicable_items` only means anything while the item is restricted;
+        // sending the empty list otherwise is what clears a restriction that was
+        // just lifted.
+        applicable_items: localData.itemApplicability === 'restricted'
+            ? localData.applicableItems
+            : [],
+        description: trimOrUndefined(localData.description) ?? '',
         enabled_for_checkout: true,
         enabled_in_portal: true,
         is_giftable: false,
@@ -111,42 +121,65 @@ const localDataToSaveInvoicingCatalogItemPayload = (localData, isCreate, lookup)
         name: localData.name.trim(),
         product_code: productCode,
         type: localData.catalogType,
+        // The form no longer collects a unit; an item that already has one keeps it.
+        unit: trimOrUndefined(localData.unit) ?? DEFAULT_CATALOG_ITEM_UNIT,
     };
-    if (description != null) {
-        itemPayload.description = description;
-    }
-    // The form no longer collects a unit; an item that already has one keeps it.
-    itemPayload.unit =
-        trimOrUndefined(localData.unit) ?? DEFAULT_CATALOG_ITEM_UNIT;
-    if (localData.itemApplicability === 'restricted' &&
-        localData.applicableItems.length > 0) {
-        itemPayload.applicable_items = localData.applicableItems;
+    // The external id is assigned by the billing service and shown read-only, so
+    // it is echoed back only when the item already has one: sending the blank a
+    // create starts with would clear an id assigned in the meantime.
+    const externalId = trimOrUndefined(localData.externalId);
+    if (externalId != null) {
+        itemPayload.external_id = externalId;
     }
     const subFamilies = localData.subFamilies.length > 0
         ? localData.subFamilies
         : [(0, invoicingCatalogItemFormHelper_1.blankInvoicingCatalogSubFamily)()];
-    itemPayload.sub_family_details = isCreate
-        ? subFamilies.map((subFamily) => buildSubFamilyPayload(localData, subFamily, false, lookup))
-        : subFamilies.map((subFamily) => {
-            const priceCode = trimOrUndefined(subFamily.priceCode) ?? toProductCode(subFamily.name);
-            const detail = {
-                description: trimOrNull(subFamily.description),
-                invoice_notes: trimOrNull(subFamily.invoiceNotes),
-                name: subFamily.name.trim(),
-                price_code: priceCode,
-                show_description_in_invoices: subFamily.showDescriptionInInvoices,
-            };
-            // Edits send a narrower body than creates, but the accounting mapping
-            // is editable on this form, so leaving it out dropped the account and
-            // class the user had just picked. `null` rather than omitted when it is
-            // empty: an absent key on an update reads as "leave it alone", which
-            // would make a cleared mapping impossible to save — the same reason
-            // `description` and `invoice_notes` go through `trimOrNull`.
-            detail.accounting_detail =
-                (0, exports.buildAccountingDetail)(subFamily, lookup) ?? null;
-            const id = trimOrUndefined(subFamily.id);
-            return id != null ? { ...detail, id } : detail;
-        });
+    if (isCreate) {
+        itemPayload.sub_families = subFamilies.map((subFamily) => buildSubFamilyPayload(localData, subFamily, false, lookup));
+        return itemPayload;
+    }
+    // Only price points the service has already stored travel in an update: it
+    // addresses them by id, and a blank one has nothing to address. A price point
+    // added on the form is created by its own request once the item is saved,
+    // rather than riding along as a row the update cannot place.
+    itemPayload.sub_families = subFamilies
+        .filter((subFamily) => subFamily.id !== '')
+        .map((subFamily) => {
+        // Edits send the same body a create does. The narrower hand-built one
+        // this replaces had to be kept in step by hand and was not: it dropped
+        // `accounting_detail` once, and `billing_cycles`, `price`,
+        // `pricing_model`, `period`, the trial fields, `proration_type`,
+        // `free_quantity`, `is_taxable` and `tiers` were never added at all, so
+        // editing any of them looked saved and changed nothing.
+        const detail = buildSubFamilyPayload(localData, subFamily, true, lookup);
+        // `null` rather than omitted when empty: an absent key on an update
+        // reads as "leave it alone", which would make a cleared mapping
+        // impossible to save — the same reason `description` and
+        // `invoice_notes` are cleared rather than dropped above.
+        detail.accounting_detail = detail.accounting_detail ?? null;
+        // Never blank: the filter above leaves only price points the service has
+        // already stored, which is the only kind an update can address.
+        return { ...detail, id: subFamily.id };
+    });
     return itemPayload;
 };
 exports.localDataToSaveInvoicingCatalogItemPayload = localDataToSaveInvoicingCatalogItemPayload;
+/**
+ * The bodies that create the price points added on an edit form, one per
+ * request to `/catalog/products`.
+ *
+ * An update cannot carry them: it addresses price points by id, and these have
+ * none until the service assigns one. They are bound to their item by
+ * `item_id`, so this needs the saved item's id and runs after the item itself
+ * is saved.
+ *
+ * Empty values are left off rather than sent as `null`: there is nothing on a
+ * price point that does not exist yet to clear.
+ */
+const localDataToCreateInvoicingCatalogProductPayloads = (localData, itemId, lookup) => localData.subFamilies
+    .filter((subFamily) => subFamily.id === '')
+    .map((subFamily) => ({
+    ...buildSubFamilyPayload(localData, subFamily, false, lookup),
+    item_id: itemId,
+}));
+exports.localDataToCreateInvoicingCatalogProductPayloads = localDataToCreateInvoicingCatalogProductPayloads;

package/lib/view/invoicing/editInvoicingCatalogItemDetailView/editInvoicingCatalogItemDetailViewReducer.d.ts

@@ -74,6 +74,8 @@ export declare const updateInvoicingCatalogItemFormDraft: import("@reduxjs/toolk
 }, "editInvoicingCatalogItemDetailView/runInvoicingCatalogProductActionFailure">, submitInvoicingCatalogItemForm: import("@reduxjs/toolkit").ActionCreatorWithPreparedPayload<[payload: SubmitInvoicingCatalogItemFormPayload], SubmitInvoicingCatalogItemFormPayload, "editInvoicingCatalogItemDetailView/submitInvoicingCatalogItemForm", never, never>, submitInvoicingCatalogItemFormSuccess: import("@reduxjs/toolkit").ActionCreatorWithPayload<{
     itemId: ID;
     kind: InvoicingCatalogItemKind;
-}, "editInvoicingCatalogItemDetailView/submitInvoicingCatalogItemFormSuccess">, submitInvoicingCatalogItemFormFailure: import("@reduxjs/toolkit").ActionCreatorWithPayload<ZeniAPIStatus<Record<string, unknown>>, "editInvoicingCatalogItemDetailView/submitInvoicingCatalogItemFormFailure">, resetEditInvoicingCatalogItemDetailView: import("@reduxjs/toolkit").ActionCreatorWithoutPayload<"editInvoicingCatalogItemDetailView/resetEditInvoicingCatalogItemDetailView">;
+}, "editInvoicingCatalogItemDetailView/submitInvoicingCatalogItemFormSuccess">, submitInvoicingCatalogItemFormFailure: import("@reduxjs/toolkit").ActionCreatorWithPayload<ZeniAPIStatus<Record<string, unknown>>, "editInvoicingCatalogItemDetailView/submitInvoicingCatalogItemFormFailure">, resetEditInvoicingCatalogItemDetailView: import("@reduxjs/toolkit").ActionCreatorWithOptionalPayload<{
+    id?: ID;
+} | undefined, "editInvoicingCatalogItemDetailView/resetEditInvoicingCatalogItemDetailView">;
 declare const _default: import("redux").Reducer<EditInvoicingCatalogItemDetailViewState>;
 export default _default;

package/lib/view/invoicing/editInvoicingCatalogItemDetailView/editInvoicingCatalogItemDetailViewReducer.js

@@ -4,6 +4,7 @@ Object.defineProperty(exports, "__esModule", { value: true });
 exports.resetEditInvoicingCatalogItemDetailView = exports.submitInvoicingCatalogItemFormFailure = exports.submitInvoicingCatalogItemFormSuccess = exports.submitInvoicingCatalogItemForm = exports.runInvoicingCatalogProductActionFailure = exports.runInvoicingCatalogProductActionSuccess = exports.runInvoicingCatalogProductAction = exports.runInvoicingCatalogPlanActionFailure = exports.runInvoicingCatalogPlanActionSuccess = exports.runInvoicingCatalogPlanAction = exports.seedInvoicingCatalogItemFormDraft = exports.updateInvoicingCatalogItemDetailFailure = exports.updateInvoicingCatalogItemDetail = exports.fetchInvoicingCatalogItemDetailPage = exports.fetchInvoicingCatalogItemDetail = exports.updateInvoicingCatalogItemFormDraft = exports.initialState = void 0;
 const toolkit_1 = require("@reduxjs/toolkit");
 const rootActions_1 = require("../../../rootActions");
+const invoicingFormDraft_1 = require("../invoicingFormDraft");
 const invoicingCatalogItemFormHelper_1 = require("./invoicingCatalogItemFormHelper");
 exports.initialState = {
     fetchState: 'Not-Started',
@@ -25,7 +26,7 @@ const editInvoicingCatalogItemDetailView = (0, toolkit_1.createSlice)({
         updateInvoicingCatalogItemFormDraft(draft, action) {
             const { id, localData } = action.payload;
             if (id != null) {
-                draft.editDraftById[id] = localData;
+                (0, invoicingFormDraft_1.applyInvoicingFormDraftEdit)(draft.editDraftById, id, localData);
             }
             else {
                 draft.newItemDraft = localData;
@@ -46,6 +47,9 @@ const editInvoicingCatalogItemDetailView = (0, toolkit_1.createSlice)({
             draft.error = undefined;
             draft.savedItemId = action.payload.itemId;
             draft.savedKind = action.payload.kind;
+            // An edit is refetched on success; keep the saved values on screen until
+            // that lands, and let it replace them.
+            (0, invoicingFormDraft_1.applyInvoicingFormDraftSaved)(draft.editDraftById, action.payload.itemId);
         },
         submitInvoicingCatalogItemFormFailure(draft, action) {
             draft.fetchState = 'Error';
@@ -68,6 +72,7 @@ const editInvoicingCatalogItemDetailView = (0, toolkit_1.createSlice)({
                 fetchState: 'Error',
                 error: action.payload.error,
             };
+            (0, invoicingFormDraft_1.applyInvoicingFormDraftFailure)(draft.editDraftById, action.payload.id, invoicingCatalogItemFormHelper_1.initialInvoicingCatalogItemFormLocalData);
         },
         fetchInvoicingCatalogItemDetailPage: {
             reducer() {
@@ -83,14 +88,10 @@ const editInvoicingCatalogItemDetailView = (0, toolkit_1.createSlice)({
                 };
             },
         },
-        /**
-         * Seed the draft from the loaded record, once. Skipped when a draft already
-         * exists so a late-arriving refetch cannot overwrite in-progress edits.
-         */
+        /** Fill the draft from the loaded record — see `applyInvoicingFormDraftSeed`. */
         seedInvoicingCatalogItemFormDraft(draft, action) {
-            if (draft.editDraftById[action.payload.id] == null) {
-                draft.editDraftById[action.payload.id] = action.payload.localData;
-            }
+            const { id, localData } = action.payload;
+            (0, invoicingFormDraft_1.applyInvoicingFormDraftSeed)(draft.editDraftById, id, localData);
         },
         runInvoicingCatalogPlanAction(draft, action) {
             draft.actionStateById[action.payload.id] = {
@@ -129,13 +130,23 @@ const editInvoicingCatalogItemDetailView = (0, toolkit_1.createSlice)({
                 error: action.payload.error,
             };
         },
-        resetEditInvoicingCatalogItemDetailView(draft) {
+        /**
+         * Discard a form's draft — the catalog item's own when `id` is given,
+         * the create draft otherwise. Scoped to the one form on purpose: another
+         * catalog item's half-finished edit is not this form's to throw away.
+         * Clearing every draft at once is what `clearAll` is for.
+         */
+        resetEditInvoicingCatalogItemDetailView(draft, action) {
             draft.fetchState = 'Not-Started';
             draft.error = undefined;
             draft.savedItemId = undefined;
             draft.savedKind = undefined;
-            draft.editDraftById = {};
-            draft.newItemDraft = { ...invoicingCatalogItemFormHelper_1.initialInvoicingCatalogItemFormLocalData };
+            const id = action.payload?.id;
+            if (id == null) {
+                draft.newItemDraft = { ...invoicingCatalogItemFormHelper_1.initialInvoicingCatalogItemFormLocalData };
+                return;
+            }
+            delete draft.editDraftById[id];
         },
     },
     extraReducers: (builder) => {

package/lib/view/invoicing/editInvoicingCatalogItemDetailView/editInvoicingCatalogItemDetailViewSelector.d.ts

@@ -44,6 +44,16 @@ export interface InvoicingCatalogItemFormView extends SelectorView {
      * Folded in here so the screen never reaches for the config view itself.
      */
     fieldHelp: InvoicingFieldHelpByCode;
+    /**
+     * True while anything the form's fields mount against is still loading: the
+     * accounting lists, and — until it has reached the draft — the item being
+     * edited. The form holds a skeleton on this rather than mount, because both
+     * arrive too late to be picked up: it seeds react-hook-form once, at first
+     * render, and the accounting fields choose between a picker and a text input
+     * from the lists. A later refetch does not raise this again, so a refresh
+     * leaves the form on screen instead of blanking it mid-edit.
+     */
+    isFormLoading: boolean;
     /**
      * True while the accounting lists are still loading, so the form can wait
      * instead of mounting pickers whose options are not there yet.
@@ -69,6 +79,13 @@ export interface InvoicingCatalogItemFormView extends SelectorView {
      */
     qboAccountHierarchy: NestedAccountHierarchyForReport[];
     qboClassHierarchy: NestedClassHierarchyForReport[];
+    /**
+     * The ids within the account tree an income account may be picked from.
+     * QuickBooks only accepts an income account on a product, so a price point
+     * mapped to anything else — A/R, deferred revenue, a bank account — fails to
+     * sync once an invoice carrying it is pushed.
+     */
+    qboIncomeAccountIds: string[];
     /**
      * Loading the item, as distinct from this view's own `fetchState`, which
      * tracks the save.