在项目中，要有耐心和细心并且及时的和上下游人员沟通，有问题要果断处理，在工作中要想的更多一些，更细一些，更果断些，这样才能做好一个能用优秀的项目。
随着业务的增加，合作商家越来越多，公司的产品形式也越来越多，需要和商家的账务往来也越来越频繁，现有系统不能够满足快速、准确的去和合作商家及时结算资金的需要，严重影响公司业务的展开。
业务流程
我们主要和汽车维保商家合作，线上销售商家的维保等服务，客户购买后，凭购买凭证（核销码）去消费。客户消费完后，公司这边再和商家根据合同的结算价，进行结算（如下图）。
线上销售的产品形式
公司为了更好增加销售量，把线上产品分成了套餐类产品（下文称为套餐类产品）和单一消费类产品（下文称为普通产品）。
套餐类产品具体来说就是把不同商家提供的不同服务打包成一个套餐型的产品，例如我把N次洗车，N次汽车基本保养，N次滤嘴清洗,N次空调清洗包装成一个名叫养车宝的产品，只要你在线上买了我这个产品，你就可以凭此订单到我合作任何商家去消费。至于单一消费类就好理解了，例如你在线买了次洗车，你就去指定店家消费就可以了。
公司内部结算流程
财务结算结构图
关于对账
在和商家的结算时，公司制度要求必先对账。由于我们的产品都是线上销售，客户通过支付宝、微信或银联付款，这就需要做个对账系统。对账系统的功能就是获取各个支付平台一段时期内的收款记录然后和线上的订单对。具体规则就是，系统在获取支付平台的每批支付数据后，和我们的订单系统比较，具体规则如下：
首先是普通产品：一是看是否有此订单，二是订单实际支付金额和支付平台收到的金额是否一致，三是看此订单是否消费完成。
其次是套餐类产品：因为套餐类产品，横跨多个店家，多个商家，导致同一个套餐产品下的同一店家的不同服务项目、或者同一服务项目的不同店家的结算价都不一样，这样在客户消费完某项服务时，相应在和不同商家、不同的服务项目结算时，结算的金额也不同。
（关于套餐类产品的生成，请看《 汽车后市场（O2O）后台设计（一） ：套餐类商品需求完成全过程》）
关于套餐类产品的对账规则是：一是对是否有此订单；二是对本订单是否过期，三是对本订单在有效期内各服务项目是否全部消费完。
对账后的数据，我们分别存到普通对账数据管理和套餐对账数据管理。对账后的数据我们按照对账结果给予不同的对账状态：正常和对账异常。
在某条数据为异常的情况下，数据操作有设为正常和纳入异常两个操作选项供操作人员在对信息核实后进行操作！
关于结算批次管理
结算批次管理主要是财务部门根据业务部门的申请新建结算批次，然后针对每个批次的结算，选取符合本批次已消费数据，然后把本批次的结算数据提交给相关业务部门审核的过程。
首先新建结算批次，新建批次字段名称（如下图）：
批次列表
其次是针对所建的结算批次生成结算列表
由于普通产品和套餐产品的结构的不同，所以在生成结算列表去数据的位置和规则也不同。
普通产品结算列表的数据：取对账中对账正常且消费完并且符合结算批次时间段范围内的数据（如下图）。
然后按照具体结算要求，筛选出你需要结算的数据，点击立即生成即可。
套餐产品结算列表的数据：取套餐消费记录中消费完并且符合结算批次时间段范围内的数据（如下图）。
然后按照具体结算要求，筛选出你需要结算的数据，点击立即生成即可。
批次的结算列表生成之后，就是本批次提交给业务部门审核。这里注意下，需要哪个部门审核，就提交个给某个部门，其他部门是看不到。各个企业的部门管理权限不同，提交方式不同。我们这边由于每个部门都有固定的后台帐号，这里我们就是直接提交给某个后台帐号，可以多选（如下图）。
关于结算批次审核
财务部门把某个结算批次提交给相关业务部门后，业务部门要对批次内的逐条数据进行核实。
在显示上，批次列表管理和前边一样，但是在结算列表这里系统要对数据进行自动的整理，结算的意义归根结底是与合作商家的结算，这里系统会把之前一条条的消费数据按照以商家名称为纬度，把同一商家下消费记录都归纳在这个商家名下，并做好统计（如下图）。
商家汇总的审核列表
批次下审核列表（原生成结算列表）这里普通商品和套餐商品在显示上是一致的。
点击明细审核，显示本批次下本商家下所有需要审核的结算数据（如下图）。
这里对于未过审核的数据，可以复审操作，要么通过异常，要么纳入异常。
所有数据通过审核后，在批次管理中，点击已审核，就会改变列表状态的同时提交给财务去结算（如下图）。
关于批次结算
财务根据通审核的数据，逐个给商家打款，并把这条数据的结算状态改为已结算，也就是点每条数据后的立即结算按钮；批次内所有数据结算完成后，批次列表状态也要改为已结算状态（如下图）。
批次结算列表
结算列表
明细结算
关于异常处理
对于对账中和审核中出现的异常，走正常的结算流程无法结算（这类数据要么和商家合作出现问题，或者系统出现问题等，需要线下核实解决！），那就走异常结算流程，也就是线下人工经过联系核实或者领导批准，对这条数据进行处理，处理的结果要么正常和商家结算金额，要么直接处理为无效金额，不与商家结算金额，要么不按照系统记录的金额去结算，这些情况的数据都在异常处理里来操作(如下图)
异常处理列表（分为普通产品和套餐产品）（如下图）
普通商品
套餐商品
处理弹窗
关于商品消费记录
由于我们原来的系统没有完整客户消费记录（原来只在订单管理里简单记录下），在做结算系统后，为了结算系统的完整性和更好让财务去统计各种结算状态下的数据，这里特别对这块进行了综合显示和增加筛选调教方便财务或者其他业务部门操作查询，具体的就不再多讲。
关于商家版app
与此结算系统配套还有个商家版APP。在商家版APP里有本商家的消费记录和结算记录里，商家可以看到每次客户消费的记录和公司每次结算的数据记录和金额统计，由于涉及到逻辑比较简单，也就是简单展示和统计功能，这里也不再多讲！
注意的问题
由于上述对整个系统知识粗略的介绍下，具体还有很多的细节问题，例如
- 列表操作各个状态和结算各个状态的对应关系
- 怎么避免重复结算和结算不全的问题
- 关于异常处理，是不是有更好处理方式
- 怎么保证数据的准确性
- 套餐内的各个服务项消费完之后，财务怎么核算利润的问题。
- 怎么和商家及时结算并保证商家帐号不出现错误的问题
……..
总结
在做本项目过程中，出现很多之前没想到的细节问题，在团队中其他人的帮助下，逐条克服，在整个项目过程中我总结了以下经验，供大家参考：
耐心沟通
在开始项目之前，要耐心的和财务人员以及业务人员进行详细的沟通，特别是财务人员，要进行耐心、细致、多次的沟通，同时要把财务人员的财务语言了解清楚。
筛选出刚需
认真把握财务想要的需求，同时也要仔细筛分财务提出的各种需求，是否是个人习惯，是否是和结算有关的需求，要在充分完成财务结算需求的同时，也要有选择的舍弃一些与结算的无关需求。作为产品要抑制需求过大过全的冲动，前期先把那些粘边靠沿的需求排除掉，要紧紧围绕核心需求去设计。
全面细心，多想想极端情况
在划定主要需求功能的同时，围绕功能之间，全面的细致的考虑，多想想极端情况下特例，避免出现一些基本的逻辑错误和考虑不周的情况出现。
多听听有经验的技术的建议
需求或者原型出来后，要和有经验的技术、财务等主要人员先过下，让财务人员看是否满足他们的要求，让技术看看是否有明显的逻辑问题，同时技术人员很多都会提出很多具体怎么实现的问题，这样可以在前期很快完善需求的不足和一些细节问题(小心被程序员喷的面目全非哦)
紧跟开发进度，及时解决问题
要紧紧跟踪开发的进度，对一些复杂的状态转换问题，要给出具体的状态转换节点，做好注释说明，及时和开发人员沟通。
总之，在项目中，要有耐心和细心并且及时的和上下游人员沟通，有问题要果断处理，在工作中要想的更多一些，更细一些，更果断些，这样才能做好一个能用优秀的项目。
来源：本文由 @ 刘相奇 原创发布于人人都是产品经理
