今天要來寫我實際做出的流程。

BTW，這個專案最後會變成一個網頁系統，把信用額度和逾期整合在一起，但那是後段的事。它的第一階段是一套每半個月自動產出逾期報表的程式，接下來要講的就是這一段。

這個專案最後變成十六個步驟，其中前面十三步全部都在處理資料，真正跟「審核」和「寄信」有關的只有最後幾步。

資料其實有四份，不是三份

我一開始以為要處理的是三份表，做下去才發現是四份。

第一份，ERP 匯出的逾期應收帳款明細表。 這是主表，但它沒有付款條件，也沒有追蹤進度。

第二份，客戶檢索表。 付款條件、負責的會計、聯絡資訊都在這裡。

第三份，BI 系統每月寄來的銷貨單。 這一份是 Email 附件，而且分成兩個分頁，因為結帳的區間跨月。

第四份，上個月的報表。

第四份是我一開始沒想到的。

催款這件事是連續的，這個月要知道上個月催到哪裡、客戶回了什麼、業務追到什麼程度，那些資訊保存在上一期的報表裡。

也就是說，這套系統自己的產出，會變成它下個月的輸入。

所以整個流程不只是一個「每個月從零跑一次」的工具，而是一條有記憶的線，如果中間有一次沒跑好，下一次就會接不上。

兩把鑰匙

四份資料要對在一起，靠的是兩個不同的欄位。

客戶代號，用來把主表和客戶檢索表對起來，補上付款條件那些欄位。

結帳單號，用來把主表和銷貨單對起來，補回原始的客戶代號和名稱。

為什麼要「補回」原始的客戶代號？因為同一個客戶，在會計和業務的視角裡，代號不一定長一樣。有些是總公司付款所以在會計的報表中會使用總公司的代號，但業務若要催款就需要看到原訂購店家的代號，如果只用一種代號去對，會計和業務彼此的溝通會有問題，所以我決定把這兩個部門看的不同的客代都顯示出來。

這一段我花了很多時間，而且它就是昨天說的那個「資料很複雜」的具體內容。技術上不難，難的是你要先知道這些欄位在現實裡代表什麼。

開發到第十天左右，我改了 mapping 的邏輯，改了兩件事。

第一，原始的客戶代號和名稱欄位不刪掉。

第二，如果對照不到，就保留原本的值，不要寫成空白。

當時我在 commit 上寫的理由是「避免 mapping 後原始資料被蓋掉」。

寫這篇的時候我才發現，這跟我在人資考核那邊做的決定是同一件事。那次是把新收到的職能另外開一個分頁，保留員工總表裡去年的那幾欄；這次是保留原始代號、對不到就 fallback 回原值。

兩次的理由一樣，就是不要用新的資料覆蓋舊的 ，因為我怕蓋掉之後找不回來原本的資料，要debug就會有點麻煩。

缺一就停

第零步不做事，只做一件事，檢查來源檔案在不在。

三份來源檔只要缺一份，整支程式就直接中止，不會往下跑。

這也是我第二次做同樣的選擇了，上一個專案我讓任何一個環節失敗就把整套系統停擺，這次是資料不齊就不開始。

理由是一樣的，帶著缺漏的資料往下跑，最後產出的是一份看起來正常、但其實是錯的報表。

為什麼有些檔案要用手放進資料夾

這個流程裡有一個很不優雅的地方。

銷貨單是系統自動從 Email 抓的，但逾期明細表和客戶檢索表，是會計每個月手動從 ERP 匯出，再放進雲端資料夾。

我當然問過能不能也自動化，答案是這兩份沒辦法從 BI 出，卡在權限。

所以這條線上有一個人工的起點，而且它一直讓我覺得很不順眼，因為對我來說，一條流程裡如果還留著判斷以外的人工環節，那它就還不算自動化。

判斷可以留給人，但「把一份檔案從一個地方匯出來、再放到另一個地方」不是判斷，那是勞力，是最應該自動化的部分，所以 這件事後來變成我想把整套東西改成網頁版的原因之一。 現在的版本已經直接接 API 拿資料，那個人工的起點就消失了。

不過那是後段的事，在我接下來要寫的這個階段，每個月還是得有人先把兩份檔案匯出來、放進資料夾，這條線才會開始跑。

例外不是例外，是業務知識

管線中段有幾條規則，我一開始以為是特例處理，後來發現不是。

呆帳要排除。 已經認列呆帳的單子不能再催，所以它們會被搬到報表最底部，用灰色分隔開，而且不列入催款信。

溢收不能當成欠款。 負數金額代表客戶多付了，這種不該催。但如果同一個客戶另外還有逾期超過三十天的單，那就要一起通知。

貨到付款要另外一頁。 這類帳務性質不同，判斷的方式也不同，所以會被分到第二個分頁去。

這三條，全部都是會計告訴我的，如果我自己來做，絕對不會知道這些背景知識

它還在長

有一件小事我覺得蠻有意思的。

這套流程一開始是十四步，後來變十五步，現在是十六步。

多出來的那一步是「依收款業務員排序」，上線兩個多月之後才加的，因為會計實際用了才發現，報表如果照業務員排在一起，他們對照起來快很多。

這種事情要等到有人真的每個月用它，才會冒出來，同時我也很感謝他們願意給我回饋！

這兩步，才是我最想講的

前面十三步都在處理資料，真正決定這套系統長什麼樣子的，是這兩步。

建立審核頁、寄出審核通知

報表產出來之後，系統會另外開一個審核頁面，上面列著五位會計各自負責的範圍，每個人有一個勾選框，然後寄一封通知信給他們。

接下來系統就停在那裡，什麼都不做。

為什麼是五個人，而不是一個

我問過能不能簡化。

答案是不行，因為那五位會計各自負責不同的客戶，不是五個人一起看同一份，是每個人只看得懂、也只該看自己那一塊，而且五人看的時間可能會不一樣。

沒有任何一個人有辦法替另外四個人確認。

這跟人資考核那邊的情況不太一樣，考核的接力是有順序的，前一棒沒做完，後一棒就拿不到東西，這裡的五個人是並排的，理論上可以同時進行，但整批還是要等最慢的那一個。

我當時有想過要不要分批放行，誰審完就先寄誰負責的那部分。最後沒有這樣做，因為催款信是寄給業務的，而一個業務手上可能有好幾個不同會計負責的客戶，分批寄的結果，是業務會在一週之內收到三封零零散散的催款信，然後不知道到底哪一封才是完整的。

放行的單位要跟收件人對齊，不是跟審核人對齊。

這件事跟我在考核那邊學到的是同一件事，那次我的結論是「放行的單位不該是某個人填完了，而是這位主管手上的資料齊了」，這次是「不該是某位會計審完了，而是這位業務該收到的東西齊了」。

還有第二關

五個人全部勾完，系統也不會直接寄信。

會先轉給一位最終審核人，等他核可，催款信和總表才會真的發出去。

為什麼多這一關？因為前面五個人各自只看自己那一塊，沒有人看過完整的那一份，而這份東西一旦寄出去，就是業務打給客戶要錢。

所以設計上是這樣，五個人負責「我這部分對不對」，最後一個人負責「這整份可不可以出去」。

這是這個專案裡我刻意留給人的環節，而且是整套流程中唯一沒有任何自動判斷的一步。