1布景
公司存在多种物料种类、不同类型的库存和价值办理纷歧，存货体系现在主要接入包装耗材、产品数据。意图是为了：
- 办理出入库价格、数量、库龄等事务数据，便于办理部门追溯及财政管控，协助库房提高存货和物料的办理才能。
- 办理库房物料及产品的费用价值，提高核算及事务的效率，完成事务信息一体化及凭据主动化。
- 辅佐方案或收购部门检查库存，为收购方案提供数据支撑。
存货体系先接入了包耗材数据，这类数据的特性是行数据不多，但每行数量很大。后接入了产品的库存，因为行数据量增加N倍以上 ，而且跟着事务不断增加数据量越来越大，考虑到原有底层规划不能很好的支撑这么大的数据量，故有了这次体系的模型升级。
2面对的问题
2.1 数据接受点问题
原事务流程在数据接受上跨越了核心P0链路后才把数据落地到库存运用（造成了一定的技能危险，历史上也的确发生过一次技能故障 ，消费上游消息代码有bug，导致P0清结算链路数据下发呈现堵塞，影响了部分结算单据的处理时效）：
（1）数据落库在单据体系
（2）相关订单数据
（3）查询出未税单价
（4）拼装后下发库存
重构前的规划，本钱表存储逻辑：不论每天本钱价有没有改变，都会维护一条记载；台账表存储逻辑：每天如果有出入库数据依照事务类型汇总+2条期初期末数据，如果没有出入库数据，只保存2条期初期末数据。从存储逻辑不难看出存储了很多冗余数据，且台账表期初期末数据以行的形式存储也是不合理的。
如下是比如数据
2.2.1 明细表（record）
每天出入库、调价单的数据
2.2.2 本钱表（cost_price）
所有物料每天都需要核算一个本钱价
2.2.3 台账表（ledger）
日台账：汇总当天明细数据、以及期初、期末价格和数量 月台账：汇总当月明细数据、以及期初、期末价格和数量
2.3 页面数据查询功用瓶颈
2.3.1 大盘&台账表剖析:
经过大盘和台账表剖析，在接入库房产品数据后，页面查询接口耗时很高，接口功用存在问题
2.3.2 日/月进销存也面对相同的问题
3处理方案
3.1 数据接受优化
3.1.1 库存运用直接接受单据池落地信息表
3.1.2 详细完成进程
3.2 数据存储规划问题优化
3.2.1 简略示例
比如一个物料，3月1日的本钱价为100元，后在3月30日又进一件本钱价200元的相同物料，则我们库里的记载信息如下， 2条数据即可 ， 【无须每日更新数据，只有当时物料当日有出入库、调价数据时，才需要插入当日最新数据】，
实际场景，当事务代码查询3月10日的本钱价时，往前查询到03.01的数据即可
3.2.2 希望的数据存储款式
而不是30条数据 （ 03.02 至 03.29，这28条数据都是冗余的数据）
3.2.3 页面数据查询功用瓶颈处理方案
因为数据存储逻辑变更，只会存储有变动的数据，而进销存报表是每天都需要产出的不论数据有没有改变。结合当时事务逻辑以及数据量最终决议把数据同步到数仓，在数仓进行数据补全后，经过报表渠道拉取报表信息。
弃用当时后管渠道查询报表 转为运用报表渠道拉取库存报表信息
数据同步流程如下：
报表渠道具有生成类似于Excel的数据展现，以及任意维度查询信息的才能，一起也具有Excel导出的功用
4重构后的价值
4.1 量化事务价值：
每月节省核算以及审阅时刻约30小时，占核算组总月结时刻份额为30%。
4.2 不行量化事务价值
-
将库房事务纳入存货体系，庞大数据量经过体系主动核算，输出表格，节省手工核算的时刻，以及提高核算数据的准确性，处理无法经过表格完成的困境；
-
提高核算质量的一起，可以完成更多库存、出售数据剖析，如周转率剖析，出入库途径剖析，减值计提等等。剖析结果提高公司退货产品的办理以及库存办理。
-
功用重构从基础数据、入库模型、调价单、本钱核算、出库模型、重算、报表都做了升级，在数据接收、本钱核算等进程中增加了校验逻辑和修正数据的功用。
4.3 技能价值
（1）技能价值：首次尝试了在线TIDB切换流程（包含数据仿制、数据同步、数据比对、数据切流），积累了TIDB切换经历，给后续的TIDB迁移专项提供了经历沉积。
（2）技能价值：把P0级的清结算运用里的部分功用迁移到库存运用中，处理了大流量的库房数据下传至清结算运用的危险，完成了买卖和非买卖在运用级别的解耦和阻隔。
（3） 团队价值：以赛代练，经过该项目培养了组内成员关于数仓渠道和报表渠道的实践和运用，拓宽了团队全体的技能栈，并积累了数据开发的对应经历，也落地了数仓渠道和报表渠道的操作运用文档（节省了后续团队成员的数据开发熟悉接入的本钱）。
