想像一款雲端發票 app 要讓顧客可以登錄紙本電子發票

可以按照下面步驟進行：

1. 顧客輸入發票
2. 顧客點選送出
3. 後端 API 檢查基本資訊：包含發票號碼、隨機碼、日期檢查。

如果你想設計更多元一點活動，例如登錄發票可以抽獎，還要考慮該檔活動時間和發票消費日期。

以下是我考慮的檢查情況

(1) 發票格式錯誤：可以用正規化表達式檢查 r'^[A-Z]{2}[0-9]{8}$'

(2) 發票重複輸入：由於在還沒確定這張發票號碼錯誤以前，重複的發票號碼會先被後端擋住，避免輸入重複的發票

(3) 隨機碼格式錯誤：可以用正規化表達式檢查 r'^[0-9]{4}$'

(4) 發票查詢後不存在或隨機碼有誤，顧客又重新輸入一樣的發票號碼且其他資訊都一樣(發票日期、隨機碼)：避免輸入重複的錯誤發票

(5) 日期格式錯誤：可以用 datetime 模組檢查

(6) (Optional) 發票日期不在指定發票期間

(7) (Optional) 登錄的時間不在指定活動期間

4. 登錄發票：一開始我選用關聯式資料庫，而我將手動發票、從財政部查詢的正確發票(也考慮到要紀錄載具的發票)分開紀錄在不同的表。由於顧客輸入的手動發票可能會錯，可能活動也要設計可以重新輸入的機制，也因此你不能將發票號碼當作 key 值。

   下圖我將發票資料寫進 invoiceManual (代表手動發票)，並記載為登記中或查詢中。