今天接《商品系統整合總結》之后，整理了訂單系統整合時的一些心得。

之前已經說過，由于公司業務線的多樣性，訂單量的不斷增加，公司中的訂單系統之前只是一個訂單中轉站，所有的履單流程都是在公司之前的ERP系統中全部完成實現，但是由于ERP系統是好多年前的軟件，雖能夠滿足業務需要，但很多環節需要借助人為手動操作來處理訂單，效率低。故希望做一次訂單系統整合，能夠系統自動化，減少人為操作成本。

實施步驟

考慮到現有業務的正常運作，故訂單系統的整合主要分為以下幾步來實施

一?、先將ERP系統中開線下單的功能遷移出來（包括大客戶訂單和刷單的訂單攔截）

說明：線下單，也可理解為訂單的內部處理，主要有以下幾種情況

1. 公司為供貨商的角色，渠道產生訂單后，需要人員內部錄入系統后實施履單流程
2. 針對刷單的訂單做的特殊處理，這塊不做贅述
3. 針對大客戶訂單，合并開票發貨處理
4. 沖紅訂單開具線下單，是公司內部系統交互的問題，不做贅述

二、三方平臺/自營式B2C訂單流程整合（不包括O2O訂單）

說明：由于之前這兩部分訂單是不同的團隊在管理，流程上本身也是存在差異的，故規劃的過程中是計劃B2C整個流程順當后再考慮

整個訂單流程如下：

整體的流程不做過多講解，處方藥部分因為也就只有醫藥電商會存在這個情況，會做特殊處理，其他的和普通的電商基本上一致；故著重說明下異常訂單攔截，拆分訂單和派單這塊的邏輯

1. 異常訂單攔截

訂單攔截主要根據業務的實際場景攔截，當然這塊也主要分2種情況

1. 數據內容校驗（如必填字段為空，金額核對不準確，黑名單等）
2. 拆分訂單過程中攔截（如負毛訂單，超區訂單，無庫存訂單，拆單數量限制等）

2. 拆分訂單

一般會考慮從以下維度處理，當然具體的還是要看各自公司的實際情況

（1）拆單因素：商品屬性，渠道，庫房，庫存等將父單拆分成不同的子單。

（2）校驗：

• 子單商品數量，相關金額（平臺優惠，商家優惠，商品優惠，訂單金額，實付金額）與父單的一致性
• 拆分訂單數量是否符合業務需求（如：拆單數量限制，貨到付款訂單拆單限制等）
• 拆分后是否需要再次拆分，如果是，則子單為異常訂單，否則拆分完成，同時取消父單，生成子單；校驗不符合的，恢復原單

3. 派單

需要考慮的因素：發貨地與倉的距離，倉的優先級，快遞優先級，快遞報價優先級等；

關于派單，在具體的派單流程過程中也是需要根據公司業務的實際情況來制定規則完成派單。

三、代運營訂單提供訂單開放接口

1. 有對接接口能力的渠道，抓取訂單，發貨后需要將物流返回到訂單系統。
2. 無對接能力的渠道，提供查詢訂單的頁面，同時需要有導入物流單號的功能。其他的輔助功能，根據公司的實際情況來決定是否需要給渠道提供。

四、O2O訂單與B2C訂單整合

后期這塊是另外一個同事負責，整合的過程中是在拆分訂單前做了一次O2O訂單條件判斷，優先門店來進行接單發貨，不滿足，倉庫再進行發貨處理。當然這樣提升了用戶體驗，當然也需要考慮三方平臺訂單物流回寫的問題，因為O2O訂單是不需要物流單號的，而B2C的訂單需要。這塊是另外一個項目組負責，這塊不做過多陳述。

在流程整理的過程中，由于剛開始是根據自己之前的習慣來畫的流程圖，第一次和負責研發的小組長評審時，大家給了一些建議，最終修改了2版整個項目組才達成共識；評審時使用最終版來和所有的人員進行需求評審，過程還算順利。在這里很感謝研發同事對我工作上的支持和幫助。

作者：簡之箐，微信公眾號：sunshinegirl，5年互聯網產品經理，曾擔任醫藥產品經理和電商產品經理，經歷主導過電商平臺的系統整合規劃。

本文由 @簡之箐 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖來自PEXELS，基于CC0協議i