在昨天的文章中提到了在相关项目需求时应该考虑财务的几个部分，其中有一项就是对销售的影响。
销售数据的重要性大家都清楚，销售报表作为销售数据的直接载体，有必要梳理一下。
看似简单，实现起来并不意味着容易，下面按照上图来简单说下销售报表。
概况介绍
数据来源
根据销售报表信息的组成，它要体现出「销售金额，销售成本」，所以销售订单包括退货与换货等单据与商品出入库的成本是重要的两部分。
销售单据根据渠道来源又包括线上和线下，零售和大宗销售的单据。
此外，还有一些视同销售的业务单据，也可以在销售报表中体现出来，例如：领用单据。
像盘盈/盘亏单据、报损出库等单据则需要根据公司和财务要求进行判断。
视同销售的业务单据进入到销售报表中需要与正常的销售数据区分开，个人倾向于此部分数据单独体现，如果财务或业务部分有实际需求需要集中体现，再进行汇总。
数据计算处理
在生成销售报表的过程中，有很多逻辑，很多种场景需要考虑，如销售订单与出入库商品的成本如何对应，优惠金额在销售报表中如何进行分摊等。
报表数据呈现的是主要信息字段，但是后台是要经过数据抽取，成本计算及报表生成几个步骤。
销售报表，个人觉得仍然应该遵循，从明细数据开始处理，根据分类生成不同的报表，然后根据业务要求再汇总，不要一步就到最终的报表中。
销售报表用途
用途主要体现在三个方面：
- 销售统计与分析，及时准确的反应销售业绩。
- 财务结算，在上图上可以看到，结算有自营与非自营两部分。自营：根据合作模式分为经、代、联几种，有的是按成本结，有的按销售结。非自营：一般是合作的商家，涉及代收款、佣金收入等。
- 账务，在财务账中需要根据销售报表数据进行再次处理，税务上需要进行应纳税额的核算等。
以上内容都通过销售报表来体现且不局限于这些，需要深入了解业务场景。
报表何时生成
对于销售报表的生成时间点也是依赖于业务需要的，其实无非是实时和定时两种。
定时，一般是每日零点以后生成，这与财务其它报表的生成时间一致，销售报表依赖于数据源和数据生成逻辑的复杂性，没有特殊要求。
实时，一般情况下是达不到的，因为业务数据生成后，还要依赖于成本计算。
但像销售金额等部分可以做到准实时，如果其他各部分都能够快速处理，也可以满足实时的要求。
实时数据要求各部分关联数据都要及时、准确，不能出错，这对整体系统有一定的要求。
个人觉得如果非财务入账数据，如果仅是数据参考型数据，可以做成实时的，否则尽量采用定时集中处理比较容易。
生成规则及过程简述
销售报表可能由几部分数据计算后再汇总而成，生成的规则非常重要。
销售数据通常采用「权责发生制」，一般情况下商品出库以后就需要进行计算，但对于非自营的数据有可能以支付时间来获取数据。
具体要根据业务单据来进行详细分析，这是首先要明确的。
销售报表中商品出入库后的成本核算，前期也介绍过，有先进先出、移动加权和加权等方法。
销售报表是需要获取出入库的商品成本的，在财务系统中成本计算也有两种方式，实时和定时的。如果是定时的，那么销售报表计算逻辑就要等此服务处理完成后再进行。
如果成本计算是实时的，那么销售报表可能做成实时的，为什么这么说？
因为在FMS中成本计算是财务中一个核心模块，异常场景比较多，如果出错便需要重算。
这是最简单的关系图，如果所有的业务单据都写入到出入库流水表中，经过出入库成本计算，销售报表可以根据出入库成本明细进行计算汇总。
当然，前提是出入库流水表中的数据要将销售相关的数据都记录完整才能满足，即销售报表的很多逻辑在上「图的1」中，否则会在「图的2」中完成。
如果采用加权成本法，那么销售报表就会比较容易生成，否则就会复杂一些。
因为加权成本法一般采用月末一次加权，所以出库成本都相同，所以报表逻辑主要在处理业务单据部分。
移动加权和先进先出则不然，它涉及业务单据与成本处理明细的对照，且不单单是「1:N」的关系，可能还会涉及到金额的再次分摊。
关于销售报表生成规则，这里简单整理几个部分，供参考，实际的代码实现过程可能更复杂。
1.业务单据字段的标准化
销售单据、退货单据、领用单据由于所负责的业务不同，数据的记录也会不同，所以首先应该尽量先收集统一。
2.基础数据的获取和映射
商品、合同、供应商或商家、分类等数据要提前准备，有些可以提前进行处理，以便于后续使用时逻辑复杂。
在前面介绍FMS系统时，有基础数据的抽取部分，要保证数据的状态实时更新是关键。
3.相关金额的分摊
先说一个常见的场景：
「网站或APP上销售雪花啤酒，规格：箱/12罐，售价 60元，可以5元优惠券，实际支付55元，免运费」。
对于这样的一个订单，如果商品是A，处理比较简单，但是如果啤酒是以罐在仓库进货或出库的，那么此订单在出库时，就会出库12罐B，这里就是一个父子商品的关系「父商品是B，子商品是A由12个组成」。
在此种场景下就有可能需要进行金额的分摊，需要将55元和5元优惠都分摊到12条或几条拆分的出库明细中。
是否分摊是依赖于出库明细记录的，而出库明细是几条，是依赖于WMS返回的具体批次（批次不同条数就不同）。
父子商品如此，对于一些礼包数据也会有相同的场景，如果库内只是包装，但没有经过系统的加工生产，那么销售的是礼包，但出库的仍是单个商品。
这时的金额分摊是一次分摊，当出入库流水经过成本计算后，可能还会出现二次分摊。
有金额分摊便会有尾差（除不尽）的出现，在销售报表中如果是商品单据级呈现，则任何一个字段值不同，都会分条显示。
上图是销售金额分摊的一个示例，可以想一下，此部分可以去模拟下场景。
销售报表层级
对于报表一直以来都有一个疑问，就是真正呈现给财务或业务部门的是最终商品单据级的明细，还是按某个维度的汇总。
因为接触过很多财务人员，都会要求是最明细的数据。记得在JM时与一位财务经理沟通时因为要求明细数据，与之争执半天，但也没能说服他。
如果是明细，对于每日单量十万或几十万时，明细可能就是几十或上百万，一个月可能就会有千万的数据。
很难想像财务拿到这些数据如何查看或分析，记得财务有位同事因为要处理数据特意申请了一台PC服务器来进行工作。
个人觉得报表生成的顺序应该是从明细到汇总，但呈现时应该是从汇总到明细。
销售明细数据也应该如此，我分析了一下财务为什么要求明细，因为一般情况下公司的专业财务软件只是财务模块，没有采购、销售等模块。
但是在财务处理数据，进行税额等核算时则要求提供明细数据，所以明细数据会作为每月的台账进行保存。
此外，FMS提供的报表还不能满足财务直接入账（如果没有财务凭证集成），所以财务需要进行二次加工处理，只能依赖明细。
最后，财务不信任汇总数据的准确性，所以拿到明细自己处理心里踏实。
只要将问题了解清楚，解决起来就会容易。
总结
本篇以销售报表为例进行了简单的分析，其实过程挺简单的，每个人都清楚，关键在于在程序实现前是否做了充分的设计，异常数据的处理尤为重要，如何补全数据是需要智慧的。
一直在努力想把文章写好「无论从内容还是排版上」，从未放弃过！
