SAP SD：它的功能，以及導入時哪裡容易出問題

SAP SD（銷售與配銷）負責 SAP 中的訂單到收款流程：報價、銷售訂單、交貨、開票，以及與財務的交接。在 S/4HANA 上，它的變化會影響專案範疇。客戶變成業務夥伴，信用管理移到 SAP Credit Management，回饋金移到條件合約，開票則直接過帳到 Universal Journal。這篇指南寫給銷售營運主管、財務主管與專案經理，讓他們了解 SD 做什麼、哪裡會出問題。第二個問題的簡短答案是：客戶主檔資料、定價條件、可用性檢查與科目決定。上線前，請用真實資料測試這四項。

在一次完整 SAP 導入後的上線中，訂單到收款的各個步驟都完全依照設計建置。在流程圖上看起來沒有問題。卻沒有人檢查庫存更新是怎麼從生產端傳進來的。

業務告訴客戶五天。製造部門知道實際上接近十天。

這個落差付出的代價不只是交貨延誤。它損失的是信任，而信任比一個組態設定更難重建。

SD 位於物流鏈的最前端。它透過一連串單據，把客戶的興趣轉成發票：

1. 詢價單：客戶詢問價格或供貨情況
2. 報價單：附有效期限的正式價格與交貨報價
3. 銷售訂單：客戶確認下單，執行可用性檢查，並確認交貨日期
4. 交貨：倉庫揀貨與包裝；貨物發出時扣減庫存
5. 開票：建立發票及其會計憑證
6. 收款：財務將收到的款項沖銷對應的未清項目

每一份單據都會參照前一份。這個單據流（document flow）讓訂單到收款可以追溯。如果這條鏈是乾淨的，您可以把每張發票追溯回最初的請求。如果單據不照順序建立，或被繞過，報表就會出錯，爭議隨之而來。

1. 01詢價單詢問價格或供貨情況
2. 02報價單附有效日期的正式報價
3. 03銷售訂單可用性檢查確認日期
4. 04交貨揀貨、包裝、貨物發出
5. 05開票發票與會計憑證
6. 06收款財務沖銷未清項目

每張發票都能追溯回最初的請求

做得好的話，這條鏈能消除人工交接。有一位製造業客戶在 SD 上線後，把訂單到收款的週期縮短了 40%，主要是消除了業務、倉庫與財務之間的交接。

銷售訂單與可用性檢查

銷售訂單處理是 SD 組態工作量最集中的地方：訂單類型、項目類別、排程行與可用性檢查。

可承諾量（Available-to-Promise，ATP）是對業務最關鍵的部分。它會依庫存、預計收貨與既有承諾，檢查能否滿足客戶要求的日期。組態設定得當，業務告訴客戶的就是系統真正能承諾的事；設定不當，業務告訴客戶的就只是自己希望能交的事。

在開頭提到的那次上線中，沒有人檢查庫存更新是怎麼從生產端傳進來的。業務報給客戶的日期，工廠根本做不到。

定價與條件

定價是 SD 中最被低估的設定。它看起來很簡單，直到第一次發票爭議出現。

SD 的條件技術（condition technique）處理基本價格、客戶折扣、數量級距、附加費、運費與稅額。每個元素都是一個條件類型，搭配一個存取順序，而條件記錄則存放數值。

我最常看到的定價問題：上線時設定的舊定價條件，從來沒有更新過。業務重新談了折扣，卻沒有人去更新 SD 裡的條件記錄，發票就開錯了，爭議最後落到應收帳款頭上。

定價治理是流程決策，不是組態決策。必須有人負責維護條件記錄。

出貨

交貨處理涵蓋揀貨、包裝與貨物發出。貨物發出是關鍵事件：它會過帳庫存扣減、把交貨單放進待開票清單，並記錄實際交貨日期。裝運點與路線決定機制，控制交貨單如何建立。配銷網路複雜的公司，會再以 SAP Transportation Management（TM）擴充這部分。

開票、科目決定與稅務

開票把交貨轉成發票，並建立會計憑證。科目決定會依據銷售組織、客戶與物料的科目指派群組，以及條件類型，把每個開票項目對應到收入、稅額與其他總帳科目。一旦設定有誤，發票就會過到錯誤的科目，財務到月底才發現。

稅額決定同樣脆弱。它取決於客戶的稅務分類、物料的稅務分類，以及交貨的國家或轄區。只要對不上，就可能對應稅的銷售開出零稅額發票，或對免稅的銷售課了稅。

信用管理

信用檢查會凍結或標記那些會讓客戶超過信用額度的訂單。它只有在額度持續維護時才有用。上線時設定的固定額度，隨著付款行為與交易量改變，就失去意義了。

當額度低於客戶的正常訂單金額時，每一張訂單都會被自動凍結。業務團隊接著就學會直接解除凍結，而不是申請額度檢討。

那不是信用管理。那是一種變通做法。

以下是 SD 的結構元素，以及各自連結到哪裡。

結構元素	在 SAP SD 中的用途	主要連結
銷售組織	最上層的銷售單位，負責銷售條件與責任	指派給 FI 中的公司代碼
配銷通路	產品如何送達客戶（批發、零售、直銷）	控制定價、主檔資料與夥伴決定
產品群組	銷售組織內的產品群組	用於報表與輸出的物料分組
銷售範圍	銷售組織、配銷通路與產品群組的組合	每份銷售單據與每筆客戶記錄都必須有
銷售辦公室	地理區域的銷售單位	區域報表與夥伴決定
銷售群組	銷售辦公室內的團隊	訂單上的負責人員
裝運點	貨物出貨的地點	把 SD 連結到倉儲管理與運輸
工廠	生產或供貨單位	庫存來源，與裝運點相連

銷售範圍是實際運作的單位。客戶的銷售資料依銷售範圍維護，每份銷售單據也都在某個銷售範圍中建立。許多資料移轉在這裡跌倒：舊系統的客戶記錄若無法乾淨地對應到銷售範圍，載入之前就需要真正下功夫準備。

如果您是從 ECC 升級，以下這些 SD 的改變需要納入專案範疇。SAP 在 S/4HANA 文件中把這個領域歸在「Sales」之下，不過多數團隊仍稱它為 SD。

ECCS/4HANA

客戶ECC客戶主檔記錄S/4HANA具客戶角色的業務夥伴

信用管理ECCFI-AR-CRS/4HANASAP Credit Management（FIN-FSCM-CR），非選配

回饋金ECCSD 回饋金處理，需從索引重建S/4HANASettlement Management 中的條件合約

可用性檢查ECC基本的產品可用性檢查S/4HANA進階 ATP：分配、缺貨訂單、替代工廠

開票ECCFI 與 CO 分別對帳S/4HANAUniversal Journal（ACDOCA）中的單一行項目

收入認列ECC許多專案自行開發遞延邏輯S/4HANASAP Revenue Accounting and Reporting，需另行授權

1. 客戶變成業務夥伴。 客戶主檔資料透過具客戶角色的業務夥伴來維護。在系統轉換時，必須在轉換執行前先設定好客戶與供應商的整合（customer-vendor integration）。
2. 信用管理移到 SAP Credit Management。 ECC 的信用管理（FI-AR-CR）在 S/4HANA 中不再提供。SAP Credit Management（FIN-FSCM-CR）是它的替代方案，所以轉換時必須移轉信用資料與設定。這不是選配。
3. 回饋金移到條件合約。 傳統的 SD 回饋金處理由 Settlement Management（條件合約管理）取代。回饋條件會立即生效，而不必再從索引重建。
4. 進階 ATP。 S/4HANA 的進階 ATP新增了產品分配、缺貨訂單處理、跨工廠的替代式確認、交貨放行與供給指派。在 S/4HANA Cloud 中，這些功能包含在標準授權內。地端部署一旦啟用，則需要專屬授權。
5. 開票直接過帳到 Universal Journal。 FI、CO 與獲利分析共用 ACDOCA 中的同一個行項目，省去了 ECC 時代 FI 與 CO 之間的對帳工作。代價是：科目決定一旦出錯，就是立即過到錯誤科目，而且在行項目層級就看得到。
6. 收入認列。 對於適用 IFRS 15 的多組成要素合約、訂閱或長期服務，SAP Revenue Accounting and Reporting 取代了許多 ECC 專案自行開發的遞延邏輯。它需另行授權，而且要在上線前設計好，不能等到年底才發現。

Clean Core 改變了 SD 客製化的處理方式。在公有雲上，不可能在核心裡寫客製程式碼。在私有雲與地端部署上雖然可行，但會讓每次升級都更困難。多數舊的定價 Z 常式，都可以用標準條件類型、公式與 BAdI 取代。真正剩下的部分，應放在 SAP BTP 上的 side-by-side 擴充。我的 Clean Core 指南談到了這個決策。

SD 與 MM

可用性檢查從 MM 讀取庫存，貨物發出則過帳庫存異動。如果庫存資料有誤，ATP 的結果就不可靠。如果因為庫存其實不在裝運點而導致貨物發出失敗，交貨就無法完成，開票也會卡住。要靠主檔資料與紀律，讓兩邊保持一致：不要用手動調整庫存的方式繞過標準過帳。

SD 與 PP

在接單生產（make-to-order）情境中，銷售訂單可以直接驅動生產，所以確認的日期就成了由生產訂單支撐的承諾。物料主檔中的策略群組，控制銷售訂單與預測之間如何互動。設定錯誤的話，兩者會相加而不是相互抵銷，計畫執行會高估需求，接著就是生產過剩。我的 SAP PP 指南談到了計畫面。

SD 與 FI

開票憑證就是介面。每張發票都會建立一份會計憑證，把收入、稅額與客戶未清項目過帳到 Universal Journal。客戶主檔上的付款條件決定到期日。當業務在沒有告知財務的情況下談妥條件，系統就會執行財務從未同意的條件。

如果 SD 設計把所有收入都視為在開票時認列，而合約的規定並非如此，事後補救的代價很高。在設計簽核之前，就要先與財務談定收入認列方式。關於整合在財務面的部分，請參閱我的 SAP FICO 指南。

有四個失敗點造成了上線後的大部分痛苦。

客戶主檔尚未就緒。 每個欄位對下游都很重要。缺少稅務分類，稅額就會算錯。缺少付款條件，FI 就無法計算到期日。缺少裝運條件，交貨排程就會出問題。資料量比計畫假設的大，來源資料也比預期的差，而且清理工作需要業務做決定。要及早開始，把它當成業務工作流，而不是技術性的載入作業。我寫的為什麼 SAP 資料移轉會失敗談到了做法。

定價條件沒有維護。 上線時設定、之後沒有人檢視的條件，在第一年內就會變成發票爭議。

可用性檢查與現實脫節。 ATP 讀到過時的資料，就會產生業務兌現不了的承諾。要用真實的生產與庫存情境來驗證，而不是單元測試用的乾淨測試資料。

科目決定的缺漏到上線後才被發現。 要用實際的會計科目表、稅碼與物料群組來測試。稅碼對不上，可能會讓訂單被擋下來，或在沒有人察覺問題之前就引發發票爭議。

這張表是我會在使用者驗收測試（UAT）簽核之前逐項檢視的清單。

風險	影響	因應做法
客戶主檔不完整	發票錯誤、交貨失敗、FI 過帳缺漏	及早啟動資料工作流；在移轉前，先依銷售範圍定義必填欄位
定價條件過時	發票爭議、收入不正確	上線時就指定條件記錄的負責人與檢視週期
ATP 與 PP 或 MM 脫節	交貨承諾不可靠	在 UAT 簽核前，以真實的計畫情境測試 ATP
科目決定有缺漏	收入過到錯誤的科目	以真實的會計科目表與完整的稅碼組合測試
解除信用凍結變成例行公事	風險曝險失控、應收帳款爭議	落實額度檢討；上線後頭 90 天追蹤手動解除的紀錄
輸出未經測試	發票與交貨單無法自動發送	上線前，以真實的列印與電子郵件路由測試每種輸出類型
付款條件不一致	到期日錯誤、現金預測失準	在載入客戶資料之前，先讓業務與財務談定條件

如果業務團隊習慣直接解除信用凍結，而不是申請檢討，要在最初的九十天內處理，趁習慣還沒養成。

SAP SD 是什麼？它的功能是什麼？

SAP SD（銷售與配銷）管理訂單到收款：詢價、報價、銷售訂單、交貨、開票，以及與財務會計的交接。它的單據流把每個步驟連結到前一步，所以每張發票都能追溯回原始訂單。它與 MM 整合處理庫存與貨物發出，與 PP 整合處理接單生產與可用性，並與 FI 整合處理收入、稅額與應收帳款。

SAP SD 的組織結構是什麼？

實際運作的單位是銷售範圍：由銷售組織、配銷通路與產品群組組合而成。每份銷售單據都在某個銷售範圍中建立，客戶的銷售資料也依銷售範圍維護。銷售辦公室與銷售群組位於其下，用於報表與責任歸屬。在物流面，裝運點與工廠決定貨物從哪裡出貨。載入客戶資料之前就要把結構定好，因為日後要改，就得重新載入資料。

SAP SD 的定價如何運作？

定價採用條件技術。每個價格元素是一個條件類型，由存取順序決定適用哪一筆條件記錄，再由定價程序依序組合這些條件類型。多數定價爭議的根源，是商業條件改變時沒有更新條件記錄，而不是組態設定的錯誤。

SAP S/4HANA 中的進階 ATP 是什麼？

進階可承諾量（aATP）是 S/4HANA 的可用性檢查。除了基本的產品可用性檢查之外，它還新增了產品分配、缺貨訂單處理、跨工廠的替代式確認、交貨放行與供給指派。這些功能包含在 S/4HANA Cloud 中，地端部署一旦啟用則需要專屬授權。供給受限，或分配規則很重要時，再使用它們。對於供應鏈穩定的公司，設定得當的基本檢查往往就夠了。

SAP SD 如何與財務會計整合？

透過開票憑證。把開票憑證轉給會計後，會建立一筆包含收入、稅額與客戶未清項目的日記帳分錄。科目決定依銷售組織、科目指派群組與條件類型，決定總帳科目。稅額取決於客戶與物料的稅務分類。客戶主檔上的付款條件設定到期日。對於適用 IFRS 15 的情況，SAP Revenue Accounting and Reporting 會遞延收入，並隨時間認列。

從 ECC 轉到 S/4HANA 時，SAP SD 有哪些改變？

客戶變成業務夥伴。信用管理從 FI-AR-CR 移到 SAP Credit Management，而且是強制的。回饋金處理由 Settlement Management 中的條件合約取代。進階 ATP 可以使用，開票則過帳到 Universal Journal。這些都要及早納入範疇，因為每一項都需要組態設定、資料移轉與測試。

SAP SD 導入最常見的錯誤有哪些？

有五個錯誤一再出現。低估客戶主檔資料。上線後讓定價條件沒有負責人。只用乾淨的資料測試 ATP。用簡化的資料測試科目決定。沒有對輸出做端到端測試。最後一項最容易被忽略。發票沒有自動發出去時，就會有人開始手動列印，這個變通做法就變成了常態。