前面幾天分別寫了會計端的逾期報表，和業務端的信用儀表板。

今天寫我為什麼把它們做成同一個東西。

它們本來是兩個需求

我在 Day 10 提過，這兩件事是分開來找我的，不同的時間、不同的人、聽起來完全無關的兩句話。

會計要的是「幫我把報表做出來，把審核跑完」。

業務要的是「我想自己查得到客戶的額度狀況」。

如果照著需求單做，這會是兩個系統。

但它們共用的東西太多了

我把兩邊攤開看的時候，發現重疊的部分比不重疊的多。

同一批客戶。 逾期看的是這些人，額度看的也是這些人。

同一批資料。 應收帳款既是逾期的來源，也是已用額度的組成之一。我在兩邊都要算它，而且必須算出一樣的答案。

連在一起的流程。 逾期報表跑完之後的下一步，本來就是通知業務去催款。會計的終點就是業務的起點。

而且兩邊都想要一個網頁。 逾期那邊是為了擺脫每個月人工匯出檔案，業務這邊是為了一次看到全部客戶。

所以問題就變成，我到底要做兩個各自去算、各自維護、而且有可能算出不同數字的系統，還是做一個就好。

合併不是把兩個功能放在一起就好

不過我做下去才發現，合併最難的不是介面。

是要選一個共同的口徑。

原本那兩套東西各有各的算法，逾期報表是我自己從明細表算出來的，而儀表板這邊 ERP 已經算好了一份。這兩份如果對不起來，合併之後就會變成同一個畫面上有兩種真相。

所以合併的過程，有一大半時間其實是在做同一件事，把舊的規則，一條一條在新的系統裡重現，然後驗證它們算出來的東西一樣。

這裡我做了幾個選擇。

宅配的判定邏輯，我維持原本比較囉嗦的版本，沒有改用簡化的寫法。因為簡化之後會多分流一些單子過去，跟會計現在習慣看到的量不一樣。在合併這種時候，「更合理」不一定比「跟現在一致」重要 ，因為我要的是讓人相信這兩份是同一件事。

逾期天數和信用額度我全部沿用 ERP 的，一個都不自己算，理由前一篇寫過。

還有一個理由，是我一直想解決的

舊的那套逾期報表，整套跑在某一個人的帳號底下。

不是共用帳號，是一個真人的帳號，他離職、調職，或是帳號被停用，這條線就斷了。而那條線每個月要產出全公司的逾期報表、跑完兩階段簽核、然後寄催款信給業務。

這件事我一直想解決，因為我不希望資料和權限分散在很多個人手上。

但這種風險如果單獨拿出來談，是很難排進順序的。 它不影響任何人當下的工作，系統跑得好好的，沒有人會因為它綁在一個人身上，而在這個月少收到一份報表。

它是一個只有在出事那天才會變成問題的問題。

而業務那邊要的儀表板不一樣，那是現在就有人要、現在就看得到價值的東西。

所以我提的方案是把它們合在一起做。業務拿到他要的那一頁，會計拿到不用再人工匯檔案的流程，而整套東西執行的位置，順便搬離了個人帳號。

一個方案，同時解決三件事。

這可能是我在這個專案裡做得最好的一個判斷。 它跟技術無關，做的事情就是把一個不容易被單獨排進優先順序的風險處理，接到一個有人要的功能上。

新的做好了，舊的還不能關

這一段我覺得很重要。最近我越來越覺得，驗證是一個專案裡最容易被跳過、但最不該跳過的步驟。

新系統做出來之後，我沒有把舊的那套關掉，到現在還沒有。

原因不是捨不得，也不是怕出事而留著備援。

是因為舊的那套，是我能拿來證明新的那套算對了的東西。

新系統的數字是從 API 直接拉的，舊系統的數字是從明細表自己算的。兩邊走完全不同的路，如果最後對得起來，那就代表兩邊都沒錯。

但如果我先把舊的刪掉，就再也沒有第二個來源可以比對了。到時候新系統算出一個數字，我只能說「應該是對的」。

所以退場的順序是有規定的，得先讓新系統建立起它自己的驗收基準，才能關掉舊的。 這件事不能反過來，也不能因為新的看起來已經能跑了就先關。

現在走到哪裡

資料的部分已經對完了。

接下來是真的上線，讓會計實際用個幾次。

老實說我本來以為對帳做完就差不多了，數字都能拆解到剛好對上，還有什麼好擔心的。

但前面兩個專案給我的教訓剛好就是這個。

考核那次，我以為寫了警語就處理好了，結果還是有人回頭改。逾期報表那次，規則跑了四個多月才發現有更好的做法，而「依業務員排序」這種需求，是會計實際用了兩個月才提出來的。

這些都不是對帳對得出來的。

對帳能證明的只有一件事，就是這個系統算的跟 ERP 一樣。但它不會告訴我會計實際打開這一頁的時候，第一眼想找的是什麼；也不會告訴我這一頁有沒有哪個地方，會讓他忍不住又想用手去改。

所以還要實際跑幾次看看，才能確定是不是真的可以結案了。