一句話：reference 類分析快照，記錄荒野旅人現行 Google Sheets 主檔（「荒野旅人ERP溝通範本」）疊在 BV 資料之上的運算層，逐項對照 ERP 是否已涵蓋、缺口、schema 現況，作為後續模組 spec 的設計來源；「做了 / 沒做」最終以 roadmap 為準，本檔不覆蓋其狀態。
來源：GS 主檔 8 分頁，公式還原於 2026-05-30（總表-六月 / 七月 / 日本、內表、出團名單-自動化、裝備、住宿、登山分級-審核器）。
前提澄清（2026-05-30，user）：
'BV資料'（電商平台的客戶 + 訂單資料）已原生整合進 ERP（user/member_profiles/orders/travelers/payments）。因此 GS 中「反查 BV 對帳 / 從 BV 拉名單 / 湊庫存狀態」整層已被結構性取代，不是缺口。本檔只盤點疊在資料之上的運算 / 邏輯層。
| GS 機制 | ERP 對應 | 說明 |
|---|---|---|
| BV 客戶資料 | user + member_profiles | 客戶帳號 + 偏好原生在租戶庫 |
| BV 訂單資料 | orders + travelers + payments | 訂單 / 同行旅客 / 收款原生 |
| 總表「客N 庫存M / 未正常下架」對帳 | departures.booked_count / capacity | 成團 / 庫存是 race-safe 原生欄位，不需對帳 |
| 內表「從 BV 拉名單」 | travelers（綁 order） | 名單原生，不需匯入 |
| 月份 / 行程字串解析 | 結構化欄位 | departures.departure_date 等取代 SWITCH/SCAN 月份解析 |
對應財務「第一大瓶頸：BV→GS 內表人工」。ERP 讓訂單原生落庫 = 結構性解掉，毋須對帳層。這也是 plan-8（legacy commerce / BVShop 遷移）的核心價值。
| # | GS 運算層 | ERP 現況 | schema 現況 | 缺口 | 財務優先* | 對應 spec（2026-05-30） |
|---|---|---|---|---|---|---|
| 1 | 登山分級審核器（越級報名 gating） | 沒有 | trips 無難度欄 | trips 難度 / 評鑑分欄 + 演算法 + 報名歷史查詢 | 4 | climbing-screening |
| 2 | 出團前置 deadline 警戒（入山申請 / 下載 · 登山險 · 旅責險 · 檢查，工作天倒數 RED/ALERT/QUEUE） | 沒有 | departures 無申請 / 保險 / 檢查日期欄 | 多組日期欄 + 工作天計算 + 假日表 | 1 | departure-prep（與 document-expiry 互補） |
| 3 | 旅客資料驗證器（內表） | 部分 | travelers 欄位足夠 | 驗證規格（非欄位）：身分證 checksum、緊連 ≠ 隊員、手機 ≠ 緊連、訂金 + 尾款 = 應付、民國 ⇄ 西元 | 1–2 | traveler-validation |
| 4 | 許可證文件附掛（出團名單：入山許可證 / 人員名冊 / 山屋床位核准證 / 入園證） | 沒有 | 無 per-departure 文件表 | per-departure 文件 metadata + 連結 | 1 | departure-prep §2.2 |
| 5 | 裝備庫存彙總 + 超收 / 剩餘警示 | 沒有 | 無 equipment schema | 裝備需求解析 + 庫存比對警示 | 3 | equipment-inventory |
| 6 | 包團 / 集體計價（集體應付 / 訂金 / 尾款，以群組鍵彙總） | 一般集體已涵蓋 | tour line 有 party size；應收由 charge lines 聚合 | 一般集體（一單多人）已涵蓋；整梯包團議價為缺口 | 2–3 | trip-pricing §5 |
* 財務影響矩陣自評（1–5）：會員 / 體能安全篩選 = 4、行動端 = 4、嚮導裝備調度 = 3、財務對帳 = 3、境外帳務 = 2、證件抽籤管理 = 1。
本批 spec 產出（2026-05-30）：依「高優先寫滿、低優先 stub」拍板 —— 缺口 1/3/6 寫到可實作深度，2/4/5 佔位 stub。設計決策（user 拍板）：審核器能力分 = 自填為主 + ERP 訂單歷史輔助；判不過 = 警示 + 轉人工審核（不硬擋）。
以下為從 GS 公式還原的演算法，寫對應 spec 時可直接抄。
輸入：① 每條行程的「評鑑分數」（難度，查表）+「高山經驗需求」旗標（Y / 空）；② 客人填過往爬過的行程。
演算法：
B18 = 最高分 + 第二高 × 0.3 + 第三高 × 0.1 + 1
（由最難那座主導，次高 / 第三高遞減加成）。X9：行程需求 = Y 且客人未具高山經驗 → 不通過（「缺乏高山經驗」）；否則通過。W9 = 能力分 − 行程難度：
≥ 0.2 → 第 1 級（輕鬆通過）≥ −0.3 → 第 2 級（通過）≥ −0.5 → 第 3 級（勉強 / 建議評估）≤ 1 → 「無須審核」（短路）。ERP 需補：trips（或 departures）新增「難度 / 評鑑分數」+「高山經驗需求」欄；客人「過往報名紀錄」= orders JOIN user，但要能映到行程難度才算得出能力分 → 故與 CRM 報名歷史耦合。
每團每類期限（入山申請日、入山下載日、登山險、旅責險、檢查），用 NETWORKDAYS.INTL(TODAY(), 期限, 1, 特別假日) 算工作天距，輸出狀態：
REDALERTQUEUEREDERP 需補：per-departure 各期限日期欄、台灣假日表、工作天計算。對應財務「一次性自動壓 deadline + 自動化醒目輔助」。注意：這與 document-expiry（護照效期）是兩回事，別混為一談。
逐筆吐錯：姓名空 / 性別錯誤（非 男 · 女 · M · F…）/ 生日空 / 生日錯誤（未來人？· 超過 100 歲）/ 身分證 checksum（字母轉碼 + 權重 1,9,8,7,6,5,4,3,2,1,1 mod 10）/ 電話 · 信箱 · 地址空 / 緊急聯絡人空 / 緊急聯絡人為隊員 / 手機與緊連電話重複 / 收款差（訂金 + 尾款 ≠ 應付）。另含民國 ⇄ 西元生日轉換、免驗名單（ECPTLIST）、包團集體金額以群組鍵彙總。
ERP 需補：traveler 建檔 / 編輯的 server 驗證規格（欄位已足夠）。對應財務「各內表人工操作客人資料，財務端有失誤風險，建議改善」。
出團名單頁每梯次掛一組 HYPERLINK(drive檔)：入山許可證、入山人員名冊、山屋床位核准證、入園證。ERP 需補：per-departure 文件清單（類型 + 連結 / 上傳）。
行程裝備以 睡墊*3 登山杖*2 字串記；跨日期窗 SUMPRODUCT + REGEXEXTRACT 彙總各品項需求 → 比庫存：庫存 − 需求 < 0 → 超收（缺）、≤ 2 → 剩餘N。另算現場付現金額（品項 × 價目表）。ERP 需補：裝備品項 / 庫存 schema + 需求彙總。住宿同模式（room-assignment 已有住宿成本）。
'BV資料'、'住宿裝備資料連動'、'範例'、'小編用' 等被公式參照的分頁不在本次匯出的 8 頁內（IMPORTRANGE 或另一檔）。其中 'BV資料' = 電商客戶 + 訂單，user 已確認整合完成，故非缺口；另三者為輔助資料（假日表 小編用、住宿裝備對照 住宿裝備資料連動），寫對應 spec（deadline 警戒 / 裝備）時可再索取。trips 難度欄。建議優先 brainstorm 成 spec。| 版本 | 日期 | 變更 | Commit |
|---|---|---|---|
| 1 | 2026-05-30 | 初版：GS 主檔公式還原 + ERP 缺口對照（BV 資料已整合前提） | — |