From 9 to 1 with Cell
  • 從0開始做架構
  • 設計與創作筆記
  • 思考與觀察筆記
用 Notion 做換算工具

用 Notion 做換算工具

Post time
01/05/2025
類型
這些年做過的架構
本篇提問

解決人工進行日期換算，與期數換算的失誤率？

本篇要解決的問題

Ｑ：解決人工進行日期換算，與期數換算的失誤率？

  • 本篇要解決的問題
  • 關於任務背景
  • 以終為始的架構設計→ 要達到哪些目標
  • 如何建立 符合的Notion 架構
  • 前期準備
  • 實際執行後的資料庫與函數用法
  • 最後完成的目標與Feedback
  • 最後，關於做轉換器，我踩過的坑
  • ✨ 延伸服務

關於任務背景

近期在做把之前做的合約資料的管理數據庫，轉換到一套 CRM 的系統裡

但遇到的其中一個狀況是，因為合約有分不同時間區段

對應的產品交付與費用是不同的，導致在人工換算的過程中，發現失誤

以及遇到不同的人填寫，會出現填寫規格不同的狀況

→ 解決：如何降低人工的錯誤率＋不同人的輸入資訊差異

以終為始的架構設計→ 要達到哪些目標

開始的第一步，先來把要解決的問題，變具體的目標

  1. 降低人工的錯誤率 → 目標：把換算計算變成公式，讓電腦自己自動計算
  2. 不同人的輸入差異 → 目標：建立一個輔助器去輔助大家填寫

再來要拆分大目標（終）→ 小項目（執行）

目前輔助器是最終目標，再來列點，輔助器裡基本需要哪些東西，來解決問題

  • 不同階段各自要交付的東西 → 用選項，去做劃分不同產品名稱
  • 交付的東西，對應的要收款的日期 → 找到對應的收款日，與合約日關係，換算公式
  • 收款費用彼此之間有期數的關係 → 自動計算一年合約收款類別之間的期數 Ex : 收款 A 項目 → 6 期 ，之後接續換收款 B 項目 （12-6）6 期
  • 拆解 CRM 填入頁面的樣子 → 適合用 Notion 裡的什麼來呈現

如何建立 符合的Notion 架構

在確定到底要用什麼 Notion 功能時，很關鍵的一點是

如果今天要做自動算數 → 那就是建立 資料庫 （這也是我最喜歡 Notion 的部分）

這一刻，可能會想，資料庫不是只適合當作資料收集數據嗎？

不不不！只要東西能夠被系統、規則化，或是被規模化去計算，他都適合用資料庫

所以先找到每個項目，以及要輸入的基本資料相關的關係

只要是有規則跟規律，那就可以開始把它變成資料庫了！

前期準備

我自己的小習慣是先把東西畫出來，預期資料庫的長相跟項目 也整理項目之間的關係後，再來開始建立資料庫

image

實際執行後的資料庫與函數用法

這邊就以上面這張作為實際的表格分享給大家看

icon

日期與期數轉換器

交付項目名稱
合約起始日
產品名稱
期數
期數換算
收款日期
每期收款費用
該項目總收費
Related 日期與期數轉換器
Related back to 日期與期數轉換器
A 項目
May 1, 2025
C01
1
June 1, 2025
NT$10,000.00
NT$10,000.00
B 項目
May 1, 2025
C02
4
4
July 1, 2025
NT$15,000.00
NT$60,000.00
C 項目
C 項目
May 1, 2025
C03
7
November 1, 2025
NT$20,000.00
NT$140,000.00
B 項目

這次有使用到的函數架構都是 Ifs() ，在日期換算部分搭配 DateAdd (數值,”單位”)

以下只針對兩個比較複雜的拿出來寫：期數換算、收費日期計算

收款費用，跟期數換算的函數差不多，只是把後面的期數變成金額數值 該項目總費用，則是每期費用＊期數

最後完成的目標與Feedback

  1. 具體減少人員在換算的過程所需要的時間，與錯誤率
  2. 統一填寫的內容邏輯，方便直接對應到 CRM 系統上做填寫
  3. 新增了可以算出該單的總金額，可以與CRM 系統上的資料做二次核對

最後，關於做轉換器，我踩過的坑

這個轉換器寫到這版本，其實已經是修改實際應用優化過的第三版

→ 這中間還有定義要填入的是含稅版本，還是不含稅版本，不含稅的話稅率多少 怎麼計算，甚至是折扣金額，怎麼對應到費用去計算

最大的坑，我想是可能對自己來說的簡單算數，對另一個人說可能不簡單

我想這就是一種，別把自己的習以為常，認定成對方也該習慣的

已經對自己來說的終，未必是最靠近對方的終

一開始，我並沒有額外把期數做換算

直到實際應用時，主要使用者說，他其實連期數都很需要花時間計算

這大概就是有時候架設的複雜，其實是試著為不同使用者做考量

跟寫完一個東西，要記得去好好傾聽，真正在用的人他的困擾還有什麼

進而去優化，調整他

這篇就先分享到這啦～

這些實戰的分享，可能更多是適合已經有一定熟悉度的人去參考的

但我想把它記錄下來，一部分也是分享 Notion 還有什麼可能

以及記錄下來這些年解決過的不同問題

希望他們不會隨著時間或是人生際遇而失去

✨ 延伸服務

如果你希望有人協助你一起搭建適合你的 Notion 架構，目前我也有提供諮詢與設計服務，

歡迎來信聯繫 聯絡 Triple.Cell | Joy ( jouyu.chen.jc@gmail.com )

icon
前一篇
icon
下一篇

閱讀更多文章

人生思考與觀察
和 GPT 聊八字後，我開始重新反思命運與選擇
和 GPT 聊八字後，我開始重新反思命運與選擇
觀察與收信

人生轉變，是命運在推動你，還是你只是順著自己的心做選擇？

那些在失去力氣的日子裡的自我覺察
那些在失去力氣的日子裡的自我覺察
自我認識與療癒

當我們進入自己不喜歡的狀態時，那裡是否藏著某種「執著」？

Logo

Where could find Joy

Joy 風景攝影 ｜ IG

Triple.Cell | 細胞日常插畫

細胞日子感受牌｜賣貨便

Notion 模板 | Notion 官網

© Triple.Cell_91_Joy

Instagram
期數換算的部分：

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 項目