心智模型
是單一成衣設計——一件 SS27 的男性 Polo、一件冬季派克大衣、一件童裝 T 恤——集中存放於一處， 跨銷售它的每一張訂單、每一個季節、每一個客戶重複使用。圍繞著這個唯一的紀錄，四個角色各司其職：- 款式擁有設計本身以及定義它的各份文件。
- 訂單取用款式——客戶承諾以指定的日期前購買它的特定配色與數量。
- 製造單生產款式——它們是針對某張訂單的生產工作所開立的生產文件。
- 版本保留歷史——款式的各份文件以編號的修訂版本向前推進， 讓款式持續演進的同時，先前每一個版本仍完整保留，供它原本所支撐的訂單繼續使用。
款式擁有什麼
款式紀錄是設計的所在地。它承載設計的商務識別，並擁有所有說明這個設計如何製作、如何計價的文件。 款式的商務識別：- 設計的名稱、設計所開發給的 、季節、性別，以及 的結構化清單。
- 款式的小圖——在系統各處的清單、選擇器與報表中所看到的圖。
- 平台在建立時所指派的唯一款式編號。
- 它的——每件的布料與輔料清單。
- 它的——每件的價格構成，分工廠端與客戶端兩條欄位。
- 它的工藝包檔案——工廠據以作業的設計與結構文件。
- 它的其他生產文件——、 包裝、品質管制與成本分析紀錄。
客戶名稱在款式上被擷取
當您在建立時將客戶連結到款式，客戶名稱便會擷取到款式上，並持續顯示在款式列、選擇器與報表中。 這樣的擷取是刻意的：款式是長壽命的設計紀錄，它「為哪個買家而開發」的可讀識別必須能撐過客戶主檔的變動。 即使客戶紀錄日後被移除，擷取到款式上的名稱仍會留著——這樣一年前的設計， 讀起來仍是當初它所代表的那個設計。連結規則與解除連結的行為，請見款式頁面。訂單如何取用款式
是 客戶以指定的出貨日購買一個或多個款式特定配色與數量的承諾。訂單取用款式——它們指回所運行的款式、 讀取款式的物料表與成本表作為自己的物料清單與計價基礎，並補上只屬於該張訂單的訂單側細節。 兩者的界線很清楚：- 在款式上：設計可重複使用的識別、它的各份文件，以及它的配色面板。
- 在訂單上：客戶承諾——下了哪些配色、什麼尺寸、什麼數量、什麼價格、什麼出貨日。
製造單如何生產款式
製造單是針對某張訂單的款式生產所開立的生產文件。它引用的是該次生產所核准的款式文件版本， 讓工廠依據一份已敲定的物料清單與一份已敲定的價格構成作業，而非依據款式當下的樣貌。 本頁不再深入這層模型之上的細節；完整機制位於製造單相關頁面。版本如何讓歷史成為一等公民
如果多張訂單共用同一個款式，那為某張訂單所做的變更，又如何不波及另一張？答案是版本控管。 每一個對款式文件有意義的變更——一次物料表修訂、一次成本表修訂——都會儲存為一個新的 。 舊版本完整保持它原本的樣子。每張訂單各自綁定自己所運行的版本，因此：- 一張在生產中的訂單會繼續使用它當初建構於其上的版本，即便款式本身已經往前走。
- 為某張訂單修訂某份文件，並不會默默改動到另一張。
- 每一次變更的歷程都會被保留，而非被覆蓋。
對比：以訂單為中心 vs. 以款式為中心
傳統的以訂單為中心系統把產品放進訂單裡。同一件外套被訂三次，就會變成三份各自獨立的物料表與成本表副本， 每次都重新輸入，沒有共用紀錄，也沒有便利的比較或重用途徑。當客戶要求換掉秋季訂單的某個物料時， 沒人說得準春季訂單當初是依據哪一份物料表所做的。 GarmentFlow 的以款式為中心模型把產品放進款式裡。這件外套只輸入一次、物料表與成本表只建構一次、 訂單則指回它們所運行的款式。再次下單時，沿用既有的成果。為某張訂單做的變更會被擷取為一個新版本， 而該訂單會被綁定到這個版本；其他訂單不受影響。設計的完整歷史集中存放在一處—— 數月、跨季節之後仍清楚可讀。您會在哪裡遇到這個模型
- 款式模組裡——租戶內所有款式的清單、款式詳細頁的物料表、成本表與其他文件分頁， 以及用來開啟新版本、切換目前版本的控制項。
- 訂單內——訂單對每個它所運行款式的視角，顯示該訂單綁定在物料表與成本表的哪個版本， 以及屬於該訂單的訂單側細節（顏色、尺寸、數量）。
- 下游工作中——採購、就緒引擎與生產， 都會透過款式解析每張訂單的版本，因此每個使用者讀到的，都是該訂單實際所運行的版本。