為甚麼 Zapier 做不到發票對數
Zapier 的設計是一次回應一件事件,而對數要比較兩個完整集合,並記住哪些仍未配對。這篇用 Zapier 自己文件裡寫明的限制,指出這個模型具體在哪裡斷開,以及它在對數流程中真正適合的位置。
- Zapier 一次回應一件事件;對數要比較兩個完整集合,並記住哪些項目仍未配對,這是另一種形狀的問題。
- 限制是白紙黑字,不是推測:循環步驟上限 500 次、每個 Zap 只准一個循環步驟、每個 Zap 上限 100 個步驟。
- 循環之後的每一個動作,每跑一次就消耗一個 task,於是收費模式正好與對數所需的多對多比較背道而馳。
- Zapier 在對數外圍的通知與交接層真正好用。把它放在那裡,把配對放回它應該在的地方。
Zapier 做不到發票對數,因為它的設計是一次回應一件事件,而對數是兩個完整集合之間的比較,並且要記住哪些項目仍未配對。這不是 Zapier 功能表上的一個缺口,而是問題形狀上的差異,再加多少個步驟都補不回來。
這件事值得說清楚,因為 Zapier 通常是一間成長中的公司第一件拿起的工具,而它確實是一件好工具。失敗不在於選錯,而在於對數看起來很像自動化,直到你真的動手做。
對數究竟是甚麼形狀的問題?
對數在問:手上有 400 張發票與 380 筆銀行交易,哪些是一對、哪些是部分配對、兩邊各自剩下甚麼?
有三個性質令這件事對事件驅動的工具特別困難。
它是多對多的。 一張發票可以由兩筆付款結清;一筆付款可以涵蓋五張發票。配對無法逐筆決定,因為第 7 張發票是否對得上第 3 筆付款,取決於第 3 筆付款是否已經被第 2 張發票用掉。
它的狀態要跨次保留。 三月未配對的發票,四月仍然未結。系統必須把它帶下去,總要有一樣東西是「仍然未清」的持久紀錄。
它帶有信心維度。 真實的配對很少完全相等。金額相差一筆手續費、參考編號打錯一個字、日期相隔數日。配對的意思是為候選項評分再作選擇,而不是測試是否相等。
Zapier 的模型是一個觸發器加若干動作,每件事件跑一次。這很適合「當一張發票到達,把它歸檔並通知某人」,卻不適合上面三個性質。
白紙黑字的限制,以及它們為何正好卡住這件事
這不是理論上的異議。Zapier 有公開這些限制,而它們落在對數最需要空間的位置。
循環上限 500 次。 Zapier 關於 Looping by Zapier 的文件寫明,一個循環步驟最多跑 500 次。一個月 400 張發票對 380 筆交易,若直接硬做就是 152,000 次候選比較,即使用有索引的做法,一旦涉及部分配對,需要的次數也遠超 500。
每個 Zap 只准一個循環。 同一份文件指出,載有多過一個 Looping by Zapier 步驟的 Zap 無法啟用。而巢狀比較,也就是集合對集合配對的本質,需要循環之內再有循環。這是現成最直接的一句「形狀不吻合」的說明。
每個 Zap 上限 100 個步驟,每個動作上限 1,000 個欄位。 Zapier 的限制文件兩者都有訂明。繞過循環限制的做法通常是串連多個 Zap 與路徑,而那正是步驟上限所約束的。
循環之後的每個動作,按次消耗 task。 Zapier 文件說明,循環步驟之後的動作步驟,每跑一次循環就消耗一個 task,所以跑 500 次就是 500 個 task。換言之,收費隨比較次數上升,而比較正是對數做得最多的事。
合起來看:這個工具為對數最需要的操作設了上限、禁止把它巢狀化、限制了繞道的做法,還按比較次數為餘下的部分收費。
大家實際會搭出甚麼,以及它為甚麼會腐化
常見的繞道是一條鏈:一個 Zap 把到達的發票寫進 Google Sheet 或 Zapier Table,另一個 Zap 寫入交易,第三個 Zap 用一個查找步驟加幾條公式嘗試配對。
它會運作一段時間。然後失敗模式就會出現,而且永遠是同一個。部分配對沒有地方安放,於是被丟掉或重複。沒有人能在不打開試算表逐行讀的情況下,說出還有甚麼未結。一次重試把同一行再處理一次,造出第二個配對。當初搭的人離職,而邏輯散落在三個 Zap、七個位置與一條沒有人想碰的試算表公式裡。
更深層的問題是,那份試算表已經悄悄變成一個資料庫,卻不具備資料庫的條件:沒有約束、沒有交易、沒有「甚麼時候配對了甚麼」的稽核紀錄。在財務上這不是技術上的講究,而是「一份可以拿給核數師看的對數」與「一份不可以」之間的分別。
成本也來得很遲。這類鏈起步便宜、要信任卻很貴,所以通常在年結時才被發現,那時要有人解釋一個由三月起一直靜靜累積的差額。
Zapier 在這裡真正好用的地方
如果只列出 Zapier 做不到的事,對它並不公平,因為對數外圍那一層正正是它的強項。
把新發票送進正確的資料夾或信箱。有例外時通知審批人。配對失敗時開一張待辦。每日把摘要推到群組頻道。銀行檔案到達時啟動對數工作。這些全部是事件形狀、全部一次一件,而且在 Zapier 上又快又便宜。
行得通的架構其實很平實:讓 Zapier 處理邊緣的事件,把配對放在一個能保存狀態、能比較集合的地方,無論那是會計系統的一項功能、一個有資料庫支撐的批次工作,還是一條為此而建的管線。
一條問題就分得出你在哪一邊
對任何在考慮的工具問一句:它能不能在你不用人手重做一次的前提下,告訴你上個月還有甚麼未配對?
可以的話,它是對數工具。不可以的話,它是一件可以在對數周邊幫忙的自動化工具。兩者都有用,而且不能互相取代。
如果你的配對需要評分與例外分流,而不只是精確查找,對數自動化要做到 97% 準確率,關鍵在哪說明了做實事的那一層驗證,而發票自動對數:兩方與三方比對則涵蓋兩方與三方對數的機制。在動手建任何東西之前先量度規模,我們的對數 ROI 計算機會把單量與處理時間換算成回本數字,而我們的免費 30 分鐘 ROI 診斷則會就你的對數實際斷在哪裡,一起走一次。
常見問題
- Zapier 可以做發票對數嗎?
- 簡單的一對一查找可以,例如收到一張發票、檢查是否存在對應的採購訂單。但集合對集合的對數就不切實際,也就是一批發票對一批交易、要追蹤部分配對、而未配對項目要跨次執行保留下來。Zapier 自己文件中關於循環與步驟的限制,令這種形狀的工作由「麻煩」變成「不可行」。
- Zapier 的循環有甚麼限制?
- Zapier 文件寫明,一個循環步驟最多可以跑 500 次,一個 Zap 不能在載有多過一個 Looping by Zapier 步驟的情況下啟用,而循環之後的每一個動作步驟,每跑一次循環就消耗一個 task。此外,每個 Zap 連同所有路徑上限為 100 個步驟,每個動作步驟上限 1,000 個欄位。
- 那應該用甚麼來對數?
- 用一些能保存狀態、又能比較集合的東西:一個有資料庫支撐的批次工作、會計或 ERP 系統內建的對數功能,或者一條為此而建的管線。判斷方法是問:這個工具能不能在你不重新做一次的前提下,回答「上個月還有甚麼未配對」。
- 那 Zapier 在財務流程上還有用嗎?
- 有,而且在對數外圍那一層往往正是最合適的工具。把新發票送進正確的資料夾、在有例外時通知審批人、配對失敗時開一張待辦、把每日摘要推到群組頻道,這些 Zapier 都做得又快又便宜。錯的是要求它當底層的配對引擎。