# @tailor-platform/erp-kit ## 0.59.0 ### Minor Changes - c89874d: **BREAKING** Regenerate the account-receivable error classes from the module docs. Error codes are unchanged, but class names lose the `Ar` prefix (`ArDocumentNotFoundError` becomes `DocumentNotFoundError`) and some error messages now follow the doc wording. - 26c1695: Enable Oxlint's `typescript/no-deprecated` rule as an error in erp-kit's own lint config and in the shared `@tailor-platform/erp-kit/oxlint/{module,backend,frontend}` configs, so calling a `@deprecated`-tagged API (SDK or otherwise) now fails lint instead of only showing a strikethrough in the editor. This also applies to scaffolded module/backend/frontend projects and, transitively, to existing consumer projects that extend the shared config — a project with an existing deprecated-API call will start failing lint after picking up this version. Two deprecated-Zod-API usages already in erp-kit and its ERP app template (`z.string().datetime()`, `z.ZodIssueCode.custom`) were migrated to their non-deprecated replacements as part of this change; the intentionally-still-callable `setBaseCurrency` deprecation stub is exempted via a scoped lint override / inline suppression rather than fixed, since it exists specifically to keep returning a deprecation error to callers. - bd96431: Add a header-level transaction currency to `PurchaseOrder`. - **BREAKING** `PurchaseOrder` gains a required `currencyId` column, and `createPurchaseOrder` takes it as a new input. The kit does not handle FX, so the domain rejects a currency that is not the company's base currency with `PURCHASE_CURRENCY_MISMATCH`, and a missing company with `PURCHASE_COMPANY_NOT_FOUND`. - **BREAKING** The purchase module's `defineModule` requires `primitives.db.currency`. - 6bd831b: Remove the `primitives` module's `setBaseCurrency` command. It had already been fully deprecated to a no-op that only ever returned `SetBaseCurrencyDeprecatedError`, directing callers to the organization module's company-level base currency assignment instead; no code path used it for anything else. **BREAKING** `setBaseCurrency` is no longer exported from the `primitives` module's command set. Callers were already unable to use it for anything beyond receiving a deprecation error, so this removes a command that could not previously succeed. - 21053aa: Add `SalesItem` to the sales module. It is a 1:1 record for an item-management item, keyed by `itemId`, managed with `createSalesItem` / `updateSalesItem` / `deleteSalesItem`. - **BREAKING** `requiresPhysicalFulfillment` is no longer accepted on sales order line input. It is resolved from the line item's `SalesItem` and frozen onto the line. - **BREAKING** Selling an item now requires a `SalesItem`. The sales order commands reject items without one with `SALES_ITEM_NOT_SELLABLE`. - **BREAKING** A confirmed line's fulfillment expectation can no longer be amended. Use REMOVE + ADD to re-resolve it. - 5831a7a: Move the transaction currency from `SalesOrderLine` to the `SalesOrder` header. - **BREAKING** `SalesOrder` gains a required `currencyId` column and `SalesOrderLine` loses its own. `createSalesOrder` takes `currencyId` on the header, and the line inputs of `createSalesOrder`, `updateSalesOrder`, and `amendConfirmedSalesOrder` no longer accept it. The kit does not handle FX, so the domain rejects a currency that is not the company's base currency with `SALES_CURRENCY_MISMATCH`, and a missing company with `SALES_COMPANY_NOT_FOUND`. - **BREAKING** The sales module's `defineModule` requires `organization.queries.getCompany`. - c7a778f: Simplify the sales order fields. - **BREAKING** `SalesOrder` drops the unused `paymentTermId` / `paymentTermSnapshot` / `requestedShipDate` columns and `SalesOrderLine` drops the unused `billingPolicy` / `requestedShipDate` columns. - **BREAKING** The order addresses are renamed from `shippingAddressSnapshot` / `billingAddressSnapshot` to `shippingAddress` / `billingAddress` and stored as plain text instead of serialized JSON. - 773584d: Apply the domain / repository / command layering (`docs/module-ddd-practices.md`) to the inbound-shipment and outbound-shipment modules. - **BREAKING** All shipment commands return ids only: `{ inboundShipmentId }` / `{ outboundShipmentId }`. Read data through the shipment queries - **BREAKING** Creating a shipment now validates the referenced items and storage locations before the line quantity invariants, so an input with both problems surfaces the master-data error first - 2e938b7: Add an optional default expense account to supplier accounts, including validation, scaffold UI support, and non-PO invoice defaults. ### Patch Changes - d4632ca: Restore automatic AppShell DataTable metadata generation in the ERP scaffold with `@tailor-platform/app-shell-sdk-plugin` 0.1.1, which supports the SDK 2.x table and relation APIs. ## 0.58.0 ### Minor Changes - 9b16329: Give apps a canonical directory structure in the structure check, mirroring what #741 did for modules (affects `erp-kit verify` and `internal measure structure`). `measureApps` previously only checked that `backend/` and `frontend/` existed. A directory is required only where some part of the app flow reads, writes or cross-checks it — being present in every real app is not on its own a reason: | directory | required because | | --- | --- | | `docs/actor/` | `app sync-check` pairs each doc with an actor in the e2e user fixture, both ways | | `docs/business-flow/` | `app generate code` reads its story docs; the story-test-case and e2e-scenario sync-checks use them as the doc side | | `docs/resolver/` | input to `app generate code`; sync-check pairs it 1:1 with `backend/src/resolver/` | | `docs/screen/` | `app sync-check` pairs each doc with an e2e page object | | `backend/src/`, `frontend/src/` | where both tsconfigs point (`"@/*": ["./src/*"]`, `include: ["src"]`), and the parent of every layer below | | `backend/src/resolver/` | output of `app generate code`; the code side of the resolver sync-check | | `backend/src/tests/` | holds `story/`, the test side of the story-test-case sync-check | | `frontend/src/components/` | `erp-kit verify` requires a co-located test for every file under it | | `frontend/src/pages/` | the impl-frontend step writes one directory per screen here; impl-review checks `pages/**/page.tsx` against the screen docs | | `frontend/src/graphql/` | the scaffold's `generate-graphql` script writes `graphql/generated/schema.graphql`, and `tsconfig.app.json` points gql.tada at that path — typecheck cannot run without it | | `frontend/e2e/` | the code side that the actor, screen and e2e-scenario sync-checks pair those `docs/` layers with; the impl-frontend step writes its `tests/`, `fixtures/` and `pages/` | `frontend/src/lib/` is **not** required. It exists in every real app, but only holds whatever helpers an app happens to need and nothing in the flow refers to it. Only the app root restricts what else may exist: a directory there outside `backend`/`frontend`/`docs` is reported as `unexpected-dir`, mirroring the module side. The nested rules only check that their required layers are present. Apps legitimately add their own directories — `i18n/`, `features/`, per-domain backend layers, and hand-written documentation next to the generated docs it describes — and none of that breaks anything. Layer names are read off `APP_PATHS`, the same constant the generators and sync-checks use, so renaming a layer there carries over. Only the layer name follows — the parent path is written out in the rule itself. Also: the naming rule tree carried its own `^(backend|frontend|e2e|docs)$` matcher on app children, which decided the same question as the new allow-list and disagreed with it about `e2e/`. Keeping both would report every non-canonical dir twice, once as `naming-violation` and once as `unexpected-dir`, so the matcher is removed and the allow-list is the only place that decides app-root shape. An app-root `e2e/` is no longer accepted — e2e tests belong in `frontend/e2e/`. Consumers will start seeing verify failures for apps that drift from this shape. The most likely one is a layer left pluralised by the 0.31.0 singular-naming migration (`docs/actors`, `backend/src/resolvers`): rename it to the singular form. Those are not cosmetic — the flow globs the singular path, so a `docs/actors` directory means `erp-kit app check` validates no actor docs at all while still exiting 0, and a `backend/src/resolvers` directory means every resolver doc is reported as having no implementation. A missing parent short-circuits its nested rules, so an app without `docs/` reports one violation rather than one per layer. Every rule root is itself required by an earlier rule, so a missing directory always surfaces exactly once instead of silently disabling the checks below it. - 4a05d69: - Add company-scoped Customer Account and Supplier Account aggregates with independent lifecycles, account names, preferred currencies, and purpose-specific address and bank-account usages - Add partner-directory and account-management queries, commands, resolvers, and ERP scaffold screens for managing multiple customer and supplier accounts per Business Partner - Improve account reference validation by loading the owning Business Partner aggregate under a lock before creating or updating account usages - Update ERP scaffold seeds, generated types, forms, detail pages, and integration coverage for the account-based Business Partner model Breaking changes: - Refactor sales, purchasing, receivables, payables, and payment workflows to reference Customer Account or Supplier Account IDs instead of Business Partner IDs while exposing account and partner lifecycle states separately - Remove obsolete Business Partner role, contact-person, identification, activation, and unused query APIs; consumers using these commands, queries, types, or permission scopes must migrate to the new account-based model - Remove the IBAN and SWIFT fields from partner bank accounts; consumers must migrate any stored values before deploying the updated schema - 6c25e14: Remove the purchase module's requisition and supplier-pricing subdomains — 17 commands, 3 queries and 5 db types that no app referenced. Breaking changes: - `purchase.db` loses `purchaseRequisition`, `purchaseRequisitionLine`, `purchaseRequisitionLineAllocation`, `purchasePriceList` and `purchasePriceRule`. Consumers that deployed these tables will see them dropped on the next `tailor deploy` — export the data first if it needs to be kept. - The `purchase:purchaseRequisition` and `purchase:purchasePricing` permission scopes no longer exist. Drop them from any role or user permission list. - `defineModule` no longer takes field extensions for the removed tables, and its `primitives` parameter narrows to `db: { unit }`. - 6c60526: Add `PurchaseItem` to the purchase module and resolve a purchase order line's `requiresPhysicalReceipt` from it instead of from line input. `PurchaseItem` is a 1:1 record for an item-management item; its existence is the decision that the item may be procured, and it owns the purchasing defaults an order line freezes. It is managed with `createPurchaseItem` / `updatePurchaseItem` / `deletePurchaseItem`, keyed by `itemId`. - **BREAKING** `requiresPhysicalReceipt` is no longer accepted on purchase order line input. It is resolved from the line item's `PurchaseItem` and frozen onto the line by `createPurchaseOrder`, `updatePurchaseOrder`, and `amendOrderedPurchaseOrder`. The `PurchaseOrderLine.requiresPhysicalReceipt` column is unchanged, so receipt tracking and invoice matching read the same value as before - **BREAKING** Ordering an item now requires a `PurchaseItem`; the commands above and `approvePurchaseOrder` reject items without one with `PURCHASE_ITEM_NOT_PURCHASABLE`. Existing apps must create a `PurchaseItem` for every item they purchase - **BREAKING** An ordered line's receipt expectation can no longer be amended — it belongs to the item's purchasing record; use REMOVE + ADD to re-resolve it - c559dae: Remove the sales module's channel, listing and customer-pricing subdomains — 21 commands, 11 queries and 6 db types that no app referenced. Breaking changes: - `sales.db` loses `channel`, `listing`, `salesPriceList`, `salesPriceRule`, `channelOrder` and `channelOrderLine`. Consumers that deployed these tables will see them dropped on the next `tailor deploy` — export the data first if it needs to be kept. - `SalesOrder.channelId` and `SalesOrderLine.matchedPriceRuleId` go with the tables they referenced, and `listSalesOrders` loses its `channelId` filter. `SalesOrderLine.priceSnapshot` goes too — it held the matched rule and price list behind a line price, which no longer exist. - The `sales:marketplace` and `sales:salesPricing` permission scopes no longer exist. Drop them from any role or user permission list. - `defineModule` no longer takes field extensions for the removed tables, and its `organization` and `primitives` parameters narrow to `db` only — no remaining command calls `getCompany` or `getCurrency`. - ea1a6e4: Apply the domain / repository / command layering to the sales module (`SalesOrder`). - **BREAKING** All sales commands return ids only: `{ salesOrderId }` (amendment additionally returns `{ revisionId }`, the recalculate commands return `{ salesOrderIds }`). Read data through the sales queries - **BREAKING** Creating a sales order with no lines now fails with `EMPTY_ORDER_NOT_ALLOWED` instead of `INVALID_ORDER_LINE`, matching the update and submit invariant - **BREAKING** Amending a confirmed sales order now validates added lines with the same policy as create: the item must be `ACTIVE` (`ITEM_NOT_ACTIVE`) and belong to the order's company (`CROSS_COMPANY_REFERENCE`), not merely exist - f4735ee: Make the region of per-PR test workspaces configurable in the shipped CI templates. `erp-kit-get-or-create-workspace` hardcoded `--region asia-northeast`, so a consumer whose production workspaces live in `us-west` ran its PR tests in a different region — diverging latency, data-residency posture, and any region-scoped org or folder quotas from what it actually ships. The interactive deploy guide already asked for the region, so the automated and manual paths disagreed. The action now takes a `region` input (default `asia-northeast`, so existing consumers need no migration), driven by a new `ERP_KIT_WORKSPACE_REGION` repo variable in `erp-kit-test-workspace-app.yml`. Region applies only when a workspace is created; `erp-kit-deploy` and `erp-kit-seed` take a workspace ID and are region-agnostic. Changing the variable therefore affects only workspaces created after the change — an existing `--test-pr` is reused wherever it already is. ### Patch Changes - 1e0a661: Regenerate every `tailor.d.ts` / `generated/*.ts` file (in-package modules and the `erp` / `user-management` scaffold templates) against the current `@tailor-platform/sdk` / `@tailor-platform/sdk-plugin-seed` so the checked-in artifacts stop drifting from what `tailor generate` actually produces: - Seed `seed/data/*.schema.ts` files now `export` their `hook` and pass the TailorDB type as `createStandardSchema`'s third argument, matching `@tailor-platform/sdk-plugin-seed` 0.2.x. Without this, `tailor seed fill` failed immediately in a freshly scaffolded app with "does not export `hook`. Run `tailor generate` to regenerate the seed schema files.", and `tailor seed validate` silently skipped each type's own `validate` checks. - `SalesOrderFieldChange` / `SalesOrderRevision` (added by the sales order amendment feature) now have their seed schema/data files and `kysely-tailordb.ts` entries, and `JournalEntry.sourceDocumentType` includes `BANK_RECONCILIATION`. - Several modules' `updatedAt: Timestamp | null` is corrected to `Generated` (TailorDB always populates it), and `tailor.d.ts` picks up the `AuthNamespaceNameRegistry` augmentation. Test fixtures that relied on the stale `null` type are updated to set `updatedAt` alongside `createdAt`. - Both scaffold templates gain a `seed:fill` script (matching what `tailor generate` now scaffolds), and their `seed` script switches to `tailor seed apply --upsert` now that every TailorDB row (`UserRole` included) carries a stable `id`. - 594efb9: Fix `module generate code` and `app generate code` scaffolding stubs that could silently ship to production without ever being implemented. `renderCommandStub` and `renderQueryStub` returned `ok({})` / `{}` next to a `// TODO: implement` comment, so an unimplemented command or query passed its own generated test and lint without complaint. Both now `throw` instead, so the generated test fails until the stub is actually implemented. `renderCommandTestStub` embedded the placeholder as a literal permission string (`permissions: ["TODO:${name}"]`) rather than a comment — if that string reached production it would fail every permission check with no warning at write time. It now throws from an IIFE instead of returning a placeholder value. `renderResolverStub`'s transaction body and `renderStoryTestStub`'s generated `it()` blocks had the same silent-success shape (`return {}` / an empty test body with no assertions); both now throw for the same reason. - 5614236: Fix `erp-kit module sync-check` crashing with `ENOENT` when `--path` is given an absolute path instead of a relative one. The model and test-case checks build fast-glob patterns from the raw `--path` value, so a match returned by fast-glob is itself absolute whenever `--path` was absolute. That match was then re-joined with `cwd` via `path.join`, which (unlike `path.resolve`) does not special-case an already-absolute second argument — the two absolute paths were concatenated into a nonexistent path and reading it threw `ENOENT`. Both checks now use `path.resolve`, which discards the base when the second argument is already absolute. ## 0.57.0 ### Minor Changes - 1120752: Refactor `amendOrderedPurchaseOrder` and the purchase-order recalculation commands into the domain / repository / command layering; revisions are now part of the PurchaseOrder aggregate. - **BREAKING** Purchase commands return ids only: `amendOrderedPurchaseOrder` returns `{ purchaseOrderId }`, the recalculation commands return `{ purchaseOrderIds }`. Read order data through the purchase queries - **BREAKING** The inbound-shipment `defineModule` requires `purchase.queries` with `listPurchaseOrderLinesForMatching` - **BREAKING** Amendment `addLines` require an ACTIVE item ### Patch Changes - 59c54c3: Reproduce the full Tailor Platform ERP Kit License text in the package README. npmjs.com renders only the README — the bundled `LICENSE` file is never shown and the sidebar's `SEE LICENSE IN LICENSE` is plain text — so the terms were unreachable from the package page. ## 0.56.0 ### Minor Changes - b8c06c8: Relicense from MIT to the Tailor Platform ERP Kit License (proprietary). `package.json` now declares `SEE LICENSE IN LICENSE`; use of this package requires a separate written agreement with Tailor. Versions published up to 0.55.1 remain available under MIT. ## 0.55.1 ### Patch Changes - 0fdd8ca: - Update `@changesets/cli` to v3 and `changesets/action` to v2 ## 0.55.0 ### Minor Changes - c70292c: - Add `shift-schedule` module — the planned side of work (シフト・勤務予定), the counterpart to the actuals `time-tracking` already owns. It defines reusable シフトパターン (`ShiftPattern`), the シフト表 period that is confirmed as a whole (`ShiftSchedule`, DRAFT → CONFIRMED), the concrete slots placed on dates within it (`Shift`), and the placements that staff them (`ShiftPlacement`). Patterns and shifts both carry ordered `segments`, so 中抜け is a genuine multi-segment shift rather than a flag, and 通し / 宿直 / 応援 / open shifts fall out of the same shape - Staffing is resolved only through `ShiftPlacement`: a `Shift` names nobody, so an open shift is simply one no ACTIVE placement references. Placements are superseded (swap) or cancelled (release) rather than deleted, so a confirmed シフト表 reads back as "who was planned here, and when did that change". `workforce.queries.getAssignment` is injected into the placement commands to verify the Assignment is effective on the shift's date — an invariant shiftSchedule cannot enforce with a join - Include `getShiftVariance` — the module-owned planned-vs-actual variance classification (遅刻 / 早退 / 超過 / 未出勤) computed from the planned segments and the `time-tracking` actuals the caller passes in; shiftSchedule never writes actuals - Every shift-schedule table is consumer-extensible: `defineModule` takes a field generic per table (`shiftSchedule`, `shift`, `shiftPattern`, `shiftPlacement`), and the commands writing them accept the matching custom fields — per entry for the bulk commands - Add the effective-dated 所定 planned-time baseline per `Assignment` (`WorkSchedule`) to the **workforce** module, with `createWorkSchedule` / `updateWorkSchedule` / `endWorkSchedule` and `getWorkSchedule` / `getWorkScheduleAsOf` / `listWorkSchedulesByAssignment` / `listActiveWorkSchedules`. It belongs with the employment facts it is one of — every Assignment has a 所定 regardless of whether shifts are planned for it, and the consumers of the baseline (overtime calculation, leave valuation) resolve it through workforce. `defineModule` takes a `workSchedule` field generic and the commands carry custom fields forward across generations - Keep `WorkSchedule` regime-neutral: it holds only the scheduled daily/weekly minutes. Employment-regime classification comes from workforce `WorkRegime`, while regime- and country-specific configuration — a flex core-time band, Japanese variable-working clearing periods, deemed hours — belongs in the consuming app through custom fields and app-owned models - 8c07fcb: Expose custom fields for leave-management `AccrualPlan` definitions and persist them through create and effective-dated update commands. Add an application eligibility evaluator seam to the anniversary grant batch. Consumers can evaluate jurisdiction- or company-specific conditions stored in custom fields, reject a candidate, report it as not evaluable for retry, or override the generic proposed grant amount without copying the batch. An overridden amount must be a non-negative half-day increment within the plan's `annualCapDays`; an out-of-range amount counts the candidate as failed instead of being clamped. The evaluator is handed the effective plan row, so type its custom fields with `TailorDBSelectable` from `@tailor-platform/sdk/kysely` rather than the create-input shape — a row carries every column, and an unset optional field reads as `null`, not `undefined`. Behaviour change: `createAccrualPlan` / `updateAccrualPlan` now reject a `grantCondition.type` outside `NONE` / `MIN_WORKED_DAYS` with `INVALID_GRANT_CONDITION`, instead of storing an unrecognized runtime value. Jurisdiction-specific gates are expressed as custom fields read by the eligibility evaluator. - 9b9438b: - **BREAKING** `createContext` no longer invents an actor for an anonymous caller. It returns a `CallerContext`, whose `actorId` is `null` when there is no caller, and it decides nothing about whether the call is allowed — that belongs to the resolver's `permission` in `tailor.config.ts` and to each command's own gate. Resolvers call it exactly as before: ```ts body: async (context) => { const ctx = createContext(context); // ... pass `ctx` to erp-kit commands }, ``` - Previously an anonymous caller got a context whose `actorId` was the nil UUID `00000000-0000-0000-0000-000000000000`. That is the platform's internal anonymous principal id, which both the function runtime and the SDK deliberately normalize to `null` before it reaches user code; erp-kit was re-materializing a value that had already been erased twice. - The `?? context.caller` fallback is gone and `invoker` is required on the argument type. It dated from the release that introduced `invoker`; under SDK v2 the resolver wrapper always injects `invoker` and leaves it `null` only for an anonymous call — the same case in which `caller` is `null` too. - **BREAKING** `defineCommand` rejects a caller with no actor before the implementation runs, returning the new `UnauthenticatedError` (`code: "UNAUTHENTICATED"`, exported from `@tailor-platform/erp-kit/core`). A command attributes its work to an actor — audit columns take the id — so there is nothing to run as without one. A resolver switching on a command's error code needs a `case` for it, beside the one it already has for `INSUFFICIENT_PERMISSION`: ```ts case "UNAUTHENTICATED": throw new DomainError("Authentication is required"); ``` A command implementation still receives `CommandContext` with `actorId: string`, so the places that read `ctx.actorId` are unchanged. - **BREAKING** A query implementation receives `CallerContext` instead of `QueryContext`. Queries carry no permission gate of their own, so nothing narrows the actor for them, and a query that scopes its result to the caller has to say what an absent actor means. erp-kit's notification queries return `UnauthenticatedError`, since every result they produce is the caller's own. The permission-gated form of `defineQuery` is unaffected — its gate rejects an absent actor, and its implementation still receives `QueryContext`. - f7c8279: - **BREAKING** Value goods receipts at the purchase-order price effective at posting time: `postInboundShipment` now derives each line's unit cost from the linked `PurchaseOrderLine.unitPrice` (converted to the primary unit via `unitConversionRate`), instead of trusting a caller-supplied snapshot taken at creation - `unitCost` is removed from `CreateInboundShipmentInput` / `UpdateInboundShipmentInput`, along with the `INBOUND_SHIPMENT_INVALID_UNIT_COST` error; `InboundShipmentLine.unitCost` stays null while DRAFT and is written at posting - `recalculatePurchaseOrderReceiptStatus` additionally returns the updated `purchaseOrderLines` - dcc83d7: Post invoice-versus-order price differences through a dedicated invoice price variance clearing account instead of the accrual account, so the accrual carries only order-priced uninvoiced receipts: - **BREAKING** `ValuationPolicy` takes a new required `invoicePriceVarianceAccountId`, and `invoiceCostVarianceAccountId` is renamed to `consumedPriceVarianceAccountId` (it expenses variances on already-consumed AVERAGE stock, not invoice differences) - **BREAKING** `postAcquisitionCostAdjustment` requires `varianceKind`, naming the clearing account the declared amounts wash against: `INVOICE_PRICE` (billed price differed from the order price) or `ORDER_PRICE` (the order price changed for quantity the accrual still carries). `AccountPayableDocument` postings declare `INVOICE_PRICE`; order reprices and cancellation compensations declare `ORDER_PRICE`. `AcquisitionCostAdjustment` rows carry a required `kind` (the variance kinds plus `REDISTRIBUTION` for the zero-amount rows receipt postings anchor), and allocations record the `varianceKind` they distribute - **BREAKING** A receipt-required purchase-order AP line now derives two distributions: an `ACCRUAL` row at quantity × order price and a signed `INVOICE_PRICE_VARIANCE` row (new `distributionType` value) for the remainder, so the AP journal relieves the accrual at the price the receipt accrued. `registerAccountPayableDocument` re-derives the split against the price it matches - 9b9438b: - **BREAKING** Require `@tailor-platform/sdk` 2.1.0 or newer (`peerDependencies` and the `erp-kit measure` compat range both move to `^2.1.0`), and close the scaffold's resolver namespace to anonymous callers with the namespace-level `defaultPermission` that 2.1.0 adds: ```ts resolver: { "main-resolver": { files: [`./src/resolver/**/*.ts`], defaultPermission: [{ conditions: [[{ user: "_loggedIn" }, "=", true]], permit: true }], }, }, ``` - A resolver that declares no `permission` of its own previously had no guard generated at all, and the gateway issues an anonymous JWT rather than rejecting an unauthenticated request, so anonymous callers reached `body` and were stopped only by the permission check inside each command. The namespace default now rejects them before `body` runs. - A resolver that is public by design opts out with `permission: "allowAnonymous"`; a resolver's own `permission` replaces the namespace default rather than merging with it. - Existing apps are unaffected until they add `defaultPermission` to their own `tailor.config.ts`. Scaffolds generated from this version have it from the start. - f0486da: - **BREAKING** Require `@tailor-platform/sdk` 2.2.0 or later; the `peerDependencies` entry is now `^2.2.0`. Move the pin in every app and module package.json to `2.2.0` — `erp-kit measure` reports anything below it as a compat-range violation. - **BREAKING** `FieldsToInsertable` and `FieldsToSelectable` are removed from `@tailor-platform/erp-kit/core`. Use `TailorDBInsertable` / `TailorDBSelectable` from `@tailor-platform/sdk/kysely` instead — same position, same meaning: ```diff -import { type FieldsToInsertable } from "@tailor-platform/erp-kit/core"; +import type { TailorDBInsertable } from "@tailor-platform/sdk/kysely"; return { commands: { - createX: createX>(), + createX: createX>(), }, }; ``` erp-kit derived both shapes from `output` itself, which the SDK now does — including inside nested objects and for `date` / `datetime` columns, which `output` alone cannot express. Keeping a second copy of those rules meant they could drift from the ones `kyselyTypePlugin` writes into the generated table types. The derived shapes change in four ways: - An extension field defined with `.default(...)` is now optional on create input. It used to be required even though the platform fills it in, so a caller had to supply a value it could not meaningfully choose. - An extension field defined with `.serial(...)` can no longer be given a value on create. It was previously accepted and written straight to the column, which leaves the sequence un-advanced and lets a later auto-assigned value collide with it. Remove such values from create-command calls; the platform assigns them. - On the read side a row still carries every column, and an unset optional field still reads as `null` rather than being omittable. What changes is the column type of a few field kinds: a `date` / `datetime` extension field reads back as `Date` instead of `string | Date`, a `db.object(...)` one resolves through `ObjectColumnType`, and an array of either through `ArrayColumnType`. Narrow any `typeof value === "string"` branch that only existed to satisfy the old union. - The type parameter accepts a table (`typeof myTable`) as well as a field map. Every `defineModule` field generic passes a field map, so no call site changes. - 880a960: - Add the `account-receivable` module with customer invoice models and `createAccountReceivableDocument`, `registerAccountReceivableDocument`, `postAccountReceivableDocument`, and `cancelAccountReceivableDocument` commands, including sales-order billing synchronization and financial-accounting journal integration - Add `correctAccountReceivableDocument` to create and post immutable AR correction documents with line and distribution provenance, due schedules, accounting entries, and sales-order billing feedback - Add incoming-payment management with editable draft payments, invoice and credit-memo settlements, cumulative over-settlement protection, cancellation, posting, and linked reversal payments - Add `INCOMING_PAYMENT` as a financial-accounting journal source type so posted and reversed customer payments retain source-document traceability - Add the sales-owned `listSalesOrderLinesForMatching` query used by account-receivable to validate sales-order sources and snapshot current unit prices without reading sales tables directly ## 0.54.0 ### Minor Changes - bc46403: **BREAKING** Require `@tailor-platform/sdk` v2. `peerDependency` is now `^2.0.0`; sdk v1 is no longer supported. To upgrade an existing app: 1. Move `@tailor-platform/sdk` to `2.0.0` and add `@tailor-platform/sdk-plugin-seed@0.1.0` if you seed data. The SDK ships codemods for most of the renames below — see its v2 migration guide before doing anything by hand. 2. The CLI binary is now `tailor`, not `tailor-sdk`, and writes to `.tailor/` instead of `.tailor-sdk/`. Update package.json scripts, CI workflows, and `.gitignore`. 3. Rename `db.type(...)` to `db.table(...)` in every TailorDB definition, and the auth-attribute module augmentation interface from `AttributeMap` to `Attributes`. 4. Resolver and executor bodies receive `caller` / `invoker` (both `TailorPrincipal | null`) instead of `user`; guard against a `null` caller where you read the caller's identity. The executor option `authInvoker` is now `invoker`, and the `AuthInvoker` type is gone. 5. The ambient `tailor.*` runtime globals are removed — import what you need from `@tailor-platform/sdk/runtime` (for example `idp` in place of `new tailor.idp.Client(...)`). 6. Re-run `tailor generate`. `updatedAt` becomes `Generated` (non-null, set on create), so drop `updatedAt: null` from insert values and set it alongside `createdAt` in fixtures. Mark type-only imports from the generated Kysely file with `import type`; the v2 type stripper does no cross-file inference, so a value import of a type-only export fails at runtime. 7. If you generated seed data, `seedPlugin` no longer emits `seed/exec.mjs`. Replace `node /exec.mjs` with `tailor seed apply` and its `validate` form with `tailor seed validate`, then delete the stale file. ## 0.53.0 ### Minor Changes - a663a0c: - **BREAKING** Derive the accrual distribution of a receipt-required purchase-order AP line instead of accepting its account from the caller: `createAccountPayableDocument`, `updateAccountPayableDocument` and `correctAccountPayableDocument` resolve it from the accrual account of the valuation policy governing the ordered item, at the line's net amount, so the invoice relieves the account the goods receipt credited. Callers now supply distributions on such a line only for the remaining tax, and none at all when the line carries no tax; amount-only lines and lines needing no physical receipt are unchanged. - A receipt-required line that no policy governs fails with `ACCOUNT_PAYABLE_AP_ACCRUAL_ACCOUNT_UNRESOLVED` - New required field `AccountPayableDistributionLine.distributionType`: `MANUAL` (caller-supplied) or `ACCRUAL` (derived). Editing or removing an `ACCRUAL` row fails with `ACCOUNT_PAYABLE_AP_DERIVED_DISTRIBUTION_IMMUTABLE`; it is recomputed when its line changes - `defineAccountPayableModule` now requires `inventory.queries.resolveItemValuationPolicies` - Add inventory query `resolveItemValuationPolicies`, resolving an item to its own valuation policy assignment or the company default, so an invoice can still be captured before its goods arrive - Expose `itemId` on `listPurchaseOrderLinesForMatching` - e53d077: Promote several private helpers that public commands force callers to replicate to public API, so consumers stop reimplementing (and drifting from) the module's own semantics: - **time-tracking `dayBreaker`** — `formReportedBlocks` requires a caller-computed `workDate`; expose `dayBreaker = { toWorkDate, addDays }` (the reference day-breaking) from the module and the `/module` registry. - **time-tracking `jpTimeEntryCodeCategories`** — `calculateTimeBlocks`/`recalculateRange` resolve each span to a `TimeEntryCode` by matching the JP strategy's category keys against `TimeEntryCode.category` and `WorkRule.premiumRatePercent[].category`. Those keys lived only in a private switch, so a mismatch failed derivation at runtime. Expose the exact keys as `jpTimeEntryCodeCategories`, and fix the `TimeEntryCode` doc that listed keys (`OVERTIME_WITHIN_STATUTORY`, `BREAK`, `LEAVE`) the strategy never emits. - **leave-management `computeGrantExpirationDate`** — a `LeaveGrant`'s `expirationDate` is `grantedDate + expirationMonths`; the anniversary batch computed it with private month arithmetic while `grantLeave` only validates a caller-supplied value. Expose `computeGrantExpirationDate` as the shared source of truth. - **workforce `APPOINTMENT_ACTIONS` / `AppointmentTypeAction`** — the closed action set required by `create`/`updateAppointmentType` was not re-exported; expose it so consumers reference the canonical values instead of hardcoding string literals. - a5e7338: - **BREAKING** Reprice receipt costs when a purchase order price changes: amending an `ORDERED` line's unit price declares the price delta over the received-but-unbilled quantity to inventory - `postAcquisitionCostAdjustment` takes a generic source reference: `accountPayableDocumentId` becomes `sourceType` / `sourceId`, line `accountPayableDocumentLineId` becomes `sourceLineId`, and `AcquisitionCostAdjustment.sourceType` gains `PURCHASE_ORDER_REVISION` - `definePurchaseModule` now requires `inventory.commands.postAcquisitionCostAdjustment` - **BREAKING** Measure account-payable price variances against the order price the line was matched at, captured on the new system-written `AccountPayableDocumentLine.matchedPurchaseOrderUnitPrice`. A purchase-order sourced non-PRICE line without it fails to post - Declare the matched-versus-current price difference when a REGISTERED document is cancelled - Fix an empty journal entry being attempted when a redistribution's deltas net to zero in every account role - 7039bb5: - Add independent order, fulfillment, and billing statuses to sales orders, with commands that recalculate progress from line quantities - Synchronize posted outbound shipments with sales-order fulfillment progress using transaction-safe quantity deltas - Improve quantity precision by using decimal values for sales-order quantities, prices, fulfillment, and billing across the module and ERP scaffold - Refactor the sales-order lifecycle to separate document control from execution progress and remove the credit-hold commands ## 0.52.0 ### Minor Changes - d1e5ebc: Re-export the `workforce`, `time-tracking`, `leave-management`, `inbound-shipment`, and `outbound-shipment` module permissions from `@tailor-platform/erp-kit/app`, so resolvers and config files can reach every module's `permissions` via the lightweight `/app` path instead of pulling in the whole module graph through `/module`. A test guard now fails if a module ships a `permissions.generated.ts` that `app.ts` doesn't re-export, so this surface can't silently drift as modules are added. - 40796d9: Migrate shared logging from `@tailor-platform/function-logger` to `tailor.logger` `defineCommand`, `defineQuery`, the notification executors, and the time-tracking derivation now log through `tailor.logger` (via `@tailor-platform/sdk/runtime`) instead of the console-based `function-logger`. Per the platform's New Logger API announcement, `console` output is becoming stdout-only and will no longer be exported through TelemetryRouter — so without this change, command execution logs from erp-kit apps would stop reaching telemetry backends. Context that was previously interpolated into the message string is now attached as structured attributes (`command`, `query`, `permission`, `durationMs`, `input`, `eventId`, `reason`, `error`, `errorName`, `phase`), so backends can facet and filter on it directly. **Breaking:** the minimum supported `@tailor-platform/sdk` is now `1.81.0` (raised from `1.55.0`), the version that introduced `tailor.logger` and `mockLogger`. `@tailor-platform/function-logger` is no longer a dependency. Two notes for consumers: - Log message text changed. Anything grepping stdout for `[command:foo]` or `[notification-redrain-events] ...` should key off the new stable messages and attributes instead. - Command/query inputs are serialized with `JSON.stringify` into an `input` attribute, which means they now reach your telemetry backend rather than only stdout. Review this against your telemetry retention and PII policy. ## 0.51.0 ### Minor Changes - 31fbab7: - Add credit memo settlement support to outgoing payments so posted invoice and credit memo open items can be paid together using their signed net amount - Add system-generated signed amounts to account payable due schedule lines while keeping settlement command inputs as positive magnitudes - Generate direction-aware payable journal lines for invoice and credit memo settlements, with exact reversing entries when an outgoing payment is reversed - Require a complete due schedule when correction invoices and credit memos are created directly in `POSTED` ## 0.50.0 ### Minor Changes - 2bd7dbf: **BREAKING** Add invoice-driven acquisition cost adjustment: purchase receipts costed at the provisional order price are trued up to the invoiced price when account-payable posts. - Add `inventory.commands.postAcquisitionCostAdjustment` and the `AcquisitionCostAdjustment` / `AcquisitionCostAdjustmentAllocation` models. Account-payable declares a signed price variance per order line; inventory redistributes the cumulative amount over the receipt cost layers by the item's costing method. - `ValuationPolicy` requires a new `invoiceCostVarianceAccountId` account; `createValuationPolicy` / `updateValuationPolicy` now take it. - `defineAccountPayableModule` now requires `inventory.commands.postAcquisitionCostAdjustment`; `postAccountPayableDocument` calls it in the same transaction. - `InventoryLedger` persists the order reference (`orderDocumentType` / `orderDocumentId` / `orderDocumentLineId`) so receipt layers resolve. - dc38e63: - Add `workforce` module — an effective-dated HR foundation (Worker, JobProfile, Position, WorkerEmployment, Assignment, AppointmentHistory) that extends the bundled `organization` and `user-management` modules. Employment type, work regime, and appointment type are company-scoped catalog entities (`EmploymentType`, `WorkRegime`, `AppointmentType`) referenced by id rather than fixed enums, so any org can add its own without a code change; each `AppointmentType` maps to a fixed assignment `action` that `recordAppointment` dispatches on - Add `time-tracking` module — the raw-punch → reported → calculated → timecard pipeline with work rules, time-entry codes, eligibility rules, and calendar-scoped holidays (`HolidayCalendar` + `CompanyHoliday`, so multi-entity/multi-country deployments classify holidays correctly). Span `category` and TimeClockEvent `source` are open string keys, not fixed enums - Add `leave-management` module — leave catalog (`LeaveType`), effective-dated accrual plans, a grant ledger with FIFO consumption, and the request/approval lifecycle; the accrual batch dispatches on a configurable `accrualMethod` and stamps a configurable `grantType`. Includes `getAnnualLeaveRegister` — a ledger-derived annual paid-leave compliance register with the Article 39 5-day mandatory-acquisition obligation (deadline, days taken, satisfied/at-risk) - Add a pluggable, per-jurisdiction `TimeClassificationStrategy` seam to `time-tracking` (default: Japan / Labor Standards Act) — apps inject their own strategy (e.g. US FLSA weekly overtime, AU penalty rates) via `defineModule({ timeCalculation: { strategy } })`; span categories are open string keys, and period logic is the strategy's responsibility. A strategy can declare a `recalculationWindow` so a single-day reported-block change re-derives its whole aggregation period (e.g. a week). Includes an authoring guide - Integrate the bundled `approval` module (ADR-003 wrapper, direct mode) into the leave request/approval and timecard submit/approve lifecycles, with self-approval and non-assignee guards - Add point-in-time reconstruction: `listAssignmentsAsOf` returns the org's worker-to-position bindings in force on any past or future date, and `applyDueAppointments` carries out future-dated CHANGE/END appointments once their effective date arrives - Ship JP catalog and default-organization seed data discovered by `erp-kit app generate seed` (employment types, work regimes, appointment types, leave types, a default Company, and the LEAVE time-entry codes the leave defaults reference) - Export `TimeClassificationStrategy` / `ClassifiedSpan` / `ClassifyInput` types and the bundled `jpTimeClassificationStrategy` from the module ## 0.49.0 ### Minor Changes - 6451558: Add step-mode send-back to the approval module: `sendBackApprovalStep` accepts an optional `targetApprovalStepId` that rewinds the request to a chosen earlier step so a prior approver can reconsider, without routing through the requester. - Requester mode (no target) is unchanged: the request transitions to `REVISION_REQUESTED` and step/assignee rows are reset only on `resubmitApprovalRequest` - Step mode (target supplied) keeps the request `PENDING`, resets the target-through-current steps to `PENDING` (their `APPROVED` assignees reset to `PENDING`, `DELEGATED` rows left as-is), and re-activates the target step to `IN_PROGRESS`, reusing the frozen assignee set without re-expanding roles - New nullable `ApprovalDecision.sentBackToStepId` column records the rewind target on step-mode `SEND_BACK` rows (null in requester mode and on all other decision types) - New `APPROVAL_INVALID_SEND_BACK_TARGET` error (`InvalidSendBackTargetError`) rejects a target that is not in the same request or not strictly earlier than the actor's current step - f0dcb36: - Add outgoing payment management to account payable, including draft creation, updates, cancellation, posting, and reversal - Add auditable AP settlement allocation with deterministic locking, over-settlement protection, balanced journal posting, and reversal history - Improve account payable correction posting so exposure, settlement eligibility, and purchase-order billing status remain transactionally consistent - 41c4e91: Rework `measure thin`'s frontend `appShellRatio` to be catalog-based and lie-free: classification is proven against the installed `@tailor-platform/app-shell` instead of hand-written tag lists, and tags that app-shell cannot replace no longer count against the score. - **Catalog matching**: the CLI resolves `@tailor-platform/app-shell` from the measured repo's `node_modules` and reads its `.d.ts`. A raw tag is _replaceable_ only when the catalog proves an equivalent — a same-name export (`