解決人工進行日期換算，與期數換算的失誤率？
本篇要解決的問題
Ｑ：解決人工進行日期換算，與期數換算的失誤率？
關於任務背景
近期在做把之前做的合約資料的管理數據庫，轉換到一套 CRM 的系統裡
但遇到的其中一個狀況是，因為合約有分不同時間區段
對應的產品交付與費用是不同的，導致在人工換算的過程中，發現失誤
以及遇到不同的人填寫，會出現填寫規格不同的狀況
→ 解決：如何降低人工的錯誤率＋不同人的輸入資訊差異
以終為始的架構設計→ 要達到哪些目標
開始的第一步，先來把要解決的問題，變具體的目標
- 降低人工的錯誤率 → 目標：把換算計算變成公式，讓電腦自己自動計算
- 不同人的輸入差異 → 目標：建立一個輔助器去輔助大家填寫
再來要拆分大目標（終）→ 小項目（執行）
目前輔助器是最終目標，再來列點，輔助器裡基本需要哪些東西，來解決問題
- 不同階段各自要交付的東西 → 用選項，去做劃分不同產品名稱
- 交付的東西，對應的要收款的日期 → 找到對應的收款日，與合約日關係，換算公式
- 收款費用彼此之間有期數的關係 → 自動計算一年合約收款類別之間的期數 Ex : 收款 A 項目 → 6 期 ，之後接續換收款 B 項目 （12-6）6 期
- 拆解 CRM 填入頁面的樣子 → 適合用 Notion 裡的什麼來呈現
如何建立 符合的Notion 架構
在確定到底要用什麼 Notion 功能時，很關鍵的一點是
如果今天要做自動算數 → 那就是建立 資料庫 （這也是我最喜歡 Notion 的部分）
這一刻，可能會想，資料庫不是只適合當作資料收集數據嗎？
不不不！只要東西能夠被系統、規則化，或是被規模化去計算，他都適合用資料庫
所以先找到每個項目，以及要輸入的基本資料相關的關係
只要是有規則跟規律，那就可以開始把它變成資料庫了！
前期準備
我自己的小習慣是先把東西畫出來，預期資料庫的長相跟項目 也整理項目之間的關係後，再來開始建立資料庫
實際執行後的資料庫與函數用法
這邊就以上面這張作為實際的表格分享給大家看
這次有使用到的函數架構都是 Ifs() ，在日期換算部分搭配 DateAdd (數值,”單位”)
以下只針對兩個比較複雜的拿出來寫：期數換算、收費日期計算
收款費用，跟期數換算的函數差不多，只是把後面的期數變成金額數值 該項目總費用，則是每期費用＊期數
期數換算的部分：
ifs(prop("交付項目名稱").contains("A 項目"),1,
prop("交付項目名稱").contains("B 項目"),prop("期數"),
prop("交付項目名稱").contains("C 項目"),(12-1-(prop("Related 日期與期數轉換器")
.map(current.prop("期數")).format().toNumber()))
)
這標要特別注意項目名稱用的 Contains 一定要打的跟前面的一樣
包含： 全形半形，有無空白！不然會抓不到對應的資料
項目C 的部分有點複雜，這邊詳細說明一下：
C 的期數＝ 12(總期數) - 1 (A 項目的期數) - ? (B 項目的期數)
為了減少不同的人可能在這部分算錯，所以把關鍵設定在輸入 B 的期數之後，會進行上述的計算
但為什麼這邊只抓取 B 項目的期數，而不抓取 A 項目，主要是因為 A 在這都是統一固定 1
所以就不特別在額外用函數去讀取資料
當然如果你的期數都數固定組合的話，其實就可以用上面公式，寫 A 項目的方式，直接固定他
為什麼是用函數算，而不是手工輸入 -> 為了減少人工計算的錯誤，以及失誤 收款日期的部分：
ifs(prop("交付項目名稱").contains("A 項目"),prop("合約起始日").dateAdd(1,"months"),
prop("交付項目名稱").contains("B 項目"),prop("合約起始日").dateAdd(2,"months"),
prop("交付項目名稱").contains("C 項目"),prop("合約起始日")
.dateAdd((2+(prop("Related 日期與期數轉換器").map(current.prop("期數"))
.format().toNumber())),"months")
)
這標要一樣特別注意項目名稱用的 Contains 一定要打的跟前面的一樣
包含： 全形半形，有無空白！不然會抓不到對應的資料
這裡的收款日期是合約起始日後滿一個月，開始收費（跟你的手機電話費一樣）
再來 B 項目會固定的由合約起始日滿第二個月開始，收費
/*我個人習慣會是只要是固定的，就都直接用打數值去換算，不要透過讀取的方式去處理*/
最後又到最複雜的 C 項目，他會是在A B 項目都收款完之後，才會進行收款
那我這邊的寫法是 第二個月之後，又過了B 項目的期數後，才會是C 項目的收款日
第一個月： A 項目 ， 第二個月開始 ： B 項目 ， 第（12-2-B 項目的期數）個月：C 項目
以上面表格為例： A 項目：1 ， B 項目： 4 次 ， C 項目 7 次
05 月 -> 合約起始日，下個月開始收款
06 月 -> A 項目 (合約起始日＋ 1 個月)
07 月 -> B 項目 (合約起始日＋ 2 個月)
08 月 -> B 項目
09 月 -> B 項目
10 月 -> B 項目
11 月 -> C 項目 (合約起始日+ (12 - 2 - B 的期數))
12 月 -> C 項目
01 月 -> C 項目
02 月 -> C 項目
03 月 -> C 項目
04 月 -> C 項目
05 月 -> C 項目 最後完成的目標與Feedback
- 具體減少人員在換算的過程所需要的時間，與錯誤率
- 統一填寫的內容邏輯，方便直接對應到 CRM 系統上做填寫
- 新增了可以算出該單的總金額，可以與CRM 系統上的資料做二次核對
最後，關於做轉換器，我踩過的坑
這個轉換器寫到這版本，其實已經是修改實際應用優化過的第三版
→ 這中間還有定義要填入的是含稅版本，還是不含稅版本，不含稅的話稅率多少 怎麼計算，甚至是折扣金額，怎麼對應到費用去計算
最大的坑，我想是可能對自己來說的簡單算數，對另一個人說可能不簡單
我想這就是一種，別把自己的習以為常，認定成對方也該習慣的
已經對自己來說的終，未必是最靠近對方的終
一開始，我並沒有額外把期數做換算
直到實際應用時，主要使用者說，他其實連期數都很需要花時間計算
這大概就是有時候架設的複雜，其實是試著為不同使用者做考量
跟寫完一個東西，要記得去好好傾聽，真正在用的人他的困擾還有什麼
進而去優化，調整他
這篇就先分享到這啦～
這些實戰的分享，可能更多是適合已經有一定熟悉度的人去參考的
但我想把它記錄下來，一部分也是分享 Notion 還有什麼可能
以及記錄下來這些年解決過的不同問題
希望他們不會隨著時間或是人生際遇而失去
✨ 延伸服務
如果你希望有人協助你一起搭建適合你的 Notion 架構，目前我也有提供諮詢與設計服務，
歡迎來信聯繫 聯絡 Triple.Cell | Joy ( jouyu.chen.jc@gmail.com )
閱讀更多文章
架構好之後，難道就能夠長時間的一直用嗎？
怎麼開始離開 Notion 的新手村？
解決人工進行日期換算，與期數換算的失誤率？
為什麼很多人覺得 Notion 太自由，反而難以上手？
有沒有可能看到自己追尋過的痕跡，反而讓感受到我能繼續走下去勒？
我們的時間到底跑去哪了？