FDE Practical Application (III): Turning Business Rules into States, Traceability, and Collaboration

The most challenging part of manufacturing systems is often not the forms, but the states. If the states are not clearly defined, subsequent inventory, costs, and reports will all be adrift.

The same batch of materials may be in states such as pending inspection, qualified, locked, or unqualified; the same order may go through stages like pending confirmation, in production, partially shipped, and closed; the same formula may also have historical versions. What seems like just a few labels actually determines who can proceed.

States Precede Pages

In our projects, we treat key cross-module states as first-class design objects:

• Purchase Contract: Draft → Pending Review → Confirmed → Available for Storage

• Material Batch: Pending Inspection → Qualified / Unqualified

• Production Batch: Pending Scheduling → In Production → Completed

• Sales Order: Pending Confirmation → Confirmed → In Production → Partially Shipped / Shipped

Each transition must answer: Who triggered it, what prerequisites are needed, which related data will be updated, should others be notified, and can it be revoked.

For example, the approval of a purchase contract not only changes the contract status but also determines whether the warehouse can accept the goods; the acceptance will generate pending sampling records; once the inspection results change, the available inventory and production occupancy must also be recalculated. A button on a page may hide consistency issues across multiple domain objects.

Inventory is Not Just a Number

In early project discussions, the warehouse was most concerned about whether “the quantity in the system can match the physical count.” Quality and production would continue to ask: Is this batch qualified? Has it been scheduled for production? Has it been reduced due to sampling?

Therefore, the inventory model must at least distinguish between quantity and availability. Once materials are stored, they automatically enter a pending inspection state; sampling will leave independent records, and only after passing inspection will they be considered normally available; scheduling will freeze the expected usage, and canceling the schedule will release it; unqualified products are handled through a specialized outbound and destruction process. This way, the system can explain why “how much total inventory is left” and “how much is currently usable” are different.

The same applies to finished products. Actual production output, quality sampling, and sales sampling cannot simply be summed up to form a deliverable quantity. Each part must have a source and destination, allowing finance, warehouse, and quality to reconcile on the same batch record.

Traceability is a Business Capability, Not a Log Decoration

Formula versions, material batch numbers, production batches, material requisition records, and shipping records are designed as a traceable chain. A production batch needs to know which formula was used at the time, material requisition needs to associate with specific material batch numbers, finished goods outbound needs to be tied to inventory batches, and reconciliation must rematch actual shipments to orders.

This design also exposes a reality: one production batch can serve multiple orders, and one order may be shipped in multiple batches. The system cannot rely solely on the “current order number” field; it needs to maintain the relationships between batches, orders, and outbound details, allocate quantities in the agreed order during reconciliation, and allow for manual review of boundary cases.

Digitalization Does Not Equal Eliminating On-Site Actions

• Managers prefer to compare historical purchase prices and complete approvals on their phones.

• Warehouses hope to automatically bring up materials pending storage based on purchase contracts, only supplementing the actual arrival quantity.

• Workshops need to input production output and working hours on tablets, while documents still need to be printed and retain signature areas.

• Materials and documents should ideally be quickly located via barcodes to reduce errors in handwritten batch numbers.

Thus, we view pages, mobile interfaces, print templates, notifications, and scanning as different entry points of the same process. As long as the data model is consistent, the on-site team can choose the most convenient entry; the system is responsible for maintaining consistency in states, permissions, and traceability.

Let States Drive Collaboration

In regular processes, quality results determine whether inventory is available, and inventory status in turn dictates whether production and shipping can continue. Once the system clarifies these prerequisites, the warehouse, quality, production, and sales can collaborate around the same record without repeatedly confirming states verbally.

This type of design preserves the boundaries of responsibilities for each department while ensuring that each step has a clear responsible party and traceable records.

From Initial Version to Continuous Convergence

Post-initial demonstration engineering work focuses on boundaries rather than decoration: inspection reports are categorized by type, batch status is recalculated when inspection results change, inventory records add withdrawal and deletion protections, approval tasks are supplemented with jump information, inventory warnings are uniformly statistically calculated, and historical data migration fills in the associations between formula versions and production batches.

These tasks share a common point: they all maintain that “the same fact can only have one explanation.” When quality status changes, inventory, notifications, and outbound permissions must also change; when codes or contract numbers are corrected, associated records must be synchronized; when accounts are terminated, the approval chain cannot continue to rely on old accounts.

FDE’s Engineering Judgment

In complex enterprise projects, FDE needs to accept two things simultaneously: the business will not fully express itself in the first interview, and real boundaries will inevitably emerge during demonstrations and usage; not all on-site habits should be automated; the system must control key facts and risks, clearly assign the parts that still require judgment to people, and leave traceable records.

The standard for final delivery is not the number of pages or the number of requirement documents, but whether business personnel can verify a real process: where the data comes from, what state it is currently in, who is responsible for the next step, and whether issues can be traced.