《系統(tǒng)需求規(guī)格說明書書》由會員分享，可在線閱讀，更多相關(guān)《系統(tǒng)需求規(guī)格說明書書（37頁珍藏版）》請在裝配圖網(wǎng)上搜索。

1、精選優(yōu)質(zhì)文檔-----傾情為你奉上 XXX系統(tǒng)或XXX項目 產(chǎn)品需求規(guī)格說明書 文件狀態(tài)： [√] 草稿 [ ] 正式發(fā)布 [ ] 正在修改 文件編號： SN_SR_001 當(dāng)前版本： V1.0 作 者： 完成日期： 2017-04-11  版本信息 版本 時間 狀態(tài) 更新人 簡要描述 審核人 審核時間 V1.0 V1.01 V1.2 V1.3 V1.4 注：

2、狀態(tài)可以為N-新建、A-增加、M-更改、 對方的所得稅 說明：版本信息必須更新，審核人和審核時間也必須審核后填寫，審核人要求部門經(jīng)理級別以上。否則開發(fā)測試可拒絕評審。審核業(yè)務(wù)功能是否有遺漏、業(yè)務(wù)流程是否符合規(guī)劃、關(guān)鍵業(yè)務(wù)邏輯是否有合理  目錄  1. 關(guān)于本文檔 1.1. 內(nèi)容說明 說明：此處描述的是文檔說明，產(chǎn)品需求文檔更新需要走修訂模式，下次更新前先接受修訂，并且每次更新必須更新版本號和版本記錄。 例子： 本文檔用于描述蘇寧開放平臺物流狀態(tài)服務(wù)系統(tǒng)的需求定義。包括各個需求的功能

3、描述，處理邏輯規(guī)則，界面定義，與其它功能的關(guān)系，與其它系統(tǒng)的接口等各個方面的定義。是蘇寧物流狀態(tài)服務(wù)系統(tǒng)唯一的全面需求定義文檔。 本文檔將根據(jù)需求管理流程和要求，隨系統(tǒng)功能變化進行及時的修訂和更新，以確保本文檔的全面性，準(zhǔn)確性和實效性。因此在閱讀使用此文檔時，請注意從項目的文檔管理系統(tǒng)中獲取最新版本。 1.2. 名詞解釋 詞匯名稱 詞匯含義 備注 LSQ 物流狀態(tài)服務(wù)系統(tǒng) LSP 物流服務(wù)平臺 LES 物流作業(yè)系統(tǒng) LWMS 分布式倉儲管理系統(tǒng) TMS 運輸管理系統(tǒng) 1.3. 參考文檔 《系統(tǒng)需求定義規(guī)范使用說明v1.0.doc》

4、 2. 系統(tǒng)概述 2.1. 業(yè)務(wù)背景 說明：此處描述業(yè)務(wù)背景，不可裁剪，清晰的業(yè)務(wù)背景描述能更好的幫助研發(fā)和測試?yán)斫猱a(chǎn)品需求，明確業(yè)務(wù)測試場景，此部分是產(chǎn)品需求定位的核心導(dǎo)向。 例子一：電子面單的業(yè)務(wù)描述 隨著電子商務(wù)服務(wù)和物流服務(wù)信息化飛速發(fā)展，包裹運單號成為快遞公司串聯(lián)快遞單、訂單、商家、商品等各種信息的樞紐。相比之下，傳統(tǒng)紙質(zhì)面單價格高、信息錄入效率低、信息安全隱患等方面的劣勢已愈發(fā)凸顯。我司在兩年前就開始了電子面單在自營物流上的應(yīng)用，經(jīng)過長期的的磨合和積累，目前將我司的應(yīng)用經(jīng)驗推廣到社會物流上，讓社會上愿意與我司物流合作的伙伴，也同樣享受到我司電子面單服務(wù)。 例子二：

5、LSQ的業(yè)務(wù)描述 物流作業(yè)狀態(tài)服務(wù)存在不足 1）服務(wù)無標(biāo)準(zhǔn)不統(tǒng)一 需物流作業(yè)的各渠道訂單，作業(yè)狀態(tài)轉(zhuǎn)化為文案描述處理的邏輯系統(tǒng)多，且處理規(guī)不統(tǒng)一， －B2C自營訂單，邏輯在B2C，數(shù)據(jù)源在OMS －菜鳥平臺/4PS平臺訂單狀態(tài)展示，邏輯在LAPI，數(shù)據(jù)源在LAPI －物流門戶訂單狀態(tài)展示，邏輯在LPS，數(shù)據(jù)源在LOS －開放平臺訂單，邏輯在SOD，數(shù)據(jù)源在SOD －R3自營訂單，無邏輯，數(shù)據(jù)源在R3 2）維度單一而不滿足新需求 不能滿足多樣化的展示需求，如目前只有訂單維度的狀

6、態(tài)詳情展示，不支持任務(wù)單、顧客包裹等維度的詳情服務(wù)。 同時，缺乏物流特定作業(yè)狀態(tài)的高實時性精確查詢服務(wù)（如是否銷單完成，是否過賬，最新站點是哪個等）。 3）開放服務(wù)的渠道有待拓展 目前，物流沒有一個公網(wǎng)渠道，使顧客能快速查詢在蘇寧各渠道訂單的作業(yè)狀態(tài)信息。 故設(shè)計一個物流狀態(tài)系統(tǒng)統(tǒng)一管理物流狀態(tài)的收發(fā)，狀態(tài)描述轉(zhuǎn)換，以及提供狀態(tài)服務(wù)查詢。 2.2. 系統(tǒng)概述 說明：系統(tǒng)說明包括文字部分和圖形部分，文字部分主要描述系統(tǒng)之間的關(guān)聯(lián)關(guān)系，圖形主要包括系統(tǒng)和相關(guān)聯(lián)系統(tǒng)之間的交互結(jié)構(gòu)，不可裁剪 例子一：系統(tǒng)說明 合作伙伴申請?zhí)K寧電子面單服務(wù)，選擇相應(yīng)的合作模式，由合作

7、伙伴提供預(yù)配送包裹的信息，由蘇寧電子面單服務(wù)生成相應(yīng)的面單信息，并由合作伙伴系統(tǒng)打印出來并完成包裝，最終投遞給蘇寧網(wǎng)點且面單能被蘇寧物流體系識別。 系統(tǒng)之間的關(guān)聯(lián)關(guān)系： 蘇寧電子面單服務(wù)是基于蘇寧自營物流電子面單應(yīng)用，整合社會上多家快遞公司，搭建一套具有蘇寧配送特色的電子面單服務(wù)體系，為蘇寧物流的合作伙伴提供統(tǒng)一的電子面單服務(wù)。實現(xiàn)了，合作伙伴對接蘇寧的物流服務(wù)，由使用紙質(zhì)面單向電子面單轉(zhuǎn)變。只要合作伙伴對接了蘇寧電子面單服務(wù)，那么就可以享受蘇寧物流體系的電子面單服務(wù)。 本系統(tǒng)當(dāng)期功能主要包含： A、用戶操作權(quán)限管理； B、配置數(shù)據(jù)信息管理； C、訂單對應(yīng)的作業(yè)單物流節(jié)點狀態(tài)信息接

8、收與分發(fā)功能； D、訂單對應(yīng)的作業(yè)單物流節(jié)點狀態(tài)信息查詢功能； 2.3. 流程概覽/系統(tǒng)框架 說明：此處需要描述和圖形化系統(tǒng)內(nèi)部功能結(jié)構(gòu)模塊圖，可從架構(gòu)和技術(shù)獲取資源。清晰的系統(tǒng)架構(gòu)對于系統(tǒng)的擴展性和維護性都非常有幫助，也便于開發(fā)和測試從整體上理解該系統(tǒng)的結(jié)構(gòu)。 2.4. 系統(tǒng)規(guī)劃與迭代 說明：此處說明對該系統(tǒng)的總體規(guī)劃步驟，一期接入什么功能，二期接入什么功能達(dá)到什么業(yè)務(wù)效果。 2.5. 功能模塊 說明：此處的列表和下面的功能需求是對應(yīng)的，系統(tǒng)需求編號是唯一識別需求的標(biāo)識。需求編號的規(guī)則見3.2.1.1章節(jié) 例子： 主功能 系統(tǒng)需求編號 子功

9、能 優(yōu)先級 備注 狀態(tài)信息接收推送 LSQ_DDZF_MDZF_0001 非采購類狀態(tài)信息接收 一級 一期需求 LSQ_DDZF_MDZF_0002 狀態(tài)信息發(fā)送 一級 一期需求 LSQ_DDZF_MDZF_0003 狀態(tài)轉(zhuǎn)換 一級 一期需求 接收計劃物流節(jié)點信息 SNPD_LSQ_SSS_04 接收計劃物流節(jié)點信息 二級 最新站點查詢服務(wù) SNPD_LSQ_SSS_05 最新站點查詢服務(wù) 二級 一期需求 詳情調(diào)用服務(wù) SNPD_LSQ_SSS_06 虛擬包裹信息接收與更新 一級 一期需求 SNPD_LSQ_SSS_07 BT

10、C物流物流詳情調(diào)用 一級 一期需求 SNPD_LSQ_SSS_08 CIC物流物流詳情調(diào)用 一級 一期需求 后臺配置 SNPD_LSQ_SSS_09 后臺配置 一級 一期需求 快遞100接入服務(wù) SNPD_LSQ_SSS_10 快遞100查詢與推送運單信息 一級 二期需求 物流詳情查詢 SNPD_LSQ_SSS_11 作業(yè)系統(tǒng)查詢狀態(tài)明細(xì) 一級 LES拆分需求 3. 系統(tǒng)功能需求 3.1 狀態(tài)信息接受推送 3.1.1 非采購類狀態(tài)信息接收 3.1.1.1 需求編號LSQ_DDZF_MDZF_0001 說明： //功能的業(yè)務(wù)介紹和業(yè)務(wù)背景

11、 此處的需求編號，在一個系統(tǒng)中必現(xiàn)唯一存在并且最后4位遞增，規(guī)則：系統(tǒng)名_模塊名_子功能名_序列號，如LSQ_DDZF_MDZF_0001： 系統(tǒng)名最長保留4位，模塊名/子功能名最長4位，序列號最長4位不夠4位補0比如0001，如果是優(yōu)化需求，需求編號不變，新增需求需求編號增加； 3.1.1.2 處理流程和約束條件 說明：此處是放上面功能的業(yè)務(wù)流程圖和功能的業(yè)務(wù)邏輯約束條件 流程圖： 說明：如果流程圖比較大或比較多，請以單獨的附件提供 約束 # 步驟 邏輯 10 功能入?yún)⒋_認(rèn) 1. 入?yún)⒋_認(rèn) 1) 用戶名； 2) 密碼 2 校驗處理 1. 校驗

12、：用戶名在數(shù)據(jù)庫中唯一且存在； 1) 成立，繼續(xù)后續(xù)校驗 2) 不成立，返回報錯：請輸入正確的用戶名密碼 2. 校驗：安全性： 1) 安全性不通過，則提示該登錄可能存在安全隱患，請重新訪問； 2) 安全性通過，則繼續(xù)下面， 3 訂單處理 4 組織結(jié)果反饋 1. 全部校驗通過： 1) 提示：登錄成功，數(shù)據(jù)庫更新最后登錄時間； 2) 可進入系統(tǒng)進行后續(xù)操作 3.1.1.3 頁面原型 說明： N/A，系統(tǒng)后臺功能無頁面 有頁面請截低保真的圖，圖片要能覆蓋所描述的功能，以及頁面訪問路徑。 3.1.1.4 數(shù)據(jù)說明 說明： N/A，系統(tǒng)后臺功能無頁

13、面 如果有頁面校驗請在此處用列表的形式說明各個頁面各個控件的校驗規(guī)則 XX功能 字段名 數(shù)據(jù)類型 頁面長度 小數(shù)位 說明 用戶名 字符 10 非空，必須包括大小寫字母、字符，不可輸入中文 密碼 字符 10 非空，必須包括大小寫字母、字符、特殊字符 3.1.1.5 功能需求描述 說明： 1）功能描述，需要做到語言準(zhǔn)確，結(jié)構(gòu)清晰，須包括從用戶角度和業(yè)務(wù)角度描述功能和業(yè)務(wù)場景；要盡可能少地從系統(tǒng)邏輯角度去撰寫需求，多寫業(yè)務(wù)邏輯以免干擾開發(fā)的最優(yōu)設(shè)計。在需求中明確業(yè)務(wù)接口。 2）版本優(yōu)化，如果是優(yōu)化功能采用修訂模式在涉及到的

14、所有原文檔（包括需求說明書、流程圖、接口文檔）上進行修改并標(biāo)注，需求說明書需對應(yīng)需求編號章節(jié)進行修改，這樣便于研發(fā)和測試了解原功能，以便快速了解優(yōu)化的業(yè)務(wù)判斷回歸場景。產(chǎn)品還需說明優(yōu)化此功能的業(yè)務(wù)場景以及建議優(yōu)化功能涉及相關(guān)使用場景。（0522版本） 特別說明：修改的功能會影響系統(tǒng)對外提供的接口，需要這些接口的使用方對接口進行驗證，并確認(rèn)接口的變更 登錄 1） 針對登錄功能，需要做安全性校驗，實行https的方式，并且登錄密碼以*顯示，在日志打印中也以*展示； 2） 登錄功能，登錄調(diào)用API 接口INTERFACE_LSQ_LOGIN_0001實現(xiàn)登錄，需要保證數(shù)據(jù)傳遞的安全性。 狀

15、態(tài)接受 LSQ系統(tǒng)接收狀態(tài)信息，作如下處理： 數(shù)據(jù)類型 長度 小數(shù)位 說明 ID 字符 32 主鍵，系統(tǒng)自動生成的流水號 外部流水號 字符 32 外部傳的流水號 外部系統(tǒng) 字符 10 當(dāng)前外部訂單對應(yīng)的“外部系統(tǒng)” 任務(wù)單號 字符 20 當(dāng)前外部訂單對應(yīng)的“外部訂單編碼” 物流訂單號 字符 30 通過賣家ID查詢客戶信息匹配表，結(jié)果為查詢到的賣家ID對應(yīng)的“客戶編碼” 訂單屬性 字符 10 當(dāng)前外部訂單對應(yīng)的“蘇寧業(yè)務(wù)類型” 訂單客戶 字符 10 若業(yè)務(wù)類型為“C019”，則默認(rèn)為“ZVIN”入倉

16、 前置任務(wù)單系統(tǒng) 字符 10 在接收4PS銷退入庫單時，若orderFlag訂單標(biāo)記帶有9，則在下傳裝運條件時，傳輸“01”自營，其他則按照原有邏輯傳“06”第三方 服務(wù)大類 字符 20 固定賦值“L01倉儲” 收入項 字符 20 固定賦值“ L0101存量” 服務(wù)產(chǎn)品 字符 4 固定賦值“ L倉庫保管” 服務(wù)細(xì)節(jié) 字符 4 根據(jù)物流中心匹配zlmt026，取屬性，若屬性=MD，則服務(wù)細(xì)節(jié)= L門店庫存，否則為L中心倉庫存 商品屬性 字符 60 用物料號匹配商品主數(shù)據(jù)，取商品屬性（當(dāng)用計費明細(xì)的物料號matnr時，首先做取

17、前置0 ，然后再去關(guān)聯(lián)MDM商品主數(shù)據(jù)） 件數(shù) 字符 10 回算表的lfimg 網(wǎng)點描述 字符 60 固定賦值“L01倉儲” 實際交貨數(shù)量 數(shù)值 13 固定賦值“ L0101存量” 數(shù)量單位 字符 3 固定賦值“ L倉庫保管” 排程日期時間 字符 14 若訂單對應(yīng)的基本信息的“預(yù)期送達(dá)開始時間”為空，且當(dāng)前日期時間比當(dāng)前日期時間18:00:00早，則為當(dāng)前日期，否則為當(dāng)前日期+1天； 若訂單對應(yīng)的基本信息“預(yù)期送達(dá)開始時間”不為空，則取該時間中的日期，格式為YYYY-MM-DD 接收日期時間 字符 19 系統(tǒng)當(dāng)前日期

18、 3.1.1.6 接口說明 說明：如果字段少可直接把接口列表貼這里，接口模板見下表必須包括深度和返回消息，如果有不同返回碼也需要一并定義。每個接口在需求文檔中撰寫一個編號，在系統(tǒng)中唯一，以便附件中能快速找到對應(yīng)的接口，便于定期維護，接口編號：規(guī)則一個系統(tǒng)唯一：INTERFACE_系統(tǒng)名_一級模塊名_編號遞增 產(chǎn)品定義的接口只需提供到中文字段名、長度、是否必須，校驗說明即可。 API 接口INTERFACE_LSQ_LOGIN_0001 深度 名稱 描述 類型長度 是否必輸 說明 1 INPUT 請求輸入 2 ITEM 3 usern

19、ame 用戶名 CHAR(10) 必輸 不可為空 3 Password 密碼 CHAR(10) 必輸 不可為空 3 token 盾牌 CHAR(30) 必輸 不可為空 1 OUTPUT 請求輸出 2 username 用戶名 CHAR(30) 必輸 2 returnCode 結(jié)果狀態(tài) CHAR(10) 必輸 0-成功，1-失敗 2 Message 文本描述 CHAR(255) 接收成功/接收失敗 returnCode返回碼說明： 快遞公司驗證 returnCode Message 快遞100需要

20、做的操作 LSQ訂閱成功 200 成功 LSQ數(shù)據(jù)驗證失敗 400 數(shù)據(jù)不完整 補充數(shù)據(jù)，重新訂閱 LSQ格式驗證失敗 500 請求格式錯誤 程序有問題，需要調(diào)整 本地服務(wù)器錯誤 501 服務(wù)器錯誤 30分鐘后嘗試 LSQ訂閱日志已存在 502 重復(fù)訂閱 理解為訂閱成功 LAPI校驗KEY錯誤 503 驗證簽名失敗 使用正確的KEY LSQ未查到對應(yīng)物流單號 504 單號錯誤 更正單號 LSQ未查到對應(yīng)物流單號 507 查詢異常 狀態(tài)接收接口INTERFACE_LSQ_STATUS_0001 由于字段較多見附件，每個接

21、口在需求文檔中撰寫一個編號，規(guī)則一個系統(tǒng)唯一：INTERFACE_系統(tǒng)名_一級模塊名_編號遞增 該功能處理過程中會調(diào)用以下接口（見附件）： 接口編號 接口名稱 原系統(tǒng) 目標(biāo)系統(tǒng) 場景 INTERFACE_LSQ_LOGIN_0001 API登錄接口 LSQ API 處理成功，登錄成功 INTERFACE_LSQ_STATUS_0001 狀態(tài)信息同步LSQ LOS/TMS/LWMS LSQ MQ信息處理成功記錄到LSQ系統(tǒng) 3.1.1.7 其它說明 說明：可以把性能需求或者安全性，穩(wěn)定性需求，頁面瀏覽器兼容性需求等等放此處 3.1.2 狀態(tài)信息發(fā)送 3

22、.1.2.1 需求編號LSQ_DDZF_MDZF_0002 3.1.2.2 處理流程和約束條件 # 步驟 邏輯 10 訂單判斷 1. 使用訂單行號查詢本地是否存在對應(yīng)的訂單行 1) 存在，繼續(xù)后續(xù)判斷； 2) 不存在，進入后續(xù)校驗； 2. 判斷訂單行狀態(tài)： 1) 如果訂單行狀態(tài)10-已提交，12-訂單異常，進入后續(xù)校驗； 2) 如果訂單行狀態(tài)大于等于20-處理成功，直接返回成功； 3. 判斷訂單是否存在后續(xù)退貨訂單； 1) 存在，返回報錯：該訂單狀態(tài)準(zhǔn)確，不可進行支付 2) 不存在，進入后續(xù)校驗； 4. 判斷訂單支付金額是否正確，判斷等式：行項目銷售額+運費

23、+服務(wù)費=支付金額之和+使用積分金額+經(jīng)理卡金額，是否成立； 1) 成立，繼續(xù)后續(xù)處理 2) 不成立：支付金額不正確，請檢查后重新輸入； 20 訂單支付信息處理 1. 訂單行支付狀態(tài)設(shè)置：將所有訂單行狀態(tài)都置為：30-已支付； 2. 保存新增的支付信息； 3. 覆蓋本地已有的優(yōu)惠單信息； 4. 凍結(jié)標(biāo)志設(shè)置：如果訂單支付信息中含有：4001（支票支付），則將訂單行凍結(jié)標(biāo)識置為：D2-支票凍結(jié)； 5. 支付確認(rèn)標(biāo)記設(shè)置：門店訂單【支付確認(rèn)開關(guān)】為打開狀態(tài)時，對于滿足以下條件的訂單行項目，將訂單行支付確認(rèn)標(biāo)識置為：0-未確認(rèn)支付； 1) 分銷渠道為10-零售、20-代購， 2

24、) 且來源系統(tǒng)為POS。 3) SAP訂單類型為ZOR-標(biāo)準(zhǔn)訂單、IDOC、Z01、ZGF。 4) 裝運條件為01、14。 5) 先銷后采標(biāo)識不為5。 20 訂單支付信息處理 1. 調(diào)用【公共規(guī)則-資源處理】功能； 1) 成功，將訂單行狀態(tài)置為：20-已處理，訂單頭狀態(tài)：20-已處理； 2) 失敗，將訂單行狀態(tài)置為：12-處理失敗，訂單頭狀態(tài)置為：12-處理失??； 30 組織結(jié)果反饋 1. 根據(jù)處理結(jié)果，組織結(jié)果反饋； 40 實時同步 1. OMSD全量：調(diào)用功能【公共功能-訂單全量信息分發(fā)OMSD】 2. OMSQ全量：調(diào)用功能【公共功能-訂單全量信息分發(fā)OMS

25、Q】 50 異步同步 1. BI-大數(shù)據(jù)系統(tǒng)：調(diào)用【公共規(guī)則-】 2. PMS-價格中心系統(tǒng)：調(diào)用【公共規(guī)則-】 3. SPCS-云商卡系統(tǒng)：調(diào)用【公共規(guī)則-】 4. BUDS-財務(wù)系統(tǒng)：調(diào)用【公共規(guī)則】 60 日志打印 打日志：OMS訂單號，OMS行訂單號，訂單支付完成時間，預(yù)計出庫時間，期望送達(dá)時間 ，支付訂單創(chuàng)建時間,SAP訂單類型，先銷后采標(biāo)識，訂單來源，下單時間，渠道，行項目類別，分次發(fā)貨標(biāo)識，支付類型（04門店支付），支付確認(rèn)標(biāo)識，日志階段：02（01提交，02支付，03支付確認(rèn)，04還欠款）id（） 3.1.2.3 頁面原型 N/A，系統(tǒng)后臺功能無頁

26、面 3.1.2.4 數(shù)據(jù)說明 N/A，系統(tǒng)后臺功能無頁面 3.1.2.5 功能需求描述 針對以下業(yè)務(wù)場景，前端系統(tǒng)通過該功能完成門店訂單收款處理； # 場景 接口 01 電器門店零售訂單收銀臺全款支付處理 POS-OMS-008 操作碼：D 02 電器門店對公云商卡訂單收銀臺全款支付處理 POS-OMS-008 操作碼：D 3.1.2.6 接口說明 3.1.2.7 其它說明 3.2 最新站點查詢服務(wù) 3.2.1 最新站點查詢 3.2.1.1 需求編號LSQ_DDTJ_DDTJ_0003 3.2.1.2 處理流程和約束條件 接收到前端系統(tǒng)提交的訂單

27、后，進行訂單提交相關(guān)處理，具體邏輯如下： 具體步驟邏輯如下： # 步驟 邏輯 10 提交訂單 前端系統(tǒng)通過以下接口提交訂單，且訂單類型為A時，進入該功能： ? SPOS-OMS-001 ? B2C-OMS-001 ? ALL-OMS-001 ? ALL-OMS-016 20 進行訂單合法性校驗 根據(jù)接口傳入訂單信息進行合法性校驗： 1. 訂單重復(fù)性校驗 2. 若接口輸入的接單模式為1或者3，則進行訂單金額校驗 1) 判斷行優(yōu)惠單金額是否正確。校驗公式：行優(yōu)惠單金額 = 行優(yōu)惠單明細(xì)金額匯總： a) 若不正確，則返回報錯：訂單行“前端系統(tǒng)行項目號“的優(yōu)惠單

28、總金額與優(yōu)惠單明細(xì)不一致。 b) 否則進行一下步判斷 2) 若訂單提交接口為ALL-OMS-001，則需判斷行銷售額是否正確，校驗公式：行銷售額 = 銷售價 * 數(shù)量： a) 若不正確，則返回報錯：訂單行“前端系統(tǒng)行項目號“的銷售額”XX”不等于銷售價格”XX”*數(shù)量”XX”。 b) 否則進行一下步判斷 3) 若訂單提交接口為ALL-OMS-001，則需判斷行應(yīng)付金額是否與支付明細(xì)匯總金額一致，校驗公式：行項目銷售額+運費+服務(wù)費=支付金額之和+使用積分?jǐn)?shù)金額+經(jīng)理卡金額： a) 若不正確，則返回報錯：訂單行“前端系統(tǒng)行項目號“的總支付金額與應(yīng)付金額不一致。 b) 否則進行一下步

29、判斷 4) 若訂單提交接口為B2C-OMS-001，則需判斷行應(yīng)付金額是否與支付明細(xì)匯總金額一致，校驗公式：銷售價*數(shù)量-經(jīng)理卡金額+運費+行稅額+服務(wù)費=支付金額之和： a) 若不正確，則返回報錯：訂單行“前端系統(tǒng)行項目號“的總支付金額與應(yīng)付金額不一致。 b) 否則進行一下步判斷 3. 根據(jù)校驗結(jié)果： 1) 若以上所有校驗通過，則進入下一步“30-生成或更新訂單信息”步驟 2) 若以上任意校驗失敗，則進入“50-返回處理結(jié)果”步驟 30 生成或更新訂單信息 根據(jù)接口傳入的訂單信息創(chuàng)建訂單信息或全量更新以下信息： 1. 若是創(chuàng)建訂單，則根據(jù)單號規(guī)則生成訂單號和訂單行號 2

30、. 進行訂單狀態(tài)設(shè)置 1) 進行訂單行總狀態(tài)設(shè)置，具體邏輯見“表-訂單行總狀態(tài)（IS）設(shè)置邏輯” 2) 進行訂單行支付狀態(tài)設(shè)置，具體邏輯見“表-訂單行支付狀態(tài)（IP）設(shè)置邏輯” 3) 進行訂單行發(fā)票狀態(tài)設(shè)置，默認(rèn)設(shè)置為IV=10 4) 進行訂單頭總狀態(tài)設(shè)置 3. 進行訂單特殊標(biāo)記設(shè)置 1) 進行訂單行凍結(jié)標(biāo)識設(shè)置 a) 若分銷渠道=30，且訂單來源為CRM，則設(shè)置分次發(fā)貨標(biāo)記為D3-對公訂單未付款凍結(jié) b) 否則，如訂單支付方式中含有4001：支票支付，則設(shè)置分次發(fā)貨標(biāo)記為：D2-支票交貨凍結(jié) c) 否則，對于其他場景設(shè)置分次發(fā)貨標(biāo)記為A-只允許一次發(fā)貨 2) 進行訂單行大

31、客戶付款類型設(shè)置。滿足以下所有條件，設(shè)置大客戶付款類型為1-確認(rèn)欠款： a) 訂單來源為SPCS b) 行項目類別為16-云商卡訂單 c) 接單模式為1 d) 支付方式含9005 3) 進行訂單行是否需要發(fā)票設(shè)置 4. 根據(jù)接口傳入訂單信息保存訂單基本信息 5. 根據(jù)接口傳入訂單擴展信息保存訂單相關(guān)擴展信息 1) 若訂單行類別= 10，且接口中存在服務(wù)商品，則需要保存服務(wù)擴展信息 2) 若訂單行類別=11，則需要保存延保擴展信息 3) 若訂單行類別=12，則需要保存贈品擴展信息 4) 若訂單行類別=13，則需要保存虛擬商品信息 5) 若訂單行類別=14，則需要保存合約擴

32、展信息 6) 若訂單行類別=16，則需要保存云商卡擴展信息 7) 若訂單行類別=20，電子書無擴展信息，無需保存 8) 若訂單行類別=22，則需要保存獨立服務(wù)擴展信息 9) 若訂單行類別=24，則需要保存運費險擴展信息 6. 若接口傳入的支付方式含9002-貨到付款、9003-融合支付，則需要保存還欠款信息 7. 訂單信息保存后，根據(jù)接單模式： 1) 若訂單保存成功，且接口傳入的接單模式為1，則進入下一步“40-訂單調(diào)度處理”； 2) 若訂單保存成功，且若接口傳入的接單模式為2、3，則進入下一步“50-返回處理結(jié)果” 3) 若訂單保存失敗，則直接進入下一步“50-返回處理結(jié)果

33、” 40 進行訂單處理調(diào)度 調(diào)用功能【OMS_ZYCL_ZYCL_001-資源處理（老流程）】進行處理 50 返回處理結(jié)果 1. 根據(jù)30、40步驟的處理結(jié)果，返回對應(yīng)信息 1) 若處理失敗，則返回前端處理失敗 2) 若處理成功，則返回前端處理成功 2. 進入下一步“記錄日志信息”步驟 60 記錄日志信息 1. 若為。。。則： 2. 3. 根據(jù)30、40步驟的處理結(jié)果 1) 若處理失敗，則結(jié)束本次提交流程 2) 若處理成功，則繼續(xù)進行后續(xù) “70-保存或更新訂單信息”、“80-異步分發(fā)訂單”和“90-保存待分發(fā)信息”步驟 70 保存或更新訂單信息 1. 保

34、存BUDS信息 1) 滿足以下所有條件，保存該訂單行支付明細(xì)到BUDS支付明細(xì)信息中 a) 訂單行項目類別不為16 b) 訂單行支付中存在9001-香港欠款、9002-貨到付款、或者9005-對公欠款 2. 設(shè)置訂單實時處理標(biāo)記。 1) 滿足以下所有條件設(shè)置實時處理標(biāo)記為Y a) 行項目類別為10-實體、12-贈品 b) “裝運條件為空-自提、17-物流門店庫自提、20-物流門店庫自提”或者“裝運條件為02-門店自提且SAP訂單類型=IDOC” c) 分次發(fā)貨標(biāo)識為A-只允許一次發(fā)貨、或者D2-支票凍結(jié) d) 訂單行狀態(tài)>=20 e) 訂單類型不為C-退貨訂單 f) 先

35、銷后采標(biāo)識為空、或者0 2) 若SAP訂單類型為ZSIA且為10渠道（門店互聯(lián)開卡訂單），則設(shè)置實時處理標(biāo)記為Y 3) 其他情況，不設(shè)置實時處理標(biāo)記 3. 保存訂單展示價信息： 1) 若調(diào)用接口為B2C-OMS-001，則需要保存訂單展示價： a) 若接口傳入的展示價（displayPrice）有值，則保存該字段的值為訂單展示價 b) 若接口傳入的展示價（displayPrice）無值，則保存訂單展示價為接口傳入的銷售價（price）- 《發(fā)票虛增價》 2) 其他調(diào)用接口不進行處理 80 異步分發(fā)訂單 1. 訂單行實時分發(fā)OMSD 1) 滿足以下所有條件的訂單實時分發(fā)OM

36、SD，通過接口（OMS-OMSD-001） a) 訂單行總狀態(tài)為20-已處理、40-已發(fā)貨、或者60-已完成 b) 訂單行項目類別<>13-禮品卡 c) 分次發(fā)貨標(biāo)識為A-只允許一次發(fā)貨、或者D2-支票凍結(jié) d) 訂單行支付確認(rèn)標(biāo)識為空、1-已支付確認(rèn) 2. 訂單行實時分發(fā)OMSQ 1) 滿足以下所有條件的訂單實時分發(fā)OMSQ，通過接口（OMS-OMSQ-001） 90 保存待分發(fā)信息 1. 滿足以下條件保存待分發(fā)已支付訂單信息到BI，，通過接口（OMS-BI-002） 1) 訂單類型為A-一般銷售訂單、B-虛擬訂單 2) 行項目類別為： 3) 訂單渠道為： 4) 訂

37、單行總狀態(tài)>=20-已處理 5) 分次發(fā)貨標(biāo)識不為D3-對公支付 2. 滿足以下條件保存待分發(fā)未支付訂單信息到BI，通過接口（OMS-BI-003） 1) 3. 滿足以下條件保存待分發(fā)已支付訂單信息到PMS，通過接口（OMS-PMS-002） 1) 訂單類型為A-一般銷售訂單 2) 訂單行項目類別為： 3) 訂單行先銷后采標(biāo)識為：0、1、2、3、4、6、或者9 4) 訂單渠道為：10、20、30（且訂單來源為CRM）、50、或者60 5) 訂單行總狀態(tài)>=20-已處理 6) 訂單行分次發(fā)貨標(biāo)識不為D3-對公支付 4. 滿足以下條件保存待分發(fā)已支付訂單信息到POS，通過接口

38、（OMS-POS-0??） 5. 保存待分發(fā)已支付訂單信息到SAP 1) 滿足以下條件保存待分發(fā)IDOC訂單信息，通過接口（OMS-SAP-022） a) 訂單行SAP訂單類型=IDOC b) 訂單行總狀態(tài)（IS）>=20 c) 訂單方向=1-正向訂單 2) 滿足以下條件保存待分發(fā)合約機訂單信息，通過接口（OMS-SAP-011） a) 訂單行SAP訂單類型=ZSIM b) 訂單行總狀態(tài)（IS）>=20 c) 訂單方向=1-正向訂單 d) 訂單行項目類別=14-合約機 3) 滿足以下條件保存待分發(fā)互聯(lián)訂單信息，通過接口（OMS-SAP-036） a) 訂單行SAP訂單類

39、型為：ZSIA、或者ZSIB b) 訂單行總狀態(tài)（IS）>=20 c) 訂單方向=1-正向訂單 d) 訂單行項目類別=14-合約機 4) 滿足以下條件保存待分發(fā)超市訂單信息，通過接口（OMS-SAP-040） a) 訂單行SAP訂單類型：CSLY、或者YDDS b) 訂單行先銷后采標(biāo)識為：8 c) 訂單行總狀態(tài)（IS）>=20 d) 訂單方向=1-正向訂單 5) 滿足以下條件保存待分發(fā)SWL、聯(lián)營廠送訂單信息，通過接口（OMS-SAP-041） a) 訂單行先銷后采標(biāo)識為：7、或者9 b) 訂單行總狀態(tài)（IS）>=20 c) 訂單方向=1-正向訂單 6) 滿足以下條件

40、保存待分發(fā)IDOC訂單（3C類）信息，通過接口（OMS-SAP-038） a) 訂單行SAP訂單類型=IDOC b) 訂單行總狀態(tài)（IS）>=20 c) 訂單方向=1-正向訂單 7) 滿足以下條件保存待分發(fā)賬期支付訂單信息，通過接口（OMS-SAP-053） a) 訂單渠道為：10、20、30、40、或者50 b) 訂單行支付狀態(tài)（IP）=30 c) 訂單行支付明細(xì)中包含9102支付方式 8) 滿足以下條件保存待分發(fā)合約機手機行結(jié)算信息，通過接口（OMS-SAP-032） a) 訂單行項目類別為：10-實體 b) 訂單行存在《合約關(guān)聯(lián)關(guān)系》 c) 訂單行關(guān)聯(lián)的合約行的SA

41、P訂單類型為：IDOC或者ZSIM d) 訂單行總狀態(tài)（IS）>=20 9) 滿足以下條件保存待分發(fā)合約機合約行結(jié)算信息，通過接口（OMS-SAP-033） a) 訂單行項目類別為：14-合約機 b) 訂單行SAP訂單類型=IDOC、或者ZSIM c) 訂單行總狀態(tài)（IS）>=20 10) 滿足以下條件保存待分發(fā)C店訂單信息，通過接口（OMS-SAP-037） a) 訂單行總狀態(tài)（IS）=20 b) 訂單行先銷后采標(biāo)識為：5 c) 訂單渠道為：50 d) 訂單行支付明細(xì)中包含支付方式5002、或者6904 11) 滿足以下條件保存待分發(fā)商轉(zhuǎn)贈訂單信息，通過接口（OMS-S

42、AP-042） a) 訂單行項目類別為：10-實體、或者12-贈品 b) 訂單行為《商轉(zhuǎn)贈訂單》 c) 訂單行總狀態(tài)（IS）=20 6. 滿足以下條件保存待返積分信息到CMF，通過接口（OMS-CMF-006/OMS-CMF-007） 1) IS>=20 已完成； 2) IP=30 已支付； 3) 接單模式<>3-一步式不待處理 4) 來源系統(tǒng)不為BSS、SAP、TMALL、SDIPA 5) 行項目類別為：10、11、12、14； 6) 業(yè)務(wù)類型不為：配置數(shù)據(jù) 7. 滿足以下條件保存待返券信息到SPES，通過接口（OMS-SPES-0??） 8. 滿足以下條件保存待

43、分發(fā)已支付訂單信息到IPS，通過接口（OMS-IPS-001） 1) 訂單行先銷后采標(biāo)識為：空、0、1、2、3、4、6、7、或者9 2) 訂單行總狀態(tài)>=20-已處理 3) 訂單行類別為：10-實體、11-延保、12-贈品、或者14-合約 4) 訂單行發(fā)票類型為：01、02（是否需要打印發(fā)票<>“N”）、03、或者04 5) 訂單渠道為：40（訂單來源為TMALL）、50、或者60 9. 保存待分發(fā)訂單信息到BUDS 1) 滿足以下條件保存待分發(fā)云商卡訂單信息，通過接口（OMS-BUDS-055） a) 訂單行項目類別為：16-云商卡 b) 訂單行總狀態(tài)（IS）=20 2)

44、 滿足以下條件保存待分發(fā)醫(yī)?？ㄓ唵涡畔?，通過接口（OMS-BUDS-055） a) 訂單行為《醫(yī)?？ㄓ唵巍? b) 訂單行總狀態(tài)（IS）>=20 3.2.1.3 頁面原型 N/A，系統(tǒng)后臺功能無頁面 3.2.1.4 數(shù)據(jù)說明 N/A，系統(tǒng)后臺功能無頁面 3.2.1.5 功能需求描述 針對以下業(yè)務(wù)場景，前端系統(tǒng)提交訂單至OMS，OMS進行訂單提交的合法校驗，訂單提交的資源處理以及訂單保存，并根據(jù)對應(yīng)的場景，判斷是否調(diào)用后續(xù)處理。 * 接單模式：1-一步式需處理資源；2-兩步式需處理資源；3-一步式無需處理資源 3.2.1.6 接口說明 該功能處理過程中會調(diào)用以下接

45、口： 接口編號 接口名稱 目標(biāo)系統(tǒng) 場景 OMS-OMSD-001 訂單信息同步OMSD OMSD 訂單處理成功后，同步訂單信息到OMSD OMS-OMSQ-001 訂單信息同步OMSQ OMSQ 訂單提交或者處理成功后，同步訂單信息到OMSQ 3.2.1.7 其它說明 表-訂單行總狀態(tài)（IS）設(shè)置邏輯 接單模式 行項目類別 狀態(tài)值 1,2 ALL 10 3 10,11,12,14,15,16,20,22,24 20 3 13 60 表-訂單行支付狀態(tài)（IP）設(shè)置邏輯 接單模式 分銷渠道 訂單來源 支付方式 狀態(tài)值 1 30

46、 CRM ALL 10 1 50,60 ALL 無9002、9003、9005 30 1 50,60 ALL 只有9002、9003、9005 10 1 50,60 ALL 有9002、9003、9005,還有其他支付方式 20 1 10,20，40 ALL 無9001、9002、9003、9005 30 1 10,20，40 ALL 只有9001、9002、9003、9005 10 1 10,20，40 ALL 有9001、9002、9003、9005,還有其他支付方式 20 1 30 非CRM 無9001、9002、9

47、003、9005 30 1 30 非CRM 只有9001、9002、9003、9005 10 1 30 非CRM 有9001、9002、9003、9005,還有其他支付方式 20 2 ALL ALL ALL 10 3 ALL ALL ALL 30 4. 系統(tǒng)非功能需求 3.3 性能需求 請根據(jù)下表中性能指標(biāo)項定義性能需求，如不能滿足可在其他項中補充。 業(yè)務(wù) 業(yè)務(wù)量 峰值業(yè)務(wù)量 用戶數(shù) 響應(yīng)時間 其他 修改時間 訂單管理 24小時1000萬 24小時2000萬 前臺系統(tǒng)必需。訪問用戶數(shù)指單位時間內(nèi)訪問系統(tǒng)的用戶總數(shù)。 響

48、應(yīng)時間指完成一個交互的總時長，從客戶端發(fā)起請求開始，到客戶端接收完服務(wù)器響應(yīng)結(jié)果結(jié)束。如果系統(tǒng)中含有多種類型的交互，可以考慮分類設(shè)置響應(yīng)時間需求。 2017-05-18 訂單查詢功能接口 24小時1000萬 24小時2000萬 10萬用戶訪問 一般響應(yīng)時間我們是建議透傳的200ms，其他的500ms內(nèi) 2017-05-18 說明：//如果優(yōu)化版本對原基礎(chǔ)數(shù)據(jù)有影響，需要在需求說明書中使用修訂模式明確新指標(biāo) 3.4 安全性需求 安全性 標(biāo)題 內(nèi)容 安全性級別 登錄 所有登錄需要保證安全性性，秘密不能明文傳輸 高 支付 支付賬號、秘密必須進行加密傳輸 高 外網(wǎng)對接 外網(wǎng)數(shù)據(jù)傳輸需要防止跨站點攻擊 中 3.5 擴展性需求 擴展性 可擴展性 可擴展性指如果未來業(yè)務(wù)需求增長，系統(tǒng)架構(gòu)能否通過最小代價改變支持增長的能力。最小代價改變?nèi)缭黾蛹悍?wù)器數(shù)量等。該需求指方案是否需要考慮可擴展性的問題。 3.6 兼容性需求 兼容性 系統(tǒng)兼容性 系統(tǒng)需要向下兼容 頁面兼容性 支持IE8\IE10|Google最新\FF最新版本瀏覽器 3.7 維護性需求 5. 附錄 專心---專注---專業(yè)