唐鳳 應該知道吧 "超商可以取貨付款 "

sunstars wrote:
你這個叫做流程不一樣，所產生的過程也就不一樣

你貼的那兩張圖
不是都是現有系統
還需要開發什麽
最多就你愛說的API介接

就你的流程圖串街金流
是不是都有物流選項要不要開啟
沒開啟就另外做
有開啟就一起做

sunstars wrote:
你有很確定一萬多分的大包裹中的小包裹裡面都沒有貼標籤嗎？
當然標籤有很多種方式。
已知就是要先去超商應取貨小白單
若小包裹和小白單最有數量有差異，責任要算誰的

不要要算無辜小店員吧

sunstars wrote:
我們在金流系統開帳後的一些API及資料庫
你怎麼又從後台跳到前台去了
你以為金流公司平常會放機器閒置的嗎

所以平常超商就沒物流嗎
若能有233萬筆物流配送，代表每筆都能追朔，不是對大家責任都清楚嗎
且是因為政策關係所以要一次那麼多筆
那不會弄可以分梯每天配送的領口罩政策嗎

mig33 wrote:
我看不懂你這個問題是想問什麼
我那幾張圖都是從金流公司的API文件擷取出來的
也就是照著API文件的流程圖寫串接程式就行了
那是金流公司的文件，不是物流公司的文件
口罩預購系統，顯然不必做追蹤233萬筆物流功能
(要做的是統計每個超商分店該配送多少口罩的功能)
所以你所謂的物流選項要不要開啟我也不知這算什麼問題

mig33 wrote:
聽你的意思是：
把這些預購的口罩變成233萬份指名的小包裹
然後再把這233萬份小包裹整理成一萬多份大包裹？

那233萬份的物流標籤列印了之後，誰要貼？
如果雇用233個人來貼，每個人要貼1萬份小包裹
弄個自動把口罩打包並自動貼標籤的機器？
不知要搞幾條這樣的封裝線？須時多久？
這個工程比串接金流系統還要更大N倍吧
以上只是討論"誰要貼標籤"
還沒討論"誰要把233萬份小包裹整理成一萬多份大包裹"

「已知就是要先去超商應(印?)取貨小白單」
看起來說的是採用目前做法要先印取貨單
但採用"取貨付款"(指名包裹)就不用印取貨單是吧？

233萬人份口罩，全國11500個超商門市
平均每個門市要處理200人份
(有些熱門門市可能會處理到500人份或更多)
指名包裹要讓超商店員從這麼多份包裹中找到取貨者的
然後還要做收現找零的動作.... 店員會瘋掉吧
取貨單的情況下
拿一份口罩給顧客(不用找包裹)、也免收現找零(及分辨偽鈔)

mig33 wrote:

我不知你幹嘛要提到前台後台
但不管前台後台，串銀行或串超商也都有類似的流程要跑
先前你認為串接銀行金流時，銀行要做"設定"
但你的"設定"這用字太模糊了，你一下說資料庫、一下說人工確認
銀行(或超商)那邊就是開帳號和給API文件，銀行不用改什麼資料庫
若有什麼要人工確認的地方，串超商的情況也一樣會有
不會因為我同意串銀行要做設定，於是你就得證串超商不用做設定
所以銀行(或超商)要在前台後台做什麼事(我不知道你指什麼)也並不重要

看你把金流233萬筆講的負荷很重
但物流233萬筆卻講的沒什麼差別似的

你說的東西也是可以調換角色的
「你以為金流公司平常會放機器閒置的嗎」(你的意思是金流公司要為此增加一些機器？)
--> 那你以為物流公司平常會放機器/人員閒置嗎 (物流公司不用為此增加一些機器/人員？)
「所以平常超商就沒物流嗎」(你的意思是加上233萬筆物流只是順便多處理一些？)
--> 所以平常銀行就沒金流嗎 (加上233萬筆金流難道就不是順便多處理一些？)

基本上金流的233萬筆都是電腦系統在處理的
物流的233萬筆免不了還是有需要人工處理的地方
就算全自動化好了，也還要靠機械處理
在處理效率上還是比不上金流系統電子資料交換
金流233萬筆(電子數據)還真的沒什麼
但物流233萬筆(實體物品)就會很嚴重了...
(例如雇用233個人來貼標籤，每人要貼1萬份包裹)

先付款再取貨 vs 取貨付款(指名包裹)
前者大幅把233萬筆物流量簡化到1萬多筆而已
等於節省了99.5%的物流數量
指名包裹233萬件就算分梯成7天處理
每天也還是要處理33.3萬件

你主張233萬筆物流實在沒什麼
但對照你把233萬筆金流看得負荷很重
不知你衡量的標準是什麼？

sunstars wrote:
你那個流程圖不是有快16個
有的存金流有的金流帶物流，有的純物流
若有個現有模型金流物流一起來做不是比較快嗎？

sunstars wrote:
是不是不知道在超商取貨有些可以直接刷卡
我要和你說不管如何那233萬筆資料，最終都要有個結果對不
若是若有個系統都包好了，就用那套就好了

sunstars wrote:
若你搞懂（健保卡處理完哪些可買後，接連的物流金流部份）
一個是全現有系統
一個是現有系統需要在串接
是那一種
問題就解了

mig33 wrote:

好像你一直以為用超商系統就不用做"串接"？
你還是沒搞懂
超商的只是物流系統、金流系統
不是口罩預購系統
因此完全不存在[全現有不用串接]這種事情
超商系統並沒有讓人實名預購口罩的功能
你想像的大概是"魔法系統"
以為不用串接就可以讓兩個系統之間傳遞資料

另外一個很簡單的道理
若是現有超商系統就可以滿足口罩2.0預購的金流
四大超商也會跟政府談好直接利用他們的系統
臺灣銀行都說了「不會向政府或消費者收取任何手續費」
這種不好康的事，能讓四大超商去做，臺銀又何必沒事找事
還用得著你去"想像"四大超商的系統不用改就能辦好事情？

下圖我把"金流系統"前面加了三個字"超商的"
代表口罩預購系統直接串超商系統的情況


第三方金流系統和超商系統之間也有互相串接
很多細節沒畫出來，並不是不存在(只代表你不用知道這麼細)
難道你以為拿掉第三方金流之後就不用做"串接"這份工？
若想直接串超商的金流系統也還有個問題
超商有4家 (7-11、全家、萊爾富、OK)
直接串超商系統的話，串接程式要寫4家(等於4份工)
若再加上你之前喜歡提的"設定"，那也會是4份"設定"
先前你認為"串接"背後有很多事的話，串4家超商的事就4倍
串銀行系統的話，已知收單金流是臺灣銀行

mig33 wrote:

雖然最終都要追蹤這233萬購買者有沒有去取貨
但中間過程的物流量可是差距很大
先付款再取貨可以把物流量簡化到1.15萬筆
節省99.5%的物流量，只剩0.5%的物流量

貨到付款的物流量是233萬筆
這233萬筆物流可是實體物品(指名包裹)
光是把包裹貼標籤，和進一步整理成1.15萬個大包裹
就是一個很浩大的作業量了
以貼標籤來說，假設3秒可以貼一個包裹
-> 1分鐘貼20包裹 -> 1小時貼1200包裹 -> 8小時貼9600包裹
2330000 / 9600 = 243
要貼完233萬個包裹等於要243個人力(一天完成的話)

硬要套用某個做法，結果就是耗用大量人力，怎麼會好？
雙11時，PChome的出貨速度是12小時10萬件(物流士約250人)
233萬個包裹，不用懷疑，就是會把物流給癱瘓掉
討論至此，兩種做法的優劣已經很明顯了

mig33 wrote:
並沒有比較快！
我有舉國語作業和英語作業的例子 <-- 你省略這部分不談了？
分成兩個作業本，國語要寫100行、英語要寫100行
合併成一個作業本，也是國語寫100行、英語寫100行
換成老師和上課時數也是
分成兩個老師上課，國語要上5堂課、英語要上5堂課
改由同一個老師來教國語和英語，也是國語5堂課、英語5堂課
要說有什麼方便的地方
要帶的作業本從2本變成1本
家長要連絡的老師從2個變成1個 <-- 消費者像這個，是有比較方便
但是學生該寫的作業量、該上課的堂數仍不會變少 <-- 工程師像這個，工作沒少
更不利的是，本來英語(不被重視)有機會不用寫、早點交作業
雙語合一之後英語反而變成一定要寫、不能省略 <-- 你說的一起做像這個，沒比較快
註：國語作業比喻金流、英語作業比喻物流

sunstars wrote:
恭喜
狂賀
你懂了我們在討論什麽了

（健保卡處理完哪些可買後，接連的物流金流部份）
首先你圖中什麽都不要改
一個是全現有系統在串接
我上面再補後三個字應該比較好懂吧

（健保卡處理完哪些可買後，接連的物流金流部份）
那如果你圖中金流要改成台灣銀行就是
一個是現有系統需要在串接

我是為了讓你懂把健保卡篩選資料獨立出來，實際上也是獨立出來的。

sunstars wrote:
做事要會變通
若依現在流程超商取貨不付款
不是也要貼標籤
所以變通方式不是讓消費者直接用小白單或條碼領貨
那何貨到付款
就不能變通為讓消費者直接用小白單或條碼付款及取貨

該名藥師在臉書社團「爆怨公社」發文表示，自己經營一間不限時間的小藥局，自口罩實名制以來變得非常繁忙，沒有休息時間，「希望大家有同理心，能自備零錢購買口罩。」

他敘述，昨天傍晚，一位帶著國小四、五年級小朋友的媽媽，拿出千元大鈔想買口罩，無奈藥局實在沒有零錢找開，於是跟客人表示自己會幫忙保留，是否能夠稍晚再拿零錢過來？沒想到客人立即爆炸，當著小孩的面歇斯底里開譙，「等等不去買東西不是一樣沒零錢？而且你們怎麼可能沒零錢！怎麼可能沒有！」還接著說出「不高興不要賣啊！」經典名句。

sunstars wrote:
不是我要省略他
是你的比喻就不是這樣套用在那上面

fu888168 wrote:
有些人怎樣都要嘴
每一個人都好神 點子多
每一個人都好棒 方法讚

VincentLu1021 wrote:
這篇學到不少知識, 個人比較相信 MIG33 寫的內容, 比較合乎一般寫程式的做法.
S網友的主張比較像主管, 只要結果, 但不管實作內容, 主管想像的事, 工程師就要照做....
會做死.....

mig33 wrote:
難懂的原因是因為你一直在講一個不存在的狀況：
你認為使用超商的系統就"不用串接"這種事

那幾張圖中的金流系統都是必然存在的
只是由誰扮演的問題而已，不管由銀行扮演或由超商扮演都是要串
要串銀行，就是銀行開帳號和給API文件，口罩系統寫串接銀行的程式
要串超商，就是超商開帳號和給API文件，口罩系統寫串接超商的程式
事情絕對不會是由銀行扮演就需要串，由超商扮演就不需要串
所以還是不懂你到底想表達什麼！
除了你好像在表達由超商扮演金流就不用串？

mig33 wrote:
難懂的原因是因為你一直在講一個不存在的狀況：
你認為使用超商的系統就"不用串接"這種事

mig33 wrote:
現在的方式哪需要貼233萬份包裹的標籤？
現在方式的取貨小白單，是隨便拿一份口罩(非指名包裹)給消費者就好
要處理的物流量只有1.15萬筆，貼物流標籤也只是貼1.15萬份
跟233萬份的物流標籤比較起來，省了99.5%的作業量

你的"變通"不知想變成怎樣？
想變成不再靠233萬份指名包裹的方式了？也就是金流和物流脫鉤？
脫鉤的話，你之前說的"一起做"就被推翻了(但一起做也沒少做工就是了)
至少現行的方式，超商店員不用處理收現和找零的問題
你所想的"變通"方式(只要有"收現")，就會讓超商店員增加負荷

mig33 wrote:
我只知道站在系統開發的角度來說
串金流的工、串物流的工，不會因為"一起做"就比省事
每個程式各司其職時是比較容易debug的
不同工作由不同程式去處理最明確(串金流程式和串物流程式各司其職)
若要把不同的工作塞在同一支程式去處理
只是"帳面上"的程式檔變少(就像雙語合一的作業本或老師數變少)
但實際要寫的程式碼並不會因為帳面程式檔減少就跟著減少(是你自己想像會減少)
甚至在發生問題時，要著手的範圍比較大(程式檔跨很多功能)，反不易判斷處理
所以你都只是在自行想像系統開發哪些事要做哪些事不用做罷了