起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識OMS：零售電商系統的核心
本文講述了OMS概念以及相關服務和功能（包括：信息下發、信息上傳、 訂單分發協同單號生成與拉、拆單發票服務、狀態更新與模板、流水、庫存），與大家分享！
OMS即：訂單管理中心，是零售電商系統的核心。
隨著中臺概念的火熱，很多電商公司都開始投入資源開始搭建各種中臺系統。
幾天前和朋友交流，他們公司成立一個新的中臺項目，項目上線后會取代現在的OMS及一些相關系統。
本人前公司似乎也在風風火火的搞中臺，但中臺是什么?搭建完成后解決了什么問題?能帶來多少效益?上了中臺是否真的能快速響應業務需求呢？
由于對中臺了解的不多，現在也回答不了，這些只能慢慢去學習，所以也只能聊聊我對基礎的一些系統、模塊的理解。
之前總結過拆單、訂單狀態、退換貨等，這些都似乎都可以歸屬于OMS,本篇接著說下我理解的OMS。
一、OMS與中臺
1. OMS
OMS主要是承接各種業務單據「入庫與出庫」快速的與上下游系統進行信息的傳遞與處理，訂單是其最核心的數據，也是數量最大、效率要求最高的部分。
在上圖中，第一層屬于內部相關系統，如商品系統、采購管理、前端購物流程產生的銷售訂單、售后發起的退貨訂單、以及領用等業務單據——這個我們可以稱之為「上游系統」或ERP；當然OMS也應屬于ERP系統的一部分。
OMS主要是針對訂單的處理，履單包括上游系統的快速流轉；但真正的生產應該是倉儲內作業。所以OMS是與WMS系統交互最為緊密，與WMS系統的信息傳遞是通過倉儲系統的API接口完成的，API接口與WMS可以稱之為「下游系統」。
OMS就是一個中間系統服務的組成，在橫向上，它又會與財務進銷存系統進行數據的傳遞，所以它是被很多系統包圍中中間的，稱其為訂單中心確實不為過。
2. 中臺
上圖是我在網上看到的一家做OMS產品的系統架構介紹，這里的訂單中心屬于業務中臺。
上圖是根據一位朋友發給我的中臺規劃，做了些簡化；訂單管理也是業務中臺的一部分。
二、相關服務與功能
1. 信息下發
商品信息
OMS不僅負責銷售訂單的下發與上傳，也包括采購訂單及返廠單數據的傳輸，同時包括基礎的商品信息。
商品收貨是WMS的初始工作，收貨入庫后才能產生商品庫存。
WMS在使用前首先要進行數據初始化，即：商品信息、品類和供應商等基礎信息，同時要進行庫存初始化，此外需要在WMS系統中進行庫區、貨位等信息創建與維護。
如果庫內需要根據原材料進行加工生產，則需要在商品系統中進行配置，如父子商品配置、加工品原料配置，這些都會以BOM單方式提前下發到WMS系統中。
供應商信息
供應商信息是在供應商管理模塊進行創建，它包括供應商ID、編號、名稱及狀態，WMS收貨時是要獲取此部分信息，進行數據校驗。
此外，在上下游系統中都有供應商庫存，且要進行供應商商品成本的計算與統計。
在WMS系統中有商品批次數據，批次編碼可以根據相關規則進行創建，以保證一品多商時可以進行商品的區分。
單據
這里的單據是指業務創建采購單、返廠單，也包括用戶的銷售訂單、退換貨訂單。
采購單、返廠單在SCM系統中創建完成后需要通過OMS同步到倉庫，以便供應商到貨后WMS系統中可以根據已經采集的采購單進行數據驗證與統計；同時在此前供應商預約送貨申請時也能夠進行收貨安排。
銷售訂單經過支付、拆單后要下發到WMS，倉庫接收后可以開始處理，揀貨、打包、發貨單。
單據的下發一般分為頭和行數據，商品數據則根據下發的單據信息，在WMS系統中根據BOM進行驗證處理。
這些都是通過API接口完成的，我們原來的系統每次的數據下發與上傳都會保存報文信息，以便出現問題進行查看、分析并解決。
所以在OMS系統與WMS等系統進行數據同步時，接口下發或回傳的XML信息一定要保存完整。
2. 信息上傳
來而不往非禮也，數據有去就應該有回。
這里的OMS系統中信息上傳是指接收WMS系統回傳的數據和相關狀態，同時在接收完數據和狀態后OMS還會進行一些業務處理。
以采購單為例，當倉庫完成入庫后，會將實際的入庫數量回傳；此時OMS系統需要根據回傳數據進行入庫單的生成，并更新上游系統的庫存；同時還要進行成本的計算及入庫流水的生成，由于數據流轉到一個節點需要計算，系統一般都是通過MQ來實現異步處理的。
同信息下發一樣，回傳的信息明細需要保留，有些還需要進行解析并保存在關系數據庫中，便于統計查詢、展示。
3. 訂單分發協同
在信息下發與上傳時都會應用到規則與策略。
隨著業務的爆發，單量增長也非?？?，所以OMS系統中還應該進行一些規則配置，以便數據快速流轉，加快系統的響應速度，給用戶更好的體現。
同時有很多狀態有些是倉儲內部的，有些是業務系統的，在訂單處理時要進行一些設置，需要有選擇的屏蔽和轉換。
4. 單號生成與拉、拆單
這幾個服務大家都比較熟悉，單號生成品就是依賴于定義好的規則生成不能重復的單號，提供給前端購物流程或后臺業務系統調用。
同時，單號的規則也會與分庫分表服務相關聯，所以單號的規則非常重要，它必須滿足單量的爆發增長，不能重復，可以通過單號進行不同維度的訂單數據保存與查詢。
拉單就將前端用戶產生的單據拉取到后端生產庫，這是銷售訂單數據的來源，拆單可以查看以前總結的《OMS|訂單拆單》,這里不重復描述了。
5. 發票服務
現在紙質發票越來越少了，電子發票的開票信息不需要同步到WMS系統了，但是開票金額的計算必不可少，且需要同步到電子發票稅務平臺。
對于售后的一些補開、退換貨涉及的重開等也需要經過發票服務進行計算——這些雖然與財務關聯很大，但是與OMS系統密不可分，所以應該是OMS的一部分。
6. 狀態更新與模板
訂單狀態是根據履單的流程不斷變化的，有在上游系統的變化，有在WMS系統內的更新。訂單的全程跟蹤便是根據狀態的流轉進行的統計與分析，業務部分會根據訂單的生命周期來進行改進。狀態變更時不僅涉及其他業務流程的邏輯處理，同時也需要進行消息通知，如短信、郵件或微信。
在零售電商系統的基礎服務層中會有對應的網關與SP進行對接，但是與用戶的交互要注意文案與格式，所以模板配置需要提前設置好，以便OMS進行調用。
只要與用戶有關，那么就要注重用戶體驗，不能漏發或多發，也不能亂發，要設置好相關的規則。
7. 流水
我在這里將出入庫流水劃分在OMS系統中，因為接收所有的倉儲作業數據，只要有出入庫那么就涉及到庫存的增或減；但是在WMS提供的API接口或返回的數據中可能不會區分單據類型，需要上游系統進行重新處理。這個幾年前在與LSCM「倉儲對接平臺」進行庫存核對時就需要到這樣的問題。
WMS雖然有單據類型，但是經過LSCM后就只有出與入兩種大類型，具體的信息都需要根據XML報文解析后，由上游系統進行重新處理。
流水也是SCM與財務系統交互的基礎，財務根據出入庫流程、庫存進行財務成本的計算、相關報表生成等。
所以如果你在負責OMS，需要注意這一塊，WMS有些是以調整單方式進行的，單據需要上游進行生成。
8. 庫存
在零售電商系統中庫存一般分為三部分，內部ERP、WMS和財務。其間關系以前曾說過，先有WMS，ERP根據出入庫單據由OMS進行增或減，財務則根據OMS的出入庫流水進行再次計算生成。
所以對賬是必須的，WMS和ERP是實時作業的，庫存是實時變化的，會有時間性的差異，財務是根據流水生成的可以有準確的期末庫存。
接觸過幾個WMS系統都是通過快照方式備份期末庫存的，這個如果WMS系統中沒有，需要進行開發，只要有一筆筆的數據就能夠推算出期末庫存。
但是當SKU數量和單據量非常非常大時，計算就需要時間，在系統設計上就要進行分倉、分品類等進行分布式計算，當然我這里只是提出；在實際生產系統中最多遇到過一天幾十萬單，幾十萬個SKU的場景，與京東等平臺這種設計肯定滿足不了，有興趣的同學可以去考慮，可以私信交流。
三、總結
OMS名詞我們都知道，但是在不同的公司OMS的功能不同，涵蓋的業務也不同；只要根據業務較為合理的進行規劃，滿足業務的變化就行了，至于它是不是訂單中臺不必過多計較了。
業務驅動技術發展，在設計時要應用領域模型，這是最近看書了解到的，業務、技術、數據、領域，究竟該如何去做，需要不斷的去參照成功企業的應用案例結合實際場景去實踐。
有朋友說我寫的東西不裝X，其實是想寫高大上的，但是文采和儲備有限，只能寫點基礎的自娛自樂，找點事干。
最后，感謝您的閱讀！
作者：倔強的大蘿卜；公眾號：倔強的大蘿卜
本文由 @倔強的大蘿卜 原創發布于人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基于CC0協議
書已買，支持作者
PS 學財務，過一遍中級財務會計（實操和邏輯）‘東北財經版可用’ +會計原理（思想）就夠了，悟性好點的2個月就通了。
非常感謝！
挺接地氣的，看得出作者是在一個具體領域持續深入學習和總結的，感謝分享。
好一個領域設計模型，最后業務、技術設計、產品設計都是要合一的，設計思想共通，職能分而不散。
多多交流：）
每天的出庫量是根據 快照方式備份期的末庫存-期初庫存-入庫量，還是直接匯總每筆銷售單的出庫數量來計算。哪種方式會好一些呢？
第二種好，也最準確
謝謝您的認可，感謝關注！
你好，能否推薦供應鏈和財務相關的書籍或學習資料，謝謝
供應鏈的書籍可以看看 劉寶紅 老師幾本書，財務的 《財務會計簡易入門》和《會計學》，個人覺得不錯
好的，下班買起來
微信讀書中有電子書可以讀：）
看書的話，還是喜歡看紙質版的書