心智模型
是单一成衣设计——一件 SS27 的男性 Polo、一件冬季派克大衣、一件童装 T 恤——集中存放于一处， 跨销售它的每一张订单、每一个季节、每一个客户重复使用。围绕着这个唯一的记录，四个角色各司其职：- 款式拥有设计本身以及定义它的各份文件。
- 订单取用款式——客户承诺以指定的日期前购买它的特定配色与数量。
- 制造单生产款式——它们是针对某张订单的生产工作所开立的生产文件。
- 版本保留历史——款式的各份文件以编号的修订版本向前推进， 让款式持续演进的同时，先前每一个版本仍完整保留，供它原本所支撑的订单继续使用。
款式拥有什么
款式记录是设计的所在地。它承载设计的商务识别，并拥有所有说明这个设计如何制作、如何计价的文件。 款式的商务识别：- 设计的名称、设计所开发给的 、季节、性别，以及 的结构化清单。
- 款式的小图——在系统各处的清单、选择器与报表中所看到的图。
- 平台在创建时所指派的唯一款式编号。
- 它的——每件的面料与辅料清单。
- 它的——每件的价格构成，分工厂端与客户端两条字段。
- 它的工艺包档案——工厂据以作业的设计与结构文件。
- 它的其他生产文件——、 包装、质量管控与成本分析记录。
客户名称在款式上被捕获
当您在创建时将客户关联到款式，客户名称便会捕获到款式上，并持续显示在款式行、选择器与报表中。 这样的捕获是刻意的：款式是长寿命的设计记录，它”为哪个买家而开发”的可读识别必须能撑过客户主档的变动。 即使客户记录日后被移除，捕获到款式上的名称仍会留着——这样一年前的设计， 读起来仍是当初它所代表的那个设计。关联规则与解除关联的行为，请见款式页面。订单如何取用款式
是 客户以指定的出货日购买一个或多个款式特定配色与数量的承诺。订单取用款式——它们指回所运行的款式、 读取款式的物料表与成本表作为自己的物料清单与计价基础，并补上只属于该张订单的订单侧细节。 两者的界线很清楚：- 在款式上：设计可重复使用的识别、它的各份文件，以及它的配色面板。
- 在订单上：客户承诺——下了哪些配色、什么尺寸、什么数量、什么价格、什么出货日。
制造单如何生产款式
制造单是针对某张订单的款式生产所开立的生产文件。它引用的是该次生产所核准的款式文件版本， 让工厂依据一份已敲定的物料清单与一份已敲定的价格构成作业，而非依据款式当下的样貌。 本页不再深入这层模型之上的细节；完整机制位于制造单相关页面。版本如何让历史成为一等公民
如果多张订单共用同一个款式，那为某张订单所做的变更，又如何不波及另一张？答案是版本控管。 每一个对款式文件有意义的变更——一次物料表修订、一次成本表修订——都会保存为一个新的 。 旧版本完整保持它原本的样子。每张订单各自绑定自己所运行的版本，因此：- 一张在生产中的订单会继续使用它当初构建于其上的版本，即便款式本身已经往前走。
- 为某张订单修订某份文件，并不会悄悄改动到另一张。
- 每一次变更的历程都会被保留，而非被覆盖。
对比：以订单为中心 vs. 以款式为中心
传统的以订单为中心系统把产品放进订单里。同一件外套被订三次，就会变成三份各自独立的物料表与成本表副本， 每次都重新录入，没有共用记录，也没有便利的比较或重用途径。当客户要求换掉秋季订单的某个物料时， 没人说得准春季订单当初是依据哪一份物料表所做的。 GarmentFlow 的以款式为中心模型把产品放进款式里。这件外套只录入一次、物料表与成本表只构建一次、 订单则指回它们所运行的款式。再次下单时，沿用既有的成果。为某张订单做的变更会被捕获为一个新版本， 而该订单会被绑定到这个版本；其他订单不受影响。设计的完整历史集中存放在一处—— 数月、跨季节之后仍清楚可读。您会在哪里遇到这个模型
- 款式模块里——租户内所有款式的列表、款式详细页的物料表、成本表与其他文件分页， 以及用来开启新版本、切换当前版本的控件。
- 订单内——订单对每个它所运行款式的视角，显示该订单绑定在物料表与成本表的哪个版本， 以及属于该订单的订单侧细节（颜色、尺寸、数量）。
- 下游工作中——采购、就绪引擎与生产， 都会通过款式解析每张订单的版本，因此每个使用者读到的，都是该订单实际所运行的版本。