###### tags:`Gateweb`

# TapSquare 專案(管理模組相關)

TapSquare 相關
===

需求
---

註冊模組(Register)
===
目的：用於給外部使用者申請及註冊的模組

Security
---
註冊模組的複雜度取決於是否存在多樣的註冊方式
* 防火牆對外80 port
* 不需token認證

問題
---
* 註冊時所需的客戶資料
* 註冊時需要決定並產生的東西
* Yahoo現行註冊流程是什麼樣子?
* Yahoo的現行註冊流程遇到了什麼問題?
* GW的現行註冊流程是什麼樣子?
* eason working on it
* GW的現行註冊流程遇到了什麼問題?
* TapSquare的客戶與GW及Yahoo的客戶有什麼不一樣?
* 這個註冊模組應該擁有哪些功能?

GW註冊流程
---

Yahoo註冊流程
---

st=>start: 開始
cond1=>condition: 是否已使用電子發票？
cond2=>condition: 是否為關網用戶？
cond3=>condition: 申請資格
dType=>operation: D類
cType=>operation: C類
aType=>operation: A類
bType=>operation: B類

st->cond1
cond1(yes)->cond2
cond1(no)->cond3
cond2(yes)->dType
cond2(no)->cType
cond3(yes@yahoo)->aType
cond3(no@yahoo+GW)->bType

yahoo的流程中，雖然A及B類都要申請電子發票資格
但當申請Yahoo+GW時，需要派業務去了解客戶是否有開立B2B+B2C發票的需求
實際申請件的內容填寫會有不同
**根據Yahoo經驗，我們應該也要對申請進來的客戶進行分類**

管理模組(Management System)
===
目的：管理公司資料，及各種「可能決定取號過程的資料」

Security
---
理論上不會對外，不用考慮太多安全問題
* 防火牆對內
* 不需token認證

管理元素
---
#### Assign Log

#### Printer

#### Vender

#### Buyer

#### Entity Data(?)
不明確是指什麼意思，聽起來像是Buyer及Vender的中介資料，用來取代原來Company的設計
如果是這樣是不是叫Business Entity比較好

#### Department

#### Team

問題
---
* 原有的Company 與新的Business Entity有什麼不一樣，為什麼要分成兩個不一樣的東西
* Department及Team要如何與AssignLog及Printer關聯，從屬關系又是如何
* Department及Team各自代表著什麼意義，我們希望使用者怎麼使用這個關聯
* 為了不讓AssignLog直接與各種元素關聯，我們應該需要一個中介表來解除藕合
* 為了不讓Printer直接與各種元素關聯，我們應該需要一個中介表來解除藕合
* 印象中sean在之前的設計中把AssignLog分成了兩層，一層是原始資料另一層是拆分的每50張一份的資料，這個設計在張數統計及取號速度上會有幫助，但也有可能會增加分配字軌的複雜度

取號模組(?)
===
目的：取號

Security(*待確認*)
---
與我們打算怎麼賣這項服務有關，如果未來會有單獨取號的需求，則需要將他對外
並加上token認證