一、项目概述
1. 背景说明
为响应央行关于平台收付款业务规范号召,解决公司”二清“资金风险,原平台型业务(顾客订单收款需要由原代收模式调整为商家直收清分模式(顾客付款或确认收款、核销后资金直接流转到商家账户),目前公司计划与支付宝和微信合作开发商家直收清分模式(后面平台型业务订单只支持这两种支付方式),商家直收清分模式会涉及到从前端APP、订单交易、统一支付、商家入驻、合同、结算以及商家对账全流程变更。
2. 产品愿景目标
为公司平台型业务资金建立合规的清分模式
3. 涉众分析
序号 |
涉众方 |
期望与利益 |
备注 |
1 | 监管机构 | 符合国家资金合规标准,杜绝”二清“风险 |
|
2 | 平台商家 | 资金有保障、更安全,结款更及时,对账结算准确无误,减少人工操作 |
|
3 |
公司管理层 |
彻底解决资金合规问题 |
|
4 |
业务运营部门 |
彻底解决资金合规问题,避免影响商家合作以及日常运营 |
|
5 |
财务管理部 |
彻底解决资金合规问题,对账结算准确无误,减少人工操作
|
|
4. 名词解释
【二清】:不具备资金清算的机构以平台对接或者大商户接入支付机构或商业银行,留存商户结算资金,并自行开展商户资金清分结算。具体到线上平台型机构的网络支付,“二清”的表现形式就是“大商户结算”模式,即用户支付资金先划转至网络平台账户,再由网络平台结算给其平台入驻商户。这在结算过程中形成了事实上的“二清”。
5. 全局规范约束
序号 |
类别 |
规范细则 |
1 |
性能 | 分账是以订单+商品维度为基础进行拆分计算各类费用的,与订单商品行的比例为 4:1左右,预计三年后日均订单100万预估,100万*2*4 =800万数据量(一笔订单平均两个商品,一笔订单商品行四笔费用),同时考虑后续扩展,按照日均20000万数据进行设计 |
2 |
查询条件 | 涉及日期查询条件统一为从D1到D2(统一为日期,包含D1和D2) |
下拉选择可支持复选 | ||
单据号输入(包括合同号等)支持空格分隔查询多个 | ||
3 |
导出 |
除设置页面外、其它页面默认全都需要导出功能 |
涉及金额、数量等信息统一为数值格式,并保留两位小数 | ||
导出列和查询结果列保持一致 | ||
4 |
分页 | 统一分页样式,并且统一单页条数为 100、300、500、1000四种每页条数 |
5 |
确认弹框 | 所以涉及修改操作,统一弹框确认,【您已选择....确认....?】 |
6 |
页面提示 | 弹框提示 |
toast提示 | ||
当前页面提醒提示 | ||
7 |
日期选择 | 日期选择框统一为一个框,并且支持开始和结束日期选择 |
8 |
页面汇总 | 在页面底部汇总当前页面汇总金额 |
9 |
处理中加载 | 在页面相关操作后,如果展示或者处理需要一定时延、蒙层提示处理中 |
10 |
登录超时提示 | 登录超时后进行操作,弹框提示是否选择重新登录 |
11 |
记录创建及修改信息 | 所有数据记录创建人、创建时间、最后修改人、最后修改时间 |
12 |
数据表单展示窗格 | 查询结果数据表单展示高度和宽度固定,可左右或者上下拖拉 |
13 |
单据号规则 | 规则统一为【2位代码】+【YYMMDDDD】【8位序号】 |
-------------------------------------------------《未完待续》-------------------------------------------------