import { NestedAccountHierarchyForReport } from '../../../commonStateTypes/accountView/nestedAccountID';
import { FetchState, FetchStateAndError } from '../../../commonStateTypes/common';
import { InvoicingDunningActionOption, InvoicingFieldHelpByCode, InvoicingNamedOption, InvoicingQboAccountMappingKindOption, InvoicingSettingsPayload } from '../../../entity/invoicing/invoicingCommonPayload';
import { ZeniAPIStatus } from '../../../responsePayload';
import { RootState } from '../../../rootStateTypes';
import { InvoicingQboConnection, InvoicingQboSyncHealth } from '../invoicingQboView/invoicingQboViewPayload';
import { InvoicingAccountingOption } from '../invoicingQboView/invoicingQboViewSelector';
import { InvoicingBrandingFormLocalData } from './invoicingBrandingFormConfig';
import { InvoicingQboSettingsLocalData } from './invoicingQboSettingsFormConfig';
/**
 * Shared primitive: the raw invoicing settings. Consumed internally by other
 * CES selectors (create-invoice, customer-detail, overview) and by non-settings
 * screens — kept standalone rather than folded into the settings view.
 */
export declare const getInvoicingSettings: (state: RootState) => InvoicingSettingsPayload | undefined;
/**
 * Shared primitive: the settings fetch state. Consumed internally by the
 * invoicing overview selector/epic for `shouldFetch` gating — kept standalone.
 */
export declare const getInvoicingSettingsFetchState: (state: RootState) => FetchStateAndError;
export interface InvoicingSettingsView {
    fetchState: FetchState;
    fieldHelp: InvoicingFieldHelpByCode;
    saveState: FetchStateAndError;
    stripeConnectState: FetchStateAndError;
    error?: ZeniAPIStatus;
    settings?: InvoicingSettingsPayload;
}
/**
 * Single bundled view for the invoicing settings screen — carries the raw
 * `settings`, the load fetch (`fetchState`/`error`), the `saveState`, and the
 * Stripe-connect fetch state.
 */
export declare const getInvoicingSettingsView: (state: RootState) => InvoicingSettingsView;
export interface InvoicingEnablePrerequisites {
    canEnable: boolean;
    isQboConfigured: boolean;
    isStripeConnected: boolean;
}
/**
 * Gates the Enable Invoicing action: payments must be able to land (Stripe
 * connected *and* accepting charges) and the QBO accounting step must be
 * finished, so an enabled tenant can always book what it invoices.
 *
 * Deliberately not part of `deriveInvoicingOnboardingStatus`, which routes the
 * module off the config flags alone. Folding these in there would (a) demote a
 * live tenant to the settings tree the moment an integration broke, stranding
 * its existing invoices, and (b) deadlock the route gate, which fetches only the
 * config — never the settings or QBO connection these read.
 */
export declare function deriveInvoicingEnablePrerequisites(settings: InvoicingSettingsPayload | undefined, isQboConnected: boolean, qboAccountMappingKindOptions: InvoicingQboAccountMappingKindOption[]): InvoicingEnablePrerequisites;
export interface InvoicingSettingsHubView {
    canEnableInvoicing: boolean;
    /**
     * Config-owned lists and fetch state the settings hub renders, folded in so the
     * screen reads this view instead of `getInvoicingConfigView`.
     */
    configFetchState: FetchState;
    dunningScheduleActionOptions: InvoicingDunningActionOption[];
    fieldHelp: InvoicingFieldHelpByCode;
    isEnablingInvoicing: boolean;
    /**
     * Whether the tenant has already enabled invoicing. The enable footer is for
     * tenants that have not, so this — not `canEnableInvoicing` — decides whether
     * it renders at all.
     */
    isInvoicingEnabled: boolean;
    isQboConfigured: boolean;
    isStripeConnected: boolean;
    qboAccountMappingKindOptions: InvoicingQboAccountMappingKindOption[];
    qboCustomerMatchingOptions: InvoicingNamedOption[];
    qboSyncStatusOptions: InvoicingNamedOption[];
    status: string | undefined;
    configError?: ZeniAPIStatus;
}
/**
 * The settings hub's composite of everything it derives from the store: whether
 * to offer Enable Invoicing at all, the in-flight flag for that action, and the
 * two integration prerequisites kept separate so the hub can name the step still
 * outstanding instead of showing a dead button.
 *
 * `isInvoicingEnabled` decides whether the footer renders; `canEnableInvoicing`
 * whether its button is live, and it still requires the onboarding step so the
 * terms cannot be skipped. A tenant partway through therefore sees the footer,
 * disabled and naming what is left, rather than nothing at all.
 *
 * Deliberately not folded into `getInvoicingConfigView`: that selector gates
 * every invoicing route and stays a pure read of the config slice. The settings
 * and QBO slices read here are only fetched once a settings screen is mounted.
 */
export declare const getInvoicingSettingsHubView: (state: RootState) => InvoicingSettingsHubView;
export interface InvoicingQboSettingsFormView {
    accountMappingKindOptions: InvoicingQboAccountMappingKindOption[];
    /** Accounts for the mapping dropdowns, narrowed per kind by the page. */
    accounts: InvoicingAccountingOption[];
    backfillState: FetchStateAndError;
    /** So the screen can fetch only what is missing, without reading the slices. */
    configFetchState: FetchState;
    customerMatchingOptions: InvoicingNamedOption[];
    fieldHelp: InvoicingFieldHelpByCode;
    isLoading: boolean;
    /** The persisted sync toggle — the backfill guard checks that, not the draft. */
    isSyncEnabledSaved: boolean;
    /** The draft the page edits, seeded from the settings response. */
    localData: InvoicingQboSettingsLocalData;
    nestedAccountHierarchy: NestedAccountHierarchyForReport[];
    retryFetchStateByTaskId: Record<string, FetchStateAndError>;
    saveState: FetchStateAndError;
    settingsFetchState: FetchState;
    syncStatusOptions: InvoicingNamedOption[];
    connection?: InvoicingQboConnection;
    syncHealth?: InvoicingQboSyncHealth;
}
/**
 * Bundled view for the QBO configuration page: the draft it edits, the accounts
 * and option lists its dropdowns render, the connection and sync health it
 * reports, and the fetch states that decide between skeleton, form and error.
 *
 * `localData` is the draft once the user has edited, and the settings response
 * before that — so the page has one field to read and CES owns when it becomes
 * available, rather than the page copying settings into local state.
 */
export declare const getInvoicingQboSettingsFormView: (state: RootState) => InvoicingQboSettingsFormView;
export interface InvoicingBrandingFormView {
    dateFormatOptions: InvoicingNamedOption[];
    fieldHelp: InvoicingFieldHelpByCode;
    localData: InvoicingBrandingFormLocalData;
    saveState: FetchStateAndError;
    addressLabel?: string;
    settings?: InvoicingSettingsPayload;
}
/**
 * Bundled view for the branding settings form: the draft `localData` (seeded
 * from the existing settings until the user edits), the business-address label
 * (from the shared Address screen, seeded on load from `address_id`), the raw
 * settings (for the logo/preview), the backend date-format choices and the
 * save fetch state.
 */
export declare const getInvoicingBrandingFormView: (state: RootState) => InvoicingBrandingFormView;