OM 配置工作簿 — 連動關係與系統指向說明
每一格「指向系統什麼物件、關聯到哪張表、為什麼必須這樣填、不這樣會怎樣」。看懂連動，就懂整本工作簿不是 17 張孤立的表，而是一張互相牽引的網。範例公司 FORESIGHT GROUP。
怎麼讀 · 連動強度圖例
| 標記 | 意思 |
|---|
| 🔗 跨表連動 | 這格的值指向另一張設定表建立的東西，或開啟/影響另一張表的運作。填錯/沒填會讓另一張表失效。 |
| 🧩 需先有主檔 | 這格從主檔資料(BU/LE/組織/客戶/品項/供應商/使用者)搜尋選取。那筆資料要先存在才選得到。 |
| ⚙️ 純設定值 | 自己決定的開關/數字/文字，不牽動其他表。 |
圖全局連動地圖（誰指向誰、為什麼）
整本的連動分四層，由下往上是「地基 → 通用 → 定價 → 承諾」。箭頭＝「指向/依賴」方向。
【底座】企業結構主檔：BU / Legal Entity / Inventory Org / 品項 / 客戶 / 供應商 / 使用者
↑ 幾乎每張表都從這裡「搜尋選取」(🧩)
【通用】③ OM 參數(地基) ──Start Approval=Yes──▶ ④ 訂單核准(被開啟)
③ Item Validation Org ──▶ 指向 Inventory Org │ ③ Coverage Start Date ──▶ ⑨ 保固
② 代運 ──▶ 需 ⑯ Buy 來源 + ③ Preparer
【定價鏈】⑥ 客戶檔 ──屬性──▶ ⑦ 分群 ──┐
⑧價目表 ⑨保固 ⑩折扣 ⑪護欄 ──綁定──▶ ⑫ 策略 ──┤
▼
⑬ 策略指派(⑦分群 × ⑫策略 收斂) ◀── 定價鏈終點
③/⑤ Pricing 參數 ◀──必須一致──▶ 彼此
【承諾鏈 GOP】⑯ 來源規則 ──放進──▶ ⑰ 指派集 ──設成──▶ ① Profile MSP_DEFAULT_ASSIGNMENT_SET
▼
⑭ 收集規劃資料(引擎有料) ──▶ ⑮ ATP 規則(指派到 Inventory Org) ──▶ 開始承諾交期
① MSC ──▶ Catalog(供 ⑰ 用類別指派) │ ① RCS ──▶ UOM Class(供 ⑨ 保固期間)
一句話：填表順序之所以「先建被指向的東西，再回來綁」，就是因為這張網——下游(⑰、⑫、④)要先存在，上游的指標(①MSP、⑬、③開關)才指得到。
①Profile Options 通用
| 欄位 | 連動 | 指向什麼 / 為什麼這樣填 / 連動理由 |
|---|
| Profile Display Code | ⚙️ 內建 | Oracle 原廠固定碼，用搜尋找出。不指向你的資料，是「要設哪顆旋鈕」的識別。 |
| Profile Level = Site | ⚙️ 純設定值 | 影響範圍。FORESIGHT 全公司一致 → Site。不牽動其他表。 |
| Value · MSP_DEFAULT_ASSIGNMENT_SET | 🔗 → ⑰ | 指向 ⑰ 的 Sourcing Assignment Set。GOP 做 ATP 承諾/供應分配時用它決定去哪找貨。連動理由：⑰ 沒先建好，這裡的 LOV 搜不到、GOP 找不到供應來源 → 交期承諾失敗。 |
| Value · MSC_SRC_ASSIGNMENT_CATALOG | 🔗 → ⑰(類別) | 指向一本 Catalog。當 ⑰ 用「品項類別」層級指派來源時，靠這本型錄認得類別。連動理由：沒設，⑰ 的 Category 層級指派無法運作。 |
| Value · RCS_DEFAULT_UOM_SERVICE_DURATION_CLASS | 🔗 → ⑨ | 指向一個 UOM Class(Time)。⑨ 保固/服務的「期間」(12 個月)用它表達。連動理由：有賣保固才需要；沒設保固期間單位無法計。 |
②Drop Ship Financial Flows 通用
| 欄位 | 連動 | 指向什麼 / 為什麼 / 連動理由 |
|---|
| Supplier Ownership Change Event | ⚙️ | 所有權轉移時點(ASN/AP Invoice Match)，影響財務入帳時機。純設定。 |
| Qualifier · Supplier | 🧩 供應商主檔 | 指定哪個供應商走代運。連動理由：該供應商(FG_Supplier_SZ)要先建主檔，且通常同一供應商也出現在 ⑯ 的 Buy DS 來源規則。 |
| Selling BU / Selling LE | 🧩 企業結構 | 對客戶開單/開發票的 BU 與法人，從企業結構主檔選。 |
| Receiving Trade Organization | 🧩 Inventory Org | 向供應商下單做帳的庫存組織(TPE1)。連動理由：同一組織也用在 ③ Item Validation、⑮ ATP、⑯/⑰ 來源指派——全公司的「組織」是共用主檔。 |
| Requisition BU | 🔗 → ③ | 發採購申請的 BU。連動理由：代運自動產生的採購申請會掛在 ③ 的 Preparer for Procurement 名下，兩者要搭配。 |
③Order Management Parameters 通用
| 欄位 | 連動 | 指向什麼 / 為什麼 / 連動理由 |
|---|
| Item Validation Organization | 🧩 Inventory Org | 指向項目主檔組織(FG_IMO)。連動理由：訂單行品項對著它驗證；與 ⑤ Pricing 的同名參數必須一致，否則定價/驗證對不上。 |
| Preparer for Procurement | 🔗 → ②⑯ | 採購代理人。連動理由：只有導入 ② 代運 或 B2B(⑯ Buy)會自動產生採購申請時才需要——沒這兩種流程可不填。 |
| Start Approval Process = Yes | 🔗 → ④(開啟) | 這是 ④ 訂單核准的總開關。連動理由：設 No，④ 寫的規則永遠不會被觸發；要核准就必須 Yes。 |
| Coverage Start Date | 🔗 → ⑨ | 保固服務起算日(出貨/交貨)。連動理由：對應 ⑨ 賣的 Coverage 品項；沒賣保固則無意義。 |
| Credit Check Failure / Activate Credit Check | ⚙️ + 信用模組 | 信用檢查行為。連動 Credit Management 設定(本工作簿外)；純行為開關。 |
| Default Price Periodicity UOM Class | 🔗 ↔ ⑤ | 週期計費 UOM。連動理由：與 ⑤ Pricing Parameters 的 Pricing 區須一致(同一套定價基礎)。 |
| Product Catalogs | 🔗 ↔ ⑤/⑪ | 品類定價/成本用的型錄。連動理由：與 ⑤ 一致；⑪ 護欄、品類定價都靠同一型錄。⚠️ 別誤填 Time。 |
④Sales Order Approval 通用
| 欄位 | 連動 | 指向什麼 / 為什麼 / 連動理由 |
|---|
| (前置) 整張規則 | 🔗 ← ③ | 依賴 ③ Start Approval=Yes 才會被觸發。這是整張表的連動命脈。 |
| Condition Attribute | 🔗 訂單資料 | 用訂單的欄位(Order Total Amount/Customer/Item…)判斷。連動理由：這些屬性來自實際銷售訂單，條件才有東西可比。 |
| Value (Primary = Yes) | ⚙️ 防呆 | 金額條件必加，否則對每種金額類型重複發核准。設定層防呆，無跨表。 |
| User Name (核准者) | 🧩 使用者主檔 | 指向 Worker/User(#FG_MGR01)。連動理由：該人要存在且有核准權限，否則訂單卡住無人可簽。 |
| Action = Assign to job level/group/hierarchy | 🧩 HCM/群組 | 若不是指定人，指向 Job Level/Approval Group/主管階層——這些要先在 HCM/設定建好。 |
⑤Pricing Parameters 定價
| 欄位 | 連動 | 指向什麼 / 為什麼 / 連動理由 |
|---|
| Parameter Name | ⚙️ 內建 | Oracle 內建固定參數清單，只填值。 |
| Item Validation Organization / Product Catalogs / Default Price Periodicity | 🔗 ↔ ③ | 與 ③ OM 參數的對應值必須一致。連動理由：OM 與 Pricing 是兩個引擎共用同一組基礎(同組織、同型錄、同 UOM)，不一致會算錯。 |
⑥Customer Pricing Profile 定價
| 欄位 | 連動 | 指向什麼 / 為什麼 / 連動理由 |
|---|
| Customer Name | 🧩 客戶主檔 | 選要分群的客戶。客戶要先存在。 |
| Revenue/Cost/Value/Rating/Size 五維度 | 🔗 → ⑦ | 給客戶貼的屬性標籤。連動理由：⑦ Pricing Segment 用完全相同的維度組合把客戶歸群——這裡貼的標籤要和 ⑦ 的條件對得起來，否則客戶分不進任何群。 |
⑦Pricing Segment 定價
| 欄位 | 連動 | 指向什麼 / 為什麼 / 連動理由 |
|---|
| 五維度條件 | 🔗 ← ⑥ | 對應 ⑥ 客戶貼的標籤。連動理由：系統拿客戶的 ⑥ 屬性比對這裡的條件，符合就歸入下面的 Segment。 |
| Pricing Segment(名稱) | 🔗 → ⑬ | 定義出來的區隔名(FG Key Account Group)。連動理由：⑬ Strategy Assignment 用這個區隔名把策略掛上去——名稱必須一字不差對得上。 |
| Precedence | ⚙️ | 多區隔符合時的優先序。純數字。 |
⑧Price Lists 定價
| 欄位 | 連動 | 指向什麼 / 為什麼 / 連動理由 |
|---|
| Type = Segment Price List | 🔗 → ⑫⑬ | 選 Segment 型，代表不直接綁客戶，而是透過 ⑫ 策略 → ⑬ 依 Segment 套用。連動理由：這個 Type 決定了它要靠定價鏈(⑫⑬)才會生效。 |
| Business Unit / Currency | 🧩 企業結構 | FG_TW_BU1 / TWD。要與 ⑫ 策略的 BU/幣別一致。 |
| Item | 🧩 品項主檔 | 逐品項定價。品項要先在品項主檔(同 ③ 驗證組織)存在。 |
| Base Price / Status=Approved | ⚙️ | 價格與狀態。Status 須 Approved 才生效(自身狀態，非跨表)。 |
| (整張表) | 🔗 → ⑫ | 連動理由：建好後要被 ⑫ 策略「綁定」才會被使用。 |
⑨Coverage Items 定價
| 欄位 | 連動 | 指向什麼 / 為什麼 / 連動理由 |
|---|
| Price List(掛在哪張) | 🔗 → ⑧ | 保固掛在 ⑧ 的同一張價目表。連動理由：共用價目表身分。 |
| Calculation Method = Coverage Item Price % | 🔗 被保品項 | 保固價＝被保商品售價的百分比。連動理由：連動到 ⑧ 被保品項的 Base Price(售價變，保固價跟著變)。 |
| Coverage UOM = Months | 🔗 ← ①RCS / ③ | 期間單位。連動理由：靠 ① RCS profile 設的 UOM Class(Time)才認得「月」；服務起算日由 ③ Coverage Start Date 決定。 |
⑩Discount List 定價
| 欄位 | 連動 | 指向什麼 / 為什麼 / 連動理由 |
|---|
| Item Level / Name | 🧩 品項主檔 | 折扣套用到哪個品項/類別。品項要存在。 |
| Tier 區間與折扣 | ⚙️ | 階梯量價數字。純設定。 |
| (整張表) | 🔗 → ⑫ | 連動理由：建好後被 ⑫ 策略綁定才會在計價時套用。 |
⑪Pricing Guidelines 定價
| 欄位 | 連動 | 指向什麼 / 為什麼 / 連動理由 |
|---|
| Constraining Value=70 / Violation=Warning | 🔗 ↔ ⑧ | 折扣上限護欄。連動理由：管控的是業務在 ⑧ 設 Allow Manual Adjustment=Yes 後的改價幅度——⑧ 開放改價、⑪ 設上限，兩者搭配。 |
| (整張表) | 🔗 → ⑫ | 連動理由：建好後被 ⑫ 策略綁定才生效。 |
⑫Pricing Strategies 定價
| 欄位 | 連動 | 指向什麼 / 為什麼 / 連動理由 |
|---|
| 綁定 Price List/Discount/Guidelines/Cost/Shipping | 🔗 ← ⑧⑨⑩⑪ | 策略是把各清單綁成一套的中樞。連動理由：這些清單(⑧⑨⑩⑪)要先建好才綁得進來；計價時：價目表取價→折扣→護欄→運費。 |
| Business Unit / Currency | 🧩 | 須與 ⑧ 一致。 |
| (整張表) | 🔗 → ⑬ | 連動理由：策略要被 ⑬ 指派給交易情境才會真正套用。 |
⑬Pricing Strategy Assignment 定價
| 欄位 | 連動 | 指向什麼 / 為什麼 / 連動理由 |
|---|
| Pricing Segment | 🔗 ← ⑦ | 指向 ⑦ 建的區隔。 |
| Pricing Strategy | 🔗 ← ⑫ | 指向 ⑫ 建的策略。 |
| (整張表) | 🔗 定價鏈終點 | 連動理由：這是「客戶 →⑥→⑦ 區隔 ×⑫ 策略」收斂之處。少了它，前面 ⑤–⑫ 全部不會被套用——所以是定價鏈最後且關鍵的一環。 |
⑭Collect Reference Data GOP
| 欄位 | 連動 | 指向什麼 / 為什麼 / 連動理由 |
|---|
| Reference Data / Collection Type | 🔗 → ⑮⑯⑰ | 把組織/品項/供應鏈資料收進規劃庫。連動理由：⑮ ATP 與 ⑯⑰ 來源要算，引擎得先有資料。所以順序上 ⑯⑰ 建好後要跑 ⑭，⑮ 才有料。 |
| Source System=OPS / Run | ⚙️ 排程 | 來源與排程。資料變動要重跑。 |
⑮ATP Rules GOP
| 欄位 | 連動 | 指向什麼 / 為什麼 / 連動理由 |
|---|
| Organization (指派) | 🧩 Inventory Org | 規則指派給哪個倉(TPE1/TXG1)。同一組織主檔。 |
| Promising Mode / Supply Types | 🔗 ← ⑭ + ⑰ | 承諾邏輯與納入的供應來源。連動理由：要靠 ⑭ 收進來的資料算可用量，並依 ⑰ 指派集找供應鏈——三者(⑭⑮⑰)合起來才完成承諾。 |
| Time Fence 天數 | ⚙️ | 純數字(30 天)。 |
⑯Sourcing Rules GOP
| 欄位 | 連動 | 指向什麼 / 為什麼 / 連動理由 |
|---|
| Source Type (Transfer/Buy/Make) | 🔗 ↔ ② | 去哪找貨。連動理由：Buy DS 規則對應 ② 代運的供應商；B2B/一般出貨也各對一種履約模式。 |
| Organization / Supplier | 🧩 主檔 | 來源組織/供應商，要先存在。 |
| (整張表) | 🔗 → ⑰ | 連動理由：規則本身不生效，要被 ⑰ 指派集「指派到組織/類別/品項」才會被 GOP 採用。 |
⑰Sourcing Assignment Set GOP
| 欄位 | 連動 | 指向什麼 / 為什麼 / 連動理由 |
|---|
| Sourcing Rule | 🔗 ← ⑯ | 指向 ⑯ 建的規則。⑯ 要先存在。 |
| Assignment Level (Item/Category/Org) | 🔗 ← ①MSC(類別) | 指派層級。連動理由：用 Category 層級時要靠 ① MSC profile 指的 Catalog 認得類別；越具體越優先。 |
| (整張表) | 🔗 → ①MSP | 連動理由：★建好後要回到 ① 設成 MSP_DEFAULT_ASSIGNMENT_SET 的值，GOP 才會採用——這條就是 GOP 鏈的閉環。 |
★最關鍵的 5 條連動（記這些就夠）
| 連動 | 為什麼重要 |
|---|
| ③ Start Approval=Yes → ④ 核准 | 開關沒開，核准規則永不觸發 |
| ⑥ 客戶屬性 → ⑦ 分群 → ⑬ 指派 → 套 ⑫ 策略(綁 ⑧⑩⑪) | 定價鏈，斷一節價格就算不出來 |
| ⑯ 來源 → ⑰ 指派集 → ① MSP → ⑭ 收資料 → ⑮ ATP | GOP 鏈，順序錯交期承諾失敗 |
| ③ ↔ ⑤ Pricing 參數一致 | OM 與 Pricing 共用基礎，不一致算錯 |
| ① RCS → ⑨ 保固期間；① MSC → ⑰ 類別指派 | 保固與類別來源各靠一個 profile 指向 |