GamePP Platform V2

目錄

色彩對應（全文通用）

線條含義

全景總覽 · 一張圖看懂所有流程

下圖把 V2 架構中所有生產線流程串成一張：從幣商客戶接入、撮合決策、進貨池、金流對帳、內帳記錄，一路到對外輸出。六個子區分別對應後面的逐區說明。

V2 全景流程：入口 → 撮合 → 經營 → 金流 → 內帳 → 對外

三條主幹脈絡

六個功能區域

①入口層 · 客戶接入 4 模式

V2 上線後，一個幣商客戶要怎麼把訂單送進來？依客戶「有沒有自己的系統、有沒有日報表習慣」分成四種路徑。四條路最終都會匯流到「標準化事件」，再分送去 ATMatch 撮合或 gamepp 進貨池。

4 模式客戶接入流程——最終都標準化後進撮合 / 進貨池

4 模式對照

共同匯流點

四條路最後都會變成標準化事件——不管是手開的單、上傳的表、API 推進來的，系統只認標準格式。這個匯流點之後就進入 ATMatch 撮合或 gamepp 進貨池。

②撮合引擎 · ATMatch 決策樹

ATMatch 是 V2 的心臟——負責判斷「這筆買單要不要撮、和誰撮、撮不撮得上」。進來的三種來源：買單、玩家賣單、🆕 進貨池。出來兩種結果：撮合事件（成功）或撮不完（失敗）。

撮合引擎決策流——4 條件檢查 + 雙路徑分流 + 對帳／水位回饋

撮合 4 條件

1. 公司一致——同一家統編才能撮（否則跨公司金流）
2. 遊戲一致——同款遊戲幣
3. 幣種一致——幣種編號要合
4. 數量配對——買賣方需求數量對得起來

撮合成功 → 事件分發

只要 4 條件都過，就產出一筆「撮合事件」，自帶三個數字：

• A · 銷貨——買家付的金額
• B · 進貨——給賣方（或進貨池）的成本
• C · 毛利——A 減 B

這筆事件會同時往 5 個方向廣播：發票開立（gamepp，以撮合公司別）、進銷存、毛利報表、稅務（含發票號碼）、內帳分錄。

撮不完 → 待結算支線

任何一個條件過不了就進「待結算池」，四個處理路徑：

• 持倉天數追蹤——掛越久風險越高
• 風險敞口（對內 know-how）——預收或預付的資金風險
• 待撮合單列表（對外表象）——客戶看到「等撮合」
• 結算水位——累積的代出款餘額

金流回饋迴路

ATMatch 不只看單，也看錢：EGoPay／網銀進帳明細進來後，會和撮合前的條件重新確認；對不上就開作業層異常單。

③經營核心 · gamepp 進貨與庫存

gamepp 是 V2 新建的部分——負責「幣商的日常經營」：怎麼進貨、庫存怎麼算、撮不完的單怎麼追、報表和稅務怎麼出。

gamepp 內部流程——進貨 / 庫存 / 撮不完 / 報表 / 稅務

5 種進貨管道

庫存快照的四層結構

庫存不是一個大數字——而是 公司 × 遊戲 × 遊戲角色 × (幣種 × 管道) 的交叉格子。為什麼要拆這麼細？

• 遊戲幣是放在具體角色帳號裡，不是放在公司裡
• 角色被封鎖 → 那個格子的庫存整批死掉
• 角色有遊戲規則的存量上限
• 撮合時要確保買家收貨角色 ↔ 賣家出貨角色是同款遊戲

撮不完單管理（know-how 實作點）

收到 ATMatch 送來的「撮不完」訊息後，gamepp 會同時產出兩套視角：

電子發票（以撮合公司別開立）

發票不在金流層——而是在 gamepp 這端開立。因為一張發票的開立公司，取決於撮合事件當下落在哪家公司（多公司架構下，一筆撮合可能走 A 公司或 B 公司），這個決策屬於經營面，不屬於金流。

報表與稅務的兩個出口

• 毛利報表——按進貨管道拆，看哪條管道最賺
• 稅務明細 113 函令——自動產出申報表格式，欄位含發票號碼（和 gamepp 發票系統勾稽）

113 函令明細表主要欄位

④金流 · 收款 · 對帳 · 發票

錢怎麼進來、怎麼出去、怎麼確認對得上——這一段都是金流層。關鍵是「對帳中樞」，由 ATMatch 的對帳引擎負責：把收款明細、撥款明細、撮合事件三邊對起來。
⚠️ 電子發票不在這層——發票以「撮合公司別」開立，屬於經營面決策，放在 gamepp。

金流層——收款 / 撥款 / 對帳；發票另在 gamepp 開立

收款路徑

1. 買單成立 → 發動 EGoPay 收款
2. 買家付錢 → 網銀進帳明細入系統
3. 對帳引擎比對：這筆進帳對應哪一張買單？
4. 對得上 → 放行撮合；對不上 → 作業層異常單

撥款路徑

1. 撮合完成／賣單確認 → 觸發網銀 API 代出款
2. 扣除手續費、匯損
3. 匯款明細回流對帳引擎
4. 對得上 → 賣單結清；對不上 → 作業層異常單

發票決策（放在 gamepp，見 §3）

撮合成功後，ATMatch 觸發「開發票」的事件，但實際開立、以哪家公司名義開、號碼流水——全在 gamepp。

⑤內帳 · gamepp_accounting

所有系統事件最後都會寫入內帳——分錄、成本、毛利、月結。這一層純內部使用，對客戶、國稅局、股東都不開放，反映的是「買賣業真相」。

三路事件來源 → 分錄 → 衍生報表

三路事件來源

• ATMatch 撮合事件——銷貨 A、進貨 B、應收、應付、庫存減少
• 金流事件——EGoPay／網銀收付款 → 銀行存款、應收、應付
• gamepp 進貨事件——庫存增加、供應商應付

核心分錄項目

衍生報表

• 毛利分析——按進貨管道拆
• 資產負債表——公司財務體質
• 損益表——當期賺賠
• 月結——月底統整

⑥異常處理 · 作業層 vs 經營層

異常單在 V2 變成兩套系統——因為「撮合對不上」和「KYC 過期」是完全不同層級的問題，給不同角色處理。

異常單兩意義——作業層 (ATMatch) vs 經營層 (gamepp)

作業層異常（ATMatch 負責）

沿用現有 anomaly_reports 資料表——已經針對 egopay 和 ticket 兩個來源實作。

經營層異常（gamepp 新建）

跨層警示

兩層異常會互相牽連——例如同一個玩家短期內重複觸發「對帳對不上」，會從作業面警示升級為「這玩家要風控介入」的經營面異常。反之，風控決定停用某個玩家 → 觸發作業面回沖單據。

⑦事件生命週期 · 一筆單走完整個系統

最後一張：跟著一筆買單，從客戶下單到對外輸出，看它在哪些系統間跳來跳去、觸發了哪些副作用。

單筆買單的 end-to-end 時序——涵蓋主幹、撮不完支線、異常三種情境

主幹時序（撮得到的情況）

1. 買家下單
2. ATMatch 發動 EGoPay 收款
3. 網銀進帳 → 對帳放行
4. ATMatch 跑 4 條件檢查 → 產撮合事件
5. 事件廣播：減庫存 + 寫分錄 + 開發票 + 發動撥款
6. gamepp 產稅務明細、毛利報表
7. 對外交付發票

撮不完支線

1. 4 條件沒過 → 送 gamepp 撮不完單管理
2. gamepp 追蹤持倉天數
3. 對外呈現「待撮合單」（服務業表象）
4. 對內記「風險敞口」（買賣業內涵）
5. 寫分錄：客戶預付款 / 庫存敞口

異常情境

• 對帳失敗 → ATMatch 作業異常單
• KYC 過期、4 萬門檻 → gamepp 經營異常單