## 2026-06-27 过程异常管控修改执行日志 1. 读取 `work/修改过程异常管控.docx`，解析到需求要点： - 页面位置：`ProductionManagement/AbnormalControl/index`。 - 原页面添加多个审批人后表现为多级审批，需要改为多选后多人同时看到任务。 - 当前任务只要其中一个审批人同意，即完成当前任务。 - 上传附件功能不正常，需要修改。 - 加工中心 `ProductionManagement/MachiningCenter/index` 与装配中心 `ProductionManagement/AssemblyCenter/index` 也需要统一嵌套该业务页面。 - 测试页面功能时不要产生业务数据。 2. 检查代码结构： - 确认独立异常管控页面位于 `src/views/ProductionManagement/AbnormalControl/index.vue`。 - 确认加工中心内复制了一份异常管控模板和方法。 - 确认装配中心入口原本被注释，且没有完整异常管控弹窗模板。 - 对比其他图纸上传页面，确认文件上传接口需要使用 `DataPDF.params = JSON.stringify(...)` 形式传参，当前异常管控直接传对象是上传异常的重要原因。 3. 前端修改： - 新增复用组件 `src/views/ProductionManagement/components/AbnormalControlPanel.vue`，承载统一异常管控页面。 - 将 `src/views/ProductionManagement/AbnormalControl/index.vue` 改为组件包装页，避免独立页面与中心页面逻辑分叉。 - 在复用组件中将审批人从“添加审批人列表”改为 `el-select multiple` 多选。 - 提交流程时将多个审批人的 ID 和姓名使用英文逗号拼接，继续通过 `审批人ID`、`审批人姓名` 参数提交，兼容原前端调用方式。 - 修复附件上传： - 上传前校验是否已选择附件。 - 按项目已有接口约定传 `params` JSON。 - 传入 `num`、`tableName=流程表`、`worker`、`uploadTime`。 - 增加上传失败回调提示。 - 加工中心新增统一异常管控弹窗，按钮改为打开复用组件。 - 装配中心恢复“异常管控”按钮，并新增统一异常管控弹窗。 - 修复加工中心旧异常管控复制代码中 `handleRowClick` 与主表行点击方法重名的问题，将旧异常管控内部行点击改名，避免覆盖主页面任务选择逻辑。 4. 数据库脚本： - 新增 `db_backups/update_abnormal_control_parallel_approval_20260627.sql`。 - 脚本包含 `sp_创建流程_简化版` 和 `sp_处理审批` 的 `CREATE OR ALTER PROCEDURE`。 - `sp_创建流程_简化版` 支持逗号分隔的多个审批人，并拆分为同一步骤序号的多个 `processing` 节点，使多人同时看到待处理任务。 - `sp_处理审批` 在任意审批人同意时，将同一步骤其他待处理节点同步关闭，并将流程置为 `completed`。 - 脚本只定义存储过程，没有插入或修改业务测试数据；本次未执行该 SQL。 5. 文档归档： - 新建目录 `work/ProductionManagement/WorkHoursCheck`。 - 已将 `work/修改过程异常管控.docx` 移动到 `work/ProductionManagement/WorkHoursCheck/修改过程异常管控.docx`。 6. 验证： - 执行 `npm run build`。 - 构建成功。 - 构建仅出现原项目资源体积较大、Browserslist 数据过期等警告。 - 未调用流程新增、审批、上传等业务接口，因此未产生业务数据。 ## 2026-06-27 过程异常管控复测问题处理日志 1. 根据用户复测反馈重新排查： - 用户发起测试流程时选择了曹元和闫一龙两个审批人，但登录曹元账号后没有看到待处理任务。 - 附件上传仍然不可用。 2. 待办不可见问题定位： - 当前前端提交多个审批人时，会把审批人ID和审批人姓名用英文逗号拼接后传给 `sp_创建流程_简化版`。 - 如果目标数据库仍是旧版存储过程，测试流程可能只生成一条节点记录，节点中的 `审批人ID` 是类似 `曹元ID,闫一龙ID` 的字符串。 - 旧版 `sp_获取待处理任务` 如果按 `审批人ID = 当前登录人ID` 精确匹配，曹元登录时就匹配不到这条节点，所以待办为空。 3. 数据库脚本补充： - 修改 `db_backups/update_abnormal_control_parallel_approval_20260627.sql`。 - 在原有 `sp_创建流程_简化版`、`sp_处理审批` 基础上新增 `sp_获取待处理任务` 的 `CREATE OR ALTER PROCEDURE`。 - 新版 `sp_获取待处理任务` 同时支持： - 新逻辑生成的同一步骤多条待办节点。 - 旧逻辑已生成的逗号分隔审批人ID节点。 - 这样已发起的曹元、闫一龙测试流程，只要目标库执行该脚本，曹元账号也可以按逗号包含关系查询到待办。 4. 附件上传问题修改： - 修改 `src/views/ProductionManagement/components/AbnormalControlPanel.vue`。 - 上传按钮改为只选择附件并记录待上传数量，不再在流程创建前直接上传。 - 流程创建成功并拿到 `新流程ID` 后，再自动调用上传接口。 - 上传参数改为使用真实流程ID：`num = 新流程ID`、`tableName = 流程表`、`worker = 当前用户`、`uploadTime = 当前时间`。 - 使用 `this.$set(this.DataPDF, 'params', JSON.stringify(...))` 设置上传参数，保持与项目已有上传页面的参数传递方式一致。 - 多附件上传按成功回调计数，全部上传完成后清空文件列表和待上传数量。 - 取消附件弹窗时清空已选择附件，避免误带入下次流程。 - 提交流程成功后刷新“我发起的”和“待我处理”列表。 5. 验证： - 修改后执行 `npm run build`。 - 构建成功。 - 构建仅有项目原有资源体积过大、Browserslist/baseline-browser-mapping 数据过期警告。 - 本次没有调用流程新增、审批、附件上传等业务接口，没有执行数据库脚本，因此未产生业务数据。 6. 仍需执行的外部动作： - 当前仓库没有可直接、安全执行数据库 DDL 的连接串或发布脚本入口。 - 前端修改已经完成，但曹元待办不可见的问题依赖目标数据库存储过程更新。 - 需要在目标 SQL Server 数据库执行 `db_backups/update_abnormal_control_parallel_approval_20260627.sql`，否则服务器仍会按旧存储过程逻辑查询，已发起的测试流程仍可能查不到。 ## 2026-06-27 过程异常管控附件功能临时移除日志 1. 根据用户反馈重新调整： - 用户确认附件功能仍然不好用，要求暂时去掉附件功能。 - 本次目标改为移除过程异常管控页面中的附件入口和上传调用，避免影响流程发起。 2. 修改复用组件： - 修改 `src/views/ProductionManagement/components/AbnormalControlPanel.vue`。 - 删除发起流程表单中的“上传附件”表单项和“点击上传”按钮。 - 删除上传附件弹窗。 - 删除 `MESUploadFile` 引入。 - 删除 `DataPDF`、`uploadPDF`、`pendingUploadCount`、`uploadFileTotal`、`uploadFileSuccess`、`uploadingAttachment` 等附件状态。 - 删除 `uploadSuccessPDF`、`uploadErrorPDF`、`uploadShowPDF`、`submitPicturePDF`、`cancelAttachmentUpload`、`clearPendingAttachments`、`uploadPendingAttachments` 等附件相关方法。 - 删除流程创建成功后的附件上传调用，成功提示恢复为只提示流程创建成功。 - 删除无用的 `.attachment-tip` 样式。 3. 清理加工中心旧残留： - 修改 `src/views/ProductionManagement/MachiningCenter/index.vue`。 - 删除旧异常管控模板里残留的“上传附件”按钮。 - 删除旧代码中已经注释的上传弹窗块。 - 删除旧异常管控方法里的 `uploadShowPDF` 和 `submitPicturePDF`。 - 删除旧数据中的 `imgDialogFormVisible`。 4. 搜索确认： - 对 `src/views/ProductionManagement/components/AbnormalControlPanel.vue`、`AbnormalControl/index.vue`、`MachiningCenter/index.vue`、`AssemblyCenter/index.vue` 执行搜索。 - 未再发现 `上传附件`、`MESUploadFile`、`uploadPDF`、`DataPDF`、`submitPicturePDF`、`uploadShowPDF`、`attachment-tip`、`附件开始上传` 等附件入口或上传调用残留。 5. 验证： - 执行 `npm run build`。 - 构建成功。 - 构建仅有项目原有资源体积过大、Browserslist/baseline-browser-mapping 数据过期警告。 - 本次未调用流程新增、审批、附件上传等业务接口，未产生业务数据。 ## 2026-06-27 过程异常管控页签刷新处理日志 1. 根据用户反馈重新调整： - 用户要求异常管控里面三个页签点击时需要刷新数据。 - 涉及页签包括：`待我处理`、`我发起的`、`已完成`。 2. 检查当前实现： - 当前 `el-tabs` 只通过 `v-model="activeTab"` 切换页签，没有绑定页签点击事件。 - 顶部三个统计卡片点击时也只是修改 `activeTab`，没有重新请求数据。 - `searchTable` 和 `searchTable1` 在接口返回空数组时不会覆盖原列表，可能导致刷新后仍显示上一次的数据。 - 绑定任务查询 `searchTable3` 也存在接口返回空数组时保留旧列表的问题。 3. 前端修改： - 修改 `src/views/ProductionManagement/components/AbnormalControlPanel.vue`。 - 给 `el-tabs` 增加 `@tab-click="handleTabClick"`。 - 新增 `handleTabClick(tab)` 方法，根据当前页签名称刷新对应数据。 - 新增 `switchTab(tabName)` 方法，统计卡片点击时先切换页签，再刷新对应数据。 - 新增 `refreshActiveTab(tabName)` 方法，统一调度三个页签的数据刷新： - `pending` 调用 `searchTable1()` 刷新待我处理。 - `initiated` 调用 `searchTable()` 刷新我发起的。 - `processed` 调用 `getProcessedTasks()` 刷新已完成。 4. 数据覆盖修正： - `getProcessedTasks()` 改为始终用 `response.data || []` 覆盖 `processedTasks`，并同步更新统计数量。 - `searchTable()` 改为始终用 `response.data || []` 覆盖 `initiatedProcesses`，并同步更新统计数量。 - `searchTable1()` 改为始终用 `response.data || []` 覆盖 `pendingTasks`，并同步更新统计数量。 - `searchTable3()` 改为始终用 `response.data || []` 覆盖 `tableData5`，避免绑定任务查询为空时残留旧数据。 5. 验证： - 执行 `npm run build`。 - 构建成功。 - 构建仅有项目原有资源体积过大、Browserslist/baseline-browser-mapping 数据过期警告。 - 本次未调用流程新增、审批等业务接口，未产生业务数据。 ## 2026-06-27 加工中心和装配中心异常管控集成问题处理日志 1. 根据用户反馈重新排查： - 加工中心和装配中心打开异常管控后，新建流程时原本应自动带入的生产任务信息没有了。 - 在异常管控中新建流程或处理任务时，弹出的二级弹框被黑色遮罩挡住，无法操作。 2. 自动带入问题定位： - 加工中心、装配中心当前主表选中行保存在各自页面的 `selectedRow`。 - 异常管控已经改成复用组件后，父页面没有把主表 `selectedRow` 传给复用组件。 - 复用组件内部只知道自己弹窗里的绑定任务列表点击结果，因此从中心页进入时不会自动显示当前生产订单、物料、工序等信息。 3. 自动带入修复： - 修改 `src/views/ProductionManagement/components/AbnormalControlPanel.vue`。 - 新增 `initialSelectedRow` 入参。 - 在组件创建和 `initialSelectedRow` 变化时调用 `applyInitialSelectedRow()`。 - `applyInitialSelectedRow()` 会把外部传入的主表选中行交给 `handleRowClick()` 统一映射。 - `handleRowClick()` 兼容多种字段名： - 生产订单：`订单号`、`计划号`、`生产订单`。 - 物料编码：`产品编码`、`零件编码`、`物料编码`。 - 物料名称：`产品名称`、`零件名称`、`物料名称`。 - 工序名称：`工序名称`。 - 同步把外部带入的信息写入异常管控的查询条件，方便打开后看到当前任务上下文。 - 新建流程校验从 `selectedRow == ""` 调整为 `!selectedRow`，兼容对象/null 两类状态。 4. 父页面传值修复： - 修改 `src/views/ProductionManagement/MachiningCenter/index.vue`。 - 修改 `src/views/ProductionManagement/AssemblyCenter/index.vue`。 - 两个中心页的异常管控弹窗中，将组件调用改为 ``。 5. 遮罩问题修复： - 复用组件内部所有二级弹窗增加 `:append-to-body="true"`： - 发起新流程弹窗。 - 处理任务弹窗。 - 流程进度详情弹窗。 - 转办流程弹窗。 - 完结流程弹窗。 - 加工中心和装配中心的外层异常管控弹窗增加 `append-to-body`，降低与页面其他弹窗层级冲突的风险。 6. 验证： - 执行 `npm run build`。 - 构建成功。 - 构建仅有项目原有资源体积过大、Browserslist/baseline-browser-mapping 数据过期警告。 - 本次未调用流程新增、审批等业务接口，未产生业务数据。 ## 2026-06-27 修改工时报表执行日志 1. 查找并读取需求文档： - 用户提到 `worke`，实际仓库中没有 `worke` 目录。 - 在 `work` 目录下找到 `work/修改工时报表.docx`。 - 读取 docx 内容，确认需求： - 页面位置：`ProductionManagement/Timesheet`。 - 页面中四个分页：`项目工时`、`作业者工时`、`任务工时`、`设备工时`。 - 四个分页里面的明细信息都要按照开始时间排序。 2. 定位代码： - 页面文件为 `src/views/ProductionManagement/Timesheet/index.vue`。 - 四个分页对应数据： - `项目工时` 使用 `projectTableData`，由 `loadProjectData()` 调用 `工时统计_项目工时_查询` 后通过 `buildProjectTree()` 组装。 - `作业者工时` 使用 `operatorTableData`，由 `loadOperatorData()` 调用 `工时统计_作业者工时_查询` 后通过 `buildOperatorTree()` 组装。 - `任务工时` 使用 `taskTableData`，由 `loadTaskData()` 调用 `工时统计_任务工时_查询` 后通过 `buildTaskTree()` 组装。 - `设备工时` 使用 `DeviceTableData`，由 `loadDeviceData()` 调用 `工时统计_设备工时_查询` 后复用 `buildOperatorTree()` 组装。 3. 代码修改： - 修改 `src/views/ProductionManagement/Timesheet/index.vue`。 - 新增 `getStartTimeValue(row)`： - 兼容 `startTime`、`planStart`、`开始时间`、`dateLabel` 字段。 - 将时间字符串转换为可比较的时间戳。 - 空值或无效时间排到最后。 - 新增 `getEarliestStartTime(row)`： - 对树形节点递归取子级最早开始时间。 - 用于父级分组排序，保证父级分组顺序跟其明细开始时间一致。 - 新增 `sortRowsByStartTime(rows)`： - 递归排序每一层 `children`。 - 每个分组下的明细按照开始时间升序排列。 - 父级分组按照子级最早开始时间升序排列。 - 在 `buildProjectTree()` 返回前调用 `sortRowsByStartTime()`，覆盖项目工时分页。 - 在 `buildOperatorTree()` 返回前调用 `sortRowsByStartTime()`，覆盖作业者工时和设备工时分页。 - 在 `buildTaskTree()` 返回前调用 `sortRowsByStartTime()`，覆盖任务工时分页。 4. 文档归档： - 新建目录 `work/ProductionManagement/Timesheet`。 - 已将 `work/修改工时报表.docx` 移动到 `work/ProductionManagement/Timesheet/修改工时报表.docx`。 5. 验证： - 执行 `npm run build`。 - 构建成功。 - 构建仅有项目原有资源体积过大、Browserslist/baseline-browser-mapping 数据过期警告。 - 本次只修改前端排序和移动文档，未调用业务接口，未产生业务数据。 ## 2026-06-27 13:42:30 作业者工时报工数量按 TaskAID+开始时间取最大值 ### 用户需求 - 修改工时报表中“作业者工时”的“报工数量”取值口径。 - 新口径：同一个 TaskAID 且开始时间相同的记录，报工数量取最大值；不再叠加其他分组条件。 - 用户提供目标数据库连接信息，本次执行中使用目标库 192.168.2.92 / YL_MESDB，日志中不记录数据库密码。 ### 执行过程 1. 检查工作目录 C:\WorkYuanLy\MES_Manage_View_V20，确认工时报表文档已在 work/ProductionManagement/Timesheet/修改工时报表.docx。 2. 检查前端文件 src/views/ProductionManagement/Timesheet/index.vue，确认“作业者工时”和“设备工时”共用 uildOperatorTree，因此修改时增加开关参数，只让作业者工时启用新口径，避免影响设备工时。 3. 连接数据库 192.168.2.92 的 YL_MESDB，确认： - dbo.View_生产工时视图 包含 TaskAID、开始时间、操作数值、操作人、阶段标识 字段。 - dbo.View_生产工时视图全部 包含 TaskAID、开始时间、操作数值、操作人、阶段标识 字段。 - dbo.工时统计_作业者工时_查询 存储过程存在。 4. 在修改数据库过程前，备份目标库当前过程定义： - db_backups/timesheet_operator_reportqty_backups/工时统计_作业者工时_查询_before_taskstart_reportqty_20260627_133625.sql - db_backups/timesheet_operator_reportqty_backups/工时统计_作业者工时_查询_导出_before_taskstart_reportqty_20260627_133625.sql 5. 修改前端 src/views/ProductionManagement/Timesheet/index.vue： - 增加 parseReportQty、 ormatReportQty、getTaskAID、getReportQtyGroupKey、uildTaskStartReportQtyMap、getTaskStartReportQty、 ecalculateOperatorReportQty。 - loadOperatorData 调用 uildOperatorTree(res.data || [], true)，启用作业者工时的新报工数量口径。 - uildOperatorTree 增加 useTaskStartMaxReportQty 参数；明细行保留 TaskAID 和内部用的 eportQtyGroupKey。 - 作业者工时的日期汇总和操作人汇总按唯一 TaskAID + startTime 取最大值后再求和，避免同一任务同一开始时间的重复行重复累加。 - 设备工时继续调用 uildOperatorTree(res.data || [])，不启用新口径。 6. 新增数据库脚本 db_backups/update_timesheet_operator_report_qty_task_start_20260627.sql： - 更新 dbo.工时统计_作业者工时_查询。 - 更新 dbo.工时统计_作业者工时_查询_导出。 - 两个过程均通过 TaskStart报工数量 按 TaskAID + CONVERT(VARCHAR(19), 开始时间, 120) 分组取最大报工数量。 - 查询过程结果集中增加 TaskAID 字段供前端兜底计算使用。 - 导出过程同步使用新口径，但不新增导出显示列，避免改变导出表头结构。 7. 执行数据库脚本到目标库；本次数据库操作只执行 ALTER PROCEDURE，未写入或修改业务表数据。 8. 使用 sys.sp_describe_first_result_set 验证 dbo.工时统计_作业者工时_查询 的结果集，确认包含 TaskAID 字段，位于结果列第 20 列。 9. 验证数据库过程定义中查询和导出都包含 GROUP BY TaskAID, CONVERT(VARCHAR(19), 开始时间, 120)，确认已按新口径分组。 10. 执行 pm run build，构建成功。构建输出仍有既有资源体积过大和 Browserslist 数据过期警告，本次修改未引入编译错误。 ### 修改结果 - 作业者工时页面“报工数量”现在按照同一 TaskAID、同一开始时间取最大值。 - 作业者工时的操作人汇总、日期汇总、明细显示和导出过程均同步使用该口径。 - 设备工时未被新口径影响。 - 已保留数据库更新前备份和本次更新脚本。 ### 验证结果 - 数据库连接和字段确认：通过。 - 存储过程更新：通过。 - 查询结果集 TaskAID 字段确认：通过。 - 前端生产构建 pm run build：通过，仅有既有警告。 ## 2026-06-27 14:13:28 修正作业者工时报工数量为全量视图取最大值 ### 用户反馈 - 上一次实现不符合要求。 - 正确口径：直接查询 [View_生产工时视图全部]，同一个 TaskAID、同一个开始时间取最大报工数量，不经过任何过滤条件。 ### 执行过程 1. 明确修正范围：报表显示行仍由原查询条件决定，但“报工数量最大值”的来源必须改为全量 [dbo].[View_生产工时视图全部]，不能从筛选后的数据集计算。 2. 修改脚本 db_backups/update_timesheet_operator_report_qty_task_start_20260627.sql： - dbo.工时统计_作业者工时_查询 中的 TaskStart报工数量 CTE 从 FROM 筛选明细 改为 FROM [dbo].[View_生产工时视图全部]。 - dbo.工时统计_作业者工时_查询_导出 中的 TaskStart报工数量 CTE 同步改为 FROM [dbo].[View_生产工时视图全部]。 - 两处最大值计算均只按 TaskAID, CONVERT(VARCHAR(19), 开始时间, 120) 分组，不增加日期、操作人、合同号、产品、工序、订单、阶段标识等过滤条件。 3. 在重新应用数据库脚本前，再次备份目标库当前过程定义： - db_backups/timesheet_operator_reportqty_backups/工时统计_作业者工时_查询_before_unfiltered_taskstart_reportqty_20260627_141106.sql - db_backups/timesheet_operator_reportqty_backups/工时统计_作业者工时_查询_导出_before_unfiltered_taskstart_reportqty_20260627_141106.sql 4. 重新连接目标库 192.168.2.92 / YL_MESDB，执行修正后的 SQL 脚本，只更新两个存储过程定义，未修改业务表数据。 5. 第一次使用 LIKE 验证时因匹配范围过大产生误判，随后改为提取 TaskStart报工数量 CTE 片段进行验证。 6. 验证结果： - dbo.工时统计_作业者工时_查询 的 TaskStart报工数量 CTE 来源为 FROM [dbo].[View_生产工时视图全部]，不包含 筛选明细。 - dbo.工时统计_作业者工时_查询_导出 的 TaskStart报工数量 CTE 来源为 FROM [dbo].[View_生产工时视图全部]，不包含 筛选明细。 - 两个过程均按 GROUP BY TaskAID, CONVERT(VARCHAR(19), 开始时间, 120) 分组取最大值。 7. 执行 pm run build，前端构建通过。输出仍有既有资源体积过大和 Browserslist 数据过期警告，本次修正未引入编译错误。 ### 修改结果 - 作业者工时查询和导出过程的报工数量最大值来源已改为全量 [dbo].[View_生产工时视图全部]。 - 最大值计算不再经过报表查询条件过滤。 - 本地脚本和目标库过程已同步。 ### 验证结果 - 目标库脚本应用：通过。 - CTE 来源验证：通过。 - 前端生产构建 pm run build：通过，仅有既有警告。 ## 2026-06-27 14:48:37 修正作业者工时报工数量最大值增加操作类别编号过滤 ### 用户反馈 - 报工数量最大值仍需直接查 [View_生产工时视图全部]。 - 同一个 TaskAID、同一个开始时间取最大值。 - 需要增加过滤条件：操作类别编号 = 6。 ### 执行过程 1. 连接目标库 192.168.2.92 / YL_MESDB，确认 [dbo].[View_生产工时视图全部] 存在以下字段： - TaskAID - 开始时间 - 操作数值 - 操作类别编号 2. 修改本地数据库脚本 db_backups/update_timesheet_operator_report_qty_task_start_20260627.sql： - 在 dbo.工时统计_作业者工时_查询 的 TaskStart报工数量 CTE 中增加 WHERE 操作类别编号 = 6。 - 在 dbo.工时统计_作业者工时_查询_导出 的 TaskStart报工数量 CTE 中同步增加 WHERE 操作类别编号 = 6。 - 最大值来源仍为 FROM [dbo].[View_生产工时视图全部]，不是筛选后的报表数据。 - 分组仍只使用 TaskAID, CONVERT(VARCHAR(19), 开始时间, 120)。 3. 在重新应用数据库脚本前，备份目标库当前过程定义： - db_backups/timesheet_operator_reportqty_backups/工时统计_作业者工时_查询_before_taskstart_reportqty_type6_20260627_144642.sql - db_backups/timesheet_operator_reportqty_backups/工时统计_作业者工时_查询_导出_before_taskstart_reportqty_type6_20260627_144642.sql 4. 重新执行 SQL 脚本到目标库，只执行 ALTER PROCEDURE，未修改业务表数据。 5. 提取两个过程的 TaskStart报工数量 CTE 进行验证，结果如下： - dbo.工时统计_作业者工时_查询：来源为 [dbo].[View_生产工时视图全部]，包含 WHERE 操作类别编号 = 6，不包含 筛选明细。 - dbo.工时统计_作业者工时_查询_导出：来源为 [dbo].[View_生产工时视图全部]，包含 WHERE 操作类别编号 = 6，不包含 筛选明细。 6. 执行 pm run build，前端构建通过。输出仍有既有资源体积过大和 Browserslist 数据过期警告，本次调整未引入编译错误。 ### 修改结果 - 作业者工时查询和导出的报工数量最大值口径已更新为： - 直接从 [dbo].[View_生产工时视图全部] 取数； - 只取 操作类别编号 = 6 的记录； - 同一 TaskAID、同一开始时间取最大 操作数值 口径后的报工数量； - 不使用报表查询条件过滤最大值来源。 ### 验证结果 - 字段确认：通过。 - 目标库过程更新：通过。 - CTE 来源和条件验证：通过。 - 前端生产构建 pm run build：通过，仅有既有警告。 ## 2026-06-27 15:02:19 修正作业者工时报工数量撤销操作类别过滤并增加装配置零 ### 用户反馈 - 之前增加 操作类别编号 = 6 不符合要求。 - 正确口径：直接查 [View_生产工时视图全部]，同一个 TaskAID、同一个开始时间取最大值，最大值来源没有任何过滤条件。 - 另增判断：指派对象包含“装配”时，报工数量为 0。 ### 执行过程 1. 重新确认需求后，修正本地 SQL 脚本 db_backups/update_timesheet_operator_report_qty_task_start_20260627.sql。 2. 从 dbo.工时统计_作业者工时_查询 的 TaskStart报工数量 CTE 中移除 WHERE 操作类别编号 = 6。 3. 从 dbo.工时统计_作业者工时_查询_导出 的 TaskStart报工数量 CTE 中移除 WHERE 操作类别编号 = 6。 4. 保留最大值来源为全量 [dbo].[View_生产工时视图全部]，并只按 TaskAID, CONVERT(VARCHAR(19), 开始时间, 120) 分组。 5. 在查询过程 报工明细 中增加判断：WHEN ISNULL(b.工位名称, '') LIKE '%装配%' THEN 0，否则使用全量视图按 TaskAID+开始时间取到的最大报工数量。 6. 在导出过程的明细查询中同步增加同样的装配置零判断，保持页面和导出口径一致。 7. 检查本地脚本，确认没有残留 操作类别编号 = 6，并确认查询和导出两处均包含装配置零判断。 8. 在重新应用数据库脚本前，备份目标库当前过程定义： - db_backups/timesheet_operator_reportqty_backups/工时统计_作业者工时_查询_before_assembly_zero_reportqty_20260627_145839.sql - db_backups/timesheet_operator_reportqty_backups/工时统计_作业者工时_查询_导出_before_assembly_zero_reportqty_20260627_145839.sql 9. 重新执行 SQL 脚本到目标库 192.168.2.92 / YL_MESDB，只执行 ALTER PROCEDURE，未修改业务表数据。 10. 数据库验证： - dbo.工时统计_作业者工时_查询 的 TaskStart报工数量 CTE 来源为 [dbo].[View_生产工时视图全部]，无 WHERE，不包含 操作类别编号，包含装配置零判断。 - dbo.工时统计_作业者工时_查询_导出 的 TaskStart报工数量 CTE 来源为 [dbo].[View_生产工时视图全部]，无 WHERE，不包含 操作类别编号，包含装配置零判断。 11. 同步修改前端兜底逻辑 src/views/ProductionManagement/Timesheet/index.vue： - 增加 isAssemblyAssignee 方法，识别 指派对象/工位名称/assignee 是否包含“装配”。 - 在 getTaskStartReportQty 中，如果为装配指派对象，直接返回 ，避免前端按同一 TaskAID+开始时间重算时把非装配最大值覆盖到装配行。 12. 执行 pm run build，前端构建通过。输出仍有既有资源体积过大和 Browserslist 数据过期警告，本次修正未引入编译错误。 ### 修改结果 - 作业者工时查询和导出的最大值来源恢复为全量 [dbo].[View_生产工时视图全部]，没有任何过滤条件。 - 最大值分组键仍为 TaskAID + 开始时间。 - 指派对象包含“装配”时，页面、汇总和导出报工数量均置为 0。 - 前端兜底逻辑已同步，避免页面端重算覆盖数据库装配置零规则。 ### 验证结果 - SQL 脚本检查：通过。 - 目标库过程更新：通过。 - CTE 无过滤和装配置零判断验证：通过。 - 前端生产构建 pm run build：通过，仅有既有警告。 ## 2026-06-27 15:26:30 根据工时查询界面文档修改工时查询页面 ### 用户需求 - 根据 work 下的 工时查询界面.docx 修改工时查询页面。 - 修改后创建对应路径并把文档移入。 - 按要求追加中文执行日志，不记录数据库密码。 ### 文档内容提取 - 文档名称：work/工时查询界面.docx。 - 文档要求： - 修改三级数据，由原三级汇总改成三级明细数据。 - 页面字段按截图展示：任务描述、日期、班次、生产订单号、报工类型、报工数量、工位、工时、程序时间、单件工时、工艺工时等。 - 报工类型字段：辅助 改成 调机，报工 改成 正常。 - 报工数量：相同 TaskAID、相同开始时间取最大值。 - 指派对象包含“装配”时，报工数量为 0。 - 程序时间没有，暂时为空。 - 单件工时按 工时（分钟）/报工数量 计算；报工数量为 0 时取工艺工时。 - 工艺工时维持原样。 - 增加字段“操作人”，取相同 TaskAID、相同开始时间的操作人拼接，且去掉加工工时大于 0 的数据。 - 白班/夜班根据操作描述包含“白班”或“夜班”判断。 ### 执行过程 1. 查找并读取文档，确认文档路径为 work/工时查询界面.docx，并提取文档正文和截图。 2. 定位工时查询页面为 src/views/ProductionManagement/Workhours/index.vue，当前调用存储过程 生产管理_工时查询_工序工时_查询。 3. 连接目标库 192.168.2.92 / YL_MESDB，读取当前 dbo.生产管理_工时查询_工序工时_查询 定义，确认旧过程的三级数据为按 TaskAID、日期、班次汇总。 4. 查询数据库字段，确认 [dbo].[View_生产工时视图] 和 [dbo].[View_生产工时视图全部] 存在 TaskAID、开始时间、结束时间、操作内容、操作类别、操作描述、操作人、加工工时、操作数值、订单号、订单行号、订单合同号、产品编码、产品名称、工序名称、工位名称 等字段。 5. 新增数据库脚本 db_backups/update_workhours_query_detail_20260627.sql： - 更新 dbo.生产管理_工时查询_工序工时_查询。 - 基础数据仍按页面查询条件取报工/辅助结束且加工工时大于 0 的记录。 - TaskStart报工数量 从 [dbo].[View_生产工时视图全部] 按 TaskAID + 开始时间 全量取最大值。 - 指派对象/工位名称包含“装配”时，报工数量置 0。 - 三级返回明细数据，不再返回班次汇总。 - 操作人使用相同 TaskAID + 开始时间 且 加工工时 <= 0 的记录去重拼接。 - 班次根据相同 TaskAID + 开始时间 的操作描述是否包含“白班”或“夜班”判断。 - 程序时间返回空。 - 单件工时按加工工时分钟/报工数量计算；报工数量为 0 时取工艺工时。 6. 备份目标库旧过程到 db_backups/workhours_query_backups/生产管理_工时查询_工序工时_查询_before_detail_query_20260627_152142.sql。 7. 第一次应用后用样本执行发现 XML 拼接操作人受 QUOTED_IDENTIFIER 设置影响，因此将脚本改为 SET QUOTED_IDENTIFIER ON，并把操作人拼接改成 SQL Server 2019 支持的 STRING_AGG。 8. 重新执行脚本到目标库，只更新存储过程定义，未修改业务表数据。 9. 执行 EXEC dbo.[生产管理_工时查询_工序工时_查询] @数据条数 = 5 验证，返回 15 行，三级明细包含 operatorNames、productionOrderNo、 eportType、 eportQty、station、workHours、pieceWorkHours、processWorkHours 等字段。 10. 修改前端 src/views/ProductionManagement/Workhours/index.vue： - 表格列调整为文档要求的工时记录结构。 - 增加操作人、生产订单号、报工类型、工位、工时、程序时间、单件工时等列。 - 报工类型前端兜底映射：包含“辅助”显示“调机”，包含“报工”显示“正常”。 - 第三级树节点改为明细行展示，不再按班次汇总展示。 - 底部汇总改为总工时。 11. 创建目录 work/ProductionManagement/Workhours，并将 work/工时查询界面.docx 移动到 work/ProductionManagement/Workhours/工时查询界面.docx。 12. 清理文档截图临时解压目录 work/.docx_extract_工时查询界面。 13. 执行 pm run build，前端构建通过。输出仍有既有资源体积过大和 Browserslist 数据过期警告，本次修改未引入编译错误。 ### 修改结果 - 工时查询页面已按文档改成工时记录形式。 - 三级数据已由班次汇总改为明细数据。 - 数据库过程和前端页面字段已同步。 - 文档已移动到 work/ProductionManagement/Workhours/工时查询界面.docx。 ### 验证结果 - 存储过程脚本应用：通过。 - 存储过程样本执行：通过。 - 前端生产构建 pm run build：通过，仅有既有警告。 ## 2026-06-27 16:34:11 根据新增结算工时页面文档新增结算工时页面 ### 用户需求 - 根据 work 下的 新增结算工时页面.docx 新增结算工时页面。 - 修改后创建对应路径并把文档移入。 - 按要求追加中文执行日志，不记录数据库密码。 ### 文档内容提取 - 文档名称：work/新增结算工时页面.docx。 - 文档要求： - 新增结算工时页面，任务描述参考工时查询页面。 - 根据订单编号（生产订单号）和工位（指派对象）分组。 - 统计设备工时，条件为加工工时 > 0。 - 报工工时：上述设备工时中操作类别等于报工的工时。 - 主辅工时：上述设备工时中操作类别等于辅助结束的工时。 - 完成数分为报工完成数和辅助完成数，对应上述工时记录的操作数值求和。 - 增加操作人字段：相同 TaskAID、相同开始时间的操作人拼接，且去掉加工工时大于 0 的数据。 ### 执行过程 1. 查找并读取文档，确认路径为 work/新增结算工时页面.docx。 2. 检查现有生产管理页面和路由机制，确认前端使用动态菜单路径加载 src/views 下组件；新增页面放置在 src/views/ProductionManagement/SettlementWorkhours/index.vue。 3. 新增数据库脚本 db_backups/create_settlement_workhours_query_20260627.sql： - 创建/更新 dbo.生产管理_结算工时_查询。 - 基础数据来源为 [dbo].[View_生产工时视图]。 - 查询条件包含合同号、产品编码、订单号、工位、开始日期、结束日期、数据条数。 - 只统计 加工工时 > 0 且操作内容/操作类别为 报工 或 辅助结束 的设备工时。 - 汇总层按 订单号 + 工位名称 分组。 - 报工工时 为报工记录加工工时小时汇总。 - 主辅工时 为辅助结束记录加工工时小时汇总。 - 报工完成数、辅助完成数 分别按对应操作类型的 操作数值 汇总。 - 明细层返回操作人、日期、工序、操作类别、完成数、工时、开始/结束时间、TaskAID。 - 操作人使用 [dbo].[View_生产工时视图全部] 中相同 TaskAID + 开始时间 且 加工工时 <= 0 的记录去重后用 STRING_AGG 拼接。 4. 执行数据库脚本到目标库 192.168.2.92 / YL_MESDB，只创建/更新存储过程，未修改业务表数据。 5. 执行样本验证 EXEC dbo.[生产管理_结算工时_查询] @数据条数 = 10，返回 18 行，包含汇总层和明细层数据。 6. 新增前端页面 src/views/ProductionManagement/SettlementWorkhours/index.vue： - 提供合同号、产品编码、生产订单号、工位、数据条数、开始/结束日期查询条件。 - 调用 生产管理_结算工时_查询。 - 使用树形表格展示订单+工位汇总，展开查看明细。 - 汇总列包含报工工时、主辅工时、报工完成数、辅助完成数、合计工时。 - 明细列包含操作人、日期、工序名称、操作类别、完成数、工时、开始时间、结束时间。 - 底部显示报工工时、主辅工时、合计工时汇总。 7. 创建目录 work/ProductionManagement/SettlementWorkhours，并将 work/新增结算工时页面.docx 移动到 work/ProductionManagement/SettlementWorkhours/新增结算工时页面.docx。 8. 执行 pm run build，前端构建通过。输出仍有既有资源体积过大和 Browserslist 数据过期警告，本次新增未引入编译错误。 ### 修改结果 - 新增结算工时页面：src/views/ProductionManagement/SettlementWorkhours/index.vue。 - 新增数据库脚本并已应用：db_backups/create_settlement_workhours_query_20260627.sql。 - 文档已移动到 work/ProductionManagement/SettlementWorkhours/新增结算工时页面.docx。 ### 验证结果 - 存储过程脚本应用：通过。 - 存储过程样本执行：通过。 - 前端生产构建 pm run build：通过，仅有既有警告。 ## 2026-06-27 16:42:14 补新增结算工时页面菜单记录 ### 用户反馈 - 新增结算工时页面后，页面上看不到菜单。 - 用户怀疑 [dbo].[登录基础数据_二级菜单] 没有增加记录。 ### 执行过程 1. 检查目标库 192.168.2.92 / YL_MESDB 的 [dbo].[登录基础数据_二级菜单] 表结构。 2. 确认字段包括 IDD、id、pid、path、componet、 edirect、 ame、 itle、icon、账号代码、模块代码、是否启用、AddData、DeleteData、EditData、SearchData。 3. 注意到字段名是 componet，不是 component。 4. 查询现有工时相关菜单，确认： - 工时查询 菜单存在，id = 166，pid = 3，路径为 Workhours/index，组件为 /ProductionManagement/Workhours/index。 - 工时查询 当前只配置给账号代码 1 和 2010。 - 结算工时 菜单此前不存在。 5. 查询 IDD 属性，确认 IDD 是自增列；当前最大菜单 id 为 230。 6. 新增菜单脚本 db_backups/add_settlement_workhours_menu_20260627.sql： - 新菜单 id 使用 231。 - pid = 3，挂在生产管理下。 - path = 'SettlementWorkhours/index'。 - componet = '/ProductionManagement/SettlementWorkhours/index'。 - ame = 'SettlementWorkhours'。 - itle = '结算工时'。 - icon 复用工时查询图标，兜底为 DimensionsSummaryReport。 - 权限按现有 工时查询 复制，插入账号代码 1 和 2010。 - 脚本带 NOT EXISTS 判断，避免重复插入同账号菜单。 7. 执行菜单脚本到目标库。 8. 查询验证结果： - IDD = 2754，账号代码 1，菜单 结算工时 已存在。 - IDD = 2755，账号代码 2010，菜单 结算工时 已存在。 - 两条记录均指向 /ProductionManagement/SettlementWorkhours/index。 ### 修改结果 - 已向 [dbo].[登录基础数据_二级菜单] 补录 结算工时 菜单。 - 菜单权限与现有 工时查询 保持一致，仅账号代码 1 和 2010 可见。 - 本次仅修改数据库菜单记录和新增脚本，不涉及前端代码变更。 ### 验证结果 - 菜单表结构确认：通过。 - 菜单脚本执行：通过。 - 结算工时 菜单记录查询：通过。 ## 2026-06-27 17:05:00 修正结算工时页面层级和已结算口径 ### 用户反馈 - 结算工时页面缺少任务描述、装夹时间、程序时间。 - 页面存在多余字段，需要去掉。 - 数据层级应为 物料汇总 -> 生产订单号+工位汇总，不需要明细层。 - 只要已经结算的数据，即 [YL_MESDB].[dbo].[MES_接口_生产计划] 中 单据状态 IS NULL 的数据。 ### 执行过程 1. 重新确认需求后，调整结算工时页面和存储过程为两级汇总，不再返回明细层。 2. 查询字段确认： - [dbo].[MES_接口_生产计划] 包含 AID、订单编号、物料编号、物料描述、单据状态。 - [dbo].[View_生产工时视图] 和 [dbo].[View_生产工时视图全部] 包含 TaskAID、订单号、产品编码、产品名称、工位名称、加工工时、操作内容、操作类别、操作数值、开始时间、操作人。 - [dbo].[车间生产管理工艺_零件生产工艺_工艺库] 包含 准备工时、标准工时，本次用 准备工时 作为装夹时间，用 标准工时 作为程序时间。 3. 重写 db_backups/create_settlement_workhours_query_20260627.sql： - dbo.生产管理_结算工时_查询 先从 [dbo].[MES_接口_生产计划] 取 单据状态 IS NULL 的结算任务。 - 工时数据通过 p.AID = v.TaskAID 关联到结算任务。 - 只统计 加工工时 > 0，且操作内容/操作类别为 报工 或 辅助结束 的设备工时。 - 汇总层级改为两级：一级按 物料编号 + 物料描述 汇总，二级按 生产订单号 + 工位名称 汇总。 - 输出字段包含任务描述、生产订单号、工位、报工工时、主辅工时、报工完成数、辅助完成数、合计工时、装夹时间、程序时间、操作人。 - 去掉明细字段：日期、工序名称、操作类别、完成数、单条工时、开始时间、结束时间等。 4. 执行脚本到目标库 192.168.2.92 / YL_MESDB，只更新存储过程定义，未修改业务表数据。 5. 执行样本验证 EXEC dbo.[生产管理_结算工时_查询] @数据条数 = 20，返回 6 行，层级为 Level=1 物料汇总和 Level=2 订单+工位汇总。 6. 使用 sp_describe_first_result_set 验证结果集字段，确认包含 materialCode、materialDesc、 askDescription、productionOrderNo、station、 eportWorkHours、uxiliaryWorkHours、 eportFinishQty、uxiliaryFinishQty、 otalWorkHours、clampingTime、programTime、operatorNames、 ecordCount。 7. 重写前端 src/views/ProductionManagement/SettlementWorkhours/index.vue： - 查询条件精简为生产订单号、物料编码、工位、数据条数、开始日期、结束日期。 - 表格改为两级树：一级物料汇总，二级生产订单号+工位汇总。 - 补回任务描述、装夹时间、程序时间列。 - 删除多余明细列：合同号、产品编码、产品名称、日期、工序、操作类别、完成数、单条工时、开始时间、结束时间。 - 底部汇总保留报工工时、主辅工时、合计工时。 8. 执行 pm run build，前端构建通过。输出仍有既有资源体积过大和 Browserslist 数据过期警告，本次修正未引入编译错误。 ### 修改结果 - 结算工时页面已改为 物料汇总 -> 生产订单号+工位汇总 两级结构。 - 页面已补回任务描述、装夹时间、程序时间。 - 页面多余明细字段已去掉。 - 数据只取 [dbo].[MES_接口_生产计划] 中 单据状态 IS NULL 的结算任务。 ### 验证结果 - 目标库存储过程更新：通过。 - 存储过程样本执行：通过。 - 结果集字段验证：通过。 - 前端生产构建 pm run build：通过，仅有既有警告。 ## 2026-06-27 17:28:58 修正结算工时程序时间装夹时间和单件工时口径 ### 用户反馈 - 程序时间目前没有，默认 0。 - 装夹时间 = 【报工工时（汇总） - 程序时间 * 完工数】 / 完工数。 - 结算报工单件工时 = 报工工时 / 报工完成数。 - 结算辅助单件工时 = 主辅工时 / 辅助完成数。 - 任务描述没了，需要加上。 ### 执行过程 1. 修改 db_backups/create_settlement_workhours_query_20260627.sql。 2. 从结算工时存储过程里移除工艺库 准备工时/标准工时 作为装夹时间、程序时间的取值。 3. 将程序时间固定输出为 。 4. 将装夹时间改为公式：CASE WHEN 报工完成数 > 0 THEN (报工工时 - 0 * 报工完成数) / 报工完成数 ELSE 0 END。 5. 新增输出字段： - settlementReportPieceHours：CASE WHEN 报工完成数 > 0 THEN 报工工时 / 报工完成数 ELSE 0 END。 - settlementAuxiliaryPieceHours：CASE WHEN 辅助完成数 > 0 THEN 主辅工时 / 辅助完成数 ELSE 0 END。 6. 保留并输出 askDescription，由 物料描述 + ' ' + 物料编号 组成，一级和二级都返回该字段。 7. 修改前端 src/views/ProductionManagement/SettlementWorkhours/index.vue： - 二级行也显示任务描述。 - 新增“结算报工单件工时”列。 - 新增“结算辅助单件工时”列。 - 绑定新字段 settlementReportPieceHours、settlementAuxiliaryPieceHours。 8. 执行 SQL 脚本到目标库 192.168.2.92 / YL_MESDB，只更新存储过程定义，未修改业务表数据。 9. 执行样本验证 EXEC dbo.[生产管理_结算工时_查询] @数据条数 = 20： - 返回任务描述。 - 程序时间为 0。 - 装夹时间按公式返回。 - 返回结算报工单件工时和结算辅助单件工时。 10. 执行 pm run build，前端构建通过。输出仍有既有资源体积过大和 Browserslist 数据过期警告，本次修正未引入编译错误。 ### 修改结果 - 程序时间默认 0。 - 装夹时间改为按汇总公式计算。 - 新增结算报工单件工时、结算辅助单件工时。 - 任务描述在物料汇总层和生产订单号+工位汇总层均显示。 ### 验证结果 - 目标库存储过程更新：通过。 - 存储过程样本执行：通过。 - 前端生产构建 pm run build：通过，仅有既有警告。 ## 2026-06-27 17:39:00 修正结算工时二级任务描述和查询性能 ### 用户反馈 - 结算工时页面红框位置的二级任务描述需要拼接工序名称和工序顺序。 - 页面打开和查询太慢，需要优化。 ### 执行过程 1. 查看当前结算工时页面 `src/views/ProductionManagement/SettlementWorkhours/index.vue`，确认页面只展示接口返回的 `taskDescription`，红框位置对应二级“生产订单号+工位”汇总行。 2. 查看当前 SQL 备份脚本 `db_backups/create_settlement_workhours_query_20260627.sql`，确认任务描述由 `物料描述 + 物料编号` 组成，未带工序名称和订单行号。 3. 修改 `db_backups/create_settlement_workhours_query_20260627.sql`： - 在结算明细中保留 `工序名称` 和 `订单行号`。 - 在二级汇总中增加 `MAX(工序名称) AS 工序名称`、`MAX(订单行号) AS 工序顺序`。 - 二级 `taskDescription` 改为：`物料描述 + 物料编号 + 工序名称 + ' 序' + 工序顺序`。 - 一级物料汇总任务描述保持 `物料描述 + 物料编号`。 4. 优化 SQL 查询性能： - 将原来按每个明细键反复查询 `[dbo].[View_生产工时视图全部]` 的操作人相关子查询，改为 `明细键 -> 操作人明细 -> 操作人拼接` 的统一聚合。 - 将订单工位汇总里的操作人相关子查询，改为先按订单工位聚合操作人，再回连到二级汇总，避免汇总行逐行重复扫描。 - 连接开始时间时使用秒级时间范围匹配，避免对大视图每行做字符串转换匹配。 5. 修改前端页面 `src/views/ProductionManagement/SettlementWorkhours/index.vue`： - 将“任务描述”列最小宽度从 280 调整为 380，避免追加工序名称和序号后显示过窄。 6. 第一次执行 SQL 脚本时发现 `sqlcmd -i` 未按 UTF-8 解释中文脚本，数据库误建了一个乱码过程，正式中文过程仍是旧定义。 7. 使用 `sqlcmd -f 65001` 重新执行 UTF-8 脚本到 `192.168.2.92 / YL_MESDB`，正式过程 `dbo.生产管理_结算工时_查询` 更新成功。 8. 确认正式过程定义中已包含 `工序顺序`。 9. 删除本次因编码误建的乱码过程，避免后续排查混淆。 10. 执行抽样验证： - `软管总成 214-20411-30-12x1SN-12x4000 电火花 序5` - `软管总成 214-20411-30-12x1SN-12x4000 打压检测 序4` - 同类二级行已能显示工序名称和工序顺序。 11. 对同样 `@数据条数 = 30` 的抽查计时： - 优化前约 17161 ms。 - 优化后约 1986 ms。 12. 执行 `npm run build`，前端构建通过。输出仍有项目既有的资源体积过大和 Browserslist 数据过期警告，本次修改未引入编译错误。 ### 修改结果 - 结算工时页面二级任务描述已拼接工序名称和工序顺序。 - SQL 操作人拼接和订单工位操作人汇总已优化，减少重复扫描。 - 任务描述列宽已加宽。 - 数据库存储过程已同步更新到目标库。 ### 验证结果 - 目标库存储过程更新：通过。 - 乱码误建过程清理：通过。 - 样本查询内容验证：通过。 - 样本查询耗时验证：从约 17.1 秒降到约 2.0 秒。 - 前端生产构建 `npm run build`：通过，仅有既有警告。 ## 2026-06-27 17:46:00 修正结算工时操作人重复拼接 ### 用户反馈 - 结算工时页面的操作人拼接存在重复姓名，需要去重。 ### 执行过程 1. 查看 `db_backups/create_settlement_workhours_query_20260627.sql` 中当前操作人拼接逻辑。 2. 确认原逻辑已经对整段 `操作人` 字符串做了 `DISTINCT`，但在订单工位汇总时，如果明细中已有 `张三,李四` 这类拼接字符串，再和其他明细拼接，会出现单个人名重复。 3. 修改 `操作人明细`： - 对源字段 `v2.操作人` 先替换中文逗号、顿号为英文逗号。 - 使用 `STRING_SPLIT` 拆成单个姓名。 - 去掉姓名前后空格。 - 过滤空姓名。 - 再按 `TaskAID + 开始时间 + 操作人` 去重后重新 `STRING_AGG`。 4. 修改 `订单工位操作人`： - 对 `结算明细.操作人` 再次按逗号拆分成单个姓名。 - 按 `物料编号 + 订单号 + 工位名称 + 操作人` 去重。 - 再重新拼接为最终 `operatorNames`。 5. 使用 `sqlcmd -f 65001` 将脚本同步到目标库 `192.168.2.92 / YL_MESDB`，只更新存储过程定义。 6. 执行抽样验证 `EXEC dbo.[生产管理_结算工时_查询] @数据条数 = 100`： - 将返回的 `operatorNames` 再拆分统计重复姓名。 - 未查出重复姓名行。 - 样例结果如 `李盛发,王宝昌,魏文海,普1,孙广义`，同一行内姓名不重复。 7. 执行 `npm run build`，前端构建通过。输出仍有项目既有的资源体积过大和 Browserslist 数据过期警告，本次修改未引入编译错误。 ### 修改结果 - 操作人拼接已改为按单个姓名去重。 - 支持处理中文逗号、顿号和英文逗号分隔的姓名。 - 数据库存储过程已同步更新到目标库。 ### 验证结果 - 目标库存储过程更新：通过。 - 重复姓名抽样检查：通过。 - 前端生产构建 `npm run build`：通过，仅有既有警告。 ## 2026-06-29 设备信息维护页面修改 ### 用户需求 - 根据 `doc/修改设备信息维护.docx` 修改设备信息维护页面。 - 修改后在 `work` 下创建对应路径，并复制原始文档。 - 在对应路径下新增或修改 `01-项目功能内容`、`02-项目程序开发详细步骤`、`03-推进台账`、`04-任务矩阵`、`05-验收证据`、`06-决策记录`，并增加 README 索引。 - 将完整执行过程追加到 `gptlog-process/gpdlog.md`，日志使用中文。 ### 执行过程 1. 查看 `doc` 目录，确认存在 `doc/修改设备信息维护.docx`。 2. 使用 PowerShell 解析 docx 中的 `word/document.xml`，提取需求文本：新增公司编码（财务）、设备信息、使用部门、入账日期、单位、数量、状态、维修记录、维保记录、工位绑定、主要设备、设备标准开机工时、特种设备、证书有效期至；生产用名复用设备名称，规格/型号复用设备型号；公司编码必填且不可修改；工位绑定为工位管理数据多选；证书有效期过期红色置顶，30 天内黄色靠前。 3. 定位目标页面为 `src/views/DeviceManagement/DeviceInformation/index.vue`。 4. 确认工位管理页面 `src/views/SystemMaintenance/WorkstationManagement/index.vue` 使用 `MES_登录_工位与名称_查询` 获取工位数据。 5. 初次用 Windows 集成认证连接 SQL Server 失败，随后根据用户提供的数据库地址、账号和密码，用数据库账号连接 `192.168.2.92 / YL_MESDB` 成功。日志和文档中不记录明文密码。 6. 查询 `dbo.基础数据_设备工位点检表`，确认原表只有旧字段：设备流水号、设备名称、设备型号、制造厂家、工位号、点检表类型、操作日期、保养人员代码、监督人员代码、设备类型。 7. 查询旧存储过程定义，确认 `设备管理_设备信息_查询/增加/编辑` 只处理设备名称、设备型号、设备类型。 8. 重写 `src/views/DeviceManagement/DeviceInformation/index.vue`：表格增加需求字段列；新增/编辑弹窗增加需求字段；公司编码新增必填、编辑禁用；工位绑定使用多选下拉，来源为 `MES_登录_工位与名称_查询`；主要设备、特种设备使用“是/否”下拉；证书有效期至使用日期选择；增加当前页证书有效期排序和行背景色；固定操作列，适配横向多列表格。 9. 新增 `db_backups/update_device_information_maintenance_20260629.sql`：使用 `COL_LENGTH` 可重复执行地增加 14 个新字段；更新 `设备管理_设备信息_查询`，返回新字段并按证书有效期预警排序；更新 `设备管理_设备信息_增加`，写入新字段并校验公司编码不能为空；更新 `设备管理_设备信息_编辑`，更新新字段但不更新公司编码。 10. 使用 `sqlcmd -f 65001` 执行增量脚本到目标库，执行成功。 11. 验证数据库字段：`dbo.基础数据_设备工位点检表` 已存在公司编码、设备信息、使用部门、入账日期、单位、数量、状态、维修记录、维保记录、工位绑定、主要设备、设备标准开机工时、特种设备、证书有效期至。 12. 验证存储过程参数：`设备管理_设备信息_增加` 已包含新增字段参数；`设备管理_设备信息_编辑` 已包含新增字段参数和设备流水号；`设备管理_设备信息_查询` 保持旧查询参数兼容。 13. 执行 `EXEC dbo.[设备管理_设备信息_查询]`，过程执行无错误。 14. 第一次执行 `npm run build` 因 124 秒超时未得到结果；随后使用更长超时时间重跑。 15. 第二次执行 `npm run build` 成功，webpack 编译通过，仅有项目既有资源体积过大和 Browserslist 数据过期警告。 16. 创建 `work/DeviceManagement/DeviceInformation`。 17. 复制 `doc/修改设备信息维护.docx` 到 `work/DeviceManagement/DeviceInformation/修改设备信息维护.docx`。 18. 在工作目录新增 `README.md`、`01-项目功能内容.md`、`02-项目程序开发详细步骤.md`、`03-推进台账.md`、`04-任务矩阵.md`、`05-验收证据.md`、`06-决策记录.md`。 ### 修改文件 - `src/views/DeviceManagement/DeviceInformation/index.vue` - `db_backups/update_device_information_maintenance_20260629.sql` - `work/DeviceManagement/DeviceInformation/修改设备信息维护.docx` - `work/DeviceManagement/DeviceInformation/README.md` - `work/DeviceManagement/DeviceInformation/01-项目功能内容.md` - `work/DeviceManagement/DeviceInformation/02-项目程序开发详细步骤.md` - `work/DeviceManagement/DeviceInformation/03-推进台账.md` - `work/DeviceManagement/DeviceInformation/04-任务矩阵.md` - `work/DeviceManagement/DeviceInformation/05-验收证据.md` - `work/DeviceManagement/DeviceInformation/06-决策记录.md` - `gptlog-process/gpdlog.md` ### 验证结果 - 数据库连接：通过。 - 表字段新增：通过。 - 存储过程参数更新：通过。 - 查询过程执行：通过。 - 前端生产构建 `npm run build`：通过，仅有既有警告。 ### 下一步 - 登录真实系统页面做人工验收：新增设备、编辑设备、工位多选、公司编码只读、证书有效期颜色和排序。 - 如现场要求历史设备补齐公司编码，需要补充历史数据治理脚本和验收规则。 ## 2026-06-29 设备信息维护取消设备类型必填 ### 用户需求 - 去掉设备类型必填修改。 ### 执行过程 1. 打开 `src/views/DeviceManagement/DeviceInformation/index.vue`。 2. 在表单校验 `rules` 中移除 `设备类型` 必填规则。 3. 保留公司编码新增必填和生产用名必填。 4. 更新 `work/DeviceManagement/DeviceInformation/03-推进台账.md`，追加第 2 轮记录。 5. 更新 `work/DeviceManagement/DeviceInformation/04-任务矩阵.md`，新增 `DI-008A` 任务记录。 ### 修改文件 - `src/views/DeviceManagement/DeviceInformation/index.vue` - `work/DeviceManagement/DeviceInformation/03-推进台账.md` - `work/DeviceManagement/DeviceInformation/04-任务矩阵.md` - `gptlog-process/gpdlog.md` ### 验证结果 - 代码层确认设备类型不再配置必填校验。 ## 2026-06-29 修复设备信息维护日期编辑报错 ### 用户反馈 - 证书有效期和入账日期编辑时报错，无法编辑修改。 ### 执行过程 1. 查询目标库 `dbo.基础数据_设备工位点检表`，确认测试数据中 `入账日期` 和 `证书有效期至` 已有日期值。 2. 查看当前前端 `src/views/DeviceManagement/DeviceInformation/index.vue`，确认两个日期字段由 `el-date-picker` 以 `yyyy-MM-dd` 字符串提交。 3. 查看当前 `设备管理_设备信息_编辑` 存储过程，确认 `@入账日期`、`@证书有效期至` 定义为 `date` 类型。 4. 判断问题原因：通用前端网关提交日期和空值时容易与 SQL Server `date` 参数转换冲突，尤其编辑清空日期时会报错。 5. 修改前端页面：新增 `dateParam` 方法，两个日期字段提交时传 `yyyy-MM-dd` 字符串或空字符串，不再传 `null`。 6. 新增数据库修复脚本 `db_backups/fix_device_information_date_edit_20260629.sql`。 7. 修复脚本调整 `设备管理_设备信息_增加/编辑`： - `@入账日期` 改为 `nvarchar(50)`。 - `@证书有效期至` 改为 `nvarchar(50)`。 - 写入表时使用 `TRY_CONVERT(date, NULLIF(@入账日期, N''))`。 - 写入表时使用 `TRY_CONVERT(date, NULLIF(@证书有效期至, N''))`。 8. 使用 `sqlcmd -f 65001` 执行修复脚本到 `192.168.2.92 / YL_MESDB`，执行成功。 9. 查询 `sys.parameters`，确认 `设备管理_设备信息_增加/编辑` 的两个日期参数已变更为 `nvarchar`。 10. 直接执行 `设备管理_设备信息_编辑` 测试正常日期：传入 `2026-07-01` 和 `2026-07-31`，返回 `result=1`，数据库日期更新成功。 11. 直接执行 `设备管理_设备信息_编辑` 测试清空日期：传入空字符串，返回 `result=1`，数据库日期字段保存为 `NULL`。 12. 更新工作目录文档：推进台账、任务矩阵、验收证据。 ### 修改文件 - `src/views/DeviceManagement/DeviceInformation/index.vue` - `db_backups/fix_device_information_date_edit_20260629.sql` - `work/DeviceManagement/DeviceInformation/03-推进台账.md` - `work/DeviceManagement/DeviceInformation/04-任务矩阵.md` - `work/DeviceManagement/DeviceInformation/05-验收证据.md` - `gptlog-process/gpdlog.md` ### 验证结果 - 修复 SQL 执行：通过。 - 日期参数类型验证：通过，已为 `nvarchar`。 - 正常日期编辑验证：通过。 - 清空日期编辑验证：通过，日期保存为 `NULL`。 ### 补充验证 - 执行 `npm run build`，前端生产构建通过。 - webpack compiled with 2 warnings，仍为项目既有资源体积过大和 Browserslist/caniuse-lite 数据过期警告。 ## 2026-06-29 修复设备信息维护日期控件点击报错 ### 用户反馈 - 点击修改入账日期或证书有效期时报错：`TypeError: date.getHours is not a function`。 - 报错来自 Element UI 日期组件 `DateTable`，说明日期控件内部拿到的不是 `Date` 对象。 ### 执行过程 1. 查看 `src/views/DeviceManagement/DeviceInformation/index.vue`，确认两个 `el-date-picker` 使用了 `value-format="yyyy-MM-dd"`，并且编辑回填时给表单日期字段赋值为字符串。 2. 判断原因：Element UI 的日期面板点击逻辑需要 `Date` 对象参与内部时间修改，当前字符串值导致 `date.getHours is not a function`。 3. 修改两个日期控件：去掉 `value-format="yyyy-MM-dd"`，让 `v-model` 保持 `Date` 对象。 4. 修改编辑回填：`入账日期` 和 `证书有效期至` 改为调用 `parseDateValue`，将数据库日期转换为本地 `Date` 对象。 5. 保留提交兼容：`dateParam` 在提交前将 `Date` 对象格式化成 `yyyy-MM-dd` 字符串，继续兼容已修复的数据库过程。 6. 执行 `npm run build`，前端构建通过。 7. 更新工作目录中的推进台账、任务矩阵和验收证据。 ### 修改文件 - `src/views/DeviceManagement/DeviceInformation/index.vue` - `work/DeviceManagement/DeviceInformation/03-推进台账.md` - `work/DeviceManagement/DeviceInformation/04-任务矩阵.md` - `work/DeviceManagement/DeviceInformation/05-验收证据.md` - `gptlog-process/gpdlog.md` ### 验证结果 - 两个日期控件已移除 `value-format`。 - 编辑回填日期已转换为 `Date` 对象。 - 提交前仍格式化为 `yyyy-MM-dd` 字符串。 - `npm run build` 通过，仅有项目既有资源体积和 Browserslist 过期警告。 ## 2026-06-29 修复设备信息维护编辑弹窗日期不回填 ### 用户反馈 - 数据库有值，列表也有值，只是点击编辑时 `入账日期` 和 `证书有效期至` 读不到，显示为空。 ### 执行过程 1. 查询数据库 `dbo.基础数据_设备工位点检表`，发现上一轮为了验证清空日期，测试记录 `设备流水号=1` 的两个日期被置为 `NULL`。 2. 根据用户说明数据库和列表实际有值，判断问题仍集中在前端 `handleEdit` 日期回填。 3. 恢复测试记录日期：`入账日期=2026-07-01`，`证书有效期至=2026-07-31`。 4. 增强 `formatDate`，兼容 `yyyy-MM-dd`、`yyyy-MM-dd HH:mm:ss`、`yyyy/MM/dd`、`/Date(...)` 等后端可能返回格式。 5. 增强 `parseDateValue`，支持直接传入 `Date` 对象，也支持通过 `formatDate` 解析字符串后生成本地 `Date` 对象。 6. 将表单默认日期从空字符串调整为 `null`，符合 Element UI 日期控件空值约定。 7. 修改编辑回填逻辑：不再整体替换 `this.form`，改为逐字段 `$set`，避免 Element Form 字段状态缓存导致日期控件未刷新。 8. 在 `dialogFormVisible = true` 后通过 `$nextTick` 再次设置 `入账日期` 和 `证书有效期至`，防止被 `resetFields` 或弹窗初始化覆盖。 9. 使用 Node 脚本验证多种日期格式均能解析为有效 `Date`。 10. 执行 `npm run build`，前端构建通过，仅有既有资源体积和 Browserslist 过期警告。 11. 确认本地 dev server 已运行在 `https://127.0.0.1:1997/`。命令行访问被自签名证书拦截，浏览器打开时需要允许证书后测试。 12. 更新工作目录中的推进台账、任务矩阵和验收证据。 ### 修改文件 - `src/views/DeviceManagement/DeviceInformation/index.vue` - `work/DeviceManagement/DeviceInformation/03-推进台账.md` - `work/DeviceManagement/DeviceInformation/04-任务矩阵.md` - `work/DeviceManagement/DeviceInformation/05-验收证据.md` - `gptlog-process/gpdlog.md` ### 验证结果 - 数据库测试记录日期恢复：通过。 - 本地日期解析函数测试：通过。 - 前端生产构建 `npm run build`：通过，仅有既有警告。 - 本地页面地址：`https://127.0.0.1:1997/`。 ## 2026-06-29 新增设备名称字段并导入设备信息 Excel ### 用户反馈 - 用户要求新增字段“设备名称”。 - 用户要求将 `doc` 下的设备信息数据插入数据库。 - 用户补充说明数据文件为 `设备信息.xlsx`。 - 用户要求继续执行。 ### 执行过程 1. 检查 `doc/设备信息.xlsx`，确认 Sheet1 表头为：`名称`、`公司编码`、`生产用名`、`型号/规格`、`设备信息`、`使用部门`、`入账日期`、`单位`、`数量`、`状态`。 2. 读取 Excel 数据，确认有效数据共 89 行。 3. 查询目标数据库 `192.168.2.92 / YL_MESDB`，确认 `dbo.基础数据_设备工位点检表` 当时为空。 4. 明确字段映射：Excel `名称` 保存到新增数据库字段 `名称`，页面显示为“设备名称”；Excel `生产用名` 保存到原字段 `设备名称`，页面显示为“生产用名”。 5. 修改 `src/views/DeviceManagement/DeviceInformation/index.vue`： - 列表新增“设备名称”列，绑定 `名称`。 - 新增/编辑弹窗新增“设备名称”输入框，绑定 `form.名称`。 - `emptyForm` 增加 `名称`。 - 编辑回填增加 `名称`。 - 新增/编辑提交参数增加 `名称`。 6. 生成 `db_backups/add_device_name_and_import_excel_20260629.sql`： - 表 `dbo.基础数据_设备工位点检表` 不存在 `名称` 字段时新增该字段。 - 调整 `设备管理_设备信息_增加` 和 `设备管理_设备信息_编辑`，增加 `@名称` 参数。 - 使用 `MERGE` 按 `公司编码` 导入或更新 Excel 数据，避免重复导入生成重复记录。 7. 执行导入脚本，数据库导入后设备信息总数为 89。 8. 抽样检查发现 Excel 日期对象导入后部分 `入账日期` 早一天，例如 `1/1/07` 被保存为 `2006-12-31`。 9. 根据 Excel 单元格显示值重新生成 `db_backups/fix_device_excel_import_dates_20260629.sql`，并执行日期修正。 10. 修正后抽样验证： - `REALLY-11` 入账日期为 `2007-01-01`。 - `REALLY-6` 入账日期为 `2008-12-24`。 - `REALLY-1` 入账日期为 `2011-01-01`。 11. 检查新增过程文本，发现“公司编码不能为空”提示在首次脚本生成时变成问号文本。 12. 使用 `apply_patch` 修正导入脚本里的提示文本，并新增 `db_backups/fix_device_add_company_code_message_20260629.sql`，只重新发布新增过程，不重新执行整份导入脚本，避免覆盖已修正日期。 13. 执行提示文本修正脚本，确认新增过程可返回中文提示。 14. 复制 `doc/设备信息.xlsx` 到 `work/DeviceManagement/DeviceInformation/设备信息.xlsx` 作为工作副本。 15. 更新 `work/DeviceManagement/DeviceInformation` 下的 README、01-项目功能内容、02-项目程序开发详细步骤、03-推进台账、04-任务矩阵、05-验收证据、06-决策记录。 16. 执行 `npm run build`，前端构建通过，仅有项目既有资源体积和 Browserslist/caniuse-lite 过期警告。 ### 修改文件 - `src/views/DeviceManagement/DeviceInformation/index.vue` - `db_backups/add_device_name_and_import_excel_20260629.sql` - `db_backups/fix_device_excel_import_dates_20260629.sql` - `db_backups/fix_device_add_company_code_message_20260629.sql` - `work/DeviceManagement/DeviceInformation/设备信息.xlsx` - `work/DeviceManagement/DeviceInformation/README.md` - `work/DeviceManagement/DeviceInformation/01-项目功能内容.md` - `work/DeviceManagement/DeviceInformation/02-项目程序开发详细步骤.md` - `work/DeviceManagement/DeviceInformation/03-推进台账.md` - `work/DeviceManagement/DeviceInformation/04-任务矩阵.md` - `work/DeviceManagement/DeviceInformation/05-验收证据.md` - `work/DeviceManagement/DeviceInformation/06-决策记录.md` - `gptlog-process/gpdlog.md` ### 验证结果 - Excel 有效数据行数：89。 - 数据库设备信息总数：89。 - `名称` 字段已存在并用于页面“设备名称”。 - Excel `生产用名` 继续保存到原 `设备名称` 字段。 - 日期修正后样例数据正确。 - 新增过程提示文本已修正为“公司编码不能为空”。 - `npm run build` 通过，仅有既有警告。 ## 2026-06-29 新增及时齐套跟踪结果页面 ### 用户需求 - 根据 `doc/新增及时齐套跟踪结果.docx` 新增页面“及时齐套跟踪结果”。 - 修改后在 `work` 下创建对应路径并复制原始文档。 - 在对应路径新增或修改 `01-项目功能内容`、`02-项目程序开发详细步骤`、`03-推进台账`、`04-任务矩阵`、`05-验收证据`、`06-决策记录` 和 README 索引。 - 将完整执行过程使用中文追加到 `/gptlog-process/gpdlog.md`。 ### 执行过程 1. 在 `doc` 目录查找需求文档，确认真实文件为 `doc/新增及时齐套跟踪结果.docx`。 2. 将 docx 临时复制为 zip 并解包读取 `word/document.xml`，提取需求正文。 3. 从需求中确认： - 一级数据字段按计划用表页面一致。 - 过滤条件和计划用表页面一致。 - 二级绿色数据来自 `SAP.SBO_YL.dbo.VIEW_Jijiankukc`。 - 二级字段包括物料编码、物料名称、缺件数量、属性、生产订单号、进度、工艺路线、预计完成时间。 4. 查找现有页面，确认“计划用表”为 `src/views/PlanManagement/PlanShell/index.vue`，使用过程 `计划排产_查询计划信息`。 5. 查找“生产计划跟踪”为 `src/views/ProductionManagement/ProductionPlanTrack/index.vue`，复用其当前序和工艺路线展示思路。 6. 查询数据库菜单表，确认“计划用表”挂在 `PlanManagement` 下，因此新页面也放在 `PlanManagement` 模块。 7. 查询 SAP linked server，确认可通过 `[SAP].[SBO_YL].[dbo].[VIEW_Jijiankukc]` 访问 SAP 缺件视图。 8. 查询 SAP 视图字段，确认存在 `ItemCode`、`U_Name`、`属性`、`未发货数量`、`在制采购`、`采购员`、`采购预计交货日期`、`采购未清数量`、`到货草稿`。 9. 查询 MES 视图字段，确认 `View_生产订单_MES` 可提供计划号、合同号、订单编号、物料编号、物料描述、计划数量、计划完成、计划开始时间、计划完成时间、齐套、发料状态、拣配状态、自制件属性、任务状态、加工状态、进度等字段。 10. 新增 `db_backups/create_timely_kit_tracking_result_20260629.sql`，创建或更新 `dbo.生产管理_及时齐套跟踪结果_查询`。 11. 新过程按计划用表参数接收筛选条件，并将 SAP 缺件数据与 MES 生产计划匹配： - 机加件：`SAP.ItemCode = MES.物料编号`。 - 装配件：`SAP.ItemCode + SAP.Project = MES.物料编号 + MES.合同号`。 - 外购件：属性为空，生产订单号取 SAP `在制采购`，工艺路线列拼接采购信息和质检状态。 12. 首次执行查询过程取样时，SQL Server 报 `QUOTED_IDENTIFIER` SET 选项错误。 13. 修改 SQL 脚本，增加 `SET ANSI_NULLS ON` 和 `SET QUOTED_IDENTIFIER ON`，重新发布过程。 14. 再次执行取样查询，确认过程可返回 SAP 缺件和 MES 计划组合数据。 15. 新增 `db_backups/add_timely_kit_tracking_result_menu_20260629.sql`。 16. 执行菜单脚本，按“计划用表”的角色授权复制新增菜单，生成 4 条“及时齐套跟踪结果”菜单记录。 17. 新增前端页面 `src/views/PlanManagement/TimelyKitTrackingResult/index.vue`： - 过滤区参考计划用表。 - 主表展示一级计划字段。 - 展开行展示二级缺件跟踪数据。 - 二级明细行使用浅绿色背景。 - 状态字段使用绿色/橙色标签样式。 18. 执行 `npm run build`，构建通过，仅有项目既有资源体积过大和 Browserslist/caniuse-lite 过期警告。 19. 创建 `work/PlanManagement/TimelyKitTrackingResult`。 20. 复制 `doc/新增及时齐套跟踪结果.docx` 到工作目录。 21. 新增 README、01-项目功能内容、02-项目程序开发详细步骤、03-推进台账、04-任务矩阵、05-验收证据、06-决策记录。 ### 修改文件 - `src/views/PlanManagement/TimelyKitTrackingResult/index.vue` - `db_backups/create_timely_kit_tracking_result_20260629.sql` - `db_backups/add_timely_kit_tracking_result_menu_20260629.sql` - `work/PlanManagement/TimelyKitTrackingResult/新增及时齐套跟踪结果.docx` - `work/PlanManagement/TimelyKitTrackingResult/README.md` - `work/PlanManagement/TimelyKitTrackingResult/01-项目功能内容.md` - `work/PlanManagement/TimelyKitTrackingResult/02-项目程序开发详细步骤.md` - `work/PlanManagement/TimelyKitTrackingResult/03-推进台账.md` - `work/PlanManagement/TimelyKitTrackingResult/04-任务矩阵.md` - `work/PlanManagement/TimelyKitTrackingResult/05-验收证据.md` - `work/PlanManagement/TimelyKitTrackingResult/06-决策记录.md` - `gptlog-process/gpdlog.md` ### 验证结果 - SAP linked server 取样查询：通过。 - `dbo.生产管理_及时齐套跟踪结果_查询` 执行：通过。 - 菜单脚本执行：通过，新增 4 条菜单记录。 - 前端构建 `npm run build`：通过，仅有既有警告。 ## 2026-06-29 修正及时齐套跟踪结果页面反馈问题 ### 用户反馈 1. 工艺路线缺少日期行和合格行，且没有颜色。 2. 二级数据里面存在重复数据，不应该出现生产订单号一样的数据。 3. 属性为空时代表外购，一级数据不对，应该取 SAP 视图 `DocEntry` 作为订单编号，再按照计划用表查询。 ### 执行过程 1. 复查 `src/views/PlanManagement/TimelyKitTrackingResult/index.vue`，确认二级明细原先只把工艺路线作为文本展示，不能展示日期行、工序行、合格行和状态颜色。 2. 复查 `db_backups/create_timely_kit_tracking_result_20260629.sql`，确认 SAP 缺件数据与 MES 计划数据匹配时，属性为空的外购数据仍可能使用在制采购号，导致一级计划数据取值不符合反馈要求。 3. 查询样例订单 `7134`，确认同一个缺件生产订单号在二级明细中会重复出现。 4. 查询样例订单 `7335`，确认该外购场景需要使用 SAP 视图 `DocEntry=7335` 作为订单编号匹配计划用表数据。 5. 修改 SQL 查询过程脚本： - 新增 SAP 缺件源数据去重，按 `DocEntry + Project + ItemCode + 属性` 保留一条。 - 外购属性为空时，一级订单编号改为优先使用 `SAP.DocEntry`。 - 外购属性为空时，MES 计划用表匹配条件增加 `MES.订单编号 = SAP.DocEntry`。 - 新增 `工艺路线明细` JSON 字段，返回工序名称、计划开始时间、计划完成时间、进度、完成数量、收检合格数、收检不合格数、加工状态等页面渲染所需数据。 - 最终结果增加按 `订单号 + 缺件生产订单号` 的去重层，避免同一生产订单号在二级明细重复出现。 6. 重新执行 `db_backups/create_timely_kit_tracking_result_20260629.sql`，发布查询过程成功。 7. 修改前端页面： - 二级列“工艺路线/采购状态”增加自制件工艺路线 HTML 渲染。 - 工艺路线渲染为三行结构：日期行、工序行、合格行。 - 根据工序进度和加工状态增加绿色、蓝色、橙色、红色样式。 - 外购件仍展示采购状态文本。 - 前端合并数据时增加二级明细去重，避免接口数据异常时重复展示同一生产订单号。 8. 更新工作目录文档： - `work/PlanManagement/TimelyKitTrackingResult/03-推进台账.md` - `work/PlanManagement/TimelyKitTrackingResult/04-任务矩阵.md` - `work/PlanManagement/TimelyKitTrackingResult/05-验收证据.md` - `work/PlanManagement/TimelyKitTrackingResult/06-决策记录.md` ### 修改文件 - `src/views/PlanManagement/TimelyKitTrackingResult/index.vue` - `db_backups/create_timely_kit_tracking_result_20260629.sql` - `work/PlanManagement/TimelyKitTrackingResult/03-推进台账.md` - `work/PlanManagement/TimelyKitTrackingResult/04-任务矩阵.md` - `work/PlanManagement/TimelyKitTrackingResult/05-验收证据.md` - `work/PlanManagement/TimelyKitTrackingResult/06-决策记录.md` - `gptlog-process/gpdlog.md` ### 验证结果 - 重新发布 `dbo.生产管理_及时齐套跟踪结果_查询` 成功。 - 查询 `@订单号=7134` 时，同一缺件生产订单号 `7134` 的二级明细只返回 1 条，不再重复。 - 查询 `@订单号=7335` 时，外购一级数据已按 `SAP.DocEntry=7335` 匹配到计划用表数据。 - 执行 `npm run build` 通过，仅保留项目已有的资源体积过大和 Browserslist/caniuse-lite 过期警告。 ### 下一步 - 登录页面人工查看展开行效果，重点确认工艺路线日期行、工序行、合格行和颜色是否与业务预期一致。 ## 2026-06-29 继续修正及时齐套跟踪结果外购和主数据问题 ### 用户反馈 1. 属性为空的外购数据应取 SAP 视图的采购员、采购未清数量、到货草稿，并根据到货草稿匹配采购入库检页面的生产订单读取检验状态。 2. 第 32 行主数据生产订单号 `2007` 的一级数据是正确参照；前 1-10 行不正确，主数据缺件不应是主数据自身，且主数据产品编码后面的字段不应为空。 ### 执行过程 1. 复查 `db_backups/create_timely_kit_tracking_result_20260629.sql`，确认上一版把一级主数据和二级缺件匹配混在同一个 `v` 里。 2. 定位到问题来源：SQL 使用 `COALESCE(v.订单编号, sap.DocEntry)`、`COALESCE(v.物料编号, sap.ItemCode)`、`COALESCE(v.物料描述, sap.U_Name)` 作为主数据兜底，导致 SAP 缺件在没有匹配到计划用表时也会生成主表行。 3. 查询 `@订单号=2007`，确认一级主数据完整，但外购缺件生产订单号显示成主订单号 `2007`，业务含义错误。 4. 查看采购入库检页面 `src/views/QualityManagement/CheckTask/purchaseIncoming.vue`，确认查询过程为 `质量管理_质量检验_入库质检任务_查询`，页面生产订单字段来自 `质量检验_质检任务_SAP.订单编号`。 5. 查看 `doc_old/fix_质量管理_入库质检任务_查询.sql`，确认采购入库检状态按 `质量检验_质检任务_SAP.入库数量` 和 `YL_质量检验_质检记录.检验数量` 判断。 6. 修改查询过程： - 一级主数据只按 `SAP.DocEntry = View_生产订单_MES.订单编号` 匹配。 - 删除主数据字段对 SAP 缺件字段的兜底。 - 新增 `detail_order`，仅用于自制缺件匹配二级生产订单、工艺路线和进度。 - 外购缺件生产订单号改为 `SAP.到货草稿`；到货草稿为 0 时留空。 - 外购质检状态改为 `SAP.到货草稿 -> 质量检验_质检任务_SAP.订单编号 -> YL_质量检验_质检记录` 口径。 - 非外购质检状态保持为空。 7. 重新发布 `dbo.生产管理_及时齐套跟踪结果_查询` 成功。 8. 验证 `@订单号=2007`：一级主数据完整，外购缺件生产订单号不再等于 `2007`。 9. 验证 `@订单号=7321`：外购缺件到货草稿 `11209` 显示为缺件生产订单号，质检状态为未完成。 10. 默认查询统计：总行数 198，产品编码/产品名称为空行数 0，缺件生产订单号等于主订单号行数 0，非外购质检状态非空行数 0。 11. 执行 `npm run build`，构建通过，仅保留项目既有 warning。 12. 删除临时验证脚本 `db_backups/verify_timely_kit_tracking_result_temp_20260629.sql`。 13. 更新 `work/PlanManagement/TimelyKitTrackingResult` 下推进台账、任务矩阵、验收证据、决策记录，并追加本日志。 ### 修改文件 - `db_backups/create_timely_kit_tracking_result_20260629.sql` - `work/PlanManagement/TimelyKitTrackingResult/03-推进台账.md` - `work/PlanManagement/TimelyKitTrackingResult/04-任务矩阵.md` - `work/PlanManagement/TimelyKitTrackingResult/05-验收证据.md` - `work/PlanManagement/TimelyKitTrackingResult/06-决策记录.md` - `gptlog-process/gpdlog.md` ### 验证结果 - 查询过程发布成功。 - `@订单号=2007`：一级主数据完整，外购缺件生产订单号不再等于 `2007`。 - `@订单号=7321`：外购缺件按到货草稿 `11209` 显示缺件生产订单号，质检状态来自采购入库检口径。 - 默认查询统计：总行数 198，产品编码/产品名称为空行数 0，缺件生产订单号等于主订单号行数 0，非外购质检状态非空行数 0。 - `npm run build` 通过，仅有项目既有资源体积过大和 Browserslist/caniuse-lite 过期警告。 ## 2026-06-30 修正及时齐套跟踪结果库存数量、采购员和工艺路线样式 ### 用户反馈 1. `src/views/PlanManagement/TimelyKitTrackingResult/index.vue` 页面二级数据需要在缺件数量后增加库存数量字段，库存数量在 SAP 里有。 2. 去掉拼接的采购员字段。 3. 工艺路线需要左对齐，当前间隔偏大。 4. 工艺路线颜色参考生产计划跟踪页面，使用红、蓝、绿，不使用橙色。 5. 所有改动按昨日方式维护 01-06 文档、README 索引、推进台账、任务矩阵、验收证据、决策记录，并追加总日志。 ### 执行过程 1. 读取目标页面 `src/views/PlanManagement/TimelyKitTrackingResult/index.vue`，确认二级明细已有缺件数量、采购员列，以及本页自定义工艺路线样式。 2. 读取参考页面 `src/views/ProductionManagement/ProductionPlanTrack/index.vue`，确认生产计划跟踪的工艺路线为左对齐、紧凑间距、红/蓝/绿文字配色。 3. 修改前端页面： - 在二级明细“缺件数量”后新增“库存数量”列。 - 在 `mergeRows` 中新增 `库存数量: this.formatQuantity(row.库存数量)`。 - 删除二级明细“采购员”列和 `采购员` 映射。 - 工艺路线名称只显示工序名称，不再拼接指派对象。 - 删除橙色状态判断和橙色样式。 - 调整 `.process-route` 相关样式为左对齐、缩小箭头和单元格间距、红/蓝/绿三色。 4. 连接数据库 `192.168.2.92 / YL_MESDB`，读取 SAP 视图字段列表，确认 `[SAP].[SBO_YL].[dbo].[VIEW_Jijiankukc]` 包含 `库存量` 字段。 5. 新增数据库增量脚本 `db_backups/update_timely_kit_tracking_result_inventory_20260630.sql`，不覆盖 20260629 历史脚本。 6. 修改增量脚本： - 在 `SAP缺件源` 中增加 `ISNULL(s.[库存量], 0) AS 库存数量`。 - 在查询结果中输出 `sap.[库存数量] AS [库存数量]`。 - 最终 SELECT 输出 `[库存数量]`。 - 删除 `sap.[采购员]` 输出。 - 外购采购状态文本从 `采购员 + 未清数量 + 到货草稿 + 质检状态` 改为 `未清数量 + 到货草稿 + 质检状态`。 7. 执行 `db_backups/update_timely_kit_tracking_result_inventory_20260630.sql` 发布过程，发布成功。 8. 验证 `@订单号=2007`，返回缺件 `24112-011-HY-WF50L`，缺件数量 `78`，库存数量 `27`，结果列不再包含采购员。 9. 验证 `@订单号=7321`，返回缺件 `XX-YG01013990`，缺件数量 `6`，库存数量 `2`，外购采购状态不再包含采购员。 10. 执行过程定义检查，结果为“有库存数量 / 未拼接采购员”。 11. 曾尝试用 `OPENQUERY([LOCALSERVER], ...)` 做辅助落表验证，但数据库未配置 `LOCALSERVER` linked server，该无效命令不作为验收证据，已用过程样例和定义检查替代。 12. 执行 `npm run build`，构建通过，仅有项目既有资源体积过大和 Browserslist/caniuse-lite 过期警告。 13. 更新 README、01-06 文档、推进台账、任务矩阵、验收证据、决策记录，并追加本日志。 ### 修改文件 - `src/views/PlanManagement/TimelyKitTrackingResult/index.vue` - `db_backups/update_timely_kit_tracking_result_inventory_20260630.sql` - `work/PlanManagement/TimelyKitTrackingResult/README.md` - `work/PlanManagement/TimelyKitTrackingResult/01-项目功能内容.md` - `work/PlanManagement/TimelyKitTrackingResult/02-项目程序开发详细步骤.md` - `work/PlanManagement/TimelyKitTrackingResult/03-推进台账.md` - `work/PlanManagement/TimelyKitTrackingResult/04-任务矩阵.md` - `work/PlanManagement/TimelyKitTrackingResult/05-验收证据.md` - `work/PlanManagement/TimelyKitTrackingResult/06-决策记录.md` - `gptlog-process/gpdlog.md` ### 验证结果 - SAP 视图字段确认：`VIEW_Jijiankukc` 包含 `库存量`。 - SAP 视图取样：`DocEntry=2007`、`ItemCode=24112-011-HY-WF50L`、`未发货数量=78`、`库存量=27`。 - 查询过程发布成功。 - `@订单号=2007` 返回 `库存数量=27`。 - `@订单号=7321` 返回 `库存数量=2`。 - 过程定义检查：有 `库存数量`，未拼接 `采购员:`。 - `npm run build` 通过，仅有项目既有 warning。 ### 下一步 - 登录系统人工验收“及时齐套跟踪结果”展开行，确认库存数量位置、外购采购状态文本、工艺路线左对齐和红/蓝/绿颜色符合现场预期。 ## 2026-06-30 修正及时齐套跟踪结果 7134 工艺路线判色 ### 用户反馈 - 当前页二级数据 `7134` 的工艺路线颜色仍有问题：当前页显示一个蓝色两个红色，生产计划跟踪显示两个蓝色一个红色。 ### 执行过程 1. 对比当前页 `src/views/PlanManagement/TimelyKitTrackingResult/index.vue` 和生产计划跟踪 `src/views/ProductionManagement/ProductionPlanTrack/index.vue` 的工艺路线判色函数。 2. 查询数据库确认 `7134` 工艺数据： - 打磨：加工状态 `6`，收检合格数 `6`。 - 打压检测：加工状态为空，收检合格数 `6`。 - 喷塑：外协，收检合格数 `0`。 3. 确认差异原因：当前页旧逻辑按进度、计划数量、完成数量或收检数量达到计划数量判蓝；生产计划跟踪按加工状态 `6/3` 或 `收检合格数 > 0` 判蓝。 4. 修改当前页判色逻辑： - 新增 `isBlueProcess`，与生产计划跟踪一致。 - 新增 `isGreenProcess`，与生产计划跟踪外协绿色口径一致。 - 新增 `getProcessBaseClass` 和 `getOutsourceGroupClassState`，复用生产计划跟踪的外协连续分组判色口径。 - `formatProcessRoute` 改为基于 `outsourceGroupClasses` 获取颜色。 5. 本地模拟 `7134` 判色结果：`step1:process-route-blue,step2:process-route-blue,step3:process-route-red`。 6. 执行 `npm run build`，构建通过，仅有项目既有资源体积和 Browserslist/caniuse-lite 过期警告。 7. 更新推进台账、任务矩阵、验收证据、决策记录和总日志。 ### 修改文件 - `src/views/PlanManagement/TimelyKitTrackingResult/index.vue` - `work/PlanManagement/TimelyKitTrackingResult/03-推进台账.md` - `work/PlanManagement/TimelyKitTrackingResult/04-任务矩阵.md` - `work/PlanManagement/TimelyKitTrackingResult/05-验收证据.md` - `work/PlanManagement/TimelyKitTrackingResult/06-决策记录.md` - `gptlog-process/gpdlog.md` ### 验证结果 - SQL 验证 `7134` 的第二道工序“打压检测”有 `收检合格数=6`。 - 本地判色模拟结果为两个蓝色、一个红色。 - 当前页无 `process-route-orange`。 - `npm run build` 通过，仅有项目既有 warning。 ### 下一步 - 登录页面展开 `7134`，确认当前页工艺路线颜色与生产计划跟踪一致。 ## 2026-06-30 恢复外购采购状态采购员拼接 ### 用户反馈 - 还原字段拼接采购员部分。 - 不要单独的采购员列。 ### 执行过程 1. 确认前端 `src/views/PlanManagement/TimelyKitTrackingResult/index.vue` 当前没有单独采购员列。 2. 修改最新过程脚本 `db_backups/update_timely_kit_tracking_result_purchase_order_20260630.sql`： - 在 `SAP缺件源` 中重新读取 `s.[采购员] COLLATE DATABASE_DEFAULT AS 采购员`。 - 外购 `工艺路线/采购状态` 文本改为 `采购员:xxx / 未清数量:xxx / 到货草稿:xxx / 质检状态:xxx`。 - 不在最终 SELECT 中输出单独 `采购员` 字段。 3. 发布 `dbo.生产管理_及时齐套跟踪结果_查询` 成功。 4. 查询 `@订单号=7321` 验证： - 缺件生产订单号为 `4111`，来自 SAP `在制采购`。 - 工艺路线/采购状态为 `采购员:张丹 / 未清数量:50 / 到货草稿:11209 / 质检状态:未完成`。 - 预计完成时间为 `2026-06-25`，来自 SAP `采购预计交货日期`。 5. 使用 `sys.dm_exec_describe_first_result_set_for_object` 检查结果集列，确认没有单独 `采购员` 列。 6. 使用 `Select-String` 检查前端页面，确认没有 `label="采购员"` 或 `prop="采购员"`。 7. 执行 `npm run build`，构建通过，仅有项目既有资源体积和 Browserslist/caniuse-lite 过期警告。 8. 更新推进台账、任务矩阵、验收证据、决策记录和总日志。 ### 修改文件 - `db_backups/update_timely_kit_tracking_result_purchase_order_20260630.sql` - `work/PlanManagement/TimelyKitTrackingResult/03-推进台账.md` - `work/PlanManagement/TimelyKitTrackingResult/04-任务矩阵.md` - `work/PlanManagement/TimelyKitTrackingResult/05-验收证据.md` - `work/PlanManagement/TimelyKitTrackingResult/06-决策记录.md` - `gptlog-process/gpdlog.md` ### 验证结果 - 查询过程发布成功。 - `@订单号=7321` 外购采购状态已包含 `采购员:张丹`。 - 结果集无单独 `采购员` 列。 - 前端无单独采购员列。 - `npm run build` 通过，仅有项目既有 warning。 ### 下一步 - 登录页面确认外购采购状态文本显示采购员，且二级表没有单独采购员列。 ## 2026-06-30 自制缺件显示所有匹配生产订单 ### 用户反馈 - 同一个生产订单号不要出现重复。 - 同一缺件物料所有匹配生产订单都显示。 ### 执行过程 1. 排查 `@订单号=4222` 当前结果，确认旧过程只返回二级生产订单 `5960` 或 `7142` 中的一条。 2. 查询 SAP 缺件视图，确认 `4222` 的缺件物料为 `22-103-060-YDZF-20V1.0-4.1`，`DocNum=5960`。 3. 查询 MES 生产订单，确认同一缺件物料同时存在 `5960` 和 `7142` 两个生产订单。 4. 定位旧逻辑问题：`detail_order` 使用 `SELECT TOP (1)`，天然只能显示一个匹配生产订单。 5. 新增脚本 `db_backups/update_timely_kit_tracking_result_multi_detail_orders_20260630.sql`。 6. 修改 `detail_order`： - 去掉自制件匹配的 `TOP (1)` 单行限制。 - 使用 `ROW_NUMBER() OVER (PARTITION BY m.[订单编号] ORDER BY m.[订单行号])`，确保同一生产订单号只保留一条代表行。 - 同一缺件物料匹配到的多个不同生产订单全部返回。 7. 发布 `dbo.生产管理_及时齐套跟踪结果_查询` 成功。 8. 验证 `@订单号=4222` 返回两条二级数据：`5960` 和 `7142`，且同一生产订单号不重复。 9. 更新 README、推进台账、任务矩阵、验收证据、决策记录和总日志。 ### 修改文件 - `db_backups/update_timely_kit_tracking_result_multi_detail_orders_20260630.sql` - `work/PlanManagement/TimelyKitTrackingResult/README.md` - `work/PlanManagement/TimelyKitTrackingResult/03-推进台账.md` - `work/PlanManagement/TimelyKitTrackingResult/04-任务矩阵.md` - `work/PlanManagement/TimelyKitTrackingResult/05-验收证据.md` - `work/PlanManagement/TimelyKitTrackingResult/06-决策记录.md` - `gptlog-process/gpdlog.md` ### 验证结果 - 查询过程发布成功。 - `@订单号=4222` 二级数据返回 `5960` 和 `7142`。 - 同一生产订单号没有重复。 - `5960` 显示 13 道工艺路线，`7142` 显示 4 道工艺路线。 ### 下一步 - 登录页面展开 `4222`，确认二级数据同时显示所有匹配生产订单且不重复。 ## 2026-06-30 11:47:54 复核同缺件物料多生产订单显示 ### 复核内容 - 按用户最新口径确认：同一个生产订单号不要出现重复，同一缺件物料所有匹配生产订单都显示。 ### 验证结果 - 执行 `EXEC dbo.[生产管理_及时齐套跟踪结果_查询] @订单号 = 4222`。 - 二级数据中缺件物料 `22-103-060-YDZF-20V1.0-4.1` 当前同时返回生产订单 `5960` 和 `7142`。 - 同一生产订单号未重复出现。 ## 2026-06-30 生产订单关闭无工时可关闭处理 ### 用户反馈 - `dbo.计划排产_生产订单关闭_查询全部订单` 的“可关闭”查询以工时为基准。 - 当前只能查出全部校验的工时再筛选。 - 特殊情况：没有工时记录，但满足其他条件的订单也需要进入可关闭处理。 ### 执行过程 1. 读取线上过程定义，确认“可关闭”分支以 `dbo.View_生产工时视图` 为主表。 2. 核对页面 `src/views/PlanManagement/PlannOrderClose/index.vue`，确认默认查询为“可关闭 + 机加”。 3. 核对 `MES_接口_生产计划`、`View_生产工时视图` 字段，确认可从生产计划补充无工时订单。 4. 查询样例，确认 `7410` 无工时，但计划数量、入库数量、终检合格数均为 `1`，单据状态为空，属性为机加件。 5. 新增脚本 `db_backups/update_plan_order_close_no_work_hours_20260630.sql`。 6. 将“可关闭”分支调整为有工时订单和无工时满足条件订单合并： - 有工时订单继续要求全部工时校验。 - 无工时订单免工时校验，但保留原可关闭条件。 7. 初版全量查询超时后，改为先写入 `#工时订单` 临时表，再判断无工时，避免重复展开复杂视图。 8. 发布存储过程成功。 9. 验证 `@订单号=7410, @单据状态=可关闭, @属性=机加` 可返回。 10. 验证默认“可关闭 + 机加”查询约 `0.56` 秒返回，并命中 `7280`、`7409`、`7410`。 ### 修改文件 - `db_backups/update_plan_order_close_no_work_hours_20260630.sql` - `work/PlanManagement/PlannOrderClose/README.md` - `work/PlanManagement/PlannOrderClose/01-项目功能内容.md` - `work/PlanManagement/PlannOrderClose/02-项目程序开发详细步骤.md` - `work/PlanManagement/PlannOrderClose/03-推进台账.md` - `work/PlanManagement/PlannOrderClose/04-任务矩阵.md` - `work/PlanManagement/PlannOrderClose/05-验收证据.md` - `work/PlanManagement/PlannOrderClose/06-决策记录.md` - `gptlog-process/gpdlog.md` ### 验证结果 - 数据库过程发布成功。 - 无工时订单 `7410` 可进入可关闭结果。 - 默认“可关闭 + 机加”查询未超时，约 `0.56` 秒返回。 ## 2026-06-30 新增产品合格率(工位)页面 ### 用户反馈 - 查看 `doc/新增产品合格率.docx`。 - 根据文档新增页面 `产品合格率(工位)`。 ### 执行过程 1. 解包并读取 `doc/新增产品合格率.docx`，确认页面放在生产管理下。 2. 读取文档截图和文字，确认一级字段为关闭日期、生产订单号、物料名称、物料编码、计划数量、完成数量、不良数量、合格率。 3. 确认二级字段为工序、工序号、工位、完工数量、不良数量、合格率、检验说明。 4. 查询 `dbo.YL_质量检验_质检记录` 字段，确认生产订单号为 `计划号`，订单行号为 `行号`，工位字段为 `工位名称`。 5. 查询 SAP 视图 `SBO_YL.dbo.UBT_OWOR`，确认关闭日期字段为 `实际结算日期`，已关闭口径为 `单据状态 IS NOT NULL`。 6. 新增查询脚本 `db_backups/create_product_pass_rate_workstation_20260630.sql`。 7. 初版四段名跨库查询较慢，改为 `OPENQUERY([SAP], ...)` 将 SAP 已关闭订单先取到本地临时表。 8. 新增菜单脚本 `db_backups/add_product_pass_rate_workstation_menu_20260630.sql`，写入生产管理下 `产品合格率(工位)` 菜单。 9. 新增前端页面 `src/views/ProductionManagement/ProductPassRateWorkstation/index.vue`，实现查询区、主表、展开二级明细和合格率颜色。 10. 发布查询过程和菜单脚本。 11. 验证样例 `@生产订单号=7649` 返回一级汇总和二级明细。 12. 执行 `npm run build`，构建通过。 ### 修改文件 - `src/views/ProductionManagement/ProductPassRateWorkstation/index.vue` - `db_backups/create_product_pass_rate_workstation_20260630.sql` - `db_backups/add_product_pass_rate_workstation_menu_20260630.sql` - `work/ProductionManagement/ProductPassRateWorkstation/README.md` - `work/ProductionManagement/ProductPassRateWorkstation/01-项目功能内容.md` - `work/ProductionManagement/ProductPassRateWorkstation/02-项目程序开发详细步骤.md` - `work/ProductionManagement/ProductPassRateWorkstation/03-推进台账.md` - `work/ProductionManagement/ProductPassRateWorkstation/04-任务矩阵.md` - `work/ProductionManagement/ProductPassRateWorkstation/05-验收证据.md` - `work/ProductionManagement/ProductPassRateWorkstation/06-决策记录.md` - `gptlog-process/gpdlog.md` ### 验证结果 - 查询过程 `dbo.生产管理_产品合格率工位_查询` 发布成功，修改时间 `2026-06-30 14:31:00.690`。 - 菜单写入 `12` 条角色记录，ID 范围 `236-247`。 - 近 7 天查询返回 `175` 行，耗时约 `0.37` 秒。 - 空条件查询自动限定近 30 天，返回 `1420` 行，耗时约 `1.17` 秒。 - `npm run build` 通过，仅有项目既有 warning。 ## 2026-06-30 产品合格率(工位)默认不查询和合格状态筛选 ### 用户反馈 - 默认进来不查询数据。 - 增加合格和不合格筛选。 - 主数据合格率小于 `100` 的为不合格。 - 默认不合格。 ### 执行过程 1. 修改 `db_backups/create_product_pass_rate_workstation_20260630.sql`，新增 `@合格状态` 参数。 2. 查询结果按主数据合格率过滤：`合格` 为大于等于 `100`，`不合格` 为小于 `100`，`全部` 不过滤。 3. 修改 `src/views/ProductionManagement/ProductPassRateWorkstation/index.vue`，删除页面创建时自动查询。 4. 查询区新增“合格状态”下拉，默认值为 `不合格`。 5. 查询时向过程传入 `合格状态`。 6. 发布查询过程成功。 7. 验证近 30 天筛选结果：不合格 `50` 行，合格 `1370` 行，全部 `1420` 行。 8. 执行 `npm run build`，构建通过。 ### 修改文件 - `src/views/ProductionManagement/ProductPassRateWorkstation/index.vue` - `db_backups/create_product_pass_rate_workstation_20260630.sql` - `work/ProductionManagement/ProductPassRateWorkstation/README.md` - `work/ProductionManagement/ProductPassRateWorkstation/01-项目功能内容.md` - `work/ProductionManagement/ProductPassRateWorkstation/02-项目程序开发详细步骤.md` - `work/ProductionManagement/ProductPassRateWorkstation/03-推进台账.md` - `work/ProductionManagement/ProductPassRateWorkstation/04-任务矩阵.md` - `work/ProductionManagement/ProductPassRateWorkstation/05-验收证据.md` - `work/ProductionManagement/ProductPassRateWorkstation/06-决策记录.md` - `gptlog-process/gpdlog.md` ### 验证结果 - 页面进入不再自动查询。 - 合格状态默认 `不合格`。 - 不合格筛选最高合格率为 `99.99`，符合小于 `100` 的判定。 - `npm run build` 通过，仅有项目既有 warning。 ## 2026-06-30 产品合格率(工位)关闭日期拆分 ### 用户反馈 - 关闭日期筛选拆成两个筛选。 - 客户不习惯一次选两个日期。 ### 执行过程 1. 修改 `src/views/ProductionManagement/ProductPassRateWorkstation/index.vue`。 2. 将原 `daterange` 日期范围选择器拆成两个独立 `date` 日期选择器。 3. 前端字段改为 `searchForm.closeDateStart` 和 `searchForm.closeDateEnd`。 4. 查询参数仍然使用 `关闭日期_Start` 和 `关闭日期_End`，数据库过程无需修改。 5. 执行 `npm run build`，构建通过。 6. 更新产品合格率 README/01-05 文档和总日志。 ### 修改文件 - `src/views/ProductionManagement/ProductPassRateWorkstation/index.vue` - `work/ProductionManagement/ProductPassRateWorkstation/01-项目功能内容.md` - `work/ProductionManagement/ProductPassRateWorkstation/02-项目程序开发详细步骤.md` - `work/ProductionManagement/ProductPassRateWorkstation/03-推进台账.md` - `work/ProductionManagement/ProductPassRateWorkstation/04-任务矩阵.md` - `work/ProductionManagement/ProductPassRateWorkstation/05-验收证据.md` - `gptlog-process/gpdlog.md` ### 验证结果 - `npm run build` 通过，仅有项目既有 warning。 - 数据库过程无需重新发布。 ## 2026-06-30 产品合格率(工位)修正工序号来源 ### 用户反馈 - 工序号为什么都是空。 - 工序号应取 `dbo.MES_接口_生产计划_生产任务.订单行号`。 - 该表中订单行号肯定不会为空。 ### 执行过程 1. 查询 `dbo.MES_接口_生产计划_生产任务` 字段，确认存在 `AID`、`订单编号`、`订单行号`、`工序名称`、`指派对象`。 2. 查询样例数据，确认 `订单行号` 在生产任务表中有值。 3. 定位原脚本中工序号来源为 `COALESCE(View_生产订单_MES.订单行号, 质检记录.行号)`。 4. 确认质检记录的 `TaskAID` 对应生产任务表的 `AID`。 5. 修改 `db_backups/create_product_pass_rate_workstation_20260630.sql`： - 明细关联表改为 `dbo.MES_接口_生产计划_生产任务`。 - 关联条件改为 `q.TaskAID = t.AID`。 - 工序号改为 `COALESCE(t.订单行号, q.行号)`。 - 工序和工位补值也改为优先使用生产任务表的 `工序名称`、`指派对象`。 6. 发布 `dbo.生产管理_产品合格率工位_查询` 成功。 7. 验证 `7649` 二级明细工序号为 `1`、`2`、`3`。 8. 验证近 30 天 `3281` 条二级明细中空工序号为 `0`。 ### 修改文件 - `db_backups/create_product_pass_rate_workstation_20260630.sql` - `work/ProductionManagement/ProductPassRateWorkstation/01-项目功能内容.md` - `work/ProductionManagement/ProductPassRateWorkstation/02-项目程序开发详细步骤.md` - `work/ProductionManagement/ProductPassRateWorkstation/03-推进台账.md` - `work/ProductionManagement/ProductPassRateWorkstation/04-任务矩阵.md` - `work/ProductionManagement/ProductPassRateWorkstation/05-验收证据.md` - `work/ProductionManagement/ProductPassRateWorkstation/06-决策记录.md` - `gptlog-process/gpdlog.md` ### 验证结果 - 查询过程修改时间：`2026-06-30 15:12:24.840`。 - `7649` 返回：领料 1、数车 2、打磨 3。 - 近 30 天明细行数 `3281`，空工序号行数 `0`。 ## 2026-06-30 AGV执行中任务改为已完成 ### 用户反馈 - 处理页面 `ProductionManagement/AGVtask/index` 里面任务状态为执行中的数据。 - 所有执行中任务都改为已完成。 ### 执行过程 1. 读取页面 `src/views/ProductionManagement/AGVtask/index.vue`，确认页面中 `RUNNING` 显示为执行中，`FINISHED` 显示为已完成。 2. 查询数据库对象，确认实时数据来自 `dbo.AGV_实时数据`，历史完成数据写入 `dbo.AGV_历史数据`。 3. 处理前统计实时表状态：`PENDING 1`、`RUNNING 35`。 4. 按完成任务口径处理 `RUNNING` 数据：插入历史表时 `TaskStatus` 写为 `FINISHED`，并设置 `EndTime`、`Duration`，随后从实时表删除这些执行中任务。 5. 处理完成后，调用页面实时查询过程验证 `RUNNING` 无数据。 6. 验证实时表仅剩 `PENDING 1`，最近 5 分钟历史表新增 `FINISHED 35`。 7. 新增 AGVtask README 和 01-06 文档，记录功能内容、执行步骤、推进台账、任务矩阵、验收证据和决策记录。 ### 修改文件 - `work/ProductionManagement/AGVtask/README.md` - `work/ProductionManagement/AGVtask/01-项目功能内容.md` - `work/ProductionManagement/AGVtask/02-项目程序开发详细步骤.md` - `work/ProductionManagement/AGVtask/03-推进台账.md` - `work/ProductionManagement/AGVtask/04-任务矩阵.md` - `work/ProductionManagement/AGVtask/05-验收证据.md` - `work/ProductionManagement/AGVtask/06-决策记录.md` - `gptlog-process/gpdlog.md` ### 验证结果 - 已转历史数量：`35`。 - 页面实时查询过程按 `RUNNING` 查询返回空结果。 - 实时表剩余状态：`PENDING 1`。 - 历史表最近 5 分钟状态：`FINISHED 35`。 ## 2026-06-30 设计报工任务模块方案文档修订 ### 用户反馈 - 读取 `doc/设计报工任务模块.docx`，梳理方案。 - 项目号具体取哪个 SAP 视图字段后续提供。 - 完成要求已有结束时间，未结束不能完成。 - 删除任务时，如果已经有报工记录，不能删除。 - 不参与之前任何生产/SAP/工时报表流程，整体独立。 - 修改文档。 ### 执行过程 1. 解析 `doc/设计报工任务模块.docx` 正文，确认原始需求包含设计任务、设计报工、设计工时校验、设计工时报表四个页面。 2. 对照参考页面： - `ProcessManagement/PartDrawlook/index.vue` - `PlanManagement/SelfMakePlando/index.vue` - `ProductionManagement/WorkHoursCheck/index.vue` - `ProductionManagement/Workhours/index.vue` 3. 新增 `work/ProductionManagement/DesignReportTask/` 文档目录。 4. 写入 README 和 01-06 文档，记录功能内容、开发步骤、推进台账、任务矩阵、验收证据和决策记录。 5. 将 Word 文档正文整理为确认版方案。 6. 解析更新后的 Word 文档，验证关键口径已写入。 ### 修改文件 - `doc/设计报工任务模块.docx` - `work/ProductionManagement/DesignReportTask/README.md` - `work/ProductionManagement/DesignReportTask/01-项目功能内容.md` - `work/ProductionManagement/DesignReportTask/02-项目程序开发详细步骤.md` - `work/ProductionManagement/DesignReportTask/03-推进台账.md` - `work/ProductionManagement/DesignReportTask/04-任务矩阵.md` - `work/ProductionManagement/DesignReportTask/05-验收证据.md` - `work/ProductionManagement/DesignReportTask/06-决策记录.md` - `gptlog-process/gpdlog.md` ### 验证结果 - Word 文档已包含 `项目号：具体 SAP 视图和字段后续提供`。 - Word 文档已包含 `未结束不能完成`。 - Word 文档已包含 `已有设计报工记录不能删除`。 - Word 文档已包含 `不上传 SAP` 和 `不参与现有生产工时报表`。 - 任务矩阵中 `DRT-009 项目号来源` 状态为待确认，`DRT-010 数据库和页面开发` 状态为待开始。 ## 2026-06-30 设计报工任务模块文档归档与菜单权限口径补充 ### 用户反馈 - 根据修改后的文档，将文档复制到对应路径。 - 在对应路径下新增或修改 README、01-06 文档。 - 将完整执行过程追加到 `/gptlog-process/gpdlog.md`。 - 不分配菜单权限。 ### 执行过程 1. 确认修改后的源文档为 `doc/设计报工任务模块.docx`。 2. 确认对应路径为 `work/ProductionManagement/DesignReportTask/`。 3. 将源 Word 文档复制到 `work/ProductionManagement/DesignReportTask/设计报工任务模块.docx`。 4. 更新 README 索引，增加复制后的 Word 文档说明，并写入“不分配菜单权限”。 5. 更新 `01-项目功能内容.md`，补充独立性要求和文档归档路径。 6. 更新 `02-项目程序开发详细步骤.md`，删除菜单权限分配动作，明确不写菜单表和角色权限表。 7. 更新 `03-推进台账.md`，记录本轮做了什么、改了哪些文件、验证了什么、下一步是什么。 8. 更新 `04-任务矩阵.md`，新增文档复制和菜单权限口径任务，并将开发验收标准调整为“不分配菜单权限”。 9. 更新 `05-验收证据.md`，记录工作目录归档路径和菜单权限口径。 10. 更新 `06-决策记录.md`，新增 DDR-006：本阶段不分配菜单权限。 11. 追加仓库内总日志和绝对路径总日志。 ### 修改文件 - `work/ProductionManagement/DesignReportTask/设计报工任务模块.docx` - `work/ProductionManagement/DesignReportTask/README.md` - `work/ProductionManagement/DesignReportTask/01-项目功能内容.md` - `work/ProductionManagement/DesignReportTask/02-项目程序开发详细步骤.md` - `work/ProductionManagement/DesignReportTask/03-推进台账.md` - `work/ProductionManagement/DesignReportTask/04-任务矩阵.md` - `work/ProductionManagement/DesignReportTask/05-验收证据.md` - `work/ProductionManagement/DesignReportTask/06-决策记录.md` - `gptlog-process/gpdlog.md` ### 验证结果 - `work/ProductionManagement/DesignReportTask/设计报工任务模块.docx` 已存在。 - README 已列出复制后的 Word 文档。 - `02-项目程序开发详细步骤.md` 已明确本阶段不分配菜单权限。 - `04-任务矩阵.md` 已新增 `DRT-011` 和 `DRT-012`。 - `06-决策记录.md` 已新增 `DDR-006 本阶段不分配菜单权限`。 ## 2026-06-30 新建设计报工模块页面、数据表和功能 ### 用户反馈 - 新建文档里面的页面、数据表、功能。 - 继续遵守“不分配菜单权限”的要求。 ### 执行过程 1. 读取 `work/ProductionManagement/DesignReportTask/01-项目功能内容.md`，确认需要落地 4 个页面、3 张独立表和独立设计报工功能。 2. 读取现有页面和通用数据库调用方式，确认页面使用 `CreateData` / `ExecDatabase` 调用存储过程。 3. 查询数据库中现有物料查询和人员查询返回字段： - 物料字段包含 `物料编码`、`物料名称`、`物料描述`。 - 人员字段包含 `人员编号`、`人员姓名`、`账号`、`角色`。 4. 新增数据库脚本 `db_backups/create_design_report_task_module_20260630.sql`。 5. 第一次发布脚本时，SAP 物料字段存在 `ntext` 与 `nvarchar` 比较问题，修正为显式 `CAST` 后重新发布。 6. 成功发布 3 张独立表： - `dbo.MES_设计报工_任务` - `dbo.MES_设计报工_记录` - `dbo.MES_设计报工_校验记录` 7. 成功发布 15 个独立过程： - `设计报工_物料查询` - `设计报工_人员查询` - `设计报工_项目查询` - `设计报工_任务_查询` - `设计报工_任务_新增` - `设计报工_任务_编辑` - `设计报工_任务_删除` - `设计报工_任务_开始` - `设计报工_任务_结束` - `设计报工_任务_完成` - `设计报工_记录_查询` - `设计报工_工时校验_查询` - `设计报工_工时校验_保存` - `设计报工_工时校验_批量保存` - `设计报工_工时报表_作业者工时_查询` 8. 事务内验证业务规则： - 新增测试任务成功。 - 未开始直接完成返回“任务未产生已结束报工，不能完成”。 - 开始任务成功。 - 开始后未结束直接完成返回“任务存在未结束报工，不能完成”。 - 结束任务成功。 - 结束后完成成功。 - 事务回滚，测试数据未保留。 9. 新增 4 个前端页面： - `src/views/ProductionManagement/DesignReportTask/Task/index.vue` - `src/views/ProductionManagement/DesignReportTask/Report/index.vue` - `src/views/ProductionManagement/DesignReportTask/Check/index.vue` - `src/views/ProductionManagement/DesignReportTask/HoursReport/index.vue` 10. 执行 `npm run build`，构建通过，仅有项目既有 asset size、entrypoint size、browserslist warning。 11. 更新 `work/ProductionManagement/DesignReportTask/` 下 README 和 01-06 文档。 12. 本轮未新增菜单权限脚本，未写入菜单表和角色权限表。 ### 修改文件 - `db_backups/create_design_report_task_module_20260630.sql` - `src/views/ProductionManagement/DesignReportTask/Task/index.vue` - `src/views/ProductionManagement/DesignReportTask/Report/index.vue` - `src/views/ProductionManagement/DesignReportTask/Check/index.vue` - `src/views/ProductionManagement/DesignReportTask/HoursReport/index.vue` - `work/ProductionManagement/DesignReportTask/README.md` - `work/ProductionManagement/DesignReportTask/01-项目功能内容.md` - `work/ProductionManagement/DesignReportTask/02-项目程序开发详细步骤.md` - `work/ProductionManagement/DesignReportTask/03-推进台账.md` - `work/ProductionManagement/DesignReportTask/04-任务矩阵.md` - `work/ProductionManagement/DesignReportTask/05-验收证据.md` - `work/ProductionManagement/DesignReportTask/06-决策记录.md` - `gptlog-process/gpdlog.md` ### 验证结果 - 数据库脚本发布成功。 - 表和过程对象存在，过程修改时间为 `2026-06-30 18:01:39` 至 `2026-06-30 18:01:40`。 - 下拉验证：`设计报工_物料查询 @过滤=N'5960'` 可返回物料，`设计报工_人员查询 @过滤=N'孙'` 可返回人员。 - 业务规则事务验证通过，测试数据已回滚。 - `npm run build` 通过，仅有项目既有 warning。 - 未分配菜单权限。 ## 2026-07-09 DesignReportTask 菜单权限、物料下拉和表单规则调整 ### 用户反馈 1. 给 `DesignReportTask` 下的四个页面增加权限，账号代码为 `1`；数据库为 `192.168.2.92 / YL_MESDB`，目标表为 `[dbo].[登录基础数据_二级菜单]`。 2. 修改 `src/views/ProductionManagement/DesignReportTask/Task/index.vue`：新建设计任务弹框中，物料编码和父件物料编码没有默认选项，必须输入后触发才有选项。 3. 检查 `DesignReportTask` 下四个页面是否都有物料编码、父件物料编码默认选项问题，并统一修改。 4. 新建设计任务去掉指派对象必填项；物料名称和父件物料名称由选择编码后带出，禁止手工修改；检查四个页面是否都有此问题并处理。 5. 后续每次 GPT/Codex 执行完毕后，必须把中文执行日志追加到 `gptlog-process/gpdlog.md`，日志包含提问、结论和完整执行过程。 ### 执行过程 1. 使用 `rg` 搜索 `DesignReportTask`、菜单表和相关路由配置，确认四个页面路径： - `src/views/ProductionManagement/DesignReportTask/Task/index.vue` - `src/views/ProductionManagement/DesignReportTask/Report/index.vue` - `src/views/ProductionManagement/DesignReportTask/Check/index.vue` - `src/views/ProductionManagement/DesignReportTask/HoursReport/index.vue` 2. 读取 `src/router/getRouter.js` 和 `src/router/menuComponentModule.js`，确认系统从菜单表动态生成路由，菜单行里的 `path`、`componet`、`name` 必须和页面组件对应。 3. 读取既有菜单脚本，包括： - `db_backups/add_formality_confirm_report_menu_20260626.sql` - `db_backups/add_product_pass_rate_workstation_menu_20260630.sql` - `db_backups/add_timely_kit_tracking_result_menu_20260629.sql` 4. 使用用户提供的数据库连接信息连接 `192.168.2.92 / YL_MESDB`。为避免凭据落盘，日志不记录数据库密码明文。 5. 查询 `[dbo].[登录基础数据_二级菜单]` 表结构，确认： - `IDD` 是自增主键。 - `id` 是前端菜单树使用的手工编号。 - `pid` 是父菜单编号。 - `componet` 为现有字段名，系统按该字段加载组件。 6. 查询账号代码 `1` 的菜单记录，确认“生产管理”父菜单为 `id=3`。 7. 查询账号代码 `1` 下是否已存在 `DesignReportTask` 相关菜单，确认执行前不存在 `设计任务`、`设计报工`、`设计工时校验`、`设计工时报表` 四条菜单。 8. 新增可重复执行脚本： - `db_backups/add_design_report_task_menu_account1_20260709.sql` 9. 菜单脚本逻辑： - 固定只处理账号代码 `1`。 - 查找账号 `1` 的“生产管理”父菜单。 - 不存在时插入四条菜单。 - 已存在时修正 `pid`、`path`、`componet`、`name`、`title`、`icon`、`模块代码` 和 `是否启用`。 10. 执行菜单脚本，成功新增四条菜单： - `id=248`，`pid=3`，`设计任务`，`DesignReportTask/Task/index`，`/ProductionManagement/DesignReportTask/Task/index` - `id=249`，`pid=3`，`设计报工`，`DesignReportTask/Report/index`，`/ProductionManagement/DesignReportTask/Report/index` - `id=250`，`pid=3`，`设计工时校验`，`DesignReportTask/Check/index`，`/ProductionManagement/DesignReportTask/Check/index` - `id=251`，`pid=3`，`设计工时报表`，`DesignReportTask/HoursReport/index`，`/ProductionManagement/DesignReportTask/HoursReport/index` 11. 回读菜单表，确认四条菜单各只有一条记录，`pid` 都为 `3`，`是否启用` 都为 `1`，`模块代码` 等于各自 `id`。 12. 使用 `Test-Path` 校验四个前端组件文件均存在。 13. 读取 `Task/index.vue`，确认新建设计任务弹框中： - `物料编码` 使用 `queryMaterialOptions` 远程查询。 - `父件物料编码` 使用 `queryParentMaterialOptions` 远程查询。 - 原逻辑只在输入关键字触发 `remote-method` 后才请求物料数据。 14. 在 `Task/index.vue` 中新增 `loadDefaultMaterialOptions()` 方法，内部调用： - `queryMaterialOptions('')` - `queryParentMaterialOptions('')` 15. 在 `Task/index.vue` 的 `created()`、`openAdd()`、`openEdit()` 中调用 `loadDefaultMaterialOptions()`，保证页面查询区、新建弹框和编辑弹框打开时都有默认物料列表。 16. 执行 `npm run build` 验证，构建通过，仅有项目既有 asset size、entrypoint size、browserslist warning。 17. 继续检查 `DesignReportTask` 下四个页面： - `Task` 页面存在物料编码和父件物料编码远程下拉。 - `Report` 页面原本查询区的物料编码和父件编码是普通输入框。 - `Check` 页面原本查询区的物料编码是普通输入框。 - `HoursReport` 页面原本查询区的物料编码是普通输入框。 18. 修改 `Report/index.vue`： - 将查询区“物料编码”从输入框改为远程下拉。 - 将查询区“父件编码”从输入框改为远程下拉。 - 增加 `materialOptions`、`parentMaterialOptions`。 - 增加 `loadDefaultMaterialOptions()`、`queryMaterialOptions()`、`queryParentMaterialOptions()` 和 `formatMaterialLabel()`。 - 在 `created()` 中预加载默认物料和父件物料列表。 19. 修改 `Check/index.vue`： - 将查询区“物料编码”从输入框改为远程下拉。 - 增加 `materialOptions`。 - 增加 `loadDefaultMaterialOptions()`、`queryMaterialOptions()` 和 `formatMaterialLabel()`。 - 在 `created()` 中预加载默认物料列表。 20. 修改 `HoursReport/index.vue`： - 将查询区“物料编码”从输入框改为远程下拉。 - 增加 `materialOptions`。 - 增加 `loadDefaultMaterialOptions()`、`queryMaterialOptions()` 和 `formatMaterialLabel()`。 - 在 `created()` 中预加载默认物料列表。 21. 执行 `npm run build` 验证四个页面物料下拉改动，构建通过，仅有项目既有 warning。 22. 检查四个页面是否存在“指派对象必填”和“物料名称、父件物料名称可编辑”的问题： - `Task/index.vue` 有新建/编辑设计任务弹框，存在 `指派对象` 的 `assigneeIds` 必填校验，也存在可编辑的 `物料名称` 和 `父件物料名称` 输入框。 - `Report/index.vue`、`Check/index.vue`、`HoursReport/index.vue` 没有新建设计任务弹框，也没有可编辑的 `物料名称` 或 `父件物料名称` 表单项，只有查询条件和表格展示。 23. 检查数据库脚本 `db_backups/create_design_report_task_module_20260630.sql`，确认 `设计报工_任务_新增` 和 `设计报工_任务_编辑` 的 `@指派对象ID`、`@指派对象` 参数允许为空，后端无需修改。 24. 修改 `Task/index.vue`： - 删除 `rules.assigneeIds` 必填校验。 - 保留 `formData.assigneeIds` 数组字段和 `handleAssigneeChange()`，支持用户选择指派对象但不强制要求。 - 给 `formData.物料名称` 输入框增加 `disabled`。 - 给 `formData.关联父件物料名称` 输入框增加 `disabled`。 25. 使用固定字符串搜索确认： - `请选择指派对象` 必填提示已不存在。 - `assigneeIds` 只剩表单数据字段和选择逻辑，不再作为必填规则。 - `Task/index.vue` 中 `物料名称` 和 `父件物料名称` 表单输入框均已禁用。 - 其它三个页面仅有表格展示的 `物料名称`，没有对应可编辑输入框。 26. 执行 `npm run build` 验证表单规则和禁用输入框改动，构建通过，仅有项目既有 warning。 27. 查看 `git status --short`，确认当前工作区还存在用户或既有修改： - `doc/设计报工任务模块.docx` - `src/views/PlanManagement/SelfMakePlando/index.vue` - `doc/~$报工任务模块.docx` - 本轮相关的 `DesignReportTask` 页面改动和菜单脚本。 28. 按用户要求补录本次会话日志到 `gptlog-process/gpdlog.md`，并确认后续执行完毕后继续追加中文日志。 ### 修改文件 - `db_backups/add_design_report_task_menu_account1_20260709.sql` - `src/views/ProductionManagement/DesignReportTask/Task/index.vue` - `src/views/ProductionManagement/DesignReportTask/Report/index.vue` - `src/views/ProductionManagement/DesignReportTask/Check/index.vue` - `src/views/ProductionManagement/DesignReportTask/HoursReport/index.vue` - `gptlog-process/gpdlog.md` ### 结论 - 账号代码 `1` 已获得 `DesignReportTask` 下四个页面菜单权限，四条菜单均挂到“生产管理”下并启用。 - `Task` 页面新建/编辑设计任务弹框打开时，物料编码和父件物料编码已有默认选项。 - `Task`、`Report`、`Check`、`HoursReport` 四个页面涉及物料查询的下拉均已支持默认选项。 - 新建设计任务的“指派对象”不再必填。 - 新建设计任务的“物料名称”和“父件物料名称”只能由选择编码后带出，前端禁止手工修改。 - `Report`、`Check`、`HoursReport` 页面不存在新建设计任务弹框，也不存在可编辑的物料名称或父件物料名称输入框，无需做同类表单禁用修改。 - 多次执行 `npm run build` 均通过，仅有项目既有资源体积和 browserslist 过期 warning。 - 已建立后续日志规则：每次 GPT/Codex 执行完毕后，将中文执行日志追加到 `gptlog-process/gpdlog.md`。 ### 验证结果 - 菜单表回读结果确认 `设计任务`、`设计报工`、`设计工时校验`、`设计工时报表` 各 1 条，账号代码均为 `1`，`pid=3`，`是否启用=1`。 - 四个前端组件文件均存在。 - 搜索确认 `请选择指派对象` 必填提示已删除。 - 搜索确认 `物料名称` 和 `父件物料名称` 的可编辑表单问题只存在于 `Task/index.vue`，且已加 `disabled`。 - `npm run build` 通过。 ## 2026-07-09 补录 2026-07-01 至 2026-07-08 项目修改日志 ### 用户反馈 - 用户要求把 7 月 1、2、3 日的修改，以及 7 月 6、7、8 日本项目的修改追加到 `gptlog-process/gpdlog.md`。 - 要求遵守既定日志规则：每次 GPT/Codex 执行完毕后，将中文执行过程日志追加到 `gptlog-process/gpdlog.md`，内容包含提问、结论和完整执行过程。 ### 执行过程 1. 读取 `gptlog-process/gpdlog.md` 末尾，确认当前日志已包含 2026-06-30 设计报工模块日志和 2026-07-09 DesignReportTask 权限、下拉、表单规则调整日志。 2. 使用 `rg` 搜索 `2026-07`、`七月`、`7月`、`07-0` 等关键词，确认现有总日志中没有按 2026-07-01 至 2026-07-08 单独补录的完整章节。 3. 使用 `git log --since "2026-07-01" --until "2026-07-09"` 查询 Git 历史，确认可追溯提交主要为： - `c4a2f6e`，2026-07-07 17:30:12，`feat: update production reporting workflows`。 - `6d93e40`，2026-07-08 10:38:56，`feat: 增加结算工时和历史工时选择`。 - `bd9ca09`，2026-07-08 16:52:29，`feat: 增加设备数据导出`。 4. 使用 PowerShell 按 `LastWriteTime` 查询 2026-07-01 至 2026-07-08 的项目文件修改时间，排除 `.git`、`node_modules`、`dist` 等目录。 5. 文件时间显示的关键记录： - 2026-07-02：`src/views/PlanManagement/TimelyKitTrackingResult/index.vue`。 - 2026-07-03：`AGENTS.md`。 - 2026-07-06：`src/views/ProductionManagement/OutsourceMange/index.vue`。 - 2026-07-07：`src/views/QualityManagement/CheckTask/processReceive.vue`、`src/views/ProductionManagement/SettlementWorkhours/index.vue`、多个 20260707 SQL 脚本、`src/views/ProductionManagement/ProductPassRateWorkstation/index.vue`。 - 2026-07-08：`src/views/PlanManagement/SelfMakePlandone/index.vue`、`src/views/PlanManagement/WorkstationPlan/index.vue`、`src/views/DeviceManagement/Devicedata/index.vue`、`src/views/DeviceManagement/DeviceDataHistory/index.vue`、`doc/设计报工任务模块.docx`、`dist.zip`。 6. 查询 2026-07-01 至 2026-07-04 的 Git 提交记录，未发现该日期范围内的 Git 提交。 7. 读取 `AGENTS.md`，确认其内容为日志记录规则：每次 GPT/Codex 执行完毕后，将中文完整执行过程日志追加到 `gptlog-process/gpdlog.md`。 8. 读取 2026-07-07 提交 `c4a2f6e` 的文件清单和关键 diff，确认该提交覆盖 24 个文件，包含设计报工模块、结算工时、产品合格率、及时齐套跟踪结果、外协管理、质检收检和数据库脚本。 9. 读取 2026-07-08 提交 `6d93e40` 的 diff，确认其重点是排产相关页面增加结算工时和历史工时选择。 10. 读取 2026-07-08 提交 `bd9ca09` 的 diff，确认其重点是设备实时数据和设备历史数据增加导出 Excel 功能。 11. 对无 Git 提交但有文件修改时间的 7 月 1、2、3、6 日，按“可追溯证据”记录，不把无法确认的内容写成确定提交。 12. 将本次补录内容追加到 `gptlog-process/gpdlog.md`。 ### 2026-07-01 修改补录 - 通过 Git 历史和文件修改时间检查，未发现 2026-07-01 当天有可追溯的项目代码或文档修改记录。 - 现有日志中出现的 `2026-07-01` 主要是设备信息维护日期字段的测试数据，例如入账日期测试值，不代表 2026-07-01 当天发生了项目文件修改。 ### 2026-07-02 修改补录 - 文件修改时间显示 `src/views/PlanManagement/TimelyKitTrackingResult/index.vue` 在 2026-07-02 11:50:48 修改。 - 后续该变更随 2026-07-07 提交 `c4a2f6e` 入库。 - 主要修改内容： 1. 调整 `getRouteProcessName(process)`。 2. 从 `process.工序名称` 和 `process.指派对象` 组合显示工序路线名称。 3. 如果工序名称中已经包含半角或全角括号形式的指派对象，则不重复追加。 4. 如果存在指派对象且工序名称未包含该指派对象，则显示为 `工序名称(指派对象)`。 - 结论：及时齐套跟踪结果页面的路线工序显示更明确，能在工序名称旁体现指派对象。 ### 2026-07-03 修改补录 - 文件修改时间显示仓库根目录新增或修改 `AGENTS.md`，时间为 2026-07-03 09:52:09。 - 当前 `AGENTS.md` 内容为本项目日志记录规则： 1. 每次 GPT/Codex 执行完毕后，须将完整执行过程日志追加到 `gptlog-process/gpdlog.md`。 2. 日志包含提问、结论和完整执行过程。 3. 写入日志必须使用中文。 - 当前 `git status` 显示 `AGENTS.md` 仍为未跟踪文件。 - 结论：7 月 3 日主要是建立项目级日志记录约束文件。 ### 2026-07-06 修改补录 - 文件修改时间显示 `src/views/ProductionManagement/OutsourceMange/index.vue` 在 2026-07-06 13:36:58 修改。 - 后续该变更随 2026-07-07 提交 `c4a2f6e` 入库。 - 主要修改内容： 1. 外协管理操作列中，“发料”按钮增加 `v-if="scope.row.单据状态 != '已取消'"`。 2. 外协管理操作列中，“收料”按钮增加 `v-if="scope.row.单据状态 != '已取消'"`。 - 结论：已取消单据不再展示发料、收料操作，避免对取消状态单据继续执行业务操作。 ### 2026-07-07 修改补录 - Git 提交：`c4a2f6e`。 - 提交时间：2026-07-07 17:30:12。 - 提交说明：`feat: update production reporting workflows`。 - 提交规模：24 个文件，约 3713 行新增、35 行删除。 #### 数据库脚本 1. `db_backups/create_design_report_task_module_20260630.sql` - 新增独立设计报工模块数据库脚本。 - 创建 `MES_设计报工_任务`、`MES_设计报工_记录`、`MES_设计报工_校验记录`。 - 创建设计报工物料、人员、项目、任务、开始、结束、完成、删除、工时校验、工时报表等过程。 - 脚本说明中明确：不写入现有生产报工表、不上传 SAP、不新增菜单权限。 2. `db_backups/exclude_unfinished_assembly_orders_from_close_query_20260707.sql` - 修改 `计划排产_生产订单关闭_查询全部订单`。 - 在“可关闭”逻辑中识别未结束装配订单。 - 对存在装配开始但未结束记录的订单进行排除，避免未结束装配订单被误判为可关闭。 3. `db_backups/optimize_settlement_workhours_query_20260707.sql` - 优化 `生产管理_结算工时_查询`。 - 增加合同号、产品编码、订单号、工位、开始日期、结束日期、数据条数等筛选参数。 - 使用临时表组织任务、基础工时数据和汇总结果，提高查询结构清晰度。 4. `db_backups/fix_settlement_workhours_query_restore_workhour_rows_20260707.sql` - 修复结算工时查询，恢复从 `View_生产工时视图` 关联回来的工时报工行。 - 使用 `TaskAID`、开始时间等关键字段组织报工明细和操作人拼接。 - 继续保留结算工时汇总需要的报工工时、辅助工时、完成数、单件工时等字段。 #### 前端页面 1. `src/views/PlanManagement/SelfMakePlando/index.vue` - 增加“历史工时”入口。 - 新增历史工时弹框。 - 通过 `生产管理_结算工时_查询` 按产品编码查询历史工时。 - 展示任务描述、生产订单号、工位、报工工时、辅助工时、完成数、结算报工单件工时、结算辅助单件工时、操作人等字段。 2. `src/views/PlanManagement/SelfMakePlandone/index.vue` - 增加与 `SelfMakePlando` 类似的“历史工时”入口和弹框。 - 通过产品编码查询历史结算工时数据并展示。 3. `src/views/PlanManagement/TimelyKitTrackingResult/index.vue` - 路线工序名称增加指派对象显示，避免只看工序名无法区分指派对象。 4. `src/views/ProductionManagement/OutsourceMange/index.vue` - 已取消单据隐藏“发料”和“收料”按钮。 5. `src/views/ProductionManagement/ProductPassRateWorkstation/index.vue` - 新增导出按钮。 - 引入 `xlsx`。 - 支持把主表和明细导出为 Excel。 - 导出字段包含关闭日期、生产订单号、物料、计划数量、完成数量、不良数量、合格率、工序、工位、检验说明等。 6. `src/views/ProductionManagement/SettlementWorkhours/index.vue` - 新增导出按钮。 - 引入 `xlsx`。 - 导出结算工时树表数据，并在末尾写入报工工时、主辅工时和合计工时汇总。 - 将“主辅工时”列名调整为“辅助工时”。 - 增加展开/收起状态记录，导出时只导出当前展开明细。 7. `src/views/ProductionManagement/DesignReportTask/Task/index.vue` - 新增设计任务页面。 - 支持设计任务查询、新建、编辑、删除。 - 支持项目号、物料编码、图号、父件编码、预计时间、状态等查询条件。 8. `src/views/ProductionManagement/DesignReportTask/Report/index.vue` - 新增设计报工页面。 - 支持任务开始、结束、完成。 - 遵守未结束不能完成、已有报工记录不能删除等独立设计报工规则。 9. `src/views/ProductionManagement/DesignReportTask/Check/index.vue` - 新增设计工时校验页面。 - 支持单条校验和批量校验。 10. `src/views/ProductionManagement/DesignReportTask/HoursReport/index.vue` - 新增设计工时报表页面。 - 支持按操作人、日期、任务形成树形工时报表。 11. `src/views/QualityManagement/CheckTask/processReceive.vue` - 质检收检流程中对部分调试输出做调整。 - 对采购订单行匹配条件保留工序名称和未关闭行状态判断。 12. `src/views/ProductionManagement/ProductPassRateWorkstation/index.vue`、`src/views/ProductionManagement/SettlementWorkhours/index.vue` - 两个报表类页面均增加 Excel 导出能力，统一使用 `xlsx`。 #### 工作文档和日志 - 更新 `work/ProductionManagement/DesignReportTask/README.md`。 - 更新 `work/ProductionManagement/DesignReportTask/01-项目功能内容.md` 至 `06-决策记录.md`。 - 复制或更新 `work/ProductionManagement/DesignReportTask/设计报工任务模块.docx`。 - 追加 `gptlog-process/gpdlog.md`。 #### 结论 - 7 月 7 日主要是生产报工、结算工时、设计报工、订单关闭判断、产品合格率导出等生产业务流程集中更新。 - 设计报工模块的表、过程、四个页面和工作文档在该提交中完成入库。 - 结算工时查询和展示能力得到增强，后续 7 月 8 日继续在排产页面使用这些结算工时数据。 ### 2026-07-08 修改补录 #### 提交一：增加结算工时和历史工时选择 - Git 提交：`6d93e40`。 - 提交时间：2026-07-08 10:38:56。 - 提交说明：`feat: 增加结算工时和历史工时选择`。 - 涉及文件： - `src/views/PlanManagement/SelfMakePlando/index.vue` - `src/views/PlanManagement/SelfMakePlandone/index.vue` - `src/views/PlanManagement/WorkstationPlan/index.vue` ##### 主要修改内容 1. `SelfMakePlando/index.vue` - 调整历史工时弹框列顺序。 - 将结算报工单件工时、结算辅助单件工时前置展示。 - 单件工时展示时乘以 60，便于按分钟口径查看。 - 保留生产订单号、工位、操作人、报工工时、辅助工时、完成数等字段。 2. `SelfMakePlandone/index.vue` - 将原“历史工时”按钮列注释掉。 - 保留页面其他业务列。 3. `WorkstationPlan/index.vue` - 工位排产表增加“结算工时”和“结算单件工时”列。 - 工位汇总和日期汇总增加结算工时合计。 - 单任务行增加结算单件工时选择按钮。 - 新增历史工时弹框，按产品编码调用 `生产管理_结算工时_查询`。 - 历史工时弹框中支持选择“报工”或“辅助”的单件工时。 - 选择后调用 `MES_OrderPlanned_EditTaskPlanned` 保存到任务的 `结算单件工时`。 - 增加 `calcStandardHours`、`calcSettlementHours`、`formatHistoryPieceHours`、`canSelectHistoryHour` 等辅助方法。 - 扩展表格最小宽度和列样式，适配新增结算工时列。 ##### 结论 - 7 月 8 日上午主要增强排产侧的结算工时使用能力，支持从历史结算工时中选择单件工时并回写排产任务。 #### 提交二：增加设备数据导出 - Git 提交：`bd9ca09`。 - 提交时间：2026-07-08 16:52:29。 - 提交说明：`feat: 增加设备数据导出`。 - 涉及文件： - `src/views/DeviceManagement/Devicedata/index.vue` - `src/views/DeviceManagement/DeviceDataHistory/index.vue` ##### 主要修改内容 1. `Devicedata/index.vue` - 设备实时数据页面增加“导出”按钮。 - 引入 `xlsx`。 - 增加 `exporting` 状态，导出时按钮 loading。 - 将当前表格数据导出为 Excel。 - 导出字段包含序号、设备名称、参数名称、数值、单位、更新时间。 - 导出文件名格式为 `设备实时数据_yyyyMMdd_HHmmss.xlsx`。 2. `DeviceDataHistory/index.vue` - 设备历史数据页面增加“导出”按钮。 - 抽出 `buildQueryParams(pageSize, pageCurrent)` 复用查询参数构建。 - 普通查询继续按分页查询。 - 导出时使用总条数作为页大小，一次性查询全部历史数据后导出。 - 导出字段包含序号、设备名称、参数名称、数值、采集时间。 - 导出文件名格式为 `设备历史数据_yyyyMMdd_HHmmss.xlsx`。 ##### 结论 - 7 月 8 日下午主要补齐设备实时数据和历史数据的 Excel 导出能力。 #### 其它 2026-07-08 文件时间记录 - `doc/设计报工任务模块.docx` 文件时间显示为 2026-07-08 18:27:31，当前 `git status` 显示该文件仍处于修改状态。 - `dist.zip` 文件时间显示为 2026-07-08 09:10:41，属于构建或发布压缩产物，本次补录仅记录文件时间，不作为源码变更结论。 ### 本次补录修改文件 - `gptlog-process/gpdlog.md` ### 本次补录结论 - 已将 2026-07-01、2026-07-02、2026-07-03、2026-07-06、2026-07-07、2026-07-08 的可追溯项目修改追加到总日志。 - 2026-07-01 未发现可追溯项目文件修改，已在日志中明确说明。 - 2026-07-02、2026-07-03、2026-07-06 根据文件修改时间和后续提交 diff 补录。 - 2026-07-07、2026-07-08 根据 Git 提交记录和文件 diff 补录。 - 本次操作只修改日志文件，没有修改业务代码和数据库。 ### 本次补录验证结果 - `git log` 已确认 2026-07-07 和 2026-07-08 的三个提交。 - `Get-ChildItem` 文件时间检查已确认 2026-07-02、2026-07-03、2026-07-06、2026-07-08 的相关文件。 - `AGENTS.md` 已读取并确认内容为中文日志记录规则。 - `gptlog-process/gpdlog.md` 已追加本节补录内容。 ## 2026-07-09 DesignReportTask 项目号来源修正 ### 用户反馈 - 用户指出项目号来源错了。 - 正确来源应为 `SAP.SBO_YL.dbo.VIEW_OPRJ.项目代码`。 - 要求检查 `DesignReportTask` 下四个页面是否都有这个问题，并全部修改。 ### 执行过程 1. 使用 `rg` 搜索 `DesignReportTask` 下四个页面和数据库脚本中的 `项目号`、`projectNo`、`projectOptions`、`queryProjects`、`设计报工_项目查询`。 2. 确认原始实现问题： - `db_backups/create_design_report_task_module_20260630.sql` 中 `设计报工_项目查询` 原来从 `dbo.MES_设计报工_任务` 的已有项目号取值。 - `Task/index.vue` 已有项目号远程下拉，但来源依赖错误过程，并且新建弹框中允许 `allow-create` 手工创建项目号。 - `Report/index.vue`、`Check/index.vue`、`HoursReport/index.vue` 的项目号查询条件是普通输入框，没有统一使用项目号来源下拉。 3. 连接目标数据库 `192.168.2.92 / YL_MESDB`，检查 `[SAP].[SBO_YL].[dbo].[VIEW_OPRJ]`。 4. 查询确认 SAP 项目视图字段： - `项目代码` - `项目名称` 5. 抽样查询 SAP 项目视图，确认存在 `CW-260001`、`CW260002`、`HT230075-1` 等项目代码。 6. 新增数据库增量脚本： - `db_backups/update_design_report_project_source_20260709.sql` 7. 增量脚本重建 `dbo.设计报工_项目查询`： - 来源改为 `[SAP].[SBO_YL].[dbo].[VIEW_OPRJ]`。 - 返回 `项目号 = 项目代码`。 - 同时返回 `项目名称`。 - 支持按 `项目代码` 或 `项目名称` 模糊过滤。 8. 同步修改 `db_backups/create_design_report_task_module_20260630.sql` 中的 `设计报工_项目查询`，避免以后重跑完整脚本时又恢复为错误来源。 9. 执行 `db_backups/update_design_report_project_source_20260709.sql` 到目标库，执行成功。日志中不记录数据库密码明文。 10. 验证存储过程： - `设计报工_项目查询 @过滤=N''` 可返回 SAP 项目代码和项目名称。 - `设计报工_项目查询 @过滤=N'CW-260001'` 返回 `CW-260001`。 11. 修改 `src/views/ProductionManagement/DesignReportTask/Task/index.vue`： - 查询区项目号下拉显示从 `项目号` 改为 `项目号 | 项目名称`。 - 新建/编辑弹框项目号下拉显示从 `项目号` 改为 `项目号 | 项目名称`。 - 去掉新建/编辑弹框项目号下拉的 `allow-create`，避免手工录入非 SAP 项目代码。 - 打开新建/编辑弹框时重新调用 `queryProjects('')`，保证默认项目列表可用。 - 增加 `formatProjectLabel()`。 12. 修改 `src/views/ProductionManagement/DesignReportTask/Report/index.vue`： - 将查询区项目号从普通输入框改为远程下拉。 - 新增 `projectOptions`、`queryProjects()`、`formatProjectLabel()`。 - 页面创建时预加载 SAP 项目代码列表。 13. 修改 `src/views/ProductionManagement/DesignReportTask/Check/index.vue`： - 将查询区项目号从普通输入框改为远程下拉。 - 新增 `projectOptions`、`queryProjects()`、`formatProjectLabel()`。 - 页面创建时预加载 SAP 项目代码列表。 14. 修改 `src/views/ProductionManagement/DesignReportTask/HoursReport/index.vue`： - 将查询区项目号从普通输入框改为远程下拉。 - 新增 `projectOptions`、`queryProjects()`、`formatProjectLabel()`。 - 页面创建时预加载 SAP 项目代码列表。 15. 使用 `rg` 检查四个页面： - 四个页面均有 `queryProjects()`。 - 四个页面项目号均使用 `设计报工_项目查询`。 - `Task/index.vue` 中不再存在 `allow-create`。 16. 更新工作文档： - `work/ProductionManagement/DesignReportTask/README.md` - `work/ProductionManagement/DesignReportTask/01-项目功能内容.md` - `work/ProductionManagement/DesignReportTask/02-项目程序开发详细步骤.md` - `work/ProductionManagement/DesignReportTask/03-推进台账.md` - `work/ProductionManagement/DesignReportTask/04-任务矩阵.md` - `work/ProductionManagement/DesignReportTask/05-验收证据.md` - `work/ProductionManagement/DesignReportTask/06-决策记录.md` 17. 文档更新内容： - 项目号来源从“待确认”改为 `[SAP].[SBO_YL].[dbo].[VIEW_OPRJ].[项目代码]`。 - 记录 `设计报工_项目查询` 使用 SAP 项目代码。 - 记录四个页面项目号查询条件统一为远程下拉。 - 将任务矩阵 `DRT-009` 改为已完成，并新增 `DRT-020`。 - 将决策记录中“项目号临时实现”标记为已废弃。 18. 执行 `npm run build`，构建通过，仅有项目既有资源体积和 browserslist 过期 warning。 19. 查看 `git status --short`，确认本轮涉及的新增和修改文件，同时发现工作区还有不属于本轮操作的一批 `work/DeviceManagement/DeviceInformation` 删除状态，未做回退。 ### 修改文件 - `db_backups/update_design_report_project_source_20260709.sql` - `db_backups/create_design_report_task_module_20260630.sql` - `src/views/ProductionManagement/DesignReportTask/Task/index.vue` - `src/views/ProductionManagement/DesignReportTask/Report/index.vue` - `src/views/ProductionManagement/DesignReportTask/Check/index.vue` - `src/views/ProductionManagement/DesignReportTask/HoursReport/index.vue` - `work/ProductionManagement/DesignReportTask/README.md` - `work/ProductionManagement/DesignReportTask/01-项目功能内容.md` - `work/ProductionManagement/DesignReportTask/02-项目程序开发详细步骤.md` - `work/ProductionManagement/DesignReportTask/03-推进台账.md` - `work/ProductionManagement/DesignReportTask/04-任务矩阵.md` - `work/ProductionManagement/DesignReportTask/05-验收证据.md` - `work/ProductionManagement/DesignReportTask/06-决策记录.md` - `gptlog-process/gpdlog.md` ### 结论 - 项目号来源已从错误的 `MES_设计报工_任务` 历史数据改为 SAP 项目视图 `[SAP].[SBO_YL].[dbo].[VIEW_OPRJ]` 的 `项目代码`。 - `设计报工_项目查询` 已发布到目标库，并返回 `项目号` 和 `项目名称`。 - `DesignReportTask` 四个页面的项目号查询条件已统一使用 SAP 项目代码远程下拉。 - `Task` 页面新建/编辑项目号不再允许手工创建非 SAP 项目号。 - 工作文档中的项目号“待确认”和“临时实现”口径已更新。 ### 验证结果 - SAP 视图字段验证：存在 `项目代码`、`项目名称`。 - 存储过程验证：`设计报工_项目查询 @过滤=N'CW-260001'` 返回 `CW-260001`。 - 前端代码检查：四个页面均存在 `queryProjects()` 和 `formatProjectLabel()`。 - 前端构建：`npm run build` 通过，仅有项目既有 warning。 ## 2026-07-09 DesignReportTask 项目号远程搜索补强 ### 用户反馈 - 用户反馈：项目号也要像物料编码一样，需要远程搜索。 ### 执行过程 1. 复查 `DesignReportTask` 四个页面中项目号控件配置。 2. 初次使用 `rg` 检查时，PowerShell 对引号和管道符解析导致命令报错，随后改用 `Get-Content` 和 `Select-String` 读取页面内容。 3. 确认当前四个页面已使用 `remote-method="queryProjects"`，但项目号下拉需要进一步补强为和物料编码一致的使用体验： - 页面打开时加载默认项目。 - 用户输入关键字时通过 `queryProjects` 远程查询。 - 清空选择后恢复默认项目列表。 - 打开下拉且本地列表为空时自动加载默认项目列表。 4. 修改 `src/views/ProductionManagement/DesignReportTask/Task/index.vue`： - 设计任务查询区项目号下拉增加 `@clear="loadDefaultProjectOptions"`。 - 新建/编辑弹框项目号下拉增加 `@clear="loadDefaultProjectOptions"`。 - 两个项目号下拉均增加 `@visible-change="handleProjectVisibleChange"`。 - 新增 `loadDefaultProjectOptions()`，内部调用 `queryProjects('')`。 - 新增 `handleProjectVisibleChange(visible)`，下拉打开且 `projectOptions` 为空时加载默认项目列表。 - `created()`、`openAdd()`、`openEdit()` 改为调用 `loadDefaultProjectOptions()`。 5. 修改 `src/views/ProductionManagement/DesignReportTask/Report/index.vue`： - 查询区项目号下拉增加清空后加载默认项目和打开时自动补加载逻辑。 - 新增 `loadDefaultProjectOptions()` 和 `handleProjectVisibleChange()`。 - `created()` 改为调用 `loadDefaultProjectOptions()`。 6. 修改 `src/views/ProductionManagement/DesignReportTask/Check/index.vue`： - 查询区项目号下拉增加清空后加载默认项目和打开时自动补加载逻辑。 - 新增 `loadDefaultProjectOptions()` 和 `handleProjectVisibleChange()`。 - `created()` 改为调用 `loadDefaultProjectOptions()`。 7. 修改 `src/views/ProductionManagement/DesignReportTask/HoursReport/index.vue`： - 查询区项目号下拉增加清空后加载默认项目和打开时自动补加载逻辑。 - 新增 `loadDefaultProjectOptions()` 和 `handleProjectVisibleChange()`。 - `created()` 改为调用 `loadDefaultProjectOptions()`。 8. 使用 `Select-String` 检查四个页面，确认均存在： - `remote-method="queryProjects"` - `@clear="loadDefaultProjectOptions"` - `@visible-change="handleProjectVisibleChange"` - `loadDefaultProjectOptions` - `handleProjectVisibleChange` 9. 第一次执行 `npm run build`，124 秒超时，未返回编译结果。 10. 使用 240 秒超时时间重新执行 `npm run build`，构建通过，仅有项目既有资源体积和 browserslist 过期 warning。 ### 修改文件 - `src/views/ProductionManagement/DesignReportTask/Task/index.vue` - `src/views/ProductionManagement/DesignReportTask/Report/index.vue` - `src/views/ProductionManagement/DesignReportTask/Check/index.vue` - `src/views/ProductionManagement/DesignReportTask/HoursReport/index.vue` - `gptlog-process/gpdlog.md` ### 结论 - `DesignReportTask` 四个页面的项目号均已按物料编码的远程搜索口径补强。 - 项目号现在支持默认列表、输入远程搜索、清空恢复默认列表、打开空列表时自动加载。 - 项目号数据仍来自已修正的 `设计报工_项目查询`，即 SAP 项目视图 `[SAP].[SBO_YL].[dbo].[VIEW_OPRJ].[项目代码]`。 ### 验证结果 - 四个页面均检查到项目号远程搜索相关配置。 - 第二次 `npm run build` 构建通过，仅有项目既有 warning。 ## 2026-07-09 DesignReportTask 操作列按钮横向显示 ### 用户反馈 - 用户反馈：操作列下的功能按钮不要纵向显示，容易误触，改成横向；检查 `DesignReportTask` 下四个页面是不是都有这个问题，并全部修改。 ### 执行过程 1. 检查 `DesignReportTask` 下四个页面： - `Task/index.vue` 存在操作列，按钮为“编辑 / 删除”。 - `Report/index.vue` 存在操作列，按钮为“开始 / 结束 / 完成”。 - `Check/index.vue` 存在操作列，按钮为“校验 / 已校验”。 - `HoursReport/index.vue` 未发现操作列，因此没有纵向按钮问题。 2. 第一次按精确标签搜索操作列未命中，随后改用 `rg` 关键字和 UTF-8 读取方式定位具体模板位置。 3. 修改 `src/views/ProductionManagement/DesignReportTask/Task/index.vue`： - 操作列宽度从 `130` 调整为 `150`。 - 将“编辑 / 删除”按钮包裹到 `design-action-buttons` 容器内。 - 新增横向 `inline-flex` 样式，设置不换行、居中、固定按钮间距。 - 覆盖 Element UI 相邻按钮默认左边距，避免按钮被默认样式挤到纵向排列。 4. 修改 `src/views/ProductionManagement/DesignReportTask/Report/index.vue`： - 操作列宽度从 `180` 调整为 `210`。 - 将“开始 / 结束 / 完成”按钮包裹到 `design-action-buttons` 容器内。 - 新增与 `Task` 页面一致的横向按钮样式。 5. 修改 `src/views/ProductionManagement/DesignReportTask/Check/index.vue`： - 操作列宽度从 `90` 调整为 `100`。 - 将“校验 / 已校验”按钮包裹到 `design-action-buttons` 容器内。 - 新增与其他页面一致的横向按钮样式。 6. 对 `HoursReport/index.vue` 进行检查，确认页面只有报表树形表格和查询条件，没有操作列，未做代码修改。 7. 使用 `rg` 检查三个已修改页面，确认都已存在 `design-action-buttons` 模板和样式。 8. 执行 `npm run build`，构建通过；输出仅包含项目既有资源体积过大、Browserslist / baseline 数据过期 warning。 ### 修改文件 - `src/views/ProductionManagement/DesignReportTask/Task/index.vue` - `src/views/ProductionManagement/DesignReportTask/Report/index.vue` - `src/views/ProductionManagement/DesignReportTask/Check/index.vue` - `gptlog-process/gpdlog.md` ### 结论 - `Task`、`Report`、`Check` 三个有操作列的页面已统一改为横向按钮排列，避免按钮纵向堆叠导致误触。 - `HoursReport` 页面没有操作列，本次无需修改。 ### 验证结果 - 已检查到三个页面均存在 `design-action-buttons` 横向按钮容器。 - `npm run build` 构建通过，仅有项目既有 warning。 ## 2026-07-09 DesignReportTask 设计报工多人开始结束逻辑 ### 用户反馈 - 用户要求修改 `src/views/ProductionManagement/DesignReportTask/Report/index.vue`。 - 业务规则： - 一个任务允许多个人员分别点击开始和结束。 - A 点击开始后，B 也可以点击开始。 - A 点击结束时，只记录 A 自己的开始时间和结束时间。 - B 点击结束时，只记录 B 自己的开始时间和结束时间。 - 点击完成时必须判断所有已点击开始的人员都已点击结束。 - 如果有人开始后未结束，需要提示具体是谁未结束，且不更新任务状态。 - 只有所有开始记录都已结束后，才允许完成任务。 ### 执行过程 1. 读取 `Report/index.vue`，确认当前前端逻辑使用 `未结束报工数` 控制按钮： - `canStart` 要求 `未结束报工数 === 0`，导致 A 开始后 B 不能开始。 - `canEnd` 只判断任务是否存在未结束记录，不能保证只结束当前操作人的记录。 - `canComplete` 在存在未结束记录时直接禁用按钮，无法按用户要求点击后提示未结束人员。 2. 检查 `db_backups/create_design_report_task_module_20260630.sql`，确认数据库过程也存在同样限制： - `设计报工_任务_开始` 原来只要任务存在任意未结束记录就禁止开始。 - `设计报工_任务_结束` 原来取任务最新一条未结束记录，不区分当前操作人。 - `设计报工_任务_完成` 原来只提示任务存在未结束报工，未返回具体人员。 3. 查询目标库 `YL_MESDB` 中 `MES_设计报工_记录` 表字段，确认已有 `操作人ID`、`操作人`、`开始时间`、`结束时间`、`工时秒数`、`报工状态` 等字段，支持按人员拆分报工记录，无需改表结构。 4. 修改 `src/views/ProductionManagement/DesignReportTask/Report/index.vue`： - 查询参数增加 `当前操作人ID` 和 `当前操作人`。 - 表格增加“未结束人员”列。 - `canStart` 改为只判断当前用户是否存在未结束报工。 - `canEnd` 改为只在当前用户存在未结束报工时可点击。 - `canComplete` 改为任务未完成且已有报工记录即可点击。 - `completeTask` 增加前端判断：如果 `未结束报工数 > 0`，提示 `未结束报工人员`，不调用完成过程。 5. 新增增量脚本 `db_backups/update_design_report_multi_person_work_20260709.sql`： - 更新 `设计报工_任务_查询`，返回 `当前用户未结束报工数` 和 `未结束报工人员`。 - 更新 `设计报工_任务_开始`，只禁止当前人员重复开始，允许其他人员同时开始。 - 更新 `设计报工_任务_结束`，只结束当前人员自己的未结束记录；若其他人员仍未结束，任务状态保持 `执行中`。 - 更新 `设计报工_任务_完成`，如果存在未结束记录，返回“以下人员还未点击结束：人员名单”，不更新任务状态。 6. 同步更新完整建库脚本 `db_backups/create_design_report_task_module_20260630.sql`，确保后续重建模块时不会丢失多人报工逻辑。 7. 使用 `sqlcmd -f 65001` 将增量脚本发布到 `192.168.2.92 / YL_MESDB`，未在日志中记录数据库密码。 8. 第一次事务验证时发现人员名单拼接使用 XML 方法会受到当前 SQL 执行环境 `QUOTED_IDENTIFIER` 设置影响，过程执行报错。 9. 将人员名单拼接从 XML 方法改为 SQL Server 2019 支持的 `STRING_AGG`，重新更新增量脚本和完整建库脚本。 10. 重新发布增量脚本到目标库。 11. 使用事务创建临时测试任务并回滚，验证流程： - 测试 A 点击开始成功。 - 测试 B 点击开始成功。 - 查询结果显示 `报工次数=2`、`未结束报工数=2`、`当前用户未结束报工数=1`、`未结束报工人员=测试A、测试B`。 - 测试 A 点击结束成功。 - A 结束后点击完成失败，返回“以下人员还未点击结束：测试B”。 - 测试 B 点击结束成功。 - A/B 都结束后点击完成成功。 - 事务最终回滚，测试数据未保留。 12. 执行 `npm run build`，前端构建通过，仅有项目既有资源体积和 Browserslist / baseline 数据过期 warning。 13. 查询数据库确认 `GPT-TEST` 临时测试任务残留数为 0，并确认 `设计报工_任务_完成` 已发布为包含 `STRING_AGG` 的新定义。 ### 修改文件 - `src/views/ProductionManagement/DesignReportTask/Report/index.vue` - `db_backups/update_design_report_multi_person_work_20260709.sql` - `db_backups/create_design_report_task_module_20260630.sql` - `gptlog-process/gpdlog.md` ### 结论 - 设计报工页面已支持同一任务多人分别开始、分别结束。 - 当前人员只能结束自己的未结束报工记录，不会误结束其他人员记录。 - 完成任务时会检查所有开始记录是否都已结束；如仍有人未结束，会提示具体人员并阻止任务完成。 - 数据库过程已同步发布到目标库，完整建库脚本也已同步更新。 ### 验证结果 - 数据库事务验证通过，测试数据已回滚且无残留。 - `npm run build` 构建通过，仅有项目既有 warning。 ## 2026-07-09 DesignReportTask DID 3 完成误判复查与防护 ### 用户反馈 - 用户反馈：刚测试 DID=3 任务，点击完成时另一个人没有点结束也提示完成了；完成后另一个人点不了结束。 ### 执行过程 1. 查询目标库 `192.168.2.92 / YL_MESDB` 中 DID=3 的真实数据： - `MES_设计报工_任务` 中 DID=3 状态为 `已完成`。 - `MES_设计报工_记录` 中 DID=3 只有 1 条记录，操作人为“超级管理员”，且该记录已有结束时间。 - DID=3 未查询到第二个人的未结束报工记录。 2. 复查数据库过程定义： - `设计报工_任务_完成` 已包含“以下人员还未点击结束”的拦截逻辑。 - `设计报工_任务_结束` 已按当前人员查找未结束记录。 3. 结论判断： - DID=3 完成成功的直接原因是数据库中没有“另一个人”的开始记录。 - 另一个人点不了结束，是因为 DID=3 没有该人员可结束的未结束记录，且任务已完成。 4. 为避免页面旧数据或并发操作再次造成误判，修改 `src/views/ProductionManagement/DesignReportTask/Report/index.vue`： - `completeTask` 改为异步方法。 - 点击完成时新增 `getLatestTask(DID)`，先实时调用 `设计报工_任务_查询` 获取最新任务状态。 - 完成前使用实时返回的 `未结束报工数` 和 `未结束报工人员` 判断，不再只依赖表格旧行数据。 - 如果实时查询发现有人未结束，提示具体人员并停止调用完成过程。 - 如果实时查询发现任务已完成，提示“任务已完成”并刷新表格。 - 如果任务没有已结束报工，提示不能完成。 - `canEnd` 改为只要当前用户存在未结束报工就允许点击结束，不再因为任务状态是 `已完成` 就禁用，用于修复历史异常状态下“已完成但仍有未结束记录”的结束入口。 5. 新增数据库防护脚本 `db_backups/fix_design_report_complete_guard_20260709.sql`： - 重新发布 `设计报工_任务_开始`、`设计报工_任务_结束`、`设计报工_任务_完成`。 - 开始、结束、完成均对对应 DID 的任务行使用事务锁，避免完成与开始/结束并发造成状态误判。 - 完成过程在事务内重新查询未结束人员，存在未结束记录时返回具体人员并不更新任务状态。 - 结束过程允许历史异常状态下“任务已完成但当前人员仍有未结束记录”的人员继续结束自己的记录。 6. 第一次事务验证时发现过程内部直接 `ROLLBACK TRANSACTION` 会回滚外层测试事务。 7. 修改防护脚本事务写法： - 没有外层事务时由过程自己开启并提交事务。 - 存在外层事务时使用 `SAVE TRANSACTION` 保存点。 - 失败时只回滚过程自己的保存点，不破坏调用方外层事务。 8. 使用 `sqlcmd -f 65001` 发布防护脚本到目标库，日志中未记录数据库密码。 9. 使用事务验证多人未结束完成拦截： - 测试 A 开始成功。 - 测试 B 开始成功。 - 测试 A 结束成功。 - 此时点击完成返回失败，提示“以下人员还未点击结束：测试B”。 - 查询显示任务仍为 `执行中`，`未结束报工数=1`，`当前用户未结束报工数=1`，`未结束报工人员=测试B`。 10. 使用事务验证历史异常状态： - 临时创建一个状态为 `已完成` 但测试 B 仍未结束的任务。 - 查询显示 `未结束报工数=1`、`当前用户未结束报工数=1`。 - 测试 B 点击结束成功。 - 结束后查询显示 `未结束报工数=0`，任务保持 `已完成`。 11. 两组事务验证均已回滚，查询确认 `GPT-GUARD`、`GPT-BAD` 测试数据残留为 0。 12. 执行 `npm run build`，构建通过，仅有项目既有资源体积和 Browserslist / baseline 数据过期 warning。 13. 查询 DID=3 当前未结束记录数为 0，确认 DID=3 没有可让另一个人结束的未结束记录。 ### 修改文件 - `src/views/ProductionManagement/DesignReportTask/Report/index.vue` - `db_backups/fix_design_report_complete_guard_20260709.sql` - `gptlog-process/gpdlog.md` ### 结论 - DID=3 本次完成成功是因为数据库里并没有第二个人的未结束开始记录。 - 已补充前端完成前实时查库，避免表格旧数据导致误判。 - 已补充数据库事务锁防护，完成过程会在最终更新状态前重新检查未结束人员。 - 已允许历史异常状态下，当前人员仍有未结束记录时可以点击结束自己的记录。 ### 验证结果 - DID=3 当前未结束记录数为 0。 - 多人未结束完成拦截验证通过。 - 历史异常已完成状态下结束验证通过。 - 测试数据无残留。 - `npm run build` 构建通过，仅有项目既有 warning。 ## 2026-07-09 清空 DesignReportTask 设计报工业务数据 ### 用户反馈 - 用户要求：清空设计相关的数据。 ### 执行过程 1. 按 `DesignReportTask` 设计报工模块业务数据范围处理，未清理菜单权限、存储过程和表结构。 2. 确认需要清空的三张业务表： - `dbo.MES_设计报工_任务` - `dbo.MES_设计报工_记录` - `dbo.MES_设计报工_校验记录` 3. 清空前查询目标库 `YL_MESDB` 当前数据量： - `MES_设计报工_任务`：2 行。 - `MES_设计报工_记录`：2 行。 - `MES_设计报工_校验记录`：1 行。 4. 清空前先导出本地备份，备份目录： - `db_backups/design_report_data_backup_20260709_110417/` 5. 备份文件包括： - `MES_设计报工_任务.json` - `MES_设计报工_记录.json` - `MES_设计报工_校验记录.json` - `_summary.json` 6. 使用事务按依赖顺序清空数据： - 先清空 `MES_设计报工_校验记录`。 - 再清空 `MES_设计报工_记录`。 - 最后清空 `MES_设计报工_任务`。 7. 清空后执行 `DBCC CHECKIDENT`，将三张表自增标识重置为 0。 8. 再次查询三张业务表行数，确认均为 0。 9. 查询三张表当前标识值，确认均为 0。 ### 修改文件 - `db_backups/design_report_data_backup_20260709_110417/MES_设计报工_任务.json` - `db_backups/design_report_data_backup_20260709_110417/MES_设计报工_记录.json` - `db_backups/design_report_data_backup_20260709_110417/MES_设计报工_校验记录.json` - `db_backups/design_report_data_backup_20260709_110417/_summary.json` - `gptlog-process/gpdlog.md` ### 结论 - `DesignReportTask` 设计报工模块三张业务表已清空。 - 清空前数据已备份到本地 `db_backups/design_report_data_backup_20260709_110417/`。 - 表结构、存储过程、菜单权限未清理。 - 三张表自增编号已重置，后续新增数据将从 1 开始。 ### 验证结果 - `MES_设计报工_任务` 当前 0 行。 - `MES_设计报工_记录` 当前 0 行。 - `MES_设计报工_校验记录` 当前 0 行。 - 三张表当前标识值均为 0。 ## 2026-07-09 DesignReportTask 已完成任务禁止开始补充判断 ### 用户反馈 - 用户反馈：当任务状态为完成时，点击开始应该提示失败；现在任务已经被另一个人点击完成后，还能点击开始。 ### 执行过程 1. 检查 `src/views/ProductionManagement/DesignReportTask/Report/index.vue`。 2. 确认页面原有 `canStart(row)` 会根据当前表格行的 `单据状态` 禁用开始按钮，但如果另一个人完成任务后当前页面未刷新，当前行仍可能是旧状态，导致用户仍能点击开始。 3. 查询数据库过程 `dbo.设计报工_任务_开始`，确认后端已包含“任务已完成，不能开始”的拦截逻辑。 4. 修改 `Report/index.vue` 的 `startTask(row)`： - 将 `startTask` 改为异步方法。 - 点击开始时先调用已有 `getLatestTask(DID)` 实时查询数据库最新任务状态。 - 使用实时返回结果覆盖当前表格行数据。 - 如果实时状态为 `已完成`，提示“任务已完成，不能开始”，刷新表格，并停止调用开始过程。 - 如果当前人员已经存在未结束报工，提示“当前人员已存在未结束的报工记录”，并停止调用开始过程。 - 只有实时状态允许开始时才调用 `设计报工_任务_开始`。 5. 使用事务临时创建一个状态为 `已完成` 的测试任务，并调用 `设计报工_任务_开始` 验证后端返回： - `result=0` - `message=任务已完成，不能开始` 6. 验证事务回滚后测试数据残留数为 0。 7. 执行 `npm run build`，构建通过，仅有项目既有资源体积和 Browserslist / baseline 数据过期 warning。 ### 修改文件 - `src/views/ProductionManagement/DesignReportTask/Report/index.vue` - `gptlog-process/gpdlog.md` ### 结论 - 已完成任务点击“开始”时，前端会先实时查库。 - 如果任务已被其他人完成，会立即提示“任务已完成，不能开始”，不会再调用开始过程。 - 后端开始过程也已确认存在同样拦截，前后端均有保护。 ### 验证结果 - 后端模拟已完成任务点击开始，返回“任务已完成，不能开始”。 - 测试数据无残留。 - `npm run build` 构建通过，仅有项目既有 warning。 ## 2026-07-09 DesignReportTask 设计任务删除失败逻辑修正 ### 用户反馈 - 用户反馈：设计任务删除的结果逻辑不正确。任务 1 点击删除并确认时提示“删除成功”，实际应该提示“删除失败”。 ### 执行过程 1. 检查 `src/views/ProductionManagement/DesignReportTask/Task/index.vue` 中 `deleteTask(row)`： - 原逻辑确认后直接调用 `设计报工_任务_删除`。 - 前端只按返回 `result` 判断成功或失败。 2. 查询目标库中 DID=1 的真实数据： - DID=1 当前状态为 `已完成`。 - DID=1 存在 3 条 `MES_设计报工_记录`。 - DID=1 存在 3 条 `MES_设计报工_校验记录`。 3. 检查数据库删除过程 `dbo.设计报工_任务_删除`： - 原过程只判断是否存在报工记录。 - 对任务不存在、已完成状态、删除 0 行、校验记录等场景保护不足。 4. 修改 `Task/index.vue`： - 删除确认后先调用新增的 `getLatestTask(DID)` 实时查询数据库最新任务。 - 如果任务不存在，提示“删除失败：任务不存在或已被删除”。 - 如果 `报工次数 > 0`，提示“删除失败：该任务已有设计报工记录，不能删除”。 - 如果任务状态为 `已完成`，提示“删除失败：任务已完成，不能删除”。 - 如果任务状态不是 `待开始`，提示对应状态不能删除。 - 只有实时查询确认可删除时，才调用 `设计报工_任务_删除`。 - 删除调用增加异常捕获，接口异常时提示“删除失败”。 5. 新增数据库脚本 `db_backups/fix_design_report_delete_guard_20260709.sql`： - 重新发布 `dbo.设计报工_任务_删除`。 - 只允许 `待开始` 且无报工记录、无校验记录的任务删除。 - 任务不存在、已有报工、已有校验、已完成、非待开始状态、删除 0 行均返回 `result=0`。 - 删除成功时才返回 `result=1`。 6. 同步更新完整建库脚本 `db_backups/create_design_report_task_module_20260630.sql` 中的删除过程定义。 7. 发布删除防护脚本到目标库 `YL_MESDB`，日志中未记录数据库密码。 8. 验证 DID=1 删除： - 执行 `设计报工_任务_删除 @DID=1` 返回 `result=0`。 - 返回消息为“删除失败：该任务已有设计报工记录，不能删除”。 - DID=1 任务仍存在。 9. 使用事务临时创建一个 `待开始` 且无报工记录的测试任务，验证可删除场景： - 删除过程返回 `result=1`、`message=删除成功`。 - 事务内删除后任务残留为 0。 - 回滚后测试数据残留为 0。 10. 执行 `npm run build`，构建通过，仅有项目既有资源体积和 Browserslist / baseline 数据过期 warning。 ### 修改文件 - `src/views/ProductionManagement/DesignReportTask/Task/index.vue` - `db_backups/fix_design_report_delete_guard_20260709.sql` - `db_backups/create_design_report_task_module_20260630.sql` - `gptlog-process/gpdlog.md` ### 结论 - 任务 1 这类已有报工记录的设计任务，现在删除时会提示删除失败。 - 前端删除前会实时查库，不再只依赖表格旧数据。 - 后端删除过程已补充完整保护，只允许未开始且无关联业务记录的任务删除。 ### 验证结果 - DID=1 删除返回失败，提示“该任务已有设计报工记录，不能删除”。 - 可删除的待开始测试任务仍能正常删除。 - 测试数据无残留。 - `npm run build` 构建通过，仅有项目既有 warning。 ## 2026-07-09 DesignReportTask 增加类别字段 ### 用户提问 - 用户要求：设计报工模块增加字段“类别”，类型为文本输入。 ### 执行过程 1. 检查 `DesignReportTask` 下四个页面： - `Task/index.vue` - `Report/index.vue` - `Check/index.vue` - `HoursReport/index.vue` 2. 确认“类别”应作为设计任务主数据字段保存，并在各业务查询中展示和筛选。 3. 修改 `Task/index.vue`： - 查询区增加“类别”文本输入框。 - 表格增加“类别”列。 - 新建/编辑设计任务弹框增加“类别”文本输入框。 - 表单初始数据增加 `类别`。 - 任务查询参数增加 `类别`。 - 新增、编辑保存参数增加 `类别`。 - 删除前实时查询任务详情时补充 `类别` 参数，避免过程参数不一致。 4. 修改 `Report/index.vue`： - 查询区增加“类别”文本输入框。 - 表格增加“类别”列。 - 报工任务查询参数增加 `类别`。 - 开始/结束/完成前实时查询任务详情时补充 `类别` 参数。 5. 修改 `Check/index.vue`： - 查询区增加“类别”文本输入框。 - 表格增加“类别”列。 - 工时校验查询参数增加 `类别`。 6. 修改 `HoursReport/index.vue`： - 查询区增加“类别”文本输入框。 - 表格增加“类别”列。 - 工时报表查询参数增加 `类别`。 - 树形标题中优先显示“类别 | 任务描述”，方便按类别识别任务。 7. 修改完整建库脚本 `db_backups/create_design_report_task_module_20260630.sql`： - `MES_设计报工_任务` 表增加 `[类别] nvarchar(100) NULL`。 - 增加 `COL_LENGTH` 兼容判断，旧库缺少字段时自动 `ALTER TABLE`。 - 以下过程增加 `@类别` 参数、返回字段和筛选条件： - `设计报工_任务_查询` - `设计报工_任务_新增` - `设计报工_任务_编辑` - `设计报工_记录_查询` - `设计报工_工时校验_查询` - `设计报工_工时报表_作业者工时_查询` 8. 新增增量脚本 `db_backups/add_design_report_category_field_20260709.sql`： - 用于直接更新现有数据库，不重建已有业务对象。 - 增加任务表“类别”字段。 - 重建上述 6 个查询/新增/编辑相关过程。 9. 将增量脚本发布到目标数据库 `192.168.2.92 / YL_MESDB`，日志中不记录数据库密码。 10. 数据库验证： - 检查 `MES_设计报工_任务` 中 `类别` 字段存在，结果为 `1`。 - 检查 6 个相关存储过程均包含 `@类别` 参数和 `[类别]` 字段，结果均为 `1`。 - 第一次事务验证时误按旧理解传入了 `@任务状态`，数据库返回该参数不存在；随后查询真实过程签名并按真实参数重新验证。 - 第二次事务验证中执行新增，返回 `result=1`、`message=新增成功`、验证 DID 为 `6`，新增类别为 `结构`。 - 同一事务内执行编辑，返回 `result=1`、`message=编辑成功`，编辑后类别为 `电气`。 - 事务回滚后验证数据残留数量为 `0`。 11. 前端静态检查： - 使用 `rg` 和 `Select-String` 确认四个页面均存在“类别”查询输入、表格列和查询参数。 12. 执行 `npm run build`： - 构建通过。 - 仅有项目既有资源体积超限 warning，以及 Browserslist / baseline-browser-mapping 数据过期提示。 ### 修改文件 - `src/views/ProductionManagement/DesignReportTask/Task/index.vue` - `src/views/ProductionManagement/DesignReportTask/Report/index.vue` - `src/views/ProductionManagement/DesignReportTask/Check/index.vue` - `src/views/ProductionManagement/DesignReportTask/HoursReport/index.vue` - `db_backups/create_design_report_task_module_20260630.sql` - `db_backups/add_design_report_category_field_20260709.sql` - `gptlog-process/gpdlog.md` ### 结论 - 设计报工模块已增加“类别”文本字段。 - 新建设计任务和编辑设计任务可以录入、保存、修改“类别”。 - 任务管理、设计报工、工时校验、工时报表四个页面均支持按“类别”筛选并展示“类别”列。 - 数据库表和相关存储过程已同步更新到目标库。 ### 验证结果 - 数据库字段存在，相关存储过程均已包含“类别”。 - 新增/编辑事务验证通过，测试数据已回滚，无残留。 - `npm run build` 构建通过，仅有项目既有 warning。 ## 2026-07-10 DesignReportTask Check 和 HoursReport 菜单权限补录 ### 用户提问 - 用户要求给 `DesignReportTask` 下 `check` 和 `HoursReport` 添加账号代码 `1` 的二级菜单权限。 - 目标数据库为 `192.168.2.92 / YL_MESDB`，目标表为 `[dbo].[登录基础数据_二级菜单]`。 - 数据库账号信息由用户提供，本日志不记录数据库明文密码。 ### 执行过程 1. 读取当前项目目录，确认存在 `gptlog-process/gpdlog.md`、`db_backups` 和 `DesignReportTask` 相关历史记录。 2. 使用 `rg` 搜索 `登录基础数据_二级菜单`、`DesignReportTask`、`HoursReport`、`check`，确认项目内已有设计报工模块和历史菜单处理记录。 3. 确认本机存在 `sqlcmd`，路径为 SQL Server ODBC 170 工具目录下的 `SQLCMD.EXE`。 4. 读取 `db_backups/add_design_report_task_menu_account1_20260709.sql`，确认历史脚本中四个页面的菜单定义： - `DesignReportTask/Task/index`：设计任务 - `DesignReportTask/Report/index`：设计报工 - `DesignReportTask/Check/index`：设计工时校验 - `DesignReportTask/HoursReport/index`：设计工时报表 5. 第一次直接读取脚本和日志时发现 PowerShell 默认编码显示中文乱码，随后改用 `Get-Content -Encoding UTF8` 重新读取，确认脚本内容和日志中文正常。 6. 使用 `sqlcmd -f 65001` 连接目标库，查询账号代码 `1` 下 `DesignReportTask/Check/index`、`DesignReportTask/HoursReport/index`、`设计工时校验`、`设计工时报表`，执行前未查询到对应记录。 7. 同步查询账号代码 `1` 的一级父菜单，确认“生产管理”父菜单存在且启用，`id=3`。 8. 查询 `[dbo].[登录基础数据_二级菜单]` 表结构，确认： - `IDD` 为 identity 字段。 - `id` 不是 identity，需要手工维护。 - 菜单字段包含 `pid`、`path`、`componet`、`name`、`title`、`icon`、`账号代码`、`模块代码`、`是否启用`、`操作时间` 等。 9. 查询当前最大 `id` 为 `249`。 10. 查询账号代码 `1` 下已有 `DesignReportTask` 菜单，确认已有： - `id=248`，`设计任务`，`DesignReportTask/Task/index`，已启用。 - `id=249`，`设计报工`，`DesignReportTask/Report/index`，已启用。 11. 在事务中补录并启用两条缺失菜单： - `id=250`，`pid=3`，`path=DesignReportTask/Check/index`，`componet=/ProductionManagement/DesignReportTask/Check/index`，`name=DesignReportCheck`，`title=设计工时校验`，`icon=PayStateSearch`，`账号代码=1`，`模块代码=250`，`是否启用=1`。 - `id=251`，`pid=3`，`path=DesignReportTask/HoursReport/index`，`componet=/ProductionManagement/DesignReportTask/HoursReport/index`，`name=DesignReportHoursReport`，`title=设计工时报表`，`icon=DimensionsSummaryReport`，`账号代码=1`，`模块代码=251`，`是否启用=1`。 12. 事务提交后 SQL 返回汇总：插入 `2` 条，更新启用 `2` 条，父菜单 `parent_id=3`。 13. 再次查询账号代码 `1` 下所有 `DesignReportTask` 菜单，确认共有四条并全部启用： - `248`：设计任务 - `249`：设计报工 - `250`：设计工时校验 - `251`：设计工时报表 14. 本次未修改前端代码和业务表结构，只修改了目标数据库中的二级菜单权限记录，并追加本日志。 ### 结论 - 账号代码 `1` 已补齐 `DesignReportTask` 下 `Check` 和 `HoursReport` 两个页面的二级菜单权限。 - 两条菜单均挂在账号代码 `1` 的“生产管理”父菜单下，父菜单 `id=3`。 - 当前账号代码 `1` 下 `DesignReportTask` 四个菜单 `Task`、`Report`、`Check`、`HoursReport` 均存在且 `是否启用=1`。 ### 验证结果 - `设计工时校验`：`id=250`，`pid=3`，`是否启用=1`。 - `设计工时报表`：`id=251`，`pid=3`，`是否启用=1`。 - 最终复查查询返回 `DesignReportTask` 四条菜单，编号为 `248` 至 `251`。 ## 2026-07-10 上传所有修改到远程 ### 用户提问 - 用户要求：上传所有修改到远程。 ### 执行过程 1. 检查 Git 工作区状态，确认当前存在已修改、已删除和未跟踪文件。 2. 确认当前分支为 `snapshot/local-save-20260625-154806`。 3. 确认远程仓库为 `origin`，地址为 `http://154.8.160.151:3000/meswork/MES_Manage_View_V20.git`。 4. 查询最近一次提交，当前 HEAD 为 `bd9ca09 feat: 增加设备数据导出`。 5. 使用 `git status -sb` 确认当前分支跟踪 `origin/snapshot/local-save-20260625-154806`。 6. 使用 `git branch -vv` 确认本地分支已绑定同名远程分支。 7. 使用 `git diff --stat` 汇总已跟踪文件改动，确认包含设计报工模块前端、数据库脚本、文档、日志和设备资料目录删除等改动。 8. 使用 `git ls-files --others --exclude-standard` 汇总未跟踪文件，确认包含 `AGENTS.md`、设计报工相关增量 SQL 脚本和数据备份 JSON。 9. 执行 `git fetch origin` 刷新远程状态。 10. 第一次执行上游分支检查时，PowerShell 将 `@{u}` 解析为哈希字面量导致命令失败；随后改用引号包裹 `@{u}` 重新执行。 11. 重新确认上游分支为 `origin/snapshot/local-save-20260625-154806`。 12. 使用 `git rev-list --left-right --count HEAD...'@{u}'` 确认本地与远程提交差异为 `0 0`，提交前不存在分叉。 13. 使用 `git status --porcelain | Measure-Object -Line` 统计当前工作区有 `32` 条状态记录。 14. 按日志规则先追加本条中文执行记录，本条记录将随同本次提交一起推送到远程。 15. 后续将执行 `git add -A` 全量暂存当前可见改动，创建提交，并推送到当前跟踪远程分支。 ### 结论 - 已确认当前分支和远程分支未分叉，可以直接提交并推送。 - 本次按用户“所有修改”的要求处理，不筛除当前工作区中的已修改、已删除和未跟踪文件。 - 本日志记录会随同本次提交一起上传到远程。 ## 2026-07-10 上传所有修改到远程结果补充 ### 执行过程 1. 执行 `git add -A`，将当前工作区全部已修改、已删除和未跟踪文件纳入暂存区。 2. `git add -A` 过程中出现若干 LF/CRLF 换行符提示，未阻止暂存。 3. 使用 `git status --short` 复核暂存区，确认新增、修改、删除均已暂存。 4. 使用 `git diff --cached --stat` 复核暂存统计，确认本次暂存共 `35` 个文件变更，包含 `3033` 行新增和 `780` 行删除。 5. 执行 `git commit -m "chore: 上传当前工作区修改"` 创建提交。 6. 提交创建成功，提交号为 `a6a92ff`，提交信息为 `chore: 上传当前工作区修改`。 7. 执行 `git push origin snapshot/local-save-20260625-154806` 推送到远程。 8. 推送成功，远程分支 `snapshot/local-save-20260625-154806` 从 `bd9ca09` 更新到 `a6a92ff`。 9. 推送后执行 `git status -sb`，确认本地分支仍跟踪 `origin/snapshot/local-save-20260625-154806`。 10. 执行 `git rev-list --left-right --count HEAD...'@{u}'`，确认本地与远程差异为 `0 0`。 11. 执行 `git log -1 --oneline`，确认当前最新提交为 `a6a92ff chore: 上传当前工作区修改`。 12. 为补充记录推送成功结果，追加本条日志；本条日志将作为单独的日志补充提交继续推送到同一远程分支。 ### 结论 - 用户要求上传的当前工作区全部修改已提交并推送到远程分支。 - 首次推送成功的提交号为 `a6a92ff`。 - 推送后本地与远程分支一致，差异为 `0 0`。 ## 2026-07-10 DesignReportTask 工时校验补结束后任务状态回写 ### 用户提问 - 用户反馈：`ProductionManagement/DesignReportTask/Check/index` 中，已经点击开始但没有结束的任务，在校验页点击“校验”并输入结束时间后可以校验完成，但任务状态没有改变，仍然是“执行中”。 ### 执行过程 1. 检查 `src/views/ProductionManagement/DesignReportTask/Check/index.vue`，确认校验保存调用的是 `设计报工_工时校验_保存`。 2. 检查完整建库脚本 `db_backups/create_design_report_task_module_20260630.sql`，确认 `设计报工_工时校验_保存` 原逻辑只更新 `MES_设计报工_记录`： - 写入 `开始时间`、`结束时间`、`工时秒数`。 - 将 `报工状态` 改为 `已结束`。 - 将 `已校验` 改为 `1`。 - 写入校验人、校验时间和备注。 3. 确认原过程没有同步更新 `MES_设计报工_任务.[单据状态]`，这是校验页手工补结束时间后任务仍为“执行中”的原因。 4. 检查 `Report/index.vue` 和需求文档，确认设计报工状态规则： - “结束”后任务状态应为 `已结束`。 - “完成”是单独动作，完成后任务状态才变为 `已完成`。 5. 决定本次修复口径： - 校验页手工补结束时间后，如果该 DID 已无未结束报工记录，则任务状态回写为 `已结束`。 - 如果该 DID 仍有其他未结束报工记录，则任务状态保持 `执行中`。 - 如果任务已经是 `已完成`，校验保存不回退任务状态。 6. 修改 `src/views/ProductionManagement/DesignReportTask/Check/index.vue`： - 在校验表格中增加“任务状态”列，直接显示 `单据状态`。 - 增加 `getStatusType` 方法，按 `已完成`、`执行中`、`已结束` 显示不同标签类型。 - 单条校验成功后改为 `await this.searchTable()`，确保校验后刷新完成再结束流程。 - 批量校验成功后也改为 `await this.searchTable()`。 7. 修改 `db_backups/create_design_report_task_module_20260630.sql` 中 `设计报工_工时校验_保存`： - 保存校验记录并更新报工记录后，新增任务状态回写逻辑。 - 状态回写规则为：已完成保持已完成；仍有未结束记录则为执行中；否则为已结束。 - 返回结果中增加 `任务状态` 字段，便于调用方确认状态。 8. 修改 `db_backups/create_design_report_task_module_20260630.sql` 中 `设计报工_工时校验_批量保存`： - 增加受影响 DID 集合。 - 批量校验后按相同规则回写任务状态。 - 将记录更新条数保存到变量，避免后续任务更新覆盖返回的 `count`。 9. 新增增量脚本 `db_backups/fix_design_report_check_status_20260710.sql`： - 用于直接发布现有数据库。 - 重建 `设计报工_工时校验_保存` 和 `设计报工_工时校验_批量保存`。 10. 将增量脚本发布到目标库 `192.168.2.92 / YL_MESDB`，日志中不记录数据库明文密码。 11. 使用事务构造临时数据验证单条校验： - 新建一个状态为 `执行中` 的临时任务和一条未结束报工记录。 - 调用 `设计报工_工时校验_保存` 传入开始时间和结束时间。 - 返回 `result=1`、`message=校验成功`、`任务状态=已结束`。 - 查询确认任务状态为 `已结束`，报工记录状态为 `已结束`，`已校验=1`。 - 回滚事务后确认测试任务残留数量为 `0`。 12. 使用事务构造多人未结束场景验证： - 新建一个状态为 `执行中` 的临时任务和两条未结束报工记录。 - 只对其中一条记录调用 `设计报工_工时校验_保存` 补结束时间并校验。 - 返回 `result=1`、`任务状态=执行中`。 - 查询确认仍有 `1` 条未结束记录，任务状态保持 `执行中`。 - 回滚事务后确认测试任务残留数量为 `0`。 13. 批量校验测试第一次执行时报错： - 错误为使用 XML 方法时 `QUOTED_IDENTIFIER` 设置不正确。 - 原因是新增增量脚本未显式设置 `SET QUOTED_IDENTIFIER ON`。 14. 检查完整建库脚本，确认完整脚本已有 `SET ANSI_NULLS ON` 和 `SET QUOTED_IDENTIFIER ON`。 15. 修改 `db_backups/fix_design_report_check_status_20260710.sql`，在过程创建前补充： - `SET ANSI_NULLS ON` - `SET QUOTED_IDENTIFIER ON` 16. 重新发布增量脚本到目标库。 17. 重新使用事务验证批量校验： - 新建一个状态为 `执行中` 的临时任务和两条已有结束时间的报工记录。 - 调用 `设计报工_工时校验_批量保存`。 - 返回 `result=1`、`message=批量校验成功`、`count=2`。 - 查询确认两条记录均已校验，任务状态变为 `已结束`。 - 回滚事务后确认测试任务残留数量为 `0`。 18. 第一次执行 `npm run build` 时 124 秒超时，没有得到构建结论。 19. 使用更长超时时间重新执行 `npm run build`，构建通过。 20. 构建输出仅有项目既有的大资源体积 warning，以及 Browserslist / baseline-browser-mapping 数据过期提示。 21. 检查 Git 状态，确认构建未额外修改 `dist`，当前变更只包含本次源码、数据库脚本和本日志。 ### 修改文件 - `src/views/ProductionManagement/DesignReportTask/Check/index.vue` - `db_backups/create_design_report_task_module_20260630.sql` - `db_backups/fix_design_report_check_status_20260710.sql` - `gptlog-process/gpdlog.md` ### 结论 - 设计工时校验页手工补结束时间并保存校验后，任务状态会按报工记录自动回写。 - 单个任务所有报工记录都已有结束时间时，任务状态会从 `执行中` 改为 `已结束`。 - 同一任务仍有其他未结束报工记录时，任务状态保持 `执行中`。 - 已完成任务不会因为工时校验被回退状态。 - 校验页现在直接显示“任务状态”，便于校验后确认状态变化。 ### 验证结果 - 单条补结束时间校验：通过，任务状态变为 `已结束`。 - 多人仍有未结束记录：通过，任务状态保持 `执行中`。 - 批量校验：通过，任务状态变为 `已结束`，返回 `count=2`。 - 所有数据库验证均在事务中回滚，测试数据无残留。 - `npm run build` 构建通过，仅有项目既有 warning。 ## 2026-07-10 DesignReportTask 新建设计任务取消物料编码必填 ### 用户提问 - 用户要求修改 `ProductionManagement/DesignReportTask/Task/index`，新建设计任务时去掉“物料编码”必填规则。 ### 执行过程 1. 检查当前 Git 工作区，确认已有上一轮未提交的 `DesignReportTask` 校验状态回写相关改动和日志改动。 2. 检查 `src/views/ProductionManagement/DesignReportTask/Task/index.vue`。 3. 搜索 `物料编码`、`rules`、`新增`、`保存` 等关键字，定位到表单校验规则： - 原规则中 `物料编码` 存在 `{ required: true, message: '请选择物料编码', trigger: 'change' }`。 - `任务描述` 仍为必填。 4. 检查 `db_backups/create_design_report_task_module_20260630.sql`，确认数据库表字段 `[物料编码]` 允许为空，新增过程 `设计报工_任务_新增` 也使用 `NULLIF(@物料编码, N'')`，后端没有强制物料编码必填。 5. 使用 `apply_patch` 修改 `Task/index.vue`： - 删除 `rules` 中的 `物料编码` 必填校验。 - 保留 `任务描述` 必填校验。 6. 复核 `Task/index.vue` 中 `rules` 片段，确认当前只剩： - `任务描述: [{ required: true, message: '请输入任务描述', trigger: 'blur' }]` 7. 注意到 `Task/index.vue` 中还有本轮之前已经存在的未提交差异，例如“研发目的”布局和人员显示格式调整；本次未回退这些既有改动。 8. 执行 `npm run build` 验证前端构建。 9. 构建通过，仅有项目既有的大资源体积 warning，以及 Browserslist / baseline-browser-mapping 数据过期提示。 10. 检查 Git 状态，确认构建未额外修改 `dist` 输出文件。 11. 追加本条中文执行日志。 ### 修改文件 - `src/views/ProductionManagement/DesignReportTask/Task/index.vue` - `gptlog-process/gpdlog.md` ### 结论 - 新建设计任务时，“物料编码”不再必填。 - 保存时仍会按原逻辑传递 `物料编码`，为空时后端按空值处理。 - “任务描述”必填规则保持不变。 ### 验证结果 - `Task/index.vue` 表单规则已不包含 `物料编码` 必填校验。 - `npm run build` 构建通过，仅有项目既有 warning。 ## 2026-07-10 DesignReportTask 移到研发管理主菜单 ### 用户提问 - 用户要求增加主菜单“研发管理”，并将 `DesignReportTask` 下四个页面都放到“研发管理”下面。 - 用户说明：“研发管理”和“生产管理”平级，属于主菜单。 ### 执行过程 1. 检查当前 Git 工作区，确认已有前几轮未提交改动： - `db_backups/create_design_report_task_module_20260630.sql` - `gptlog-process/gpdlog.md` - `src/views/ProductionManagement/DesignReportTask/Check/index.vue` - `src/views/ProductionManagement/DesignReportTask/Task/index.vue` - `db_backups/fix_design_report_check_status_20260710.sql` 2. 查询目标库 `192.168.2.92 / YL_MESDB` 的 `[dbo].[登录基础数据_二级菜单]`，日志中不记录数据库明文密码。 3. 查询 `DesignReportTask` 当前菜单分布： - 账号代码 `1` 下存在四个页面，均挂在 `pid=3` 的“生产管理”下。 - 账号代码 `2010` 下只存在 `Task` 和 `Report` 两个页面，均挂在 `pid=3`。 4. 查询主菜单，确认当前没有“研发管理”主菜单。 5. 查询账号代码 `1` 的主菜单，确认： - `id=3` 为“生产管理”。 - 当前主菜单最大 id 为 `8`。 - 账号代码 `1` 下 `id=9` 未被占用。 6. 考虑到用户本轮未指定其他账号，且账号 `2010` 下并不具备四个 `DesignReportTask` 页面，本次按前序操作口径处理账号代码 `1`，避免无意给其他账号新增页面权限。 7. 检查前端动态路由逻辑： - `src/router/getTreeData.js` 按 `pid` 构造菜单树。 - 主菜单使用 `path` 和 `/layout/Layout` 作为布局路由。 - 子菜单使用原有 `componet=/ProductionManagement/DesignReportTask/...` 加载真实页面组件。 8. 新增数据库增量脚本 `db_backups/move_design_report_task_to_rd_menu_account1_20260710.sql`： - 若账号 `1` 下不存在“研发管理”，则插入主菜单： - `id=9` - `pid=0` - `path=/ResearchManagement` - `componet=/layout/Layout` - `name=ResearchManagement` - `title=研发管理` - `icon=CreateProject` - `账号代码=1` - `模块代码=9` - `是否启用=1` - 若“研发管理”已存在，则更新为上述主菜单配置并启用。 - 定义 `DesignReportTask` 四个子菜单： - `DesignReportTask/Task/index`：设计任务 - `DesignReportTask/Report/index`：设计报工 - `DesignReportTask/Check/index`：设计工时校验 - `DesignReportTask/HoursReport/index`：设计工时报表 - 如果四个子菜单缺失则补录；如果已存在则移动到“研发管理”下并启用。 - 子菜单 `componet` 保持 `/ProductionManagement/DesignReportTask/...` 不变，避免影响页面组件加载路径。 9. 执行 `db_backups/move_design_report_task_to_rd_menu_account1_20260710.sql` 发布到目标库。 10. 发布结果返回： - `id=9`，`pid=0`，`title=研发管理`。 - `id=248`，`pid=9`，`title=设计任务`。 - `id=249`，`pid=9`，`title=设计报工`。 - `id=250`，`pid=9`，`title=设计工时校验`。 - `id=251`，`pid=9`，`title=设计工时报表`。 11. 再次查询账号代码 `1` 的主菜单，确认“研发管理”已与“生产管理”同级，均为 `pid=0`。 12. 再次查询账号代码 `1` 的 `DesignReportTask` 四个页面，确认四条均为 `pid=9`。 13. 查询账号代码 `1` 下 `pid=3` 的 `DesignReportTask` 数量，结果为 `0`，确认生产管理下已无设计报工页面残留。 14. 本次不修改前端页面代码；动态菜单通过数据库菜单表生效。 ### 修改文件 - `db_backups/move_design_report_task_to_rd_menu_account1_20260710.sql` - `gptlog-process/gpdlog.md` ### 结论 - 账号代码 `1` 已新增“研发管理”主菜单。 - “研发管理”与“生产管理”平级，均为主菜单，`研发管理.id=9`，`pid=0`。 - 账号代码 `1` 的 `DesignReportTask` 四个页面已全部移动到“研发管理”下。 - 生产管理下不再包含账号代码 `1` 的 `DesignReportTask` 页面。 ### 验证结果 - `研发管理`：`id=9`，`pid=0`，`path=/ResearchManagement`，`componet=/layout/Layout`，`是否启用=1`。 - `设计任务`：`id=248`，`pid=9`，`是否启用=1`。 - `设计报工`：`id=249`，`pid=9`，`是否启用=1`。 - `设计工时校验`：`id=250`，`pid=9`，`是否启用=1`。 - `设计工时报表`：`id=251`，`pid=9`，`是否启用=1`。 - 账号代码 `1` 下生产管理 `pid=3` 的 `DesignReportTask` 页面数量为 `0`。 ## 2026-07-10 设计报工结束弹框增加进度说明 ### 用户提问 - 用户要求修改 `ResearchManagement/DesignReportTask/Report/index`。 - 点击“结束”时先弹框，弹框显示： - id 号 - 物料名称 - 物料编码 - 任务描述 - 新增字段“进度说明” - 点击弹框里的“确认”后，才执行结束报工。 ### 执行过程 1. 根据当前菜单配置确认：虽然菜单已经挂到“研发管理”，真实前端组件仍使用原路径 `src/views/ProductionManagement/DesignReportTask/Report/index.vue`，因此本次修改该组件。 2. 检查 `Report/index.vue` 现有逻辑： - “结束”按钮原来直接调用 `endTask(row)`。 - `endTask(row)` 会先查询最新任务状态和当前操作人未结束报工记录。 - 校验通过后直接调用存储过程 `设计报工_任务_结束`。 3. 查询目标库 `192.168.2.92 / YL_MESDB` 的表结构和存储过程定义，日志中不记录数据库明文密码。 4. 确认 `[dbo].[MES_设计报工_记录]` 原来没有 `[进度说明]` 字段，存储过程 `[dbo].[设计报工_任务_结束]` 原来没有 `@进度说明` 参数。 5. 采用持久化方案：结束报工弹框录入的“进度说明”写入报工记录表，并在查询和工时报表中返回该字段。 6. 修改 `src/views/ProductionManagement/DesignReportTask/Report/index.vue`： - 新增“结束报工”弹框。 - 弹框内展示 `DID`、`物料编码`、`物料名称`、`任务描述`。 - 新增可编辑字段 `进度说明`，最大长度 500。 - 点击列表“结束”时只打开弹框，不立即结束。 - 点击弹框“确认”后才调用 `设计报工_任务_结束`。 - 调用结束存储过程时传入 `进度说明`。 - 调整 `runAction()`，使其成功返回 `true`、失败返回 `false`，便于确认后关闭弹框。 7. 修改 `src/views/ProductionManagement/DesignReportTask/Check/index.vue`： - 在报工记录列表增加 `进度说明` 列，便于校验页面查看结束说明。 8. 修改 `src/views/ProductionManagement/DesignReportTask/HoursReport/index.vue`： - 在工时报表中增加 `进度说明` 列。 9. 修改初始化脚本 `db_backups/create_design_report_task_module_20260630.sql`： - `MES_设计报工_记录` 增加 `[进度说明] nvarchar(500) NULL`。 - 增加字段补齐脚本，字段不存在时自动添加。 - 重建 `设计报工_任务_结束`，增加 `@进度说明` 参数并写入记录表。 - 重建 `设计报工_记录_查询`，返回 `进度说明`。 - 重建 `设计报工_工时报表_作业者工时_查询`，返回 `进度说明`。 10. 新增数据库增量脚本 `db_backups/add_design_report_progress_note_20260710.sql`： - 补齐 `[进度说明]` 字段。 - 重建 `设计报工_任务_结束`。 - 重建 `设计报工_记录_查询`。 - 重建 `设计报工_工时报表_作业者工时_查询`。 11. 执行增量脚本发布到目标库 `192.168.2.92 / YL_MESDB`，执行成功。 12. 使用数据库事务做验证，验证后回滚测试数据： - 临时插入一条设计任务。 - 临时插入一条当前用户未结束报工记录。 - 执行 `设计报工_任务_结束` 并传入 `进度说明`。 - 返回 `1, 结束成功`。 - 查询确认任务状态变为 `已结束`。 - 查询确认报工记录状态变为 `已结束`，结束时间已写入，`进度说明` 已保存。 - 查询确认 `设计报工_记录_查询` 可以返回 `进度说明`。 - 查询确认 `设计报工_工时报表_作业者工时_查询` 可以返回 `进度说明`。 - 回滚事务后确认测试任务无残留。 13. 执行 `npm run build`，构建通过。 ### 修改文件 - `src/views/ProductionManagement/DesignReportTask/Report/index.vue` - `src/views/ProductionManagement/DesignReportTask/Check/index.vue` - `src/views/ProductionManagement/DesignReportTask/HoursReport/index.vue` - `db_backups/create_design_report_task_module_20260630.sql` - `db_backups/add_design_report_progress_note_20260710.sql` - `gptlog-process/gpdlog.md` ### 结论 - 设计报工点击“结束”后会先弹出确认窗口。 - 弹框显示 id 号、物料编码、物料名称、任务描述，并支持填写“进度说明”。 - 只有点击弹框“确认”后才会真正执行结束报工。 - “进度说明”已落库到报工记录，并在校验页面和工时报表中展示。 ### 验证结果 - 数据库增量脚本已发布到 `192.168.2.92 / YL_MESDB`。 - 数据库事务验证通过，测试数据已回滚。 - `npm run build` 构建通过，仅有项目既有体积和 Browserslist 数据过期 warning。 ## 2026-07-10 上传设计报工相关修改到远程 ### 用户提问 - 用户要求“上传所有修改到远程”。 ### 执行过程 1. 在完成设计报工相关前端修改、数据库脚本发布、数据库事务验证和前端构建验证后，检查 Git 工作区。 2. 确认本地分支为 `snapshot/local-save-20260625-154806`，跟踪远端分支 `origin/snapshot/local-save-20260625-154806`。 3. 执行 `git fetch origin` 刷新远端状态。 4. 检查本地与远端提交数量差异，结果为 `0 0`，确认推送前本地和远端没有分叉。 5. 使用内容搜索检查待提交文件中未包含数据库明文密码。 6. 暂存本批设计报工相关改动文件： - `db_backups/add_design_report_progress_note_20260710.sql` - `db_backups/create_design_report_task_module_20260630.sql` - `db_backups/fix_design_report_check_status_20260710.sql` - `db_backups/move_design_report_task_to_rd_menu_account1_20260710.sql` - `gptlog-process/gpdlog.md` - `src/views/ProductionManagement/DesignReportTask/Check/index.vue` - `src/views/ProductionManagement/DesignReportTask/HoursReport/index.vue` - `src/views/ProductionManagement/DesignReportTask/Report/index.vue` - `src/views/ProductionManagement/DesignReportTask/Task/index.vue` 7. 执行 `git diff --cached --check`，未发现空白错误。 8. 创建提交： - 提交号：`e89cef4` - 提交信息：`feat: 完善设计报工研发管理流程` 9. 执行 `git push`，将提交推送到远端 `origin/snapshot/local-save-20260625-154806`。 10. 为满足项目日志要求，追加本条中文执行记录，并继续将该日志补充同步到远端。 ### 结论 - 设计报工相关功能和数据库脚本改动已提交并推送到远端。 - 功能提交号为 `e89cef4`。 - 本条日志补充将继续提交并推送到同一远端分支。 ## 2026-07-11 设计工时报表增加数据导出功能 ### 用户提问 - 用户要求修改 `ResearchManagement/DesignReportTask/HoursReport/index` 页面，增加数据导出功能。 ### 执行过程 1. 读取仓库根目录 `AGENTS.md`，确认每次执行结束后必须将提问、结论和完整执行过程以中文追加到 `gptlog-process/gpdlog.md`。 2. 搜索菜单、工作文档和前端源码，确认菜单虽然位于 `ResearchManagement`，但真实组件路径仍为 `src/views/ProductionManagement/DesignReportTask/HoursReport/index.vue`。 3. 检查目标页面现有实现，确认： - 页面通过 `设计报工_工时报表_作业者工时_查询` 一次查询全部结果，没有分页。 - 查询结果在前端组装为“操作人、日期、任务”三级树形结构。 - 页面已有开始日期、结束日期、操作人、项目号、物料编码、类别和任务 ID 筛选条件。 4. 搜索项目内已有 Excel 导出实现，确认项目已安装并普遍使用 `xlsx`，导出按钮采用 Element UI 的 `el-icon-download` 和成功、失败、无数据消息提示。 5. 确定采用前端导出当前查询结果的方案，不新增后端接口，也不重复请求数据库；导出顺序保持页面树形显示顺序。 6. 修改 `src/views/ProductionManagement/DesignReportTask/HoursReport/index.vue`： - 在查询按钮旁增加“导出”按钮。 - 查询加载中或当前无数据时禁用导出按钮。 - 增加独立的 `exporting` 状态，导出过程中显示加载状态。 - 引入 `xlsx`。 - 新增树形数据递归扁平化方法，按操作人、日期、任务的顺序生成 Excel 数据。 - 导出操作人汇总、日期汇总和任务明细，并增加“层级”列便于识别数据类型。 - 导出页面现有字段：操作人/日期/任务、工作日期、RID、DID、项目号、物料编码、物料名称、图号、类别、报工次数、工时、开始时间、结束时间、校验状态、进度说明和备注。 - 为各列设置适合中文内容的列宽。 - 导出文件名使用 `设计工时报表_yyyyMMdd_HHmmss.xlsx` 格式。 - 增加无数据、导出成功和导出失败提示及异常日志。 7. 执行 `npx eslint src/views/ProductionManagement/DesignReportTask/HoursReport/index.vue`，单文件 ESLint 检查通过；仅出现项目依赖的 Browserslist 和 Baseline 数据过期提示。 8. 首次执行生产构建时调用超时并被终止，没有形成有效验证结果。 9. 使用充足超时时间重新执行 `npm run build`，Webpack 生产构建成功；仅有项目原有的大资源体积警告和浏览器兼容数据库过期提示。 10. 检查 Git 工作区和差异：构建未留下 `dist` 版本控制变更，`git diff --check` 未发现空白错误。 11. 启动本地开发服务器进行预览验证。首次开发编译耗时较长，在 HTTP 轮询截止后随即完成，日志显示 `webpack compiled successfully`。 12. 确认开发服务器使用 HTTPS，使用忽略本地证书校验的请求访问 `https://localhost:1997/`，返回 HTTP `200`。随后将开发服务器重启为日志输出到系统临时目录，清理工作区临时日志，并保持预览服务运行。 ### 修改文件 - `src/views/ProductionManagement/DesignReportTask/HoursReport/index.vue` - `gptlog-process/gpdlog.md` ### 结论 - 设计工时报表页面已增加 Excel 数据导出功能。 - 导出内容使用当前筛选后的完整树形报表数据，并保留操作人汇总、日期汇总和任务明细层级。 - 不需要新增或修改后端接口。 ### 验证结果 - 单文件 ESLint 检查通过。 - `npm run build` 生产构建通过。 - `git diff --check` 通过。 - 本地开发服务器编译成功，`https://localhost:1997/` 返回 HTTP `200`。 ## 2026-07-11 产品合格率工位菜单迁移到质量管理 ### 用户提问 - 用户要求将 `ProductionManagement/ProductPassRateWorkstation/index` 页面放到“质量管理”菜单下，并提供了目标数据库 `192.168.2.92` 的授权凭据。 - 按安全要求，本日志不记录数据库明文密码。 ### 执行过程 1. 搜索前端页面、菜单脚本和项目工作文档，确认： - 页面组件为 `src/views/ProductionManagement/ProductPassRateWorkstation/index.vue`。 - 菜单路由为 `ProductPassRateWorkstation/index`。 - 组件配置为 `/ProductionManagement/ProductPassRateWorkstation/index`。 - 原菜单脚本 `db_backups/add_product_pass_rate_workstation_menu_20260630.sql` 按生产管理中的“生产计划跟踪”菜单复制权限和父级。 2. 检查本机数据库工具，确认可使用 `sqlcmd` 连接 SQL Server。 3. 使用用户提供的凭据只读查询 `192.168.2.92 / YL_MESDB`，查询结果显示： - 产品合格率工位菜单共有 11 条，分别属于账号代码 `1、1004、1006、1007、2008、2010、2014、2015、2018、2026、2027`。 - 11 条目标菜单原来均位于生产管理下，`pid=3`。 - 账号 `1、1004、1007、2010、2026、2027` 已有质量管理根菜单。 - 账号 `1006、2008、2014、2015、2018` 缺少质量管理根菜单。 4. 查询菜单表结构，确认： - 菜单表为 `dbo.登录基础数据_二级菜单`。 - `IDD` 是标识列和主键，业务菜单 `id` 可在不同账号间复用。 - 现有质量管理根菜单统一使用 `id=4、pid=0、path=/QualityManagement、componet=/layout/Layout`。 5. 查询账号代码 `1` 的质量管理子菜单，确认菜单归属由 `pid=4` 决定，组件源码不必搬到 `QualityManagement` 目录。因此保留原组件路径，避免修改动态路由和源码目录。 6. 新增幂等增量脚本 `db_backups/move_product_pass_rate_workstation_to_quality_menu_20260711.sql`： - 动态收集所有已有产品合格率工位菜单的账号。 - 对缺少质量管理根菜单的目标账号补齐标准质量管理根菜单。 - 在菜单 ID 4 被其他菜单占用时主动终止事务，避免错误覆盖。 - 将全部产品合格率工位菜单的 `pid` 更新为 `4`。 - 保留路由和组件配置，并统一启用状态、模块代码和操作时间。 - 使用事务和 `XACT_ABORT` 保证迁移原子性。 7. 使用 `sqlcmd` 将增量脚本发布到 `192.168.2.92 / YL_MESDB`，执行成功： - 11 条目标菜单全部更新为 `pid=4`。 - 5 个缺失质量管理根菜单的账号已补齐父菜单。 8. 检查旧初始化脚本，发现已有记录重复执行时不会修改 `pid`，但以后为新账号创建菜单时仍可能放回生产管理。 9. 修改 `db_backups/add_product_pass_rate_workstation_menu_20260630.sql`： - 父菜单解析由生产管理改为质量管理。 - 仅在账号存在质量管理根菜单时创建目标菜单。 - 更新已有目标菜单时同步将 `pid` 调整为对应质量管理根菜单 ID。 10. 在目标数据库重复执行修改后的旧初始化脚本，脚本执行成功，11 条目标菜单仍全部保持 `pid=4`，验证不会回退到生产管理。 11. 首次执行最终一致性查询时，第一项统计已返回 11 条全部迁移成功，但后续语句因误将 CTE 跨多条 SQL 语句复用而报“对象名 Targets 无效”；该错误只发生在只读校验查询中，不影响此前已提交的迁移事务。 12. 将校验查询改为表变量后重新执行，完整验证通过： - 目标菜单总数：11。 - 质量管理下数量：11。 - 生产管理残留数量：0。 - 启用数量：11。 - 缺失质量管理父菜单数量：0。 - 单账号重复目标菜单数量：0。 13. 执行 `git diff --check` 检查脚本差异，未发现空白错误。 ### 修改文件 - `db_backups/move_product_pass_rate_workstation_to_quality_menu_20260711.sql` - `db_backups/add_product_pass_rate_workstation_menu_20260630.sql` - `gptlog-process/gpdlog.md` ### 结论 - 产品合格率工位页面已经从生产管理菜单迁移到质量管理菜单。 - 页面组件仍保留在 `ProductionManagement/ProductPassRateWorkstation/index`，只调整数据库菜单层级。 - 当前已有该页面权限的 11 个账号均可通过质量管理菜单访问，原来缺少质量管理根菜单的账号已补齐父菜单。 - 旧初始化脚本已同步修正，后续重复部署不会将该页面重新放回生产管理。 ### 验证结果 - 数据库增量脚本发布成功。 - 修改后的旧初始化脚本重复执行成功。 - 11 条目标菜单全部为 `pid=4`，生产管理残留为 0。 - 缺失父菜单和重复菜单均为 0。 - `git diff --check` 通过。 ## 2026-07-11 上传全部修改到远程 ### 用户提问 - 用户要求把当前所有修改上传到远程仓库。 ### 执行过程 1. 检查 Git 工作区，确认待上传修改包括： - `src/views/ProductionManagement/DesignReportTask/HoursReport/index.vue`：设计工时报表 Excel 导出功能。 - `db_backups/move_product_pass_rate_workstation_to_quality_menu_20260711.sql`：产品合格率工位菜单迁移增量脚本。 - `db_backups/add_product_pass_rate_workstation_menu_20260630.sql`：旧菜单初始化脚本改为使用质量管理父菜单。 - `gptlog-process/gpdlog.md`：对应任务的中文执行日志。 2. 确认当前分支为 `snapshot/local-save-20260625-154806`，跟踪远端分支 `origin/snapshot/local-save-20260625-154806`。 3. 检查待提交内容，确认没有构建产物或其他临时文件。 4. 执行 `git diff --check`，未发现空白错误。 5. 执行 `git fetch origin` 刷新远端状态。 6. 首次统计本地与远端分叉时，PowerShell 将未加引号的 `@{u}` 解析为自身语法，导致 Git 收到错误参数；给修订参数加引号后重新执行成功。 7. 正确的分叉统计结果为 `0 0`，本地提交和远端提交在上传前完全同步，没有分叉。 8. 对已跟踪差异和未跟踪文件执行数据库密码及常见凭据特征扫描，匹配数量均为 0，确认用户提供的数据库明文密码未写入待上传文件。 9. 暂存三个功能文件并执行 `git diff --cached --check`，检查通过。 10. 创建功能提交： - 提交号：`0784746` - 提交信息：`feat: 增加工时报表导出并调整质量菜单` - 变更统计：3 个文件，新增 244 行，删除 7 行。 11. 将本次上传过程追加到 `gptlog-process/gpdlog.md`，创建独立日志提交。 12. 执行 `git push`，将功能提交和日志提交一起推送到 `origin/snapshot/local-save-20260625-154806`。 13. 推送后重新检查本地与远端提交差异及工作区状态，确认远端已包含全部修改。 ### 结论 - 当前工作区内的设计工时报表导出、产品合格率工位菜单迁移、旧菜单脚本修正和对应中文日志已全部提交并上传到远程。 - 功能提交号为 `0784746`。 ### 验证结果 - `git diff --check` 通过。 - `git diff --cached --check` 通过。 - 凭据特征扫描结果为 0。 - 上传前本地与远端分叉为 `0 0`。 - 推送后本地与远端同步，工作区无未提交修改。 ## 2026-07-15 设计报工限制、重复报工及多类说明功能 ### 用户提问 - 修改 `src/views/ProductionManagement/DesignReportTask/Report/index.vue`：一个人不能同时开始多个任务，点击开始时提示哪个任务未关闭。 - 任务点击完成后仍允许再次开始和结束，第二次开始、结束后也可以再次完成。 - 增加“异常说明”和“奇思妙想”功能，允许随时多次录入文字；列表按“时间换行内容”的格式显示，多次录入显示多条。 - “进度说明”采用与异常说明相同的列表显示格式。 - 将“未结束人员”改名为“设计正在对应”。 - 在设计任务页面同时显示异常说明、奇思妙想、进度说明和设计正在对应字段。 ### 执行过程 1. 读取仓库根目录 `AGENTS.md`，确认本次执行结束后必须将提问、结论和完整执行过程以中文追加到 `gptlog-process/gpdlog.md`。 2. 检查目标报工页、设计任务页、校验页、工时报表页、相关 SQL 增量脚本、项目命令和 Git 工作区状态。 3. 确认报工页原有逻辑只校验当前行的 `当前用户未结束报工数`，无法可靠阻止同一人员跨任务同时开始；前后端还把“已完成”作为禁止重新开始的终态。 4. 确认原有结束弹窗已经可以录入进度说明，数据库报工记录也已有对应字段，但任务查询和两个任务列表尚未聚合显示进度历史。 5. 确认异常说明和奇思妙想没有独立数据表及保存过程，不能仅靠前端完成持久化和多条历史展示，因此确定增加幂等数据库增量脚本。 6. 检查工作区已有改动，发现设计任务页存在用户未提交的表单布局调整，质量检验页面也存在无关修改；本次保留所有已有改动，只在设计任务页追加所需列表字段，并对该页原有布局改动做必要的空格格式整理。 7. 修改报工页列表： - 将“未结束人员”列标题改为“设计正在对应”，继续使用原有 `未结束报工人员` 返回字段。 - 新增进度说明、异常说明和奇思妙想三列。 - 三列使用保留换行的样式展示历史内容。 8. 修改报工页操作区： - “开始”按钮不再因任务已完成而禁用。 - 新增“异常说明”和“奇思妙想”两个文字按钮。 - 新增通用说明录入弹窗，显示 DID 和任务描述，内容必填，最多 2000 字。 - 保存时调用新增存储过程，并携带当前操作人 ID 和姓名。 9. 增加开始前全任务实时查询：如果当前人员已有任何未结束记录，提示“任务 DID + 任务描述尚未关闭，请先结束该任务”；查询失败时阻止开始，避免绕过校验。 10. 保留结束按钮仅在当前任务存在本人未结束记录时启用；已完成任务重新开始后状态变为执行中，结束后变为已结束，因此可以再次点击完成。 11. 修改设计任务页列表，新增“设计正在对应”、进度说明、异常说明和奇思妙想四列，展示格式与报工页一致。 12. 新增 `db_backups/update_design_report_task_notes_and_restart_20260715.sql`： - 幂等补齐报工记录的进度说明字段。 - 新建 `MES_设计报工_任务说明` 表，保存异常说明和奇思妙想的多条记录、操作人及录入时间。 - 新建 `设计报工_任务说明_新增` 保存过程，校验任务、说明类型和非空内容。 - 重建 `设计报工_任务_查询`，聚合进度说明、异常说明和奇思妙想，单条格式为“时间 + 换行 + 内容”，多条之间留空行。 - 重建设计报工开始过程，取消已完成任务禁止开始的限制。 - 开始过程使用按人员标识生成的 `sp_getapplock` 事务锁，防止两个页面并发点击时同时产生两条未结束记录。 - 开始过程跨全部任务检查当前人员的未结束记录，返回未关闭 DID 和任务描述。 - 重建设计报工结束过程，允许重新开始后的任务结束，并按现有方式保存本轮进度说明。 13. 首次执行两目标页面 ESLint 时，报工页无错误；设计任务页报告用户原有布局调整中的多余空格、空行和异步箭头函数格式问题。 14. 对设计任务页做最小格式整理后，再次执行两目标页面 ESLint，检查通过；仅输出项目依赖的 Browserslist 和 Baseline 数据过期提示。 15. 对三个目标文件执行 `git diff --check`，检查通过；全工作区检查仍能看到无关的 `OtherInbound.vue` 原有尾随空格，本次没有修改该文件。 16. 执行 `npm run build`，webpack 生产构建成功；仅有项目原有的大资源体积警告和浏览器兼容数据过期提示，构建没有留下受版本控制的 `dist` 改动。 17. 尝试使用当前 Windows 集成身份对目标数据库 `192.168.2.92 / YL_MESDB` 做只读连通性检查，服务器拒绝 Guest 身份登录；未猜测或查找数据库凭据，也未向目标数据库发布脚本。 18. 检查本地开发服务，确认进程来自当前仓库，访问 `https://localhost:1997/` 返回 HTTP 200。 19. 为验证 SQL，在独立 LocalDB 测试实例中创建最小基础表。前两次使用 PowerShell 标准输入传递中文 SQL 时发生代码页解析错误，均未进入增量脚本有效验证；每次都在 `finally` 中删除测试实例，随后核对并清理由第一次测试生成的 MDF/LDF 文件。 20. 改用 UTF-8 SQL 测试夹具和 `sqlcmd -i -f 65001` 重跑隔离测试，增量脚本编译及业务场景验证通过： - 状态为已完成的任务可以重新开始。 - 同一人员未结束第一项任务时开始第二项任务，被正确拦截并返回第一项任务的 DID 和描述。 - 第一项任务可以正常结束并保存进度说明，状态回到已结束。 - 连续保存两条异常说明和一条奇思妙想均成功。 - 任务查询按要求返回进度说明、两条异常说明和奇思妙想的“时间换行内容”历史。 21. 验证结束后删除临时 SQL 测试夹具、LocalDB 实例及测试数据文件，确认不保留测试数据。 22. 最终检查目标文件状态和差异，确认未修改用户无关的质量检验页面，未提交或推送任何文件。 ### 修改文件 - `src/views/ProductionManagement/DesignReportTask/Report/index.vue` - `src/views/ProductionManagement/DesignReportTask/Task/index.vue` - `db_backups/update_design_report_task_notes_and_restart_20260715.sql` - `gptlog-process/gpdlog.md` ### 结论 - 同一人员只能保留一个未结束的设计报工任务，前端会提示具体未关闭任务，数据库事务锁同时保证并发场景不会绕过限制。 - 已完成任务可以重新开始、结束，并在新一轮结束后再次完成。 - 异常说明和奇思妙想支持在任意任务状态下多次录入；进度说明、异常说明和奇思妙想均按“时间换行内容”显示多条历史。 - 报工页和设计任务页都已显示进度说明、异常说明、奇思妙想和“设计正在对应”。 - 前端代码和数据库增量脚本均已在本机验证；由于当前身份没有目标 SQL Server 登录权限，增量脚本尚未发布到目标数据库，目标环境启用新功能前必须执行该脚本。 ### 验证结果 - 两目标页面 ESLint 检查通过。 - 三个目标文件 `git diff --check` 通过。 - `npm run build` 生产构建通过。 - 隔离 LocalDB 中增量脚本编译通过，重新开始、跨任务拦截、结束及多条说明聚合场景验证通过。 - `https://localhost:1997/` 返回 HTTP 200，本地开发服务保持运行。 ## 2026-07-15 发布设计报工增量脚本到目标数据库 ### 用户提问 - 用户提供目标数据库地址 `192.168.2.92`、数据库管理员账号及密码，要求继续完成数据库发布。 - 按安全要求，本日志不记录数据库明文密码。 ### 执行过程 1. 使用用户提供的 SQL Server 凭据连接 `192.168.2.92 / YL_MESDB`，先执行只读预检。 2. 预检确认目标数据库为 `YL_MESDB`，服务器为 `YLLT-MES`，数据库兼容级别为 150。 3. 确认 `MES_设计报工_任务`、`MES_设计报工_记录` 和记录表的 `进度说明` 字段已经存在；`MES_设计报工_任务说明` 表和 `设计报工_任务说明_新增` 过程尚不存在。 4. 确认设计报工查询、开始、结束、完成过程均存在，其中查询和开始过程仍为本次修改前的旧版本。 5. 使用 `sqlcmd` 的失败即退出模式和 UTF-8 输入模式执行 `db_backups/update_design_report_task_notes_and_restart_20260715.sql`，脚本发布成功。 6. 发布后检查数据库对象定义，确认： - 任务说明表已创建。 - 任务说明保存过程已创建。 - 开始过程已包含 `sp_getapplock` 人员并发锁。 - 查询过程已包含异常说明、奇思妙想和进度说明聚合。 - 开始过程已移除“任务已完成，不能开始”的旧限制。 7. 在目标数据库外层事务中插入两条临时设计任务，执行完整业务验证： - 状态为已完成的第一条任务开始成功。 - 同一测试人员在第一条任务未结束时开始第二条任务，被正确拦截，返回第一条任务 DID 和任务描述。 - 第一条任务结束成功并保存第一轮进度，随后完成成功。 - 第一条任务第二次开始、结束并保存第二轮进度，随后再次完成成功。 - 连续新增两条异常说明和一条奇思妙想，三次保存均成功。 - 任务查询返回两次报工记录、最终已完成状态、两轮进度说明、两条异常说明和一条奇思妙想；显示内容符合“时间换行内容”的多条格式。 8. 回滚外层测试事务，并查询确认名称以 `Codex发布验证_` 开头的测试任务数量为 0，没有向正式库遗留测试任务、报工记录或说明记录。 9. 检查本地工作区，数据库发布没有生成新的临时文件或构建产物；保留用户原有的无关工作区修改。 ### 结论 - `update_design_report_task_notes_and_restart_20260715.sql` 已成功发布到 `192.168.2.92 / YL_MESDB`。 - 同一人员跨任务同时开始限制、未关闭任务提示、已完成任务重新开始和再次完成、进度说明历史、异常说明及奇思妙想多条录入功能均已在目标数据库验证通过。 - 验证数据已全部回滚，正式数据库无测试数据残留。 ### 验证结果 - 数据库对象和过程定义检查通过。 - 两轮“开始、结束、完成”验证通过。 - 跨任务重复开始拦截验证通过。 - 多条进度、异常说明和奇思妙想聚合验证通过。 - 回滚后测试任务数量为 0。 ## 2026-07-15 设计报工按钮、说明悬停及任务可见范围调整 ### 用户提问 - 设计报工点击开始后，当前任务的开始按钮应变为灰色且不可点击。 - 进度说明、异常说明和奇思妙想在列表正常显示时应单行省略，避免撑高行高；鼠标悬停对应字段时显示完整内容。 - 设计任务新建弹窗需在指派对象前增加“对齐可见”字段，并使用与指派对象相同的人员多选方式。 - 设计报工页面根据登录账号限制任务范围，只显示本人创建、对齐可见包含本人以及指派对象包含本人的任务。 ### 执行过程 1. 重新检查报工页和设计任务页现有模板、数据模型、人员查询、任务新增/编辑参数及目标数据库过程结构。 2. 检查登录流程和 Vuex 用户状态，确认登录态 `id` 来源于 `Personnel_Number`，与设计任务人员选择器使用的 `人员编号`一致，可以直接用于对齐可见和指派对象精确匹配。 3. 调整设计报工开始按钮： - 恢复 `canStart` 行级判断。 - 当前行 `当前用户未结束报工数` 大于 0 时开始按钮禁用并显示为灰色。 - 其他任务的开始按钮仍可点击，继续保留提示具体未关闭任务的逻辑。 4. 调整报工页和设计任务页的三类说明展示： - 进度说明、异常说明和奇思妙想正常状态使用单行、溢出隐藏和省略号，不再撑高表格行。 - 每个字段外层增加 Element UI Tooltip，非空内容悬停时显示完整历史。 - Tooltip 内容保留原有换行，设置最大宽度、最大高度、自动纵向滚动和长文本换行。 5. 在设计任务列表增加“对齐可见”列，便于维护人员直接确认任务可见范围。 6. 在设计任务新增/编辑弹窗的“指派对象”之前增加“对齐可见”多选人员字段： - 使用独立的远程人员选项集合，避免与指派对象搜索互相覆盖。 - 保存人员编号列表到 `对齐可见ID`，保存人员姓名列表到 `对齐可见`。 - 编辑时还原已选人员，并补齐当前远程列表中不存在的已选项。 - 每次打开新建弹窗时刷新对齐可见人员列表。 7. 扩展数据库增量脚本： - 幂等增加任务表 `对齐可见ID` 和 `对齐可见` 两个字段。 - 查询过程返回两个新字段。 - 重建任务新增和编辑过程，支持保存及修改对齐可见人员。 - 仅当查询传入当前登录人员时应用报工页可见范围；不传人员的设计任务维护页继续返回全部任务。 8. 第一版可见范围按用户最初要求实现为“本人创建或对齐可见包含本人”。用户随后补充“指派对象的任务也可见”，立即终止正在进行的旧版本构建，避免把不完整版本作为最终验证结果。 9. 将查询可见范围扩展为三种关系的并集： - 当前人员姓名等于创建人。 - 当前人员编号或姓名存在于对齐可见列表。 - 当前人员编号或姓名存在于指派对象列表。 10. 使用隔离 LocalDB 对第一版字段和查询规则进行验证： - 不传当前人员时维护页返回全部三条任务。 - 创建人只能看到本人创建任务。 - 同时具有创建和对齐关系的人员返回两条任务。 - 仅对齐可见人员返回对应任务。 - 无任何关系人员返回 0 条。 - 编辑对齐可见后，新人员立即能查询到任务，并返回对齐可见字段。 11. 用户补充指派对象规则后，再次使用隔离 LocalDB 验证： - 指派对象列表包含当前人员时能返回对应任务。 - 无创建、对齐或指派关系的人员返回 0 条。 12. 两次 LocalDB 验证均使用独立临时实例；验证后删除 SQL 测试夹具、实例及 MDF/LDF 文件，没有遗留测试资源。 13. 执行两目标页面 ESLint，检查通过；仅输出项目依赖的 Browserslist 和 Baseline 数据过期提示。 14. 对目标前端文件和数据库脚本执行 `git diff --check`，检查通过。 15. 执行 `npm run build`；用户补充指派对象规则前的构建被主动终止，补齐最终规则后重新执行生产构建并成功通过，仅有项目原有的大资源体积及浏览器数据过期警告。 16. 使用用户此前提供的数据库凭据，将扩展后的幂等脚本重新发布到 `192.168.2.92 / YL_MESDB`，发布成功；日志不记录明文密码。 17. 在目标数据库检查确认： - 两个对齐可见字段已经存在。 - 查询过程包含指派对象可见逻辑。 - 新增和编辑过程均包含对齐可见参数。 18. 在目标数据库外层事务中执行正式环境验证： - 本人创建任务查询返回 1 条。 - 对齐可见任务查询返回 1 条。 - 指派对象任务查询返回 1 条。 - 无关系人员查询返回 0 条。 - 不传人员的设计任务维护查询仍返回指定任务。 19. 回滚目标数据库测试事务，确认 `Codex可见验证_` 测试任务残留数量为 0。 20. 最终再次执行 ESLint、生产构建、目标文件空白检查和本地开发服务访问检查，全部通过；`https://localhost:1997/` 返回 HTTP 200。 ### 修改文件 - `src/views/ProductionManagement/DesignReportTask/Report/index.vue` - `src/views/ProductionManagement/DesignReportTask/Task/index.vue` - `db_backups/update_design_report_task_notes_and_restart_20260715.sql` - `gptlog-process/gpdlog.md` ### 结论 - 当前人员开始任务后，该任务行的开始按钮会立即在刷新后变灰并不可点击；其他任务仍可点击并提示未关闭任务。 - 三类说明列表保持单行省略，悬停可查看保留换行的完整内容，不再导致表格行高过高。 - 设计任务新增和编辑弹窗已支持“对齐可见”人员多选，并在列表显示选中人员。 - 设计报工页面只显示本人创建、对齐可见包含本人或指派对象包含本人的任务；设计任务维护页仍显示全部任务。 - 数据库字段和过程已发布到目标库，正式环境事务验证通过且无测试数据残留。 ### 验证结果 - 两目标页面 ESLint 检查通过。 - 目标文件 `git diff --check` 通过。 - 最终 `npm run build` 生产构建通过。 - 隔离 LocalDB 的新增、编辑、创建人可见、对齐可见和指派可见场景通过。 - 目标数据库三类可见关系及维护页全量查询验证通过。 - 目标数据库回滚后测试任务数量为 0。 - `https://localhost:1997/` 返回 HTTP 200。 ## 2026-07-15 上传当前全部修改到远程仓库 ### 用户提问 - 用户要求将当前工作区的所有修改上传到远程仓库。 ### 执行过程 1. 检查 Git 工作区、当前分支、跟踪分支和远程地址，确认当前分支为 `snapshot/local-save-20260625-154806`，跟踪 `origin/snapshot/local-save-20260625-154806`。 2. 确认待上传内容共 7 个文件： - 设计报工前端两个页面。 - 设计报工数据库增量脚本。 - 及时齐套跟踪结果数据库脚本。 - 其他入库检验页面。 - 销售退货检验页面。 - 中文执行日志。 3. 检查差异统计：暂存后共新增 1200 行、删除 79 行；设计报工数据库脚本为新增文件，其余 6 个文件为修改文件。 4. 执行 `git diff --check`，首次发现 `OtherInbound.vue` 新增差异中存在一行尾随空白；使用最小编辑删除空白，不改变质量检验业务逻辑。 5. 再次执行全工作区和暂存区空白检查，均通过；仅输出 Git 对部分文件未来行尾转换的提示。 6. 对已跟踪差异和未跟踪数据库脚本执行数据库密码、`SQLCMDPASSWORD` 及常见密码参数特征扫描，结果均无命中；用户提供的数据库明文密码未写入任何待上传文件。 7. 执行 `git fetch origin` 刷新远程状态。 8. 比较本地与远程提交，分叉结果为 `0 0`；上传前本地 HEAD 和远程跟踪分支均为 `9e58193`，不存在远程新提交或本地未推送提交。 9. 对 4 个修改页面执行 ESLint： - 两个设计报工页面检查通过，仅有项目依赖数据过期提示。 - 两个质量检验页面因文件原有双引号、分号、模板换行、缩进和未定义全局函数等旧代码风格，报告大量存量规则错误。 - 未使用自动修复重写近千行用户代码，避免产生与本次功能无关的大范围格式变更。 10. 采用此前已完成的最终生产构建作为质量检验页面的编译验证；该构建包含本次全部前端改动并成功通过，仅有项目原有的大资源体积和浏览器数据过期警告。 11. 确认设计报工数据库脚本已在隔离 LocalDB 和目标数据库验证通过，及时齐套脚本已在目标数据库针对销售订单 `261079`、生产订单 `7912` 验证通过。 12. 检查本地开发服务，`https://localhost:1997/` 返回 HTTP 200；生产构建没有留下受版本控制的 `dist` 改动。 13. 执行 `git add -A` 暂存当前全部修改，并复核暂存区确实包含全部 7 个文件。 14. 对暂存区再次执行 `git diff --cached --check` 和凭据特征扫描，检查通过。 15. 创建功能提交： - 提交号：`38771ef` - 提交信息：`feat: 完善设计报工、质检及齐套跟踪` - 变更统计：7 个文件，新增 1200 行，删除 79 行。 16. 执行 `git push origin snapshot/local-save-20260625-154806`，功能提交成功推送到远程，远程分支从 `9e58193` 更新到 `38771ef`。 17. 功能提交推送成功后，按仓库 `AGENTS.md` 要求追加本条完整中文上传过程日志，并将通过独立日志提交继续同步到同一远程分支。 ### 结论 - 用户要求的当前全部业务修改已经创建提交并成功上传到远程分支。 - 功能提交号为 `38771ef`。 - 数据库明文密码没有进入提交内容。 - 本条上传过程日志将通过后续独立提交同步到远程，确保工作区最终无未提交修改。 ### 验证结果 - 上传前本地与远程分叉为 `0 0`。 - 全工作区和暂存区 `git diff --check` 通过。 - 暂存区凭据特征扫描无命中。 - 两个设计报工页面 ESLint 通过。 - 最终生产构建通过。 - 功能提交已成功推送至远程。 ## 2026-07-16 发货状态列表增加订单及生产数量字段 ### 用户提问 - 用户要求修改 `ProductionManagement/DeliveryNoticeList/index`，增加订单数量（取计划数量）、入库数量、完成数量和合格数量四个字段。 ### 执行过程 1. 从当前工作目录及元利相关项目中搜索目标路径，定位实际文件为 `C:\WorkYuanLy\MES_Manage_View_V20\src\views\ProductionManagement\DeliveryNoticeList\index.vue`。 2. 检查目标页面现有实现，确认列表通过存储过程 `装配中心任务看板_发货状态查询` 获取数据并直接赋值给 `tableData`，现有“数量”列使用 `交货数量 || 计划数量`，页面已有统一的 `formatQuantity` 数量格式化方法。 3. 搜索项目内相同字段的使用方式，确认中文字段可以直接通过 `scope.row` 访问；检查项目依赖和构建命令，确认项目为 Vue 2、Element UI 和 Webpack 5。 4. 读取仓库根目录 `AGENTS.md`，确认每次执行后必须将提问、结论和完整执行过程以中文追加到 `gptlog-process/gpdlog.md`。 5. 修改目标列表： - 将原“数量”列调整为“订单数量”，固定读取 `计划数量`。 - 新增“入库数量”列，读取 `入库数量`。 - 新增“完成数量”列，读取 `完成数量`。 - 新增“合格数量”列，读取 `合格数量`。 - 四列均复用 `formatQuantity`，统一处理空值、整数和小数显示。 6. 使用文本检索复核目标页面，确认四个列名和对应字段均已写入，原“交货数量或计划数量”的混合显示逻辑已移除。 7. 首次执行 `npm run build` 时，构建超过 180 秒工具超时；期间只输出 Baseline、Browserslist 数据过期提示，没有模板或代码错误，超时进程随后已终止。 8. 使用更长超时重新执行 `npm run build`，Webpack 在约 40 秒内成功完成生产构建。 9. 构建仅保留项目原有的大体积字体、图片、第三方库、入口文件体积警告，以及 Baseline、Browserslist 数据过期提示；没有新增编译错误。 10. 按仓库要求在本日志末尾追加本次完整中文执行记录，未修改或覆盖已有历史日志。 ### 修改文件 - `src/views/ProductionManagement/DeliveryNoticeList/index.vue` - `gptlog-process/gpdlog.md` ### 结论 - 发货状态列表现在包含订单数量、入库数量、完成数量和合格数量四个独立字段。 - 订单数量严格读取后端返回的 `计划数量`，不再与 `交货数量` 混用。 - 查询请求和筛选条件保持不变，四个字段直接使用现有存储过程返回值。 ### 验证结果 - 目标文件字段检索检查通过。 - `npm run build` 生产构建通过。 - 仅存在项目原有的资源体积及依赖数据过期警告，无编译错误。 ## 2026-07-15 设计工时报表增加任务工时页签 ### 用户提问 - 用户指定修改 `src/views/ProductionManagement/DesignReportTask/Report/index.vue`，说明当前页面为按日期和人员计算的工时报表。 - 要求在同一页面新增一个按 DID 计算的工时报表，顶部页签切换方式参考 `ProductionManagement/Timesheet/index`。 - 原报表命名为“作业者工时”，新增报表命名为“任务工时”。 ### 执行过程 1. 检查用户指定的 `Report/index.vue`、设计报工模块全部页面、菜单脚本、项目文档及参考页面 `ProductionManagement/Timesheet/index.vue`。 2. 确认用户描述的按日期和人员计算报表实际位于 `src/views/ProductionManagement/DesignReportTask/HoursReport/index.vue`，菜单名为“设计工时报表”；指定的 `Report/index.vue` 实际是设计报工开始、结束、完成操作页。 3. 根据菜单路由和业务意图，选择修改正确的 `HoursReport/index.vue`，避免把报工操作页面误改成工时报表。 4. 阅读参考 Timesheet 页面“作业者工时”和“任务工时”页签、查询切换、树形数据组装及导出逻辑。 5. 检查现有设计作业者工时查询过程 `设计报工_工时报表_作业者工时_查询`，确认现有结构为操作人→工作日期→报工明细三级树。 6. 查询目标数据库现有设计报工记录和现有报表返回结果，确认筛选参数、字段类型、工时秒数、校验状态、进度说明及备注的数据口径。 7. 修改 `HoursReport/index.vue`： - 增加 Element UI 顶部页签，名称为“作业者工时”和“任务工时”。 - 默认显示“作业者工时”，保留原有人员→日期→明细三级树和全部字段。 - 新增“任务工时”表格，使用 DID→操作人两级树。 - DID 根节点显示任务描述、项目号、物料、图号、类别、报工次数、总工时、最早开始、最晚结束和综合校验状态。 - 操作人子节点显示该人员在当前 DID 上的报工次数、工时、起止时间、校验状态、进度说明和备注。 - 两个页签共用开始日期、结束日期、操作人、项目号、物料编码、类别和 DID 筛选条件。 - 点击页签时查询对应报表过程。 - 底部总工时根据当前页签根节点动态计算。 - 导出按钮根据当前页签导出对应树形数据，工作表和文件名分别使用“作业者工时”或“任务工时”。 8. 新增数据库脚本 `db_backups/add_design_report_task_hours_report_20260715.sql`，创建过程 `设计报工_工时报表_任务工时_查询`。 9. 新过程沿用原作业者工时的全部筛选条件，只统计已正常结束的设计报工记录，并按 DID 汇总根节点、按 DID 和操作人汇总子节点。 10. 新过程对每个汇总层计算报工次数、工时小时、最早开始时间、最晚结束时间；校验状态区分“已校验”“未校验”“部分校验”；进度说明按结束时间和内容聚合，备注同步聚合。 11. 执行前端单文件 ESLint 和目标差异空白检查，均通过；仅输出项目依赖的 Browserslist 和 Baseline 数据过期提示。 12. 在独立 LocalDB 测试实例中创建最小任务和报工表，执行新过程脚本并插入两个人员共同报工同一 DID 的测试数据。 13. 隔离验证结果：DID 10 根节点汇总 2 次、1.50 小时、状态“部分校验”；张三子节点 1 次、1.00 小时、已校验；李四子节点 1 次、0.50 小时、未校验；任务及人员的进度说明和备注聚合正确。 14. 删除 LocalDB 测试夹具、测试实例及 MDF/LDF 文件，确认没有临时测试资源残留。 15. 执行 `npm run build`，生产构建成功；仅有项目原有的大资源体积和浏览器兼容数据过期警告，未生成受版本控制的 `dist` 变更。 16. 使用用户此前提供的数据库凭据，将 `add_design_report_task_hours_report_20260715.sql` 发布到 `192.168.2.92 / YL_MESDB`；日志不记录明文密码。 17. 在目标库创建新过程成功，修改时间为 `2026-07-15 18:14:19`。 18. 使用临时表只读接收目标库作业者工时和任务工时两个过程的完整返回结果，交叉核对真实数据： - 两个报表统计的已结束报工次数均为 30。 - 任务工时根节点与人员子节点结构正确。 - 多人任务 DID 1 汇总为 3 次、0.02 小时；子节点为超级管理员 2 次、张一帆 1 次。 - 两种报表按不同维度分别先保留两位小数，跨全部分组求和存在 0.01 至 0.02 小时累计舍入差，属于分组舍入口径差异，不影响单个 DID 汇总。 19. 最终再次执行 HoursReport 页面 ESLint、目标文件 `git diff --check`、数据库对象检查和本地服务检查，均通过；`https://localhost:1997/` 返回 HTTP 200。 ### 修改文件 - `src/views/ProductionManagement/DesignReportTask/HoursReport/index.vue` - `db_backups/add_design_report_task_hours_report_20260715.sql` - `gptlog-process/gpdlog.md` ### 结论 - 设计工时报表现在同一页面提供“作业者工时”和“任务工时”两个顶部页签。 - 原作业者工时功能、筛选条件和三级树结构保持不变。 - 新任务工时按照 DID 汇总，并可展开查看每位操作人的工时贡献。 - 查询、总工时和 Excel 导出都会随当前页签切换。 - 新任务工时查询过程已经发布到目标数据库并通过真实数据验证。 ### 验证结果 - HoursReport 单文件 ESLint 通过。 - 目标文件 `git diff --check` 通过。 - 隔离 LocalDB 的 DID 及人员汇总验证通过。 - `npm run build` 生产构建通过。 - 目标数据库过程发布成功。 - 目标库真实数据中两个报表的已结束报工次数均为 30，多人 DID 展开结构正确。 - 本地开发服务返回 HTTP 200。 ## 2026-07-15 修复及时齐套生产订单 7912 工艺路线颜色 ### 用户提问 - 修改 `PlanManagement/TimelyKitTrackingResult/index`。 - 搜索销售订单 `261079` 后展开子项，生产订单 `7912` 的工艺路线状态不正确。 - 第 4 序已经完成 5 个，应显示蓝色；第 5 序已经发料，应显示绿色。 - 要求参考“生产计划跟踪”页面搜索生产订单 `7912` 时的工艺路线。 ### 执行过程 1. 检查 `src/views/PlanManagement/TimelyKitTrackingResult/index.vue`、参考页面 `src/views/ProductionManagement/ProductionPlanTrack/index.vue`、及时齐套查询脚本和原项目验收文档。 2. 对比两页的工艺路线前端算法，确认蓝色、绿色、红色判断和连续外协分组处理逻辑完全一致： - 收检合格数大于 0、报工或辅助结束显示蓝色。 - 外协工序收料数大于收检合格数与不合格数之和时显示绿色。 - 连续且 `外协分组` 相同的工序统一采用该组最后一道工序的颜色。 3. 确认及时齐套页面不直接计算数据库状态，而是解析 `生产管理_及时齐套跟踪结果_查询` 返回的 `工艺路线明细` JSON 后着色。 4. 查询目标数据库过程参数和生产订单 `7912` 的 `View_生产订单_MES` 原始工序数据。首次查询误用了视图不存在的 `开始时间` 字段而失败，删除该字段后重新查询成功。 5. 原始数据确认： - 第 4 序数铣，计划数 5、完成数 5、收料数 5、收检合格数 5，任务状态为已完成，应显示蓝色。 - 第 5 序调质，收料数 5、收检数 0、任务状态为已开工，应显示绿色。 - 第 6 序喷砂尚未开始，应显示红色。 6. 执行参考过程 `生产管理_生产计划跟踪` 查询订单 `7912`，确认参考数据包含 `外协分组`： - 第 2 至第 4 序的外协分组为空，属于同一连续组，跟随第 4 序显示蓝色。 - 第 5 序外协分组为 2，独立显示绿色。 - 第 6 序外协分组为 3，独立显示红色。 7. 执行及时齐套查询过程查询销售订单 `261079`。首次命令同时使用了互斥的 `sqlcmd -W` 与 `-y` 选项而失败，修正选项后重新执行成功。 8. 检查及时齐套对生产订单 `7912` 的实际返回 JSON，确认完成数、收料数、收检数均正确，但每道工序都缺少 `外协分组` 字段。 9. 定位根因：前端把缺少分组字段的第 2 至第 6 序全部视为同一个连续外协组，最终全部跟随第 6 序显示红色；因此不是页面蓝绿基础判断错误，而是后端 JSON 字段缺失。 10. 修改当前最新及时齐套过程脚本 `db_backups/update_timely_kit_tracking_result_multi_detail_orders_20260630.sql`，在 `工艺路线明细` JSON 中增加 `p2.[外协分组]`。 11. 发布前执行差异和空白检查，确认脚本只增加一个返回字段，不改变筛选、缺件匹配或其他统计口径；目标库当前过程定义检查结果为确实缺少该字段。 12. 使用用户此前提供的数据库凭据，将修改后的过程脚本发布到 `192.168.2.92 / YL_MESDB`；日志不记录明文密码。 13. 发布后重新执行销售订单 `261079` 的及时齐套查询，从实际过程输出中提取生产订单 `7912` 的工艺路线 JSON，并按页面当前算法复算： - 第 4 序数铣：外协第一组，收检合格 5，最终颜色为蓝色。 - 第 5 序调质：外协分组 2，收料 5、收检 0，最终颜色为绿色。 - 第 6 序喷砂：外协分组 3，未收料未收检，最终颜色为红色。 14. 检查目标数据库过程定义，确认 `p2.[外协分组]` 已发布。 15. 执行及时齐套页面 ESLint，检查无错误，仅保留页面原有 `v-html` 安全规则警告和项目依赖数据过期提示。 16. 执行数据库脚本 `git diff --check`，检查通过；访问本地开发服务 `https://localhost:1997/` 返回 HTTP 200。 17. 保留工作区中用户已有的设计报工和质量检验相关修改，本次未改动或回退这些无关文件。 ### 修改文件 - `db_backups/update_timely_kit_tracking_result_multi_detail_orders_20260630.sql` - `gptlog-process/gpdlog.md` ### 结论 - `TimelyKitTrackingResult/index.vue` 的现有颜色算法与生产计划跟踪一致，无需重复修改前端算法。 - 实际问题是及时齐套查询返回的工艺路线 JSON 漏掉 `外协分组`，导致多个不同外协组被错误合并并统一显示红色。 - 字段已补齐并发布到目标数据库；销售订单 `261079`、生产订单 `7912` 现在第 4 序显示蓝色，第 5 序显示绿色，第 6 序显示红色，与生产计划跟踪一致。 ### 验证结果 - 目标数据库原始工序和参考生产计划跟踪数据对比通过。 - 目标过程发布成功，定义中已包含 `p2.[外协分组]`。 - 实际过程返回 JSON 已包含第 5 序分组 2、第 6 序分组 3。 - 使用页面现有算法复算结果为第 4 序蓝色、第 5 序绿色、第 6 序红色。 - 页面 ESLint 无错误，只有原有 `v-html` warning。 - SQL 差异空白检查通过。 - `https://localhost:1997/` 返回 HTTP 200。 ## 2026-07-15 上传设计任务工时报表全部修改到远程仓库 ### 用户提问 - 用户要求将当前工作区中的所有修改上传到远程仓库。 ### 执行过程 1. 检查 Git 工作区、当前分支、跟踪分支和远程状态，确认当前分支为 `snapshot/local-save-20260625-154806`，跟踪 `origin/snapshot/local-save-20260625-154806`。 2. 确认本次待上传内容共 3 个文件： - `src/views/ProductionManagement/DesignReportTask/HoursReport/index.vue`。 - `db_backups/add_design_report_task_hours_report_20260715.sql`。 - `gptlog-process/gpdlog.md`。 3. 复核本次功能验证结果：HoursReport 单文件 ESLint 通过，`npm run build` 生产构建通过，目标文件空白检查通过，独立 LocalDB 汇总测试通过，目标数据库真实数据交叉验证通过，本地开发服务返回 HTTP 200。 4. 对工作区差异执行 `git diff --check`，检查通过。 5. 对已跟踪差异和未跟踪文件执行数据库凭据及常见明文密码特征扫描，检查无命中；用户此前提供的数据库明文密码未写入待上传文件。 6. 检查工作区没有待提交的 `dist` 构建产物或临时测试资源。 7. 执行 `git fetch origin` 刷新远程状态，比较本地和跟踪分支，上传前分叉结果为 `0 0`；本地 HEAD 与远程跟踪分支均为 `4f42c3a`。 8. 执行 `git add -A` 暂存当前全部修改，复核暂存区确实只包含上述 3 个文件，共新增 334 行、删除 50 行。 9. 对暂存区再次执行 `git diff --cached --check` 和凭据特征扫描，均检查通过。 10. 创建功能提交： - 提交号：`9d08fb1`。 - 提交信息：`feat: 增加设计任务工时报表`。 - 变更统计：3 个文件，新增 334 行、删除 50 行。 11. 执行 `git push origin snapshot/local-save-20260625-154806`，功能提交成功推送到远程，远程分支从 `4f42c3a` 更新到 `9d08fb1`。 12. 功能提交推送成功后，按照仓库 `AGENTS.md` 要求追加本条完整中文上传过程日志，并通过独立日志提交继续同步到同一远程分支。 ### 结论 - 设计任务工时报表页签、任务工时数据库过程脚本及此前执行日志已创建功能提交并成功上传到远程分支。 - 功能提交号为 `9d08fb1`。 - 数据库明文密码未进入任何提交内容。 - 本条上传过程日志将通过后续独立提交同步到远程，完成后再次校验本地与远程一致性。 ### 验证结果 - 上传前本地与远程分叉为 `0 0`。 - 工作区和暂存区空白检查通过。 - 暂存区凭据特征扫描无命中。 - HoursReport 页面 ESLint 通过。 - 生产构建通过。 - 独立 LocalDB 和目标数据库查询验证通过。 - 功能提交已成功推送至远程。 ## 2026-07-17 设计任务分类、领导批示及历史记录权限调整 ### 用户提问 - 用户要求修改 `src/views/ProductionManagement/DesignReportTask/Task/index.vue`，将分类改为固定下拉选项：实验、研发、方案评审、售前、订单、确认、售后问题指导、售后物料准备、返修品处理、其他。 - 用户要求任务描述和设计要求只有创建人可以修改。 - 用户要求在设计任务界面和报工界面的操作位置增加作用相同的“领导批示”，并将“领导批示”字段放在两个列表的第一列。 - 用户要求领导批示、异常、奇思妙想、进度按“日期+编辑人，换行，内容”的方式显示，并按倒序排列，第一条为最新内容。 ### 执行过程 1. 读取仓库根目录 `AGENTS.md`，确认必须把提问、结论和完整执行过程以中文追加到 `gptlog-process/gpdlog.md`。 2. 检查设计报工模块的 `Task/index.vue`、`Report/index.vue`、`HoursReport/index.vue`、现有存储过程脚本和当前用户 Vuex 字段，确认设计任务页为任务维护界面，报工页为开始、结束、完成及异常/奇思妙想录入界面。 3. 检查现有数据库脚本 `update_design_report_task_notes_and_restart_20260715.sql`，确认异常说明和奇思妙想存储在 `MES_设计报工_任务说明`，进度说明存储在 `MES_设计报工_记录`；现有聚合缺少编辑人且按正序返回。 4. 检查当前工作区，确认用户已有 `DeliveryNoticeList/index.vue` 和 `gptlog-process/gpdlog.md` 修改；本次保留这些修改，没有覆盖或回退。 5. 修改设计任务页面： - 查询条件“类别”和新建/编辑表单“类别”改为固定选项下拉框。 - 在列表第一列增加固定的“领导批示”列。 - 在操作区增加“领导批示”按钮和录入弹窗，通过统一过程 `设计报工_任务说明_新增` 保存。 - 根据当前登录人员姓名与任务创建人判断编辑权限；非创建人打开编辑弹窗时，任务描述和设计要求禁用。 - 调整领导批示、进度说明、异常说明、奇思妙想的单元格样式，保留日期/编辑人与内容之间的换行，最多显示约四行并可通过提示框查看完整历史。 6. 修改设计报工页面： - 查询条件“类别”使用与任务页面相同的固定下拉选项。 - 在列表第一列增加固定的“领导批示”列。 - 在操作区增加“领导批示”按钮，复用异常说明和奇思妙想的同一录入弹窗及保存过程。 - 同步调整四类历史字段的换行显示样式。 7. 新增数据库迁移 `db_backups/add_design_report_leader_instruction_and_note_history_20260717.sql`： - 将任务说明类型约束扩展为领导批示、异常说明、奇思妙想。 - 扩展 `设计报工_任务说明_新增`，允许保存领导批示。 - 更新 `设计报工_任务_查询`，返回领导批示，并为四类历史内容拼接日期、编辑人、换行和内容。 - 所有历史聚合按业务时间降序、流水号降序排列，时间相同时仍保证后录入内容在前。 - 更新 `设计报工_任务_编辑`，只有最后编辑人与创建人一致时才更新任务描述和设计要求，防止绕过前端直接调用接口越权修改。 8. 执行两个 Vue 文件的 ESLint，检查通过；仅输出项目已有的 Baseline 和 Browserslist 数据过期提示。 9. 执行目标文件 `git diff --check`，检查通过；仅有仓库换行符转换提示，无空白错误。 10. 在本机 SQL Server 2019 LocalDB 创建一次性 `YL_MESDB` 最小测试库，包含任务、报工记录和任务说明三张测试表以及测试数据。 11. 首次执行迁移时发现动态删除检查约束直接拼接 `QUOTENAME` 的写法在 SQL Server 2019 报语法错误；将其改为先生成变量，再通过 `sys.sp_executesql` 执行。 12. 从干净测试库重新执行修正后的迁移，执行成功。 13. 隔离数据库行为验证： - “领导批示”可以通过统一任务说明过程保存。 - 最新领导批示位于较早批示之前，且显示为日期和编辑人后换行显示内容。 - 最新进度位于较早进度之前，并包含报工编辑人。 - 异常说明和奇思妙想同样按最新内容在前返回。 - 非创建人调用任务编辑过程后，任务描述和设计要求保持原值。 - 创建人调用任务编辑过程后，两字段正常更新。 14. 验证结束后删除 LocalDB 测试数据库和两个临时验证脚本，确认没有测试资源残留。 15. 尝试使用当前 Windows 身份连接 `192.168.2.92 / YL_MESDB` 做发布前检查，远端登录超时；未猜测或使用未提供的数据库凭据，因此本次迁移脚本未发布到生产库。 16. 执行 `npm run build`，Webpack 生产构建成功；仅保留项目已有的大资源体积、Baseline 和 Browserslist 数据过期警告，没有编译错误，也没有产生受版本控制的 `dist` 变化。 17. 检查现有本地开发服务，`https://localhost:1997/` 返回 HTTP 200。 18. 按仓库要求追加本条完整中文执行日志，并再次复核工作区差异。 ### 修改文件 - `src/views/ProductionManagement/DesignReportTask/Task/index.vue` - `src/views/ProductionManagement/DesignReportTask/Report/index.vue` - `db_backups/add_design_report_leader_instruction_and_note_history_20260717.sql` - `gptlog-process/gpdlog.md` ### 结论 - 设计任务分类已经改为用户指定的十项固定下拉选项，报工页查询使用同一选项集。 - 设计任务和报工列表的第一列均为领导批示，两个页面都可以通过同一数据库过程录入。 - 领导批示、异常说明、奇思妙想和进度说明统一显示日期、编辑人及换行后的内容，最新记录排在第一条。 - 任务描述和设计要求已经同时受到前端禁用和数据库过程保护，只有创建人可以修改。 - 前端与数据库迁移均已实现并通过本地验证；迁移脚本因生产数据库当前身份登录超时尚未发布。 ### 验证结果 - 两个目标 Vue 文件 ESLint 通过。 - 目标差异空白检查通过。 - SQL Server 2019 LocalDB 迁移执行通过。 - 领导批示保存、四类历史格式及倒序验证通过。 - 创建人和非创建人权限行为验证通过。 - `npm run build` 生产构建通过。 - `https://localhost:1997/` 返回 HTTP 200。 - LocalDB 测试数据库和临时文件已清理。 ## 2026-07-17 发布设计任务领导批示迁移到生产数据库 ### 用户提问 - 用户提供生产数据库 `192.168.2.92` 的 `sa` 账号凭据，用于发布上一项设计任务分类、领导批示、历史记录格式和创建人编辑权限相关数据库迁移。 ### 执行过程 1. 使用用户提供的数据库账号连接 `192.168.2.92 / YL_MESDB`；密码仅通过当前 PowerShell 进程的 `SQLCMDPASSWORD` 环境变量传递，命令结束后立即删除该环境变量，未将密码写入项目文件或本日志。 2. 发布前只读检查目标数据库和对象，确认当前数据库为 `YL_MESDB`，登录账号正确，并确认以下对象均存在： - `dbo.MES_设计报工_任务说明`。 - `dbo.设计报工_任务说明_新增`。 - `dbo.设计报工_任务_查询`。 - `dbo.设计报工_任务_编辑`。 3. 使用 `sqlcmd -b -C -l 30 -f 65001` 执行迁移脚本 `db_backups/add_design_report_leader_instruction_and_note_history_20260717.sql`；发布过程返回成功，数据库上下文为 `YL_MESDB`。 4. 发布后检查任务说明类型约束： - 约束名称为 `CK_MES_设计报工_任务说明_类型`。 - 约束已启用且为可信状态。 - 定义中同时包含领导批示、异常说明和奇思妙想，检查通过。 5. 检查三个过程的修改时间，均为 `2026-07-17 11:50:08`，确认本次发布已更新目标对象。 6. 使用 SQL Server 首结果集元数据检查 `设计报工_任务_查询`，确认第一列为非空 `nvarchar(max)` 类型的“领导批示”。 7. 检查过程定义，确认领导批示保存逻辑、进度及任务说明按时间倒序聚合、缺少编辑人时的兜底显示均已发布。 8. 首次自动检查创建人权限时使用 SQL `LIKE` 匹配含方括号的字段名，方括号被 SQL 解释为模式字符而产生误报；改用 `CHARINDEX` 分别检查任务描述 CASE、设计要求 CASE 和创建人与最后编辑人比较条件，三项均通过，未重新执行迁移。 9. 从生产任务表选择最新 DID，实际执行更新后的 `设计报工_任务_查询`；查询成功，确认新聚合语句可以在生产真实数据上正常运行。该验证为只读操作，未新增或修改业务数据。 10. 按仓库 `AGENTS.md` 要求追加本条完整中文执行过程日志，日志不记录明文密码。 ### 修改文件 - `gptlog-process/gpdlog.md` ### 结论 - 设计任务领导批示、四类历史记录格式及倒序、创建人编辑权限迁移已成功发布到 `192.168.2.92 / YL_MESDB`。 - “领导批示”已经成为任务查询结果的第一列，数据库保存过程允许领导批示类型。 - 任务描述和设计要求的数据库创建人权限保护已生效。 - 数据库密码未写入任何项目文件或执行日志。 ### 验证结果 - 生产数据库连接和发布前对象检查通过。 - 数据库迁移脚本执行通过。 - 任务说明约束启用、可信且定义正确。 - 三个目标过程修改时间已更新。 - 查询首列“领导批示”元数据检查通过。 - 历史格式及倒序定义检查通过。 - 创建人权限定义检查通过。 - 生产库真实 DID 查询执行通过。 ## 2026-07-17 调整设计任务分类、增加任务来源并恢复默认行高 ### 用户提问 - 用户要求分类选项删除“确认”，增加“售中”和“售后信息确认”。 - 用户要求增加“任务来源”字段并放在类别旁边。 - 用户要求列表页面不要根据历史内容调整行高，使用默认行高。 ### 执行过程 1. 检查设计任务页 `Task/index.vue`、设计报工页 `Report/index.vue`、上一轮数据库迁移和当前工作区状态。 2. 确认两个页面共用相同分类选项；任务表尚无“任务来源”字段；领导批示、进度说明、异常说明和奇思妙想的 `.note-history` 样式使用多行显示并设置了最小、最大高度。 3. 确认工作区还存在用户的发货列表、工时校验和工时编辑等修改，本次没有覆盖或回退这些无关内容。 4. 修改设计任务页分类选项，删除独立选项“确认”，新增“售中”和“售后信息确认”；最终选项为实验、研发、方案评审、售前、售中、订单、售后信息确认、售后问题指导、售后物料准备、返修品处理、其他。 5. 在设计任务页增加任务来源： - 查询区在类别右侧增加任务来源文本筛选。 - 列表在类别右侧增加任务来源列。 - 新建、编辑表单在类别右侧增加任务来源输入框，最大长度 200。 - 空表单、查询参数、实时查询参数和新增/编辑保存参数均接入任务来源。 6. 在设计报工页同步使用新分类选项，并在类别右侧增加任务来源查询条件和列表列；普通查询、最新任务查询及当前未结束任务查询均传递任务来源参数。 7. 将两个页面的历史内容单元格恢复为单行、20 像素最小高度和超出省略显示，移除多行及最大高度设置；完整历史仍可通过原有悬浮提示查看，因此表格行高不再随内容增加。 8. 扩展数据库迁移 `db_backups/add_design_report_leader_instruction_and_note_history_20260717.sql`： - 当字段不存在时，为 `MES_设计报工_任务` 增加可空 `nvarchar(200)` 任务来源列。 - 更新 `设计报工_任务_查询`，增加任务来源参数、返回列和模糊筛选，并把返回列放在类别与任务描述之间。 - 更新 `设计报工_任务_新增`，保存任务来源。 - 更新 `设计报工_任务_编辑`，更新任务来源，同时保留上一轮任务描述和设计要求的创建人权限保护。 9. 执行两个 Vue 文件 ESLint 和目标差异空白检查，均通过；仅输出项目已有的 Baseline、Browserslist 数据过期及换行符提示。 10. 在 SQL Server 2019 LocalDB 创建一次性最小测试库和三张设计报工测试表，执行扩展后的迁移成功。 11. 首次运行隔离验证命令时漏传 LocalDB 数据库名，连接默认落到 `master`，因此提示找不到测试过程和表；该命令未修改任何业务数据。补充 `-d YL_MESDB` 后重新验证成功。 12. LocalDB 验证结果： - 任务来源字段为 `nvarchar(200)`。 - 查询结果中的类别、任务来源、任务描述依次为第 7、8、9 列。 - 查询、新增、编辑三个过程均包含任务来源参数。 - 使用“售中”和“客户现场”新增测试任务成功。 - 将分类编辑为“售后信息确认”、任务来源编辑为“售后反馈”成功。 - 按“售后反馈”筛选查询成功返回测试任务。 13. 删除 LocalDB 测试数据库和临时验证脚本，确认没有临时资源残留。 14. 使用用户已提供的生产数据库账号连接 `192.168.2.92 / YL_MESDB`，发布前确认生产任务表尚无任务来源字段和相应过程参数。 15. 通过当前进程的 `SQLCMDPASSWORD` 环境变量执行扩展后的迁移，发布成功；密码未写入脚本或日志，命令结束后删除环境变量。 16. 生产库发布后验证： - 任务来源字段存在且为 `nvarchar(200)`。 - 查询结果中任务来源位于类别和任务描述之间。 - 查询、新增、编辑三个过程均包含任务来源参数。 - 三个过程修改时间均为 `2026-07-17 13:36:33`。 - 使用生产库最新真实 DID 执行带任务来源参数的查询成功，验证过程为只读操作。 17. 执行 `npm run build`，Webpack 生产构建成功；仅有项目已有的大资源体积和浏览器数据过期警告，没有编译错误或受版本控制的构建产物变化。 18. 检查 `https://localhost:1997/` 返回 HTTP 200；检查分类、任务来源参数、单行样式和临时资源均符合要求；检查数据库密码未进入仓库。 19. 按 `AGENTS.md` 要求追加本条完整中文执行日志。 ### 修改文件 - `src/views/ProductionManagement/DesignReportTask/Task/index.vue` - `src/views/ProductionManagement/DesignReportTask/Report/index.vue` - `db_backups/add_design_report_leader_instruction_and_note_history_20260717.sql` - `gptlog-process/gpdlog.md` ### 结论 - 分类已删除“确认”，增加“售中”和“售后信息确认”，两个页面选项一致。 - 任务来源已经加入设计任务的查询、新建、编辑和列表，并加入设计报工的查询和列表，显示位置紧邻类别。 - 列表历史内容恢复单行省略显示，行高不再根据内容自动增加，悬浮提示仍显示完整内容。 - 任务来源数据库字段和查询、新增、编辑过程已发布到生产数据库。 ### 验证结果 - 两个目标 Vue 文件 ESLint 通过。 - 目标差异空白检查通过。 - LocalDB 任务来源新增、编辑、筛选和列顺序验证通过。 - 临时测试数据库和脚本已清理。 - 生产数据库迁移发布成功。 - 生产库字段、三个过程参数和查询列顺序检查通过。 - 生产库真实 DID 查询通过。 - `npm run build` 生产构建通过。 - `https://localhost:1997/` 返回 HTTP 200。 ## 2026-07-17 迁移设计任务完成功能并增加领导批示角色权限 ### 用户提问 - 用户要求把“完成”功能由设计报工页面迁移到设计任务页面。 - 用户要求设计任务和设计报工页面默认不显示已完成任务。 - 用户要求领导批示按钮增加权限限制，只有权限包含“领导”的角色才能显示。 - 用户随后补充：权限包含“管理员”的角色也可以显示领导批示按钮。 ### 执行过程 1. 检查设计任务页、设计报工页、用户登录、Vuex 用户状态、动态路由权限、数据库角色表和设计报工相关过程。 2. 确认原“完成”按钮和完整校验逻辑位于 `Report/index.vue`，包括实时任务查询、未结束报工校验、至少一次已结束报工校验、完成确认和 `设计报工_任务_完成` 调用。 3. 确认当前登录状态只保存角色编号，Vuex 的 `roles` 固定为 `admin` 以驱动历史路由框架，不能代表真实角色功能；真实角色名称存储在 `登录基础数据_角色信息.Roles_Function`。 4. 只读检查生产角色表，确认存在角色功能包含“领导”的角色，例如质量部领导和采购部领导；数据库角色表及字段可用于精确权限判断。 5. 修改设计任务页： - 在状态选项中增加“未完成”，并把默认状态设为“未完成”。 - 在操作区增加“完成”按钮。 - 迁入原报工页的完整完成逻辑：实时刷新任务、检查未结束人员、检查是否已有报工、二次确认、调用 `设计报工_任务_完成` 并刷新列表。 - 增加独立动作加载状态，防止完成操作重复提交。 - 将原仅用于删除的实时任务查询提示调整为完成和删除均适用的通用提示。 6. 修改设计报工页： - 删除“完成”按钮、`canComplete` 和 `completeTask` 方法。 - 缩小操作列宽度。 - 状态选项增加“未完成”，默认状态设为“未完成”。 7. 两个页面都会在首次加载时使用当前角色编号调用 `设计报工_领导批示权限_查询`；按钮默认隐藏，只有查询返回有权限时才显示。 8. 根据用户补充要求，将权限条件定义为当前角色功能包含“领导”或“管理员”任一文本；前端变量统一命名为 `canUseLeaderInstruction`，避免仍表达为仅领导角色。 9. 两个页面保存领导批示时都额外传递当前角色编号；异常说明和奇思妙想继续使用同一过程，不受领导批示角色限制。 10. 扩展数据库迁移脚本： - 新增 `设计报工_领导批示权限_查询`，按角色编号检查角色功能是否包含“领导”或“管理员”。 - `设计报工_任务说明_新增` 增加角色编号参数；当说明类型为领导批示时，在数据库再次校验领导或管理员权限，无权限返回“当前角色无领导批示权限”。 - `设计报工_任务_查询` 增加“未完成”状态语义，过滤所有单据状态为“已完成”的任务；全部和其他具体状态查询保持原有行为。 11. 执行两个 Vue 文件 ESLint 和目标差异空白检查，均通过；只有项目已有的浏览器数据过期及换行符提示。 12. 在 SQL Server 2019 LocalDB 创建一次性最小测试库，构造领导角色、管理员角色、普通角色、未完成任务和已完成任务，执行迁移成功。 13. LocalDB 权限验证： - 领导角色权限结果为 1。 - 管理员角色权限结果为 1。 - 普通角色权限结果为 0。 - 普通角色保存领导批示被数据库拒绝，且任务说明表中没有越权记录。 - 领导角色和管理员角色分别保存领导批示成功。 - 普通角色保存异常说明成功，确认权限没有错误限制其他说明类型。 14. LocalDB 默认筛选验证：任务表包含一条待开始、一条已完成任务，使用“未完成”查询只返回待开始任务，返回数量为 1，已完成数量为 0。 15. 删除 LocalDB 测试数据库和临时验证脚本，确认无测试资源残留。 16. 使用用户已提供的生产数据库账号执行扩展后的迁移；密码只通过当前命令进程环境变量传递，命令结束后清理，未写入仓库或日志。 17. 生产库验证结果： - 随机选择实际领导、管理员和普通角色调用权限过程，结果依次为 1、1、0。 - 权限查询过程、任务说明新增过程和任务查询过程修改时间均为 `2026-07-17 14:14:39`。 - 任务说明新增过程确认包含角色编号参数。 - `设计报工_任务_完成` 过程仍存在，完成按钮迁移没有改变其数据库业务逻辑。 - 使用真实生产数据执行“未完成”查询返回 7 条，已完成数量为 0；查询过程仅执行只读验证。 18. 执行代码检索，确认完成按钮和相关方法只存在于设计任务页，设计报工页不再包含完成入口；两个页面均默认选择“未完成”，领导批示按钮均使用权限变量控制。 19. 执行 `npm run build`，生产构建成功；仅有项目已有的大资源体积和浏览器数据过期警告，没有编译错误或受版本控制的构建产物变化。 20. 检查 `https://localhost:1997/` 返回 HTTP 200；检查数据库密码未进入仓库；按 `AGENTS.md` 要求追加本条完整中文日志。 ### 修改文件 - `src/views/ProductionManagement/DesignReportTask/Task/index.vue` - `src/views/ProductionManagement/DesignReportTask/Report/index.vue` - `db_backups/add_design_report_leader_instruction_and_note_history_20260717.sql` - `gptlog-process/gpdlog.md` ### 结论 - “完成”按钮及全部校验逻辑已经从设计报工页迁移到设计任务页。 - 设计任务和设计报工页面默认只显示未完成任务，用户仍可通过状态下拉查看全部或指定状态。 - 领导批示按钮只有当前角色功能包含“领导”或“管理员”时显示。 - 领导批示保存过程具备相同的数据库权限校验，普通角色不能绕过页面直接提交。 - 权限过程和未完成筛选已发布生产数据库。 ### 验证结果 - 两个目标 Vue 文件 ESLint 通过。 - 目标差异空白检查通过。 - LocalDB 领导、管理员、普通角色权限验证通过。 - LocalDB 领导批示写入和越权拦截验证通过。 - LocalDB 未完成默认筛选验证通过。 - 临时测试资源已清理。 - 生产数据库迁移发布成功。 - 生产库实际角色权限结果为领导 1、管理员 1、普通角色 0。 - 生产库未完成查询返回 7 条，已完成数量为 0。 - `npm run build` 生产构建通过。 - `https://localhost:1997/` 返回 HTTP 200。 ## 2026-07-17 清空生产数据库全部设计报工业务数据 ### 用户提问 - 用户要求清空所有设计数据。 ### 执行过程 1. 将本次清理范围限定为设计报工模块的业务数据表，不删除表结构、存储过程、菜单和项目、物料、人员等基础资料。 2. 使用用户已提供的生产数据库账号连接 `192.168.2.92 / YL_MESDB`；密码仅通过当前命令进程环境变量传递，命令结束后立即清理，未写入仓库或日志。 3. 发布前查询所有名称包含“设计报工”的生产业务表及行数，确认存在四张表： - `MES_设计报工_任务`：11 条。 - `MES_设计报工_记录`：40 条。 - `MES_设计报工_任务说明`：10 条。 - `MES_设计报工_校验记录`：16 条。 4. 检查外键关系，确认报工记录引用任务且删除规则为 `NO_ACTION`，任务说明引用任务且删除规则为 `CASCADE`；校验记录包含 RID 和 DID 引用字段但没有数据库外键。 5. 检查四张表的自增列，分别为任务 DID、报工记录 RID、任务说明 SID、校验记录 VID。 6. 在单个数据库事务中按依赖顺序执行清理：校验记录、任务说明、报工记录、任务。 7. 删除后在提交前再次检查四张表；如果任一表仍有数据则抛出错误并回滚整个事务。本次检查全部为空，事务成功提交。 8. 在同一事务中将四张表的自增值重置为 0，使后续新增的第一条数据从 1 开始。 9. 数据库返回的实际删除数量为：任务 11、报工记录 40、任务说明 10、校验记录 16，总计 77 条。 10. 提交后再次查询四张表，行数均为 0；再次查询四个自增列，当前值均为 0。 11. 按仓库 `AGENTS.md` 要求在日志末尾追加本条完整中文执行记录。 ### 修改文件 - `gptlog-process/gpdlog.md` ### 结论 - 生产数据库中设计报工模块的任务、报工记录、任务说明和校验记录已全部清空。 - 共删除 77 条业务数据，四张表当前均为 0 行。 - 四张表自增值已重置，后续新数据编号从 1 开始。 - 表结构、存储过程、菜单和基础资料保持不变。 ### 验证结果 - 事务删除成功，无回滚或外键错误。 - 任务表：0 条，自增值 0。 - 报工记录表：0 条，自增值 0。 - 任务说明表：0 条，自增值 0。 - 校验记录表：0 条，自增值 0。 ## 2026-07-17 放大设计列表行高字体并统一报工字段顺序 ### 用户提问 - 用户先反馈分类删除“确认”、增加“售中”和“售后信息确认”后，设计任务界面似乎仍有“确认”。 - 用户随后要求修改设计任务和设计报工页面：列表行高变成三倍、修改字体大小、相应调整列宽，并让设计报工列表字段位置与设计任务一致。 ### 执行过程 1. 检查当前设计任务和设计报工列表模板、样式、分类选项和工作区状态。 2. 确认两个页面的分类数组均为实验、研发、方案评审、售前、售中、订单、售后信息确认、售后问题指导、售后物料准备、返修品处理、其他；源码中不存在独立的“确认”选项，“确认”文本只作为“售后信息确认”的组成部分存在。 3. 检查当前设计任务列表字段顺序，确认在本次修改前已经调整为：领导批示、DID、状态、任务描述、设计要求、指派对象、预计开始、预计结束、进度说明、异常说明、奇思妙想、项目号、物料编码、物料名称、图号、类别、任务来源、父件物料编码、研发立项号、研发目的、对其可见、报工次数、未结束、设计正在对应、创建日期、创建人、备注、操作。 4. 以当前设计任务列表为唯一顺序基准，重排设计报工列表全部共同字段，避免按旧版顺序推断。 5. 在设计报工列表补齐原来未显示的共同字段：父件物料编码、研发立项号、研发目的、对其可见、创建日期、创建人和备注。 6. 自动提取两个 Vue 模板中的列名进行顺序比对，确认两个页面的 27 个共同字段完全同序；设计报工特有的“最后开始”和“最后结束”放在共同字段之后、操作列之前。 7. 为两个列表统一增加 `design-data-table` 样式类，并固定数据行和单元格高度为 108 像素，约为原 mini 表格行高的三倍。 8. 统一字体和垂直尺寸： - 表格正文调整为 16 像素。 - 表头调整为 15 像素、高度 48 像素。 - 操作按钮调整为 15 像素。 - 状态标签调整为 14 像素、高度 30 像素。 - 单元格统一使用 24 像素行高。 9. 历史内容单元格在固定行高中使用 72 像素内容区、24 像素行高，最多展示三行并保留原有悬浮完整内容，防止内容继续撑高表格行。 10. 同步加宽两个页面的对应列：领导批示和三类历史列 360，任务描述和设计要求 320，人员及可见字段 200 至 220，日期字段 180，物料及研发字段按内容调整为 150 至 280。 11. 设计任务操作列调整为 340 像素，设计报工操作列调整为 440 像素，保证放大后的按钮和权限动态显示不会挤压换行。 12. 首次 ESLint 和差异空白检查发现设计任务模板有两处空白行带尾随空格；清理后重新执行，两项检查均通过。 13. 执行两个目标 Vue 文件 ESLint，检查通过；仅输出项目已有的 Baseline 和 Browserslist 数据过期提示。 14. 执行 `npm run build`，Webpack 生产构建成功；仅有项目已有的大资源体积和浏览器数据过期警告，没有模板、JavaScript 或样式错误，也没有产生受版本控制的构建产物变化。 15. 检查 `https://localhost:1997/` 返回 HTTP 200；再次核对分类源码没有独立“确认”，并确认工作区其他已有修改未被覆盖或回退。 16. 本次仅修改前端列表布局和样式，不修改或写入生产数据库业务数据。 17. 按仓库 `AGENTS.md` 要求在日志末尾追加本条完整中文执行记录。 ### 修改文件 - `src/views/ProductionManagement/DesignReportTask/Task/index.vue` - `src/views/ProductionManagement/DesignReportTask/Report/index.vue` - `gptlog-process/gpdlog.md` ### 结论 - 设计任务和设计报工列表数据行已统一固定为 108 像素，字体、表头、标签和操作按钮同步放大。 - 两个页面的对应列宽已经统一加宽，三行历史内容不会继续撑高列表。 - 设计报工的 27 个共同字段已经与当前设计任务列表完全同序，并补齐缺少的字段。 - 设计报工特有的最后开始和最后结束保留在共同字段之后。 - 两个分类数组均无独立“确认”选项，保留的是“售后信息确认”。 ### 验证结果 - 两个列表共同字段顺序自动比对通过。 - 分类独立“确认”文本检查无命中。 - 两个目标 Vue 文件 ESLint 通过。 - 目标文件差异空白检查通过。 - `npm run build` 生产构建通过。 - `https://localhost:1997/` 返回 HTTP 200。 ## 2026-07-17 设计任务和设计报工列表长文本自动换行 ### 用户提问 - 用户要求列表内容超出列宽时不要省略，改为换行显示。 ### 执行过程 1. 检查上一轮设计任务和设计报工列表样式，确认列表基础行高为 108 像素，普通字段仍带 Element UI 的 `show-overflow-tooltip` 省略行为，历史内容限制在 72 像素三行并隐藏超出内容。 2. 保留上一轮统一后的列宽、字体大小和字段顺序，不修改数据库、业务逻辑或查询参数。 3. 在两个页面的 `design-data-table` 表格正文中统一覆盖普通单元格和 Element UI tooltip 单元格样式： - `white-space: normal !important`，允许按列宽自动换行。 - `text-overflow: clip`，取消省略号。 - `overflow: visible`，不裁剪超出内容。 - `overflow-wrap: anywhere` 和 `word-break: break-word`，长编号、无空格文本也可以换行。 4. 修改两个页面的历史内容样式，移除 72 像素最大高度和隐藏裁剪；保留 72 像素最小高度及原始换行格式，内容超过三行时完整展开。 5. 保留数据单元格的 108 像素基础高度；当换行内容需要更多空间时，由表格自动增加该行高度，避免文字覆盖相邻行。 6. 执行两个目标 Vue 文件 ESLint，检查通过；仅输出项目已有的 Baseline 和 Browserslist 数据过期提示。 7. 执行目标文件差异空白检查，检查通过；只有仓库换行符转换提示。 8. 通过文本检查确认两个页面均包含自动换行、取消省略和长单词断行样式，同时不存在历史内容 `max-height: 72px` 和 `text-overflow: ellipsis` 残留。 9. 执行 `npm run build`，Webpack 生产构建成功；仅有项目已有的大资源体积和浏览器数据过期警告，没有模板或样式编译错误，也没有产生受版本控制的构建产物变化。 10. 检查 `https://localhost:1997/` 返回 HTTP 200。 11. 按仓库 `AGENTS.md` 要求在日志末尾追加本条完整中文执行记录。 ### 修改文件 - `src/views/ProductionManagement/DesignReportTask/Task/index.vue` - `src/views/ProductionManagement/DesignReportTask/Report/index.vue` - `gptlog-process/gpdlog.md` ### 结论 - 设计任务和设计报工列表中的普通字段、编号和历史内容均按列宽自动换行。 - 列表不再使用省略号，也不再裁剪超过三行的历史内容。 - 108 像素作为基础行高保留，内容较多时表格行会继续增长并完整显示。 ### 验证结果 - 两个目标 Vue 文件 ESLint 通过。 - 目标文件差异空白检查通过。 - 自动换行和取消省略样式检查通过。 - 历史内容最大高度及省略号残留检查无命中。 - `npm run build` 生产构建通过。 - `https://localhost:1997/` 返回 HTTP 200。