sunstars wrote:
本篇主要討論超商付款
超商取貨付款或先付款取貨
後面都已經有現有的金流系統
以超商付款來說
訂單收款明細和金流系統是分開的
不要混在一起談
"串接"金流系統本來就反映訂單的收款狀態
除非你也認為採"爛尾式"做法
(不要管個別訂單的收款狀態、不管懲罰機制)
不然設計系統的時候本來就是要綜合考量
那你說,超商取貨付款
要不要把每個訂單的付款狀態取回來?
至於所謂的"金流系統"
算起來主要也是銀行那邊在做
線上刷卡、ATM轉帳都是銀行系統處理的
所以也是現成的金流系統
一般公司"串接"銀行的金流系統
其實只是把銀行那邊的訂單收款狀態值拿回來
你該不會連這一點也不知道?
以線上刷卡來說
一般公司網站就把訂單資料帶到銀行網站
所以使用者在做刷卡動作時
填信用卡號碼、手機收驗證簡訊....等
都是在銀行的網站上做<--使用銀行現成的金流系統
最後才把刷卡結果(=訂單收款狀態)帶回一般公司網站
請你回答你知不知道以上這些?
我猜你是想像成一般公司網站也做自己的金流系統
不然"串接"金流系統這件事本質上也是使用現成的金流系統
然後取得訂單的付款狀況
mig33 wrote:
"串接"金流系統本來就反映訂單的收款狀態
除非你也認為採"爛尾式"做法
(不要管個別訂單的收款狀態、不管懲罰機制)
不然設計系統的時候本來就是要綜合考量
那你說,超商取貨付款
要不要把每個訂單的付款狀態取回來?
至於所謂的"金流系統"
算起來主要也是銀行那邊在做
線上刷卡、ATM轉帳都是銀行系統處理的
所以也是現成的金流系統
一般公司"串接"銀行的金流系統
其實只是把銀行那邊的訂單收款狀態值拿回來
你該不會連這一點也不知道?
金流是金流
訂單狀況是訂單狀況
不要把金流及訂單狀況扯在一起
難道你真的覺的
在超商每一個取貨付款會馬上匯錢給銀行端?
你自己都知道
收款狀態值拿回來
那超商取貨付款不是現有的嗎
所以是政府自己要玩一套才要弄那麼麻煩不是嗎
另外超商取貨付款是現有拍賣及網購大宗
所以那政府在忙什麽?
mig33 wrote:
以線上刷卡來說
一般公司網站就把訂單資料帶到銀行網站
所以使用者在做刷卡動作時
填信用卡號碼、手機收驗證簡訊....等
都是在銀行的網站上做
然後先付款後超商取貨
就會用到你說的流程
由銀行驗證此次付款是否通過
你講的這些不是都是網購不管取貨付款或先付款在取貨的現在進行式嗎?
若對現有的流程沒問題的話,那你還有那麼多圈圈的疑問我就不懂你了
sunstars wrote:
金流是金流
訂單狀況是訂單狀況
不要把金流及訂單狀況扯在一起
難道你真的覺的
在超商每一個取貨付款會馬上匯錢給銀行端?
你自己都知道
收款狀態值拿回來
那超商取貨付款不是現有的嗎
所以是政府自己要玩一套才要弄那麼麻煩不是嗎
另外超商取貨付款是現有拍賣及網購大宗
所以那政府在忙什麽?
金流是金流
一般公司(和口罩2.0)並沒有要做"金流"系統啊
金流系統也已經是銀行"現成"的
所以一般公司做的只是"串接"現成的金流系統
至於"串接"金流系統的目的就是即時取得訂單付款狀態
不然某些更小的公司,沒做串接金流時
一個簡陋的做法就是把公司的銀行帳戶資訊給客戶
請客戶匯款後再用人工方式通知說已付款
既然"串接"金流系統的目的就是即時取得訂單付款狀態
你所謂「不要把金流及訂單狀況扯在一起」根本就是你沒搞懂"串接"的意思
於是你把一般公司 "串接"金流系統 想像成 "開發"金流系統
銀行金流: 消費者 -> 公司銀行帳戶 (串接後很快就知道訂單付款狀況)
超商金流: 消費者 -> 超商 -> 公司銀行帳戶 (爛尾情況下不知訂單付款狀況)
但我沒看過有人做爛尾設計的,所以超商金流也是會跟公司系統做串接
超商收的錢叫"代收款"
正因為超商每一個取貨付款不會馬上匯錢給銀行端
利用銀行現成金流系統的好處就是連匯錢都不用匯了
使用者付款的錢就已經直接進公司銀行帳戶
(不過這個好處並沒很重要)
超商金流,收錢歸收錢、結算匯款歸結算匯款、通知收到錢歸通知收到錢
看來你又把 "通知收到錢" 跟 "結算匯款" 攪在一起了
公司系統串超商金流時,目的在取得個別訂單的付款狀態(=通知收到錢)
至於每週結算匯款,就只是把"代收款"移交給正主,跟通知訂單付款狀態兩碼事
並不是"通知"收到某訂單的錢了就必須要馬上把某訂單的錢"匯款"到公司銀行帳戶
通知收到錢可以每分鐘通知、每5分鐘通知、每小時通知、每天通知...都行
跟每週結算代收款要撥多少錢到銀行帳戶,是兩碼子的事情,不用綁在一起
但你提到「在超商每一個取貨付款會馬上匯錢給銀行端?」
看來你把兩者攪在一起,認為通知收到錢就等於要馬上匯錢到公司銀行帳戶
這可能跟另一網友把拆帳匯款和訂單付款明細併在一起講,導致你認為綁在一起
超商的金流系統是現成的
銀行的金流系統也是現成的
開發團隊有那麼笨要開發自己的金流系統?
還是你以為開發團隊在忙著開發新的金流系統?
似乎你沒弄清楚一般公司其實不開發自己的金流系統
我前面也說了
如果不要拿回單筆訂單的收款狀態值(爛尾)最快
在都要拿回單筆訂單的收款狀態值的情況下
先付款是串、後付款也是串
接銀行是串、接超商也是串
都一樣要取回233萬筆訂單的付款狀態值
另外取貨付款對超商店員來說
還要做核對證件、收現、找零...之類的動作
但先付款的情況下,就免了收現、找零
(這個好處看來不錯,可節省店員的處理時間)
sunstars wrote:
然後先付款後超商取貨
就會用到你說的流程
由銀行驗證此次付款是否通過
取貨付款的話
店員要驗證收到的錢是不是偽鈔
如果給的是大鈔,還要做找零的動作
--> 人工處理
先付款的話
刷卡、ATM交給銀行的金流來處理
--> 電腦系統處理
銀行電腦系統處理 vs 超商店員人工處理
你認為節省超商店員時間這個好處怎麼樣?
mig33 wrote:
金流是金流
一般公司(和口罩2.0)並沒有要做"金流"系統啊
金流系統也已經是銀行"現成"的
所以一般公司做的只是"串接"現成的金流系統
至於"串接"金流系統的目的就是即時取得訂單付款狀態
不然某些更小的公司,沒做串接金流時
一個簡陋的做法就是把公司的銀行帳戶資訊給客戶
請客戶匯款後再用人工方式通知說已付款
既然"串接"金流系統的目的就是即時取得訂單付款狀態
你所謂「不要把金流及訂單狀況扯在一起」根本就是你沒搞懂"串接"的意思
於是你把一般公司 "串接"金流系統 想像成 "開發"金流系統
銀行金流: 消費者 -> 公司銀行帳戶 (串接後很快就知道訂單付款狀況)
超商金流: 消費者 -> 超商 -> 公司銀行帳戶 (爛尾情況下不知訂單付款狀況)
但我沒看過有人做爛尾設計的,所以超商金流也是會跟公司系統做串接
超商收的錢叫"代收款"
正因為超商每一個取貨付款不會馬上匯錢給銀行端
利用銀行現成金流系統的好處就是連匯錢都不用匯了
使用者付款的錢就已經直接進公司銀行帳戶
(不過這個好處並沒很重要)
超商金流,收錢歸收錢、結算匯款歸結算匯款、通知收到錢歸通知收到錢
看來你又把 "通知收到錢" 跟 "結算匯款" 攪在一起了
公司系統串超商金流時,目的在取得個別訂單的付款狀態(=通知收到錢)
至於每週結算匯款,就只是把"代收款"移交給正主,跟通知訂單付款狀態兩碼事
並不是"通知"收到某訂單的錢了就必須要馬上把某訂單的錢"匯款"到公司銀行帳戶
通知收到錢可以每分鐘通知、每5分鐘通知、每小時通知、每天通知...都行
跟每週結算代收款要撥多少錢到銀行帳戶,是兩碼子的事情,不用綁在一起
但你提到「在超商每一個取貨付款會馬上匯錢給銀行端?」
看來你把兩者攪在一起,認為通知收到錢就等於要馬上匯錢到公司銀行帳戶
這可能跟另一網友把拆帳匯款和訂單付款明細併在一起講,導致你認為綁在一起
超商的金流系統是現成的
銀行的金流系統也是現成的
開發團隊有那麼笨要開發自己的金流系統?
還是你以為開發團隊在忙著開發新的金流系統?
似乎你沒弄清楚一般公司其實不開發自己的金流系統
我前面也說了
如果不要拿回單筆訂單的收款狀態值(爛尾)最快
在都要拿回單筆訂單的收款狀態值的情況下
先付款是串、後付款也是串
接銀行是串、接超商也是串
都一樣要取回233萬筆訂單的付款狀態值
另外取貨付款對超商店員來說
還要做核對證件、收現、找零...之類的動作
但先付款的情況下,就免了收現、找零
(這個好處看來不錯,可節省店員的處理時間)
如果一切和你說的
都是現成的
那為何還要建立另外的系統
現行的流程本來就不是利用現行暨有資源
若一切都用現有資源,根本就不需要再介接金流這件事情
因為我們討論的案子不一樣
所以永遠不會有交集
sunstars wrote:
如果一切和你說的
都是現成的
那為何還要建立另外的系統
現行的流程本來就不是利用現行暨有資源
若一切都用現有資源,根本就不需要再介接金流這件事情
因為我們討論的案子不一樣
所以永遠不會有交集
我說的是"金流系統是現成的"
但要"串接"金流系統 (不管是串接銀行金流或串接超商金流)
"串接"這件事也是要花一些時間
至於你認為採用超商貨到付款不用花時間的話
也就是你說的「根本就不需要再介接金流」
只有採用"爛尾式"設計才有可能
不過另一位網友討論到後來已否認他說的是爛尾式設計
更何況開發團隊要花時間在開發實名管制銷售系統
正確說來是拿一些已經存在的系統做修改
這些也都是要時間的
「因為我們討論的案子不一樣」
的確,你都是在想像你自己認為的案子
你根本不知道你主張的方式叫爛尾式設計
不去追蹤訂單付款狀態、不做懲罰機制的話
我同意這的確是最簡單的!
以下擷取自"藍新金流"
信用卡付款--在第6道動作回傳付款完成訊息
ATM轉帳--在第8道動作回傳付款完成訊息
超商取貨付款--在第9道動作回傳付款完成訊息






























































































