material_manage_system

zhangwenrui/material_manage_system

Fork 0

Commit Graph

Author	SHA1	Message	Date
文睿张	3cc783b5ff	物料数据迁移，并让每个公司自带默认单位与仓库数据迁移（北京 / 武汉两个 SQLite 物料库 → wmms） - 北京进默认组织、武汉单独建组织：两套分类编码完全相同但含义不同（北京 A01=标准件，武汉 A01=机加工件），共存会撞 material_categories 的组织内编码唯一约束 - 199 条物料、37 个企业、45 条变更日志，以及各分类的 code_rules.next_sequence （对齐到已导入的最大序号 +1，否则用户新增物料会撞上已有编码） - 迁移段并入 scripts/init.sql 末尾，空库初始化即得完整数据公司默认数据 - 新建公司时种入 32 个物料单位 + 默认仓库 + 主库位，与建公司同事务，种一半失败会整体回滚（否则留下一个没单位、又占着公司编码的组织） - 单位在后端按公司隔离（MaterialRepo.IsActiveUnit 要求物料引用的单位属于本公司），此前新建的公司连单位下拉都是空的，物料的 base_unit_id 也无处可指 - init.sql 的单位段补齐「块」「Pcs」，与代码里的清单保持逐条一致默认组织更名：默认公司组织 → 北京	2026-10-14 16:05:36 +08:00
文睿张	696e90893b	fix: 主数据编辑的两类静默失败 UPDATE 漏列： - code_rules 的 SET 补上 category_id。此前改分类提示"保存成功"但不落库，是唯一用户可达的活缺陷（同页的分类下拉没有 disabled，且规则只能改不能删，没有"删了重建"这条退路） - code_rules 有 uk_code_rules_org_category，补列后改到已占用的分类会撞唯一键，新建与更新统一翻成中文的 ErrDuplicateCodeRule - 分类/单位/仓库/库位/伙伴的编码定为不可变：分类编码是编码规则前缀的来源（init.sql 的种子数据直接取 material_categories.code），伙伴编码是对外业务编号，改掉会让历史数据脱节且查不回来。service 的 Update* 不再要求编码非空 ——原先是"必须传、传了却被丢弃"；新建侧的必填校验保留 - 顺带补齐两处同款漏网：organization.go 的 code 与 partner.go 的 partner_code （前者 service 本就不校验编码，自洽，无需改）记录不存在时的静默成功： - DSN 开启 clientFoundRows，让 RowsAffected 返回"匹配"行数而非"实际改变"行数。否则"编辑时一个字段都没改"和"记录不存在"都返回 0，无法区分，直接加检查会把正常保存误判成记录不存在（真 MySQL 8.0 实测） - 新增 repository.execExpectingRow，7 个 Update* 影响 0 行时返回 ErrRecordNotFound；伙伴走事务内的 SELECT ... FOR UPDATE，只需翻译 sql.ErrNoRows - 既有 4 处 RowsAffected 用法逐处核对过，均不受该 flag 影响测试：补 6 个 Update* 的存在性检查、编码必填约束的两端、唯一键翻译、DSN 拼接；全部做过变异验证（抽掉实现后对应测试确实变红）。	2026-09-21 17:26:53 +08:00
文睿张	a103549854	拆分主数据和仓库数据	2026-09-16 16:29:04 +08:00

Author

SHA1

Message

Date

文睿张

3cc783b5ff

物料数据迁移，并让每个公司自带默认单位与仓库

数据迁移（北京 / 武汉两个 SQLite 物料库 → wmms）
- 北京进默认组织、武汉单独建组织：两套分类编码完全相同但含义不同（北京 A01=标准件，
  武汉 A01=机加工件），共存会撞 material_categories 的组织内编码唯一约束
- 199 条物料、37 个企业、45 条变更日志，以及各分类的 code_rules.next_sequence
  （对齐到已导入的最大序号 +1，否则用户新增物料会撞上已有编码）
- 迁移段并入 scripts/init.sql 末尾，空库初始化即得完整数据

公司默认数据
- 新建公司时种入 32 个物料单位 + 默认仓库 + 主库位，与建公司同事务，
  种一半失败会整体回滚（否则留下一个没单位、又占着公司编码的组织）
- 单位在后端按公司隔离（MaterialRepo.IsActiveUnit 要求物料引用的单位属于本公司），
  此前新建的公司连单位下拉都是空的，物料的 base_unit_id 也无处可指
- init.sql 的单位段补齐「块」「Pcs」，与代码里的清单保持逐条一致

默认组织更名：默认公司组织 → 北京

2026-10-14 16:05:36 +08:00

文睿张

696e90893b

fix: 主数据编辑的两类静默失败

UPDATE 漏列：
- code_rules 的 SET 补上 category_id。此前改分类提示"保存成功"但不落库，
  是唯一用户可达的活缺陷（同页的分类下拉没有 disabled，且规则只能改不能删，
  没有"删了重建"这条退路）
- code_rules 有 uk_code_rules_org_category，补列后改到已占用的分类会撞唯一键，
  新建与更新统一翻成中文的 ErrDuplicateCodeRule
- 分类/单位/仓库/库位/伙伴的编码定为不可变：分类编码是编码规则前缀的来源
  （init.sql 的种子数据直接取 material_categories.code），伙伴编码是对外业务
  编号，改掉会让历史数据脱节且查不回来。service 的 Update* 不再要求编码非空
  ——原先是"必须传、传了却被丢弃"；新建侧的必填校验保留
- 顺带补齐两处同款漏网：organization.go 的 code 与 partner.go 的 partner_code
  （前者 service 本就不校验编码，自洽，无需改）

记录不存在时的静默成功：
- DSN 开启 clientFoundRows，让 RowsAffected 返回"匹配"行数而非"实际改变"行数。
  否则"编辑时一个字段都没改"和"记录不存在"都返回 0，无法区分，直接加检查会把
  正常保存误判成记录不存在（真 MySQL 8.0 实测）
- 新增 repository.execExpectingRow，7 个 Update* 影响 0 行时返回 ErrRecordNotFound；
  伙伴走事务内的 SELECT ... FOR UPDATE，只需翻译 sql.ErrNoRows
- 既有 4 处 RowsAffected 用法逐处核对过，均不受该 flag 影响

测试：补 6 个 Update* 的存在性检查、编码必填约束的两端、唯一键翻译、DSN 拼接；
全部做过变异验证（抽掉实现后对应测试确实变红）。

2026-09-21 17:26:53 +08:00

文睿张

a103549854

拆分主数据和仓库数据

2026-09-16 16:29:04 +08:00

3 Commits