> ## 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-Hant/reference/glossary#order)</Tooltip>
**同時沿著兩條軌道前進**：把承諾轉化為出貨成衣的實際作業，以及這筆交易本身的商業狀態。本頁是兩條軌道的心智模型、它們的關係，以及製造單與就緒引擎所在的位置。每一步的實際操作細節，請參閱對應的模組頁。

本頁建立在[以款式為中心的模型](/zh-Hant/concepts/style-centric-model)之上：訂單是*執行*款式，而非*包含*款式。

## 心智模型：兩條平行的軌道

GarmentFlow 裡的每張訂單都同時帶有：

* **工作階段**——目前的實際作業推進到哪裡，從最初的詢價一路走到出貨完成。這條軌道是訂單日常作業的主線。
* **商業狀態**——這筆交易本身的商業承諾狀況，從詢盤、報價走到已確認，再到已完成或已取消。這是訂單在商業面的標籤。

這兩條軌道**各自獨立**追蹤、各自前進。把訂單標記為**已確認**（商業狀態的變動）與推離詢價階段（工作階段的推進）是兩個不同的動作，平台**不會**讓其中一個自動牽動另一個。它們是同一張訂單的兩個讀數，由團隊自行保持步調一致，而不是由平台綁在一起。

## 工作階段——主線

工作階段是訂單依序經過的固定階段，一次走一個：

1. **詢價**——訂單已開立，但實際作業尚未啟動，條件仍在洽談。
2. **開發樣**——已交由工廠開發初樣，讓客戶可審視設計。
3. **報價**——已為客戶估出價格。
4. **PI 已發**——
   <Tooltip tip="出貨前用以確認價格、數量與條款的初步發票。">[形式發票](/zh-Hant/reference/glossary#pi-proforma-invoice)</Tooltip>
   已寄給客戶。
5. **PO 已收**——已收到客戶的採購單，這筆交易正式成立。
6. **採購**——正依據訂單已核准的
   <Tooltip tip="一個款式由哪些布料與輔料構成的清單。">[物料表](/zh-Hant/reference/glossary#bom-bill-of-materials)</Tooltip>
   採購物料。
7. **生產樣**——大貨前的生產樣正在製作與審視。
8. **大貨生產**——主生產在工廠裡進行中。
9. **已出貨**——成衣已離開工廠、運往客戶。

工作階段之所以是主線，是因為它就是業務人員日常推動的內容——每一個階段都對應一段真實的作業，訂單的就緒度、排程與下游文件都掛在它上面。

### 階段如何推進

部分推進由團隊在工作完成時手動標記，部分則在平台看到觸發事件時自動完成：

* 推進到 **PI 已發**：當該訂單建立了形式發票時自動發生。
* 推進到 **採購**：當該訂單的第一份物料表獲核准時自動發生——這是物料清單已穩定到可以開始採購的訊號。
* 推進到 **大貨生產**：當生產前樣品獲核准時自動發生。
* 推進到 **已出貨**：當該訂單的出貨進入運送中時自動發生。

其餘的推進——離開詢價、開發樣、PI 與採購等階段——由團隊在各步驟完成時手動標記。

### 階段一次推一步、不會跳階也不會倒退

工作階段一次只往前推一個階段，**既不跳階也不倒退**。已經完成的階段推進就維持已完成的狀態，即使上游的決定後來被重新檢視——舉例來說，**撤回**某份物料表的核准**不會**把訂單退回先前的階段。若要在訂單已推離某個由核准觸發的階段之後再變更上游文件的內容，標準作法是為該文件**開立新版並重新核准**（每張訂單各自的版本鎖定會記住該訂單當下使用的版本；詳見[物料表、成本表與文件版本](/zh-Hant/concepts/bom-cost-sheet-artifact-versions)）。

## 商業狀態——平行軌道

除了工作階段之外，訂單還帶有一個由團隊設定的**商業狀態**，用來表達這筆交易目前的承諾位置。可用的狀態包括詢盤、報價單、**已確認**、樣品、PP 樣、生產、出貨、**已完成**與**已取消**。

商業狀態裡有兩個是最重要的：

* **已確認**——客戶已承諾、這筆交易拍板成立。確認是其他部門可據以開始規劃的商業訊號——意味著款式、數量與出貨日是真的。這個狀態由團隊在訂單上設定，**不是**由工作階段自動推導。
* **已取消**——這筆交易告吹。訂單可從幾乎任何更早的狀態被改為已取消，讓團隊在客戶撤單時能乾淨地停下手中的工作。已取消是**終態**，不會再被反向回復。

**已完成**則代表這筆交易在商業面已結案——已出貨、已開票、已收齊款項。與已取消一樣，已完成也是**終態**。

商業狀態會在團隊標記時改變。**唯一**由平台自動寫入狀態的時點，是訂單開始投入生產作業時——為該訂單建立生產紀錄時，狀態會自動翻為**生產**，讓這張訂單不再被當成尚未開工的訂單顯示。

### 狀態與階段彼此不互相把關

由於兩條軌道各自獨立追蹤，訂單因此可能出現乍看奇怪的組合——例如商業狀態已經是*生產*，但工作階段還停在採購（團隊已先把商業標籤切過去，雖然現場還沒實際下線）。請依其本意各自解讀：階段說的是**作業推進到了哪裡**，狀態說的是**這筆交易處於何種承諾位置**。它們的一致由團隊的紀律維繫，平台不會強迫它們同步。

## 製造單在主線上的位置

<Tooltip tip="針對某張訂單的款式版本所開立的生產文件；開立時其內容即被凍結。">[製造單（MO）](/zh-Hant/reference/glossary#mo-manufacturing-order)</Tooltip>
——某張訂單該次生產所對應的生產規格文件——是在工作階段這條主線上建立與開立的。實務上，這通常發生在訂單已具備該次生產所應依循的已核准物料表（理想情況下還有已核准成本表）之後；以階段對照，大致落在**採購**到**大貨生產**之間。

開立製造單會做兩件事：

* 它會將製造單**鎖定到該訂單的技術文件、物料表、成本表、包裝指示與品質規範的特定版本**。日後在款式上對這些文件做新的修訂，**不會**改變已開立製造單所指向的版本——工廠看到的，仍是它被開立當下所依據的那份內容。
* 它會將製造單在開立當下**凍結為定稿**。已鎖定文件之後的內容變動，不會穿透到已開立的製造單上。

開立**不會**由平台依「版本是否已核准」設關卡。團隊應遵循的紀律是：**在開立製造單之前，先核准該訂單的物料表與成本表**——這樣凍結下來的那份內容，就是團隊願意背書的那份。平台信任團隊遵循這項紀律；經驗法則請見[款式、訂單與製造單](/zh-Hant/concepts/style-vs-order-vs-mo)。

開立製造單本身**並不會**推進工作階段、也不會改變商業狀態——這兩條軌道仍各自由前述事件推進。

## 就緒引擎所在的位置

[就緒引擎](/zh-Hant/concepts/readiness-engine-and-ai)疊在兩條軌道之上。它讀取團隊正在做的同一批工作——物料表核准、試身簽核、收料、已開立的文件——並逐張訂單算出已完成了什麼、還缺什麼。工作階段告訴您訂單**走到了哪一段**；就緒引擎則告訴您**那一段裡還缺哪些**、以及出貨日是否有風險。

兩個讀數彼此互補：階段推進是線性主線，就緒視圖則是疊在它上面的檢查清單。

## 訂單不會被刪除

訂單一旦建立，就會留在系統裡。訂單上**沒有刪除動作**——若有一筆交易不再進行，標準作法是把它**取消**，將紀錄留檔，並以清楚的商業標籤標示之後不再對它做任何處理。這讓既有的下游文件與報表仍能維持完整的稽核軌跡。

## 您在哪裡會看到這個模型

* **在訂單明細頁**——訂單抬頭顯示商業狀態，工作階段的推進則與訂單概觀和就緒視圖並列。
* **在訂單模組**——清單檢視以商業狀態作為每張訂單的快速辨識標籤。
* **在下游作業上**——就緒引擎、生產時程，以及文件與轉換鏈，都會讀取訂單的工作階段以判斷哪些工作已解鎖。

## 相關頁面

* [款式、訂單與製造單](/zh-Hant/concepts/style-vs-order-vs-mo)
* [物料表、成本表與文件版本](/zh-Hant/concepts/bom-cost-sheet-artifact-versions)
* [就緒引擎與 AI](/zh-Hant/concepts/readiness-engine-and-ai)
* [文件與轉換鏈](/zh-Hant/concepts/documents-and-conversion-chain)
* [訂單模組指南](/zh-Hant/modules/orders)