Please enable JavaScript.

Coggle requires JavaScript to display documents.

GTAS運行流程, GTAS 功能模組, SSFC團體票開票流程, 團票資料整合, SSFC, ARA, SSFC ARA mapping -…

- - - - PMD營業人員
        
        SSFC跟1A api request 開票成功
        
        SSFC產出SAT File
        
        SAT產出方式可能為daily
        
        有開票跟沒開票的都在一起(畫面有個開票成功)
        
        SAT 檔案格式傳輸方式
        
        於團票系統開票
        
        1A 產出 ARA
        
        ARA 目前DIH只做到 DEV環境而已尚未 prod
        
        DIH team 需確認GTAS所需欄位在判斷如何抓
        
        匯入GTAS系統
        
        SAT + ARA + GTAS票價本 = 章節六票價審查
        
        ARA 與票價本所算出的付款數據與 SAT 是否相符
        
        ARA那些欄位條件要match GTAS找出相符的票價本
        
        2 more items...
        
        SAT 以case 為單位
        
        1 more item...
        
        如何決定GTAS審查的排程時間
        
        ARA 傳file 到SFTP 頻率不定 (1小時 or 4小時..)
      - PNR會事先開好後續還有需多流程才會確定開票成功
- - - - 錯誤修正後需重跑期間票價審核過的案件
- - - - 影響往後提供給該家旅行社的座位數
    - - SSFC直接與1A串接自動化開票
- - - - DIH協助
        
        直接提供，我們所需要的欄位資料
        
        to DB?
        
        SFTP 讀檔資料落地
        
        篩選GTAS所需資料欄位
        
        要用parse的結果要去看一下他們DB table結構
      - 自行處理
        
        reload機制
        
        SFTP連線
        
        解壓縮
        
        parsing XML
        
        抓取要的欄位
    - - ARA抓取
        
        SAT API
        
        先落地於何處
- - - - 不同PNR
        
        相同ISSUE DATE
        
        一般狀況發生機率大，由於櫃台收到錢才會開票，所以旅行社都會盡量同一天開票，節省作業流程。
        
        對GTAS來說是會整併在同個Case
        
        不同ISSUE DATE
        
        發生機率小，開票發生異常狀況才會發生，但業務單位還是會儘量同一天開完。
        
        對GTAS來說會是不同CASE
      - 相同PNR
        
        不發生
      - 發生情境
        
        30人限制
        
        如單筆PNR團票人數大於30人，因應系統限制，分拆成另一筆PNR(每筆PNR不超過30人)
        
        加開
        
        一開始業務分配給旅行社固定人數後(該case有幾個人)，如旅行社反應生意太好人數不夠，業務加開的人數會是另一個PNR
  - - - 與同團另一個case 的PNR ISSUE DATE可能同天也可能不同天
        
        同團加開
        
        越到起飛日月容易發生同團加開
        
        對GTAS來說會是不同CASE (因為在SSFC就是不同Case了