猎米云商电商学院 > 电商系统 > 电商系统开发 | 用案例讲解,如何搭建移动加权成本计算服务

电商系统开发 | 用案例讲解,如何搭建移动加权成本计算服务

电商系统 2021-01-19 30 0

导语

财务成本计算一直以来都是我认为比较复杂的部分,近期刚好有几位朋友咨询有关成本的问题。所以决定将此部分结合案例进行详细的梳理与总结,希望对大家有所帮助。

成本计算的重要性

成本是衡量一件要做的事情是否值得去做的指标,这是最通俗的理解。没有成本,就无法分析公司的经营情况,无法去合理的进行商品的价格设定、无法判断出企业是否盈利,财务系统中的成本计算就是做这项工作的。

在财务系统中成本计算一般是独立的计算服务,它根据商品的出入库流水、商品的库存,按照成本核算方法,按照某种规则进行的一系列的计算,从而准确的核算出每个商品准确的成本价及成本金额。

案例介绍

某企业是一家以食品、酒水零售为主的垂直电商,它不仅有线上业务,而且在很多城市也开了很多门店,实现线下线下融合。

线下门店的商品由仓库进行统一配送后再进行销售给普通用户,对于线上订单如果非到家订单由仓库直接通过快递发给用户,到家订单则根据用户收货地址进行门店匹配,由门店送货到用户。

采购与运营业务要求可以实时查看到商品的成本价格、当前仓库或门店的库存数量及金额,财务要求采用移动加权平均法进行成本核算,每天能够查看前一天的期末库存,按结算周期生成结算单,购销和代销时涉及的结算成本一定要准确,同时每一件商品的成本变化要能够可追述。

案例分析

根据案例介绍,在商品的转移过程中要进行成本的计算,而且有两个阶段的成本。

① 供应商到仓后后,仓库按照移动加权平均算法计算在仓商品的成本。 

② 从仓库到门店后,门店按照移动加权平均算法计算门店商品的成本。

每个仓库都需要单独计算,因为仓库是在不同的城市,在财务上会归属于不同的分公司。门店有很多,每个门店的成本都要单独计算,不同时期的商品从仓库出库时的成本是不同的,可以把门店看作是一个个小的独立仓库(前置仓),这样在产品或系统设计上都可以采用一套成本计算逻辑。

为了保证计算的及时性,后台成本计算服务可以按“仓/门店”启用多个线程或多台应用服务器独立部署的方案,这样既不会相互影响,又解决了海量单据时的计算性能问题。

此外,对于业务提出的实时成本显示的问题要重点考虑。实时成本计算对系统要求很多,在计算过程中出现异常情况时数据的准确性难以保证,所以要和业务做深入沟通,了解业务的真正用途。

经过与业务反复确认,他们对于实时成本主要是在做日常运营时有一个数据参考,避免公司损失,对于数据的准确度要求并不严格,允许微小的差异。

系统设计与实现

初步分析了此案例(这里略过一些其他步骤),下面就进行具体的系统设计与实现阶段。

1.梳理出入库单据及计算公式

前期介绍过电商企业库存可以分为三部分:仓储库存、ERP库存和财务库存,财务库存是依赖于仓储和ERP的业务单据经过计算而来的,首先要确定这些单据类型,如图所示。

这些单据都会引起仓储库存数量的增加或减少,每种单据要进行类型的定义,如:入库上架(01 采购入库),出库拣货(03 销售订单),盘盈(09 盘盈入库)。这些单据类型要与ERP下发到仓储的业务单据进建立映射关系,有些在库内货位间移动的单据电商ERP系统或财务系统不关注,可以不用进行处理。

设计原则是要将影响仓储库存增加或减少的所有单据都罗列出来,不能遗漏。同时,按照财务的按权责发生制,成本计算时点是根据出入库的时间进行的。

针对整理的每种单据都要确定计算逻辑,具体确定后的规则,如下。

2.后台计算主流程

明确了单据类型,要确定成本计算的主流程,如图所示。

每种单据也需要根据规则进行细化,这里以采购退货出库单举例,供参考,如图所示。

3.异常处理流程

对于在计算过程中的异常情况是系统要着重考虑的,常见的异常情况归纳为以下4种。

① 出入库流水获取有问题,重复或缺失。

② 单据中涉及单价的问题,业务系统的问题。

③ 由于计算时序问题,财务库存不足使得无法计算。

④ 计算服务程序的问题,新上线的功能在生产中不可预料的场景。

针对以上问题,在成本计算服务中都要有对应的方案,具体如下。

① 因出入库流水问题,系统预警后要及时终止,重新获取流水数据或手动处理。

② 业务系统及时修正,修正后重写更新流水,针对有问题单据涉及的流水重新处理。

③ 按天计算原则,只能从一天的0:00开始,不能按时、分、秒进行处理。

④ 加强测试,将生产数据脱敏后导入测试库,真实模拟新业务场景。

4.重算流程

因数据异常或系统问题需要重新进行商品成本计算,在重算服务模块的设计时,需要考虑针对某一个SKU商品进行重算,而不是每次出现异常后全部重新计算。重算流程包括两个过程:数据恢复和重算。

①数据恢复

数据恢复是将在计算过程中涉及的出入库流水表、库存表、出入库计算明细表数据根据当前的数据进行先恢复到计算开始时的信息和状态,以便重新开始,如图所示。

②重算

重算是针对已恢复的全部或部分出入库流水,按照成本计算规则进行再次处理的过程,如图所示。

重算是有些原则需要遵守,主要有以下几个方面需要注意。

①已经完成的月结不能重新计算。此原则在点击开始执行或数据恢复、数据计算、数备份、日结报表时都要给出明显的提示,防止误操作使得历史数据重新计算而产生新的问题。程序中可以增加限制,如:选择开始日期与结束日期时要与是否月结进行相互验证。

②结束日期不能小于开始日期。

③进行重算时,要确保实时的后台相关服务已经停止,避免数据混乱。

④默认是按SKU进行重算,不建议使用全部重算(时间较长、且数据计算量大)。

操作过程如下所示。

5.案例中两阶段成本计算的关系

在案例分析时介绍过,仓和门店可以看成是不同类型的仓库,门店的商品来源于仓库的调拨出库单或要货单,所以在第二阶段成本计算时依赖于第一阶段成本计算结果数据。

一般情况下仓库发货后再配送到店是需要时间的,如果次日送达,在成本计算时没有影响(仓库流水处理在前一日,门店流水处理在次日)。但是,如果从仓到店是当日送达时,仓库的出库流水与门店入库流水是同一日产生的,此种场景下,如果采用分仓计算成本方式,就会出现门店入库流水计算时获取不到仓库出库流水计算的成本价的异常情况(门店成本计算时,仓库流水未处理完)。

对于这种分仓计算时相互依赖的场景,可以利用消息队列来实现计算任务间的调度,即当一个仓的成本计算完成后写入消息,依赖此仓数据的其他仓计算服务会订阅并读取到这个消息并启动成本计算程序。

这种分仓间有依赖性的独立计算的方式,在系统处理上会复杂于按照全部出入库流水整体计算的方式。

在本案例中建议部署两套计算服务:即A-所有仓库的成本计算服务,B-所有门店的成本计算服务,B服务依赖于A服务的方案

6.实时成本计算与定时成本计算的解决

在电商企业,如果在业务不成熟或相关业务系统上线初期,不建议采用实时成本计算的方案,实时计算的复杂度与后期系统维护的工作量比较大。

实时计算应该在每一次出入库,在增加或扣减库存时进行成本的计算,而且要电商财务系统与电商ERP融合。在本案例中,笔者在设计时,将实时成本计算服务集成在OMS服务中,如图所示。

当OMS服务接收到入库或出库的单据时,一方面将这些单据进行处理生成出入库流水,另一方面对每一笔单据按照成本计算规则进行实时的商品成本计算,这些都在电商ERP系统中完成的,数据与财务系统是隔离的,但成本计算服务可以共享。

每日零点以后当电商财务成本计算完比后,财务系统会与ERP系统进行库存对账,在核对时不仅核对数量,也要核对移动加权成本价,如果不符,则以财务库存覆盖ERP库存成本单价的方式更新,可以手动更新或自动更新(建议先核对差异原因后再手动更新的方式)。

至此,以移动加权平均法进行成本核算的实现过程介绍完毕,我们可以参考此案例的步骤与方法,结合实际的业务需求进行合理的财务成本计算服务设计。

写在最后

以上介绍的成本计算服务实现的主要部分,在实际的系统开发时需要产品、研发、业务几个部门坐下来详细讨论,而且达成共识。产品并不了解系统,研发不了解业务,业务的要求有时也很模糊,只有大家都理解了,将各个场景梳理顺畅了,数据流转的清晰了,可以呈现出业务需要的数据就达到了基本目标。

发表评论

◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。