结算概念模型设计
前言
从订单到收款流程中，一般会涉及到针对财务结算系统的设计，梳理一个常规的结算模块，可以通过概念模型设计快速了解大致需要涉及哪些模型以及这些模型之间的关系，并通过这些模型了解大致的设计要点。
结算场景
结算核心流程设计：
名词解释和核心场景：
应收场景：应收是站在企业的角度，按企业应该收客户多少钱去理解。各种的应收单据，比如：销售结算单、应收调整单等
应付场景：企业应该付给客户多少钱的单据，比如：折让/折扣、付款单等
收款场景：收款申请单匹配资金流水最终生成收款单
动账场景：完结单据通过产生相应的（正向或逆向）账户流水去修改不同账户的金额
ERP 单据入账场景：完结单据产生了账户流水修改了账户金额，比如修改了应收净额，那么需要在 ERP 那边去入账记录。根据不同的场景，入账可以分为：应收入账、收款入账、贷项入账
ERP 核销入账场景：应收的单据和应付或收款单据进行核销（正负抵消，相当于平账），分为两类核销入账：收款核销（有收款单参与的核销）和贷项核销。另外，基于实际的业务的复杂度，可能会有自动核销或手动核销场景，也会存在部分核销和全部核销场景，以及取消核销的逆向场景
开票场景：在中国的场景中，常规有开红字发票（代表的是冲抵的，是负数。销项负数发票）和蓝字发票（代表的是收入的，是正数。一般情况下开具的发票）。在海外的场景，还有商业发票（CI）和Credit Note（CN）等
结算概念模型设计
设计要点：
申请单一般承载着信息的补充收集和审核流程，而完结单据一般就是最终态的、可以当做凭证依据的单据。当然也存在不需要申请过程直接生成完结单据的场景，比如订单系统推送生成的销售结算单
完结单据通过产生账户流水记录去修改账户的金额，而一般可以通过业务客户+法人客户+核算主体+币种唯一确认一个账户
根据业务场景的不同，有时不只是完结单据才能去动账，申请单也存在直接动账的场景：一般涉及到申请单的动账是针对在途账户，而当申请单转化为完结单据时，动账则分两步，一是冲销掉之前的在途，二是去动应收净额账户
由于 ERP 系统不会及时返回入账结果，会对外提供可批量查询的接口，因此需要一个 ERP 入账状态记录表去集中化的管理不同单据的入账状态，通过通过定时任务去批量查询和更新相应状态
完结单据 ERP 入账成功后，会生成正向应收或逆向应收核销单，而这两种单据会基于同一个账户维度以及其他的一些核销规则（先进先出或先逾期先核销等）去生成相应的核销单，而核销单生成后也需要去 ERP 核销入账
一般需要信息的补充收集和审核流程才会生成开票申请单，比如开红票需要用户上传红字信息表。
对于开票，一般会涉及两种场景，一种是完结单据生成后，自动发起开票以及将开票结果同步回来。另一种场景是用户手动发起，完结单据生成之后，由用户决定是否需要进行开票。而在后一种手动开票的场景中，需要额外考虑是否会存在批量开票的场景，这里尤其需要关注大批量开票可能带来性能问题，需要通过一定的设计去规避
结算模块的核心业务其实就是各种动账、入账以及开票的过程，而为了快速简单地实现这一业务诉求，最终一般会催生出业务的终极模型：应收调整申请单+应收调整单，直接针对应收净额账户的调整，并且可以通过动态的配置表去实现不同的业务场景
小结
这里只是提供一个订单到收款流程中常规的结算模块设计供大家参考。概念模型可以帮助我们快速理解结算模块的整体设计，接下来还需根据业务的实际情况，进行具体属性的完善以及逻辑实现。