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

JasonQ wrote:
你不知道如何用API匯入“資料庫檔案”,再交由後台系統合併資料庫?

現在網路時代都講究時效性
每筆帳款客戶付款後
就趕快進入到系統
為什麼要採用你那種沒時效性的做法?

JasonQ wrote:
一次餵10筆交易明細,必定要搭配10筆10次匯款入帳,還是一次匯款10筆總結的貨款?

除非你只要"帳款總額"
不然就是會有這10筆的交易明細
然後系統就是要把這10筆交易明細去對映到帳單啊

你說的每日結、每週結、每月結
難道就不要明細嗎?
當你只要一個"總額"時,就是指沒有明細
如果有明細,也還是要處理到233萬筆訂單

有入帳就趕快處理,時間上還分散掉
但你的說法是把233萬筆明細一次處理?
這樣既沒有時效性
還把處理明細的負荷給集中到同一時間
mig33 wrote:
現在的主流做法就是A...(恕刪)


233萬筆明細而已,不需呼叫233萬次金流驗證系統吧?

這樣不就大.....幅降低系統負擔?
mig33 wrote:
現在網路時代都講究時...(恕刪)


你沒做過進出口貿易? 你沒一次買過2項以上同種商品?


你沒用過合併結帳!!?

都說超商是週結付款了,你還在講求即時資訊!!?
mig33 wrote:
現在網路時代都講究時...(恕刪)


每筆帳款? 週結模式有幾筆帳款?
JasonQ wrote:
233萬筆明細而已,不需呼叫233萬次金流驗證系統吧?
這樣不就大.....幅降低系統負擔?

你說的每日結、每週結、每月結
難道就不要明細嗎?
當你只要一個"總額"時,就是指沒有明細
如果有明細,也還是要處理到233萬筆訂單

有入帳就趕快處理,時間上還分散掉
但你的說法是把233萬筆明細一次處理?
這樣既沒有時效性
還把處理明細的負荷給集中到同一時間


同樣要處理233萬筆明細
分散時間每次傳送一小量
還比集中時間一次傳送極大量來的好
因為傳送"大檔"中途當掉的機率比較大
mig33 wrote:
你說的每日結、每週結...(恕刪)


你真的不懂還是硬凹?

明細跟掌帳款可以分開你知道嗎?

只有交易明細不用處理線上金流驗證你知道嗎?

你知道單純文字檔案的傳輸而不需要串接認證系統比較簡單嗎?
mig33 wrote:
你說的每日結、每週結...(恕刪)


“同樣要處理233萬筆明細
分散時間每次傳送一小量
還比集中時間一次傳送極大量來的好
因為傳送"大檔"中途當掉的機率比較大”

你都知道可以分批傳輸了....

既然如此,週結或是日結帳可以吧?不需要做到秒結帳或是分結帳吧?
JasonQ wrote:
你真的不懂還是硬凹?
明細跟掌帳款可以分開你知道嗎?
只有交易明細不用處理線上金流驗證你知道嗎?
你知道單純文字檔案的傳輸而不需要串接認證系統比較簡單嗎?

是你在硬凹吧?
請問你到底要不要明細?
要明細,就是233萬筆明細
系統就是要把233萬筆明細對映到訂單
既然這個工是一定要做的話
那差別就是"即時處理"或"一次處理"

我不認為一次處理比較好
第一,沒時效性
第二,一次處理傳送的資料(檔案)比較大
假設每筆訂單明細會用去60bytes
233萬筆的明細就是2,330,000*60=139,800,000
大約是140MB大小的檔案

別以為140MB不大
很多系統參數沒調校好的時候
可能連處理和傳遞20MB大小的資料(檔案)就出現error

若要設計成分批處理的話
分2批是分,分233萬批也是分
銀行餵資料會把同1分鐘的合併餵
所以實際上也應該會比233萬批還少
橫豎都要分批的話
那就採兼顧時效和分散處理時間的方法就行了
也就是靠API每1分鐘(或每5分鐘)來串接

又你不是說你知道使用者刷卡的手機驗證碼是銀行系統在處理
那線上金流驗證流程這部分,不關公司系統的事

至於公司和銀行之間,通常是初期
雙方防火牆和系統各自設定好相關的資訊
後續都是程式自動在跑了
mig33 wrote:
不好意思你只是自認為(恕刪)

某人講的那麼利害~就讓他當政務官就好辣.幹嘛跟他認真
~~台灣最不缺的是酸民..可悲
loveyabe8 wrote:
某人講的那麼利害~就(恕刪)


腦子只能想著 <7元很多嗎?>的傻民

也不少
文章分享
評分
評分
複製連結
請輸入您要前往的頁數(1 ~ 20)

今日熱門文章 網友點擊推薦!