1. 這是什麼工具？
Inventory Tool 是日常營運與每月出貨決策工具。首頁先回答「今天有沒有異常」，Inventory Tool 再讓你決定每個 SKU 要出多少貨、什麼時候出、箱規怎麼帶到供應鏈與 Seller Central。
網址：https://sk-inventory.pages.dev
首頁 + 5 個分頁
| 位置 | 用途 | 什麼時候用 |
|---|
| 首頁 Dashboard | 資料新鮮度、費用變動、銷售異常、庫存警示 | 每天先看 5 分鐘 |
| 庫存預估 | 主畫面：所有 SKU 的銷量預估、出貨建議、S1/S2 手動出貨量 | 每月 1 號決策、平日追蹤 |
| 成效追蹤 | 看上幾個月預估準不準、哪些 SKU 老是預估錯 | 月初檢討 / 校正流程 |
| 小時訂單 | 看每小時與每日訂單流量趨勢 | 監控銷量波動 |
| 箱規 | 維護每個產品的裝箱規格（每箱幾件、重量、尺寸） | 新品、箱規變更、建倉前確認 |
| 裝箱明細 | 上傳 Amazon box label PDF，產出供應鏈裝箱明細 xlsx | shipment label 出來後 |
資料來源
每天自動跑： SP-API（Amazon 後台）→ 拉訂單、FBA 庫存、費用資料 → 計算預估、成效、警示 → dump JSON → 部署到 Cloudflare Pages。
你打開時看到的數字： 是最近一次 pipeline 產生的版本。首頁的資料新鮮度列會顯示「訂單 / FBA 庫存 / 月度費用 / 變異追蹤」各自是否更新；庫存預估左上角只顯示一個最新更新時間，避免三個時間戳造成混淆。
2. 首頁 Dashboard
每天先打開 首頁 Dashboard。它不是給你做細節編輯，而是快速回答：「今天資料可信嗎？有沒有馬上要處理的營運異常？」
| 區塊 | 看什麼 | 判斷方式 |
|---|
| 資料新鮮度 | 訂單、FBA 庫存、月度費用、變異追蹤 | 今天 / 昨天 = 正常；多天前 = 先不要用它做重大決策 |
| FBA 費用變動 | biweekly fee check 是否發現 FBA fee 新增、下架、上升或下降 | 費用上升要檢查毛利；費用下降可更新成本假設 |
| 銷售異常 | 7D vs 30D 的暴跌 / 暴漲 SKU | 暴跌要查 stockout、listing、價格；暴漲要提前看庫存 |
| 庫存警示 | Shipping Plan 紅底、確認 stockout、即將斷貨 | 點 SKU 連回庫存預估表處理 |
原則：Dashboard 是決策前提。只要資料新鮮度變黃或變紅，先確認 pipeline 是否正常，再看庫存預估表。
3. 每月出貨決策流程
每月 1 號是決策日。打開「庫存預估」分頁後的標準流程：
1先看資料日期
確認左上角最新更新日期是今天或合理時間；如果資料舊，先不要直接下出貨決策。
2設定出貨日期
「下個月出貨日」「下下個月出貨日」兩個日期欄會同步到雲端，其他裝置打開也會看到同一組日期。
3掃 Shipping Plan 紅底
紅底代表目前庫存撐不到目標月 + buffer，需要優先決定 S1 / S2 出貨量。
4Hover 看細節
Sales/day、各月預估、parent 季節係數 sparkline 都有 hover 細節，先看原因再改數字。
5必要時 override
可手動改 Sales/day、S1 出貨、S2 出貨；S1/S2 欄位灰字只是建議值，空白代表尚未人工確認。
6記筆記（optional）
點 SKU 旁邊的 📝 → 寫下你 override 的原因（例：「競品出 Lightning Deal」、「自己降價衝排名」），可以貼圖。
7匯出與交接
「出貨計畫」給內部與供應鏈；「建倉」給 Seller Central；KPGS 會另外帶出手套統計。
4. Sales/day 怎麼來的
Sales/day 是預估系統的最關鍵輸入。其他所有預估數字都是從它推算出來的。
計算公式
完整月：Sales/day = base month 銷量總和 ÷ base month 天數
當月 partial：Sales/day = 本月已發生銷量 ÷ 已完成天數。系統會避開今天尚未完整的資料，並在畫面標示 base month 是否為 partial。
例：4 月份某 SKU 賣了 1500 件 → Sales/day = 1500 / 30 = 50/日。
為什麼用「上月」不是「過去 30 天」？
- 季節性對齊：5 月做決策時，4 月的銷量是「跟今年 5 月最像」的近期樣本（同樣是春天、同樣的市場狀態）。「過去 30 天」會跨越 4/5 月分界，混進兩個月的不同情境。
- 對應公式：預估 5 月銷量時，公式是
Sales/day × (5 月季節係數 / 4 月季節係數) × 5 月天數。這個公式假設 Sales/day 是「base 月（= 4 月）的日均」，所以 base 月明確很重要。
- 現在的自然漂移 policy：沒有「鎖定報表」按鈕。每次 pipeline 更新後，畫面會自然使用最新 base month；若要回看舊版本，用「歷史報表」下拉選單。
關鍵問題：stockout 怎麼處理？
⚠️ 重要
如果上月有 stockout（斷貨日），那些日子賣 0 件會被平均進去 → Sales/day 系統性偏低 → 下個月算出的需求也會偏低 → 出太少貨 → 又斷貨 → 惡性循環。
這就是為什麼系統會偵測 stockout 並提供「建議補正值」（見第 5 節）。
多月預估的核心公式
預估某月銷量 = Sales/day × (該月季節係數 / 上月季節係數) × 該月天數
季節係數（Coefficient）
系統從過去訂單資料推算每個 parent / product line 的 12 個月季節指數，平均值約為 1.0。parent row 旁邊的小長條圖就是該線的季節係數 sparkline：深藍標出 base month，淺藍標出 S1 / S2 對應月份。
| 月份 | 1月 | 2月 | 3月 | 4月 | 5月 | 6月 | 7月 | 8月 | 9月 | 10月 | 11月 | 12月 |
|---|
| 係數（範例） |
0.85 |
0.90 |
0.95 |
1.00 |
1.05 |
1.10 |
1.15 |
1.20 |
1.10 |
1.00 |
0.90 |
0.80 |
（實際係數從 SP-API 訂單資料動態算出，並非固定值）
實際算例
SKU：assorted_bs_9p3t（嬰兒襪 黑白灰組 3-5 歲）
- 4 月銷量總和：1500 件 →
Sales/day = 1500/30 = 50/日
- 4 月係數 = 1.00、5 月係數 = 1.05、5 月有 31 天
- 預估 5 月銷量 =
50 × (1.05 / 1.00) × 31 = 1627 件
主表欄位怎麼讀
| 欄位 | 意思 |
|---|
FBA | 目前 FBA 倉庫可賣庫存 |
Shipping | 已在路上的庫存（in-transit + 未上架） |
Sales/day | 核心輸入。可手動覆蓋；hover 可看 7/14/30/90/180D velocity 與修改紀錄。 |
預估 pre-target | 從目前 base window 到目標出貨前的累計需求。表頭會動態顯示實際日期範圍。 |
期末庫存 | 目標日期當天預估剩餘庫存（= FBA + Shipping + 手動出貨 − 累計需求）。 |
預估 target / target+1 | S1 / S2 對應月份的預估需求。 |
預估 +20D | 目標月需求再加上 buffer 天數。Buffer 可改 +14D / +20D / +30D。 |
Shipping Plan | = 期末庫存 − 預估 + buffer 需求。負值（紅底）= 不夠 → 需要出貨；正值（綠字）= 庫存夠。 |
原本預估 | 上一期 snapshot 預估的同 target 月需求（給你看「上次怎麼算的 vs 這次」） |
S1 出貨 / S2 出貨 | 人工確認的出貨量。空白 input 的灰字是建議箱規數量，不代表已確認。 |
當前偏差 / ⚠ | 顯示已完成月份的成效追蹤訊號，幫你知道這個 SKU 近期是否常估錯。 |
6. Stockout 偵測與補正建議
三級警示燈
| 狀態 | 視覺 | 觸發條件 | 建議動作 |
|---|
| 正常 |
白底 |
無斷貨跡象 |
不必處理 |
| 疑似 stockout |
黃底 |
連續 N 天零銷量（門檻動態） |
檢查；通常需要 override |
| 確認 stockout |
紅底 |
FBA snapshot 顯示 fulfillable = 0 |
必須檢查並 override |
動態門檻（為什麼有的 SKU 連 2 天 0 就警告，有的要連 14 天？）
因為不同 SKU 的銷售節奏不同：
| SKU 類型（日均） | 連續 0 天門檻 | 邏輯 |
|---|
| 高 velocity（50/日） | 2 天 | 每天都該賣，連 2 天 0 就詭異 |
| 中 velocity（5/日） | 2 天 | 同上 |
| 低 velocity（1/日） | 7 天 | 本來就會有 0 銷量日，要連 7 天才異常 |
| 冷門品（0.3/日） | 14 天 | 每 3 天才賣一次是正常，14 天都沒賣才警告 |
建議補正值（adj 灰字）
當系統偵測到 stockout，會在 Sales/day 數字旁顯示灰色斜體建議值。例：
SKU
名稱
FBA
Shipping
Sales/day
assorted_bs_9p3t
嬰兒襪 黑白灰 3-5歲
1533
2161
42.04 35.04
解讀：「系統算出 42/日，但偵測到 stockout，建議補正成 35/日」。建議值用 A→B→C 三層 fallback 算出來：
建議值的三層演算法
| 路徑 | 什麼時候用 | 邏輯 |
|---|
A. parent_coef
（同類 SKU 補） |
同 parent 有「沒斷貨的兄弟 SKU」 |
用兄弟的銷量比例推算這個 SKU 在 stockout 期間應該賣多少 |
B. historical
（歷史外推） |
該 SKU 過去 12 月有「乾淨月」（沒 stockout） |
拿那個月的日均 × 季節係數調整到本月 |
C. yoy
（去年同月 + 成長率） |
有去年同月資料 + parent 線過去 24 個月歷史 |
去年同月日均 × 整條線 YoY 成長率 |
注意：建議值是
參考，不是命令。你看到後可以：
- 接受（點一下，填入即可）
- 改成你判斷的值（你比系統更懂背景）
- 忽略（如果你判斷該 SKU 真的就賣這麼少，例如停產中）
Override 後的視覺變化
一旦你改了 Sales/day，紅/黃底會消失，旁邊出現一個小 ⚠️ 提示「曾偵測到 stockout，已 override」。這代表「事情有處理過」，避免下次又被當成新警告。
7. Sales/day Hover 統計卡
滑鼠停在任何 Sales/day 欄位上 200 毫秒，會跳出一個白底浮窗：
assorted_bs_9p1t — Sales velocity
| 視窗 | 平均/日 | σ | vs 30D |
|---|
| 7D | 21.9 | 18.6 | -54.3% |
| 14D | 30.6 | 16.0 | -35.9% |
| 30D | 47.8 | 22.6 | baseline |
| 90D | 47.9 | 14.4 | +0.2% |
| 180D | 72.2 | 51.9 | +51.0% |
本月修改紀錄（2026-04）
尚無修改紀錄
欄位說明
- 視窗 (7D / 14D / 30D / 90D / 180D)
- 過去 N 天的平均日銷量。30D 是預估系統用的「baseline」。
- 平均 / 日
- 該視窗內的銷量總和 ÷ N。
- σ（標準差）
- 該 SKU 在那個時間窗內，每日銷量的波動程度。
- σ 大 → 銷量極不穩定（可能有促銷期、有斷貨期）
- σ 小 → 銷量穩定（每天都差不多）
- 粗略公式：68% 的日子會落在「平均 ± 1σ」之間
- vs 30D
- 該視窗的平均跟 30D 比的百分比差距。
- 7D「-54.3%」= 過去 7 天比 30 天平均少 54%（最近爆掉了，可能 stockout）
- 180D「+51.0%」= 過去 180 天比 30 天平均多 51%（前面有過旺季或促銷）
怎麼用這個卡片做判斷
例 1：7D 跟 30D 差很多 → 警示近期變化
「7D = 22、30D = 48」表示最近一週銷量腰斬。要查為什麼（stockout？競品？）。
例 2：180D 跟 30D 差很多 → 警示季節性
「180D = 72、30D = 48」表示前 180 天平均比近 30 天高 50%。可能上半年是旺季、最近進淡季。預估時要小心別用 30D 預估到旺季。
例 3：σ 比平均還大 → 該 SKU 太雜訊
σ = 51.9、平均 = 72.2 → 變異係數 72%。表示這 SKU 賣得「忽冷忽熱」（可能是促銷敏感品）。預估容易錯。
本月修改紀錄
下半部顯示當月（base_month）對這個 SKU Sales/day 的所有修改紀錄：
- 系統算出（raw value）
- 建議補正值（adj suggested）
- 你的每次編輯（時間戳 + 值 + 是否接受建議）
跨月不顯示 — 進入 5 月後，4 月的修改不會出現在這裡（避免雜訊）。但軌跡仍然存在 KV 後台，可用於成效分析。
8. 📝 SKU 筆記功能
每個 SKU 旁邊都有一個 📝 圖示。沒筆記時是灰色虛線、有筆記時實心 + 顯示數量。
SKU
名稱
FBA
Shipping
Sales/day
assorted_bs_9p0m 📝
嬰兒襪 黑白灰 0-6個月
132
24
0.30
assorted_bs_9p3t 📝3
嬰兒襪 黑白灰 3-5歲
1533
2161
42.04 35.04
怎麼用
- 點 SKU 旁邊的 📝 → 跳出筆記 modal
- 「+ 新增筆記」展開表單
- 內容：純文字（支援 Markdown 粗體斜體）+ 圖片（拖拉、Cmd+V 貼上、或點擊選檔）
- 儲存 → 列表更新（最新在上，每筆有時間戳）
- 點 🗑️ 刪除特定筆記
什麼時候該寫筆記？
好的筆記（事後幫得到自己）：
- 「4/15-4/20 競品出 -25% Lightning Deal，我們銷量掉 30%（附 BSR 截圖）」
- 「自己 5/3-5/5 跑 -20% coupon 衝排名，銷量爆 1.8 倍 → 6/1 預估時要砍回 baseline」
- 「5/15 listing 被 Amazon 暫時下架，下午 6 點恢復」
- 「下批貨延誤兩週，6/1 出貨改成 6/15」
原則：當下記，不要拖。系統不會自動幫你記住「為什麼 5 月銷量爆掉」，但你寫一句「自己降價衝排名」三秒就完成。下個月看到 📝 就會想起來。
限制
- 單筆筆記最大 1MB（含圖片，會自動壓縮到 1280px JPEG 80%）
- 單個 SKU 最多 50 筆
- 圖片是上傳後立即儲存到雲端 KV，不依賴本機
9. 名稱對應與箱規
現在名稱與箱規都已經從固定 JSON 升級成雲端 KV 設定。意思是：在網頁上改，其他人重新整理後也會看到同樣設定。
名稱欄與 FNSKU
- 在「庫存預估」表格直接點 名稱 欄即可修改品名。
- 名稱會寫入
name_mapping:us，不是只存在本機瀏覽器。
- SKU 欄旁可查看 / 複製 FNSKU；「出貨計畫」Excel 也會在 SKU 右邊新增 FNSKU 欄。
- 新品若還沒有名稱對應，會在頁面上方出現未辨識提醒。
箱規 Tab
| 功能 | 做法 |
|---|
| 修改既有箱規 | 直接點格子 inline edit，儲存後寫入 Cloudflare KV。 |
| 新增箱規 | 按「+ 新增一列」，填 Model、Units/box、重量、長寬高。 |
| 單位切換 | 畫面可在 lb·in / kg·cm 間切換；匯出與系統內部仍保留標準值。 |
| Import / Export | 可用 xlsx 匯入整批箱規，也可匯出給供應鏈確認。 |
新品流程：新增 SKU 時，通常要補三件事：名稱對應、箱規、以及 product line / parent grouping。只改名稱不一定夠，因為建倉與裝箱明細還要靠箱規 model 找到每箱數量與尺寸。
10. 出貨計畫、建倉、KPGS 手套統計
右上角兩個藍色按鈕：
| 按鈕 | 用途 | 誰用 |
|---|
| 出貨計畫（深藍） |
把目前表格匯出 Excel。第一張 sheet 是「出貨計畫」主表；第二張 sheet 是「KPGS手套統計」。 |
給供應鏈 / 內部追蹤 |
| 建倉（淺藍） |
匯出 Amazon FBA 出貨範本（Merchant SKU / Quantity / 箱規） |
直接上傳到 Seller Central 建立 Inbound Shipment |
Shipping Plan 欄位的判讀
| 顏色 | 數值 | 意思 | 動作 |
|---|
| 紅底 |
負值（例 -1682） |
下次出貨日的庫存不夠 buffer 期 |
必須出貨 |
| 白底 |
0 ~ +99 |
剛好夠 |
視情況 |
| 綠字 |
正值 (+100 以上) |
庫存充裕 |
可以不出 |
S1 / S2 出貨欄怎麼用
- 灰色 placeholder 是系統按箱規算出的建議值，方便你判斷一箱一箱怎麼湊。
- 真正人工確認後，請直接在 S1 / S2 input 裡輸入數量。Enter 儲存，Esc 取消。
- 「原本預估」欄只在有人工輸入時比較差異，避免灰字建議值造成誤判。
- 「出貨計畫」主表會把畫面上的數字匯出給供應鏈；KPGS 手套統計則只統計人工輸入的 S1 / S2 數量。
KPGS 手套統計
KPGS 是手套 + 護膝 + 護肘的組合。為了讓供應鏈知道要備多少手套，KPGS parent row 右側有一個 手套統計 入口。
規則：
- 只統計 KPGS parent 底下的 SKU。
- 粉色手套只認白名單花色：pink camo、pink snowflake、unicorn 相關 KPGS SKU。
- 剩下 KPGS SKU 全部算黑色手套。
- 尺寸由 SKU suffix 判斷：
_2_4、_4_8、_8_11。
- 只讀人工輸入的 S1 / S2 出貨量，不讀 placeholder，也不讀 backend default。
| 列 | 意思 |
|---|
| 粉色2-4手套 / 粉色4-8手套 / 粉色8-11手套 | 粉色花色 KPGS 對應年齡段的手套總數 |
| 黑色2-4手套 / 黑色4-8手套 / 黑色8-11手套 | 非粉色白名單 KPGS 對應年齡段的手套總數 |
| Total | 所有 KPGS 手套總數 |
明細表與 Excel 欄位會用實際日期當表頭，例如 2026/06/05 數量、2026/07/03 數量。
11. 成效追蹤 Tab
位於分頁第 2 位（庫存預估 / 成效追蹤 / 小時訂單 / 箱規 / 裝箱明細）。
頂部 Banner（每月 1-6 號自動出）
上月成效摘要
平均誤差、stockout、overstock 會在月初提醒你檢查。點「查看細節」可進入成效追蹤。
觸發條件（任一）：
- MAPE（平均誤差）> 15%
- 有任一 SKU 提早 stockout
- 有任一 SKU overstock
這個 banner 的目的不是責備，而是讓每月的預估結果能回饋到下一次決策。
子分頁 A：月度排名
- 最近月份的 MAPE 與整體表現。
- Top over-forecast SKU：預估太高、實際賣得少。
- Top under-forecast SKU：預估太低、實際賣得多，常見原因是 stockout 或近期爆量。
- 有筆記的 SKU 會顯示筆記入口，方便回看當時原因。
子分頁 B：Per-SKU 歷史
- 下拉選一個 SKU。
- 看該 SKU 過去每個月：預估 vs 實際 vs 變異率。
- 變異率負值 = 預估太高；正值 = 預估太低。
什麼時候會有資料？
變異追蹤需要「該月實際銷量」才能計算，所以必須等 target month 完整結束 + 24 小時 buffer。例：4/30 結束後，5/2 的 daily pipeline 才會把 4 月實際 vs 預估寫入資料庫與 JSON。
12. 小時訂單 Tab
小時訂單用來看每個 parent / SKU 的訂單節奏，適合回答「今天是不是突然變慢」、「某 SKU 是否只是一兩小時沒單，還是真的趨勢變了」。
- 資料來自 SP-API Orders / Orders Report，daily pipeline 會做 rolling fetch 與補資料。
- Parent → Child 展開，可看每小時折線圖。
- 遇到 Dashboard 顯示銷售暴跌時，可以回這裡看是全天低迷，還是某個時段資料尚未完整。
13. 裝箱明細 Tab
裝箱明細是給 shipment label 出來後使用的工具：把 Amazon box label PDF 丟進去，系統解析每箱的 shipment / box / SKU / qty，再套箱規與名稱對應，產出供應鏈可讀的 xlsx。
標準流程
- 到 Seller Central 下載 box label PDF。
- 打開「裝箱明細」分頁，拖拉或選取 PDF，可一次上傳多份。
- 確認解析到的箱數與 warning。若有箱規查不到，xlsx 對應欄位會留空。
- 按「裝箱明細」產出 xlsx。
- 如果需要重新排版 PDF，再用「重新排版 PDF」功能。
注意：裝箱明細不打 SP-API，它是純前端解析 PDF。若解析不到箱子，通常是 PDF 格式不是預期的 Amazon label 格式，或文字抽取順序不同。
14. 常見問題 FAQ
Q1: 我看到一堆紅底黃底，是不是系統壞了？
不是。高 velocity SKU 連續幾天沒賣就很值得警覺，所以系統會偏敏感。重點不是把所有警告清掉，而是先處理 Shipping Plan 紅底、FBA = 0、或 Dashboard 顯示暴跌的 SKU。
Q2: 系統建議的 adj 值跟我直覺差很多，誰對？
通常是你對。系統只看數字，不知道「上週你跟客戶談了大單」、「競品最近狂打廣告」。建議值是底線參考，但你的判斷 + 筆記裡的脈絡更重要。
Q3: 為什麼建議值有時比 raw 還低（往下修）？
當「同 parent 兄弟 SKU」也都低銷時（例：整條 BS 線當月都低迷），系統用兄弟的銷量推算這個 SKU 該有的水準，可能比 raw 還低。這代表 stockout 不是主因，整體市場才是。要查市場原因。
Q4: 我 override 後，下個月會自動帶過去嗎？
不會。Override 只影響當月（base_month）的下游計算。下個月會用新的 base_month 重新算 raw value。如果 5 月又遇到類似情況，需要再 override 一次（系統會幫你看到上次 override 紀錄當參考）。
Q5: 我寫的筆記其他人看得到嗎？
看得到。筆記存在雲端 KV，全部 Inventory Tool 使用者共享。就像 Notion 共享筆記。圖片也共享。
Q6: 「出貨計畫」和「建倉」差在哪？
出貨計畫 是內部 Excel（主表 + KPGS手套統計，給供應鏈看的全部資訊）；建倉 是 Amazon FBA 規定格式（SKU、數量、箱規），用來上傳到 Seller Central 建立 Inbound Shipment。
Q7: 表格資料是即時的嗎？
不是。資料由 daily pipeline 自動更新，首頁 Dashboard 會顯示各資料源的新鮮度；庫存預估左上角顯示最新更新日期。如果資料舊，先不要用它做重大出貨決策。
Q8: 為什麼「成效追蹤」分頁沒資料？
成效追蹤要等 target month 完整結束 + 24 小時 buffer。若剛跨月或 pipeline 還沒跑完，會先顯示尚無資料。先看首頁「變異追蹤」的新鮮度。
Q9: S1 / S2 欄位的灰字算不算已確認出貨？
不算。灰字只是系統按箱規給的建議值。你要真的採用時，必須手動輸入到格子裡；KPGS 手套統計也只會算手動輸入值。
Q10: KPGS 手套統計為什麼跟主表出貨量不一樣？
主表可能顯示建議值或手動值；手套統計只看人工確認的 S1 / S2 數量。這是刻意設計，避免供應鏈把尚未確認的 placeholder 當成真的手套需求。
Q11: 我改了箱規或名稱，別人會看到嗎？
會。名稱、箱規、出貨日期、筆記都存在 Cloudflare KV。其他人重新整理後會看到同一份設定。
15. 名詞對照
- SKU (Stock Keeping Unit)
- 商品識別碼。例：
assorted_bs_9p3t（嬰兒襪、混色、9 雙、3-5 歲）。
- Parent / 變體
- 同一個產品線的不同尺寸/顏色變體。例：BS（baby socks）有 22 個 SKU，黑白灰、藍、粉、不同年齡尺寸。同 parent 的 SKU 共享季節係數。
- FBA (Fulfillment by Amazon)
- Amazon 倉儲系統。SKU 必須先送進 FBA 倉庫才能賣。
- FNSKU
- Amazon FBA 倉內辨識碼。出貨計畫 Excel 會放在 SKU 右邊，方便供應鏈與 label / shipment 對帳。
- Sales/day（日均銷量）
- 該 SKU 在 base_month 的日均售出件數。預估系統的核心輸入。
- base_month / target_month
- base_month = 計算用的「上月」；target_month = 想預估的「未來月」。例：5/1 做決策時，base = 4 月，target = 5/6/7 月。
- S1 / S2
- 兩個出貨批次。S1 通常是下一個月出貨，S2 是下下個月出貨；日期欄會同步到雲端。
- Stockout（斷貨）
- FBA 庫存歸零、無法販售。會嚴重扭曲日均銷量計算。
- Overstock（積壓）
- 月底庫存夠賣 90 天以上 = overstock。資金壓在貨上、可能要付 long-term storage fee。
- Override（覆蓋值）
- 手動把系統算的數字改成自己判斷的值。所有 override 都進 audit log，永久保留。
- Placeholder（灰字建議值）
- S1 / S2 input 裡的灰字，代表系統依箱規算出的建議出貨量。灰字不是人工確認值。
- MAPE (Mean Absolute Percentage Error)
- 平均絕對百分比誤差。15% 表示平均每 SKU 的預估離實際差 15%。越低越準。
- Variance（變異率）
- (實際 − 預估) ÷ 預估。負值 = 預估高了、正值 = 預估低了。
- σ（Sigma / 標準差）
- 銷量波動程度。σ 大 = 忽冷忽熱、難預估；σ 小 = 穩定、好預估。
- YoY (Year-over-Year)
- 同期年增率。例：今年 4 月 vs 去年 4 月。系統用 trailing 12 month 平滑。
- TTM (Trailing Twelve Months)
- 過去 12 個月。用來算 YoY 成長率時兩邊各取 12 個月。
- Buffer
- +20D / +30D 等選項，多預留幾天的安全庫存。+20D 是預設，意思「下次出貨日當天的庫存還能多撐 20 天」。
- KPGS 手套統計
- KPGS 組合商品的手套需求統計，分粉色 / 黑色與 2-4、4-8、8-11 三個尺寸。只統計人工輸入的 S1 / S2 出貨量。
- KV (Cloudflare KV)
- 雲端 key-value 儲存。出貨日期、名稱對應、箱規、筆記與 override log 都透過 KV 在不同裝置間共享。
- 建倉
- 匯出 Amazon FBA 建立 inbound shipment 用的檔案。它比內部「出貨計畫」簡化，重點是 SKU、數量與箱規。
- SP-API (Selling Partner API)
- Amazon 提供的 API。系統每天從這拉訂單、庫存、價格。
Inventory Tool · 更新 2026-05-01 ·
sk-inventory.pages.dev ·
有問題找工程師