谈那些结算重付1700万元的网上事故
因为涉及到敏感信息，公司和平台的名称已经被删除，所以不要想象它们都发生在JD.COM，也可能是一个宝藏，一个多一个群体。毕竟这个圈子很小。有些内容需要了解背景和上下文，所以要关注系统本身或上下游交互过程中存在的问题，作为警告。1、结算系统配合上游升级，上线后几天质控部门反馈发现一商家利用取消退款套现，一个珠宝商家套现880W 有20家企业有疑似问题，总金额2万W。
新系统采用收支两线原则。取消退款订单后，商户将首先结算，然后逆向扣除。考虑到商户对账体验扣除的所有细节将处理相同的事务，如果执行不成功，将重新测试，但不会挂断账户。商户利用统一事务处理的间隙时间立即提取现金，导致应收账款无法及时收回。
方案
1)移动终端无法冻结漏洞修复上线，冻结20个疑似商户账户；
2)结算系统紧急将所有逆向进行挂账，并增加时序逻辑;
2.战略商家和平台A、B两个事业部签订了入驻合同，分别约定了10W和13W保证金实际收取了商家两笔10元W和一笔13W存款，商家投诉被商业欺诈。
原因
运营在合同审核通过后发现账期选错了，按照正常流程如果要更新账期只能再签一份补充协议进行修正或者下线原主合同再新签，但都需要再走一遍各级领导审核。后来通过老运营指点知道了合同系统可以更新版本，可以直接修改账期、付款方式等信息。
于是更新了连合同系统产品经理都不熟悉的隐藏技能。但问题是，合同系统的更新版本将重新推动所有信息：结算系统信息是基于业务ID维度创建，根据商家更新版本ID进行了update;但是保证金系统是应收单的维度，所以在原合同更新版本后再次创建应收账单。
方案
1)合同系统隐藏更新版本入口；
2)保证金系统在线合同维度应收判重；
3.订单中心重复了一批海外订单的结算细节，跨越了两个连续的自然月，订单结算系统未经验证，导致商家重复结算。总金额20W美金。
原因
1)由于订单中心主从数据库迁移，这批订单的主流水库再次推送，迁移后再次从库推送。
2)而且由于同一订单相继推送结算明细的场景，结算系统不能以订单号作为判断条件，只能是结算明细UUID，正好是两批订单UUID结算系统检验通过了不同的结算系统。因此，商家重复结算。
方案
最初认为上游订单中心再次推动逆向结算细节抵消，然后沟通，因为这些订单实际上没有逆转，如果强制推动一批逆向水，以后的问题不能定位，计划放弃。
1)如果订单已成功支付，结算人员将调整项目输入下一个结算单，并抵消这些重复结算的订单。
2)订单未付款的，结算人员应当在当期输入调整项进行抵销；
思考：如何根本性规避?
4.结算系统配合公司整体要求进行合规改造。由于涉及的业务类型和业务量过大，分批上线。但后来有商家找到反馈，他当天收到的钱比平时多，有些订单好像反复付款。
原因
由于新结算系统的切换设置了白名单和开关，这种业务类型的业务在切换过程中确实被切换，因此新系统上线后的结算清单细节和金额是正确的。但旧结算系统未及时离线，导致旧结算系统仍在结算，因此结算重复。
方案
1)旧结算系统的线下业务类型；
2)新增试算功能，验证结算次数和状态；
3)结算人员联系商家确认重复结算的订单明细和金额，结算人员在下次结算单中调整账户。
5.某医药企业向采销反馈，当期结算单的付款对账不均匀，自己的会计系统无法记账，需要重新对账。对账后，商家财务反馈商家后台结算单金额正确，但同一批订单在另一批COD系统结算后，近年来重复支付金额为1700W 。
原因
1)平台订单分为先付订单和后付订单，由结算系统与订单中心互动，最终向商家支付。
2)该平台使用的物流服务提供商也为该平台和其他外包订单提供后款订单COD结算业务。物流服务提供商不过滤平台订单，导致重复付款结算。
方案
物流服务提供商COD该系统过滤订单中心的后订单，以确保平台结算系统是商户结算的唯一关闭。
结算不是小事，细节显示能力。一旦结算系统出现错误，在许多情况下无法通过自己的验证发现。因此，在做每一个需求和处理每一个问题时，我们应该清楚地了解系统的现状，并综合考虑可能的业务场景。
如果我说的是，如果每个人负责的结算系统都发生了在线事故，不要扔锅进行研发、测试和操作。问题的发生不仅是一方的责任，还可以参考以下流程：
1.定位问题的原因是第一步和首要任务；
2.及时止损，确定问题数据明细；
3、产研三方确定方案，RD上线修复，QA场景测试；
4.尽快联系结算员和运营商进行沟通和电子邮件确认，避免后期争吵； 本文由POS机办理中心整理，未经许可不允许任何形式的转载，本文唯一地址:https://www.cdkft.cn/xinwenzixun/27856.html，其他地址不完整的均为抄袭！POS机申请办理请添加客服微信号：shandianpos
