乌克兰av片_99在线看_日韩三级在线播放_av片日韩_嫩草亚洲_深夜福利视频一区二区

導語

OMS即訂單管理中心，是零售電商系統的核心，隨著中臺概念的火熱，很多電商公司都開始投入資源開始搭建各種中臺系統，幾天前和朋友交流，他們公司成立一個新的中臺項目，項目上線后會取代現在的OMS及一些相關系統。本人前公司似乎也在風風火火的搞中臺，但中臺是什么?搭建完成后解決了什么問題?能帶來多少效益?上了中臺是否真的能快速響應業務需求呢？由于對中臺了解的不多，現在也回答不了，這些只能慢慢去學習，所以也只能聊聊我對基礎的一些系統、模塊的理解，之前總結過拆單、訂單狀態、退換貨等，這些都似乎都可以歸屬于OMS,本篇接著說下我理解的OMS。

OMS與中臺

上圖是我在網上找一家做OMS產品的系統介紹，這里的訂單中心屬于業務中臺。上圖是根據一位朋友發給我的中臺規劃，做了些簡化；訂單管理也是業務中臺的一部分。

OMS

這個圖是根據本人了解的內容簡單畫的一個圖，OMS主要是承接各種業務單據「入庫與出庫」快速的與上下游系統進行信息的傳遞與處理，訂單是其最核心的數據，也是數量最大、效率要求最高的部分。在上圖中，第一層屬于內部相關系統，如商品系統、采購管理、前端購物流程產生的銷售訂單、售后發起的退貨訂單、以及領用等業務單據，這個我們可以稱之為「上游系統」或ERP,當然OMS也應屬于ERP系統的一部分。OMS主要是針對訂單的處理，履單包括上游系統的快速流轉，但真正的生產應該是倉儲內作業，所以OMS是與WMS系統交互最為緊密，與WMS系統的信息傳遞是通過倉儲系統的API接口完成的，API接口與WMS可以稱之為「下游系統」。OMS就是一個中間系統服務的組成，在橫向上，它又會與財務進銷存系統進行數據的傳遞，所以它是被很多系統包圍中中間的，稱其為訂單中心確實不為過。

相關服務與功能

信息下發

商品信息OMS不僅負責銷售訂單的下發與上傳，也包括采購訂單及返廠單數據的傳輸，同時包括基礎的商品信息。在上一篇介紹WMS收貨與入庫流程時提到過，商品收貨是WMS的初始工作，收貨入庫后才能產生商品庫存。WMS在使用前首先要進行數據初始化，即商品信息、品類和供應商等基礎信息，同時要進行庫存初始化，此外需要在WMS系統中進行庫區、貨位等信息創建與維護。如果庫內需要根據原材料進行加工生產，則需要在商品系統中進行配置，如父子商品配置、加工品原料配置，這些都會以BOM單方式提前下發到WMS系統中。供應商信息供應商信息是在供應商管理模塊進行創建，它包括供應商ID、編號、名稱及狀態，WMS收貨時是要獲取此部分信息，進行數據校驗，此外，在上下游系統中都有供應商庫存，且要進行供應商商品成本的計算與統計。在WMS系統中有商品批次數據，批次編碼可以根據相關規則進行創建，以保證一品多商時可以進行商品的區分。單據這里的單據是指業務創建采購單、返廠單，也包括用戶的銷售訂單、退換貨訂單。采購單、返廠單在SCM系統中創建完成后需要通過OMS同步到倉庫，以便供應商到貨后WMS系統中可以根據已經采集的采購單進行數據驗證與統計，同時在此前供應商預約送貨申請時也能夠進行收貨安排。銷售訂單經過支付、拆單后要下發到WMS，倉庫接收后可以開始處理，揀貨、打包、發貨單。單據的下發一般分為頭和行數據，商品數據則根據下發的單據信息，在WMS系統中根據BOM進行驗證處理。這些都是通過API接口完成的，我們原來的系統每次的數據下發與上傳都會保存報文信息，以便出現問題進行查看、分析并解決。所以在OMS系統與WMS等系統進行數據同步時，接口下發或回傳的XML信息一定要保存完整。

信息上傳

來而不往非禮也，數據有去就應該有回，這里的OMS系統中信息上傳是指接收WMS系統回傳的數據和相關狀態，同時在接收完數據和狀態后OMS還會進行一些業務處理。以采購單為例，當倉庫完成入庫后，會將實際的入庫數量回傳，此時OMS系統需要根據回傳數據進行入庫單的生成，并更新上游系統的庫存，同時還要進行成本的計算及入庫流水的生成，由于數據流轉到一個節點需要計算，系統一般都是通過MQ來實現異步處理的。同信息下發一樣，回傳的信息明細需要保留，有些還需要進行解析并保存在關系數據庫中，便于統計查詢、展示。

訂單分發協同

在信息下發與上傳時都會應用到規則與策略，隨著業務的爆發，單量增長也非常快，所以OMS系統中還應該進行一些規則配置，以便數據快速流轉，加快系統的響應速度，給用戶更好的體現。同時有很多狀態有些是倉儲內部的，有些是業務系統的，在訂單處理時要進行一些設置，需要有選擇的屏蔽和轉換。

單號生成與拉、拆單

這幾個服務大家都比較熟悉，單號生成品就是依賴于定義好的規則生成不能重復的單號，提供給前端購物流程或后臺業務系統調用。同時，單號的規則也會與分庫分表服務相關聯，所以單號的規則非常重要，它必須滿足單量的爆發增長，不能重復，可以通過單號進行不同維度的訂單數據保存與查詢。拉單就將前端用戶產生的單據拉取到后端生產庫，這是銷售訂單數據的來源，拆單可以查看以前總結的《OMS|訂單拆單》,這里不重復描述了。

發票服務

現在紙質發票越來越少了，電子發票的開票信息不需要同步到WMS系統了，但是開票金額的計算必不可少，且需要同步到電子發票稅務平臺。對于售后的一些補開、退換貨涉及的重開等也需要經過發票服務進行計算，這些雖然與財務關聯很大，但是與OMS系統密不可分，所以應該是OMS的一部分。

狀態更新與模板

訂單狀態是根據履單的流程不斷變化的，有在上游系統的變化，有在WMS系統內的更新，訂單的全程跟蹤便是根據狀態的流轉進行的統計與分析，業務部分會根據訂單的生命周期來進行改進。狀態變更時不僅涉及其他業務流程的邏輯處理，同時也需要進行消息通知，如短信、郵件或微信。在零售電商系統的基礎服務層中會有對應的網關與SP進行對接，但是與用戶的交互要注意文案與格式，所以模板配置需要提前設置好，以便OMS進行調用。只要與用戶有關，那么就要注重用戶體驗，不能漏發或多發，也不能亂發，要設置好相關的規則。

流水

我在這里將出入庫流水劃分在OMS系統中，因為接收所有的倉儲作業數據，只要有出入庫那么就涉及到庫存的增或減。但是在WMS提供的API接口或返回的數據中可能不會區分單據類型，需要上游系統進行重新處理。這個幾年前在與LSCM「倉儲對接平臺」進行庫存核對時就需要到這樣的問題，WMS雖然有單據類型，但是經過LSCM后就只有出與入兩種大類型，具體的信息都需要根據XML報文解析后，由上游系統進行重新處理。流水也是SCM與財務系統交互的基礎，財務根據出入庫流程、庫存進行財務成本的計算、相關報表生成等。所以如果你在負責OMS，需要注意這一塊，WMS有些是以調整單方式進行的，單據需要上游進行生成。

庫存

在零售電商系統中庫存一般分為三部分，內部ERP、WMS和財務，其間關系以前曾說過，先有WMS，ERP根據出入庫單據由OMS進行增或減，財務則根據OMS的出入庫流水進行再次計算生成。所以對賬是必須的，WMS和ERP是實時作業的，庫存是實時變化的，會有時間性的差異，財務是根據流水生成的可以有準確的期末庫存。接觸過幾個WMS系統都是通過快照方式備份期末庫存的，這個如果WMS系統中沒有，需要進行開發，只要有一筆筆的數據就能夠推算出期末庫存。但是當SKU數量和單據量非常非常大時，計算就需要時間，在系統設計上就要進行分倉、分品類等進行分布式計算，當然我這里只是提出，在實際生產系統中最多遇到過一天幾十萬單，幾十萬個SKU的場景，與京東等平臺這種設計肯定滿足不了，有興趣的同學可以去考慮，可以私信交流。

總結

OMS名詞我們都知道，但是在不同的公司OMS的功能不同，涵蓋的業務也不同，只要根據業務較為合理的進行規劃，滿足業務的變化就行了，至于它是不是訂單中臺不必過多計較了。業務驅動技術發展，在設計時要應用領域模型，這是最近看書了解到的，業務、技術、數據、領域，究竟該如何去做，需要不斷的去參照成功企業的應用案例結合實際場景去實踐。