電子訂單系統 (Eos)
甚麼是電子訂單系統（EOS）？
電子訂單系統（EOS）是一種以電腦為基礎的系統，用於建立、接收、記錄及傳送商品或服務訂單。在零售、電子商務及供應鏈營運中，它透過以電子方式擷取訂單資料，並讓負責處理訂單的各方或應用程式取得相關資料，從而取代或補充紙本表格、電話訂單及手動重新輸入。
這個術語亦可寫作電子訂購系統。其範圍取決於業務背景：它可以指零售商的補貨應用程式、供應商訂購入口網站，或較大型業務平台中的訂單輸入功能。單憑這個名稱，並不能確定一組固定的功能。EOS可以連接庫存、付款、倉庫及運輸系統，但不應假定它必然具備這些連接。
在電子商務及供應鏈中的角色
EOS運作於採購需求轉化為結構化業務指令的環節。消費者可以透過網上結帳提交訂單，而零售採購員則可以透過供應商入口網站訂購補充庫存。在任何一種情況下，系統都會記錄所需商品、數量、訂購者，以及適用的交付及商業條件。
電子訂單並不是實體貨件，而是可啟動後續活動的資訊，包括供應情況檢查、訂單接納、庫存分配、揀貨、包裝及發貨。這些活動可以在同一個應用程式中進行，也可以由不同的已連接系統分別處理。
電子訂購亦不一定代表使用網站。訂單可以透過內部採購畫面輸入、從檔案上載、透過應用程式介面（API）交換，或使用電子數據交換（EDI）傳送。UN/EDIFACT及GS1 EDI等標準為交換業務訊息提供結構，但它們並不是完整的訂購應用程式。
電子訂單系統如何運作
以下流程是示例工作流程，而不是強制性的技術規格。檢查的次序及深度取決於交易、商業協議及系統設計。
- 擷取要求。買方或其他應用程式提供產品識別碼、數量、買方資料及交付要求。系統會建立一項可在處理期間參考的記錄。
- 驗證資料。系統可以檢查必填欄位、已識別的產品代碼、允許的數量、地址格式及帳戶權限。驗證確認資料符合既定規則，但不一定確認賣方能夠履行要求。
- 檢查商業及庫存條件。在有已連接資料可用的情況下，應用程式可以檢查價格、議定條款、庫存供應情況、付款狀態或信用批核。有些檢查可能需要人工審核。
- 傳送或路由訂單。要求會傳送給供應商或相關內部應用程式。接收系統可以將傳入訊息轉換為自己的記錄格式。
- 記錄回應。賣方可以接納、拒絕訂單，或提出修改。技術接收確認訊息已抵達；不應自動將其理解為商業接納。
- 將已接納資料傳送至履行流程。已接納的訂單項目可以成為分配、倉庫放行或供應商履行流程的輸入。一張訂單可以產生多個貨件，而部分項目可能仍未履行。
- 維持後續變更。修訂、取消、延期交貨及履行更新必須與正確的訂單及項目保持關聯。是否支援這些操作取決於具體實施方式。
一項關鍵控制是區分提交、接收、接納及履行。將這些概念視為可互換，可能導致誤導客戶的訊息或營運錯誤。訂單出現在畫面上，本身並不能證明庫存已被預留，或承運商已收到包裹。
訂單記錄可能包含的資料
所需欄位會因交易而異。以下各組資料說明實際訂單處理所需的資訊，而不是定義通用的EOS資料標準。
| 資料組別 | 欄位示例 | 營運用途 |
|---|---|---|
| 訂單識別 | 訂單參考編號、建立日期、買方參考編號 | 區分交易並支援對帳。 |
| 交易各方 | 買方、賣方、帳單方、交付收件人 | 識別所涉及的組織或人士。 |
| 訂單項目 | 產品識別碼、數量、計量單位 | 指定所要求的商品及數量。 |
| 商業資料 | 貨幣、議定價格、付款條款 | 記錄要求的商業基礎。 |
| 交付要求 | 收貨地址、要求交付日期、服務指示 | 提供規劃履行流程的指示。 |
| 處理參考資料 | 接納狀態、修訂參考編號、相關貨件參考編號 | 將訂單與後續操作及記錄連結。 |
一致的識別碼與欄位的存在同樣重要。例如，如果一個應用程式將其理解為十個單件，而另一個應用程式將其理解為十箱，那麼數量十便存在歧義。因此，產品識別碼、計量單位、地址記錄及貨幣代碼需要由已連接系統共同議定其解釋方式。
相關系統及技術術語
電子訂購與多項業務功能有所重疊。以下區分說明的是各自的重點，而不是軟件產品之間的嚴格界線。單一平台可以執行其中多項功能。
| 術語 | 主要重點 | 與EOS的關係 |
|---|---|---|
| 訂單管理系統（OMS） | 管理訂單的接納、分配、履行及例外情況。 | EOS可以提供訂單輸入，而OMS則協調更廣泛的訂單生命週期。 |
| 電子數據交換（EDI） | 在系統之間交換結構化業務訊息。 | EDI可以承載採購訂單及相關文件；它本身並不是完整的訂購流程。 |
| 企業資源規劃（ERP） | 連接採購、庫存及會計等業務記錄和流程。 | 電子訂購可以是ERP的一項功能，也可以是與ERP連接的外部應用程式。 |
| 倉庫管理系統（WMS） | 控制倉庫活動及庫存流動。 | WMS可以接收由已接納訂單衍生的履行指示。 |
| 採購訂單 | 列明買方所要求採購內容的業務文件。 | 採購訂單是EOS可以建立或傳送的文件，而不是系統本身。 |
API及EDI不一定是處於同一層級的替代方案。API描述程式化介面，而EDI涉及結構化業務文件交換。整合方案可以使用API傳送EDI格式的文件。實際需要考慮的問題是交換哪些資料、如何保留其含義，以及如何處理回應及錯誤。
在跨境電子商務中的使用
跨境訂購增加了資料及協調要求，但不會改變EOS的基本目的。賣方需要在安排國際履行前取得可用的訂單資料。相關詳情可能包括目的地國家、收件人資料、交易貨幣、產品描述及交付指示。
並非所有與海關相關的欄位都需要由買方輸入。有些資料可能來自產品主檔資料或後續運輸流程。然而，在準備貨件文件前，缺少或不準確的產品描述、價值或原產地資料可能需要更正。
電子訂單並不是海關申報。訂單資料可以用於商業發票或申報，但可能需要額外資料及檢查。世界海關組織資料模型處理跨境監管資料要求的協調；不應將其視為電子商務訂單輸入的通用規格。
例如，零售商可能收到一張包含兩種產品的海外訂單。其中一種產品可能可立即供應，而另一種則需要補貨。訂單系統會記錄客戶要求，但下游流程必須決定是暫停訂單，還是建立多個貨件。任何貨件參考資料都應與相關訂單項目保持連結，以免將部分履行誤認為整張訂單已完成。
營運控制及限制
當資料在系統之間傳遞而無需重新輸入時，以電子方式擷取資料可以減少重複的手動輸入。但這並不保證庫存準確、價格正確、交付成功或履行流程沒有錯誤。不正確的來源資料與正確資料一樣，都可以順利通過自動化流程。
評估EOS或調查整合方案時，可進行以下檢查：
- 重複處理：接收流程能否識別重複提交，而不建立非預期的第二張訂單？
- 狀態含義：技術接收、商業接納、付款確認及發貨是否有清晰區分？
- 資料映射：產品代碼、計量單位、貨幣及地址欄位在不同應用程式之間是否保留其含義？
- 例外處理：被拒訊息、無法供應的商品及無效欄位，是否對負責解決問題的人員清晰可見？
- 變更控制：使用者能否識別目前的訂單版本，並確定取消要求是否在倉庫處理前抵達？
- 存取及可追溯性：企業能否確定誰提交或修改了訂單，並將敏感操作限制於獲授權使用者？
這些是評估問題，而不是EOS這個術語所保證具備的功能。其重要性取決於業務流程、交易量及錯誤訂單所造成的後果。
常見問題
EOS在電子商務中代表甚麼？
在此語境下，EOS代表電子訂單系統或電子訂購系統，即用於以電子方式擷取及傳送訂單的軟件。其確切範圍應根據出現該術語的文件加以確認。
EOS是否等同於訂單管理系統？
不一定。電子訂購着重於輸入及傳送訂單。訂單管理可以延伸至分配、履行、變更及例外情況。單一應用程式可以同時提供這兩類功能。
電子訂單是否確認貨品已發貨？
不是。提交及接納與發貨是不同的環節。發貨確認需要來自履行或運輸流程的資料，而不只是存在訂單記錄。
EOS是否需要EDI？
不需要。EOS可以使用入口網站、API、檔案交換、EDI或這些方式的組合。EDI在實施的情況下，會提供結構化訊息交換。
來源
- 聯合國歐洲經濟委員會：介紹UN/EDIFACT — 支持對標準化電子業務資料交換的說明，而不是將EOS定義為特定軟件類別。
- GS1：電子數據交換 — 支持標準化業務訊息在訂購、交付及相關交易流程中的角色。
- 世界海關組織：WCO資料模型 — 支持區分商業訂單資料與跨境監管程序的協調資料要求。
