一.全资管理财系统存管接入:
1.总体思路:
业务系统现已实现标准版(公司结算系统)，存管版(民泰银行存管)两种模式的存管系统，系统通过配置文件的形式识别当前的交易模式。----代码在一个分支中开发，实现多配置切换。
2.功能页面:
功能页面影响主要有
2.1. 功能菜单不同，例如标准版有些菜单有，存管有些没有
2.2. 页面元素不同，比如有些按钮在标准版可以展示，在存管中不展示
2.3. 页面交互，数据项的控制不同，比如标准支持T+0，存管支持T+1
对于第1,2两项:
可通过两套菜单实现，前端只需识别当前的交易模式，并获取对应的菜单，交互图如下:
对于第3:
可采用模板页面的方式，将同一功能的差异化实现，分写到两个或多个模板页面中，加载页面时按需加载
loadModal: function (selector, url, title, callback){$.ajax({"url" : "pages/"+url,method : "get","async" : false,success : function(html){$(selector).html(html);var _title = title ? title : $(selector + " .modal-title").html();$(selector + " .modal").modal({backdrop: 'static'}).find('.modal-title').html(_title);callback();}});},
3.接口方案:
目前系统中接口分三类:
3.1 前端用户使用的接口(app端)
3.2 后台管理系统所需的接口
3.3 接收结算回调通知的接口
本次存管适配中，三类接口都将有所调整，考虑到兼容性，对于存管的适配，在接口前添加depository的标识
例如:修改密码:
标准版:POST mimosa/client/investor/baseaccount/editpaypwd
存管版:POST mimosa/depository/client/investor/baseaccount/editpaypwd
4.代码结构:
在后台业务代码中，对需要差异化实现的功能，抽提出公共的接口，采用多实现类的方式来实现标准版和存管版的不同逻辑处理
如下:
此实现类在实例化的时候，通过springboot的自动装配@Condition实现选择性实例化，如下:
#application.properties配置项
trade.mode=depository/*** Description：交易模式匹配器-存管版* @author ddyin* @date 2017/12/7*/
public class TradeModeDepositoryCondition implements Condition{@Overridepublic boolean matches(ConditionContext conditionContext, AnnotatedTypeMetadata annotatedTypeMetadata) {return conditionContext.getEnvironment().getProperty("trade.mode").contains("depository");}
}/*** Description：交易模式匹配器-标准版** @author ddyin* @date 2017/12/7*/
public class TradeModeStandardCondition implements Condition{@Overridepublic boolean matches(ConditionContext conditionContext, AnnotatedTypeMetadata annotatedTypeMetadata) {return conditionContext.getEnvironment().getProperty("trade.mode").contains("standard");}
}public interface UserInterface {public void say();
}/*** Description：用户服务-标准版实现** @author ddyin* @date 2017/12/7*/
@Service
@Conditional(value = TradeModeStandardCondition.class)
public class UserSettlementImpl implements UserInterface{@Overridepublic void say() {System.out.println("11111111");}
}/*** Description：用户服务-存管版实现** @author ddyin* @date 2017/12/7*/
@Service
@Conditional(value = TradeModeDepositoryCondition.class)
public class UserDepositoryImpl implements UserInterface{@Overridepublic void say() {System.out.println("2222222");}
}
5.交互流程；
由于对接存管后，交易密码的存储和校验需要跳转到存管系统页面来操作，且交易的提交需要传递密码校验通过后的密文。
故，涉及交易密码的功能，在系统交互上会增加交互步骤，以申购为例，系统通讯图如下:
5.1 第三步申购信息的缓存，生成一个UUID作为key，请求参数作为value存入redis中
5.2 第四步传递的callbackurl带上key，业务系统提供统一的密码交易通知接口
5.3 第八步获取传回的key，从redis取请求参数(即请求参数存redis)
6.功能设计:
6.1 实名绑卡
需要跳转存管页面的功能包含:
实名绑卡，交易密码修改，交易密码重置，交易密码确认(跟随业务操作跳转)
以下跳转是需要输入交易密码:
充值，体现，申购，赎回，还款(发行人和融资人)
以绑卡为例:
以申购为例描述序列流程:
6.2 标的的建立和标的的结标:
在业务流程上通过埋点的方式调用存管接口，无设计上的变更。
6.2.1 标的的建立----埋点在产品审核通过
6.2.2 标的的结标----埋点在产品清算状态变更
6.3 轧差:
6.3.1 将活期和定期分开轧差处理
活期轧差继续使用t_money_platform_publisher_offset以时间批次，产品维度进行轧差
定期轧差继续使用t_money_platform_publisher_product_offset以产品编号维度轧差处理
6.3.2 份额确认结算合并之份额确认结算---流程如下:
6.3.3 份额确认结算合并之份额确认不退款
7.接口设计:
7.1 实名绑卡:
请求路径：/mimosa/depository/client/investor/baseaccount/bindcardapply
7.1.1 请求
| 参数 | 参数名称 | 类型 | 参数说明 | 是否可空 | 样例 |
| realName | 用户名 | String(32) | 非空 | 48293819282382 | |
| certificateNo | 身份证号 | String(32) | 非空 | 410101199109091234 | |
| bankName | 银行名称 | String(32) | 非空 | 中国银行 | |
| cardNo | 银行卡号 | String(32) | 非空 | 234589987653456 | |
| phone | 手机号 | String(32) | 非空 | 15029203949 | |
| bankBranchNo | 开户行行号 | String(32) | 非空 | ||
| bankBranchName | 开户行名称 | String(50) | 非空 | ||
| callbackUrl | 页面回跳URL | String(1000) | 非空 |
7.1.2 响应
| 参数 | 参数名称 | 类型 | 参数说明 | 是否可空 | 样例 |
| errorCode | 错误码 | String(32) | 非空 | ||
| errorMessage | 错误描述 | String(1000) | 可空 | ||
| redirectUrl | 跳转URL | String(1000) | 非空 | http://ip/xxx.do |
7.2 修改交易密码:
请求路径：/mimosa/depository/client/investor/baseaccount/editpaypwd
7.2.1 请求
| 参数 | 参数名称 | 类型 | 参数说明 | 是否可空 | 样例 |
| callbackUrl | 页面回跳URL | String(1000) | 非空 |
7.2.2 响应
| 参数 | 参数名称 | 类型 | 参数说明 | 是否可空 | 样例 |
| errorCode | 错误码 | String(32) | 非空 | ||
| errorMessage | 错误描述 | String(1000) | 可空 | ||
| redirectUrl | 跳转URL | String(1000) | 非空 | http://ip/xxx.do |
7.3 重置交易密码:
请求路径：/mimosa/depository/client/investor/baseaccount/forgetpaypwd
7.3.1 请求
| 参数 | 参数名称 | 类型 | 参数说明 | 是否可空 | 样例 |
| callbackUrl | 页面回跳URL | String(1000) | 非空 |
7.3.2 响应
| 参数 | 参数名称 | 类型 | 参数说明 | 是否可空 | 样例 |
| errorCode | 错误码 | String(32) | 非空 | ||
| errorMessage | 错误描述 | String(1000) | 可空 | ||
| redirectUrl | 跳转URL | String(1000) | 非空 | http://ip/xxx.do |
7.4 申购:
请求路径：/mimosa/depository/client/tradeorder/invest
7.4.1 请求
| 参数 | 参数名称 | 类型 | 参数说明 | 是否可空 | 样例 |
| productOid | 产品oid | String(32) | 非空 | 3ef6a51a78e84cb588a78a478a74d008 | |
| moneyVolume | 投资额度 | String(32) | 非空 | 3000 | |
| cid | 渠道cId | String(32) | 非空 | 123456 | |
| ckey | 渠道ckey | String(32) | 非空 | 123456 | |
| couponId | 卡券OId | String(32) | 非空 | 3ef6a51a78e84cb588a78a478a74d008 | |
| couponType | 卡券类型 | String(32) | 非空 | ||
| couponDeductibleAmount | 卡券优惠金额 | String(32) | 非空 | 200 | |
| couponAmount | 卡券金额 | String(32) | 非空 | 200 | |
| payAmouont | 实际支付金额 | String(32) | 非空 | 2800 |
7.4.2 响应
| 参数 | 参数名称 | 类型 | 参数说明 | 是否可空 | 样例 |
| errorCode | 错误码 | String(32) | 非空 | ||
| errorMessage | 错误描述 | String(1000) | 可空 | ||
| redirectUrl | 跳转URL | String(1000) | 非空 | http://ip/xxx.do |
7.5 赎回:
请求路径：/mimosa/depository/client/tradeorder/redeem
7.5.1 请求
| 参数 | 参数名称 | 类型 | 参数说明 | 是否可空 | 样例 |
| productOid | 产品oid | String(32) | 非空 | 3ef6a51a78e84cb588a78a478a74d008 | |
| orderAmount | 赎回金额 | String(32) | 非空 | 3000 | |
| cid | 渠道cid | String(32) | 非空 | 123456 | |
| ckey | 渠道ckey | String(32) | 非空 | 123456 |
7.5.2 响应
| 参数 | 参数名称 | 类型 | 参数说明 | 是否可空 | 样例 |
| errorCode | 错误码 | String(32) | 非空 | ||
| errorMessage | 错误描述 | String(1000) | 可空 | ||
| redirectUrl | 跳转URL | String(1000) | 非空 | http://ip/xxx.do |
7.6 接收存管跳转地址:
请求路径：/mimosa/depository/boot/callback
7.6.1 请求
| 参数 | 参数名称 | 类型 | 参数说明 | 是否可空 | 样例 |
| tradeCode | 交易编码 | String(32) | 非空 | invest、redeem、deposit、withdraw | |
| key | 交易标识 | String(32) | 非空 | 1h843vgf3234jgffg3234332 |
7.6.2 响应
HTML
7.7 后台查询交易模式:
请求路径：GET /mimosa/boot/config/tradeMode
7.7.1 请求
| 参数 | 参数名称 | 类型 | 参数说明 | 是否可空 | 样例 |
| 无 |
7.7.2. 响应
| 参数 | 参数名称 | 类型 | 参数说明 | 是否可空 | 样例 |
| errorCode | 错误码 | String(32) | 非空 | ||
| errorMessage | 错误描述 | String(1000) | 可空 | ||
| tradeMode | 交易模式 | String(32) | 非空 | standard标准版 depository存管版 |
二.存管兼容需求:(存管化需求)
1.总原则:
1.1 部署到存管方时，去除不适宜的部分，页面上不显示，具体查看上面文档内容
1.2 App内充值仅开放:线下充值不在我们的app功能覆盖范围内
1.3 mimosa后台给发行人充值仅开放:网银充值和线下入金确认，其中网银充值会有待核销金额问题，只影响发行人的可提现金额，普通个人投资者没有这个问题
1.4 不支持T+0产品，不支持活转定，不支持续投，T+0可通过输入0来控制，活转定和续投只需app端没有入口即可
1.5 mimosa后台添加的发行人是机构会员，app端注册的投资者天然是个人会员，机构会员不支持投资，个人会员不支持募资，在注册的时候，上传会员类型需要写死，包括绑卡走不同的流程
1.6 平台子账号涉及的事件归属：
| 子账户类型 | 事件 |
| 投资冻结子账户 | 申购； 退款（募集失败）； 放款； 充值补单； |
| 还款冻结子账户 | 赎回； 清盘赎回； 还本付息； 现金分红； 还款； 充值补单； |
| 收益子账户 | 提现（平台服务费）； 转出； 充值补单； |
| 红包子账户 | 申购（代金券）； 退款（代金券）； 转出； 充值补单； |
| 佣金子账户 | 现金红包； 赎回（体验金收益）； 还本付息（加息券收益）； 返佣； 充值补单； |
2.平台页面更改:(仅存管部署，基线仍保留原有平台逻辑)
场景：由于存管系统给平台子账户充值都是直接充值，而xx系统给基本账户充值，再转账给备付金；存管系统没有平台基本户，但有投资冻结户，还款冻结户
3.轧差逻辑变更:(轧差逻辑和流程调整到基线，存管和基线由于账户设置不同，在登账事件上会有不同，面向存管时，登账时间需要单独一套)
三.理财前端适应存管需求改造方案:
1.改造对应的原型:
https://pqdsox.axshare.com/#g=1&p=%E6%88%91%E7%9A%84__%E4%B8%89%E6%96%B9%E5%AD%98%E7%AE%A1_
2.存管方案中，充值投资前需要开设存管账户，充值提现等交易资金结算通过第三方存管机构完成。
3.存管开户流程，所需资料，对接方式需要根据三方存管要求进行配置，这里对接民泰银行
开设民泰银行账户时，存管开户，绑定银行卡，设置交易密码一起完成，原有方案任务之前的准备中的认证绑卡修改为存管开户，平台投资操作流程如下:
投资者资金资产流转如下图:
4.存管需求对理财端前端的影响主要体现在:
4.1 注册:
注册成功后的页面，准备投资按钮调整成跳转存管页面进行开户，引导注册成功用户进行开户操作。
4.2 存管开户:
存管开户有两种对接方式:
4.2.1 对接三方页面，直接跳转存管页面进行开户(民泰银行)。
4.2.2 对接存管的数据接口，在平台页面提交开户所有资料。
民泰银行选择第一种对接方式，跳转民泰银行存管开户页面，开户提交后返回平台结果页，开户成功后引导用户充值和风险测评，失败则提示失败原因，并支持用户重复开户。
根据三方存管银行接口或者平台的特殊需求，存管开户分两套模板来适应不同的客户需求，一种是上传身份证照片，一种是不需要上传身份证照片。
4.2.2.1 需上传身份证照片：存管开户时增加身份证上传页面显示，要求拍照上传身份证正反面照片，上传成功之后保存图片并进入绑卡页面，根据用户已上传身份证件OCR识别出的信息进行回显，姓名允许编辑身份证号不允许编辑
4.2.2.2 无需上传身份证照片：存管开户时不显示身份证上传页面，身份认证与绑卡一步完成，允许手动输入或图像扫描两种形式录入身份证和银行卡信息，通过相机扫描身份证和银行卡信息时只识别提取信息，不保存图像。
4.3 交易验证:
4.3.1 充值、提现、申购、赎回交易流程中，交易密码到三方存管页面进行输入，提交后返回平台页面，根据三方返回验证结果进行处理，验证通过后生成订单并根据订单处理结果则进入结果提示页，验证失败则不生成订单，增加验证失败提示页，并允许用户重新输入交易密码或重新发起交易。
4.3.2充值不再需要校验短信验证码，取消短信验证码环节，提交充值之后直接跳转至三方存管页面输入交易密码，密码验证通过后充值订单提交成功。
4.4 提现:
提现提交成功页面，提现到账时间根据对接的第三方存管机构提现到账情况进行显示，如T+0时显示1个工作日内，T+1显示2个工作日内。
4.5 设置:
我的银行卡一栏显示修改为“存管账户”，未开通存管账户时，显示“去开通”，点击进入存管开户页面；已完成存管开户时，显示“已开通”，点击进入银行卡管理页面，银行卡管理页面显示与平台存管方案一样。
存管账户多卡绑定和解绑卡的需求与平台存管一致，银行卡在解除绑定之后不影响已开通的存管账户，如需投资引导用户至绑卡流程，要求重新绑卡，不需要再走投资前准备流程，充值和提现也一样。
交易密码一栏在未开通存管账户之前默认显示“去设置”，点击进入存管开户页面。存管账户开通之后显示“重置”，点击进入存管银行对应流程页。
4.6 资产统计:
存管方案中，投资订单的份额确认和结算合并处理，对于投资者来说不存在已份额确认未结算的情况，因此原方案中记录此阶段资金的“在途资金”去掉，赎回、退款、还本付息确认成功后直接增加投资者可用余额；
投资人提现由存管银行进行处理，无需平台审核，不存在提现冻结金额，因此原方案中的“提现冻结金额”去掉，提现提交成功之后直接扣减可用余额。
总资产=可用余额+持有活期+持有定期+申请中资产
存管方案APP原型变更：https://pqdsox.axshare.com
