存管系统小结(改造):

一.全资管理财系统存管接入:

    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