政府補助公示上傳：從人工轉檔到 API 排程的五個檢查點

這篇文章適合誰

• 行銷／業務：需要向決策者說明「為何截止日前仍漏上傳」、評估導入 API 的時程與風險。
• 技術：負責補助資料匯出、格式轉換與對外介接的開發或維運人員。

問題背景

我們在補助管理與公示相關專案中，最常聽到的痛點不是「系統不夠新」，而是每到截止日就人工轉檔、仍漏上傳。承辦人從內部系統匯出、再依主管機關範本調整欄位；任何一步靠記憶或複製貼上，都可能造成漏筆、日期格式不符，或上傳窗口已關才發現錯誤。申報高峰期尤其明顯——同一批資料被多人交叉修改，卻沒有單一來源的「最終版」。若無法指出最終版由誰核可，再大的系統預算也難換來準時上傳。

決策者摘要：問題多半不在「要不要買新系統」，而在人工交接點沒有責任歸屬與驗收標準；先盤點流程，再談介接，投資效益較可預期。

檢查點一：釐清人工轉檔的斷點

決策者關注： 哪個環節最依賴「某人記得怎麼轉」？那就是優先自動化、也最值得向管理層說明的投資項目。

技術重點：

• 畫出資料來源、格式調整、上傳責任的流程圖，標出每個 handoff 的負責人與驗收標準
• 從內部案件系統追到公示檔，確認問題是否在匯出後的二次整理
• 將「無單一責任人」的節點列為第一批自動化候選

檢查點二：資料擷取與格式標準化

決策者關注： 截止前才手動對照規格修欄位，人力成本與錯誤率都無法預測；標準化後可量化「一筆成功上傳」的工時。

技術重點：

• 在 .NET 後端建立單一轉換層：必填欄位、編碼、日期與金額格式，寫入前驗證
• 對外公示 schema 固定，內部欄位名稱可不同；每次轉換保留版本號
• 保留轉換前快照，便於比對被拒絕檔案對應哪一版規則

檢查點三：API 上傳與排程

決策者關注： 例行上傳不應佔用承辦人登入中央公示平台的時間；人只處理例外，可釋放高峰期的作業產能。

技術重點：

• 背景服務在可上傳時段自動送出，與「已核定、待公示」狀態連動
• 僅通過驗證的批次進入佇列；排程可暫停，不影響已驗證的待送資料
• 避開尖峰維護時段，介接規格更新時可凍結新批次、續送舊佇列

檢查點四：失敗重試與通知

決策者關注： 失敗若只留在承辦人截圖或便條，無法向稽核或長官說明「為何當天沒上傳」。

技術重點：

• 指數退避重試、失敗次數上限
• Slack、Email 或工單通知，附錯誤摘要與可下載的原始 payload
• 「格式正確但暫停受理」時，明確暫存與隔日重送策略

檢查點五：稽核紀錄與權限

決策者關注： 查帳時需要「誰、何時、送了哪一版」的證據，而非事後補截圖。

技術重點：

• 不可竄改的稽核 log：觸發者、送出版本、回應碼
• 區分可預覽、可送出、可重送角色；以角色而非個人帳號綁定
• 人員輪調時不必重設整套流程

上線後維運

法規與欄位定義會變。將公示 schema 與轉換規則參數化；新欄位先走 staging 再上正式排程。建立與主管機關公告的對照清單，避免規格已改、排程仍送舊版。人工轉檔在高頻、有截止壓力的場景難以維持；API 排程加上前五點，能把漏上傳從人為疏失降為可追蹤的例外。

下一步

若單位仍在 Excel 與網頁上傳之間來回，建議先從流程盤點與格式標準化著手，再評估介接時程。我們在補助公示整合與企業後台系統實績中，常以類似檢查點協助客戶分階段導入——歡迎透過網站聯絡我們討論現況盤點。