貨運追蹤最累的一段,是貨況分散在不同航空公司、船公司與貨代系統裡,客戶一問就得逐家去查、再一封封回報。我們為物流貨運業者打造的這套系統,把空運提單(AWB)與海運提單(SWB)收進同一個平台管理,並串接第三方追蹤服務:貨件一建立就自動註冊追蹤,對方貨況一有更新,就透過 webhook 即時回傳、自動寫進系統,海運還能追到每一個貨櫃的事件。狀態變動時,系統依提單型態(空運或海運、進口或出口)自動套用對應的郵件範本通知客戶。也就是說,「我的貨到哪了」不再需要人工一家一家查、一封一封回,貨況會自己更新、也會自己通知。
空運提單(AWB)與海運提單(SWB)都提供進口、出口的列表與詳情,列表支援伺服器端分頁、排序與欄位搜尋,詳情頁以時間軸呈現完整追蹤歷程。也就是說,空運海運不必分兩套系統,貨代在同一個平台就能管所有提單、查所有貨況。
海運一張提單可關聯多個貨櫃,每個貨櫃有各自的追蹤事件、位置、船隻與航線紀錄;空運則細到每個航段的航班與計畫、實際時間。換句話說,追蹤不只是「一票貨到哪」,而是細到哪個櫃、哪一段,遇到客訴或延誤時查得到根因。
貨件建立或更新時自動註冊到第三方追蹤平台,對方貨況一有變化就透過 webhook 即時回傳,系統自動判斷是空運還是海運並更新資料。也就是說,貨況不靠人工逐家查詢,而是由來源端主動推、系統自動收,資料既新鮮又不漏。
貨件狀態變動時,系統依「空運或海運、進口或出口」自動挑對應的郵件範本,用佔位符把貨件實際欄位帶進信件,自動寄給相關收件人。結果就是,通知客戶這件重複又瑣碎的事交給系統做,內容還能依每票貨客製,不必人工一封封改。
每個角色能存取的功能以資料方式儲存,管理員在後台就能指派,不必改程式、重新部署。也就是說,組織調整或新增角色時,權限在後台點一點就生效,系統不必為了權限異動而停機改版。
介面支援繁中、簡中、英文即時切換,並提供機場、港口代碼(UN/LOCODE)搜尋;系統啟動時自動匯入國家碼與港口機場碼。這麼一來,跨國團隊各自用慣用語言操作,填提單時港口機場代碼有標準清單可選,減少填錯的機會。
系統以 ASP.NET Core 6 MVC 打造,採 Repository 與 Unit of Work 架構,串接第三方追蹤服務並提供 RESTful API。要讓貨況又即時又對得上,重點落在下面三件事。
貨件註冊到第三方之後,貨況更新是由對方主動 webhook 回調,系統即時解析並寫進資料庫,而不是自己每隔幾分鐘去問一次。也就是說,貨況更新既即時又省資源,不會因為輪詢頻率太疏而漏掉或延遲。
所有時間戳統一以 UTC 儲存,透過工具在顯示層才轉成台北時間,物件對應時就內建這層轉換。換句話說,跨時區的貨況時間不會因為誰的伺服器在哪而對不上,顯示給誰都是正確的當地時間。
郵件範本以 [欄位名] 佔位符撰寫,寄送時自動把貨件實際欄位值填進去,範本依語言與提單型態分開維護。也就是說,要改通知內容或加一種語言,改的是後台範本而不是程式碼,客服或行銷自己就能維護。
有幾件原本得靠人工的事,現在都由系統自動完成:貨件一建立就自動註冊追蹤;貨況由第三方 webhook 主動推送、自動更新;狀態變動自動套範本、自動寄信通知客戶;日誌與例外由監控面板自動收集、定期清理。對業者來說,等於把「盯貨況、回報客戶」這件每天重複幾百次的事,交給系統自動接續完成。
取決於功能範圍。若包含空運與海運提單管理、第三方追蹤整合與自動通知,屬於中大型系統專案;影響報價的主因是要串接的追蹤來源數量、通知與報表的複雜度,以及權限與多語系需求。建議先列出必要功能,我們可以依範圍提供分階段的報價方案。
常見時程約 4 到 8 個月:需求釐清與流程設計約 1–2 個月,提單管理、第三方整合與通知開發、測試約 3–5 個月,最後是上線輔導。若分階段上線(先做提單管理與追蹤、再上自動通知與報表),第一個版本可以更快上線試用。
可以。系統以 webhook 與 API 方式串接第三方追蹤服務,貨件建立後自動註冊追蹤,對方貨況更新時透過 webhook 即時回傳並自動更新;若有多個追蹤來源,也能分別整合,讓不同來源的貨況集中在同一個平台呈現。
貨況由第三方追蹤來源主動 webhook 回調更新,屬於即時同步而非定時輪詢。狀態變動時,系統會依提單型態自動套用對應的郵件範本、帶入貨件資料,自動寄信通知相關收件人,不需人工逐一回報。
可以。介面支援繁中、簡中、英文即時切換;所有時間統一以 UTC 儲存、在顯示時才轉換為當地時間,因此跨時區的團隊看到的貨況時間都一致且正確,適合跨國的貨運協作。