主数据层建立：粒度方案 B 落地

本节要点：5 工具各搞一套主数据 = 重复冲突；粒度方案 B 统一（部门 28/科目 561/往来 2047/银行 17）；不需要建物料主数据表，外购入库单直接作单价源。

问题：5 个工具 5 套主数据

做到第 5 个工具时发现问题：

• 出纳工具内嵌了部门字典、银行编码
• 销售大表内嵌了客户对照、收入科目
• 损耗表内嵌了物料分类
• 应付凭证内嵌了科目/往来/部门

每个工具各搞一套，重复且冲突：

• 新增一个部门，要改 4 个工具
• 出纳工具的"部门编码"和应付的"部门编码"不一致
• 客户在销售工具叫"A 公司"，在应付工具叫"A（北京）"

这是技术债，越往后越乱。

决策：建主数据层

抽出统一的主数据层，所有工具共用：

主数据	数量	来源	用途
部门	28	HR	费用分摊
科目	561	T+ 科目体系	凭证生成
往来单位	2047	供应商 + 客户	应收应付
银行账户	17	出纳	银行流水
产品	占位	待补	销售/成本

存成 Excel（主数据/ 目录），工具读 Excel 不写死代码。新增部门/科目改 Excel，不改代码。

粒度方案 A vs B

主数据的"粒度"是关键决策——记多细？

方案 A：粗粒度

只记大类（部门 28 / 科目一级 ~50）。工具自己维护明细。

问题：明细还是各工具各搞一套，没解决冲突。

方案 B：细粒度 ✅ 选这个

记到最细（科目 561 条全量 / 往来 2047 全量）。工具直接查，不自己维护。

代价：Excel 大（科目表 561 行），维护成本高。但一处改处处生效，值。

选 B。粒度细 = 单一数据源 = 无冲突。

对现有工具的影响

工具	改造	效果
出纳 v1.3	集成 load_dept_map + find_master_data_dir，优先读 Excel 兜底内嵌字典	部门新增不用改代码
销售大表	客户对照表读主数据	客户名统一
应付凭证	科目/往来/部门全读主数据	跟出纳用同一套
损耗表	物料分类读主数据	跟领料用同一套
领料	物料分类已共用	✅

一个重要结论：不需要建物料主数据表

做损耗表时，本来想建"物料主数据表"（物料编码 + 名称 + 规格 + 单价）。

讨论后发现：不需要。

单价的真实来源是外购入库单（采购入库记录的实际采购价）。物料主数据表会重复维护单价，且单价月变动（加权平均），主数据表不适合存。

结论：物料主数据只管"分类 + 编码统一"，单价用外购入库单作数据源，工具按物料编码 join。

这个结论省了一张大表的维护成本。

实施步骤

1. 盘点现有工具内嵌字典——出纳/销售/应付/损耗各有什么
2. 建主数据 Excel——部门/科目/往来/银行/产品分类，5 张表
3. 写加载函数——load_dept_map / load_subject_map / find_master_data_dir（找主数据目录，支持环境变量 + 默认路径）
4. 工具改造——优先读主数据 Excel，兜底内嵌字典（向后兼容）
5. 测试——新增一条部门，4 个工具都能识别

教训

1. 主数据层应该第一个工具就建——我们等到第 5 个才建，返工成本高
2. 粒度选细不选粗——粗粒度等于没统一
3. 单价不入主数据——单价是交易数据，不是主数据
4. Excel 存主数据够了——别一上来搞数据库，Excel + 工具读完全够用

给同行的建议

如果你做第 2 个以上工具，立刻建主数据层：

1. 盘点各工具重复维护的字典（部门/科目/客户/供应商）
2. 抽成统一 Excel
3. 写加载函数（优先读 Excel，兜底内嵌）
4. 老工具逐步改造

不要等到第 5 个工具才做，技术债会越滚越大。

---

本节要点

• 5 工具各搞一套主数据 = 重复冲突
• 粒度方案 B（细粒度）：部门 28 / 科目 561 / 往来 2047 / 银行 17
• 工具优先读 Excel 兜底内嵌字典
• 不需要物料主数据表——外购入库单直接作单价源
• 第 2 个工具时就该建，别等到第 5 个

相关推荐

• 应付凭证自动生成：金蝶 → T+ 映射
• 9 岗位 AI 化全景：主数据层建立