店舖系統開發課
店舖課處在配信與集信中間，在各部門與廠商間擔任橋樑，處理需求時需注意實際可行度，並需要考慮各專案的排程，懂得先後的順序。
在專案測試時考慮GPRC機能、異常情況時是否需設計TimeOut或Resnd等機制，以及思考店舖端可能會遇到的狀況來預防發生問題的可能性。
此外若店舖有帳務或交易上的糾紛時，也負責幫忙調查店舖端手順或系統判定等問題。
實習工作內容：
工作內容
主要是幫助新機能測試。需先列出測試的案例，除了正常案例以外也需列出異常案例，例如，當設備網路斷線時系統如何處理...等，測試新機能是否正常外也注意現有機能所發生的問題是否解決。
在測試機能時我們多使用TESTXML模擬與廠商間的通訊，除了查看TM是否正常運作，也要確認SAL以及DB的資料是否正確存入，若是含有通訊機能，更需確認離線機制是否正常。當遇到問題時可透過LOG做初步的判斷問題的原因，確認是機能有誤還是環境設定錯誤等問題。
SAL (電文)：
SC和TM間的交易明細，紀錄從TM登錄的那刻到日結帳時的所有交易，以3001~3099作為一筆交易起訖，每個功能用3xxx來代表，再於每條3xxx電文中記錄與此功能相關的交易資訊細項。
在SC可用於帳務計算、分析、單品庫存；在TM可用於帳務核算、紀錄明細、上傳給SC分析、退貨。
當TM進行日結帳後SAL也會打包儲存到歷史區。
LOG(交易歷程)：
每個LOG紀錄的細項皆不相同，有主要記錄TM每一步操作歷程、通訊或是資料的處理流向；會員點數查詢及兌換；電文解譯看存入哪些DB…等各種用途的LOG，當店舖端遇到問題時可以供工程師檢查歷程並排除錯誤。
TESTXML(假電文)：
在測試時會碰到需要模擬購票、取貨或是會員點數增加減少的情景，此時可以透過TESTXML模擬FamiPort與總公司或廠商通訊後回傳的資料。會員資料、手機支付條碼、取退票券、中獎發票…等皆有各自的模擬電文。可以說是測試時我們最常使用也最需要會的工具