前面三天寫的都是會計端的逾期報表。今天跳到另一條線，業務端的信用儀表板。
先講痛點。
業務想知道某個客戶現在的狀況，得自己到 ERP 裡面查。可以查得到，但那是單筆查詢，一次一家。
所以會變成這樣，他知道某一家客戶的額度剩多少，但他不知道自己手上二十幾家客戶裡面，哪幾家已經超額了、哪幾家逾期最久、風險集中在哪裡。
要知道這些，他得一家一家查完，然後自己在腦袋裡排序。
沒有人會這樣做。所以實際上就是，除非會計寄催款信過來，不然業務不太會主動發現問題。
儀表板要解決的就是這件事，把全部客戶攤在同一頁上，一眼看出誰有狀況。
要做出這一頁，我得先回答一個看起來很簡單的問題。
一個客戶的額度，到底被用掉多少？
我原本以為就是「他欠我們多少錢」。做下去才發現不是。
信用額度佔用的不只是已經欠的錢，而是從下單到收款之間，每一個還沒完成的階段。
這四種狀態的錢，全部都算佔用。
因為對公司來說，這四種都是「已經把東西給出去了，或者已經承諾要給出去了，但還沒變成現金」。風險是一樣的，只是階段不同。
所以已用額度是這四項加起來，額度餘額就是上限減掉它。減完是負的，就是超額。
這件事我覺得蠻有意思的。在我做這個之前，我對「信用額度」的理解是錯的 ，我以為它是在管欠款，其實它管的是整條還沒收回來的鏈。
會計最初告訴我的版本是五項，還多一個「暫出」。
我照做了，但對帳的時候發現對不起來。
追下去才知道，ERP 算信用餘額的公式裡本來就不含那一項，而那一項全公司只有兩三家客戶有值。
如果我照五項去算，那兩三家的額度餘額和超額判斷就會跟 ERP 不一樣。
所以我把它改成四項，那一項獨立顯示成一格，點進去一樣看得到明細，但不加進已用額度。
這跟我前面寫過的「例外不是例外，是業務知識」剛好反過來。那次是需求方知道我不知道的事；這次是需求方說的，跟系統實際的算法不一樣 ，而我得選一邊。
我選了對齊系統，然後回頭跟會計解釋為什麼。
逾期金額不能另外再加一次。
因為應收帳款裡面本來就包含了逾期的部分，逾期只是「這筆應收帳款已經過期了」的狀態，不是另一筆錢。
這種重複計算的錯誤如果犯了，數字會變得很難看，而且很難被發現，因為它不會報錯，只會讓每個超額的客戶都超得更誇張一點。
再來是風險怎麼標示。
一個客戶可能同時超額、同時逾期超過九十天、同時有一堆三十天以上的單。那他在畫面上應該顯示成哪一種？
最後的做法是給它一個順序，依序判定，命中了就停。
超額 → 嚴重逾期 → 需要追蹤 → 正常。
超額排第一，因為那代表這個客戶已經不該再出貨了，比「他有一筆錢晚了很久」更急。
這個順序是會計定的，而我覺得這是整個儀表板裡最重要的一個設定。因為一個什麼都標出來的畫面，跟什麼都沒標是一樣的。 業務打開來如果看到滿江紅，他還是不知道今天該先打給誰。
還有一個決定是，ERP 已經算好的東西，我一個都不自己重算。
信用額度的上限是 ERP 用它自己的加權邏輯算出來的最終值，逾期天數也是系統直接給的欄位。我當時有想過要不要自己再算一遍，最後決定全部沿用。
理由是如果我自己算，就會出現兩個版本的數字。而只要它們有一點不一樣，所有人都會開始問「到底哪一個才對」。那個問題一旦出現，這個儀表板就沒有人敢用了。
所以這一版我的工作不是算出答案，是證明我顯示的東西跟 ERP 對得起來。
驗收的時候我把畫面上的逾期總額整個拆開，扣掉被移除的呆帳客戶、扣掉被分流走的宅配單，回推到 API 給我的原始數字，看能不能剛好對上。
最後是可以的，差額是零。那一刻我才敢說這個畫面能看。
還有一件事我做完才發現它的價值。
我在 Day 11 寫過，逾期報表的第四份資料來源是「上個月的自己」，因為追蹤進度得從上一期的報表撈回來。
那個做法有一個很糟的地方，只要中間有一次沒跑好，前期的紀錄就會斷掉。
在儀表板裡，追蹤進度變成系統自己保存的東西，而且業務和會計都可以編輯。
它不再是每個月被重新產生一次的欄位，而是一筆會一直累積下去的紀錄。
接下來講這一版踩的坑，三個，而且形狀都一樣。
宅配那一段要判斷物流商是誰。我在客戶資料裡找到一個名字看起來就是物流相關的欄位，於是就用了。
後來發現那個欄位在 ERP 裡的原意是「承辦人」，不是物流商。名字長得像，意思完全不同。
欄位的名字不等於欄位的意思。 這句話我以前也知道，但知道跟真的被咬到是兩回事。
這個最嚴重，而且它正好是信用額度這條線上的問題。
系統把應收帳款和信用額度都掛在「付款總店」身上。有些客戶是連鎖的，總店幫底下的分店付款，所以分店自己查是零，金額全部堆在總店那裡。
但業務負責的是分店，不是那個集團。
所以我得把「這張單到底屬於哪一家分店」還原出來，而資料裡沒有這個欄位。
我一開始用群組去推。同一個群組裡的，應該就是同一家的分店吧。
這裡有兩個洞，我兩個都踩了。
第一，代付關係會跨群組。 A 幫 B 付款，但兩家根本不在同一個群組裡。
第二個更致命。 我的條件裡有一句「群組代號不等於自己的客戶代號」，想用它排除掉總店。但群組代表自己的群組代號，就等於它自己的客戶代號。
所以這個條件把所有的群組代表整批排除了，其中有一家底下掛著八十幾家分店。
實際去驗的時候，正確的母體有八百多家，我那個條件只抓到四百多家。
漏掉的將近一半。而畫面看起來完全正常。
沒有報錯、沒有空白、沒有任何一個地方會提醒我少了三百多家。如果不是後來去做全量比對，這件事可能到現在都還沒有人發現。
後來九月的時候，API 開始回傳一個新欄位，每一張銷貨單可以直接查到它屬於哪個客戶。我就把做法整個換掉，不再用推的，一張一張去問。兩千多張跑完，只要那張單有銷貨單號，還原率是百分之百。
能查就不要猜。 但這裡有一個很現實的部分，我不是一開始就能這樣做，那個欄位當時根本還沒有，猜在當下是唯一的選項。
所以我後來會多做一件事，把那些「目前只能用推的」地方標記起來 ，因為條件會變，而我不想等到下一次全量比對才發現它早就可以不用猜了。
最後一個坑是我自己造成的。
有一段資料我需要全表掃描。我的筆記上寫著「這個方法要跑五十五分鐘，已棄用」，所以我一直用另一種比較省的抓法。
九月重整的時候我決定實際再測一次。
四個併發跑下去，七分鐘。而且更完整，原本那個省事的抓法，物流資料的覆蓋率只有一半左右，換回全表掃描之後幾乎翻倍。
我看著那句「已棄用」看了很久。那句話是我自己寫的，而且寫下來之後，我就再也沒有懷疑過它。
前一篇我才寫完文件的重要性，這一篇就被自己的文件坑了。
所以我現在會多寫一件事，不只寫結論，也寫下這個結論是什麼時候、在什麼條件下測出來的。因為條件會變，而結論不會自己更新。
明天寫這兩條線是怎麼合在一起的，以及為什麼我覺得它們本來就該是同一個東西。
iThome鐵人賽
看影片追技術