上文我们提及到该结算单的原始数据是来源于“通行账单模块去合作方取的ETC账单数据”,然后根据结算规则生成结算单。
基于上述情况,账单数据来源各种原因(如网络波动我方漏取、他方漏发、解析故障)有那么一点儿不稳定,而通行账单有一个“账单日期的概念,也叫请款日期”,打比方1月1号0点-23点59分合作方原定会发100笔ETC账单给我们,那么这100笔ETC账单的账单日期旧是1月1号。但是由于某种原因我方取到账单的时间推迟了2天,那么这100笔账单的“账单日期”并不会由此变为1月3号,他依然属于1月1日的,只不过我们的结算日期会相应推迟而已。
因为这种情况往往不能被第一时间被发现,为了应对这种特殊情况,我们将“通行账单”和“通行账单结算单”进行了解耦,正常的流程正常发起,而当发现有过往日期 “漏账单”的情况,则启动补偿机制,将漏掉的账单重新生成结算单,并再次补付款。
虽不想面对,但是有少付就可能有多付,那如何处理这种情况呢,请看下图,在合作方不愿意手动配合退款的情况下,我们在结算单模块新增一个类型“多付应收账单”,由系统与“通行应付账单”进行轧差。
为了兼顾财务有时进行线下付款/补付的场景,可针对结算账单设计了关联线下付款的功能。
四、主要页面原型1. 结算规则配置
结算规则配置,无非就是定义好几个W。WHAT结算什么;WHO,对谁结算;WHEN,按什么时间或者周期;HOW,怎么结算。
沿着这个思路,看以下规则,就包含了要结算哪条业务线什么类型的账单,向哪个合作方,结算周期D0还是D1, 怎么结算,垫资还是不用垫资,净额还是全额。
新增结算规则不用拘泥于一定要有什么配置项,可根据业务来定义有什么类型的账单需要结算,然后再抽象出类似结算周期,结算对象这种公共参数出来后,根据实际业务的不同结算需求去规划额外的的、特有的配置参数,以撑起我们规则的灵活性。