报表碎片化
同一配件或同一服务项目存在多个叫法，物资入出存统计与维修项目分析被拆成互不相关的多行。
Module 10 / 基础数据
先把字典立规矩，报表才对得上
同一个东西在三家门店有三个叫法，汇总时就变成三行；有人图省事自建一个类别， 三个月后谁也说不清它到底算什么。基础数据模块做的就是把这些名词、 目录与归属一次性钉死，让后面的单据和报表都建立在同一套定义上。
六类字典
品牌车系车型
作业项目
物资目录
仓库与班组
会员级别
6类
基础数据分组
公共 / 维修 / 整车 / 物资 / 财务 / 客户
19项
统一维护对象
从供应商到会员级别，集中定义集中下发
Functions / 系统功能
六组字典，撑起全部业务单据
字典不是后台的技术配置，它直接决定前台能选什么、单据怎么写、报表怎么汇总。
- 公共基础数据公共字典、供应商设置、保险公司
- 维修基础数据维修字典、车间班组、作业项目
- 整车基础数据整车字典、品牌车系车型、整车仓库、代办项目
- 物资基础数据物资字典、物资品牌、物资分类、物资目录、物资仓库
- 财务基础数据财务字典
- 客户基础数据客户字典、会员字典、会员级别
Why / 为什么重要
基础数据的代价是后置的
上线时不重视字典，问题往往在半年后集中爆发：报表越汇总越碎，历史数据无法对比，改一次要动全部单据。
历史不可比
分类中途调整后，新老数据断层，环比失去意义，管理层只能凭印象判断趋势。
维护成本翻倍
门店各自新增归类，集团层面每次统一都要返工清洗，清洗成本远高于上线时一次性梳理。
基础数据治理的投入几乎都发生在上线前，收益却体现在未来每一张报表上。换句话说，这一块偷的懒，统计分析 M9 迟早要连本带利还回来。
Sequence / 初始化顺序
七步从空系统到可用系统
这几步有明确的先后依赖关系，跳步会导致后面的单据录不进去或录进去也汇总不出来。
-
机构
先定义集团、区域与门店的组织层级，它是所有数据归属与数据权限的根节点。
-
字典
导入公共字典、维修字典、整车字典、物资字典、财务字典与客户字典，确立统一叫法。
-
目录
建立品牌车系车型、物资分类与物资目录、代办项目，目录是单据录入的选项来源。
-
仓库
设置整车仓库与物资仓库，绑定所属机构，库存类报表依赖这一层。
-
班组
配置车间班组与作业项目，派工、工时与工位效率分析都建立在这一层之上。
-
价格体系
确定工时单价、折扣权限与结算口径，并配套财务字典中的科目与费率定义。
-
权限
最后在系统管理 M11 中建立角色与员工账号，把前面六步的成果按岗位分配下去。
Governance / 集团与门店
集团统一定，门店按需继承
既不能让门店随意新增，也不能什么都卡死。系统按数据性质区分「必须统一」与「可以继承后微调」。
| 数据类型 | 维护层级 | 门店能否自建 | 原因 |
|---|---|---|---|
| 品牌车系车型 | 集团 | 不可 | 全集团统一检索口径，自建会造成车辆档案无法跨店识别 |
| 物资分类与物资目录 | 集团 | 不可 | 直接影响物资入出存统计与呆滞分析的准确性 |
| 供应商设置 | 集团 | 不可 | 采购账与应付账需要唯一主体 |
| 物资仓库 | 门店 | 可 | 各店仓位数与用途不同，但须挂在自己的机构下 |
| 车间班组 | 门店 | 可 | 班组设置取决于门店工位配置与排班方式 |
| 会员级别 | 集团 | 不可 | 会员卡跨店通用，折扣权益必须一致 |
继承规则：门店继承集团字典后通常只能使用不能修改；确需新增的，走申请、审核、集团统一编码三步再下发。这样既保证门店业务能跑，又不让字典口径在基层悄悄漂移。
Practice / 操作实务
六条字典维护纪律
这些纪律看起来琐碎，但决定了两年之后这套系统还能不能算得清账。
- 先定编码规则：物资目录、车型与供应商在录入前先确定编码规则，后续靠规则自动生成，避免手工编号重复。
- 作业项目与工时绑定：作业项目不仅要挂名称，还要挂标准工时与班组归属，否则派工与工时毛利无从统计。
- 物资品牌与分类分开：品牌是属性，分类是统计口径，两者不要互相替代，否则精品销售统计口径会失真。
- 保险公司信息一次录全：保险公司在公共基础数据中统一维护，承保机构名称不一会直接影响续保提取与保险理赔结算。
- 会员级别谨慎调整：会员级别变动会连锁影响折扣与会员服务 M8 的积分规则，调整前应评估对历史权益的影响。
- 停用优于删除：不再使用的字典项建议停用而非删除，历史单据仍然引用它，删除会造成历史记录无法追溯。