Manufacturing Module — Analysis & Build Specification

A complete, generic specification for a Manufacturing module to be built into an existing ERP. Written for an AI coding agent (Claude Code) to implement. The module is generic (any manufacturer); a Melamine tableware factory is used throughout only as a stress-test example.

📖 What this is

This is the analysis output of a full requirements study. It defines a manufacturing module covering the entire production lifecycle, designed to plug into an ERP that already has Finance, Inventory, Procurement, Sales, and HR.

Genericity is the prime directive: every factory-specific behaviour is expressed as configuration (a field/enum) + branching logic, never as hard-coded special cases. See 00 §0.2.

🗂️ How to read these files (in order)

🏗️ The architecture at a glance

┌──────────────────────────────────────────────────┐
│  SHOP FLOOR CONTROL (SFC) — real-time tracking     │
├──────────────────────────────────────────────────┤
│  ① MASTER DATA   — definitions (BOM/Routing/WC)    │
│  ② PLANNING      — MPS → MRP → CRP                  │
│  ③ EXECUTION     — Order → Issue → Confirm → GR     │
│  ④ COSTING       — methods, elements, variances     │
└──────────────────────────────────────────────────┘
   ↕ integrates: Sales · Procurement · Inventory · GL · HR

Data flows top-down with a closed feedback loop (CRP conflicts & costing variances correct Planning).

🎯 The genericity mandate (the one rule)

When you find behaviour that "only this factory does," do NOT branch the code by factory. Add a configuration field that defaults to the common behaviour, and branch on that field.

Examples (full table in 00 §0.2): - 4 production modes → production_type enum - Customer-supplied material → material_ownership enum - Multi-output molds → cavity_count field - Multiple quality grades from one run → yield is a distribution, not a scalar - Piece-rate vs hourly pay → labor_calc enum

🔑 Master enums (defined in 00)

production_type     ∈ { MakeToStock, MakeToOrder, AssembleToOrder, TollManufacturing }
material_ownership  ∈ { Own, Customer }
procurement_type    ∈ { Buy, Make }
costing_method      ∈ { Standard, Actual, Average, FIFO }
labor_calc          ∈ { Hourly, PieceRate }
issue_type          ∈ { Manual, Backflush, AutoIssue }
issue_level         ∈ { PerOrder, PerShift, PerOperation }
resource_type       ∈ { Machine, Tool, Labor }
lot_sizing_rule     ∈ { Exact, Fixed, MinMax, EOQ, PeriodOrder }
order_status        ∈ { Planned, Released, InProcess, Completed, Closed }
operation_status    ∈ { Waiting, Ready, InProgress, Completed }

🔨 Recommended build order

1. Master Data (recursive BOM, Routing, WC, Tool) + CRUD
2. Item MRP Settings + Standard Cost
3. MPS → 4. MRP → 5. CRP
6. Production Order → 7. Material Issue → 8. Confirmation → 9. Goods Receipt
10. Costing (methods, elements, cost centers, variances)
11. SFC (real-time operation tracking, terminals, dashboard)
12. Integrations (Sales, Procurement, Inventory, GL, HR)

Each step depends on the prior. Full data model and cardinalities in 06.

📌 Conventions for the builder

• Pseudo-code in these files is language-agnostic intent, not literal code. Implement idiomatically in the host ERP's stack.
• Melamine test cases prove the design handles edge cases — they are examples, not the thing to hard-code.
• Honour cross-cutting rules from 00: frozen snapshots, state machines, many-to-many demand↔supply, multi-level recursion, config-over-code, real-time GL postings, resource abstraction.
• A parallel set of HTML files (in ../html/) presents the same content for human reading; the Markdown files are the source of truth for implementation.

✅ Scope summary

In scope (build): Master Data, Planning, Execution, Costing, Shop Floor Control, and the integration adapters to existing modules.

Out of scope (integrate, don't rebuild): GL, Inventory core, Procurement core, Sales, HR.

Future phases (interfaces noted in 06 §6.5): APS detailed scheduling, Quality, Tool/Mold management, Maintenance, OEE, PLM/ECO.