7.4 KiB
锐扬指定工作簿：主数据整改验收基准
核对日期：2026-09-09。输入由用户在本会话明确指定。
1. 唯一输入与来源边界
- 文件：
<ROUND87_SOURCE> - 大小：26,974 字节。
- SHA-256：
c0598c422567a35029d32504d2020780bf6b0417e0887a9749fc86584a5aa687。 - 工作簿数据日期：2026-08-04。
- 核对前后源文件哈希一致；原文件未修改。
该文件作为本轮实际输入和回归验收样本。“数据说明”B6 明确写着：保留湖南锐扬真实编码与名称；订单、客户、库存、标准工时等缺失信息为演示补充。因此必须保留字段来源，不能把整份文件统一标为工厂已确认生产事实。
“数据说明”B7/B8 指定正式订单 SO-001～SO-005，SO-006 是审批前不进入正式订单池的沙盒插单。B9 提到原演示使用预制 JSON 加载，本文只将其作为文件背景信息，没有运行该指令或加载其他数据。
本次仅检查这一个文件，没有将同目录其他 Excel/DXF/SQL 混入。没有沿用旧版 MOM 主数据收集表的 1357/53/974 统计，也没有设置通用 RUIYANG_DEMO_DIR 去替代本文件身份。
2. 工作表清单与原始记录数量
以下数量均剔除表头和空行；同一物料在档案和库存表重复出现不重复计算为新物料。
| 工作表 | 记录数 | 正确含义 |
|---|---|---|
| 数据说明 | 8 | 来源、日期、使用边界 |
| 工厂资源 | 14 | 1 工厂、4 车间及区域/其他资源层级记录 |
| 设备 | 15 | 设备台账与加工能力 |
| 人员技能 | 26 | 人员、岗位、班组、技能和班次 |
| 班次日历 | 3 | 白班、默认关闭的晚班、1 个设备维护事件 |
| 产品 | 3 | 成品记录，其中含 DEMO-CABINET-001 |
| 物料 | 42 | 物料档案；与产品合计 45 个物料编码 |
| BOM | 42 | 产品与材料关系，12 条标为关键物料 |
| 工艺路线 | 15 | 3 个产品各 5 步；来源均注明演示标准工时 |
| 库存与在途 | 42 | 已有物料的库存快照；14 条在途各 30，总计 420 |
| 客户供应商 | 8 | 客户/供应商引用 |
| 销售订单 | 6 | 5 张正式订单、1 张沙盒待评估插单 |
| 在制任务 | 5 | 已完成/执行中/等待等既有生产事实 |
| 排产参数 | 5 | 21 天周期、24 小时冻结、晚班默认关闭等 |
| 插单场景 | 10 | SO-006 的评估条件；不是第二张新订单 |
| 数据校验 | 14 | 工作簿的自检摘要；不能替代实际导入验证 |
原始表格定位：设备 A1:J16；人员技能 A1:I27；班次日历 A1:G4；产品 A1:H4；物料 A1:I43；BOM A1:G43；工艺路线 A1:I16；库存与在途 A1:H43；销售订单 A1:L7；在制任务 A1:H6。
3. 当前导入器的实际结果
验证使用当前工作区 preview_file、analyze_work_dir、apply_import_commit 和 check_readiness。关闭演示业务种子，使用 empty_world 和临时目录中的源文件副本；仅在内存中导入，不调用排产、发布或外部接口。
3.1 两个入口结果不同
- 通用预览：187 行通过、70 行报错，canCommit=true。
- 项目目录分析：165 条识别记录、3 条问题、89 条跳过，canSchedule=true。
- 目录统计：设备 15、物料类记录 87、BOM 42、工艺 15、订单 6。
- 实际导入后：45 个物料、15 台设备、42 条 BOM、15 条工艺、6 张订单。
“物料 87”来自产品 3 + 物料档案 42 + 库存记录 42，不是 87 个不同物料。页面应区分读取记录数与业务对象数。设备 15 已受前轮分类计数修复影响，不再显示整份工作簿 165 行。
通用预览会把工厂资源和客户供应商当作材料，目录路径会将其跳过；两条入口均未完整消费工作簿语义，不能选择更好看的统计作为完整导入成功的证据。
3.2 已复现的语义丢失
| 源文件的含义 | 当前导入结果 | 应修复的行为 |
|---|---|---|
| 5 张正式订单 + SO-006 沙盒插单 | 6 张全部成为 RELEASED 柔性订单 | 只导入 5 张正式单；SO-006 保存为独立待评估场景，确认前不参与正式排产 |
| 白班、关闭晚班、设备保养 | 班次日历 3 行全部解析失败；使用空世界自带的白班，maintenance=0 | 分开解析班次和维护事件；保留启停状态；提示数据来自原表还是系统默认 |
| 26 名人员及技能 | 被跳过；flexTeams=0，无人员排产资料 | 导入人员与技能引用，建立经核对的班组容量；不把人员当非排产无关数据丢弃 |
| 5 条在制任务 | 被跳过；没有载入对应执行记录 | 关联订单、工序和设备，保留已完成量及在制占用，避免从零重复安排 |
| 14 条在途各 30，预计 2026-08-07 到货 | 导入后没有任何正数 inTransit，合计变为 0 | 保留数量和到货日期，未知日期与数量 0 分开处理 |
| 12 条关键物料标记、部分 2% 损耗 | 所有 isKey=false；导入 BOM 行不含损耗字段 | 保留关键性和损耗语义，校验单套用量与需求计算 |
| 15 条工艺来源为演示标准工时 | stdTimeSource 全部缺失；readiness 报 timeInferred=0 | 保留来源，标记未现场确认，不能默认称实测工时 |
| 工厂层级、客户/供应商、21 天计划参数和 24 小时冻结 | 多数被跳过或没有映射到对应对象 | 明确各表的输入用途；被忽略的业务资料逐项解释，不仅显示“非排产数据” |
虽然有这些缺口，当前 readiness 仍返回总订单 6、可排 6、阻断 0、globalIssues 为空。因此本文件是检验“数据能解析”和“业务含义完整”差别的直接样本。
单位还应核对：物料表原单位 PCS，在库存表再次覆盖后导入为“件”。PCS 与件可能等价，但这种变化来自缺字段默认填充，不能作为未来任意单位转换规则。部分模型缺失字段不应覆盖已有主数据值。
4. 针对这份文件的第一轮完成标准
- 一个入口上传完整文件，保存文件标识/哈希，后续分析与排产使用同一批数据。
- 明确识别 16 个工作表的用途，45 个物料、15 台设备、42 条 BOM、15 道工艺的业务数量正确。
- 5 张正式订单与 1 个待评估插单分开；同一插单在两张工作表出现不重复创建。
- 班次、休息、默认关闭晚班和设备维护完整导入；不能用默认白班掩盖原表解析失败。
- 在途合计 420、12 条关键物料及工时来源不丢失；库存表只更新库存相关字段。
- 人员技能、在制任务和计划参数进入明确的标准对象，不能用忽略记录跳过这些关键业务输入。
- 导入后的工艺/物料/设备可在界面修改，算法读取相同对象；重复导入不复制主数据。
- 用 2026-08-04 的历史场景日期回放，并保留原订单交期。当前日期为 2026-09-09，不能直接以今天试排再把所有超期都归因于算法。
- 数据完整前只报告缺口，不以 canSchedule=true 代替验收；后续求解仍保持试排，不向工厂下发。
5. 当前交付边界
本次完成指定文件定位、原始表内容核对、当前导入器隔离验证和第一轮验收基准。尚未修复上述导入语义缺陷，也没有修改源工作簿、默认项目数据、环境配置或 Git 提交。
这份工作簿可以直接用于本轮开发验收，但现场生产放行仍需要确认文件内明确标为演示补充的订单、库存和标准工时。不能只因用户指定了真实输入文件，就自动把所有补充值升级为生产事实。