JasonQ wrote:
我已經不想跟他一起鬼打牆了....
一個過渡時期使用的口罩分配系統
一個只有一個星期開發時間的口罩預購系統
我不知道為何要捨棄原有的資源，大張旗鼓的建置線上支付金流系統....
第四是線上付款與金流，ATM 轉帳、信用卡付款等方式，需處理與銀行金流的系統串接、跟超商拆帳等細節。
mig33 2020-03-12 14:26 145樓
你一直把焦點放在233萬筆訂單的金流串接
我覺得你忽略了，真正的問題在前段
也就是開放預購時湧入的流量，才是最大的考驗
銀行系統通常半夜有一些時段停止服務
假設一天運作22小時=1320分鐘
每分鐘串一次資料，那一天就是串接1320次
付款期限不知道給多久，假設4天 (後面3天留給物流)
串接次數就是5280次
如果有一半的人採用ATM付款
就等於串接5280次處理掉一百多萬筆訂單
JasonQ wrote:
233萬線上支付會如何？看這幾天虛擬主機、頻寬要增加多少吧？（這些都是錢）
李伯璋今天清晨6點多提供最新統計，根據昨天9點上線到晚間12點的資料，透過App預購成功人數共365711人，emask網站預購成功者有104016人，其中健保卡插卡者共55418人，自然人憑證插卡者共48598人，合計有469727人預購成功。
nyslap wrote:
買的人吸收?要怎麼讓...(恕刪)
JasonQ wrote:
花時間搞線上金流？ 已經很成熟的技術，只要有足夠的頻寬、夠多的虛擬伺服器做平行運算、夠長的開發與壓力測試時間....就可以做到的事，何必花資源硬要合併在系統內？
mig33 wrote:
以下擷取自"藍新金流"
信用卡付款--在第6道動作回傳付款完成訊息
ATM轉帳--在第8道動作回傳付款完成訊息
超商取貨付款--在第9道動作回傳付款完成訊息
每一種方式全都有串接
就算超商取貨付款也是免不了要串233萬筆
你認為超商取貨付款不用串接根本是你的想像
而且可以由銀行電腦系統完成的事情
你覺得非要讓超商店員來處理收現找零這些事
mig33 wrote:
你才鬼打牆
新聞也明明確確的說做的事情是與銀行金流的系統串接
你偏要扭曲成開發建置線上支付金流系統
mig33 wrote:
前面我就貼了三張交易流程圖給你看
信用卡, ATM轉帳, 超商取貨付款
不管哪種都一樣要做"串接"
可能你看不懂那三張交易流程圖...
JasonQ wrote:
我已經不想跟他一起鬼打牆了....
JasonQ wrote:
看協議取貨限制幾天，假設三天，三天沒取貨付款，口罩就直接原店重新加入庫存清單，直接分配給下一批預購的人....
預購系統只要掌握各店回報的取貨狀態、未取貨名單，系統直接扣除下一批物流到店（甚至於再提早到郵局到物流中心的數量）。
這樣，運費只有一次，政府也不用吸收棄標的衍生費用（頂多超商協助多存放6天，我認為超商可以不索取這六天倉儲費用）
系統除了扣帳，還把未取貨的名單加入禁止名單，假設設定30天不能再預購....
如果棄標的人多，預購系統負擔自然降低
如果棄標的人少，系統自然可以發揮“物流配送、庫存分配的大數據分析功能”，把有限資源做最大的利用~~~
這才是展現台灣人工智慧、大數據分析技術的功能 - 智慧物流優化，而不用靠人工去配貨、配訂單....
