项目

一般

简介

新功能 #6137

开发费用结算导入-付款清单匹配功能

由 宋 姣姣 在 超过 2 年 之前添加. 更新于 超过 2 年 之前.

状态:
待开发
优先级:
紧急
指派给:
-
开始日期:
2023-03-03
计划完成日期:
% 完成:

0%

预期时间:
预约开发日期:
预计PRD完成时间:
预计PRD开始时间:
实际PRD开始时间:
实际PRD完成时间:
需求设计进度:
0%
预计UI设计开始时间:
预计UI设计结束时间:
实际UI设计开始时间:
实际UI设计结束时间:
UI设计进度:
0%
详细设计开始时间:
详细设计结束时间:
详细设计进度:
预计开发开始时间:
预计开发结束时间:
实际开发开始时间:
实际开发结束时间:
开发进度:
0%
预计测试开始时间:
预计测试结束时间:
实际测试开始时间:
实际测试结束时间:
测试进度:
0%

描述

业务场景:非垫付类业务,在我们开票前,由保司将业务清单提供给我们,我们的业务人员将清单导入系统留做支付用。进行付款阶段后,保司会提供一批需要打款的人员名单,里面包括姓名、卡号、身份证号等等。其中人员需要打款的金额从之前导入到系统里的清单去凑数,例如:张三需支付金额为3500元,则业务人员会到系统里找n个业务清单凑够3500元,将这些清单的业务员归属到张三身上,然后将这批清单提交结算单状态生成流水进行支付

问题:拿着付款金额去找清单的动作,工作量大且容易出现问题

解决方案:人员与清单的匹配过程由系统实现。在费用结算导入页面增加【付款清单匹配】选项卡,页面提供机构、导入日期范围的选择,可设置结费比例的上限且为必填项,导入模板由【序号】、【收款人姓名】、【身份证号】、【收款金额】、【收款卡号】、【开户行】、【付款凭证号】组成,用户上传Excel后,点击导入按钮即进行清单匹配动作,并将上述信息及重新计算后的佣金和比例更新到匹配成功的结算单上。其中业务员为固定业务员。

匹配逻辑:遍历收款人,根据金额遍历累加清单金额,如当前累加金额与付款金额相差20元以内,则直接将当前清单的比例及佣金重新计算,以得到累加金额与付款金额相等。如累加金额大于应付金额,则重新计算当前清单的比例及佣金。另外只要重新计算比例,则比例的上限不能超过页面上输入的比例,也不能低于4%

已知问题:
1、保费很高,比例可能很小,例如保费3000,比例是1%——此问题不考虑。监管查的话由业务人员解释,例如:核保系统较低,出险率较高所以返的少。
3、比例保持到6位基本与佣金相同,如果比例保持在4位,则佣金可能差1角;如果保留2位,则佣金可能差4元——以金额准确为主,比例可以有精度差。

附:注意执行效率问题

3.1QD支付3905-6.xls (20 KB) 3.1QD支付3905-6.xls 宋 姣姣, 2023-03-03 17:14
3.1QD支付73166.13-60.xls (30.5 KB) 3.1QD支付73166.13-60.xls 宋 姣姣, 2023-03-03 17:14
3.1QD支付103410.24-71.xls (33 KB) 3.1QD支付103410.24-71.xls 宋 姣姣, 2023-03-03 17:14
3.1QD支付301687-153.xls (49 KB) 3.1QD支付301687-153.xls 宋 姣姣, 2023-03-03 17:14
车险-橙柿云.xls (3.46 MB) 车险-橙柿云.xls 宋 姣姣, 2023-03-03 17:14

历史记录

#1 由 宋 姣姣 更新于 超过 2 年 之前

业务清单及收款人清单见附件

#2 由 宋 姣姣 更新于 超过 2 年 之前

  • 状态需求待设计 变更为 需求设计中

上述的固定用户即每个机构的名叫【平台用户】的用户

#3 由 宋 姣姣 更新于 超过 2 年 之前

  • 状态需求设计中 变更为 需求评审

#4 由 宋 姣姣 更新于 超过 2 年 之前

  • 状态需求评审 变更为 待开发
  • 指派给宋 姣姣 变更为 匿名用户

#5王 珍 更新于 超过 2 年 之前

根据实际需要增加以下需求:
1.原逻辑不变,根据用户导入支付明细自动生成对应流水,需要注意的是,特殊处理小金额情况,例如:张三支付1元。
2.用户导入支付明细,身份证号码和开户行为选填项

#6王 珍 更新于 超过 2 年 之前

生成流水时,前一批数据全部导入成功后才可以进行操作,否则不可以再次操作

导出 Atom PDF