→ sagarain:合法的辦 01/25 09:32
所以寫程式的人就要賭上飯碗，跟腦殘主管或是更高層抗爭嗎?
這種 bug 不是 program bug, 是 policy bug, 以台灣的狀況來說幾乎無解，
但如果出事，一定是找某個倒霉員工來扛。
推 tsctao:丟掉業務 比得承擔事後可能的一堆莫名奇妙的風險來的好吧 01/25 09:39
推 hsinyeh:期交所根本沒有市價酖這種東西啊... 01/25 09:42
是啊，我也記得沒有市價單，但台灣的券商搞了一大堆奇怪的下單方式呢，
大家也習以為常了，例如市價單的做法就是漲停價丟下去...
股票是沒差，選擇權的市價單會要人命的。
這種非正規做法，有事先規劃的還好，但大多是在系統完成後才一個一個臨時加上去。
→ centaurjr:目前看起來風險不是在卷商就是買家,好像不關設計者的事 01/25 09:43
推 nuker:嗯，真的是程式應該就不只一人受害 01/25 09:45
推 rommel1:應該搞一個程式 即時監控保證金是否不足 01/25 09:52
→ rommel1:不足就不能繼續下單.... 01/25 09:52
要做是不難，但通常是來不及，不過無法一次成交的話，保證金不太夠時就趕快取消，
倒是可以減輕損失。
→ rommel1:最好也能在撮合速度上設限 禁止幾秒鐘上百口同時成交 01/25 09:53
所以說這是 policy 的問題，單筆本來就要有口數上限，上限計算公式要給出，
不然預設一定是漲停價計算，把原本的限制丟掉卻沒給替代公式，當然會出包。
至於成交口數限制，就不是券商這邊能處理的了。
推 creepy:苦主在用程式應該只有設保證金限制 沒有下口數限制 01/25 10:02
→ creepy:所以當初1000口就順利通過檢核 但是每次成交都應該要檢核 01/25 10:03
→ creepy:使用者的保證金帳戶才對 01/25 10:03
→ creepy:所以要保險的話 大家要把程式中的口數限制也設定好免遭不測 01/25 10:04
→ creepy:期交所只負責磋合 不管你保證金的 下單券商要負全責 01/25 10:06
推 arthurwang:這篇點到問題，推 01/25 10:06
推 creepy:不過低流動量的價位本來就會有穿價的問題 這程式應該早知道 01/25 10:08
這就是麻煩的地方，要讓使用者有最大的方便，其實是一個需要專業的事情，
要放開限制，要考慮很多事情，應該要做規劃研究，但台灣多以主管的判斷來替代。
這樣就會出現經驗上的誤差，券商顯然完全沒想過有人會這樣下單，
當然，正常人也想不到選擇權還有市價大單這種下法，但有研究過的話，
應該就可以發現這個問題，從而根據商品流量或其他方式做控管。
推 arthurwang:其實市價單這個名詞很容易讓人誤會 01/25 10:22
推 f5j:可以借轉op版嗎？謝謝。 01/25 10:23
是可以啦，只是我有一種其實沒講出什麼的感覺...
→ arthurwang:實際上市價單就是 漲/跌停單，但因為這會優先成交 01/25 10:23
→ arthurwang:所以成交價往往會是當時的市價 01/25 10:24
但就是有很多人不知道...
※ 編輯: semop 來自: 218.174.32.120 (01/25 10:30)
→ cyranoh:以前電話下單說要市價 營業員說不能講市價要講漲停價 01/25 10:39
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 211.74.99.239
推 vvanch:XD 01/25 10:50
噓 HarvardSu:使用者的口數明明就可以照下 只是系統要分次送出 01/25 10:57
→ HarvardSu:而分次送出就是你講的 "能下口數極少" 的計算方式 01/25 10:58
→ HarvardSu:連這樣邏輯也搞不清楚 難怪KGI這樣的台製系統會出包 01/25 10:58
推 semop:哪有這種事 如果有做基本控管 就不可能自動拆分連續下單 01/25 11:12
→ semop:程式如果爛到這樣還能拿到生意 而不是將限制改掉的 01/25 11:14
→ semop:那就真的是爛到底了 我不覺得台灣資訊業有爛成這樣 01/25 11:14
→ semop:至少我的經驗是程式寫好好的 卻被要求改來改去 改到不成樣 01/25 11:18
→ semop:現在我都不承認什麼東西是我寫的 根本和原始設計完全不同了 01/25 11:19