系统需求规格说明书.doc

XXX系统或XXX项目
产品需求规格说明书

文献状态：
[√] 草稿
[ ] 正式发布
[ ] 正在修改
文献编号：
SN_SR_001
当前版本：
V1.0
作 者：

完毕日期：
2023-04-11

版本信息
版本
时间
状态
更新人
简要描述
审核人
审核时间
V1.0

V1.01

V1.2

V1.3

V1.4

注：状态可认为N-新建、A-增长、M-更改、D-删
除。

对方的所得税 说明：版本信息必须更新，审核人和审核时间也必须审核后填写，审核人规定部门经理级别以上。否则开发测试可拒绝评审。审核业务功能是否有漏掉、业务流程是否符合规划、关键业务逻辑是否有合理

目录
1. 关于本文档 4
1.1. 内容说明 4
1.2. 名词解释 4
1.3. 参考文档 4
2. 系统概述 5
2.1. 业务背景 5
2.2. 系统概述 6
2.3. 流程概览/系统框架 7
2.4. 系统规划与迭代 8
2.5. 功能模块 8
3. 系统功能需求 9
3.1 状态信息接受推送 9
3.2 最新站点查询服务 19
4. 系统非功能需求 33
3.3 性能需求 33
3.4 安全性需求 34
3.5 扩展性需求 34
3.6 兼容性需求 34
3.7 维护性需求 34
5. 附录 34

1. 关于本文档
1.1. 内容说明
说明：此处描述的是文档说明，产品需求文档更新需要走修订模式，下次更新前先接受修订，并且每次更新必须更新版本号和版本记录。
例子：
本文档用于描述苏宁开放平台物流状态服务系统的需求定义。涉及各个需求的功能描述，解决逻辑规则，界面定义，与其它功能的关系，与其它系统的接口等各个方面的定义。是苏宁物流状态服务系统唯一的全面需求定义文档。
本文档将根据需求管理流程和规定，随系统功能变化进行及时的修订和更新，以保证本文档的全面性，准确性和实效性。因此在阅读使用此文档时，请注意从项目的文档管理系统中获取最新版本。

1.2. 名词解释
词汇名称
词汇含义
备注
LSQ
物流状态服务系统

LSP
物流服务平台

LES
物流作业系统

LWMS
分布式仓储管理系统

TMS
运送管理系统

1.3. 参考文档
《系统需求定义规范使用说明v1.0.doc》

2. 系统概述
2.1. 业务背景
说明：此处描述业务背景，不可裁剪，清楚的业务背景描述能更好的帮助研发和测试理解产品需求，明确业务测试场景，此部分是产品需求定位的核心导向。
例子一：电子面单的业务描述
随着电子商务服务和物流服务信息化飞速发展，包裹运单号成为快递公司串联快递单、订单、商家、商品等各种信息的枢纽。相比之下，传统纸质面单价格高、信息录入效率低、信息安全隐患等方面的劣势已愈发凸显。我司在两年前就开始了电子面单在自营物流上的应用，通过长期的的磨合和积累，目前将我司的应用经验推广到社会物流上，让社会上乐意与我司物流合作的伙伴，也同样享受到我司电子面单服务。
例子二：LSQ的业务描述
物流作业状态服务存在局限性
1）服务无标准不统一
需物流作业的各渠道订单，作业状态转化为文案描述解决的逻辑系统多，且解决规不统一，
－B2C自营订单，逻辑在B2C，数据源在OMS
－菜鸟平台/4PS平台订单状态展示，逻辑在LAPI，数据源在LAPI
－物流门户订单状态展示，逻辑在LPS，数据源在LOS
－开放平台订单，逻辑在SOD，数据源在SOD
－R3自营订单，无逻辑，数据源在R3
2）维度单一而不满足新需求
不能满足多样化的展示需求，如目前只有订单维度的状态详情展示，不支持任务单、顾客包裹等维度的详情服务。
同时，缺少物流特定作业状态的高实时性精确查询服务（如是否销单完毕，是否过账，最新站点是哪个等）。
3）开放服务的渠道有待拓展
目前，物流没有一个公网渠道，使顾客能快速查询在苏宁各渠道订单的作业状态信息。
故设计一个物流状态系统统一管理物流状态的收发，状态描述转换，以及提供状态服务查询。
2.2. 系统概述
说明：系统说明涉及文字部分和图形部分，文字部分重要描述系统之间的关联关系，图形重要涉及系统和相关联系统之间的交互结构，不可裁剪
例子一：系统说明
合作伙伴申请苏宁电子面单服务，选择相应的合作模式，由合作伙伴提供预配送包裹的信息，由苏宁电子面单服务生成相应的面单信息，并由合作伙伴系统打印出来并完毕包装，最终投递给苏宁网点且面单能被苏宁物流体系辨认。
系统之间的关联关系：
苏宁电子面单服务是基于苏宁自营物流电子面单应用，整合社会上多家快递公司，搭建一套具有苏宁配送特色的电子面单服务体系，为苏宁物流的合作伙伴提供统一的电子面单服务。实现了，合作伙伴对接苏宁的物流服务，由使用纸质面单向电子面单转变。只要合作伙伴对接了苏宁电子面单服务，那么就可以享受苏宁物流体系的电子面单服务。
本系统当期功能重要包含：
A、用户操作权限管理；
B、配置数据信息管理；
C、订单相应的作业单物流节点状态信息接受与分发功能；
D、订单相应的作业单物流节点状态信息查询功能；

2.3. 流程概览/系统框架
说明：此处需要描述和图形化系统内部功能结构模块图，可从架构和技术获取资源。清楚的系统架构对于系统的扩展性和维护性都非常有帮助，也便于开发和测试从整体上理解该系统的结构。

2.4. 系统规划与迭代
说明：此处说明对该系统的总体规划环节，一期接入什么功能，二期接入什么功能达成什么业务效果。

2.5. 功能模块
说明：此处的列表和下面的功能需求是相应的，系统需求编号是唯一辨认需求的标记。需求编号的规则见3.2.1.1章节
例子：
主功能
系统需求编号
子功能
优先级
备注
状态信息接受推送
LSQ_DDZF_MDZF_0001
非采购类状态信息接受
一级
一期需求
LSQ_DDZF_MDZF_0002
状态信息发送
一级
一期需求
LSQ_DDZF_MDZF_0003
状态转换
一级
一期需求
接受计划物流节点信息
SNPD_LSQ_SSS_04
接受计划物流节点信息
二级

最新站点查询服务
SNPD_LSQ_SSS_05
最新站点查询服务
二级
一期需求
详情调用服务
SNPD_LSQ_SSS_06
虚拟包裹信息接受与更新
一级
一期需求
SNPD_LSQ_SSS_07
BTC物流物流详情调用
一级
一期需求
SNPD_LSQ_SSS_08
CIC物流物流详情调用
一级
一期需求
后台配置
SNPD_LSQ_SSS_09
后台配置
一级
一期需求
快递100接入服务
SNPD_LSQ_SSS_10
快递100查询与推送运单信息
一级
二期需求
物流详情查询
SNPD_LSQ_SSS_11
作业系统查询状态明细
一级
LES拆分需求

3. 系统功能需求
3.1 状态信息接受推送
3.1.1 非采购类状态信息接受
3.1.1.1 需求编号LSQ_DDZF_MDZF_0001
说明：
//功能的业务介绍和业务背景

此处的需求编号，在一个系统中必现唯一存在并且最后4位递增，规则：系统名_模块名_子功能名_序列号，如LSQ_DDZF_MDZF_0001： 系统名最长保存4位，模块名/子功能名最长4位，序列号最长4位不够4位补0比如0001，假如是优化需求，需求编号不变，新增需求需求编号增长；
3.1.1.2 解决流程和约束条件
说明：此处是放上面功能的业务流程图和功能的业务逻辑约束条件
流程图：

说明：假如流程图比较大或比较多，请以单独的附件提供

约束
#
环节
逻辑
10
功能入参确认
1. 入参确认
1) 用户名；
2) 密码

2
校验解决
1. 校验：用户名在数据库中唯一且存在；
1) 成立，继续后续校验
2) 不成立，返回报错：请输入对的的用户名密码
2. 校验：安全性：
1) 安全性不通过，则提醒该登录也许存在安全隐患，请重新访问；
2) 安全性通过，则继续下面，
3
订单解决

4
组织结果反馈
1. 所有校验通过：
1) 提醒：登录成功，数据库更新最后登录时间；
2) 可进入系统进行后续操作

3.1.1.3 页面原型
说明：
N/A，系统后台功能无页面
有页面请截低保真的图，图片要能覆盖所描述的功能，以及页面访问途径。

3.1.1.4 数据说明
说明：
N/A，系统后台功能无页面
假如有页面校验请在此处用列表的形式说明各个页面各个控件的校验规则
XX功能
字段名
数据类型
页面长度
小数位
说明
用户名
字符
10

非空，必须涉及大小写字母、字符，不可输入中文
密码
字符
10

非空，必须涉及大小写字母、字符、特殊字符

3.1.1.5 功能需求描述
说明：
1）功能描述，需要做到语言准确，结构清楚，须涉及从用户角度和业务角度描述功能和业务场景；要尽也许少地从系统逻辑角度去撰写需求，多写业务逻辑以免干扰开发的最优设计。在需求中明确业务接口。
2）版本优化，假如是优化功能采用修订模式在涉及到的所有原文档（涉及需求说明书、流程图、接口文档）上进行修改并标注，需求说明书需相应需求编号章节进行修改，这样便于研发和测试了解原功能，以便快速了解优化的业务判断回归场景。产品还需说明优化此功能的业务场景以及建议优化功能涉及相关使用场景。（0522版本）
特别说明：修改的功能会影响系统对外提供的接口，需要这些接口的使用方对接口进行验证，并确认接口的变更
登录
1） 针对登录功能，需要做安全性校验，实行https的方式，并且登录密码以*显示，在日记打印中也以*展示；
2） 登录功能，登录调用API 接口INTERFACE_LSQ_LOGIN_0001实现登录，需要保证数据传递的安全性。
状态接受
LSQ系统接受状态信息，作如下解决：

数据类型
长度
小数位
说明
ID
字符
32

主键，系统自动生成的流水号
外部流水号
字符
32

外部传的流水号
外部系统
字符
10

当前外部订单相应的“外部系统”
任务单号
字符
20

当前外部订单相应的“外部订单编码”
物流订单号
字符
30

通过卖家ID查询客户信息匹配表，结果为查询到的卖家ID相应的“客户编码”
订单属性
字符
10

当前外部订单相应的“苏宁业务类型”
订单客户
字符
10

若业务类型为“C019”，则默认为“ZVIN”入仓
前置任务单系统
字符
10

在接受4PS销退入库单时，若orderFlag订单标记带有9，则在下传装运条件时，传输“01”自营，其他则按照原有逻辑传“06”第三方
服务大类
字符
20

固定赋值“L01仓储”
收入项
字符
20

固定赋值“ L0101存量”
服务产品
字符
4

固定赋值“ L010101仓库保管”
服务细节
字符
4

根据物流中心匹配zlmt026，取属性，若属性=MD，则服务细节= L01010101门店库存，否则为L01010102中心仓库存
商品属性
字符
60

用物料号匹配商品主数据，取商品属性（当用计费明细的物料号matnr时，一方面做取前置0 ，然后再去关联MDM商品主数据）
件数
字符
10

回算表的lfimg
网点描述
字符
60

固定赋值“L01仓储”
实际交货数量
数值
13

固定赋值“ L0101存量”
数量单位
字符
3

固定赋值“ L010101仓库保管”
排程日期时间
字符
14

若订单相应的基本信息的“预期送达开始时间”为空，且当前日期时间比当前日期时间18:00:00早，则为当前日期，否则为当前日期+1天；
若订单相应的基本信息“预期送达开始时间”不为空，则取该时间中的日期，格式为YYYY-MM-DD
接受日期时间
字符
19

系统当前日期

3.1.1.6 接口说明
说明：假如字段少可直接把接口列表贴这里，接口模板见下表必须涉及深度和返回消息，假如有不同返回码也需要一并定义。每个接口在需求文档中撰写一个编号，在系统中唯一，以便附件中能快速找到相应的接口，便于定期维护，接口编号：规则一个系统唯一：INTERFACE_系统名_一级模块名_编号递增
产品定义的接口只需提供到中文字段名、长度、是否必须，校验说明即可。
API 接口INTERFACE_LSQ_LOGIN_0001
深度
名称
描述
类型长度
是否必输
说明
1
INPUT
请求输入

2
ITEM

3
username
用户名
CHAR(10)
必输
不可为空
3
Password
密码
CHAR(10)
必输
不可为空
3
token
盾牌
CHAR(30)
必输
不可为空
1
OUTPUT
请求输出

2
username
用户名
CHAR(30)
必输

2
returnCode
结果状态
CHAR(10)
必输
0-成功，1-失败
2
Message
文本描述
CHAR(255)

接受成功/接受失败
returnCode返回码说明：
快递公司验证
returnCode
Message
快递100需要做的操作
LSQ订阅成功
200
成功

LSQ数据验证失败
400
数据不完整
补充数据，重新订阅
LSQ格式验证失败
500
请求格式错误
程序有问题，需要调整
本地服务器错误
501
服务器错误
30分钟后尝试
LSQ订阅日记已存在
502
反复订阅
理解为订阅成功
LAPI校验KEY错误
503
验证署名失败
使用对的的KEY
LSQ未查到相应物流单号
504
单号错误
更正单号
LSQ未查到相应物流单号
507
查询异常

状态接受接口INTERFACE_LSQ_STATUS_0001
由于字段较多见附件，每个接口在需求文档中撰写一个编号，规则一个系统唯一：INTERFACE_系统名_一级模块名_编号递增
该功能解决过程中会调用以下接口（见附件）：
接口编号
接口名称
原系统
目的系统
场景
INTERFACE_LSQ_LOGIN_0001
API登录接口
LSQ
API
解决成功，登录成功
INTERFACE_LSQ_STATUS_0001
状态信息同步LSQ
LOS/TMS/LWMS
LSQ
MQ信息解决成功记录到LSQ系统

3.1.1.7 其它说明
说明：可以把性能需求或者安全性，稳定性需求，页面浏览器兼容性需求等等放此处
3.1.2 状态信息发送
3.1.2.1 需求编号LSQ_DDZF_MDZF_0002

3.1.2.2 解决流程和约束条件
#
环节
逻辑
10
订单判断
1. 使用订单行号查询本地是否存在相应的订单行
1) 存在，继续后续判断；
2) 不存在，进入后续校验；
2. 判断订单行状态：
1) 假如订单行状态10-已提交，12-订单异常，进入后续校验；
2) 假如订单行状态大于等于20-解决成功，直接返回成功；
3. 判断订单是否存在后续退货订单；
1) 存在，返回报错：该订单状态准确，不可进行支付
2) 不存在，进入后续校验；
4. 判断订单支付金额是否对的，判断等式：行项目销售额+运费+服务费=支付金额之和+使用积分金额+经理卡金额，是否成立；
1) 成立，继续后续解决
2) 不成立：支付金额不对的，请检查后重新输入；
20
订单支付信息解决
1. 订单行支付状态设立：将所有订单行状态都置为：30-已支付；
2. 保存新增的支付信息；
3. 覆盖本地已有的优惠单信息；
4. 冻结标志设立：假如订单支付信息中具有：4001（支票支付），则将订单行冻结标记置为：D2-支票冻结；
5. 支付确认标记设立：门店订单【支付确认开关】为打开状态时，对于满足以下条件的订单行项目，将订单行支付确认标记置为：0-未确认支付；
1) 分销渠道为10-零售、20-代购，
2) 且来源系统为POS。
3) SAP订单类型为ZOR-标准订单、IDOC、Z01、ZGF。
4) 装运条件为01、14。
5) 先销后采标记不为5。
20
订单支付信息解决
1. 调用【公共规则-资源解决】功能；
1) 成功，将订单行状态置为：20-已解决，订单头状态：20-已解决；
2) 失败，将订单行状态置为：12-解决失败，订单头状态置为：12-解决失败；
30
组织结果反馈
1. 根据解决结果，组织结果反馈；
40
实时同步
1. OMSD全量：调用功能【公共功能-订单全量信息分发OMSD】
2. OMSQ全量：调用功能【公共功能-订单全量信息分发OMSQ】
50
异步同步
1. BI-大数据系统：调用【公共规则-】
2. PMS-价格中心系统：调用【公共规则-】
3. SPCS-云商卡系统：调用【公共规则-】
4. BUDS-财务系统：调用【公共规则】
60
日记打印
打日记：OMS订单号，OMS行订单号，订单支付完毕时间，预计出库时间，盼望送达时间 ，支付订单创建时间,SAP订单类型，先销后采标记，订单来源，下单时间，渠道，行项目类别，分次发货标记，支付类型（04门店支付），支付确认标记，日记阶段：02（01提交，02支付，03支付确认，04还欠款）id（10000055）

3.1.2.3 页面原型
N/A，系统后台功能无页面
3.1.2.4 数据说明
N/A，系统后台功能无页面

3.1.2.5 功能需求描述
针对以下业务场景，前端系统通过该功能完毕门店订单收款解决；
#
场景
接口
01
电器门店零售订单收银台全款支付解决
POS-OMS-008 操作码：D
02
电器门店对公云商卡订单收银台全款支付解决
POS-OMS-008 操作码：D

3.1.2.6 接口说明
3.1.2.7 其它说明
3.2 最新站点查询服务
3.2.1 最新站点查询
3.2.1.1 需求编号LSQ_DDTJ_DDTJ_0003
3.2.1.2 解决流程和约束条件
接受到前端系统提交的订单后，进行订单提交相关解决，具体逻辑如下：

具体环节逻辑如下：
#
环节
逻辑
10
提交订单
前端系统通过以下接口提交订单，且订单类型为A时，进入该功能：
Ø SPOS-OMS-001
Ø B2C-OMS-001
Ø ALL-OMS-001
Ø ALL-OMS-016
20
进行订单合法性校验
根据接口传入订单信息进行合法性校验：
1. 订单反复性校验
2. 若接口输入的接单模式为1或者3，则进行订单金额校验
1) 判断行优惠单金额是否对的。校验公式：行优惠单金额 = 行优惠单明细金额汇总：
a) 若不对的，则返回报错：订单行“前端系统行项目号“的优惠单总金额与优惠单明细不一致。
b) 否则进行一下步判断
2) 若订单提交接口为ALL-OMS-001，则需判断行销售额是否对的，校验公式：行销售额 = 销售价 * 数量：
a) 若不对的，则返回报错：订单行“前端系统行项目号“的销售额”XX”不等于销售价格”XX”*数量”XX”。
b) 否则进行一下步判断
3) 若订单提交接口为ALL-OMS-001，则需判断行应付金额是否与支付明细汇总金额一致，校验公式：行项目销售额+运费+服务费=支付金额之和+使用积分数金额+经理卡金额：
a) 若不对的，则返回报错：订单行“前端系统行项目号“的总支付金额与应付金额不一致。
b) 否则进行一下步判断
4) 若订单提交接口为B2C-OMS-001，则需判断行应付金额是否与支付明细汇总金额一致，校验公式：销售价*数量-经理卡金额+运费+行税额+服务费=支付金额之和：
a) 若不对的，则返回报错：订单行“前端系统行项目号“的总支付金额与应付金额不一致。
b) 否则进行一下步判断
3. 根据校验结果：
1) 若以上所有校验通过，则进入下一步“30-生成或更新订单信息”环节
2) 若以上任意校验失败，则进入“50-返回解决结果”环节
30
生成或更新订单信息
根据接口传入的订单信息创建订单信息或全量更新以下信息：
1. 若是创建订单，则根据单号规则生成订单号和订单行号
2. 进行订单状态设立
1) 进行订单行总状态设立，具体逻辑见“表-订单行总状态（IS）设立逻辑”
2) 进行订单行支付状态设立，具体逻辑见“表-订单行支付状态（IP）设立逻辑”
3) 进行订单行发票状态设立，默认设立为IV=10
4) 进行订单头总状态设立
3. 进行订单特殊标记设立
1) 进行订单行冻结标记设立
a) 若分销渠道=30，且订单来源为CRM，则设立分次发货标记为D3-对公订单未付款冻结
b) 否则，如订单支付方式中具有4001：支票支付，则设立分次发货标记为：D2-支票交货冻结
c) 否则，对于其他场景设立分次发货标记为A-只允许一次发货
2) 进行订单行大客户付款类型设立。满足以下所有条件，设立大客户付款类型为1-确认欠款：
a) 订单来源为SPCS
b) 行项目类别为16-云商卡订单
c) 接单模式为1
d) 支付方式含9005
3) 进行订单行是否需要发票设立
4. 根据接口传入订单信息保存订单基本信息
5. 根据接口传入订单扩展信息保存订单相关扩展信息
1) 若订单行类别= 10，且接口中存在服务商品，则需要保存服务扩展信息
2) 若订单行类别=11，则需要保存延保扩展信息
3) 若订单行类别=12，则需要保存赠品扩展信息
4) 若订单行类别=13，则需要保存虚拟商品信息
5) 若订单行类别=14，则需要保存合约扩展信息
6) 若订单行类别=16，则需要保存云商卡扩展信息
7) 若订单行类别=20，电子书无扩展信息，无需保存
8) 若订单行类别=22，则需要保存独立服务扩展信息
9) 若订单行类别=24，则需要保存运费险扩展信息
6. 若接口传入的支付方式含9002-货到付款、9003-融合支付，则需要保存还欠款信息
7. 订单信息保存后，根据接单模式：
1) 若订单保存成功，且接口传入的接单模式为1，则进入下一步“40-订单调度解决”；
2) 若订单保存成功，且若接口传入的接单模式为2、3，则进入下一步“50-返回解决结果”
3) 若订单保存失败，则直接进入下一步“50-返回解决结果”
40
进行订单解决调度
调用功能【OMS_ZYCL_ZYCL_001-资源解决（老流程）】进行解决
50
返回解决结果
1. 根据30、40环节的解决结果，返回相应信息
1) 若解决失败，则返回前端解决失败
2) 若解决成功，则返回前端解决成功
2. 进入下一步“记录日记信息”环节
60
记录日记信息
1. 若为。。。则：
2.
3. 根据30、40环节的解决结果
1) 若解决失败，则结束本次提交流程
2) 若解决成功，则继续进行后续 “70-保存或更新订单信息”、“80-异步分发订单”和“90-保存待分发信息”环节
70
保存或更新订单信息
1. 保存BUDS信息
1) 满足以下所有条件，保存该订单行支付明细到BUDS支付明细信息中
a) 订单行项目类别不为16
b) 订单行支付中存在9001-香港欠款、9002-货到付款、或者9005-对公欠款
2. 设立订单实时解决标记。
1) 满足以下所有条件设立实时解决标记为Y
a) 行项目类别为10-实体、12-赠品
b) “装运条件为空-自提、17-物流门店库自提、20-物流门店库自提”或者“装运条件为02-门店自提且SAP订单类型=IDOC”
c) 分次发货标记为A-只允许一次发货、或者D2-支票冻结
d) 订单行状态>=20
e) 订单类型不为C-退货订单
f) 先销后采标记为空、或者0
2) 若SAP订单类型为ZSIA且为10渠道（门店互联开卡订单），则设立实时解决标记为Y
3) 其他情况，不设立实时解决标记
3. 保存订单展示价信息：
1) 若调用接口为B2C-OMS-001，则需要保存订单展示价：
a) 若接口传入的展示价（displayPrice）有值，则保存该字段的值为订单展示价
b) 若接口传入的展示价（displayPrice）无值，则保存订单展示价为接口传入的销售价（price）- 《发票虚增价》
2) 其他调用接口不进行解决
80
异步分发订单
1. 订单行实时分发OMSD
1) 满足以下所有条件的订单实时分发OMSD，通过接口（OMS-OMSD-001）
a) 订单行总状态为20-已解决、40-已发货、或者60-已完毕
b) 订单行项目类别<>13-礼品卡
c) 分次发货标记为A-只允许一次发货、或者D2-支票冻结
d) 订单行支付确认标记为空、1-已支付确认
2. 订单行实时分发OMSQ
1) 满足以下所有条件的订单实时分发OMSQ，通过接口（OMS-OMSQ-001）
90
保存待分发信息
1. 满足以下条件保存待分发已支付订单信息到BI，，通过接口（OMS-BI-002）
1) 订单类型为A-一般销售订单、B-虚拟订单
2) 行项目类别为：
3) 订单渠道为：
4) 订单行总状态>=20-已解决
5) 分次发货标记不为D3-对公支付
2. 满足以下条件保存待分发未支付订单信息到BI，通过接口（OMS-BI-003）
1)
3. 满足以下条件保存待分发已支付订单信息到PMS，通过接口（OMS-PMS-002）
1) 订单类型为A-一般销售订单
2) 订单行项目类别为：
3) 订单行先销后采标记为：0、1、2、3、4、6、或者9
4) 订单渠道为：10、20、30（且订单来源为CRM）、50、或者60
5) 订单行总状态>=20-已解决
6) 订单行分次发货标记不为D3-对公支付
4. 满足以下条件保存待分发已支付订单信息到POS，通过接口（OMS-POS-0??）
5. 保存待分发已支付订单信息到SAP
1) 满足以下条件保存待分发IDOC订单信息，通过接口（OMS-SAP-022）
a) 订单行SAP订单类型=IDOC
b) 订单行总状态（IS）>=20
c) 订单方向=1-正向订单
2) 满足以下条件保存待分发合约机订单信息，通过接口（OMS-SAP-011）
a) 订单行SAP订单类型=ZSIM
b) 订单行总状态（IS）>=20
c) 订单方向=1-正向订单
d) 订单行项目类别=14-合约机
3) 满足以下条件保存待分发互联订单信息，通过接口（OMS-SAP-036）
a) 订单行SAP订单类型为：ZSIA、或者ZSIB
b) 订单行总状态（IS）>=20
c) 订单方向=1-正向订单
d) 订单行项目类别=14-合约机
4) 满足以下条件保存待分发超市订单信息，通过接口（OMS-SAP-040）
a) 订单行SAP订单类型：CSLY、或者YDDS
b) 订单行先销后采标记为：8
c) 订单行总状态（IS）>=20
d) 订单方向=1-正向订单
5) 满足以下条件保存待分发SWL、联营厂送订单信息，通过接口（OMS-SAP-041）
a) 订单行先销后采标记为：7、或者9
b) 订单行总状态（IS）>=20
c) 订单方向=1-正向订单
6) 满足以下条件保存待分发IDOC订单（3C类）信息，通过接口（OMS-SAP-038）
a) 订单行SAP订单类型=IDOC
b) 订单行总状态（IS）>=20
c) 订单方向=1-正向订单
7) 满足以下条件保存待分发账期支付订单信息，通过接口（OMS-SAP-053）
a) 订单渠道为：10、20、30、40、或者50
b) 订单行支付状态（IP）=30
c) 订单行支付明细中包含9102支付方式
8) 满足以下条件保存待分发合约机手机行结算信息，通过接口（OMS-SAP-032）
a) 订单行项目类别为：10-实体
b) 订单行存在《合约关联关系》
c) 订单行关联的合约行的SAP订单类型为：IDOC或者ZSIM
d) 订单行总状态（IS）>=20
9) 满足以下条件保存待分发合约机合约行结算信息，通过接口（OMS-SAP-033）
a) 订单行项目类别为：14-合约机
b) 订单行SAP订单类型=IDOC、或者ZSIM
c) 订单行总状态（IS）>=20
10) 满足以下条件保存待分发C店订单信息，通过接口（OMS-SAP-037）
a) 订单行总状态（IS）=20
b) 订单行先销后采标记为：5
c) 订单渠道为：50
d) 订单行支付明细中包含支付方式5002、或者6904
11) 满足以下条件保存待分发商转赠订单信息，通过接口（OMS-SAP-042）
a) 订单行项目类别为：10-实体、或者12-赠品
b) 订单行为《商转赠订单》
c) 订单行总状态（IS）=20
6. 满足以下条件保存待返积分信息到CMF，通过接口（OMS-CMF-006/OMS-CMF-007）
1) IS>=20 已完毕；
2) IP=30 已支付；
3) 接单模式<>3-一步式不待解决
4) 来源系统不为BSS、SAP、TMALL、SDIPA
5) 行项目类别为：10、11、12、14；
6) 业务类型不为：配置数据

7. 满足以下条件保存待返券信息到SPES，通过接口（OMS-SPES-0??）
8. 满足以下条件保存待分发已支付订单信息到IPS，通过接口（OMS-IPS-001）
1) 订单行先销后采标记为：空、0、1、2、3、4、6、7、或者9
2) 订单行总状态>=20-已解决
3) 订单行类别为：10-实体、11-延保、12-赠品、或者14-合约
4) 订单行发票类型为：01、02（是否需要打印发票<>“N”）、03、或者04
5) 订单渠道为：40（订单来源为TMALL）、50、或者60
9. 保存待分发订单信息到BUDS
1) 满足以下条件保存待分发云商卡订单信息，通过接口（OMS-BUDS-055）
a) 订单行项目类别为：16-云商卡
b) 订单行总状态（IS）=20
2) 满足以下条件保存待分发医保卡订单信息，通过接口（OMS-BUDS-055）
a) 订单行为《医保卡订单》
b) 订单行总状态（IS）>=20

3.2.1.3 页面原型
N/A，系统后台功能无页面
3.2.1.4 数据说明
N/A，系统后台功能无页面

3.2.1.5 功能需求描述
针对以下业务场景，前端系统提交订单至OMS，OMS进行订单提交的合法校验，订单提交的资源解决以及订单保存，并根据相应的场景，判断是否调用后续解决。
* 接单模式：1-一步式需解决资源；2-两步式需解决资源；3-一步式无需解决资源
3.2.1.6 接口说明
该功能解决过程中会调用以下接口：
接口编号
接口名称
目的系统
场景
OMS-OMSD-001
订单信息同步OMSD
OMSD
订单解决成功后，同步订单信息到OMSD
OMS-OMSQ-001
订单信息同步OMSQ
OMSQ
订单提交或者解决成功后，同步订单信息到OMSQ
3.2.1.7 其它说明
表-订单行总状态（IS）设立逻辑
接单模式
行项目类别
状态值
1,2
ALL
10
3
10,11,12,14,15,16,20,22,24
20
3
13
60
表-订单行支付状态（IP）设立逻辑
接单模式
分销渠道
订单来源
支付方式
状态值
1
30
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、9003、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. 系统非功能需求
3.3 性能需求
请根据下表中性能指标项定义性能需求，如不能满足可在其他项中补充。
业务
业务量
峰值业务量
用户数
响应时间
其他
修改时间
订单管理
24小时1000万
24小时2023万
前台系统必需。访问用户数指单位时间内访问系统的用户总数。
响应时间指完毕一个交互的总时长，从客户端发起请求开始，到客户端接受完服务器响应结果结束。假如系统中具有多种类型的交互，可以考虑分类设立响应时间需求。

2023-05-18
订单查询功能接口
24小时1000万
24小时2023万
10万用户访问
一般响应时间我们是建议透传的200ms，其他的500ms内

2023-05-18
说明：//假如优化版本对原基础数据有影响，需要在需求说明书中使用修订模式明确新指标
3.4 安全性需求
安全性
标题
内容
安全性级别
登录
所有登录需要保证安全性性，秘密不能明文传输
高
支付
支付账号、秘密必须进行加密传输
高
外网对接
外网数据传输需要防止跨站点袭击
中
3.5 扩展性需求
扩展性
可扩展性
可扩展性指假如未来业务需求增长，系统架构能否通过最小代价改变支持增长的能力。最小代价改变如增长集群服务器数量等。该需求指方案是否需要考虑可扩展性的问题。

3.6 兼容性需求
兼容性
系统兼容性
系统需要向下兼容
页面兼容性
支持IE8\IE10|Google最新\FF最新版本浏览器

3.7 维护性需求
5. 附录