close
最近有機會接觸到規劃下一代電子發票的人，發現目前架構很可能導致未來繳稅的人還要另外負擔手續費給中介廠商，而原因來自於主辦端擔心政府無法負荷那麼大的流量。
經過瞭解架構後，發現流量問題多半來自過時的架構規劃，只要改採時下流行的規劃方式，搭配經濟部砸四百億力推的雲端服務，其實流量跟平台效能並不是不能解決的問題。
可惜目前執行者礙於既有資源跟錯誤的假設，導致最後得要仰賴民間中介商去平衡流量，而這種做法下，民間中介商擔負的成本，當然會跟使用者收費，問題是，哪個業者會想要為了繳稅還要額外負擔手續費？（何況這是完全可以避免的）
政府希望透過新的電子發票機制發行，一方面減少紙張跟人事成本，一方面透過降低複雜度來擴大稅收對象，立意尚稱良善，但是眼前的架構不用推也知道在擴大稅收方面業者的配合度肯定沒辦法太好。
本來我想這跟我這種小咖也沒啥關係，不過這兩年來，一天到晚在對抱怨政府規劃做得不好的文章按讚，如今有機會參與，反而不積極有所作為，那怎麼說得過去？
執行上的資訊：
- 負責規劃的人有心改善架構問題，但礙於角色，舊架構是否改變要看政府原委託廠商的意願。
- 雖同屬經濟部的體制下，但可能礙於執行單位不同，以至於明明政府就有發展雲端服務的資金跟計劃，這個電子發票服務看上去卻完全無法沾上邊。但實際上，雲端虛擬化技術在解決網路服務負載問題上，是個相當實際的方案。
技術上的資訊：
- 目前的同步方式是累積資料後寫檔->批次壓縮->sFTP上傳->排程解壓縮->寫資料庫並搬檔案。可預期該架構需要系統不斷地檢查，資料同步上也會有時間差，因此需要複雜的檢查機制才能確保資訊正確。
- 改採新規劃架構變成 API 批次上傳->伺服端直接寫資料庫管理。資料傳輸完成後，資訊就是正確的了，不需要太多檢查機制。
我的小目標：
- 避免繳稅的人需要額外負擔手續費，即使需要透過民營加值中心，也希望加值中心的獲利是直接從稅收中抽取。
- 主導者的理想我很認同，就是提供Protocol給大家跟進，而不是綁Tunkey程式，有機會的話我會積極去找尋雲端資源來解決原服務商對流量的顧慮。
- 在不擋到任何人財路的前提下改善機制：繳稅的業者只需要繳稅，民營單位協助政府收稅可從中獲利，政府透過門檻降低來增加稅收及對過內交易狀況的掌握，避免不必要的架構跟硬體成本來增加國庫在硬體方面的支出。（想想不犯法啦...）
特別說明：
其實參與其中的每一個人，跟我們想象的不同，都是認真且具備專業實力的廠商，且分別都非常努力，也非常謹慎，但同時也害怕落人口舌。他們需要業界的幫助，但又害怕被指為官商勾結或圖利某單位等，但相對的，有非常想要有所作為。因此，他們算是壓力大又資源有限，想請各界幫忙但又沒有預算。
當然我個人能力也有限，不過只要有機會，就試試看吧...
全站熱搜
留言列表
