報價單是什麼 從價格明細到訂單的資料起點

客戶回覆「照上次報價下單」，業務卻發現資料夾裡有三個版本，最後一次降價只留在通訊軟體。這個假設情境中，最容易出問題的並不是加總公式，而是公司無法確認究竟承諾了什麼。報價單在ERP中的作用，就從保存這份可供核對的交易資訊開始。

報價單通常記錄企業提供給客戶的商品或服務方案，包含品項、數量、計價方式及其他交易條件。在作業上，它與後續履約用的訂單有不同用途。

價格以外的欄位 決定後續能不能執行

一張只有品名與總價的報價單，未必足以讓其他部門安排工作。例如「設備一套」沒有寫清楚是否含安裝、運送或教育訓練，業務與交付單位便可能對工作範圍有不同理解。商品交易也一樣，規格、單位與數量不明確，可能直接影響備貨。

可以依業務型態整理需要的欄位：客戶及聯絡窗口、商品代碼與規格、數量及單位、單價與折扣、幣別與稅額處理、付款條件、交期、報價有效期間，以及不包含的服務項目。欄位不必越多越好，但會影響價格與履約的條件不能只靠口頭記憶。

報價轉訂單 是承接已確認的內容

假設報價包含A商品100件、B商品50件，客戶最後只接受A商品60件。若直接把整張報價轉成訂單而不核對，倉庫可能以為兩項商品都要備貨。自動帶入可以省去重打品項與價格，接受數量與交付安排仍需要確認。

這也是「來源資料」與「執行資料」的差別。報價保留提出過的方案，訂單記錄目前要執行的內容；兩者應能互相追查，但不必永遠完全相同。若企業允許同一份報價分次成立訂單，系統還需要追蹤已轉出的明細與數量，防止重複建立。

Ragic官方以報價轉訂單說明資料拋轉：可以設定來源與目的表單欄位對應，將既有資料帶到新紀錄。這提供了轉單機制的例子，實際的核准條件、分批規則與價格處理仍要另行規劃。

版本管理要保存客戶當時看到的內容

報價修改很常見，真正需要管理的是哪個版本已經寄出、哪個版本獲得接受。若把原報價直接改掉，之後就難以核對客戶回覆時看到的條件。可採取保留修訂版本、記錄生效狀態與附件的方式，讓內部與客戶端有一致的比對基準。

官方產品文件中也可見啟用後鎖定報價、修訂時增加版本識別的設計。這不代表每套系統都有相同操作，但說明了版本管理應處理的問題。

最新價格不應不明原因地覆蓋歷史交易

假設商品本月單價由100元調為110元，企業仍需知道上個月已確認訂單的原成交價格。如果歷史訂單每次開啟都重新抓最新價目表，報表與客戶認知便可能不一致。導入時應區分「帶入目前預設值」和「保存當時交易值」。

訂單成立後若真的變更價格，應留下變更原因、核准與適用範圍，而不是讓主檔更新悄悄改動既有交易。至於出貨、請款與退貨，需要依各自的交易依據承接資料，不能一律回到最早的報價當作最後答案。

對主管而言，報價進度也應與訂單成果分開呈現。已寄出報價、等待回覆、客戶要求修改與已接受，都代表不同工作。如果把所有報價金額加總成已成交金額，便會誤讀營運狀況。可以追蹤有效期間、下一次聯絡時間與未接受原因，讓資料支持後續跟進；涉及成交率時，也要先定義統計期間與分母，避免不同報表互相比不出意義。

報價管理讓交接更有依據

對業務而言，完整報價可降低反覆查找條件的時間；對倉庫與交付人員而言，它讓工作範圍更清楚。企業也能依保留的版本與結果，分析哪些方案被接受、哪些條件經常修改。這些分析必須建立在資料有持續更新的前提上。

報價單在系統中的意義，因而不只在產出一份好看的文件。當它能保留版本、銜接訂單並追查後續差異，前端溝通才有機會變成各部門共同使用的執行依據。