@happyvertical/smrt-planner 0.0.2 → 0.1.1

package/dist/recipes/help/descriptions.json

@@ -156,7 +156,6 @@
   },
   "@happyvertical/smrt-commerce:Contract": {
     "status": "Where the contract stands, for example draft, sent, accepted or completed.",
-    "customerId": "The customer this contract is for.",
     "subtotal": "The contract amount before tax.",
     "taxAmount": "The tax charged on the contract.",
     "totalAmount": "What the customer pays in all, tax included.",
@@ -168,8 +167,7 @@
     "notes": "Anything worth remembering about this contract.",
     "terms": "The conditions agreed with the customer, such as deposits, delivery or payment conditions.",
     "channelId": "Where the contract came from, for example your shop or a marketplace.",
-    "contractType": "The kind of contract: order, estimate, lease, agreement and so on.",
-    "vendorId": "The vendor on the other side, for contracts you buy."
+    "contractType": "The kind of contract: order, estimate, lease, agreement and so on."
   },
   "@happyvertical/smrt-commerce:ContractLineItem": {
     "contractId": "The order, quote or agreement this line belongs to.",

package/dist/recipes/index.d.ts

@@ -41,6 +41,8 @@ export interface RecipeNavTarget {
 }
 /** A recipe's `nav` entries resolved to catalog models; unknown ones are dropped. */
 export declare function recipeNav(recipe: Recipe): RecipeNavTarget[];
+/** Is `key` a keyed nav entry of the model (`/m/<pkg>/<Model>/<key>/`) in any recipe? */
+export declare function hasNavKey(packageId: string, modelName: string, key: string): boolean;
 /**
  * In-app path of a nav entry, without the app query: `/m/<pkg>/<Model>/`, and
  * `/m/<pkg>/<Model>/<key>/` for a keyed entry (the same model shown twice).

package/dist/recipes/index.js

@@ -49,6 +49,12 @@ export function recipeNav(recipe) {
             : [];
     });
 }
+/** Is `key` a keyed nav entry of the model (`/m/<pkg>/<Model>/<key>/`) in any recipe? */
+export function hasNavKey(packageId, modelName, key) {
+    return recipes.some((recipe) => recipeNav(recipe).some((entry) => entry.key === key &&
+        entry.packageId === packageId &&
+        entry.model.name === modelName));
+}
 /**
  * In-app path of a nav entry, without the app query: `/m/<pkg>/<Model>/`, and
  * `/m/<pkg>/<Model>/<key>/` for a keyed entry (the same model shown twice).

package/dist/recipes/plumbing.d.ts

@@ -18,6 +18,13 @@ import type { Catalog, CatalogModel } from '../catalog/types.ts';
  * 4. Tiny lookup list: a name ending `Status` or `Type` with at most three
  *    non-system fields (`AssetStatus`, `PlaceType`, `ProfileType`). Richer
  *    types such as `ContentContributionType` stay features.
+ * 5. Named in {@link PLUMBING_MODELS}: rows the catalog's shape cannot tell
+ *    apart from features. smrt-commerce's money model (smrt#3988) is the
+ *    case: `TaxCode` is a feature (the codes people choose on a line), but
+ *    its `TaxComponent` rates belong to codes, `TaxSettings` is the tenant's
+ *    one settings row (the Settings tab edits its portable part),
+ *    `DocumentTax` is a document's derived tax snapshot and
+ *    `TaxSummaryReport` a materialized report a server host refreshes.
  */
 export declare const JUNCTION_BASES: readonly string[];
 export declare const CHILD_SUFFIXES: readonly string[];
@@ -25,7 +32,11 @@ export declare const LOOKUP_SUFFIXES: readonly string[];
 export declare const LOOKUP_MAX_FIELDS = 3;
 export declare const LINK_MIN_REFS = 2;
 export declare const LINK_MAX_OTHER_FIELDS = 1;
-type ModelShape = Pick<CatalogModel, 'name' | 'fields' | 'extends'>;
+/** Plumbing by name (rule 5), by qualified model id, with its reason. */
+export declare const PLUMBING_MODELS: Readonly<Record<string, string>>;
+type ModelShape = Pick<CatalogModel, 'name' | 'fields' | 'extends'> & {
+    id?: string;
+};
 /** The reason a model is plumbing, or null when it is a feature. */
 export declare function plumbingReason(model: ModelShape): string | null;
 export declare function isPlumbing(model: ModelShape): boolean;
@@ -58,6 +69,21 @@ export interface ChildLink {
  * in no recipe (a Feature) falls back to {@link childModels}.
  */
 export declare function childLinks(catalog: Catalog, recipes: readonly RecipeScope[], modelId: string): ChildLink[];
+/**
+ * Every model whose rows point at the model (or at a class it extends), one
+ * link per reference field, plumbing or not: `Customer` <- `Order.customerId`,
+ * `Quote.customerId`, `Invoice.customerId`; `InventoryLocation` <-
+ * `StockTransfer.fromLocationId` and `.toLocationId`. {@link childLinks} is
+ * the subset that lives inside the record (line items); this is what a
+ * record's view page lists as its related records. Catalog order.
+ */
+export declare function reverseLinks(catalog: Catalog, modelId: string): ChildLink[];
+/**
+ * The records a model's own reference fields point at (`Order.customerId` ->
+ * `Customer`), one per field whose target the catalog knows; the way up from
+ * a record's view page.
+ */
+export declare function forwardLinks(catalog: Catalog, modelId: string): ChildLink[];
 /** Does any recipe give the model a menu entry of its own? */
 export declare function hasNavPage(recipes: readonly RecipeScope[], modelId: string): boolean;
 /**
@@ -67,4 +93,12 @@ export declare function hasNavPage(recipes: readonly RecipeScope[], modelId: str
 export declare function childTitle(childName: string, parentNames: readonly string[]): string;
 /** Names of the model and its STI ancestors, for {@link childTitle}. */
 export declare function lineageNames(catalog: Catalog, modelId: string): string[];
+/**
+ * The priced child records that make up a model's own record (its line
+ * items): the {@link childModels} whose name starts with the model's or an
+ * STI ancestor's (`ContractLineItem` under every Contract, `InvoiceLineItem`
+ * under Invoice), so a Product, which line items also point at, has none.
+ * `isLine` says what a line is (the planner's `isLineModel`).
+ */
+export declare function itemModels(catalog: Catalog, modelId: string, isLine: (model: CatalogModel) => boolean): CatalogModel[];
 export {};

package/dist/recipes/plumbing.js

@@ -17,6 +17,13 @@
  * 4. Tiny lookup list: a name ending `Status` or `Type` with at most three
  *    non-system fields (`AssetStatus`, `PlaceType`, `ProfileType`). Richer
  *    types such as `ContentContributionType` stay features.
+ * 5. Named in {@link PLUMBING_MODELS}: rows the catalog's shape cannot tell
+ *    apart from features. smrt-commerce's money model (smrt#3988) is the
+ *    case: `TaxCode` is a feature (the codes people choose on a line), but
+ *    its `TaxComponent` rates belong to codes, `TaxSettings` is the tenant's
+ *    one settings row (the Settings tab edits its portable part),
+ *    `DocumentTax` is a document's derived tax snapshot and
+ *    `TaxSummaryReport` a materialized report a server host refreshes.
  */
 export const JUNCTION_BASES = [
     'SmrtJunction',
@@ -40,9 +47,19 @@ export const LOOKUP_SUFFIXES = ['Status', 'Type'];
 export const LOOKUP_MAX_FIELDS = 3;
 export const LINK_MIN_REFS = 2;
 export const LINK_MAX_OTHER_FIELDS = 1;
+/** Plumbing by name (rule 5), by qualified model id, with its reason. */
+export const PLUMBING_MODELS = {
+    '@happyvertical/smrt-commerce:TaxComponent': 'lookup',
+    '@happyvertical/smrt-commerce:TaxSettings': 'settings',
+    '@happyvertical/smrt-commerce:DocumentTax': 'snapshot',
+    '@happyvertical/smrt-commerce:TaxSummaryReport': 'report',
+};
 const REF_TYPES = new Set(['foreignKey', 'crossPackageRef']);
 /** The reason a model is plumbing, or null when it is a feature. */
 export function plumbingReason(model) {
+    const named = model.id ? PLUMBING_MODELS[model.id] : undefined;
+    if (named)
+        return named;
     const base = model.extends?.split(':').pop();
     if (base && JUNCTION_BASES.includes(base))
         return 'junction';
@@ -150,6 +167,52 @@ export function childLinks(catalog, recipes, modelId) {
     }
     return [...found.values()];
 }
+/**
+ * Every model whose rows point at the model (or at a class it extends), one
+ * link per reference field, plumbing or not: `Customer` <- `Order.customerId`,
+ * `Quote.customerId`, `Invoice.customerId`; `InventoryLocation` <-
+ * `StockTransfer.fromLocationId` and `.toLocationId`. {@link childLinks} is
+ * the subset that lives inside the record (line items); this is what a
+ * record's view page lists as its related records. Catalog order.
+ */
+export function reverseLinks(catalog, modelId) {
+    const all = catalog.packages.flatMap((p) => p.models);
+    const byId = new Map(all.map((m) => [m.id, m]));
+    const parents = new Set(lineage(byId, modelId));
+    if (!parents.size)
+        return [];
+    const found = [];
+    for (const candidate of all) {
+        if (parents.has(candidate.id))
+            continue;
+        for (const field of candidate.fields) {
+            if (REF_TYPES.has(field.type) &&
+                field.related &&
+                parents.has(qualify(field.related, candidate.id))) {
+                found.push({ model: candidate, fk: field.name });
+            }
+        }
+    }
+    return found;
+}
+/**
+ * The records a model's own reference fields point at (`Order.customerId` ->
+ * `Customer`), one per field whose target the catalog knows; the way up from
+ * a record's view page.
+ */
+export function forwardLinks(catalog, modelId) {
+    const all = catalog.packages.flatMap((p) => p.models);
+    const byId = new Map(all.map((m) => [m.id, m]));
+    const model = byId.get(modelId);
+    if (!model)
+        return [];
+    return model.fields.flatMap((field) => {
+        if (!REF_TYPES.has(field.type) || !field.related)
+            return [];
+        const target = byId.get(qualify(field.related, model.id));
+        return target ? [{ model: target, fk: field.name }] : [];
+    });
+}
 /** Does any recipe give the model a menu entry of its own? */
 export function hasNavPage(recipes, modelId) {
     return recipes.some((r) => r.nav.some((e) => e.model === modelId));
@@ -183,3 +246,14 @@ export function lineageNames(catalog, modelId) {
         return m ? [m.name] : [];
     });
 }
+/**
+ * The priced child records that make up a model's own record (its line
+ * items): the {@link childModels} whose name starts with the model's or an
+ * STI ancestor's (`ContractLineItem` under every Contract, `InvoiceLineItem`
+ * under Invoice), so a Product, which line items also point at, has none.
+ * `isLine` says what a line is (the planner's `isLineModel`).
+ */
+export function itemModels(catalog, modelId, isLine) {
+    const names = lineageNames(catalog, modelId);
+    return childModels(catalog, modelId).filter((child) => isLine(child) && names.some((name) => child.name.startsWith(name)));
+}

package/dist/screens/definition.d.ts

@@ -0,0 +1,35 @@
+/**
+ * The planner's catalog models as the generated record screens take them
+ * (`@happyvertical/smrt-svelte/screens`, smrt#3718): a
+ * `ScreenCollectionDefinition` is the browser-safe collection definition a
+ * SMRT build emits, and the planner has the same facts in `catalog.json`. The
+ * applied recipe options (which fields a view shows, their labels and help)
+ * travel as the `ScreenPolicy`, so a field renders only when the policy lists
+ * it, as on a generated screen.
+ *
+ * The facts the catalog has beyond a generated definition travel as the
+ * field roles' hints: `enum` (a status select, a badge), `format` (`money`
+ * by the planner's `isMoneyField`, `date` for business dates), `display`
+ * (the field a record is named by) and `role: 'items'` on the relationship
+ * edges of line items, so the record page shows them as its line-items table.
+ */
+import type { ScreenCollectionDefinition, ScreenPolicy } from '@happyvertical/smrt-svelte/screens';
+import type { CatalogModel } from '../catalog/types.ts';
+import type { ViewField } from '../recipes/policy.ts';
+/**
+ * The field a record of the model is named by (see `recordName`), when it
+ * has a name of its own: the framework's `title` role. A document (an order)
+ * has none; the field roles find its identifier and the header leads with it.
+ */
+export declare function displayFieldOf(model: CatalogModel): string | undefined;
+/**
+ * The model's own fields (and reference edges) as a screen collection
+ * definition, keyed by its collection name like a generated one.
+ */
+export declare function screenDefinition(model: CatalogModel): ScreenCollectionDefinition;
+/**
+ * The fields a view shows, with the recipe options' labels and help, as the
+ * screens' resolved policy: everything listed is `basic`, in list order, and
+ * a field the applied options hide is simply not in it.
+ */
+export declare function screenPolicy(model: CatalogModel, fields: readonly ViewField[]): ScreenPolicy;

package/dist/screens/definition.js

@@ -0,0 +1,132 @@
+import { catalog, getModelByQualifiedName } from "../catalog/index.js";
+import { isLineModel } from "../data/derived.js";
+import { labelFields } from "../data/display.js";
+import { isMoneyField } from "../data/fakes.js";
+import { itemModels } from "../recipes/plumbing.js";
+const FIELD_TYPES = [
+    'text',
+    'integer',
+    'decimal',
+    'boolean',
+    'datetime',
+    'json',
+    'foreignKey',
+    'crossPackageRef',
+];
+function fieldType(type) {
+    return FIELD_TYPES.includes(type)
+        ? type
+        : 'text';
+}
+/**
+ * A business date is a day, not a moment: `issueDate`, `dueDate`,
+ * `periodStart`. A model that books a time of day (`allDay`: events) keeps
+ * its dates as datetimes, as do `...At` timestamps.
+ */
+const DATE_NAME = /(Date|^date|period(Start|End))$/;
+function dateFormat(model, field) {
+    return field.type === 'datetime' &&
+        !field.system &&
+        DATE_NAME.test(field.name) &&
+        !model.fields.some((f) => f.name === 'allDay')
+        ? 'date'
+        : undefined;
+}
+/**
+ * The field a record of the model is named by (see `recordName`), when it
+ * has a name of its own: the framework's `title` role. A document (an order)
+ * has none; the field roles find its identifier and the header leads with it.
+ */
+export function displayFieldOf(model) {
+    return labelFields(model)[0];
+}
+function fieldDefinition(model, field) {
+    const ui = field.ui ? { ...field.ui } : undefined;
+    const format = isMoneyField(field) ? 'money' : dateFormat(model, field);
+    return {
+        type: fieldType(field.type),
+        required: field.required,
+        nullable: !field.required,
+        ...(field.default !== undefined ? { default: field.default } : {}),
+        ...(field.description ? { description: field.description } : {}),
+        ...(ui ? { ui } : {}),
+        ...(field.enum?.length ? { enum: [...field.enum] } : {}),
+        ...(format ? { format } : {}),
+        ...(displayFieldOf(model) === field.name ? { display: true } : {}),
+    };
+}
+/** A field's `related` as a qualified name, given the model it is declared on. */
+function qualify(related, ownerId) {
+    return related.includes(':')
+        ? related
+        : `${ownerId.slice(0, ownerId.lastIndexOf(':'))}:${related}`;
+}
+/**
+ * Does `model` hold the line items of what `field` points at? A priced child
+ * record (`ContractLineItem`, `InvoiceLineItem`: quantity, unit price,
+ * amount) named after its target (`itemModels`): a line's `contractId` is
+ * its document, its `productId` only what it sells.
+ */
+function isItemsEdge(model, field) {
+    if (!field.related)
+        return false;
+    const target = qualify(field.related, model.id);
+    return itemModels(catalog, target, isLineModel).some((child) => child.id === model.id);
+}
+/** The model's reference fields as the definition's relationship edges. */
+function relationships(model) {
+    return model.fields.flatMap((field) => {
+        if ((field.type !== 'foreignKey' && field.type !== 'crossPackageRef') ||
+            !field.related) {
+            return [];
+        }
+        const target = getModelByQualifiedName(qualify(field.related, model.id));
+        return target
+            ? [
+                {
+                    field: field.name,
+                    kind: field.type === 'crossPackageRef'
+                        ? 'crossPackageRef'
+                        : 'foreignKey',
+                    relatedCollection: target.model.collection,
+                    ...(isItemsEdge(model, field) ? { role: 'items' } : {}),
+                },
+            ]
+            : [];
+    });
+}
+/**
+ * The model's own fields (and reference edges) as a screen collection
+ * definition, keyed by its collection name like a generated one.
+ */
+export function screenDefinition(model) {
+    const edges = relationships(model);
+    return {
+        name: model.collection,
+        objectRef: model.id,
+        className: model.name,
+        idField: 'id',
+        fields: Object.fromEntries(model.fields.map((field) => [field.name, fieldDefinition(model, field)])),
+        ...(edges.length ? { relationships: edges } : {}),
+    };
+}
+/**
+ * The fields a view shows, with the recipe options' labels and help, as the
+ * screens' resolved policy: everything listed is `basic`, in list order, and
+ * a field the applied options hide is simply not in it.
+ */
+export function screenPolicy(model, fields) {
+    return {
+        objectRef: model.id,
+        fields: Object.fromEntries(fields.map((field, order) => [
+            field.name,
+            {
+                visibility: 'basic',
+                label: field.label,
+                help: field.help ?? null,
+                order,
+                required: field.required,
+            },
+        ])),
+    };
+}

package/dist/screens/relations.d.ts

@@ -0,0 +1,17 @@
+import { type ScreenRelation } from '@happyvertical/smrt-svelte/screens';
+import type { Catalog, CatalogModel } from '../catalog/types.ts';
+import type { Recipe } from '../recipes/types.ts';
+export type { ScreenRelation };
+/** The models the visitor's app has: the added recipes' and the features. */
+export declare function appModels(added: readonly Recipe[], features: readonly string[]): Set<string>;
+/** "Customer" for `customerId`, "From location" for `fromLocationId`. */
+export declare function referenceLabel(field: string): string;
+/**
+ * The record screen's relations for `modelId`, children first (catalog
+ * order, confined to `inApp`), then references (every catalog target). A
+ * child pointing at the model through several fields gets one relation per
+ * field, told apart by the field's name.
+ */
+export declare function screenRelations(catalog: Catalog, modelId: string, inApp: ReadonlySet<string>): ScreenRelation[];
+/** The catalog model a relation names, when the catalog has it. */
+export declare function relationModel(catalog: Catalog, relation: ScreenRelation): CatalogModel | undefined;

package/dist/screens/relations.js

@@ -0,0 +1,98 @@
+/**
+ * What a record's view page relates it to, from the catalog's foreign keys
+ * (smrt#3718 record view): `children` are the models whose rows point at the
+ * record (a customer's orders, quotes and invoices), `items` the priced
+ * child records that make up the record itself (an order's line items, from
+ * the plumbing rules' `childModels`), `reference` the records the record
+ * itself points at (an order's customer).
+ * Children count only from models in the visitor's app (an added recipe's
+ * models and the added features); references list every target the catalog
+ * has, so a field pointing outside the app (a customer's Profile) still
+ * shows its record's name. Whether a reference links is the view's call
+ * (`RecordView` links only targets in the app). Generic for every model;
+ * nothing here names one.
+ *
+ * The planner derives these from the catalog rather than through the
+ * framework's `deriveScreenRelations`, which reads a definition's
+ * `relationships` by collection name: the catalog also knows a model's STI
+ * parent (`Order` extends `Contract`), so an order's line items
+ * (`ContractLineItem.contractId`) are its children too, as `childLinks`
+ * already treats them. The shape is the framework's `ScreenRelation`.
+ */
+import { lineItemColumns, relatedColumns, } from '@happyvertical/smrt-svelte/overview';
+import { deriveFieldRoles, } from '@happyvertical/smrt-svelte/screens';
+import { isLineModel } from "../data/derived.js";
+import { humanize } from "../data/format.js";
+import { childTitle, forwardLinks, itemModels, lineageNames, reverseLinks, } from "../recipes/plumbing.js";
+import { screenDefinition } from "./definition.js";
+/** The models the visitor's app has: the added recipes' and the features. */
+export function appModels(added, features) {
+    const ids = new Set(features);
+    for (const recipe of added)
+        for (const id of recipe.models)
+            ids.add(id);
+    return ids;
+}
+/** "Customer" for `customerId`, "From location" for `fromLocationId`. */
+export function referenceLabel(field) {
+    return humanize(field.replace(/_?id$/i, '') || field);
+}
+/**
+ * The record screen's relations for `modelId`, children first (catalog
+ * order, confined to `inApp`), then references (every catalog target). A
+ * child pointing at the model through several fields gets one relation per
+ * field, told apart by the field's name.
+ */
+export function screenRelations(catalog, modelId, inApp) {
+    const parents = lineageNames(catalog, modelId);
+    const children = reverseLinks(catalog, modelId).filter((link) => link.model.exposed && inApp.has(link.model.id));
+    // Line items live inside the record: its line-items table, not a tab.
+    const items = new Set(itemModels(catalog, modelId, isLineModel).map((m) => m.id));
+    const perModel = new Map();
+    for (const link of children) {
+        perModel.set(link.model.id, (perModel.get(link.model.id) ?? 0) + 1);
+    }
+    const relations = children.map((link) => {
+        const kind = items.has(link.model.id) ? 'items' : 'children';
+        // The table columns by role, as the framework's `deriveScreenRelations`
+        // attaches them: a line-items table, or a related-records tab.
+        const definition = screenDefinition(link.model);
+        const roles = deriveFieldRoles(definition);
+        const exclude = [link.fk];
+        return {
+            model: link.model.id,
+            field: link.fk,
+            label: (perModel.get(link.model.id) ?? 0) > 1
+                ? `${childTitle(link.model.name, parents)} (${referenceLabel(link.fk).toLowerCase()})`
+                : childTitle(link.model.name, parents),
+            kind,
+            columns: kind === 'items'
+                ? lineItemColumns(definition, roles, { exclude })
+                : // Identifier, status, date, party and the amount: the framework's
+                    // default four would drop the amount for a second party.
+                    relatedColumns(definition, roles, { exclude, max: 5 }),
+            // Lines keep the order they were entered in.
+            ...(kind === 'items' && 'sortOrder' in definition.fields
+                ? { sort: 'sortOrder' }
+                : {}),
+        };
+    });
+    for (const link of forwardLinks(catalog, modelId)) {
+        relations.push({
+            model: link.model.id,
+            field: link.fk,
+            label: referenceLabel(link.fk),
+            kind: 'reference',
+        });
+    }
+    return relations;
+}
+/** The catalog model a relation names, when the catalog has it. */
+export function relationModel(catalog, relation) {
+    for (const pkg of catalog.packages) {
+        const model = pkg.models.find((m) => m.id === relation.model);
+        if (model)
+            return model;
+    }
+    return undefined;
+}

package/dist/screens/totals.d.ts

@@ -0,0 +1,37 @@
+/**
+ * A document's totals for the record page's `line-items` widget, on
+ * smrt-commerce's money model.
+ *
+ * - An issued document (it has left `draft`) is frozen: `storedDocumentTotals`
+ *   hands the widget its stored figures as smrt-svelte's
+ *   `StoredLineItemsTotals` (subtotal, the informational discount, tax,
+ *   total, pricing mode, rounding scope and one row per tax component, e.g.
+ *   GST and PST apart), which it shows without recalculating.
+ * - A draft computes live: `documentTotals` is the record's own subtotal /
+ *   tax / total by the framework's field roles, which the widget compares with
+ *   its lines and flags when they disagree.
+ */
+import type { LineItemsTotals } from '@happyvertical/smrt-svelte/overview';
+import { type RecordScreenProps } from '@happyvertical/smrt-svelte/screens';
+import type { CatalogModel } from '../catalog/types.ts';
+type Row = Readonly<Record<string, unknown>>;
+/**
+ * smrt-svelte's `StoredLineItemsTotals`, which its entry points do not export
+ * by name (smrt#4023); it is what `RecordScreen.lineItemStoredTotals` returns.
+ */
+export type StoredLineItemsTotals = NonNullable<ReturnType<NonNullable<RecordScreenProps['lineItemStoredTotals']>>>;
+/**
+ * The live totals of a draft by role (plus its `lineAmountType`); `undefined`
+ * when it has none of them. The informational `discountTotal` is passed like
+ * the rest: the widget shows it as included and never subtracts it (smrt#4014).
+ */
+export declare function documentTotals(model: CatalogModel, record: Row): LineItemsTotals | undefined;
+/** Has the document left `draft`, freezing its money? */
+export declare function isIssued(model: CatalogModel, record: Row): boolean;
+/**
+ * An issued document's frozen money as the widget's stored totals: its own
+ * header figures and its lines' stored tax snapshots summed per component.
+ * `undefined` for a draft or a model without the money model's header.
+ */
+export declare function storedDocumentTotals(model: CatalogModel, record: Row, lines: readonly Row[]): StoredLineItemsTotals | undefined;
+export {};

package/dist/screens/totals.js

@@ -0,0 +1,65 @@
+import { deriveFieldRoles, recordTotals, } from '@happyvertical/smrt-svelte/screens';
+import { documentLineAmountType, documentRoundingScope, } from "../data/derived.js";
+import { storedTaxRows } from "../data/money.js";
+import { screenDefinition } from "./definition.js";
+const minor = (value) => typeof value === 'number' && Number.isSafeInteger(value) ? value : null;
+const hasField = (model, name) => model.fields.some((f) => f.name === name);
+/**
+ * The live totals of a draft by role (plus its `lineAmountType`); `undefined`
+ * when it has none of them. The informational `discountTotal` is passed like
+ * the rest: the widget shows it as included and never subtracts it (smrt#4014).
+ */
+export function documentTotals(model, record) {
+    const roles = deriveFieldRoles(screenDefinition(model));
+    const totals = recordTotals(record, roles);
+    return Object.values(totals).some((v) => minor(v) !== null)
+        ? totals
+        : undefined;
+}
+/** Has the document left `draft`, freezing its money? */
+export function isIssued(model, record) {
+    const status = model.fields.find((f) => f.name === 'status');
+    return (Boolean(status?.enum?.includes('draft')) &&
+        typeof record.status === 'string' &&
+        record.status !== '' &&
+        record.status !== 'draft');
+}
+/**
+ * An issued document's frozen money as the widget's stored totals: its own
+ * header figures and its lines' stored tax snapshots summed per component.
+ * `undefined` for a draft or a model without the money model's header.
+ */
+export function storedDocumentTotals(model, record, lines) {
+    if (!isIssued(model, record))
+        return undefined;
+    if (!['subtotal', 'taxAmount', 'totalAmount', 'discountTotal'].every((n) => hasField(model, n))) {
+        return undefined;
+    }
+    const subtotal = minor(record.subtotal);
+    const tax = minor(record.taxAmount);
+    const total = minor(record.totalAmount);
+    const discount = minor(record.discountTotal) ?? 0;
+    if (subtotal === null || tax === null || total === null)
+        return undefined;
+    const lineAmountType = documentLineAmountType(record, 'exclusive');
+    return {
+        subtotal,
+        discount,
+        tax,
+        total,
+        lineAmountType,
+        roundingScope: documentRoundingScope(record, 'line'),
+        showNetSubtotal: lineAmountType === 'inclusive',
+        taxes: storedTaxRows(lines, lineAmountType).flatMap((row) => row.taxComponentId
+            ? [
+                {
+                    taxComponentId: row.taxComponentId,
+                    name: row.name,
+                    percent: row.percent,
+                    taxable: row.taxable,
+                    tax: row.tax,
+                },
+            ]
+            : []),
+    };
+}

package/dist/sections/info.d.ts

@@ -13,4 +13,4 @@ export interface SectionInfo {
  */
 export declare function sectionInfo(id: string): SectionInfo;
 /** The title of a section page: its label once the layout has resolved, never the raw id. */
-export declare function sectionTitle(heading: string | null | undefined): string;
+export declare function sectionTitle(heading: string | null | undefined, fallback?: string): string;

package/dist/sections/info.js

@@ -34,6 +34,6 @@ export function sectionInfo(id) {
     return description ? { description } : {};
 }
 /** The title of a section page: its label once the layout has resolved, never the raw id. */
-export function sectionTitle(heading) {
-    return heading?.trim() || 'Planner';
+export function sectionTitle(heading, fallback = 'Planner') {
+    return heading?.trim() || fallback;
 }

package/dist/settings/app-settings.d.ts

@@ -14,9 +14,25 @@ export interface AppSettings {
     taxRate: number;
     /** Default payment terms; empty means unset. */
     paymentTerms: string;
+    /**
+     * New documents' prices include tax (`lineAmountType: 'inclusive'`: a
+     * line's amount is the gross and tax is backed out of it); otherwise
+     * prices exclude tax (`'exclusive'`: a line's amount is its net).
+     */
+    pricesIncludeTax: boolean;
+    /** Whether tax rounds per line or once per document (`taxRoundingScope`). */
+    taxRounding: TaxRounding;
 }
+export type TaxRounding = 'line' | 'document';
+export declare const TAX_ROUNDINGS: readonly TaxRounding[];
 export declare const DEFAULT_SETTINGS: Readonly<AppSettings>;
-/** Which model fields each setting is the default of (the single source). */
+/**
+ * Which model fields each setting is the default of (the single source). The
+ * money settings name the same fields as smrt-core's
+ * `COMMERCE_SETTING_TARGETS`: `pricesIncludeTax` is Invoice and Contract
+ * `lineAmountType` (`'inclusive'` / `'exclusive'`), `taxRounding` their
+ * `taxRoundingScope`.
+ */
 export declare const SETTING_TARGETS: Readonly<Record<keyof AppSettings, readonly {
     model: string;
     field: string;