主题
仓库基础数据
仓库基础数据不是一张“配置完就不用再看”的静态表，它决定了后续物料能不能顺利建档、采购时怎么分组、物料列表能不能按类别和供应商快速筛选。
当前仓库基础数据主要包括两部分：
- 物料类别
- 物料供应商
页面定位
它们本质上是 物料管理 的前置基础数据。
先理解一个关键事实
当前前端实现里，仓库基础数据不是一个带 Tabs 的“基础数据总页”，而是两个独立页面：
物料类别物料供应商
也就是说，写教程时更准确的讲法不是“进入基础数据页后切换标签”，而是分别进入两个独立页面进行维护。
这两类基础数据到底有什么用
更具体地说：
| 基础数据 | 它解决什么问题 |
|---|---|
| 物料类别 | 这件物料归到哪一类，方便建档、筛选、理解库存结构 |
| 物料供应商 | 这件物料可以找谁采购，支持采购分组和默认供应商选择 |
如果没有这两类基础数据，后续物料录入会直接受阻。
与物料管理是什么关系
这部分是理解仓库基础数据最重要的地方。
一、它们是物料新增/编辑的必填前置条件
在当前前端中，新增或编辑物料时：
- 类别是必填项；
- 供应商是必填项。
这意味着：
- 没有物料类别，物料不能完整建档；
- 没有物料供应商，物料也不能完整建档。
当基础数据为空时，物料表单里还会出现“去添加”入口，提醒用户先补齐基础数据。
二、它们不只是“建档用”，还直接参与筛选
在 物料管理 页面中：
- 可以按类别筛选物料；
- 可以按供应商筛选物料；
- 关键字搜索还能命中类别名和供应商名。
所以基础数据不是为了后台“存一下”，而是会直接改变日常找料的体验。
三、供应商还会直接影响智能采购
一个物料可以关联多个供应商。
在智能采购中：
- 系统会先默认取该物料关联供应商数组中的第一个供应商；
- 采购时仍然允许用户切换为该物料关联的其他供应商；
- 采购弹窗会按供应商分组展示采购计划。
也就是说，供应商基础数据不是“联系人通讯录”，而是采购链路中的真实业务数据。
物料类别怎么理解
页面作用
物料类别页面的目标很单纯：维护“仓库里的物料应该如何分组”。
它帮助你回答的是：
- 板材属于哪一类？
- 封边带属于哪一类？
- 五金、辅料、包装材料是否要单独分开？
- 日后库存筛选时，用户能否快速缩小范围？
当前页面实际有多复杂
当前前端里的物料类别页非常轻量，不是复杂主数据管理页。
它只有：
- 一个名称搜索框；
- 一个列表；
- 新增、编辑、删除等基础操作。
列表字段
当前类别列表里真正展示的核心字段很少：
| 字段 | 说明 |
|---|---|
| 序号 | 当前页行号 |
| 物料类别名称 | 类别名称本身 |
| 操作 | 编辑、删除 |
也就是说，当前页面没有这些内容：
- 类别编码
- 备注
- 使用数量
- 创建时间
- 启用/停用状态
搜索与顶部操作
当前类别页：
- 搜索项只有一个：
物料类别名称 - 顶部操作有：
- 新增
- 批量删除
- 刷新
- 列显示设置
当前页面不显示导出。
新增 / 编辑类别时要填什么
当前表单很简单，实际只维护一个字段：
- 物料类别名称
所以这不是一个需要准备很多资料的页面，更像是“先把分类骨架搭起来”。
类别应该怎么规划才合理
实践上，更建议：
- 先按仓库最容易理解的维度分；
- 类别不要过碎；
- 让车间、采购、仓库对类别叫法保持一致。
物料供应商怎么理解
页面作用
物料供应商页面的核心任务，是维护“哪些供应来源可供物料选择”。
它服务的不是通讯录管理，而是：
- 物料建档时可关联供应商；
- 采购时可按供应商分组；
- 一个物料可配置多个候选供应商；
- 智能采购时有默认供应商可带出。
当前页面实际有多复杂
和物料类别一样，当前供应商页也非常轻量。
它不是传统 ERP 那种“完整供应商档案页”，当前前端里主要只维护名称。
列表字段
当前供应商列表里真正展示的字段很少：
| 字段 | 说明 |
|---|---|
| 序号 | 当前页行号 |
| 供应商名称 | 供应商名称本身 |
| 操作 | 编辑、删除 |
当前页面没有这些旧式字段：
- 联系人
- 联系电话
- 地址
- 备注
这一点和一些旧教程描述不一样，写新教程时需要按当前系统事实来讲。
搜索与顶部操作
当前供应商页：
- 搜索项只有一个：
供应商名称 - 顶部操作有：
- 新增
- 批量删除
- 刷新
- 列显示设置
当前页面同样不显示导出。
新增 / 编辑供应商时要填什么
当前表单实际只维护一个字段：
- 供应商名称
所以，从系统实现角度看，它更像“采购选择项维护”，而不是完整供应商主档案管理。
删除时要特别注意什么
这是基础数据最容易被误解的一点。
前端不会提前灰掉删除按钮
当前前端页面上：
- 如果你有删除权限，删除按钮仍然会显示；
- 页面不会提前告诉你“这个类别/供应商已被引用，不能删”；
- 也不会先把按钮禁用。
但后端会做硬性拦截
如果某个类别或供应商已经被物料引用：
- 类别：不能删除；
- 供应商：不能删除。
也就是说，这不是“建议不要删”，而是系统实际上不允许删。
这意味着什么
所以更准确的使用建议是：
- 如果某个类别或供应商已经在物料中使用，就不要期待还能删掉；
- 真正可行的做法通常是：
- 停止继续使用它；
- 把新物料改绑到新的类别/供应商；
- 老数据保留可追溯性。
一个物料可以关联多个供应商，这在系统里怎么体现
这是供应商基础数据最值得写清楚的一点。
不是“主供应商 + 备选供应商”独立字段模型
当前前端模型里，物料关联的是：
- 供应商列表
也就是说：
- 一个物料可以同时关联多个供应商；
- 但当前系统并没有单独的“主供应商字段”或“默认供应商字段”。
那默认供应商从哪里来
在智能采购里，系统默认取：
- 首个供应商
也就是“供应商数组中的第一个”。
所以更准确的说法不是：
- “系统有主供应商字段”
而是：
- “当前默认采购供应商表现为该物料已关联供应商数组中的第一个供应商”。
用户还能不能改
可以。
在智能采购弹窗中，用户仍然可以把当前物料切换为它已关联的其他供应商。
类别和供应商在物料页里是怎么联动的
这部分很适合写给一线用户，因为它能直接解释为什么基础数据维护后会改善找料体验。
物料页可以按类别和供应商双向筛选
在 物料管理 页面中：
- 选择某个供应商后，类别按钮数量会按这个供应商下真实存在的物料数量动态变化；
- 选择某个类别后，供应商按钮数量也会按该类别下真实存在的物料数量动态变化；
- 当前没有物料命中的类别或供应商，会被自动禁用。
这意味着：
- 类别和供应商不是静态标签；
- 它们直接参与日常找料和筛料过程；
- 基础数据维护得越规范，物料页筛选体验越稳定。
常见场景
场景一：第一次上线仓库模块，先搭基础骨架
- 先建立常用物料类别；
- 再录入常用供应商名称；
- 然后进入物料管理开始建档；
- 录入物料时补齐类别和供应商；
- 后续采购、领料、补料流程才能顺畅跑起来。
场景二：新增物料时发现选不到类别或供应商
- 在物料新增页发现基础数据为空；
- 系统会出现“去添加”入口；
- 先去维护物料类别或供应商；
- 回来继续完成物料建档。
场景三：某类物料越来越难找
- 打开物料页筛选发现分类过乱；
- 回头检查物料类别是否建得过碎或命名不统一；
- 整理后续新增物料的归类方式；
- 让物料筛选逻辑重新恢复清晰。
场景四：同一物料需要多个采购来源
- 给该物料关联多个供应商；
- 智能采购时系统先默认带出第一个供应商；
- 实际采购前再按价格、交期或现场情况切换供应商。
常见问题
为什么基础数据看起来这么简单？
因为当前前端实现里，它们的职责就是做“轻量可用的选择项维护”。系统把复杂度主要放在了物料管理、采购、领补退料这些业务页，而不是把类别/供应商做成超重主档。
为什么供应商页没有联系人、电话、地址？
因为按当前前端实现，供应商基础数据只维护名称。这和一些旧教程或传统 ERP 认知不一样，写教程时要以当前系统事实为准。
为什么我明明看到删除按钮，删的时候却失败？
因为前端不会提前判断是否被引用，但后端会拦截已被物料引用的类别/供应商删除请求。
为什么物料一定要选类别和供应商？
因为当前物料建档把这两项都当作必填基础字段。没有它们，物料无法形成完整业务身份，也无法顺畅进入采购与筛选流程。
系统有没有“主供应商”字段？
按当前前端，没有单独主供应商字段。默认采购供应商表现为该物料关联供应商数组中的第一个供应商。
使用建议
- 先把物料类别命名统一，再开始大批量建物料。
- 供应商维护先求“够用”，当前系统里先把名称维护准确最重要。
- 不要把类别切得过碎，否则物料筛选会越来越难用。
- 删除前先确认该类别或供应商是否已经被物料使用。
- 对于有多个采购来源的物料，维护多个供应商比频繁改名更稳妥。