> ## 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.
# 報價單
> 報價單是您擺到客戶面前的價格提案——以單一幣別承載款式、配色、尺寸與單價的文件，客戶接受後再開立任何訂單。
[報價單](/zh-Hant/reference/glossary#quotation)
是您正式向客戶提出的價格提案，承載一個或多個
[款式](/zh-Hant/reference/glossary#style)，
列出指定的配色與尺碼，並有明確的有效期限——這份文件由客戶接受（或婉拒）後，
任何[訂單](/zh-Hant/reference/glossary#order)
才會被開立。
## 什麼是報價單
一份報價單是**單一客戶、單一幣別、單一版次**。一份報價單對一位客戶以一個幣別開立，並執行一條以上的款式行——
每條款式承載構成這份提案的配色、尺碼、數量與單價。
報價單以款式為中心：每一行可顯式連結到一筆
[款式](/zh-Hant/reference/glossary#style)
主檔，讓提案綁定到一筆真實、可重複使用的款式紀錄，而非自由文字代號。
同一份報價單可執行多個款式，每個款式各有自己的配色與尺碼。
報價單會走過清晰的生命週期——**草稿**、**已送出**、**已核准**或**已拒絕**，
最終在報價轉為訂單時成為**已轉換**。當客戶在報價已送出後要求修改，報價單會被修訂：
平台在同一條鏈上開啟新的版次，舊版次被標示為**已取代**，整條鏈仍保留在歷史中。
## 為什麼存在
報價是這筆生意從對話變成提案的時刻：價格、數量、配色與有效期限，都寫進客戶可簽回的同一份文件。
報價單給業務一份單一的、可掛上自家品牌寄出的文件，並在客戶接受後給營運端一個乾淨的交接——
每一條款式行、每一個配色、每一個尺碼、每一個價格都帶到下游，無須重打。
版次制讓提案得以在議價中演進，而每一個較早的版本仍完整保留。
修訂後的報價是同一條鏈上的新版次，因此每一輪所提議過的歷程都被保存——
最後開出的訂單，明確就是依據被接受的那個特定版次而來的。
## 何時會用到
* **業務階段**——把已定價的提案擺到客戶面前，先於任何訂單。
* **議價時**——修訂提案，在同一條鏈上開啟新版次、編輯、再次送出。
* **客戶接受時**——作為交接到客戶已承諾的
[訂單](/zh-Hant/modules/orders)的入口；
您的管理員已啟用之處，亦可由此產生
[形式發票](/zh-Hant/reference/glossary#pi-proforma-invoice)
（PI）供客戶安排付款。
* **客戶簽回 PI 後**——把簽回副本附到報價單上，讓商業軌跡集中在同一份紀錄。
報價單位於**報價單**模組。要走一遍端到端的報價流程，詳見
[建立報價單](/zh-Hant/modules/create-a-quotation)。
## 依賴項
* 一筆**客戶紀錄**，在報價單表頭上挑選。客戶主檔由您的管理員維護。
* 至少一個**要報的款式**。一條行可以連結到既有的款式主檔，也可承載自由文字款號；
連結為佳，讓提案綁定到真實的款式紀錄。詳見
[款式](/zh-Hant/modules/styles)。
* 每個您打算報價的款式上都需要一份**成本表**，作為報價單載入單價的依據。
成本表是計價工具；報價單是提案。詳見[成本表](/zh-Hant/modules/cost-sheet)。
* **報價單寫入權限**，給建立、編輯、送出、核准、拒絕、修訂或轉換報價的使用者。
讀取對您租戶內任何已登入的使用者開放。
## 哪些東西依賴它
* 報價單轉換後開出的
[訂單](/zh-Hant/reference/glossary#order)——
新訂單保留一條回溯到來源報價單的連結，並承接其客戶、幣別、款式、配色、尺碼與單價。
詳見[訂單](/zh-Hant/modules/orders)。
* 由已核准報價單產生的
[形式發票](/zh-Hant/reference/glossary#pi-proforma-invoice)——
PI 把明細項目、單價、客戶與條款往下帶。
詳見[文件與轉換鏈](/zh-Hant/concepts/documents-and-conversion-chain)。
* 客戶**簽回的 PI**——上傳到報價單上，讓原始提案、由它產生的 PI、以及客戶簽回的副本都掛在同一份紀錄上。
* 生產與財務據以回溯的稽核軌跡——每一次出貨都能透過其訂單、PI 以及它源自的報價單追回原點。
詳見[文件與轉換鏈](/zh-Hant/concepts/documents-and-conversion-chain)。
* 轉換後的金流——一旦已核准的報價單轉換為訂單，訂金與請款路徑便在
[Finance 模組](/zh-Hant/modules/finance)中運作，面向客戶的結算全貌則匯總至
[對帳單](/zh-Hant/modules/statement-of-account)。訂單最終承載的客戶
發票，與報價單的 PI 屬於不同的商業文件——關於該文件，詳見
[發票](/zh-Hant/modules/invoices)。
## 欄位
報價單的欄位依用途分組。表頭承載識別、客戶、商業條件與備註；每一條款式行承載一個報出的款式；
每一格尺碼承載一個「配色 × 尺碼」的價格。
### 表頭——識別
* `報價單號`——報價單的永久商業識別碼。建立時由平台產生；在您租戶內具有唯一性。
格式為租戶可設定的前綴、年份，以及一個每年重置的流水號（前綴由您的管理員設定）。
* `版次`——此報價單在修訂鏈上的版次號。第一份報價單從版次 1 起算；每次**修訂**都會在同一條鏈上
開啟一個新版次，逐次加一。鏈以「上層版次參考」相連，而不是重用同一個報價單號。
* `建立者`——建立此報價單的使用者。由平台在建立時設定；報價單轉換時，會作為訂單上的指派業務沿用。
### 表頭——客戶與商業條件
* `客戶`——您報價的對象。從客戶主檔挑選。**必填**。
* `幣別`——報出單價所用的幣別。一份報價單對應一個幣別；以不同幣別報價即為另一份報價單。
選單列出您租戶採用的幣別（USD、EUR、JPY、TWD、CNY、GBP）。**必填**。
* `有效期限`——這份提案過期的日期。超過此日期後，價格不再保證。選填。
* `季節`——這份提案所對應的銷售季節，從您的管理員設定的租戶季節清單中挑選。
租戶通常會把清單項目設定為年度與季節合併的單一標籤（例如 `2026 S/S`、
`26 FW`），讓提案在文件上同時帶有年度與季節。選填。
* `產地`——這份提案的產地（國家或地區）。從您的管理員設定的租戶產地清單中挑選。選填。
* `條款`——印在報價單上的付款與商業條款文字。從您的管理員設定的租戶付款條件清單中挑選；
所選項目的文字會保存在報價單上。選填。
* `備註`——內部用的自由文字，會印為報價單文件上的「Remark」。選填。
### 表頭——AI 封面備註
* `AI 封面備註`——以 AI 起草的選填封面備註，存放在報價單上，供報價單文件的封面頁使用。
### 表頭——稽核
* `建立日期`、`最後更新日期`——由平台設定。在報價單上顯示作為參考；
`建立日期`即報價單文件所印出的開立日期。
### 款式行——識別與連結
每一條款式行是報價單上的一個款式區塊，承載該款式被報出的配色與尺碼。
* `款式主檔編號`——選填的
[款式](/zh-Hant/reference/glossary#style)
主檔連結。從款式主檔選擇器挑選。連結會把此行綁定到真實的款式紀錄
（並在報價單文件上呈現該主檔的識別碼）；留空時，此行為自由文字行。選填但建議使用。
* `款號`——報價單上對客戶顯示的款式編號。**必填**，上限 100 字元。
與主檔的款號互相獨立，因此即使此行已連結到主檔，仍可承載客戶專屬的款式代號。
* `款式名稱`——報價單上的款式名稱。**必填**，上限 255 字元。
* `Fabric No.`——報價單上此款式的布料參考。選填，上限 300 字元。
* `樣品尺寸`——這份提案所參照的樣品尺寸。選填，上限 50 字元。
* `最小訂購量 (MOQ)`——此款式行所附帶的最小訂購量。非負整數；選填，
該行不附條件時留空。承載於報價單行上供文件呈現之用，於轉換時不會傳遞到訂單。
* `配色數`——此款式行上所登錄的相異配色數量。由各尺碼列中實際輸入的配色名稱推算，
因此不會與資料脫鉤；不可直接編輯。
### 款式行——遺留描述欄位
這些欄位曾於早期版本的報價單表單上存在，已不再作為新報價的輸入欄位提供。
平台仍會在原本帶有它們的款式行上保留這些值——在修訂報價、以及由報價單轉換出的訂單行上——
讓您過去登錄的描述細節不致遺失。
* `性別`——款式所對應的性別。在原本帶有此值的行上沿用；新報價不再輸入。
* `後整理`——款式上的自由文字後整理備註。在原本帶有此值的行上沿用；新報價不再輸入。
### 尺碼格——配色 × 尺碼
每一格尺碼是「一個配色 × 一個尺碼」，承載該格的數量與單價。
* `配色`——報價單上寫出的配色名稱。**必填**，上限 100 字元。報價單上為自由文字——
從款式主檔的配色清單中挑選，是訂單層級才處理的事。
* `色碼`——選填的配色代碼，通常為十六進位值（例如 `#000000`）。上限 50 字元。
* `尺寸`——本列的尺碼標籤（例如 `S`、`M`、`38`）。**必填**，上限 50 字元。
* `數量`——本「配色 × 尺碼」所報的數量。整數，**零或以上**。
* `單價`——本「配色 × 尺碼」每件的報價，幣別同報價單`幣別`。
**零或以上**。報價單的定價是逐尺碼的——同一個配色可在不同尺碼上承載不同價格，
而總額會據實計算。
### 附件——簽回的形式發票
客戶簽回的
[形式發票](/zh-Hant/reference/glossary#pi-proforma-invoice)
附在報價單上，而非訂單或 PI 上。每份附件承載：
* `檔名`、`檔案類型`、`大小`——檔案中繼資料。僅接受 **PDF** 與 **JPG** 上傳。
* `上傳者`、`上傳時間`——附上檔案的人與時間。
## 業務規則
1. **一份報價單對應單一客戶與單一幣別。** 客戶與幣別在表頭挑選，並在報價單生命週期內維持不變。
以不同幣別、或對不同客戶的提案即為另一份報價單。
2. **編輯僅限於草稿。** 表頭變更、款式行新增／編輯／刪除、配色與尺碼編輯，以及單價編輯，
都要求報價單處於**草稿**。對非草稿狀態的報價單下寫入請求，會以「僅限草稿」訊息被拒。
3. **送出會把報價單從進一步編輯上鎖。** 一旦您送出報價單，它便離開**草稿**進入**已送出**，
平台不再接受對表頭、款式或尺碼的編輯。變更已送出報價的方式是**修訂**——詳見業務規則 6。
4. **客戶的回應決定下一個狀態。** 從**已送出**，報價單在客戶接受時轉為**已核准**，
或在客戶婉拒時轉為**已拒絕**。兩者都由團隊在報價單上設定，而非由其他動作推導。
5. **僅已核准的報價單可轉換為訂單。** 在任何其他狀態上，「轉換為訂單」會被拒，
並回應目前的狀態；已轉換過的報價單不得再次轉換。
6. **修訂會在同一條鏈上開啟新版次，並使先前版次被取代。** 修訂**已送出**、**已核准**或**已拒絕**的報價單，
會在原報價單上開啟一份新的**草稿**報價單，版次號加一，深層複製每一條款式行與尺碼，
並帶上 `配色`、`色碼`、`尺寸`、`數量` 與 `單價`，亦複製表頭
（客戶、幣別、有效期限、季節、產地、條款、備註）。新報價單會領取自己的新 `報價單號`；
先前報價單在同一動作中被標示為**已取代**。`AI 封面備註`不會被複製——
新版次需要時請重新起草。
7. **報價單清單預設隱藏已取代的版次。** 已取代的報價單仍保留在紀錄中，
可透過直接連結或在清單中包含已取代列來檢視，以保存議價歷程。
8. **產生 PI 不會改變報價單的狀態。** 當您的管理員已啟用您租戶的「報價產 PI」、且報價單處於**已核准**時，
「產生形式發票」會開啟一份從報價單預填的新
[形式發票](/zh-Hant/reference/glossary#pi-proforma-invoice)。
報價單仍維持**已核准**，因此仍可轉換為訂單。
9. **簽回的 PI 附在報價單上。** 客戶 PI 的簽回副本上傳到報價單紀錄本身，
而非訂單或 PI 文件。
10. **報價單文件依需求渲染。** 報價單匯出為帶有您租戶品牌（標誌、配色、賣方資訊區塊）的 PDF；
渲染時不會存到檔案庫，因此每次下載都反映目前的報價單。
11. **報價單上的寫入動作受權限管控。** 由具備報價單寫入權限的使用者建立、編輯、送出、核准、拒絕、修訂、轉換報價單，
並上傳簽回 PI。讀取對您租戶內任何已登入的使用者開放。
## 驗證
| 時機 | 檢查 | 失敗時會發生什麼 |
| -------- | -------------------------------------------------------------------------------- | ------------------------------- |
| 建立或編輯表頭 | `幣別`為已設定的幣別之一 | 儲存被拒。 |
| 編輯表頭 | 報價單處於**草稿** | 儲存被拒，回應「僅草稿報價單可編輯」。 |
| 新增或編輯款式行 | `款號`已填入（≤100）且`款式名稱`已填入（≤255）；`Fabric No.` ≤300；`樣品尺寸` ≤50；`最小訂購量 (MOQ)` 設定時 ≥ 0 | 哪個欄位超過上限就在該欄位上被拒。 |
| 新增或編輯款式行 | 所屬報價單處於**草稿** | 儲存被拒，回應「僅草稿報價單可編輯」。 |
| 新增或編輯尺碼格 | `配色`已填入（≤100）、`尺寸`已填入（≤50）、`色碼` ≤50、`數量` ≥ 0、`單價` ≥ 0 | 哪個欄位超過上限就在該欄位上被拒。 |
| 新增或編輯尺碼格 | 所屬報價單處於**草稿** | 儲存被拒，回應「僅草稿報價單可編輯」。 |
| 送出 | 報價單處於**草稿** | 送出被拒，回應目前狀態。 |
| 核准 | 報價單處於**已送出** | 核准被拒，回應目前狀態。 |
| 拒絕 | 報價單處於**已送出** | 拒絕被拒，回應目前狀態。 |
| 修訂 | 報價單處於**已送出**、**已核准**或**已拒絕** | 修訂被拒，回應目前狀態。 |
| 轉換為訂單 | 報價單處於**已核准** | 轉換被拒，回應目前狀態；已轉換過的報價單被拒，回應「已轉換」。 |
| 產生 PI | 報價單處於**已核准**，且您租戶的「報價產 PI」已啟用 | 產生被拒（回應目前狀態，或回應您的租戶未啟用）。 |
| 上傳簽回 PI | 檔案為 **PDF** 或 **JPG** | 上傳被拒。 |
並**沒有**儲存時驗證會檢查**已核准**或**已送出**的報價單至少有一條款式行、
或每條款式行至少有一列尺碼。表單要求至少要有一條款式行起頭；
團隊才是決定提案是否就緒可送的把關者。
## 日期邏輯
報價單有一個具商業意義的日期：
* **`有效期限`**——這份提案過期的日期。由使用者在表頭設定；選填。
在轉換時不會傳遞到訂單（訂單自帶 `訂單日期` 與 `出貨日期`）。
平台會記錄兩個稽核時間戳：
* **`建立日期`**——報價單被開啟的當下。在報價單文件上印為開立日期。
* **`最後更新日期`**——報價單最近一次被寫入的當下。
報價單表頭上**沒有**`送出時間`、`核准時間`、`拒絕時間`或`轉換時間`——
每一次轉換的可見訊號，是**狀態**本身以及該列的`最後更新日期`時間戳。
多幣別處理：報價單僅承載`幣別`；報價單上不記錄匯率。
幣別換算是訂單階段的事——當報價單轉換時，匯率記錄在[訂單](/zh-Hant/modules/orders)上。
## 狀態與轉換
報價單會走過一條六態的生命週期。**草稿**是唯一可編輯的狀態；
其他每一個狀態都對編輯上鎖，僅在報價單上以明確的動作來轉換。
* **草稿**——報價單可編輯。表頭變更、行的新增／編輯／刪除、配色與尺碼編輯均可作用。
新報價單從這裡起算。
* **已送出**——報價單已交付給客戶。編輯被拒；變更的方式是**修訂**。
* **已核准**——客戶已接受提案。編輯被拒；報價單現在可以**轉換為訂單**、
可以**產生 PI**（在您的管理員啟用之處），也可在提案需要變更時被**修訂**。
* **已拒絕**——客戶已婉拒提案。編輯被拒；報價單仍可被**修訂**，以開啟一個調整條件後的新版次。
* **已取代**——報價單已被鏈上的修訂版次取代。編輯被拒；該列保留在歷史中，
可透過直接連結檢視，預設報價單清單中隱藏。
* **已轉換**——報價單已被轉換為訂單。編輯被拒；
自此刻起，被轉出的訂單才是這筆交易的活的紀錄。
轉換：
* （建立） → **草稿**：新報價單從此處起算，可完整編輯。
* **草稿** → **已送出**：使用者送出報價單。
* **已送出** → **已核准**：客戶接受。
* **已送出** → **已拒絕**：客戶婉拒。
* **已送出** | **已核准** | **已拒絕** → **已取代**（本報價單）並且在鏈上出現新的**草稿**報價單：
**修訂**會開啟一個新版次，深層複製表頭與每一條行與尺碼；
原本的報價單在同一動作中被標示為**已取代**。
* **已核准** → **已轉換**：使用者把報價單轉換為訂單。一張新訂單開出，
承接報價單的客戶、幣別、款式、配色、尺碼與單價，並保留一條回溯到來源報價單的連結。
詳見[變更的影響](#變更的影響)。
各狀態解鎖或鎖住的東西：
* **草稿**——完整編輯權限（表頭、款式行、尺碼）。送出已啟用。
* **已送出**——編輯被拒。核准、拒絕、修訂均已啟用。
報價單文件的下載已啟用。
* **已核准**——編輯被拒。轉換為訂單已啟用。
「產生 PI」在您的管理員為您租戶啟用時為已啟用。
修訂已啟用。簽回 PI 上傳已啟用。報價單文件的下載已啟用。
* **已拒絕**——編輯被拒。修訂已啟用。報價單文件的下載已啟用。
* **已取代**——編輯被拒。該列為唯讀；實質工作在鏈上最新的版次。
* **已轉換**——編輯被拒。由此報價單建立的訂單即活的紀錄；
被轉出的報價單仍作為「提案來源」的參考。
## 計算
報價單的計算在檢視時由尺碼格即時推算，表頭上不儲存任何總額。
每一格尺碼：
* **行小計** = `數量 × 單價`。任一輸入未設定時為空。
每一條款式行：
* **款式小計** = 該款式上每一格尺碼之`行小計`總和。
每一份報價單：
* **總計** = 全部款式行上每一格尺碼之`行小計`總和。顯示於報價單文件上。
總計以報價單的`幣別`表示。沒有任何折扣、調整或逐報價單的扣除——
文件上的數字即是所有報出之`數量 × 單價`的精確總和。
## 變更的影響
* **編輯草稿報價單的表頭或款式行。** 變更被儲存，下一次檢視即重新計算受影響的總額。
* **編輯草稿報價單的尺碼格。** 行小計與總計在下一次讀取時重新計算。
* **送出。** 報價單從**草稿**進入**已送出**；自此每一條編輯路徑均被拒。
客戶現在可以回應。
* **核准。** 報價單從**已送出**進入**已核准**。
**轉換為訂單**已啟用。
您的管理員為您租戶啟用時，**產生 PI**已啟用。**修訂**仍為已啟用。
簽回 PI 上傳已啟用。
* **拒絕。** 報價單從**已送出**進入**已拒絕**。
讓提案重生的方式是**修訂**——以調整後的條件開啟新版次。
* **修訂。** 目前的報價單被標示為**已取代**，同一條鏈上以下一個版次號開啟一份新的**草稿**報價單。
新報價單深層複製先前版次的每一條款式行與尺碼，並複製表頭
（客戶、幣別、有效期限、季節、產地、條款、備註）。
新報價單領取自己的新 `報價單號`；鏈上對前一列的連結保留。
`AI 封面備註`不會被複製——需要時請重新起草。
* **轉換為訂單。** 報價單從**已核准**進入**已轉換**。一張新
[訂單](/zh-Hant/reference/glossary#order)
開出，承接客戶、幣別、每一條款式行（連結到款式主檔之處沿用該連結）、每一個配色、
每一個尺碼，以及來自報價單的每一個單價。新訂單保留一條回溯到來源報價單的連結。
訂單自己的欄位——其編號、狀態與階段、出貨日期、貿易條件、出貨地與訂金條件——
由[訂單](/zh-Hant/modules/orders)管控，而非由報價單。
* **產生 PI。** 在您的管理員已啟用、且報價單處於**已核准**時，產生 PI 會開啟一份從報價單預填的新
[形式發票](/zh-Hant/reference/glossary#pi-proforma-invoice)——
明細項目、客戶、幣別與條款均沿用。報價單的狀態不變；您仍可將它轉換為訂單。
PI 即是客戶為安排付款而簽回的文件。
* **上傳簽回 PI。** 客戶簽回 PI 的 PDF 或 JPG 副本附到報價單上。
報價單的狀態不變。
* **下載報價單文件。** 報價單以單頁文件渲染，呈現客戶的收件人區塊、您租戶的賣方資訊區塊、
報價單表頭（`報價單號`、日期、幣別、季節、產地、有效期限、條款、備註），
以及逐款式區塊列出每一個配色及其尺碼、數量、單價與小計，附上以報價單幣別表示的總計。
下載不會改變報價單。渲染為依需求進行，因此每次下載皆反映報價單的目前狀態。
## 最佳實務
* **報價時開著成本表。** 成本表是逐款式算出工廠成本、客戶價與毛利的地方；
報價單則是提案。把報價單的單價取自成本表的客戶側數字，提案才會穩穩立基於真實毛利。
詳見[成本表](/zh-Hant/modules/cost-sheet)與
[建立成本表](/zh-Hant/modules/build-the-cost-sheet)。
* **每一條款式行都連結到其款式主檔。** 透過 `款式主檔編號` 連結，
能把行綁定到真實的款式紀錄，讓提案（以及它轉出的訂單）持續連到該款式的物料表、成本表歷史，
與下游的生產文件。自由文字行可用，但連結才能讓後續整條鏈容易追溯。
* **`有效期限`要審慎設定。** 清楚的截止日期告訴客戶提案何時仍然有效，
也提醒您的業務團隊何時該重整提案。
* **修訂——不要嘗試編輯已送出的報價。** 平台會拒絕該編輯，而先前的版次正是
「該輪實際所提議過什麼」的紀錄。
* **僅在提案完備時才送出。** 平台不會因為缺價或空款式而擋下送出；
商品開發是把關者。請在按下送出前，把款式、配色、尺碼與單價都走一遍。
* **儘快上傳簽回 PI。** 把簽回副本附到報價單上，可讓原始提案、由它產生的 PI，
以及客戶的簽回接受全部集中在同一份紀錄——好找、好稽核。
## 相關頁面
* [建立報價單](/zh-Hant/modules/create-a-quotation)
* [訂單](/zh-Hant/modules/orders)
* [成本表](/zh-Hant/modules/cost-sheet)
* [款式](/zh-Hant/modules/styles)
* [文件與轉換鏈](/zh-Hant/concepts/documents-and-conversion-chain)
* [Finance](/zh-Hant/modules/finance)
* [對帳單](/zh-Hant/modules/statement-of-account)