@tailor-platform/erp-kit 0.5.1 → 0.7.0

package/src/modules/finance-ledger/testing/fixtures.ts

@@ -0,0 +1,382 @@
+import type {
+  FiscalYear,
+  AccountingPeriod,
+  JournalEntry,
+  JournalLine,
+  PeriodClose,
+  TrialBalance,
+  TrialBalanceLine,
+  FinancialStatement,
+  FinancialStatementLineItem,
+  Schema,
+} from "../lib/types";
+
+const createdAt = new Date("2024-01-01T00:00:00.000Z");
+
+export const baseCompany = {
+  id: "company-1",
+  status: "ACTIVE",
+};
+
+export const baseAccount = {
+  id: "account-1",
+  code: "1000",
+  name: "Cash",
+  classification: "ASSET",
+  status: "ACTIVE",
+  successorAccountId: null,
+};
+
+export const baseAccount2 = {
+  id: "account-2",
+  code: "2000",
+  name: "Accounts Payable",
+  classification: "LIABILITY",
+  status: "ACTIVE",
+  successorAccountId: null,
+};
+
+export const receivableAccount = {
+  id: "account-receivable",
+  code: "1100",
+  name: "Accounts Receivable",
+  classification: "RECEIVABLE",
+  status: "ACTIVE",
+  successorAccountId: null,
+};
+
+export const payableAccount = {
+  id: "account-payable",
+  code: "2100",
+  name: "Accounts Payable Control",
+  classification: "PAYABLE",
+  status: "ACTIVE",
+  successorAccountId: null,
+};
+
+export const inactiveAccount = {
+  ...baseAccount,
+  id: "account-inactive",
+  status: "INACTIVE",
+  successorAccountId: null,
+};
+
+export const deprecatedAccount = {
+  ...baseAccount,
+  id: "account-deprecated",
+  status: "DEPRECATED",
+  successorAccountId: baseAccount.id,
+};
+
+export const retainedEarningsAccount = {
+  id: "account-retained-earnings",
+  code: "3100",
+  name: "Retained Earnings",
+  classification: "RETAINED_EARNINGS",
+  status: "ACTIVE",
+  successorAccountId: null,
+};
+
+export const revenueAccount = {
+  id: "account-revenue",
+  code: "4000",
+  name: "Sales Revenue",
+  classification: "REVENUE",
+  status: "ACTIVE",
+  successorAccountId: null,
+};
+
+export const expenseAccount = {
+  id: "account-expense",
+  code: "5000",
+  name: "Cost of Goods Sold",
+  classification: "EXPENSE",
+  status: "ACTIVE",
+  successorAccountId: null,
+};
+
+export const baseAccountGroup = {
+  id: "account-group-1",
+  name: "Current Assets",
+  code: "CA",
+};
+
+export const baseChartOfAccounts = {
+  id: "coa-1",
+  companyId: baseCompany.id,
+  status: "ACTIVE",
+};
+
+export const baseCurrency = {
+  id: "currency-1",
+  code: "USD",
+  isActive: true,
+};
+
+export const baseUser = {
+  id: "user-1",
+  status: "ACTIVE",
+};
+
+export const baseFiscalYear = {
+  id: "fiscal-year-1",
+  companyId: baseCompany.id,
+  name: "FY 2024",
+  startDate: new Date("2024-01-01"),
+  endDate: new Date("2024-12-31"),
+  yearEndCloseExecuted: false,
+  createdAt,
+  updatedAt: null,
+} as const satisfies FiscalYear<Schema>;
+
+export const baseFiscalYear2 = {
+  ...baseFiscalYear,
+  id: "fiscal-year-2",
+  name: "FY 2025",
+  startDate: new Date("2025-01-01"),
+  endDate: new Date("2025-12-31"),
+} as const satisfies FiscalYear<Schema>;
+
+export const baseAccountingPeriod = {
+  id: "period-1",
+  companyId: baseCompany.id,
+  fiscalYearId: baseFiscalYear.id,
+  name: "January 2024",
+  startDate: new Date("2024-01-01"),
+  endDate: new Date("2024-01-31"),
+  periodType: "OPERATING",
+  status: "OPEN",
+  createdAt,
+  updatedAt: null,
+} as const satisfies AccountingPeriod<Schema>;
+
+export const neverOpenedPeriod = {
+  ...baseAccountingPeriod,
+  id: "period-never-opened",
+  status: "NEVER_OPENED",
+} as const satisfies AccountingPeriod<Schema>;
+
+export const futureEnterablePeriod = {
+  ...baseAccountingPeriod,
+  id: "period-future-enterable",
+  status: "FUTURE_ENTERABLE",
+} as const satisfies AccountingPeriod<Schema>;
+
+export const closedPeriod = {
+  ...baseAccountingPeriod,
+  id: "period-closed",
+  status: "CLOSED",
+} as const satisfies AccountingPeriod<Schema>;
+
+export const permanentlyClosedPeriod = {
+  ...baseAccountingPeriod,
+  id: "period-permanently-closed",
+  status: "PERMANENTLY_CLOSED",
+} as const satisfies AccountingPeriod<Schema>;
+
+export const lastPeriodOfYear = {
+  ...baseAccountingPeriod,
+  id: "period-last",
+  name: "December 2024",
+  startDate: new Date("2024-12-01"),
+  endDate: new Date("2024-12-31"),
+} as const satisfies AccountingPeriod<Schema>;
+
+export const baseJournalEntry = {
+  id: "journal-entry-1",
+  companyId: baseCompany.id,
+  accountingPeriodId: baseAccountingPeriod.id,
+  entryDate: new Date("2024-01-15"),
+  journalType: "MISCELLANEOUS",
+  referenceNumber: "JE-001",
+  status: "DRAFT",
+  description: "Test journal entry",
+  sourceDocumentReference: null,
+  adjustingEntryType: null,
+  reversalOfId: null,
+  postedAt: null,
+  createdAt,
+  updatedAt: null,
+} as const satisfies JournalEntry<Schema>;
+
+export const postedJournalEntry = {
+  ...baseJournalEntry,
+  id: "journal-entry-2",
+  referenceNumber: "JE-002",
+  status: "POSTED",
+  postedAt: createdAt,
+} as const satisfies JournalEntry<Schema>;
+
+export const reversedJournalEntry = {
+  ...baseJournalEntry,
+  id: "journal-entry-3",
+  referenceNumber: "JE-003",
+  status: "REVERSED",
+  postedAt: createdAt,
+} as const satisfies JournalEntry<Schema>;
+
+export const baseJournalLine = {
+  id: "journal-line-1",
+  journalEntryId: baseJournalEntry.id,
+  accountId: baseAccount.id,
+  debitAmount: 1000,
+  creditAmount: null,
+  description: "Debit line",
+  currencyCode: null,
+  exchangeRate: null,
+  functionalDebitAmount: 1000,
+  functionalCreditAmount: null,
+  createdAt,
+  updatedAt: null,
+} as const satisfies JournalLine<Schema>;
+
+export const baseJournalLine2 = {
+  id: "journal-line-2",
+  journalEntryId: baseJournalEntry.id,
+  accountId: baseAccount2.id,
+  debitAmount: null,
+  creditAmount: 1000,
+  description: "Credit line",
+  currencyCode: null,
+  exchangeRate: null,
+  functionalDebitAmount: null,
+  functionalCreditAmount: 1000,
+  createdAt,
+  updatedAt: null,
+} as const satisfies JournalLine<Schema>;
+
+export const basePeriodClose = {
+  id: "period-close-1",
+  accountingPeriodId: baseAccountingPeriod.id,
+  status: "NOT_STARTED",
+  initiatedByUserId: baseUser.id,
+  completionPercentage: 0,
+  subledgerVerificationDetails: null,
+  trialBalanceId: null,
+  preliminaryStatementIds: null,
+  approvedByUserId: null,
+  finalizedByUserId: null,
+  yearEndCloseExecuted: false,
+  createdAt,
+  updatedAt: null,
+} as const satisfies PeriodClose<Schema>;
+
+export const inProgressPeriodClose = {
+  ...basePeriodClose,
+  id: "period-close-in-progress",
+  status: "IN_PROGRESS",
+  completionPercentage: 12,
+} as const satisfies PeriodClose<Schema>;
+
+export const subledgersVerifiedPeriodClose = {
+  ...basePeriodClose,
+  id: "period-close-subledgers-verified",
+  status: "SUBLEDGERS_VERIFIED",
+  completionPercentage: 25,
+} as const satisfies PeriodClose<Schema>;
+
+export const adjustmentsPostedPeriodClose = {
+  ...basePeriodClose,
+  id: "period-close-adjustments-posted",
+  status: "ADJUSTMENTS_POSTED",
+  completionPercentage: 50,
+} as const satisfies PeriodClose<Schema>;
+
+export const trialBalanceVerifiedPeriodClose = {
+  ...basePeriodClose,
+  id: "period-close-tb-verified",
+  status: "TRIAL_BALANCE_VERIFIED",
+  completionPercentage: 62,
+} as const satisfies PeriodClose<Schema>;
+
+export const underReviewPeriodClose = {
+  ...basePeriodClose,
+  id: "period-close-under-review",
+  status: "UNDER_REVIEW",
+  completionPercentage: 75,
+} as const satisfies PeriodClose<Schema>;
+
+export const softLockedPeriodClose = {
+  ...basePeriodClose,
+  id: "period-close-soft-locked",
+  status: "SOFT_LOCKED",
+  completionPercentage: 87,
+  approvedByUserId: baseUser.id,
+} as const satisfies PeriodClose<Schema>;
+
+export const permanentlyClosedPeriodClose = {
+  ...basePeriodClose,
+  id: "period-close-permanently-closed",
+  status: "PERMANENTLY_CLOSED",
+  completionPercentage: 100,
+} as const satisfies PeriodClose<Schema>;
+
+export const baseTrialBalance = {
+  id: "trial-balance-1",
+  companyId: baseCompany.id,
+  accountingPeriodId: baseAccountingPeriod.id,
+  chartOfAccountsId: baseChartOfAccounts.id,
+  variant: "PRE_CLOSE",
+  generatedAt: createdAt,
+  totalDebits: 10000,
+  totalCredits: 10000,
+  isBalanced: true,
+  createdAt,
+  updatedAt: null,
+} as const satisfies TrialBalance<Schema>;
+
+export const baseTrialBalanceLine = {
+  id: "trial-balance-line-1",
+  trialBalanceId: baseTrialBalance.id,
+  accountId: baseAccount.id,
+  accountGroupId: baseAccountGroup.id,
+  accountCode: "1000",
+  accountName: "Cash",
+  openingBalance: 0,
+  periodDebits: 5000,
+  periodCredits: 2000,
+  closingBalance: 3000,
+  sortOrder: 1,
+  createdAt,
+  updatedAt: null,
+} as const satisfies TrialBalanceLine<Schema>;
+
+export const baseFinancialStatement = {
+  id: "financial-statement-1",
+  companyId: baseCompany.id,
+  chartOfAccountsId: baseChartOfAccounts.id,
+  trialBalanceId: baseTrialBalance.id,
+  comparativePeriodTrialBalanceId: null,
+  statementType: "BALANCE_SHEET",
+  status: "DRAFT",
+  reportingDate: new Date("2024-01-31"),
+  startDate: null,
+  endDate: null,
+  cashFlowMethod: null,
+  generatedAt: createdAt,
+  finalizedAt: null,
+  createdAt,
+  updatedAt: null,
+} as const satisfies FinancialStatement<Schema>;
+
+export const finalizedFinancialStatement = {
+  ...baseFinancialStatement,
+  id: "financial-statement-2",
+  status: "FINALIZED",
+  finalizedAt: createdAt,
+} as const satisfies FinancialStatement<Schema>;
+
+export const baseFinancialStatementLineItem = {
+  id: "fs-line-item-1",
+  financialStatementId: baseFinancialStatement.id,
+  accountId: baseAccount.id,
+  accountGroupId: baseAccountGroup.id,
+  label: "Cash",
+  amount: 3000,
+  comparativeAmount: null,
+  lineType: "DETAIL",
+  sectionType: "Current Assets",
+  sortOrder: 1,
+  createdAt,
+  updatedAt: null,
+} as const satisfies FinancialStatementLineItem<Schema>;

package/src/modules/finance-ledger/tsconfig.json

@@ -0,0 +1,16 @@
+{
+  "compilerOptions": {
+    "target": "ES2022",
+    "module": "ESNext",
+    "moduleResolution": "bundler",
+    "allowSyntheticDefaultImports": true,
+    "esModuleInterop": true,
+    "allowJs": true,
+    "strict": true,
+    "noEmit": true,
+    "skipLibCheck": true,
+    "resolveJsonModule": true,
+    "types": ["node", "@tailor-platform/function-types"]
+  },
+  "include": ["**/*.ts"]
+}

package/src/modules/inventory/docs/features/inventory-adjustment.md

@@ -39,7 +39,7 @@ flowchart TD
 - **Shrinkage / theft**: Periodic checks or count results show missing inventory with no corresponding shipment. A negative adjustment with reason code "Shrinkage" records the loss.
 - **Counting error correction**: A cycle count reveals more units on the shelf than the system shows. A positive adjustment with reason code "Counting Error" increases the on-hand balance.
 - **Receiving error correction**: Goods receipt recorded the wrong quantity. A positive or negative adjustment with reason code "Receiving Error" corrects the discrepancy.
-- **Production variance**: Actual yield differs from the expected output of a manufacturing process. An adjustment with reason code "Production Variance" reconciles the difference.
+- **Production variance fallback**: Actual yield differs from expected output, but the site is not using the manufacturing module or the discrepancy is discovered with no resolvable production-order or work-order source document. In that limited case, a direct adjustment with reason code "Production Variance" reconciles the difference.
 - **Threshold-based approval**: An adjustment exceeding a configured quantity or value limit is routed to a supervisor for approval before confirmation.
 - **Bulk post-count adjustment**: After a full physical inventory count, the system generates one adjustment record per variance line, allowing batch review, reason-code assignment, and confirmation.
 
@@ -56,6 +56,7 @@ flowchart TD
 - Adjustments originating from an inventory count link back to the count session for traceability
 - Confirmed adjustments update inventory valuation consistent with the organization's costing method
 - Adjustments are immutable after confirmation; corrections require a new, offsetting adjustment
+- A direct adjustment with reason code `Production Variance` must be rejected or rerouted when a resolvable manufacturing `productionOrderReference` or `workOrderReference` exists; those cases must enter inventory through `ManufacturingScrapHandoff`
 
 ## Reference Links
 

package/src/modules/inventory/docs/features/scrap-management.md

@@ -2,10 +2,12 @@
 
 ## Overview
 
-Scrap management handles the controlled removal of damaged, expired, defective, or obsolete stock from usable inventory. Scrap is modeled as an InventoryAdjustment with `adjustmentType = SCRAP`. When confirmed, the adjustment moves stock from the source storage location to a virtual "scrap" location, effectively removing it from available stock and reducing inventory valuation.
+Scrap management handles the controlled removal of damaged, expired, defective, or obsolete stock from usable inventory. Scrap is modeled as an `InventoryAdjustment` with `adjustmentType = SCRAP`. When confirmed, the adjustment moves stock from the source storage location to a virtual "scrap" location, effectively removing it from available stock and reducing inventory valuation.
 
 Organizations may enforce approval workflows for scrap adjustments that exceed a defined value threshold, ensuring proper oversight of material losses. Scrap adjustments follow the same approval workflow as correction adjustments (DRAFT → PENDING_APPROVAL → CONFIRMED). Once confirmed, the adjustment is immutable — if scrap was created in error, a new CORRECTION adjustment with a positive quantityDelta can restore the stock.
 
+Inventory accepts scrap input both from direct inventory users and from upstream manufacturing execution. Manufacturing-originated scrap enters inventory through the `ManufacturingScrapHandoff` contract defined in manufacturing `work-order-execution.md`, after which inventory creates or updates the `InventoryAdjustment` that owns stock and valuation effects.
+
 ## Business Purpose
 
 - Remove physically damaged, expired, or quality-rejected stock from available inventory so it is not accidentally picked, sold, or consumed
@@ -38,9 +40,42 @@ flowchart TD
 - **Quality failure scrap**: Items that fail incoming or in-process quality inspection are immediately scrapped, with the quality rejection linked as the scrap reason
 - **Obsolescence write-off**: Slow-moving or discontinued items are scrapped as part of a periodic inventory review to reflect their true recoverable value
 - **High-value approval scrap**: A scrap adjustment exceeds the organization's value threshold, triggering a manager approval step before the stock movement is executed
+- **Manufacturing-originated scrap**: A work order reports scrap and sends `ManufacturingScrapHandoff`; inventory resolves the source location, creates a SCRAP adjustment, and runs the same approval policy as any other scrap event
 - **Scrap error correction**: A scrap adjustment is found to have been created in error; a new CORRECTION adjustment with positive quantityDelta restores the stock to the source location
 - **Lot/serial-tracked scrap**: Specific lots or serial numbers are scrapped, maintaining full traceability from receipt through disposal. Serial numbers transition to SCRAPPED state on confirmation.
 
+Inventory accepts `ManufacturingScrapHandoff` from manufacturing work-order execution with the following minimum fields:
+
+- `productionOrderReference`
+- `workOrderReference`
+- `itemReference`
+- `scrapQuantity`
+- `unitOfMeasure`
+- `scrapReasonCode`
+- `siteReference`
+- `postingDate`
+
+Optional and conditional fields:
+
+- `sourceStorageLocationReference`: optional when inventory can derive the source location from prior issue, backflush, or site-level manufacturing scrap policy; otherwise required
+- `inventoryLotReference`: required when the scrapped item is lot-tracked
+- `serialReferences`: required when the scrapped item is serial-tracked
+- `scrapDispositionCode`: optional classification retained for downstream analysis
+
+Inventory maps the handoff into an inventory-owned `InventoryAdjustment` as follows:
+
+- `adjustmentType = SCRAP`
+- `itemReference`, `siteReference`, `postingDate`, and reason fields come directly from the handoff
+- `productionOrderReference` and `workOrderReference` are retained as source-document traceability fields on the adjustment
+- `sourceStorageLocationReference` is taken from the payload when present; otherwise inventory must derive it from manufacturing issue history, staging-location policy, or other site-level configuration before the adjustment can proceed
+- `inventoryLotReference` and `serialReferences` flow into the same lot or serial validation rules used by direct inventory scrap
+
+Approval and confirmation rules are inventory-owned:
+
+- If the resulting scrap value exceeds the configured approval threshold, inventory creates the adjustment in `PENDING_APPROVAL`
+- If the threshold is not exceeded, inventory may confirm the adjustment immediately
+- If location, lot, serial, or quantity resolution fails, inventory rejects the handoff and does not mutate stock
+
 ## Test Cases
 
 - Creating a SCRAP adjustment with positive quantityDelta is rejected
@@ -55,6 +90,9 @@ flowchart TD
 - Scrapped items cannot re-enter available stock without a new CORRECTION adjustment
 - Scrap reason is mandatory and must be one of the defined reason categories
 - Listing adjustments filtered by `adjustmentType = SCRAP` returns only scrap records
+- A valid `ManufacturingScrapHandoff` must create or update a SCRAP adjustment that preserves the production-order and work-order references for traceability
+- Manufacturing-originated scrap must follow the same approval threshold policy as manually entered scrap adjustments
+- If inventory cannot resolve the source storage location required for `ManufacturingScrapHandoff`, the handoff must be rejected without mutating stock
 
 ## Reference Links
 

package/src/modules/manufacturing/README.md

@@ -0,0 +1,63 @@
+# README
+
+## Overview
+
+The Manufacturing module manages production planning and execution from recipe and process definition through order release, shop-floor progress tracking, completion, and cost capture. It owns the master and transactional records that explain what should be produced, how it should be produced, where capacity exists to produce it, what work is in progress, what quantities were consumed or completed, and how actual manufacturing results differ from the plan.
+
+Manufacturing sits between upstream demand or supply signals and downstream stock or finance execution. It references items from item-management, company and site context from organization, units and currencies from primitives, and coordinates with inventory for component issue, finished-goods receipt, and scrap posting. That coordination includes named cross-module contracts such as `ManufacturingReceiptHandoff`, `ManufacturingScrapHandoff`, `InventoryIssueOutcomeEvent`, and `ManufacturingCostSettlementAcknowledgment`, which let inventory and downstream accounting remain the owners of stock movement, valuation, and settlement while manufacturing remains the owner of production intent and variance analysis. It may prepare cost and account-reference data for downstream accounting, but journal posting and ledger ownership remain outside the module.
+
+## Key Features
+
+- **[Bill of Material Management](docs/features/bill-of-material-management.md)**: Define versioned multi-level bills of material for finished goods and subassemblies, including component quantities, scrap assumptions, effectivity, and default selection rules used by production orders
+- **[Routing and Work Center Definition](docs/features/routing-and-work-center-definition.md)**: Define routings as ordered manufacturing steps and configure work centers with capacity, calendars, standard times, and cost rates used for planning and execution
+- **[Production Order Lifecycle](docs/features/production-order-lifecycle.md)**: Create, schedule, release, reschedule, cancel, complete, technically complete, and close production orders with BOM and routing snapshots plus progress visibility from planned order through settled closeout
+- **[Work Order Execution](docs/features/work-order-execution.md)**: Execute operation-level work orders with start, pause, report, complete, material issue or backflush, scrap capture, and finished or intermediate receipt handoff to inventory
+- **[Manufacturing Cost and Variance](docs/features/manufacturing-cost-and-variance.md)**: Capture planned versus actual component, labor, machine, and overhead cost at production-order level and classify manufacturing variances for downstream accounting consumption
+
+## Module Scope
+
+### In Scope
+
+- Bill of material ownership, including component lines, versioning, effectivity windows, multi-level subassembly references, and `bomType` semantics for `MANUFACTURE`, `PHANTOM`, and `KIT`
+- Routing ownership, including ordered operations, standard setup or run times, operation instructions, and work-center assignment
+- Work center master data, including company or site scope, availability calendar, capacity assumptions, and standard cost rates
+- Production order planning and control, including creation, scheduling, BOM or routing selection, release, cancellation, completion, technical completion, and closeout
+- Work order execution at operation level, including start, pause, resume, quantity reporting, time capture, scrap reporting, and exception notes
+- Material requirement handoff to inventory for reservation, issue, backflush, finished-goods receipt, intermediate receipt, and scrap posting
+- Planned-versus-actual manufacturing cost rollup using component issue values from inventory plus labor or machine rates from work centers, with explicit variance categories and downstream account references
+- Production status, progress, and auditability scoped by company and site
+
+### Out of Scope
+
+- Forecasting, MRP netting, replenishment proposals, and automated procurement planning
+- Advanced finite-capacity optimization, drag-and-drop scheduling boards, and AI or rules-based sequencing
+- Quality inspection plans, nonconformance, CAPA, rework loops, and regulated electronic batch record workflows
+- Subcontracting, outside processing, contract manufacturing, and supplier-operated work centers
+- Co-products, by-products, and joint-production costing
+- Detailed operator kiosk UX, barcode device workflows, PLC or IoT machine integration, and MES hardware connectivity
+- Warehouse ownership, stock balances, lot or serial master records, and inventory valuation logic
+- Journal entry posting, WIP settlement, period close, and general-ledger balance ownership
+- Preventive maintenance, OEE analytics, and HR or payroll-driven labor management
+
+### Scope Decision Rationale
+
+Manufacturing is scoped to the **production definition and execution layer**: product recipe, process steps, capacity context, production order control, and operation-level reporting. These concepts depend on one another and change together, so they belong in one module rather than being split prematurely across planning, execution, and costing.
+
+Inventory remains the owner of **physical stock state**. Manufacturing decides that materials should be issued, scrap should be recorded, or finished goods should be received, but inventory owns the resulting stock movement, lot or serial handling, warehouse location state, and valuation basis. Manufacturing can request issue execution, but actual material cost becomes manufacturing-visible only when inventory returns the named `InventoryIssueOutcomeEvent` after inventory-owned valuation is complete. This keeps manufacturing focused on production intent and progress rather than warehouse internals.
+
+Sales and purchase remain the owners of **commercial demand and supply commitments**. Manufacturing can consume sales demand, open supply status, or manual planner input when creating production orders, but it must not own customer orders, purchase orders, or supplier receipts. That separation preserves clean module boundaries and allows manufacturing to serve both make-to-stock and make-to-order flows without duplicating commercial logic.
+
+Accounting remains the owner of **financial posting and settlement**. Manufacturing can capture planned and actual production cost, classify variances into price, usage, rate, efficiency, scrap, and yield categories, and reference WIP or variance accounts from coa-management, but posting journal entries and enforcing period-close rules belong to downstream accounting modules. This keeps cost insight in manufacturing without pulling ledger behavior into the shop-floor domain.
+
+## Module Dependencies
+
+- [item-management](../item-management/README.md) — Finished goods, subassemblies, raw materials, and consumables are referenced as Items or SKUs
+- [organization](../organization/README.md) — Company and Site scope for BOM defaults, work centers, and production execution context
+- [primitives](../primitives/README.md) — Unit-of-measure conversions for component and output quantities plus currency references for costing
+- [inventory](../inventory/README.md) — Downstream execution of component issue, backflush, finished-goods receipt, intermediate receipt, scrap, lot assignment, and actual material cost sourcing through `InventoryIssueOutcomeEvent`
+- [user-management](../user-management/README.md) — Permissions for create, release, reschedule, start, complete, technically complete, cancel, close, and cost-review actions
+- [audit](../audit/README.md) — Immutable audit trail for BOM revisions, routing changes, order transitions, and execution events
+- [coa-management](../coa-management/README.md) — WIP, absorption, material price, material usage, labor rate, labor efficiency, machine rate, machine efficiency, scrap, and yield account references for downstream cost posting
+- [sales](../sales/README.md) — Optional demand signal source for make-to-order or priority-driven production planning
+- [purchase](../purchase/README.md) — Optional material availability and ETA signal source for release decisions and shortage visibility
+- [product-management](../product-management/README.md) — Optional product or variant metadata source when aligning commercial catalog structure to manufacturing definitions

package/src/modules/manufacturing/command/activateBillOfMaterial.generated.ts

@@ -0,0 +1,6 @@
+// @generated — do not edit
+import { permissions } from "../lib/permissions.generated";
+import { run } from "./activateBillOfMaterial";
+import { defineCommand } from "@tailor-platform/erp-kit/module";
+
+export const activateBillOfMaterial = defineCommand(permissions.activateBillOfMaterial, run);