新老两套钱包逻辑，同步使用，迁移
不包括酒店收益和合伙人收益，但是可能会影响到生成收益
一、C端代码及场景覆盖
二、外部调用调整：金时房客、总后台、OA、星火
三、数据迁移，及兼容处理
- 一、C端代码及场景覆盖
- 1. 用户虚拟金额管理
- 2. 新代码覆盖旧场景
- 存时、存时豆
- 现金钱包
- 订单核销后：
- 用户推荐人：多级
- 酒店推荐人：多级
- 区域代理商推荐人：省、市、区县
- 用户金石
- 核销后给下单人赠金石：身份，推广员、普通用户
- 每日签到
- 绑定推荐人(用户注册或绑定推荐人)
- 3. 新增场景或由其它系统转入
- 现金钱包（订单核销后）
- 活动房间返现 8.88 双倍返（下单人）
- 分存时兑换（下单人）
- 提现、提现驳回返还
- 金石
- 酒店签约后给推荐人发金石
- 总后台派发
- 星火订单奖励
- 星火注册和绑定推荐人
- 存时、存豆
- 4. 植入原逻辑触发位置
- 订单支付，订单退款
- 提现，提现驳回
- 签到，奖池奖励
- 离店核销订单奖励
- 用户注册，绑定推荐人
- 酒店签约
- 5. 提供新接口供外部调用
- App、客户端调用
- 我的存时豆、明细（存豆罐）
- 我的金石及明细
- 我的钱包及明细
- 订单兑换存时、分时
- 新签到、日历接口
- 新订单支付接口
- 收银台接口
- 支付宝支付
- 小程序支付
- 微信支付
- 存时豆支付
- 微信存时豆组合支付
- 支付宝存时豆组合支付
- 小程序存时豆组合支付
- 酒店信息
- 总后台、OA调用
- 燎原计划（星火商城）调用
- 8. 重写订单奖励
- 区域代理推荐人小额返佣累加到分后实时发放
- 重写订单推荐人返佣
- 返佣 按子订单仅金额支付的总价算返佣金额
- 二、外部调用处理
- 星火修改
- 推广员签到额外奖励存时、存时豆（奖池）
- 直推推广员奖励星火订单7天 奖励存时、存时豆；改为请求jsfk接口派发 【无】
- 注册、绑定推荐人发放金石
- 会议签到奖励金石 【废弃】
- 订单金石奖励（推荐人）
- 注册或绑定发金石（推荐人）
- 总后台修改
- 发放存时、存豆
- 发放金石
- 提现驳回 返还金额
- 酒店签约发放金石、上传合同
- 更新推荐关系，整合到jsfk api
- 其它明细log列表
- 获取用户当前、金石、余额、存时存豆
- OA修改
- OA新增钱包明细接口
- OA新增07-04 新增
- 用户列表
- 用户账户
- 删除用户
- 派发、扣除 存时和存时豆
- 派发、扣除 用户收益
- 派发、扣除 金石
- H5我的存时豆 07-05新增
- 金时房客07-08新增
- 提现限额
- 提现：支付宝、微信 两种模式，立即提现和审核后提现
- 总后台、金时房客07-12修改和新增
- 三、数据迁移，及兼容处理
- 增加视图接替原moneybag表（最小化修改，前端最小影响）
- 星火读的场景，例如 星火后台 金石管理 金石记录（建议 金石管理 移动到oa后台），积分不变
- app、小程序读场景，用户钱包，金石等(前端不动)
- 迁移脚本，上线后，旧数据合并一次派发到新表
特别注意：迁移和过渡期
迁移是服务端夜间上线一次性迁移，将老的用户钱包数据
指一些由客户端操作发放的接口，由于客户端需要审核时间，导致服务器代码和客户端不匹配，会造成数据不一致的情况
- 签到接口，获取金时和存时豆，此接口在老版接口里兼容新版的签到
- 上线前处理完历史提现审批
其它备注：
酒店钱包不在本次调整范围内，奖励保持原有逻辑
h5我的存时豆 页面换链接
detail 或 child 是异步生成 可能会影响奖励发放
酒店钱包锁客第一次不发奖励
OA酒店签署完合同 调用 jsfk发放金石 [已上线]
星火小程序去掉金石
- 订单详情的分时存时
- 优惠券