1733 lines
110 KiB
Markdown
1733 lines
110 KiB
Markdown
## 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`。
|
||
- 两个中心页的异常管控弹窗中，将组件调用改为 `<abnormal-control-panel :initial-selected-row="selectedRow" />`。
|
||
|
||
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。
|
||
- 未分配菜单权限。
|