> ## Documentation Index
> Fetch the complete documentation index at: https://docs.garmentflow.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# 订单生命周期

> 订单同时推进的两条平行轨道——工作阶段与商业状态——它们的关系，以及制造单与就绪引擎所在的位置。

GarmentFlow 里的一张<Tooltip tip="客户承诺购买特定款式、配色与数量，并于指定日期前出货。">[订单](/zh-Hans/reference/glossary#order)</Tooltip>
**同时沿着两条轨道前进**：把承诺转化为出货成衣的实际作业，以及这笔交易本身的商业状态。本页是两条轨道的心智模型、它们的关系，以及制造单与就绪引擎所在的位置。每一步的实际操作细节，请参阅对应的模块页。

本页建立在[以款式为中心的模型](/zh-Hans/concepts/style-centric-model)之上：订单是*执行*款式，而非*包含*款式。

## 心智模型：两条平行的轨道

GarmentFlow 里的每张订单都同时带有：

* **工作阶段**——目前的实际作业推进到哪里，从最初的询价一路走到出货完成。这条轨道是订单日常作业的主线。
* **商业状态**——这笔交易本身的商业承诺状况，从询盘、报价走到已确认，再到已完成或已取消。这是订单在商业面的标签。

这两条轨道**各自独立**追踪、各自前进。把订单标记为**已确认**（商业状态的变动）与推离询价阶段（工作阶段的推进）是两个不同的动作，平台**不会**让其中一个自动牵动另一个。它们是同一张订单的两个读数，由团队自行保持步调一致，而不是由平台绑在一起。

## 工作阶段——主线

工作阶段是订单依序经过的固定阶段，一次走一个：

1. **询价**——订单已开立，但实际作业尚未启动，条件仍在洽谈。
2. **开发样**——已交由工厂开发初样，让客户可审视设计。
3. **报价**——已为客户估出价格。
4. **PI 已发**——
   <Tooltip tip="出货前用以确认价格、数量与条款的初步发票。">[形式发票](/zh-Hans/reference/glossary#pi-proforma-invoice)</Tooltip>
   已寄给客户。
5. **PO 已收**——已收到客户的采购单，这笔交易正式成立。
6. **采购**——正依据订单已核准的
   <Tooltip tip="一个款式由哪些面料与辅料构成的清单。">[物料表](/zh-Hans/reference/glossary#bom-bill-of-materials)</Tooltip>
   采购物料。
7. **生产样**——大货前的生产样正在制作与审视。
8. **大货生产**——主生产在工厂里进行中。
9. **已出货**——成衣已离开工厂、运往客户。

工作阶段之所以是主线，是因为它就是业务人员日常推动的内容——每一个阶段都对应一段真实的作业，订单的就绪度、进度与下游文件都挂在它上面。

### 阶段如何推进

部分推进由团队在工作完成时手动标记，部分则在平台看到触发事件时自动完成：

* 推进到 **PI 已发**：当该订单创建了形式发票时自动发生。
* 推进到 **采购**：当该订单的第一份物料表获核准时自动发生——这是物料清单已稳定到可以开始采购的信号。
* 推进到 **大货生产**：当生产前样品获核准时自动发生。
* 推进到 **已出货**：当该订单的出货进入运送中时自动发生。

其余的推进——离开询价、开发样、PI 与采购等阶段——由团队在各步骤完成时手动标记。

### 阶段一次推一步、不会跳阶也不会倒退

工作阶段一次只往前推一个阶段，**既不跳阶也不倒退**。已经完成的阶段推进就维持已完成的状态，即使上游的决定后来被重新审视——举例来说，**撤回**某份物料表的核准**不会**把订单退回先前的阶段。若要在订单已推离某个由核准触发的阶段之后再变更上游文件的内容，标准做法是为该文件**开立新版并重新核准**（每张订单各自的版本锁定会记住该订单当下使用的版本；详见[物料表、成本表与文件版本](/zh-Hans/concepts/bom-cost-sheet-artifact-versions)）。

## 商业状态——平行轨道

除了工作阶段之外，订单还带有一个由团队设定的**商业状态**，用来表达这笔交易目前的承诺位置。可用的状态包括询盘、报价单、**已确认**、样品、PP 样、生产、发货、**已完成**与**已取消**。

商业状态里有两个是最重要的：

* **已确认**——客户已承诺、这笔交易拍板成立。确认是其他部门可据以开始规划的商业信号——意味着款式、数量与出货日是真的。这个状态由团队在订单上设定，**不是**由工作阶段自动推导。
* **已取消**——这笔交易告吹。订单可从几乎任何更早的状态被改为已取消，让团队在客户撤单时能干净地停下手中的工作。已取消是**终态**，不会再被反向回复。

**已完成**则代表这笔交易在商业面已结案——已出货、已开票、已收齐款项。与已取消一样，已完成也是**终态**。

商业状态会在团队标记时改变。**唯一**由平台自动写入状态的时点，是订单开始投入生产作业时——为该订单创建生产记录时，状态会自动翻为**生产**，让这张订单不再被当成尚未开工的订单显示。

### 状态与阶段彼此不互相把关

由于两条轨道各自独立追踪，订单因此可能出现乍看奇怪的组合——例如商业状态已经是*生产*，但工作阶段还停在采购（团队已先把商业标签切过去，虽然现场还没实际下线）。请依其本意各自解读：阶段说的是**作业推进到了哪里**，状态说的是**这笔交易处于何种承诺位置**。它们的一致由团队的纪律维系，平台不会强迫它们同步。

## 制造单在主线上的位置

<Tooltip tip="针对某张订单的款式版本所开立的生产文件；开立时其内容即被冻结。">[制造单（MO）](/zh-Hans/reference/glossary#mo-manufacturing-order)</Tooltip>
——某张订单该次生产所对应的生产规格文件——是在工作阶段这条主线上创建与开立的。实务上，这通常发生在订单已具备该次生产所应依循的已核准物料表（理想情况下还有已核准成本表）之后；以阶段对照，大致落在**采购**到**大货生产**之间。

开立制造单会做两件事：

* 它会将制造单**锁定到该订单的技术文件、物料表、成本表、包装指示与品质规范的特定版本**。日后在款式上对这些文件做新的修订，**不会**改变已开立制造单所指向的版本——工厂看到的，仍是它被开立当下所依据的那份内容。
* 它会将制造单在开立当下**冻结为定稿**。已锁定文件之后的内容变动，不会穿透到已开立的制造单上。

开立**不会**由平台依「版本是否已核准」设关卡。团队应遵循的纪律是：**在开立制造单之前，先核准该订单的物料表与成本表**——这样冻结下来的那份内容，就是团队愿意背书的那份。平台信任团队遵循这项纪律；经验法则请见[款式、订单与制造单](/zh-Hans/concepts/style-vs-order-vs-mo)。

开立制造单本身**并不会**推进工作阶段、也不会改变商业状态——这两条轨道仍各自由前述事件推进。

## 就绪引擎所在的位置

[就绪引擎](/zh-Hans/concepts/readiness-engine-and-ai)叠在两条轨道之上。它读取团队正在做的同一批工作——物料表核准、试身签核、收料、已开立的文件——并逐张订单算出已完成了什么、还缺什么。工作阶段告诉您订单**走到了哪一段**；就绪引擎则告诉您**那一段里还缺哪些**、以及出货日是否有风险。

两个读数彼此互补：阶段推进是线性主线，就绪视图则是叠在它上面的检查清单。

## 订单不会被删除

订单一旦创建，就会留在系统里。订单上**没有删除动作**——若有一笔交易不再进行，标准做法是把它**取消**，将记录留档，并以清楚的商业标签标示之后不再对它做任何处理。这让既有的下游文件与报表仍能维持完整的审计轨迹。

## 您在哪里会看到这个模型

* **在订单明细页**——订单抬头显示商业状态，工作阶段的推进则与订单概览和就绪视图并列。
* **在订单模块**——清单视图以商业状态作为每张订单的快速识别标签。
* **在下游作业上**——就绪引擎、生产时程，以及文件与转换链，都会读取订单的工作阶段以判断哪些工作已解锁。

## 相关页面

* [款式、订单与制造单](/zh-Hans/concepts/style-vs-order-vs-mo)
* [物料表、成本表与文件版本](/zh-Hans/concepts/bom-cost-sheet-artifact-versions)
* [就绪引擎与 AI](/zh-Hans/concepts/readiness-engine-and-ai)
* [文件与转换链](/zh-Hans/concepts/documents-and-conversion-chain)
* [订单模块指南](/zh-Hans/modules/orders)