S0 列表迁移修正方案

面向 S0 内容迁移持续使用。当前目标已明确为 复刻原平台业务语义，但仍需避免把“纯查询结果”误建成业务实体表。后续每次新增一个原平台列表，先识别该列表属于 实体模型、聚合模型 还是 查询模型，再决定目标实现方式并登记。

零、使用约定

项	约定
使用场景	原平台为低代码平台，列表可能直接绑定 SQL；目标平台为 `Admin.NET + SqlSugar + 前后端分离`
当前问题	AI 容易把“列表查询结果”误识别成“独立实体表”
当前迁移目标	以复刻原平台对象语义为优先，不以沿用现有抽象命名为优先
本文目标	建立统一判定标准，避免误建模；同时明确在“复刻优先”前提下该如何落地
执行方式	每次只处理一个列表；先判定归类，再决定是否建表 / 建聚合 / 建查询接口
与现有 S0 的关系	已落地的 `Batch2 产销建模`、`Batch3 制造建模` 作为参考边界；但当其与源平台语义冲突时，优先服从“复刻目标”

1. 文档信息

文档名称：S0 列表迁移修正方案
文档版本：v0.2
创建日期：2026-04-09
最后更新日期：2026-04-09
当前状态：启用中
负责人：待补充
参与角色：产品 / 开发 / 测试 / 业务方
关联链接：
- S0迁移.md
- Batch2-产销建模迁移方案.md
- Batch3-制造建模迁移方案.md

2. 项目背景

2.1 背景说明

原平台为低代码平台，很多页面列表直接绑定 SQL 查询，页面本身不一定对应真实业务实体。迁移到 AiDOPWarehouse 后，目标系统不再是“页面直接查 SQL”，而是“数据库实体 + 后端接口 + 前端页面”的结构。

当前迁移目标已经明确：

优先复刻原平台的对象语义、表语义、字段语义
但不把纯查询结果误当成业务实体

因此，后续判断标准不再是“尽量贴现有代码抽象”，而是：

如果原平台背后是明确的主数据表/业务表，优先向源表语义收敛。
如果原平台背后只是 SQL 拼装结果，仍按查询模型处理。
如果现有 S0 模型与源平台语义冲突，应优先评估是否回到源模型，而不是优先迁就现有实现。

2.2 当前痛点

原平台列表可能只是多表 join、统计、过滤后的结果，不具备独立生命周期。
AI 容易根据页面字段自动生成独立实体表，导致实体边界膨胀。
后续一旦按错误建模开发，接口、菜单、前端页面、数据迁移都会一起偏掉。

2.3 机会或价值

统一“实体模型 / 聚合模型 / 查询模型”的判断标准。
在“复刻优先”前提下，明确哪些对象应该整体切到源表语义。
后续每收到一个列表即可快速归类、记录、执行，不再反复讨论建模边界。

3. 总体目标

3.1 总体目标

为 S0 列表迁移建立一套稳定的修正规则，确保低代码平台中的“列表”在“复刻原平台”的目标下：

不会把纯查询结果误建模成独立实体表
不会因为迁就现有抽象命名而偏离源平台对象语义

3.2 具体目标

建立列表识别标准，先区分“写模型”与“读模型”。
为每个列表输出统一结论：按源表语义重建、改为聚合、改为查询接口、或待确认。
在本文中持续维护列表识别台账，作为后续开发依据。
保证复刻后的前端页面在字段标签、按钮文案、标题、列名上默认使用中文业务词汇，不遗留英文技术字段名。
保证复刻后的新实现接管旧路由、旧菜单入口、旧权限标识，而不是额外生成一套并行新入口。
保证被替换的旧页面、旧 API、旧前端调用在切换完成后进入删除或废弃清理范围，不长期并存。

3.3 成功指标

新增列表进入开发前，都能先完成一次归类登记。
不再出现“只是列表查询结果，却先建成实体表”的默认行为。
对于源平台明确的主数据/业务表，方案能默认向源表语义收敛。
当现有 Batch2、Batch3 与源平台冲突时，能明确写出是否回切到源模型。
页面交付后，用户可见界面不出现 ItemNum、ParentItem、WorkCtr 这类直接裸露的英文字段名，除非业务明确要求双语。
页面切换后，原菜单入口和原路由地址继续可用，用户无需记忆新地址。
同一业务对象不长期保留“旧页面 + 新页面”双入口。

3.4 本期不追求的目标

不在本文中直接完成所有列表的最终代码开发。
不对既有已上线模块做无依据的大规模重构。
不在未拿到页面/字段/SQL/操作信息时强行给出高置信度结论。

4. 现有 S0 参考边界

以下边界以仓库当前实现为参考，但不是绝对约束。后续所有新列表优先按“源平台语义”判断，再决定是否复用现有模式。

4.1 已确认属于实体模型 / 聚合模型的正例

模块	典型对象	归类	原因
产销建模	Customer / Material / OrderPriorityRule	实体模型	具备新增、编辑、删除、启停、编码、组织归属等独立生命周期
制造建模	ProductionLine / WorkCenter / PersonSkill 等	实体模型	标准主数据维护页，对应真实业务表
制造建模	BOM / Routing / LinePost / PreprocessElement	聚合模型	不是单表 CRUD，而是头表 + 子表整体保存

4.2 已确认属于查询模型的正例

模块	典型对象	归类	原因
看板 / KPI	`AidopKanbanController` 下各类指标、告警、模块明细	查询模型	直接 SQL 查询，面向展示，无独立业务写入
纯展示聚合页	文档中明确“不迁移纯展示类聚合大屏”	查询模型	只读，不形成业务主数据

4.3 核心原则

现有 S0 的经验不是“一个列表一个表”，但在当前“复刻优先”目标下，需要补充下面的覆盖规则：

有独立业务生命周期的内容，落为实体或聚合。
只是为了展示、检索、汇总、统计的内容，落为查询模型。
先看业务对象本身，再看页面形式；不能按页面反推建表。

4.4 复刻优先覆盖规则

当原平台信息足够明确时，按以下优先级决策：

源平台对象语义优先于现有抽象命名
- 如果原平台背后就是 CustMaster、ItemMaster、LineMaster、StdOpMaster 这类明确主表，目标方案应优先向这些主表语义收敛。
源平台写模型优先于现有近似模型
- 如果现有 S0 已有“相近但不等价”的模型，只能作为迁移基础，不能直接视为已经对齐。
查询展示字段不改变主模型归类
- 左联码表、名称表、说明表得到的展示字段，通常只进查询 DTO，不应因此把主数据误判为查询模型。
出现建模冲突时，先做路线决策
- 像 BOM、工艺路线这类对象，若现有实现与源平台语义层级不同，应先明确是否回到源模型，不默认延续旧模型。

4.5 前端复刻强制规则

当方案进入开发执行时，前端必须额外满足以下规则：

页面文案中文化
- 用户可见的页面标题、表单标签、表格列名、按钮文案、提示语、校验信息，应默认使用中文业务术语。
- 英文字段名只允许出现在代码、接口字段、开发注释中，不应直接暴露在用户界面。
- 如果原平台本身是“中文(英文编码)”双语标签，则前端应复刻这种双语格式；如果原平台只有中文，则新页面不得自行补英文。
新实现接管旧入口
- 新页面默认接到旧页面原有路由地址。
- 新接口默认接到旧模块原有前端 API 调用入口或兼容其调用方式。
- 菜单、按钮权限、页面名称默认沿用旧入口，不额外新增一套平行菜单。
旧实现不长期并存
- 若当前任务目标是“替换旧页面”，则旧页面、旧路由占位、旧 API 封装、旧菜单项应进入清理范围。
- 除非方案明确写“短期双轨切换期”，否则默认不允许长期保留新旧两个页面入口。
优先替换，不优先新增
- 对于已有近似模块，默认优先在原模块路径上替换实现，不优先新建 xxx-new、xxxV2、xxxLegacyCopy 之类的新页面。

5. 列表识别判定标准

每次收到一个列表，先回答下面几个问题。

5.1 是否具备独立业务生命周期

满足越多，越偏向实体或聚合：

是否允许单独新增
是否允许单独编辑
是否允许单独删除
是否有启用/禁用、状态、版本、审批等字段
是否会被其他模块引用为主数据
是否脱离当前列表页后仍然成立

如果这些都不明显，通常不是实体。

补充：

如果原平台页面绑定的是单表主数据/业务表，且存在明确表单维护，即使列表 SQL 带少量关联展示字段，也应优先视为实体或聚合，不应因为 LEFT JOIN 就降级成查询模型。

5.2 是否只是查询结果

满足越多，越偏向查询模型：

原平台列表直接绑定 SQL
SQL 来自多表 join
含统计字段、计算字段、派生字段
列表仅用于展示、筛选、导出
没有稳定主键或主键只是临时拼装
页面没有真正的新增/编辑/删除，只是查看详情或跳转

5.3 是否属于聚合而不是单表

满足以下特征时，不应简单建成“一个列表一个实体”：

页面保存时同时维护头数据和多行子数据
子行不单独存在，必须依附头对象
更新时常见“删除旧子行，再全量插入新子行”
业务语义是“一个对象下包含多个明细”

这类应参照 BOM、工艺路线、线体岗位、前处理要素。

6. 识别结论分类

每个列表最终只落到以下 6 类中的 1 类。

分类	名称	说明	目标实现
A	实体主表	真实业务对象，具备独立生命周期	建实体表 + DTO + Controller + 页面
B	聚合头表	头表本身独立，但必须带子项整体保存	建头表/子表 + 聚合接口 + 聚合页面
C	聚合子表	子项不单独成资源，只依附头表存在	不单独建菜单和资源，纳入聚合保存
D	实体查询页	基于已有实体的列表视图	不新增表；补查询 DTO / 筛选接口 / 前端页
E	查询模型	纯 SQL/拼装/统计结果	建只读接口、DTO、必要时视图或查询服务，不建业务实体表
F	待确认	信息不足，无法安全判断	先登记，待补 SQL / 页面操作 / 业务规则

7. 各类修正动作

7.1 若判定为 A：实体主表

执行方式：

建 SqlSugar 实体表
建 QueryDto / UpsertDto
建标准 CRUD Controller
建前端列表页和表单页
纳入菜单与 InitTables
前端页面标题、字段标签、按钮文案按原平台中文业务词汇复刻
新页面优先接原模块旧路由和旧菜单入口
切换完成后，旧页面与旧接口进入清理范围

适用前提：

对象本身是主数据、规则、配置、档案、业务单据等真实对象
不是查询结果拼装

7.2 若判定为 B：聚合头表

执行方式：

建头表实体
建子表实体
建聚合 Upsert DTO
控制器按“头 + 子项整体保存”实现
前端页按主子表编辑
前端主子表标题、列名、按钮文案按原平台中文业务词汇复刻
新聚合页面优先接原模块旧路由和旧菜单入口
切换完成后，旧聚合页面与旧接口进入清理范围

适用前提：

页面保存语义是整体提交
子项没有独立菜单和独立生命周期

7.3 若判定为 C：聚合子表

执行方式：

不单独建菜单
不单独建标准 CRUD 资源
作为聚合请求体中的子数组维护

适用前提：

子项脱离头对象后没有业务意义

7.4 若判定为 D：实体查询页

执行方式：

不新增“列表专用实体表”
先确认现有实体是否已与源平台语义对齐
若未对齐，则在保留模块边界前提下，整体向源表语义重做表名、字段名、DTO、实体和页面字段
基于对齐后的实体补列表过滤、分页、排序、展示字段
必要时补充只读 DTO
前端页面直接消费查询接口
页面字段标签默认中文化；若原平台是“双语标签”，则按原格式复刻
若当前已有旧页面，则新实现优先替换旧页面并接管旧路由、旧菜单、旧权限
不允许为了复刻再额外挂一套平行页面入口

适用前提：

列表只是已有实体的不同展示方式
数据源仍来自已有主表
或者原平台对象明确是单表主数据，但当前项目已有一个“近似模块”可承接，适合在该模块内按源语义重构

7.5 若判定为 E：查询模型

执行方式：

不建业务实体表
建只读 DTO / VO
后端用查询接口实现
可选：使用 SQL、视图、查询服务、读模型对象
前端列表页只做查询、筛选、导出，不做业务写入
页面标题、列名、筛选项默认中文化，不直接暴露英文数据库字段名
若是替换旧查询页，则优先接管旧路由与旧菜单入口
切换完成后，旧查询页进入清理范围

适用前提：

原平台列表本质上是 SQL 查询结果
数据来自多个实体拼装或统计
页面没有独立写入语义

7.6 若判定为 F：待确认

执行方式：

先登记台账
补齐最少信息后再判定
禁止在信息不足时先建实体表

最少补充信息：

列表名称
页面用途
是否支持新增/编辑/删除
原 SQL 或数据来源
列表字段
详情/保存行为

8. 单个列表处理流程

后续每个列表统一按以下顺序处理：

接收列表信息
至少包含：列表名称、页面用途、字段、按钮操作、原 SQL 或来源说明。
先判断源平台背后是不是明确主表/主对象
若是，优先按“复刻该主表语义”思考；若否，再继续判断是否只是查询结果。
判断是否有独立生命周期
若有，继续判断是单实体还是聚合；若无，优先判断为查询模型。
判断是否多表拼装 / 统计 / 计算结果
若是，优先归入查询模型，不默认建表。
若现有 S0 模型与源平台冲突，判断是否需要路线决策
例如 BOM、工艺路线这类“现有是聚合，源平台是行级”的对象。
输出初判结论
结论格式统一为：分类 + 理由 + 建议落地方式 + 待确认项。
登记到本文台账
后续开发、复盘、回看统一以台账为准。
若进入开发执行，默认补充三项实现要求
页面中文化、接管旧路由、删除旧页面/旧入口。

9.1 开发执行附加要求

以下要求适用于所有已确认进入开发的列表：

9.1.1 页面文案要求

页面标题、查询条件、表格列名、表单标签、按钮文案、弹窗标题、校验提示必须优先使用中文。
不允许把数据库字段名、DTO 字段名直接当作页面标签。
若原平台页面采用“中文(英文编码)”格式，则按原样复刻；若原平台不是双语，不要擅自加英文。

9.1.2 路由与菜单要求

新页面默认接入旧路由地址。
新页面默认复用旧菜单项、旧权限编码、旧页面入口。
除非方案明确写明“新增入口”，否则不应出现第二个并行菜单。

9.1.3 旧实现清理要求

被替换的旧页面应删除或明确废弃，不长期保留。
被替换的旧 API 调用封装应删除或切到新接口，不长期保留双套调用。
被替换的旧菜单项、旧临时路由、旧占位页应进入清理清单。

9. 你后续每次发我列表时，建议提供的信息

信息越完整，判定越快；但不是必须一次全齐。

9.1 最少信息

列表名称
页面是干什么的
页面上有哪些按钮：新增、编辑、删除、导出、查看详情、审批等
列表字段

9.2 最好补充的信息

原平台绑定的 SQL
该列表来自哪些表
是否存在详情页或表单页
保存时是改一张表，还是头子一起保存
这个对象会不会被其他模块引用

10. 单条列表识别输出模板

后续每次识别，统一按下面格式输出并登记：

### [列表名称]

- 初判分类：
- 判断依据：
- 建议落地：
- 是否需要新表：
- 是否需要聚合：
- 是否改为查询接口：
- 待确认项：
- 当前结论状态：待确认 / 已确认 / 已落地

11. 列表识别台账

11.1 当前台账

序号	模块	列表名称	原平台特征	初判分类	建议落地方式	结论状态	备注
1	供应	供应商维护列表	主表 `SuppMaster` + 左联 `LocationMaster` 补展示字段 + 表单维护 + 按 `Domain` 过滤	D	保留供应商模块边界，但整体向 `SuppMaster` 语义收敛；查询层补展示字段	待确认	本质是供应商主数据，不是查询模型；对账周期字段在列表中是格式化展示值
2	供应	货源清单列表	主表 `srm_purchase` + 左联 `ic_item` 补物料字段 + 列表维护/导入	D	保留货源清单模块边界，但整体向 `srm_purchase` 语义收敛；查询层补物料展示字段	待确认	本质是供应来源/采购报价维护表，不是查询模型；多表关联主要用于展示
3	仓储	库位维护列表	主表 `LocationMaster` + 表单维护 + 页面内生成货架明细	B	按聚合头表处理；主表向 `LocationMaster` 语义收敛，货架明细纳入整体维护	待确认	这条不是普通单表页；截图已出现“货架明细”与“生成货架明细”区域
4	仓储	成本中心列表	单表 `CostCtrMaster` + 主键 `RecID` + 表单维护 + 按 `Domain` 过滤	D	保留成本中心模块边界，但整体向 `CostCtrMaster` 语义收敛	待确认	本质是成本中心主数据，不是查询模型
5	仓储	条码规则列表	单表 `BarCodeNbr` + 主键 `RecID` + 大字段表单维护	D	保留条码规则模块边界，但整体向 `BarCodeNbr` 语义收敛	待确认	本质是条码规则主数据，不是查询模型；左联供应商仅补展示字段
6	仓储	标签格式列表	主表 `BarCodeType` + 页面含标签元素明细子表	B	按聚合头表处理；主表向 `BarCodeType` 语义收敛，标签元素纳入整体保存	待确认	这条不是普通单表页；截图已出现标签元素明细编辑区
7	仓储	货架列表	主表 `LocationShelfMaster` + 左联 `LocationMaster` 补库位名称	C	按聚合子表处理；作为库位维护下的货架明细资源复刻，保留独立查询视图	待确认	本质是库位下属货架明细，不建议升级为独立主数据模型
8	仓储	部门维护列表	单表 `DepartmentMaster` + 主键 `RecID` + 表单维护 + 按 `Domain` 过滤	D	保留部门模块边界，但整体向 `DepartmentMaster` 语义收敛	待确认	本质是部门主数据，不是查询模型
9	仓储	雇员列表	主表 `EmployeeMaster` + 左联 `DepartmentMaster` / `GeneralizedCodeMaster` 补展示 + 表单维护	D	保留雇员模块边界，但整体向 `EmployeeMaster` 语义收敛；查询层补部门与岗位展示字段	待确认	本质是雇员主数据，不是查询模型；多表关联主要用于展示
10	仓储	单号类型列表	主表 `NbrTypeMaster` + 左联 `DepartmentMaster` 补部门描述	D	保留单号类型模块边界，但整体向 `NbrTypeMaster` 语义收敛；查询层补部门展示字段	待确认	本质是单号类型主数据，不是查询模型
11	仓储	单号规则维护列表	单表 `NbrControl` + 主键 `RecID` + 表单维护	D	保留单号规则模块边界，但整体向 `NbrControl` 语义收敛	待确认	本质是单号规则主数据，不是查询模型
12	仓储	物料状态任务指派	主表 `wms_rwzp` + 页面含头信息和子表明细区 + 流程动作	B	按聚合头表处理；保持任务指派单据语义，头信息和物料明细整体提交	待确认	虽然表单属性指向单表，但页面明显是主子结构和流程单据，不宜降级成普通单表列表
13	仓储	物料职责维护	主表 `EmpWorkDutyMaster` + 左联 `EmployeeMaster` / `LocationMaster` / `LineMaster` 补展示 + 区间物料编码职责维护	D	保留物料职责模块边界，但整体向 `EmpWorkDutyMaster` 语义收敛；查询层补雇员/库位/产线/职责展示字段	待确认	本质是职责分配维护表，不是查询模型；多表关联主要用于展示
14	仓储	零件包装规格列表	主表 `ItemPackMaster` + 左联 `ItemMaster` 补物料名称型号	D	保留零件包装规格模块边界，但整体向 `ItemPackMaster` 语义收敛；查询层补物料展示字段	待确认	本质是包装规格主数据，不是查询模型；多表关联主要用于展示
15	质量	原材料检验规范	主表 `qms_jygf` + 页面含附件与子表明细	B	按聚合头表处理；主表向 `qms_jygf` 语义收敛，检验明细纳入整体保存	待确认	页面存在附件导入和子表区，不应按普通单表页处理
16	质量	原材料白名单	单表 `qms_lymjbmd` + 主键 `id` + 表单维护	D	保留原材料白名单模块边界，但整体向 `qms_lymjbmd` 语义收敛	待确认	本质是免检白名单主数据，不是查询模型
17	质量	抽样方案	单表 `qms_sampscheme` + 主键 `id` + 表单维护	D	保留抽样方案模块边界，但整体向 `qms_sampscheme` 语义收敛	待确认	本质是抽样方案主数据，不是查询模型
18	质量	检验仪器	单表 `qms_inspectioninstru` + 主键 `id` + 表单维护	D	保留检验仪器模块边界，但整体向 `qms_inspectioninstru` 语义收敛	待确认	本质是检验仪器主数据，不是查询模型
19	质量	检验依据	主表 `qms_inspectioncrit` + 页面含技术文档明细子表	B	按聚合头表处理；主表向 `qms_inspectioncrit` 语义收敛，技术文档纳入整体保存	待确认	页面存在“技术文档”子表，不应按单表页处理
20	质量	检验方案	主表 `qms_inspectpro` + 页面含方案设置子表	B	按聚合头表处理；主表向 `qms_inspectpro` 语义收敛，方案设置明细纳入整体保存	待确认	页面存在“检验方案设置”子表，不应按单表页处理
21	质量	检验方法	单表 `qms_inspection_method` + 主键 `id` + 表单维护	D	保留检验方法模块边界，但整体向 `qms_inspection_method` 语义收敛	待确认	本质是检验方法主数据，不是查询模型
22	质量	检验标准	主表 `qms_inspectionstd` + 页面含检验项目子表	B	按聚合头表处理；主表向 `qms_inspectionstd` 语义收敛，检验项目明细纳入整体保存	待确认	页面存在“检验项目”子表，不应按单表页处理
23	质量	检验项目	单表 `qms_inspectionitems` + 主键 `id` + 表单维护	D	保留检验项目模块边界，但整体向 `qms_inspectionitems` 语义收敛	待确认	本质是检验项目主数据，不是查询模型
24	质量	检验频率	单表 `qms_inspectionfreq` + 主键 `id` + 表单维护	D	保留检验频率模块边界，但整体向 `qms_inspectionfreq` 语义收敛	待确认	本质是检验频率主数据，不是查询模型
25	质量	过程检验规范	主表 `qms_gcjygf` + 页面含附件与子表明细	B	按聚合头表处理；主表向 `qms_gcjygf` 语义收敛，检验明细纳入整体保存	待确认	页面存在附件导入和子表区，不应按普通单表页处理
26	质量	质量字典	QMS 左侧字典树导航页 + 多类字典入口聚合	E	不新建业务实体表；作为质量字典导航页复刻，复用下层字典资源	待确认	这是导航/入口页，不是单一业务表单

11.2 已登记明细

11.2.1 供应商维护列表

来源模块：供应
页面名称：供应商维护列表
原表单名：供应商维护表单
原表名：SuppMaster
关联表：LocationMaster
主键：RecID
原平台特征：列表页支持查询、添加、编辑、查看、删除；表单属性截图显示数据表为 SuppMaster - 供应商主数据、主键为 RecID；列表 SQL 以供应商主表为主，左联库位表补“供应商库位”展示，并将对账周期起止日格式化为中文文本
初判分类：D 实体查询页
判断依据：
- 它不是统计报表，也不是纯查询结果，不属于查询模型
- 它背后是明确的供应商主数据表，具备独立表单维护形态
- 左联 LocationMaster 和对账周期格式化逻辑只影响展示，不改变其主数据实体归类
建议落地：
- 保留供应商维护模块边界，不新建“列表专用实体表”
- 在复刻优先前提下，整体向 SuppMaster 语义收敛
- 列表里的 LocationName、APStartDay1Text、APEndDay1Text、APStartDay2Text、APEndDay2Text 只放查询 DTO，不落主表
- 页面文案按原页面中文化复刻，新实现接旧路由、旧菜单、旧权限入口，切换后清理旧页面/旧调用
是否需要新表：否
是否需要聚合：否
是否改为查询接口：否；优先使用实体分页接口并补展示 DTO
当前识别到的源字段：
- 主表字段：Supp、SortName、PurContact、CrTerms、Curr、TaxIn、TaxClass、APStartDay1、APEndDay1、APStartDay2、APEndDay2、Remark、Type、IsActive、RecID
- 展示字段：LocationName、APStartDay1/APEndDay1/APStartDay2/APEndDay2 的中文格式化文本
- 隐藏字段：Domain、CreateTime、CreateUser、UpdateTime、UpdateUser
- 页面能力：查询、添加、编辑、查看、删除

MySQL 版列表 SQL：

SELECT
s.RecID AS id,
s.Supp,
s.SortName,
s.CrTerms,
s.Curr,
s.Type,
s.TaxIn,
s.TaxClass,
TRIM(CONCAT(l.Location, ' ', IFNULL(l.Descr, ''))) AS LocationName,
CASE
    WHEN s.APStartDay1 = 0 THEN ''
    ELSE CONCAT(
        CASE WHEN s.APStartDay1 > 200 THEN '下月' ELSE '每月' END,
        REPLACE(RIGHT(CAST(s.APStartDay1 AS CHAR(10)), 2), '31', '最后'),
        '日'
    )
END AS APStartDay1Text,
CASE
    WHEN s.APEndDay1 = 0 THEN ''
    ELSE CONCAT(
        CASE WHEN s.APEndDay1 > 200 THEN '下月' ELSE '每月' END,
        REPLACE(RIGHT(CAST(s.APEndDay1 AS CHAR(10)), 2), '31', '最后'),
        '日'
    )
END AS APEndDay1Text,
CASE
    WHEN s.APStartDay2 = 0 THEN ''
    ELSE CONCAT(
        CASE WHEN s.APStartDay2 > 200 THEN '下月' ELSE '每月' END,
        REPLACE(RIGHT(CAST(s.APStartDay2 AS CHAR(10)), 2), '31', '最后'),
        '日'
    )
END AS APStartDay2Text,
CASE
    WHEN s.APEndDay2 = 0 THEN ''
    ELSE CONCAT(
        CASE WHEN s.APEndDay2 > 200 THEN '下月' ELSE '每月' END,
        REPLACE(RIGHT(CAST(s.APEndDay2 AS CHAR(10)), 2), '31', '最后'),
        '日'
    )
END AS APEndDay2Text
FROM SuppMaster s
LEFT JOIN LocationMaster l
ON s.Domain = l.Domain
AND s.PurContact = l.Location
WHERE s.Domain = ?;

当前建议映射：
- Supp -> 供应商编码
- SortName -> 简称
- PurContact -> 供应商库位
- CrTerms -> 支付方式
- Curr -> 币别
- TaxIn -> 含税
- TaxClass -> 税类型
- APStartDay1 / APEndDay1 -> 对账周期1开始 / 结束
- APStartDay2 / APEndDay2 -> 对账周期2开始 / 结束
- Remark -> 备注
- Type -> 供应商类型
- LocationName -> 供应商库位展示字段
- 对账周期格式化字段 -> 列表展示文本
待确认项：
- Type 在当前页面是否要展示或只做隐藏字段
- PurContact 是否保存库位编码
- CrTerms、Curr、TaxClass 是否来自统一字典
- APStartDay* / APEndDay* 的真实输入控件和存储规则
当前结论状态：待确认
关联修改方案：供应建模/供应商维护方案.md

11.2.2 货源清单列表

来源模块：供应
页面名称：货源清单
原表单名：货源清单表单
原表名：srm_purchase
关联表：ic_item
主键：id
原平台特征：列表页支持查询、添加、导出 Excel、货源清单导入；表单属性截图显示数据表为 srm_purchase - 物料采购报价、主键为 Id；列表 SQL 以采购报价主表为主，左联 ic_item 获取物料编码、型号、单位等展示字段
初判分类：D 实体查询页
判断依据：
- 它不是统计报表，也不是纯查询结果，不属于查询模型
- 它背后是明确的采购货源/报价维护表，具备独立表单维护形态
- 左联 ic_item 只是补充物料展示信息，不改变主表实体归类
建议落地：
- 保留货源清单模块边界，不新建“列表专用实体表”
- 在复刻优先前提下，整体向 srm_purchase 语义收敛
- 列表里的 number、model、unit、icitem、supplier 只放查询 DTO，不落主表
- 页面文案按原页面中文化复刻，新实现接旧路由、旧菜单、旧权限入口，切换后清理旧页面/旧调用
是否需要新表：否
是否需要聚合：否
是否改为查询接口：否；优先使用实体分页接口并补展示 DTO
当前识别到的源字段：
- 主表字段：id、tenant_id、factory_id、icitem_id、icitem_name、supplier_type、is_active、supplier_id、supplier_name、supplier_number、order_price、currency_type、taxrate、tariff、freight、price_terms、effective_date、expiring_date、quota_rate、lead_time、qty_min、packaging_qty、order_rector_name、order_rector_num、IsRequireGoods
- 展示字段：number、model、unit、icitem、supplier
- 隐藏字段：company_id、create_time、create_by_name
- 页面能力：查询、添加、导出 Excel、货源清单导入、编辑、删除

MySQL 版列表 SQL：

SELECT
sp.id,
sp.tenant_id,
sp.factory_id,
sp.icitem_id,
it.number,
sp.icitem_name,
'原材料' AS item_type,
it.model,
it.unit,
sp.supplier_type,
sp.is_active,
sp.supplier_id,
sp.supplier_name,
sp.supplier_number,
sp.order_price,
sp.currency_type,
IFNULL(sp.taxrate, 0) AS taxrate,
IFNULL(sp.tariff, 0) AS tariff,
sp.freight,
sp.price_terms,
sp.effective_date,
sp.expiring_date,
IFNULL(sp.quota_rate, 0) AS quota_rate,
sp.lead_time,
sp.qty_min,
sp.packaging_qty,
sp.order_rector_name,
sp.order_rector_num,
CONCAT(it.number, sp.icitem_name) AS icitem,
CONCAT(sp.supplier_name, sp.supplier_number) AS supplier,
sp.IsRequireGoods
FROM srm_purchase sp
LEFT JOIN ic_item it
ON sp.icitem_id = it.Id;

当前建议映射：
- number -> 物料编码
- icitem_name -> 物料名称
- item_type -> 物料类别
- model -> 规格型号
- unit -> 订货单位
- supplier_type -> 供应类别
- is_active -> 是否失效/启用状态
- IsRequireGoods -> 采购类型
- supplier_number -> 供应商编码
- supplier_name -> 供应商名称
- order_price -> 价格
- currency_type -> 币种
- taxrate -> 增值税率(%)
- tariff -> 关税(%)
- freight -> 运费
- price_terms -> 价格条款
- effective_date / expiring_date -> 生效日期 / 失效日期
- quota_rate -> 配额比例(%)
- lead_time -> 采购前置期(天)
- qty_min -> 最小订货数量
- packaging_qty -> 每箱包装数量
待确认项：
- is_active 在页面上实际表达“是否失效”还是“是否启用”
- IsRequireGoods 的枚举值与中文映射
- supplier_type、currency_type、price_terms 是否来自字典
- netpurc、quota_priority 是否真实存在于表结构但未出现在当前 SQL 中
当前结论状态：待确认
关联修改方案：供应建模/货源清单列表方案.md

11.2.3 库位维护列表

来源模块：仓储
页面名称：库位维护
原表单名：库位维护
主表名：LocationMaster
关联子表：货架明细，待确认真实物理表是否为 LocationShelfMaster
主键：RecID
原平台特征：列表页以库位主表为主；表单属性截图显示数据表为 LocationMaster - 仓库主数据、主键为 RecID；表单中已出现“货架明细”区域和“生成货架明细”动作，说明保存语义不是纯单表 CRUD
初判分类：B 聚合头表
判断依据：
- 主体是明确的库位主数据表
- 页面内直接维护货架明细，且存在批量生成明细动作
- 货架明细脱离库位后没有独立业务意义，更符合主子聚合保存
建议落地：
- 按 LocationMaster 头表 + 货架明细子表的聚合方式复刻
- 不新建“库位列表专用表”
- 列表中的 Sort 仅作为排序/显示辅助字段，不落主表
- 页面继续保持中文化、接旧路由、接旧菜单，并替换旧页面
是否需要新表：否
是否需要聚合：是
是否改为查询接口：否；列表仍基于实体分页接口，货架明细通过聚合接口维护
当前识别到的源字段：
- 主表字段：Location、Descr、Storer、Typed、PhysicalAddress
- 展示/排序字段：Sort
- 表单补充字段：Ufld2（保管员）
- 隐藏字段：Domain、IsActive、RecID、CreateUser、CreateTime、UpdateUser、UpdateTime

MySQL 版列表 SQL：

SELECT
RecID AS id,
Location,
Descr,
Storer,
Typed,
PhysicalAddress,
CASE
    WHEN Typed = 'Supp' THEN 2
    ELSE 0
END AS Sort
FROM LocationMaster
WHERE Domain = ?
AND IsActive = 1;

待确认项：
- “货架明细”是否直接落在 LocationShelfMaster
- Storer、Typed、Ufld2 的中文业务含义
- 生成货架明细时依赖的范围字段和生成规则
当前结论状态：待确认
关联修改方案：仓储方案/库位维护列表方案.md

11.2.4 成本中心列表

来源模块：仓储
页面名称：成本中心
原表名：CostCtrMaster
主键：RecID
原平台特征：列表 SQL 来自单表 CostCtrMaster，按 Domain 过滤，无统计、无复杂拼装
初判分类：D 实体查询页
判断依据：
- 它背后是明确的成本中心主数据表
- 页面语义是成本中心维护，不是只读统计查询
- 当前 SQL 没有多表聚合，不应误判为查询模型
建议落地：
- 保留成本中心模块边界
- 整体向 CostCtrMaster 语义收敛
- 页面中文化，接旧路由与旧菜单，切换后删除旧页面
是否需要新表：否
是否需要聚合：否
是否改为查询接口：否
当前识别到的源字段：
- CostCtr、Descr、Ufld1、EffTime
- 隐藏字段：Domain、RecID

MySQL 版列表 SQL：

SELECT
RecID AS id,
Domain,
CostCtr,
Descr,
Ufld1,
EffTime
FROM CostCtrMaster
WHERE Domain = ?;

待确认项：
- Ufld1 的业务含义，截图疑似“责任人”
- 表单页是否还有 IsActive、审计字段等隐藏字段
当前结论状态：待确认
关联修改方案：仓储方案/成本中心方案.md

11.2.5 条码规则列表

来源模块：仓储
页面名称：条码规则列表
原表单名：条码规则设置
原表名：BarCodeNbr
关联表：SuppMaster
主键：RecID
原平台特征：列表页和表单页都围绕条码规则单表维护；表单字段多，但仍是单记录编辑；左联供应商仅补 SuppName
初判分类：D 实体查询页
判断依据：
- 它背后是明确的条码规则表，不是查询模型
- 页面虽然字段多，但没有主子表整体保存特征
- SuppName 只是展示字段，不改变主表归类
建议落地：
- 保留条码规则模块边界
- 整体向 BarCodeNbr 语义收敛
- 查询层补 SuppName
- 页面中文化，接旧路由与旧菜单，替换旧页面
是否需要新表：否
是否需要聚合：否
是否改为查询接口：否
当前识别到的源字段：
- 主表字段：Customer、Type、WaterRules、WaterLen、Separator、FirmLength、FirmString1 至 FirmString12 及对应长度/备注字段
- 展示字段：SuppName
- 隐藏字段：Domain、RecID
MySQL 版列表 SQL：以 BarCodeNbr 为主表，左联 SuppMaster 取 SortName 作为 SuppName；保留原字段结构迁移
待确认项：
- 需进一步核对 FirmString1 至 FirmString12 对应长度字段的完整清单
- Customer 在本页表达“供应商”还是通用对象编码
当前结论状态：待确认
关联修改方案：仓储方案/条码规则列表方案.md

11.2.6 标签格式列表

来源模块：仓储
页面名称：标签格式列表
原表单名：标签格式设置
主表名：BarCodeType
关联子表：标签元素明细，待确认真实物理表
主键：RecID
原平台特征：表单属性截图显示主表为 BarCodeType - 标签类型；页面中存在标签元素明细表格，可增删明细行
初判分类：B 聚合头表
判断依据：
- 主表是标签格式头对象
- 页面内存在子表级元素编辑，不是纯单表页
- 标签元素脱离标签格式后没有独立业务意义
建议落地：
- 按 BarCodeType 头表 + 标签元素子表聚合复刻
- 不新建“标签格式列表专用表”
- 页面中文化，接旧路由、接旧菜单，并替换旧页面
是否需要新表：否
是否需要聚合：是
是否改为查询接口：否
当前识别到的源字段：
- 头表字段：BarType、Class、InputString
- 子表字段：元素类型、内容、数据字段、X/Y、长/宽、字体等
- 隐藏字段：Domain、RecID

MySQL 版列表 SQL：

SELECT
RecID AS id,
BarType,
Class,
InputString
FROM BarCodeType
WHERE Domain = ?;

待确认项：
- 标签元素明细的真实物理表名与主外键字段
- Class 的中文业务含义和值域
当前结论状态：待确认
关联修改方案：仓储方案/标签格式列表方案.md

11.2.7 货架列表

来源模块：仓储
页面名称：货架列表
原表名：LocationShelfMaster
关联表：LocationMaster
主键：RecID
原平台特征：列表 SQL 以货架明细表为主，左联库位表补充库位名称；页面展示的是库位下的货架数据
初判分类：C 聚合子表
判断依据：
- 货架天然从属于库位，不应升级成独立主数据模型
- 当前页面虽然有独立列表视图，但数据本体仍是库位下属明细
- 左联 LocationMaster 只是为了展示库位名称
建议落地：
- 在目标系统中作为“库位维护”聚合下的子表明细处理
- 如果业务需要保留独立查询入口，可提供只读或轻维护子列表视图，但不单独建主资源
- 页面中文化，接旧路由、接旧菜单，并与库位聚合保持一致
是否需要新表：否
是否需要聚合：作为聚合子表纳入
是否改为查询接口：否；仍以聚合子表方式维护，必要时补子列表查询
当前识别到的源字段：
- 主表字段：InvShelf、Location、Descr、Area
- 展示字段：kwhjname、LocationMaster.Descr

MySQL 版列表 SQL：

SELECT
s.RecID AS id,
s.InvShelf AS hj,
CONCAT(s.Location, ':', s.InvShelf) AS kwhjname,
s.Location,
l.Descr,
s.Descr AS ShelfDescr,
s.Area
FROM LocationShelfMaster s
LEFT JOIN LocationMaster l
ON s.Domain = l.Domain
AND s.Location = l.Location
WHERE s.Domain = ?;

待确认项：
- 货架列表是否允许脱离库位页单独新增编辑
- Area 的业务含义和值域
当前结论状态：待确认
关联修改方案：仓储方案/货架列表方案.md

11.2.8 部门维护列表

来源模块：仓储
页面名称：部门维护列表
原表单名：部门信息
原表名：DepartmentMaster
主键：RecID
原平台特征：列表与表单都围绕 DepartmentMaster 单表维护，按 Domain 和 IsActive 过滤
初判分类：D 实体查询页
判断依据：
- 它背后是明确的部门主数据表
- 页面语义是部门维护，不是查询模型
- 没有主子聚合特征
建议落地：
- 保留部门模块边界
- 整体向 DepartmentMaster 语义收敛
- 页面中文化，接旧路由、接旧菜单，并替换旧页面
是否需要新表：否
是否需要聚合：否
是否改为查询接口：否
当前识别到的源字段：
- 主表字段：Department、Descr
- 隐藏字段：IsActive、IsConfirm、Domain、RecID、CreateUser、CreateTime、UpdateUser、UpdateTime

MySQL 版列表 SQL：

SELECT
RecID AS id,
Department,
Descr
FROM DepartmentMaster
WHERE Domain = ?
AND IsActive = 1;

待确认项：
- 页面是否需要保留 IsConfirm
- Department 是否只是编码，是否另有完整名称字段
当前结论状态：待确认
关联修改方案：仓储方案/部门维护列表方案.md

11.2.9 雇员列表

来源模块：仓储
页面名称：雇员列表
原表单名：雇员信息
原表名：EmployeeMaster
关联表：DepartmentMaster、GeneralizedCodeMaster
主键：RecID
原平台特征：列表 SQL 以 EmployeeMaster 为主，左联部门和岗位字典补展示字段；表单属性截图显示为雇员主数据维护页
初判分类：D 实体查询页
判断依据：
- 它背后是明确的雇员主数据表，不是查询模型
- 部门名称和岗位名称只属于展示补充
- 页面仍是标准表单维护，而不是聚合页
建议落地：
- 保留雇员模块边界
- 整体向 EmployeeMaster 语义收敛
- 查询层补 DepartDescr 与 JobTitle 展示字段
- 页面中文化，接旧路由、接旧菜单，并替换旧页面
是否需要新表：否
是否需要聚合：否
是否改为查询接口：否
当前识别到的源字段：
- 主表字段：Employee、Name、Sex、Phone、Email、BirthDate、Department、DateEmployed、EmploymentStatus、MaritalStatus、JobTitle、DateTerminated、WorkCtr、CarId、DefaultWorkLocation
- 展示字段：DepartDescr、字典翻译后的 JobTitle
- 隐藏字段：Domain、RecID
MySQL 版列表 SQL：以 EmployeeMaster 为主表，左联 DepartmentMaster 取部门名称，左联 GeneralizedCodeMaster 按 FldName='JobTitle' 取岗位名称；过滤条件为 Domain = ? 且 IsActive = 1
待确认项：
- EmploymentStatus、MaritalStatus 是否来自统一字典
- BusinessPhone、City、Country 等字段是否在实际表结构中存在但未出现在当前 SQL
当前结论状态：待确认
关联修改方案：仓储方案/雇员列表方案.md

11.2.10 单号类型列表

来源模块：仓储
页面名称：单号类型维护
原表单名：单号类型
原表名：NbrTypeMaster
关联表：DepartmentMaster
主键：RecID
原平台特征：表单属性截图显示数据表为 NbrTypeMaster；列表 SQL 以单号类型主表为主，左联部门表补部门描述
初判分类：D 实体查询页
判断依据：
- 背后是明确的单号类型主数据表
- 左联部门仅用于展示 DeptDescr
- 页面是标准列表 + 表单维护，不是查询模型
建议落地：
- 保留单号类型模块边界
- 整体向 NbrTypeMaster 语义收敛
- 查询层补 DeptDescr
- 页面中文化，接旧路由、旧菜单并替换旧页面
是否需要新表：否
是否需要聚合：否
是否改为查询接口：否
当前识别到的源字段：
- 主表字段：Dept、NbrClass、NbrType、Descr1
- 展示字段：DeptDescr
- 隐藏字段：Domain、RecID、CreateUser、CreateTime、UpdateUser、UpdateTime、IsActive、IsConfirm

MySQL 版列表 SQL：

SELECT
n.RecID AS id,
n.Dept,
d.Descr AS DeptDescr,
n.NbrClass,
n.NbrType,
n.Descr1
FROM NbrTypeMaster n
LEFT JOIN DepartmentMaster d
ON n.Domain = d.Domain
AND n.Dept = d.Department
WHERE n.Domain = ?
AND n.IsActive = 1;

待确认项：
- NbrClass 的值域与中文映射
- Descr1 是否就是页面中的“类型描述”
当前结论状态：待确认
关联修改方案：仓储方案/单号类型方案.md

11.2.11 单号规则维护列表

来源模块：仓储
页面名称：单号规则维护
原表单名：单号规则维护表单
原表名：NbrControl
主键：RecID
原平台特征：表单属性截图显示数据表为 NbrControl；页面是标准单表规则维护，包含前缀、初始值、最小值、最大值、重置/跳号/手工产生等字段
初判分类：D 实体查询页
判断依据：
- 背后是明确的单号规则表
- 页面无子表，无统计拼装
- 页面语义是规则主数据维护，不是查询模型
建议落地：
- 保留单号规则模块边界
- 整体向 NbrControl 语义收敛
- 页面中文化，接旧路由、旧菜单并替换旧页面
是否需要新表：否
是否需要聚合：否
是否改为查询接口：否
当前识别到的源字段：
- NbrType、Description、NbrPre1、NbrPre2、NbrPre3、IniValue、MinValue、MaxValue、AllowReset、AllowSkip、AllowManual、DateType、IsDateType
- 隐藏字段：Domain、CreateUser、CreateTime、UpdateUser、UpdateTime、RecID、IsActive、IsConfirm

MySQL 版列表 SQL：

SELECT
NbrType,
Description,
NbrPre1,
NbrPre2,
NbrPre3,
IniValue,
MinValue,
MaxValue,
AllowReset,
AllowSkip,
AllowManual,
DateType,
IsDateType,
RecID AS id
FROM NbrControl
WHERE Domain = ?;

待确认项：
- DateType 的枚举值与中文映射
- NbrType 是否必须关联单号类型表做下拉引用
当前结论状态：待确认
关联修改方案：仓储方案/单号规则维护方案.md

11.2.12 物料状态任务指派

来源模块：仓储
页面名称：物料状态任务指派
原表单名：物料状态任务指派
原表名：wms_rwzp
主键：id
原平台特征：表单属性截图显示数据表为 wms_rwzp；页面存在头信息区域和下方子表明细区，并带“处理过程 / 保存 / 发送 / 终止”等流程动作
初判分类：B 聚合头表
判断依据：
- 页面形态是典型单据头 + 明细行结构
- 页面存在流程动作，不是普通单表主数据页
- 虽然源表单属性指向单表，但业务语义明显是任务单据聚合
建议落地：
- 以“任务单头 + 物料明细行”方式复刻页面语义
- 若当前源库只有 wms_rwzp 单表，可先按复刻页面行为设计聚合接口，再评估物理拆表
- 页面中文化，接旧路由、旧菜单并替换旧页面
是否需要新表：待评估
是否需要聚合：是
是否改为查询接口：否
当前识别到的源字段：
- 头字段：tcrq、sqr、rwlx、clr、zt、xqsj
- 明细字段：wlbm、Descr、sl、rqpc、yskw、mdkw、bz

MySQL 版列表 SQL：

SELECT
wp.id,
wp.tcrq,
wp.sqr,
wp.rwlx,
wp.wlbm,
im.Descr,
wp.sl,
wp.rqpc,
wp.yskw,
wp.mdkw,
wp.xqsj,
wp.clr,
wp.bz,
wp.zt
FROM wms_rwzp wp
LEFT JOIN ItemMaster im
ON wp.wlbm = im.ItemNum
AND im.Domain = ?

待确认项：
- 头行与明细行在源库中的真实存储方式
- rwlx、zt 的值域与中文映射
- “发送”“终止”对应的状态流转规则
当前结论状态：待确认
关联修改方案：仓储方案/物料状态任务指派方案.md

11.2.13 物料职责维护

来源模块：仓储
页面名称：物料职责维护
原表单名：物料职责维护表单
原表名：EmpWorkDutyMaster
主键：RecID
原平台特征：表单属性截图显示数据表为 EmpWorkDutyMaster - 员工岗...；页面以雇员、物料编码区间、库位、生产线、职责为核心字段；列表 SQL 以 EmpWorkDutyMaster 为主，左联雇员、库位、产线表补展示字段，并对 Duty 做中文文本转换
初判分类：D 实体查询页
判断依据：
- 背后是明确的职责分配主表
- 页面是标准列表 + 表单维护，不存在子表编辑区
- 左联雇员、库位、产线和职责中文转换都只影响展示，不改变主表归类
建议落地：
- 保留物料职责模块边界
- 整体向 EmpWorkDutyMaster 语义收敛
- 查询层补 EmployeeName、LocationName、LineName、DutyText
- 页面中文化，接旧路由、旧菜单并替换旧页面
是否需要新表：否
是否需要聚合：否
是否改为查询接口：否
当前识别到的源字段：
- 主表字段：Employee、ItemNum1、ItemNum2、Location、ProdLine、Ufld2
- 展示字段：EmployeeName、LocationName、LineName、Duty
- 隐藏字段：Domain、CreateUser、CreateTime、UpdateUser、UpdateTime、RecID、Duty、EmpType

MySQL 版列表 SQL：

SELECT
w.RecID AS id,
w.Employee,
e.Name AS EmployeeName,
w.ItemNum1,
w.ItemNum2,
TRIM(CONCAT(w.Location, ' ', IFNULL(t.Descr, ''))) AS LocationName,
TRIM(CONCAT(w.ProdLine, ' ', IFNULL(l.Describe, ''))) AS LineName,
REPLACE(
    REPLACE(
        REPLACE(
            REPLACE(
                REPLACE(
                    REPLACE(
                        REPLACE(w.Duty, 'iss-po', '采购收货'),
                    'iss-so', '销售发货'),
                'iss-wo', '发料'),
            'packing', '退料'),
        'rct-unp', '计划外入库'),
    'rct-wo', '入库'),
'Up-Shelf', '上架') AS Duty
FROM EmpWorkDutyMaster w
LEFT JOIN LineMaster l
ON w.Domain = l.Domain
AND w.ProdLine = l.Line
LEFT JOIN EmployeeMaster e
ON w.Domain = e.Domain
AND w.Employee = e.Employee
LEFT JOIN LocationMaster t
ON w.Domain = t.Domain
AND w.Location = t.Location
WHERE w.Domain = ?;

待确认项：
- Ufld2、Duty、EmpType 的业务含义
- Duty 是否应拆成原始编码字段和显示文本字段
- EmployeeName、LocationName、LineName 是否只用于列表展示
当前结论状态：待确认
关联修改方案：仓储方案/物料职责维护方案.md

11.2.14 零件包装规格列表

来源模块：仓储
页面名称：物料包装规格维护
原表单名：零件包装规格表单
原表名：ItemPackMaster
关联表：ItemMaster
主键：RecID
原平台特征：表单属性截图显示数据表为 ItemPackMaster；列表 SQL 以包装规格主表为主，左联物料主数据补名称和型号
初判分类：D 实体查询页
判断依据：
- 背后是明确的包装规格主表
- 左联物料表仅补展示字段
- 页面是标准列表 + 表单维护，不是查询模型
建议落地：
- 保留零件包装规格模块边界
- 整体向 ItemPackMaster 语义收敛
- 查询层补 Descr、Descr1
- 页面中文化，接旧路由、旧菜单并替换旧页面
是否需要新表：否
是否需要聚合：否
是否改为查询接口：否
当前识别到的源字段：
- 主表字段：ItemNum、PackingQty、SmallPackingQty、PackingType、NetWeight、WeightUM、Length、Width、High、IssSpecific、CustItem、Remark
- 展示字段：Descr、Descr1
- 隐藏字段：Domain、CreateUser、CreateTime、UpdateUser、UpdateTime、IsActive、IsConfirm、RecID

MySQL 版列表 SQL：

SELECT
p.RecID AS id,
p.ItemNum,
p.PackingQty,
p.SmallPackingQty,
p.PackingType,
p.NetWeight,
p.WeightUM,
p.Length,
p.Width,
p.High,
p.IssSpecific,
p.CustItem,
p.Remark,
i.Descr,
i.Descr1
FROM ItemPackMaster p
LEFT JOIN ItemMaster i
ON p.Domain = i.Domain
AND p.ItemNum = i.ItemNum
WHERE p.Domain = ?
AND p.IsActive = 1;

待确认项：
- IssSpecific 的中文业务含义和值域
- PackingType、WeightUM 是否来自统一字典
当前结论状态：待确认
关联修改方案：仓储方案/零件包装规格方案.md | 1 | 产销 | 客户维护列表 | 单表 CustMaster + 主键 RecID + 表单维护 + 按 Domain 过滤 | D | 保留客户模块边界，但整体向 CustMaster 语义收敛；不新建列表专用表 | 待确认 | 本质是客户主数据，不是查询模型；当前目标是复刻，不再优先迁就 Customer 抽象命名 | | 2 | 产销 | 物料维护列表 | 主表 ItemMaster + 主键 RecID + 表单维护 + 左联 LocationMaster 补展示字段 | D | 保留物料模块边界，但整体向 ItemMaster 语义收敛；查询层补展示字段 | 待确认 | 本质是物料主数据；LocationDescr 属于查询展示字段，不应单独建表 | | 3 | 产销 | 订单优先级列表 | 单表 PriorityCode + 主键 RecID + 表单维护 + 按 Domain 与 IsActive 过滤 | D | 保留优先级模块边界，但整体向 PriorityCode 语义收敛 | 待确认 | 本质是优先级配置主数据，不是查询模型；OrderBy 为枚举展示字段 | | 4 | 制造 | 标准BOM维护列表 | 主表 ProductStructureMaster + 左联 ItemMaster / 聚合 ProductStructureOp + 行级维护 | F | 进入路线决策；在“复刻优先”前提下默认优先评估回到 ProductStructureMaster 行级语义 | 待确认 | 原平台更像 BOM 行表维护，和现有 Batch3 的 BOM 头子聚合模型不一致 | | 5 | 制造 | 标准工序维护列表 | 单表 StdOpMaster + 主键 RecID + 表单维护 + 按 Domain 过滤 | D | 保留标准工序模块边界，但整体向 StdOpMaster 语义收敛 | 待确认 | 本质是标准工序主数据，不是查询模型；字段较少，适合直接源语义收敛 | | 6 | 制造 | 生产线维护列表 | 主表 LineMaster + 主键 RecID + 左联 GeneralizedCodeMaster 翻译码值 + 按 Domain 过滤 | D | 保留生产线模块边界，但整体向 LineMaster 语义收敛；查询层补码表展示字段 | 待确认 | 本质是生产线主数据；WorkshopComments/LineCategoryComments 属于码表翻译字段，不应单独建表 | | 7 | 制造 | 标准工艺流程维护列表 | 主表 RoutingOpDetail + 左联 ItemMaster / WorkCtrMaster + 行级维护 | F | 进入路线决策；在“复刻优先”前提下默认优先评估回到 RoutingOpDetail 行级语义 | 待确认 | 原平台更像工艺路线行表维护，和现有 Batch3 的工艺路线头子聚合模型不一致 | | 8 | 制造 | 物料替代关系列表 | 单表 ItemSubstituteDetail + 主键 RecID + 表单维护 + 按 Domain 过滤 | D | 保留物料替代关系模块边界，但整体向 ItemSubstituteDetail 语义收敛 | 待确认 | 本质是物料替代关系主数据，不是查询模型；属于关系型明细表但仍是单表维护 | | 9 | 制造 | 选择替代方案页面 | UNION 常量行 + ic_substitute 查询结果 + 仅查询筛选 | E | 建新查询页与只读接口，不建业务实体表；复刻原页面列与筛选行为 | 待确认 | 这是新页面；本质是选择器/弹窗型读模型，不是主数据维护页 | | 10 | 制造 | 工单控制参数设置 | 单表 WorkOrdControl + TOP 1 单记录读取 + 表单直接保存 | A | 按单记录参数表处理，整体向 WorkOrdControl 语义收敛；页面按配置表单复刻 | 待确认 | 本质是工单控制参数配置，不是列表查询；同域通常只维护一条记录 | | 11 | 制造 | 人员技能维护列表 | 单表 EmpSkills + 主键 RecID + 表单维护 | D | 保留人员技能模块边界，但整体向 EmpSkills 语义收敛 | 待确认 | 本质是员工与技能关系维护表，不是查询模型；属于关系型明细表但仍是单表维护 | | 12 | 制造 | 产线岗位维护列表 | 主表 LineSkillMaster + 左联 LineMaster 补展示 + 页面含“产线岗位技能明细”子表区 | B | 按聚合头表处理；主表向 LineSkillMaster 语义收敛，子表纳入整体保存 | 待确认 | 这条不是普通单表；截图已出现子表区域，应按主子聚合页处理 | | 13 | 制造 | 工作中心维护列表 | 主表 WorkCtrMaster + 左联 DepartmentMaster 补展示字段 | D | 保留工作中心模块边界，但整体向 WorkCtrMaster 语义收敛；查询层补部门展示字段 | 待确认 | 本质是工作中心主数据；DepartmentName 属于查询展示字段，不应单独建表 | | 14 | 制造 | 生产线物料维护列表 | 主表 ProdLineDetail + 左联 RoutingOpDetail / rf_dictionary / WorkCtrMaster 补展示字段 | D | 保留生产线物料模块边界，但整体向 ProdLineDetail 语义收敛；查询层补展示字段 | 待确认 | 本质是生产线物料能力维护表，不是查询模型；多表关联主要用于展示 | | 15 | 制造 | 生产要素参数列表 | 主表 DevMonitor + CodeType='Prod' 条件过滤 | D | 保留生产要素参数模块边界，但整体向 DevMonitor 语义收敛；按 CodeType 固定条件查询 | 待确认 | 本质是生产要素参数主数据，不是查询模型；CodeType='Prod' 是业务分组条件 | | 16 | 制造 | 物料工序生产要素列表 | 主表 ItemOpCondition + 左联 ItemMaster / RoutingOpDetail / GeneralizedCodeMaster 补展示 | D | 保留物料工序生产要素模块边界，但整体向 ItemOpCondition 语义收敛；按 CodeType='Prod' 固定条件查询 | 待确认 | 本质是物料工序生产要素维护表，不是查询模型；多表关联主要用于展示 | | 17 | 制造 | 物料前处理要素列表 | 主表 ItemOpCondition + 左联 ItemMaster / GeneralizedCodeMaster 补展示 | D | 保留物料前处理要素模块边界，但整体向 ItemOpCondition 语义收敛；按 CodeType='PrevProcess' 固定条件查询 | 待确认 | 本质是物料前处理要素维护表，不是查询模型；与“物料工序生产要素”共用主表但业务分组不同 | | 18 | 制造 | 前处理要素参数列表 | 主表 DevMonitor + CodeType='PrevProcess' 条件过滤 | D | 保留前处理要素参数模块边界，但整体向 DevMonitor 语义收敛；按 CodeType 固定条件查询 | 待确认 | 本质是前处理要素参数主数据，不是查询模型；与“生产要素参数”共用主表但业务分组不同 | | 19 | 制造 | SOP维护列表 | 主表 QualitySegmentImage + 左联 ImageType / LineMaster / RoutingOpDetail 补展示 | D | 保留 SOP 维护模块边界，但整体向 QualitySegmentImage 语义收敛；查询层补展示字段 | 待确认 | 本质是 SOP 文件维护表，不是查询模型；多表关联主要用于展示 | | 20 | 制造 | SOP文件类型维护列表 | 单表 ImageType + 主键 RecID | D | 保留 SOP 文件类型模块边界，但整体向 ImageType 语义收敛 | 待确认 | 本质是 SOP 文件类型主数据，不是查询模型 |

11.2 台账字段说明

字段	说明
模块	如产销、制造、仓储、质量、供应等
列表名称	原平台页面名称或用户约定名称
原平台特征	例如“SQL 直查”“主子表保存”“单表 CRUD”“统计报表”
初判分类	A/B/C/D/E/F
建议落地方式	实体、聚合、查询接口、视图、DTO 等
结论状态	待确认 / 已确认 / 已落地
备注	缺失信息、风险点、业务确认结果

11.3 已登记明细

11.3.1 客户维护列表

来源模块：产销
原表名：CustMaster
主键：RecID
原平台特征：表单属性截图显示数据表为“CustMaster - 客户主数据”，主键为“RecID - 自增列”；列表 SQL 仅来自单表，并按 Domain 做工厂过滤
初判分类：D 实体查询页
判断依据：
- 它不是统计报表，也不是多表拼装结果，不属于查询模型
- 它背后是明确的客户主数据表，具备表单维护形态
- 当前目标工程中已存在 AdoS0Customer，因此不建议再新建一张“客户维护列表实体表”
建议落地：
- 复用现有 Customer 建模与页面
- 将该列表视为“客户主数据在低代码平台中的一个列表视图”
- 若源字段与现有 AdoS0Customer 不一致，则补字段映射或补充字段，而不是新建独立表
是否需要新表：否
是否需要聚合：否
是否改为查询接口：否，优先复用现有 Customer 分页接口；仅在筛选或展示字段不足时扩展查询 DTO
当前识别到的源字段：
- 列表 SQL：RecID、Cust、SortName、Curr、Slspsn1、Slspsn2、ShipTo、Remarks
- 关联表单字段：Cust、SortName、Curr、ShipTo、TaxClass、TaxIn、Slspsn1、Class、Remarks
- 隐藏字段：IsActive、IsConfirm、Domain、RecID、CreateUser、CreateTime、UpdateUser、UpdateTime

MySQL 版列表 SQL：

SELECT
c.RecID AS id,
c.Cust,
c.SortName,
c.Curr,
c.Slspsn1,
c.Slspsn2,
c.ShipTo,
c.Remarks
FROM CustMaster c
WHERE c.Domain = ?;

当前建议映射：
- RecID -> Id
- Domain -> 待确认映射到 FactoryRefId 还是工厂编码字段
- Cust -> 倾向客户编码
- SortName -> 待确认映射到 Name 还是 ShortName
- Curr -> Currency
- Slspsn1 / Slspsn2 -> PrimarySales / BackupSales
- ShipTo -> 当前目标缺失，建议补字段评估
- TaxClass -> 当前目标缺失，建议补字段评估
- TaxIn -> 可映射 IsTaxIncluded
- Class -> 可映射 CustomerLevel，但需确认类型和值域
- Remarks -> Remark
待确认项：
- Cust 是否只是编码，是否另有客户名称字段
- SortName 是否应进入 Name、ShortName，还是保留为独立字段
- Domain 在原系统中是工厂编码、工厂主键还是租户域值
- ShipTo、TaxClass 是否属于客户主数据必须字段，是否需要回补到现有 AdoS0Customer
- IsActive、IsConfirm 是否需要映射到现有 IsEnabled / 审核状态
当前结论状态：待确认
关联修改方案：字段映射修改/客户维护字段映射修改方案.md

11.3.2 物料维护列表

来源模块：产销
原表名：ItemMaster
主键：RecID
原平台特征：表单属性截图显示数据表为 ItemMaster，主键为 RecID；列表 SQL 以 ItemMaster 为主表，左联 LocationMaster 仅补充库位描述字段
初判分类：D 实体查询页
判断依据：
- 主体仍是明确的物料主数据表，不是统计报表
- 左联 LocationMaster 仅用于展示 LocationDescr，不改变其“物料主数据”本质
- 当前目标工程中已存在 AdoS0Material，因此不建议再新建一张“物料维护列表实体表”
建议落地：
- 复用现有 Material 模块
- 将当前模块整体向 ItemMaster 语义收敛，而不是继续沿用抽象的 Material 字段体系
- 列表中的 LocationDescr 作为查询展示字段处理，不进入独立业务表
是否需要新表：否
是否需要聚合：否
是否改为查询接口：否；优先保留物料主数据资源，仅补列表展示字段和筛选能力
当前识别到的源字段：
- 列表 SQL：RecID、ItemNum、Descr、PkgCode、Descr1、CreateTime、UM、PurMfg、Drawing、ItemType、Location、DefaultShelf、KeyItem、NetWeight、NetWeightUM、Inspect、PurLT、InsLT、MfgLT、Length、Size、SizeUM、IssuePolicy、IsMainMas、LocationType、CommodityCode、Rev、MaxOrd、MinOrd、OrdMult、MinOrdSales、AutoLotNums、Install、SafetyStk、DaysBetweenPM、LotSerialControl、AllocateSingleLot、Status、Planner、Remark、LocationDescr、IsActive
- 表单截图字段：ItemNum、Descr、Descr1、UM、PurMfg、Drawing、ItemType、Location、DefaultShelf、KeyItem、NetWeight、NetWeightUM、Inspect、InsLT、PurLT、Length、Size、SizeUM、IssuePolicy、MFGMTTR、LocationType、CommodityCode、Rev、MaxOrd、MinOrd、OrdMult、MinOrdSales、AutoLotNums、Install、SafetyStk、DaysBetweenPM、ExpireAlarmDay、StockTurnOver、LotSerialControl、AllocateSingleLot、Status、TraceDetail、IsMainMas、Remark、EMTType、IsActive、PkgCode、OwnerApplication、BOMDesign、RoutingDes
- 隐藏字段：Domain、RecID、CreateUser、CreateTime、UpdateUser、UpdateTime、IsConfirm

MySQL 版列表 SQL：

SELECT
i.RecID AS id,
i.ItemNum,
i.Descr,
i.PkgCode,
i.Descr1,
i.CreateTime,
i.UM,
i.PurMfg,
i.Drawing,
i.ItemType,
i.Location,
i.DefaultShelf,
i.KeyItem,
i.NetWeight,
i.NetWeightUM,
i.Inspect,
i.PurLT,
i.InsLT,
i.MfgLT,
i.Length,
i.Size,
i.SizeUM,
i.IssuePolicy,
i.IsMainMas,
i.LocationType,
i.CommodityCode,
i.Rev,
i.MaxOrd,
i.MinOrd,
i.OrdMult,
i.MinOrdSales,
i.AutoLotNums,
i.Install,
i.SafetyStk,
i.DaysBetweenPM,
i.LotSerialControl,
i.AllocateSingleLot,
i.Status,
i.Planner,
i.Remark,
TRIM(CONCAT(i.Location, ' ', IFNULL(l.Descr, ''))) AS LocationDescr,
i.IsActive
FROM ItemMaster i
LEFT JOIN LocationMaster l
ON i.Domain = l.Domain
AND i.Location = l.Location;

当前建议映射：
- RecID -> Id
- Domain -> 待确认映射为 DomainCode 或与 FactoryRefId 的转换依据
- ItemNum -> 倾向物料编码主字段
- Descr -> 倾向物料名称主字段
- Descr1 -> 倾向规格型号
- UM -> 单位
- PurMfg -> P/L 件或采购制造属性
- Drawing -> 图号
- Location / DefaultShelf -> 默认库位 / 默认货架
- Inspect / InsLT -> 检验标记 / 检验天数
- PurLT / MfgLT -> 供应提前期 / 备料提前期
- IssuePolicy -> 是否前处理
- LocationDescr -> 只读查询展示字段
- IsActive -> 启用字段
待确认项：
- PurMfg、IssuePolicy、EMTType 等字段的业务枚举值定义
- KeyItem、TraceDetail、OwnerApplication 是否属于本期必须落地字段
- MFGMTTR、ExpireAlarmDay、BOMDesign、RoutingDes 是否已有现有模块等价字段，还是应新增
- Location / DefaultShelf 当前是直接存编码、ID，还是需接批次仓储模块后重构
- IsConfirm 是否需要单独审核语义，不应混入启用字段
当前结论状态：待确认
关联修改方案：字段映射修改/物料维护字段映射修改方案.md

11.3.3 订单优先级列表

来源模块：产销
原表名：PriorityCode
主键：RecID
原平台特征：表单属性截图显示数据表为 PriorityCode - 优先级配置表，主键为 RecID；列表 SQL 来自单表，并按 Domain、IsActive=1 过滤
初判分类：D 实体查询页
判断依据：
- 它不是统计报表，也不是多表拼装结果，不属于查询模型
- 它背后是明确的优先级配置主数据表，具备表单维护形态
- 当前目标工程中已存在 AdoS0OrderPriorityRule，因此不建议再新建一张“订单优先级列表实体表”
建议落地：
- 复用现有 OrderPriorityRule 模块
- 将当前模块整体向 PriorityCode 语义收敛，而不是继续沿用抽象的 OrderPriorityRule 字段体系
- OrderBy 的“倒序/正序”只作为列表展示映射；底层仍应保留源值
是否需要新表：否
是否需要聚合：否
是否改为查询接口：否；优先保留优先级配置主数据资源，仅补展示转换与筛选能力
当前识别到的源字段：
- 列表 SQL：Descr、Value、Priority、RecID、SourceTable、IsActive、CreateUser、UpdateUser、CreateTime、UpdateTime、OrderBy、Domain、SourceColumn、SourceID、ValueID、SourceType、ValueType
- 表单截图字段：Descr、Priority、OrderBy、SourceTable、SourceColumn、SourceType、SourceID、Value、ValueType、ValueID

MySQL 版列表 SQL：

SELECT
`Descr`,
`Value`,
`Priority`,
`RecID` AS id,
`SourceTable`,
`IsActive`,
`CreateUser`,
`UpdateUser`,
`CreateTime`,
`UpdateTime`,
CASE WHEN `OrderBy` = 0 THEN '倒序' ELSE '正序' END AS `OrderBy`,
`Domain`,
`SourceColumn`,
`SourceID`,
`ValueID`,
`SourceType`,
`ValueType`
FROM `PriorityCode`
WHERE `Domain` = ?
AND `IsActive` = 1;

当前建议映射：
- RecID -> Id
- Domain -> 待确认映射为 DomainCode 或与 FactoryRefId 的转换依据
- Descr -> 倾向规则名称主字段
- Value -> 倾向工单表字段
- Priority -> 优先级
- OrderBy -> 排序方式源值
- SourceTable / SourceColumn / SourceType / SourceID -> 来源表相关字段
- ValueType / ValueID -> 工单表字段类型 / 关联字段
- IsActive -> 启用字段
待确认项：
- OrderBy 在源库中是 0=倒序,1=正序 还是反向定义
- Value 是否就是“工单表字段”，还是表达式/字段名混合
- SourceID、ValueID 是关联字段名、字段编码，还是主键列含义
- SourceType、ValueType 的取值域和业务枚举定义
- 是否存在 IsConfirm、审核流等隐藏字段，只是当前列表未给出
当前结论状态：待确认
关联修改方案：字段映射修改/订单优先级字段映射修改方案.md

11.3.4 标准BOM维护列表

来源模块：制造
原表单名：标准BOM维护表单
原表名：ProductStructureMaster
关联表：ItemMaster、ProductStructureOp
主键：RecID
原平台特征：表单属性截图显示数据表为 ProductStructureMaster、主键为 RecID；列表 SQL 以 BOM 行表为主，左联物料主数据取子项名称，并将 ProductStructureOp 聚合为工序显示值
初判分类：F 待确认
判断依据：
- 它不是简单查询报表，因为存在明确主表与维护表单
- 但它也不是当前 AiDOP/Batch3 已落地的 mfg_bom + mfg_bom_item 头子聚合模型
- 原平台当前更接近“BOM 行级维护”，而不是“BOM 头 + 子项集合整体保存”
- 因此不能直接按现有 AdoS0MfgBom 方案认定为已对齐
建议落地：
- 先单独决策 BOM 建模路线
- 若目标是完全复刻原平台，应以 ProductStructureMaster 为主模型重建
- 若目标是对齐现有 S0 制造建模，应坚持 BOM 头 + BOM 行聚合，并额外做源字段映射转换
是否需要新表：待确认
是否需要聚合：待确认
是否改为查询接口：否；它不是纯展示查询
当前识别到的源字段：
- 主表字段：ParentItem、ComponentItem、UM、StartEff、EndEff、Qty、Op、Refs、Remark、Scrap、QtyConsumed、RecID
- 衍生展示字段：Descr、preStructureType、StructureType
- 隐藏字段：Domain、IsActive、CreateUser、CreateTime、UpdateUser、UpdateTime
- 表单属性信息：表单名 标准BOM维护表单、数据表 ProductStructureMaster、主键 RecID

MySQL 版列表 SQL：

SELECT
pm.ParentItem,
pm.ComponentItem,
im.Descr,
IFNULL(UPPER(ppm.StructureType), '') AS preStructureType,
CASE WHEN UPPER(pm.StructureType) = 'X' THEN '是' ELSE '' END AS StructureType,
pm.UM,
pm.StartEff,
pm.EndEff,
pm.Qty,
CASE
    WHEN UPPER(ppm.StructureType) = 'X' AND UPPER(pm.StructureType) <> 'X' THEN IFNULL(ps.Op, '')
    ELSE CAST(pm.Op AS CHAR(20))
END AS Op,
pm.Refs,
pm.Remark,
pm.Scrap,
pm.QtyConsumed,
pm.RecID AS id
FROM ProductStructureMaster pm
LEFT JOIN ItemMaster im
ON pm.Domain = im.Domain
AND pm.ComponentItem = im.ItemNum
LEFT JOIN (
SELECT Domain, ComponentItem, StructureType
FROM ProductStructureMaster
WHERE UPPER(StructureType) = 'X'
GROUP BY Domain, ComponentItem, StructureType
) ppm
ON pm.Domain = ppm.Domain
AND pm.ParentItem = ppm.ComponentItem
LEFT JOIN (
SELECT
    pp.Domain,
    pp.ParentItem,
    pp.ComponentItem,
    GROUP_CONCAT(CAST(p.Op AS CHAR(20)) ORDER BY p.Op SEPARATOR ',') AS Op
FROM ProductStructureOp pp
LEFT JOIN ProductStructureOp p
    ON p.Domain = pp.Domain
   AND p.ComponentItem = pp.ComponentItem
   AND p.ParentItem = pp.ParentItem
GROUP BY pp.Domain, pp.ParentItem, pp.ComponentItem
) ps
ON pm.Domain = ps.Domain
AND pm.ParentItem = ps.ParentItem
AND pm.ComponentItem = ps.ComponentItem
WHERE pm.Domain = ?;

当前建议映射：
- ParentItem -> 父级物料
- ComponentItem -> 子级物料
- Descr -> 子级物料名称展示字段
- Qty -> 标准用量
- UM -> 单位
- Scrap -> 损耗率
- QtyConsumed -> 固定损耗量
- Op -> 工序；可能来自主表单值，也可能来自 ProductStructureOp 聚合值
- StructureType / preStructureType -> 结构类型衍生展示字段
- StartEff / EndEff -> 生效区间
- Refs / Remark -> 附加字段
待确认项：
- 当前要复刻的是“行级 BOM 维护”，还是要并入现有 Batch3 的“BOM 头子聚合”
- ProductStructureMaster 是否可直接视为 BOM 行表，是否还存在独立 BOM 头信息
- ProductStructureOp 在源系统里是子表，还是只是工序展开表
- StructureType='X' 的业务意义是什么，是否代表虚拟件/预结构
- 若坚持现有 Batch3 聚合模型，ParentItem、ComponentItem、Op 应如何映射到 mfg_bom / mfg_bom_item
当前结论状态：待确认
关联修改方案：字段映射修改/标准BOM字段映射修改方案.md

11.3.5 标准工序维护列表

来源模块：制造
原表单名：标准工序表单
原表名：StdOpMaster
主键：RecID
标题字段：RecID
原平台特征：表单属性截图显示数据表为 StdOpMaster、主键为 RecID、标题字段为 RecID；列表 SQL 为单表全字段查询，并按 Domain 做工厂过滤
初判分类：D 实体查询页
判断依据：
- 它不是统计报表，也不是多表拼装结果，不属于查询模型
- 它背后是明确的标准工序主数据表，具备独立表单维护形态
- 字段规模很小，明显属于标准字典/主数据对象，不需要额外拆成聚合模型
建议落地：
- 复用现有标准工序建模与页面，不新建一张“标准工序列表实体表”
- 将该列表视为“标准工序主数据在低代码平台中的一个列表视图”
- 若现有制造建模中的工序实体字段与源字段不一致，则整体向 StdOpMaster 语义收敛
是否需要新表：否
是否需要聚合：否
是否改为查询接口：否；优先复用实体分页接口
当前识别到的源字段：
- 主表字段：StdOp、MilestoneOp、RecID
- 隐藏字段：Domain、CreateUser、CreateTime、UpdateUser、UpdateTime
- 表单属性信息：表单名 标准工序表单、数据表 StdOpMaster、主键 RecID、标题字段 RecID

MySQL 版列表 SQL：

SELECT
*,
RecID AS id
FROM StdOpMaster
WHERE Domain = ?;

当前建议映射：
- StdOp -> 标准工序名称
- MilestoneOp -> 是否关键工序
- Domain -> 工厂域编码
- RecID -> 主键
- CreateUser / CreateTime / UpdateUser / UpdateTime -> 审计字段
待确认项：
- MilestoneOp 在源系统里是布尔值、字符枚举，还是数字枚举
- StdOpMaster 是否还存在 IsActive、IsConfirm 等隐藏字段，只是当前表单未展示
- 现有 S0 制造建模里标准工序实体与 StdOpMaster 的差异范围有多大
当前结论状态：待确认
关联修改方案：字段映射修改/标准工序字段映射修改方案.md

11.3.6 生产线维护列表

来源模块：制造
原表单名：生产线维护表单
原表名：LineMaster
关联表：GeneralizedCodeMaster
主键：RecID
原平台特征：表单属性截图显示数据表为 LineMaster、主键为 RecID；列表 SQL 以生产线主表为主，左联 GeneralizedCodeMaster 获取车间与产线类别的中文说明，并按 Domain 做工厂过滤
初判分类：D 实体查询页
判断依据：
- 它不是统计报表，也不是多表业务聚合结果，不属于查询模型
- 它背后是明确的生产线主数据表，具备独立表单维护形态
- 两个左联仅用于码值翻译展示，不改变其主数据实体本质
建议落地：
- 复用现有生产线建模与页面，不新建一张“生产线列表实体表”
- 将该列表视为“生产线主数据在低代码平台中的一个列表视图”
- 若现有制造建模中的生产线实体字段与源字段不一致，则整体向 LineMaster 语义收敛
- GeneralizedCodeMaster 的说明字段仅作为查询 DTO 展示字段补充
是否需要新表：否
是否需要聚合：否
是否改为查询接口：否；优先复用实体分页接口，必要时补展示 DTO
当前识别到的源字段：
- 主表字段：Line、Location、Workshop、Describe、LineType、LineCategory、VLocation、Location2、Location3、PickingLocation、MidLocation、IsActive、RecID
- 展示字段：c.Comments AS LineCategoryComments、b.Comments AS WorkshopComments
- 隐藏字段：Domain、CreateUser、CreateTime、UpdateUser、UpdateTime
- 表单属性信息：表单名 生产线维护表单、数据表 LineMaster、主键 RecID

MySQL 版列表 SQL：

SELECT
a.RecID AS id,
a.Line,
a.Location,
a.Workshop,
a.`Describe`,
a.LineType,
c.Comments AS LineCategoryComments,
a.VLocation,
a.Location2,
a.Location3,
a.PickingLocation,
a.MidLocation,
b.Comments AS WorkshopComments
FROM LineMaster a
LEFT JOIN GeneralizedCodeMaster b
ON a.Workshop = b.Val
AND b.FldName = 'workshop'
AND b.Domain = ?
LEFT JOIN GeneralizedCodeMaster c
ON a.Domain = c.Domain
AND c.FldName = 'LineCategory'
AND a.LineCategory = c.Val
WHERE a.Domain = ?;

当前建议映射：
- Line -> 生产线编码/名称主字段
- Describe -> 生产线描述
- LineType -> 产线类型
- LineCategory -> 产线类别源值
- Location -> 库位
- Workshop -> 车间源值
- VLocation / Location2 / Location3 / PickingLocation / MidLocation -> 辅助库位类字段
- LineCategoryComments -> 产线类别名称展示字段
- WorkshopComments -> 车间名称展示字段
- IsActive -> 启用状态
待确认项：
- Line 在源系统里是编码、名称，还是编码兼名称
- Describe 是否就是正式描述主字段，还是备注型字段
- LineType、LineCategory、Workshop 的取值域和码表定义
- VLocation、Location2、Location3、PickingLocation、MidLocation 的业务边界和是否都需要落正式字段
当前结论状态：待确认
关联修改方案：字段映射修改/生产线字段映射修改方案.md

11.3.7 标准工艺流程维护列表

来源模块：制造
原表单名：标准工艺流程维护表单
页面标题：标准工艺路线维护
原表名：RoutingOpDetail
关联表：ItemMaster、WorkCtrMaster
主键：RecID
原平台特征：表单属性截图显示数据表为 RoutingOpDetail - 工序流转、主键为 RecID；列表 SQL 以工艺路线工序行表为主，左联物料主数据与工作中心主数据取展示名称，并按 IsActive=1 过滤
初判分类：F 待确认
判断依据：
- 它不是简单查询报表，因为存在明确主表与维护表单
- 但它也不是当前 AiDOP/Batch3 已落地的 mfg_routing + mfg_routing_operation 头子聚合模型
- 原平台当前更接近“工艺路线行级维护”，而不是“工艺路线头 + 工序行集合整体保存”
- 因此不能直接按现有 AdoS0MfgRouting 方案认定为已对齐
建议落地：
- 先单独决策工艺路线建模路线
- 若目标是完全复刻原平台，应以 RoutingOpDetail 为主模型重建
- 若目标是对齐现有 S0 制造建模，应坚持 工艺路线头 + 工序行聚合，并额外做源字段映射转换
是否需要新表：待确认
是否需要聚合：待确认
是否改为查询接口：否；它不是纯展示查询
当前识别到的源字段：
- 主表字段：Ufld11、Ufld12、IsActive、RoutingCode、Op、Descr、WorkCtr、MilestoneOp、Ufld1、Ufld2、UDeci1、Ufld3、Ufld4、Ufld5、UDeci2、Ufld6、Ufld7、Ufld8、UDeci3、Ufld9、UDeci4、RecID
- 衍生展示字段：ItemName、Model、WorkCtrName
- 隐藏字段：Domain、IsConfirm、CreateUser、CreateTime、UpdateUser、UpdateTime、CommentIndex
- 表单属性信息：表单名 标准工艺流程维护表单、页面标题 标准工艺路线维护、数据表 RoutingOpDetail、主键 RecID

MySQL 版列表 SQL：

SELECT
a.RecID AS id,
a.Domain,
a.Ufld11,
a.Ufld12,
a.IsActive,
a.RoutingCode,
b.Descr AS ItemName,
b.Descr1 AS Model,
a.Op,
a.Descr,
a.WorkCtr,
m.Descr AS WorkCtrName,
a.MilestoneOp,
a.Ufld1,
a.Ufld2,
a.UDeci1,
a.Ufld3,
a.Ufld4,
a.Ufld5,
a.UDeci2,
a.Ufld6,
a.Ufld7,
a.Ufld8,
a.UDeci3,
a.Ufld9,
a.UDeci4
FROM RoutingOpDetail a
LEFT JOIN ItemMaster b
ON a.RoutingCode = b.ItemNum
AND b.Domain = a.Domain
LEFT JOIN WorkCtrMaster m
ON m.Domain = a.Domain
AND m.WorkCtr = a.WorkCtr
WHERE a.IsActive = 1;

当前建议映射：
- Ufld11 -> 工艺路线编码
- Ufld12 -> 工艺路线名称
- RoutingCode -> 物料编码
- ItemName / Model -> 物料名称 / 规格型号展示字段
- Op -> 工序编码
- Descr -> 工序名称
- WorkCtr / WorkCtrName -> 工作中心编码 / 名称
- MilestoneOp -> 报工工序
- Ufld2/UDeci1/Ufld3、Ufld5/UDeci2/Ufld6、Ufld8/UDeci3/Ufld9 -> 活动一/二/三及数量/单位
- UDeci4 -> 基本批量
- Ufld5 或 Ufld7 之外的工序委外/供应商字段需结合表单再次确认
待确认项：
- 当前要复刻的是“行级工艺流程维护”，还是要并入现有 Batch3 的“工艺路线头子聚合”
- RoutingOpDetail 是否可直接视为工艺路线工序行表，是否还存在独立工艺路线头信息
- Ufld1~Ufld12、UDeci1~UDeci4 的完整业务含义及数据类型边界
- MilestoneOp、IsConfirm、CommentIndex 的取值规则
- 若坚持现有 Batch3 聚合模型，Ufld11/Ufld12/RoutingCode/Op/WorkCtr 应如何映射到 mfg_routing / mfg_routing_operation
当前结论状态：待确认
关联修改方案：字段映射修改/标准工艺流程字段映射修改方案.md

11.3.8 物料替代关系列表

来源模块：制造
原表单名：物料替代关系表单
原表名：ItemSubstituteDetail
主键：RecID
原平台特征：表单属性截图显示数据表为 ItemSubstituteDetail、主键为 RecID；列表 SQL 为单表全字段查询，并按 Domain 做工厂过滤
初判分类：D 实体查询页
判断依据：
- 它不是统计报表，也不是多表拼装结果，不属于查询模型
- 它背后是明确的物料替代关系维护表，具备独立表单维护形态
- 虽然它描述的是“关系”，但当前原平台就是单表维护，不是头子聚合保存
建议落地：
- 保留物料替代关系这一独立资源边界，不新建“列表专用实体表”
- 在复刻优先前提下，整体向 ItemSubstituteDetail 语义收敛
- 后续若现有系统已有近似模块，也应以源表字段为准做重构，而不是继续扩展抽象命名
是否需要新表：否
是否需要聚合：否
是否改为查询接口：否；优先使用实体分页接口
当前识别到的源字段：
- 主表字段：ParentItem、ItemNum、SubstituteItem、SubstituteQty、Remark、RecID
- 隐藏字段：Domain、CreateUser、CreateTime、UpdateUser、UpdateTime
- 表单属性信息：表单名 物料替代关系表单、数据表 ItemSubstituteDetail、主键 RecID

MySQL 版列表 SQL：

SELECT
*,
RecID AS id
FROM ItemSubstituteDetail
WHERE Domain = ?;

当前建议映射：
- ParentItem -> 父级物料
- ItemNum -> 物料编码
- SubstituteItem -> 替代物料
- SubstituteQty -> 替代数量
- Remark -> 备注
- Domain -> 工厂域编码
- RecID -> 主键
- CreateUser / CreateTime / UpdateUser / UpdateTime -> 审计字段
待确认项：
- ParentItem 和 ItemNum 的业务边界是否分别表示父项物料与被替代物料
- SubstituteQty 的单位是否默认继承 ItemNum 对应物料单位
- 是否还存在 IsActive、IsConfirm 等隐藏字段，只是当前表单未展示
当前结论状态：待确认
关联修改方案：字段映射修改/物料替代关系字段映射修改方案.md

11.3.9 选择替代方案页面

来源模块：制造
页面类型：新页面
页面名称：选择替代方案
原平台特征：页面截图显示只有查询框和结果表格，无新增/编辑/删除表单；SQL 由一条常量默认行与 ic_substitute 查询结果 UNION 组成，并按 company_id、factory_id、IsDeleted=0 过滤
初判分类：E 查询模型
判断依据：
- 它不是主数据维护表单，没有独立新增/编辑/删除语义
- SQL 明显是拼装后的选择器结果集，包含一条固定默认记录
- 页面用途更像“下拉选择/弹窗选择/方案选择列表”，不是业务主表维护
建议落地：
- 建新查询页和只读接口
- 不建业务实体表，不把该页面结果集误建成 SubstituteScheme 之类的新主表
- 若 ic_substitute 已存在业务表，则接口直接查询该表并补默认行
- 前端页面按原平台列结构与查询行为复刻
是否需要新表：否
是否需要聚合：否
是否改为查询接口：是
当前识别到的源字段：
- 查询字段：substitute_code、substitute_strategy、substitute_mode、create_time
- 衍生字段：id = 1000000000000000001 的默认空白行
- 过滤条件：company_id、factory_id、IsDeleted

MySQL 版列表 SQL：

SELECT
1000000000000000001 AS id,
'' AS substitute_code,
NULL AS substitute_strategy,
NULL AS substitute_mode,
NULL AS create_time
UNION
SELECT
id,
substitute_code,
substitute_strategy,
substitute_mode,
create_time
FROM ic_substitute
WHERE company_id = ?
AND factory_id = ?
AND IsDeleted = 0;

当前建议映射：
- substitute_code -> 替代方案
- substitute_strategy -> 替代策略
- substitute_mode -> 替代方式
- create_time -> 创建时间
- 默认空白行 -> 选择器默认项/空白项
待确认项：
- 默认空白行的真实业务目的，是“允许不选”还是“默认空方案”
- 页面是否只是弹窗选择器，还是后续还会扩成维护页
- substitute_strategy、substitute_mode 的中文枚举映射
- 是否需要按方案编码模糊查询
当前结论状态：待确认
关联修改方案：字段映射修改/选择替代方案页面方案.md

11.3.10 工单控制参数设置

来源模块：制造
页面名称：工单控制参数设置
页面形态：列表页上直接加载并保存的单记录表单
原表名：WorkOrdControl
主键：RecID
原平台特征：前端脚本在页面初始化时隐藏按钮，按 Domain 执行 TOP 1 查询，读取单条 WorkOrdControl 记录回填表单；若无记录则按当前用户和时间准备新增所需审计字段
初判分类：A 实体主表
判断依据：
- 它不是统计报表，也不是多表拼装结果，不属于查询模型
- 它背后是明确的参数配置表，并存在真实写入语义
- 页面虽然不是标准列表 CRUD，而是“单记录配置页”，但本质仍是业务参数主表维护
- 每个 Domain 通常只维护一条记录，属于“单例配置实体”，不是聚合
建议落地：
- 按 WorkOrdControl 单表配置对象复刻
- 页面继续采用“打开即加载、保存时新增或更新同域单条记录”的交互，不强行改成标准列表页
- 后端提供“按 Domain 取当前配置 + 保存当前配置”接口
是否需要新表：否
是否需要聚合：否
是否改为查询接口：否；应提供读取+保存配置接口
当前识别到的源字段：
- 主表字段：PaintingPer、EnteringPer、IssuedInterval、PostVarsatSFC、IsIssued、IsPrintRejectBarcode、IsPrintScrapBarcode、IsQualityConfirm、RecID
- 隐藏字段：IsActive、IsConfirm、CreateUser、CreateTime、UpdateUser、UpdateTime、Domain
- 页面脚本行为：按 Domain 取 TOP 1；无记录时自动准备新增；有记录时按 RecID 回填

MySQL 版查询 SQL：

SELECT
PaintingPer,
EnteringPer,
IssuedInterval,
PostVarsatSFC,
IsIssued,
IsPrintRejectBarcode,
IsPrintScrapBarcode,
IsQualityConfirm,
RecID
FROM WorkOrdControl
WHERE Domain = ?
ORDER BY RecID
LIMIT 1;

当前建议映射：
- EnteringPer -> 工单超报百分比(%)
- PaintingPer -> 计划超报百分比(%)
- IssuedInterval -> 领料间隔时间(H)
- PostVarsatSFC -> 完成数量是否包含不良
- IsIssued -> 是否发料出库模式
- IsPrintRejectBarcode -> 是否产生不良品标签
- IsPrintScrapBarcode -> 是否产生废品标签
- IsQualityConfirm -> 不良品需要品保人员确认
- RecID -> 主键
待确认项：
- 每个 Domain 是否严格只能有一条 WorkOrdControl 记录
- 保存逻辑是否为“有则更新，无则新增”
- IsActive、IsConfirm 是否参与页面逻辑，还是仅做审计/状态保留
- 页面上隐藏的 btn1 原意是什么，是否代表不允许新增多条
当前结论状态：待确认
关联修改方案：字段映射修改/工单控制参数设置方案.md

11.3.11 人员技能维护列表

来源模块：制造
页面名称：人员技能维护
原表名：EmpSkills
主键：RecID
原平台特征：表单属性截图显示数据表为 EmpSkills - 员工技能、主键为 RecID；列表 SQL 为单表查询，页面用于维护员工与技能、等级、效率等关系信息
初判分类：D 实体查询页
判断依据：
- 它不是统计报表，也不是多表拼装结果，不属于查询模型
- 它背后是明确的人员技能关系维护表，具备独立表单维护形态
- 虽然它描述的是“员工-技能关系”，但原平台就是单表维护，不是聚合页
建议落地：
- 保留人员技能维护这一独立资源边界，不新建“列表专用实体表”
- 在复刻优先前提下，整体向 EmpSkills 语义收敛
- 页面字段、查询列、保存字段按原平台中文业务词汇复刻
是否需要新表：否
是否需要聚合：否
是否改为查询接口：否；优先使用实体分页接口
当前识别到的源字段：
- 主表字段：Employee、Site、SkillNo、SkillLevel、EfficiencyCoefficient、DATESKILL、SkillDescription、EmployeeName、EmployeeID、RecID
- 隐藏字段：Domain、CreateUser、CreateTime、UpdateUser、UpdateTime
- 表单属性信息：表单名 人员技能维护、数据表 EmpSkills、主键 RecID

MySQL 版列表 SQL：

SELECT
RecID AS id,
Domain,
EmployeeName,
SkillNo,
Site,
DATESKILL,
CreateUser,
UpdateUser,
CreateTime,
UpdateTime,
EmployeeID,
SkillDescription,
SkillLevel,
EfficiencyCoefficient,
Employee
FROM EmpSkills;

当前建议映射：
- Employee -> 人员编号
- EmployeeName -> 人员名称
- EmployeeID -> 人员内部 ID
- Site -> 工作组
- SkillNo -> 技能编码
- SkillDescription -> 技能描述
- SkillLevel -> 技能等级
- EfficiencyCoefficient -> 生产效率
- DATESKILL -> 取得技能日期/技能日期
- RecID -> 主键
待确认项：
- Employee、EmployeeID、EmployeeName 三者的边界定义
- Site 是工作组、工位组，还是班组
- DATESKILL 的真实业务含义与日期格式
- EfficiencyCoefficient 的取值范围和精度规则
当前结论状态：待确认
关联修改方案：字段映射修改/人员技能维护方案.md

11.3.12 产线岗位维护列表

来源模块：制造
页面名称：产线岗位维护
原表单名：产线岗位维护表单
原表名：LineSkillMaster
关联表：LineMaster
主键：RecID
原平台特征：表单属性截图显示数据表为 LineSkillMaster - 产线技能要...、主键为 RecID；页面除主表字段外，还存在“产线岗位技能明细”子表区；列表 SQL 以主表为主，左联 LineMaster 补生产线描述
初判分类：B 聚合头表
判断依据：
- 页面已明确出现子表区域“产线岗位技能明细”，不是普通单表 CRUD
- 主表字段用于描述岗位头信息，子表用于维护岗位技能明细，符合“头 + 子项整体保存”的聚合特征
- 列表 SQL 虽然只查到主表，但不代表保存语义是单表
建议落地：
- 按主子聚合页处理
- 主表整体向 LineSkillMaster 语义收敛
- 子表不单独建菜单和独立资源，纳入聚合保存
- 左联 LineMaster 得到的生产线描述字段只作为查询展示字段
是否需要新表：否
是否需要聚合：是
是否改为查询接口：否；应提供聚合查询和聚合保存接口
当前识别到的源字段：
- 主表字段：ProdLine、JOBNo、JOBDescr、RecID
- 展示字段：ProdLine + Describe 组合展示生产线
- 隐藏字段：Domain、CreateUser、CreateTime、UpdateUser、UpdateTime
- 页面结构信息：存在“产线岗位技能明细”子表区

MySQL 版列表 SQL：

SELECT
ls.RecID AS id,
ls.Domain,
CONCAT(ls.ProdLine, ' ', lm.`Describe`) AS ProdLine,
ls.JOBNo,
ls.JOBDescr
FROM LineSkillMaster ls
LEFT JOIN LineMaster lm
ON ls.ProdLine = lm.Line
AND ls.Domain = lm.Domain
WHERE ls.Domain = ?;

当前建议映射：
- ProdLine -> 生产线编码
- ProdLine + Describe -> 生产线展示字段
- JOBNo -> 岗位编码
- JOBDescr -> 岗位描述
- Domain -> 工厂编码
- 子表区 -> 产线岗位技能明细集合
待确认项：
- 子表真实表名和字段结构
- 保存时是“头表 + 子表整体提交”还是子表单独保存
- ProdLine 在页面上是保存编码还是保存“编码+描述”组合值
- LineSkillMaster 是否仅是头表命名，还是本身包含部分技能字段
当前结论状态：待确认
关联修改方案：字段映射修改/产线岗位维护方案.md

11.3.13 工作中心维护列表

来源模块：制造
页面名称：工作中心维护
原表单名：工作中心表单
原表名：WorkCtrMaster
关联表：DepartmentMaster
主键：RecID
原平台特征：表单属性截图显示数据表为 WorkCtrMaster、主键为 RecID；列表 SQL 以工作中心主表为主，左联 DepartmentMaster 取部门展示名称
初判分类：D 实体查询页
判断依据：
- 它不是统计报表，也不是多表业务拼装结果，不属于查询模型
- 它背后是明确的工作中心主数据表，具备独立表单维护形态
- 左联部门表只是补展示字段，不改变主数据实体归类
建议落地：
- 保留工作中心模块边界，不新建“列表专用实体表”
- 在复刻优先前提下，整体向 WorkCtrMaster 语义收敛
- DepartmentName 只作为查询展示字段，不落主表
是否需要新表：否
是否需要聚合：否
是否改为查询接口：否；优先使用实体分页接口
当前识别到的源字段：
- 主表字段：WorkCtr、Descr、Department、IsActive、RecID
- 展示字段：DepartmentName
- 隐藏字段：Domain、CreateUser、CreateTime、UpdateUser、UpdateTime
- 表单属性信息：表单名 工作中心表单、数据表 WorkCtrMaster、主键 RecID、标题字段 RecID

MySQL 版列表 SQL：

SELECT
a.RecID AS id,
a.WorkCtr,
a.Descr,
a.Department,
CONCAT(b.Department, ' ', b.Descr) AS DepartmentName,
a.IsActive,
a.CreateUser,
a.CreateTime,
a.UpdateUser,
a.UpdateTime
FROM WorkCtrMaster a
LEFT JOIN DepartmentMaster b
ON b.Department = a.Department
AND b.Domain = ?;

当前建议映射：
- WorkCtr -> 工作中心编码
- Descr -> 工作中心描述
- Department -> 所属部门编码
- DepartmentName -> 所属部门展示字段
- IsActive -> 状态
待确认项：
- IsActive 的真实取值范围
- Department 是否保存部门编码
- DepartmentMaster 是否仅用于展示，不参与保存校验
当前结论状态：待确认
关联修改方案：字段映射修改2/工作中心维护方案.md

11.3.14 生产线物料维护列表

来源模块：制造
页面名称：生产线物料维护
原表单名：生产线物料维护表单
原表名：ProdLineDetail
关联表：RoutingOpDetail、rf_dictionary、WorkCtrMaster
主键：RecID
原平台特征：表单属性截图显示数据表为 ProdLineDetail、主键为 RecID；列表 SQL 以生产线物料主表为主，左联工艺工序、字典和工作中心表补展示字段
初判分类：D 实体查询页
判断依据：
- 它不是统计报表，也不是纯查询结果，不属于查询模型
- 它背后是明确的 ProdLineDetail 单表维护对象，具备独立表单维护形态
- 多表左联主要用于补充工序标准、设备名称、工作中心描述等展示信息
建议落地：
- 保留生产线物料模块边界，不新建“列表专用实体表”
- 在复刻优先前提下，整体向 ProdLineDetail 语义收敛
- 展示字段放查询 DTO，不落主表
是否需要新表：否
是否需要聚合：否
是否改为查询接口：否；优先使用实体分页接口
当前识别到的源字段：
- 主表字段：Line、Part、Site、Op、Rate、SetupTime、SkillNo、InternalEquipmentTypeCode、MoldTypeCode、StandardStaffCount、Start、IsActive、IsConfirm、RecID
- 展示字段：Describe、OpStdOp、time1
- 隐藏字段：Domain、CreateUser、CreateTime、UpdateUser、UpdateTime
- 表单属性信息：表单名 生产线物料维护表单、数据表 ProdLineDetail、主键 RecID

MySQL 版列表 SQL：

SELECT
pl.RecID AS id,
pl.Line,
rd.title AS `Describe`,
CONCAT(pl.Site, ' ', wm.Descr) AS Site,
pl.Part,
pl.Rate,
pl.SetupTime,
pl.SkillNo,
IFNULL(pl.SetupTime, 0) * 60 AS time1,
CONCAT(CAST(a.Op AS CHAR(10)), ' ', a.Descr) AS OpStdOp
FROM ProdLineDetail pl
LEFT JOIN RoutingOpDetail a
ON pl.Op = a.Op
AND pl.Part = a.RoutingCode
AND pl.Domain = a.Domain
LEFT JOIN rf_dictionary rd
ON pl.Line = rd.code
AND pl.Line IS NOT NULL
AND pl.Line <> ''
AND TRIM(pl.Line) <> ''
LEFT JOIN WorkCtrMaster wm
ON pl.Domain = wm.Domain
AND pl.Site = wm.WorkCtr
WHERE pl.IsActive = 1;

当前建议映射：
- Part -> 物料编码
- Op -> 工序编码
- Site -> 工作中心编码
- Line -> 设备/生产线编码
- Rate -> 单位标准产能(小时)
- SetupTime -> 换模时间(小时)
- SkillNo -> 员工技能编码
- InternalEquipmentTypeCode -> 厂内设备类型编码
- MoldTypeCode -> 模具类型编码
- StandardStaffCount -> 标准人数
- Describe / OpStdOp / time1 -> 展示派生字段
待确认项：
- ProdLineDetail 的完整字段结构，尤其 InternalEquipmentTypeCode、MoldTypeCode、StandardStaffCount
- Line 在此表中表示设备还是生产线
- Site 是否严格对应 WorkCtr
- rf_dictionary 中 title 的字典类型约束
当前结论状态：待确认
关联修改方案：字段映射修改2/生产线物料维护方案.md

11.3.15 生产要素参数列表

来源模块：制造
页面名称：生产要素参数
原表单名：生产要素参数表单
原表名：DevMonitor
主键：RecID
原平台特征：表单属性截图显示数据表为 DevMonitor - 生产设备信息...、主键为 RecID；列表 SQL 为单表查询，并固定按 CodeType='Prod' 与 Domain 过滤
初判分类：D 实体查询页
判断依据：
- 它不是统计报表，也不是多表拼装结果，不属于查询模型
- 它背后是明确的参数维护表，具备独立表单维护形态
- CodeType='Prod' 只是从同一主表中切出“生产要素参数”这一业务子集，不改变其单表维护本质
建议落地：
- 保留生产要素参数模块边界，不新建“列表专用实体表”
- 在复刻优先前提下，整体向 DevMonitor 语义收敛
- 通过固定筛选条件 CodeType='Prod' 输出当前页面数据
是否需要新表：否
是否需要聚合：否
是否改为查询接口：否；优先使用实体分页接口并固定带 CodeType='Prod'
当前识别到的源字段：
- 主表字段：DeviceNumber、DeviceDescr、MessageCode、CodeDescr、ValueType、StdValue、TopLimit、LowLimit、Ufld1、UM、RecID
- 隐藏字段：Domain、CreateUser、CreateTime、UpdateUser、UpdateTime、CodeType
- 表单属性信息：表单名 生产要素参数表单、数据表 DevMonitor、主键 RecID

MySQL 版列表 SQL：

SELECT
m.RecID AS id,
m.DeviceNumber,
m.DeviceDescr,
m.MessageCode,
m.CodeDescr,
m.ValueType,
m.StdValue,
m.TopLimit,
m.LowLimit,
m.Ufld1,
m.UM
FROM DevMonitor m
WHERE m.Domain = ?
AND m.CodeType = 'Prod';

当前建议映射：
- DeviceNumber -> 要素编码
- DeviceDescr -> 要素描述
- MessageCode -> 参数编码
- CodeDescr -> 参数描述
- ValueType -> 值类型
- StdValue -> 标准值
- TopLimit -> 上限值
- LowLimit -> 下限值
- Ufld1 -> 值选择数据
- UM -> 单位
- CodeType -> 参数分组类型，当前固定为 Prod
待确认项：
- DevMonitor 是否还有其它 CodeType 页面共用同一张表
- Ufld1 的真实业务含义和存储格式
- ValueType 的枚举范围
- StdValue、TopLimit、LowLimit 的精度规则
当前结论状态：待确认
关联修改方案：字段映射修改2/生产要素参数方案.md

11.3.16 物料工序生产要素列表

来源模块：制造
页面名称：物料工序生产要素
原表单名：物料工序生产要素表单
原表名：ItemOpCondition
关联表：ItemMaster、RoutingOpDetail、GeneralizedCodeMaster
主键：RecID
原平台特征：表单属性截图显示数据表为 ItemOpCondition、主键为 RecID；列表 SQL 以主表为主，左联物料、工序和码表获取展示字段，并固定按 CodeType='Prod' 和 Domain 过滤
初判分类：D 实体查询页
判断依据：
- 它不是统计报表，也不是多表拼装结果，不属于查询模型
- 它背后是明确的 ItemOpCondition 单表维护对象，具备独立表单维护形态
- 多表左联主要用于补充物料名称、工序名称和类型名称展示，不改变主表实体归类
建议落地：
- 保留物料工序生产要素模块边界，不新建“列表专用实体表”
- 在复刻优先前提下，整体向 ItemOpCondition 语义收敛
- 页面查询固定带 CodeType='Prod'
- 展示字段放查询 DTO，不落主表
是否需要新表：否
是否需要聚合：否
是否改为查询接口：否；优先使用实体分页接口并固定带 CodeType='Prod'
当前识别到的源字段：
- 主表字段：ItemNum、Op、Line、Typed、ItemCode、Descr、IsMain、RecID
- 展示字段：ItemDescr、OpDescr、TypedDescr
- 隐藏字段：Domain、CreateUser、CreateTime、UpdateUser、UpdateTime、CodeType
- 表单属性信息：表单名 物料工序生产要素表单、数据表 ItemOpCondition、主键 RecID

MySQL 版列表 SQL：

SELECT
c.RecID AS id,
c.ItemNum,
i.Descr AS ItemDescr,
c.Op,
r.Descr AS OpDescr,
c.Line,
c.Typed,
g.Comments AS TypedDescr,
c.ItemCode,
c.Descr,
c.IsMain
FROM ItemOpCondition c
LEFT JOIN ItemMaster i
ON c.Domain = i.Domain
AND c.ItemNum = i.ItemNum
LEFT JOIN RoutingOpDetail r
ON c.Domain = r.Domain
AND c.ItemNum = r.RoutingCode
AND c.Op = r.Op
LEFT JOIN GeneralizedCodeMaster g
ON c.Domain = g.Domain
AND c.Typed = g.Val
AND g.FldName = 'OpConditionType'
WHERE c.Domain = ?
AND c.CodeType = 'Prod';

当前建议映射：
- ItemNum -> 物料编码
- ItemDescr -> 物料名称展示字段
- Op -> 工序编码
- OpDescr -> 工序名称展示字段
- Line -> 生产线
- Typed -> 类型编码
- TypedDescr -> 类型名称展示字段
- ItemCode -> 要素编码
- Descr -> 描述
- IsMain -> 是否关键
- CodeType -> 当前固定为 Prod
待确认项：
- ItemCode 的真实业务含义，是生产要素编码还是条件编码
- Typed 的码表取值范围与业务含义
- IsMain 的取值范围
- Line 是否保存生产线编码
当前结论状态：待确认
关联修改方案：字段映射修改2/物料工序生产要素方案.md

11.3.17 物料前处理要素列表

来源模块：制造
页面名称：物料前处理要素维护
原表单名：物料前处理要素
原表名：ItemOpCondition
关联表：ItemMaster、GeneralizedCodeMaster
主键：RecID
原平台特征：表单属性截图显示数据表为 ItemOpCondition - 物料工序加...、主键为 RecID；列表 SQL 以主表为主，左联物料与码表获取展示字段，并固定按 CodeType='PrevProcess' 与 Domain 过滤
初判分类：D 实体查询页
判断依据：
- 它不是统计报表，也不是多表拼装结果，不属于查询模型
- 它背后是明确的 ItemOpCondition 单表维护对象，具备独立表单维护形态
- 只是通过 CodeType='PrevProcess' 切出“前处理要素”业务子集
建议落地：
- 保留物料前处理要素模块边界，不新建“列表专用实体表”
- 在复刻优先前提下，整体向 ItemOpCondition 语义收敛
- 页面查询固定带 CodeType='PrevProcess'
- 展示字段放查询 DTO，不落主表
是否需要新表：否
是否需要聚合：否
是否改为查询接口：否；优先使用实体分页接口并固定带 CodeType='PrevProcess'
当前识别到的源字段：
- 主表字段：ItemNum、Op、ItemCode、Descr、IsMain、RecID
- 展示字段：ItemDescr、OpDescr
- 隐藏字段：Domain、CreateUser、CreateTime、UpdateUser、UpdateTime、CodeType
- 表单属性信息：表单名 物料前处理要素、数据表 ItemOpCondition、主键 RecID

MySQL 版列表 SQL：

SELECT
c.RecID AS id,
c.ItemNum,
i.Descr AS ItemDescr,
c.Op,
r.Comments AS OpDescr,
c.ItemCode,
c.Descr,
c.IsMain
FROM ItemOpCondition c
LEFT JOIN ItemMaster i
ON c.Domain = i.Domain
AND c.ItemNum = i.ItemNum
LEFT JOIN GeneralizedCodeMaster r
ON c.Domain = r.Domain
AND r.FldName = 'PrevProcessOp'
AND c.Op = r.Val
WHERE c.Domain = ?
AND c.CodeType = 'PrevProcess';

当前建议映射：
- ItemNum -> 物料编码
- ItemDescr -> 物料名称展示字段
- Op -> 工序/前处理工序编码
- OpDescr -> 工序名称展示字段
- ItemCode -> 要素编码
- Descr -> 要素描述
- IsMain -> 是否关键
- CodeType -> 当前固定为 PrevProcess
待确认项：
- ItemCode 的真实业务含义
- PrevProcessOp 字典的取值范围
- IsMain 的取值规则
- 是否还存在被注释掉的 Typed / TypedDescr 字段业务要求
当前结论状态：待确认
关联修改方案：字段映射修改2/物料前处理要素方案.md

11.3.18 前处理要素参数列表

来源模块：制造
页面名称：前处理要素参数维护
原表单名：前处理要素参数表单
原表名：DevMonitor
主键：RecID
原平台特征：表单属性截图显示数据表为 DevMonitor - 生产设备信息...、主键为 RecID；列表 SQL 为单表查询，并固定按 CodeType='PrevProcess' 与 Domain 过滤
初判分类：D 实体查询页
判断依据：
- 它不是统计报表，也不是多表拼装结果，不属于查询模型
- 它背后是明确的参数维护表，具备独立表单维护形态
- CodeType='PrevProcess' 只是从同一主表中切出“前处理要素参数”这一业务子集
建议落地：
- 保留前处理要素参数模块边界，不新建“列表专用实体表”
- 在复刻优先前提下，整体向 DevMonitor 语义收敛
- 通过固定筛选条件 CodeType='PrevProcess' 输出当前页面数据
是否需要新表：否
是否需要聚合：否
是否改为查询接口：否；优先使用实体分页接口并固定带 CodeType='PrevProcess'
当前识别到的源字段：
- 主表字段：DeviceNumber、Descr、MessageCode、CodeDescr、ValueType、StdValue、TopLimit、LowLimit、Ufld1、UM、RecID
- 隐藏字段：Domain、CreateUser、CreateTime、UpdateUser、UpdateTime、CodeType
- 表单属性信息：表单名 前处理要素参数表单、数据表 DevMonitor、主键 RecID

MySQL 版列表 SQL：

SELECT
m.RecID AS id,
m.DeviceNumber,
m.DeviceDescr AS Descr,
m.MessageCode,
m.CodeDescr,
m.ValueType,
m.StdValue,
m.TopLimit,
m.LowLimit,
m.Ufld1,
m.UM
FROM DevMonitor m
WHERE m.Domain = ?
AND m.CodeType = 'PrevProcess';

当前建议映射：
- DeviceNumber -> 要素编码
- Descr/DeviceDescr -> 要素描述
- MessageCode -> 参数编码
- CodeDescr -> 参数描述
- ValueType -> 值类型
- StdValue -> 标准值
- TopLimit -> 上限值
- LowLimit -> 下限值
- Ufld1 -> 值选择数据
- UM -> 单位
- CodeType -> 当前固定为 PrevProcess
待确认项：
- DeviceDescr 与 Descr 在源表中的真实字段名
- Ufld1 的真实业务含义和输入形式
- ValueType 的枚举范围
- 数值字段的精度规则
当前结论状态：待确认
关联修改方案：字段映射修改2/前处理要素参数方案.md

11.3.19 SOP维护列表

来源模块：制造
页面名称：SOP维护
原表单名：SOP维护表单
原表名：QualitySegmentImage
关联表：ImageType、LineMaster、RoutingOpDetail
主键：RecID
原平台特征：表单属性截图显示数据表为 QualitySegmentImage - 质检...、主键为 RecID；列表 SQL 以主表为主，左联文件类型、产线、工序补展示字段
初判分类：D 实体查询页
判断依据：
- 它不是统计报表，也不是纯查询结果，不属于查询模型
- 它背后是明确的 SOP 文件维护表，具备独立表单维护形态
- 多表左联主要用于补充产线、文件类型、工序展示字段
建议落地：
- 保留 SOP 维护模块边界，不新建“列表专用实体表”
- 在复刻优先前提下，整体向 QualitySegmentImage 语义收敛
- 展示字段放查询 DTO，不落主表
是否需要新表：否
是否需要聚合：否
是否改为查询接口：否；优先使用实体分页接口
当前识别到的源字段：
- 主表字段：Line、ItemNum、Op、Path、Descr、ImageTypeID、Rev、SortID、RecID
- 展示字段：Line + Describe、Op 组合显示、imgType
- 隐藏字段：Domain、CreateUser、CreateTime、UpdateUser、UpdateTime
- 表单属性信息：表单名 SOP维护表单、数据表 QualitySegmentImage、主键 RecID

MySQL 版列表 SQL：

SELECT
q.RecID AS id,
CONCAT(l.Line, ' ', l.`Describe`) AS Line,
q.ItemNum,
CONCAT(CAST(r.Op AS CHAR(10)), ' ', IFNULL(r.Descr, '')) AS Op,
i.Descr AS imgType,
q.Path,
q.Descr,
q.Rev,
q.SortID
FROM QualitySegmentImage q
LEFT JOIN ImageType i
ON q.ImageTypeID = i.ImageTypeID
AND q.Domain = i.Domain
LEFT JOIN LineMaster l
ON q.Line = l.Line
AND q.Domain = l.Domain
LEFT JOIN RoutingOpDetail r
ON q.Op = r.Op
AND q.Domain = r.Domain
AND r.RoutingCode = q.ItemNum
WHERE q.Domain = ?;

当前建议映射：
- Line -> 生产线
- ItemNum -> 物料编码
- Op -> 工序
- ImageTypeID / imgType -> 文件类型编码 / 描述
- Path -> 文件路径
- Descr -> 文件名称
- Rev -> 文件版本
- SortID -> 排序
待确认项：
- Path 是物理路径、相对路径还是文件服务地址
- SortID 的排序规则
- Rev 的版本规则
- 是否需要文件上传而不只是路径录入
当前结论状态：待确认
关联修改方案：字段映射修改2/SOP维护方案.md

11.3.20 SOP文件类型维护列表

来源模块：制造
页面名称：SOP文件类型维护
原表单名：SOP文件类型表单维护
原表名：ImageType
主键：RecID
原平台特征：表单属性截图显示数据表为 ImageType、主键为 RecID；列表 SQL 为单表查询，按 Domain 过滤
初判分类：D 实体查询页
判断依据：
- 它不是统计报表，也不是多表拼装结果，不属于查询模型
- 它背后是明确的 SOP 文件类型主数据表，具备独立表单维护形态
建议落地：
- 保留 SOP 文件类型模块边界，不新建“列表专用实体表”
- 在复刻优先前提下，整体向 ImageType 语义收敛
是否需要新表：否
是否需要聚合：否
是否改为查询接口：否；优先使用实体分页接口
当前识别到的源字段：
- 主表字段：ImageTypeID、Descr、RecID
- 隐藏字段：Domain、CreateUser、CreateTime、UpdateUser、UpdateTime
- 表单属性信息：表单名 SOP文件类型表单维护、数据表 ImageType、主键 RecID

MySQL 版列表 SQL：

SELECT
RecID AS id,
ImageTypeID,
Descr
FROM ImageType
WHERE Domain = ?;

当前建议映射：
- ImageTypeID -> 文件类型编码
- Descr -> 文件类型描述
- RecID -> 主键
待确认项：
- ImageTypeID 是否允许自定义编码
- Descr 是否需要唯一
- 是否还有启用状态字段未在截图中体现
当前结论状态：待确认
关联修改方案：字段映射修改2/SOP文件类型维护方案.md

12. 当前执行规则

从本文启用后，后续每收到一个列表，默认执行以下动作：

先识别，不先建表。
先登记，再开发。
只要存在“它可能只是查询结果”的可能，就优先按查询模型审视。
只有确认具备独立生命周期，才进入实体或聚合建模。

13. 当前理解确认

对后续协作方式的理解如下：

你每次给我发一个原平台列表的内容。
我负责按本文标准帮你识别它属于哪一类。
我会给出理由和建议落地方式。
我会把结果继续记录到这份文档里，作为持续迁移台账。

如果后续你直接发 SQL、字段截图文字版、页面按钮、详情保存逻辑中的任意一种，我都可以开始判定，不要求你一次把信息补全。

14. 20240410 质量建模已登记明细

14.1 原材料检验规范

来源模块：质量
原表名：qms_jygf
主键：id
初判分类：B 聚合头表
判断依据：页面含附件导入和子表区，明显不是单表 CRUD
建议落地：主表按 qms_jygf 复刻，附件和检验明细纳入整体保存
源 SQL：select * from qms_jygf
关联修改方案：质量方案/原材料检验规范方案.md

14.2 原材料白名单

来源模块：质量
原表名：qms_lymjbmd
主键：id
初判分类：D 实体查询页
判断依据：表单属性截图显示单表维护，无子表区
建议落地：整体向 qms_lymjbmd 语义收敛
源 SQL：select * from qms_lymjbmd
关联修改方案：质量方案/原材料白名单方案.md

14.3 抽样方案

来源模块：质量
原表名：qms_sampscheme
主键：id
初判分类：D 实体查询页
判断依据：表单属性截图显示单表维护，无子表区
建议落地：整体向 qms_sampscheme 语义收敛
源 SQL：select * from qms_sampscheme
关联修改方案：质量方案/抽样方案方案.md

14.4 检验仪器

来源模块：质量
原表名：qms_inspectioninstru
主键：id
初判分类：D 实体查询页
判断依据：表单属性截图显示单表维护，无子表区
建议落地：整体向 qms_inspectioninstru 语义收敛
源 SQL：select * from qms_inspectioninstru
关联修改方案：质量方案/检验仪器方案.md

14.5 检验依据

来源模块：质量
原表名：qms_inspectioncrit
主键：id
初判分类：B 聚合头表
判断依据：页面存在“技术文档”明细区和附件列
建议落地：主表按 qms_inspectioncrit 复刻，技术文档作为子表整体保存
源 SQL：select * from qms_inspectioncrit
关联修改方案：质量方案/检验依据方案.md

14.6 检验方案

来源模块：质量
原表名：qms_inspectpro
主键：id
初判分类：B 聚合头表
判断依据：页面存在“检验方案设置”子表
建议落地：主表按 qms_inspectpro 复刻，方案设置明细纳入整体保存
源 SQL：当前 SQL 文件为空，先按页面结构识别
关联修改方案：质量方案/检验方案方案.md

14.7 检验方法

来源模块：质量
原表名：qms_inspection_method
主键：id
初判分类：D 实体查询页
判断依据：表单属性截图显示单表维护，无子表区
建议落地：整体向 qms_inspection_method 语义收敛
源 SQL：select * from qms_inspection_method
关联修改方案：质量方案/检验方法方案.md

14.8 检验标准

来源模块：质量
原表名：qms_inspectionstd
主键：id
初判分类：B 聚合头表
判断依据：页面存在“检验项目”子表区
建议落地：主表按 qms_inspectionstd 复刻，检验项目明细纳入整体保存
源 SQL：select * from qms_inspectionstd
关联修改方案：质量方案/检验标准方案.md

14.9 检验项目

来源模块：质量
原表名：qms_inspectionitems
主键：id
初判分类：D 实体查询页
判断依据：表单属性截图显示单表维护，无子表区
建议落地：整体向 qms_inspectionitems 语义收敛
源 SQL：select * from qms_inspectionitems
关联修改方案：质量方案/检验项目方案.md

14.10 检验频率

来源模块：质量
原表名：qms_inspectionfreq
主键：id
初判分类：D 实体查询页
判断依据：页面结构为标准基础信息表单，无子表区
建议落地：整体向 qms_inspectionfreq 语义收敛
源 SQL：select * from qms_inspectionfreq
关联修改方案：质量方案/检验频率方案.md

14.11 过程检验规范

来源模块：质量
原表名：qms_gcjygf
主键：id
初判分类：B 聚合头表
判断依据：页面含附件导入和子表区，明显不是单表 CRUD
建议落地：主表按 qms_gcjygf 复刻，附件和检验明细纳入整体保存
源 SQL：select * from qms_gcjygf
关联修改方案：质量方案/过程检验规范方案.md

14.12 质量字典

来源模块：质量
页面名称：质量基础
初判分类：E 查询模型
判断依据：这是左侧字典树导航页，不是单一业务表单
建议落地：不新建业务实体表；复刻质量字典导航树，并将下层字典项接到统一字典资源
字典范围：单据类型、业务类型、客诉、检验优先级、产品不合格联络单、8D、NCR、项目管理、生化、CAPA、生产记录清单、检验状态、AQL接受水平、AQL值
关联修改方案：质量方案/质量字典方案.md

S0列表迁移修正方案提示词.md 121 KB History Raw

S0 列表迁移修正方案

零、使用约定

1. 文档信息

2. 项目背景

2.1 背景说明

2.2 当前痛点

2.3 机会或价值

3. 总体目标

3.1 总体目标

3.2 具体目标

3.3 成功指标

3.4 本期不追求的目标

4. 现有 S0 参考边界

4.1 已确认属于实体模型 / 聚合模型的正例

4.2 已确认属于查询模型的正例

4.3 核心原则

4.4 复刻优先覆盖规则

4.5 前端复刻强制规则

5. 列表识别判定标准

5.1 是否具备独立业务生命周期

5.2 是否只是查询结果

5.3 是否属于聚合而不是单表

6. 识别结论分类

7. 各类修正动作

7.1 若判定为 A：实体主表

7.2 若判定为 B：聚合头表

7.3 若判定为 C：聚合子表

7.4 若判定为 D：实体查询页

7.5 若判定为 E：查询模型

7.6 若判定为 F：待确认

8. 单个列表处理流程

9.1 开发执行附加要求

9.1.1 页面文案要求

9.1.2 路由与菜单要求

9.1.3 旧实现清理要求

9. 你后续每次发我列表时，建议提供的信息

9.1 最少信息

9.2 最好补充的信息

10. 单条列表识别输出模板

11. 列表识别台账

11.1 当前台账

11.2 已登记明细

11.2.1 供应商维护列表

11.2.2 货源清单列表

11.2.3 库位维护列表

11.2.4 成本中心列表

11.2.5 条码规则列表

11.2.6 标签格式列表

11.2.7 货架列表

11.2.8 部门维护列表

11.2.9 雇员列表

11.2.10 单号类型列表

11.2.11 单号规则维护列表

11.2.12 物料状态任务指派

11.2.13 物料职责维护

11.2.14 零件包装规格列表

11.2 台账字段说明

11.3 已登记明细

11.3.1 客户维护列表

11.3.2 物料维护列表

11.3.3 订单优先级列表

11.3.4 标准BOM维护列表

11.3.5 标准工序维护列表

11.3.6 生产线维护列表

11.3.7 标准工艺流程维护列表

11.3.8 物料替代关系列表

11.3.9 选择替代方案页面

11.3.10 工单控制参数设置

11.3.11 人员技能维护列表

11.3.12 产线岗位维护列表

11.3.13 工作中心维护列表

11.3.14 生产线物料维护列表

11.3.15 生产要素参数列表

11.3.16 物料工序生产要素列表

11.3.17 物料前处理要素列表

11.3.18 前处理要素参数列表

11.3.19 SOP维护列表

11.3.20 SOP文件类型维护列表

12. 当前执行规则

S0列表迁移修正方案提示词.md 121 KB

History Raw