feat: 完善设计报工及生产管理功能

gptlog-process/gpdlog.md

@@ -4807,6 +4807,39 @@ pm run build：通过，仅有既有警告。
 ### 结论
 - 明日计划已改为8个主时间段、每段6条大工作项。
 - 每条记录不再包含子序号和10分钟时间格式。
+- 工作项粒度更适合报工填写，持续性任务允许重复。
+
+### 验证结果
+- 8个主时间段保留。
+- 每段6条记录，共48条。
+- 子序号和子时间已移除。
+- 本次未修改业务资源。
+
+## 2026-07-21 新增四类大屏发货任务堵点查询
+
+### 用户提问
+- 用户要求根据桌面 `发货任务堵点.docx` 修改大厅计划、仓库、装配和质检测试大屏，并指定已完成的发货通知页面及 `装配中心任务看板_发货状态查询` 作为参考。
+- 经需求确认，装配阶段在完成数量小于计划数量时显示“装配”，相等后继续检查质检和入库；质检大屏使用序检检验数量。
+
+### 执行过程
+1. 只读分析需求文档、四个大屏和发货通知参考实现，确认需为不同看板提供不同来源及过滤规则，且不应直接改变发货通知页现有查询口径。
+2. 只读核查生产库字段和枚举，确认终检合格、收检不合格的既有业务口径；确认序检数据在质检记录中对应 `检测类型编号=6、质检类型=收检`。
+3. 新建迁移 `db_backups/create_shipping_bottleneck_dashboard_proc_20260721.sql`，定义独立过程 `dbo.发货任务堵点_看板查询`，参数支持大厅、仓库、装配、质检四种看板类型。
+4. 数据源第一部分读取 `[SAP].[SBO_YL].[dbo].[UBT_ODRF_ODLNMES]` 并左连 MES 生产订单；第二部分读取 `View_生产订单_MES.优先级='是'` 的装配任务，并排除已存在于 SAP 的订单。
+5. 预先按 TaskAID 汇总当前装配操作人、终检合格数量、收检不合格数量和序检检验数量，并按合同号汇总装配工时，避免一对多连接造成重复和数量放大。
+6. 特殊物料编码包含 `3420-YT`、`3420-HT`、`3420-YF` 时堵点直接返回“见子任务”；其他记录依次判断齐套、派发、发料、开工、装配、质检、待入库。
+7. 大厅过滤“终检合格+收检不合格=计划数量”的记录；仓库仅返回 SAP 来源；装配仅返回完成数量小于计划数量；质检仅返回序检检验数量小于完成数量。
+8. 在事务中临时执行迁移并调用四种参数，预演结果为大厅16行、仓库17行、装配12行、质检2行，随后回滚，确认迁移可编译且口径正确。
+9. 两个前端项目完成过程切换和堵点字段接入后，分别执行 `npm run build`，构建成功，仅有既有非阻断警告。
+10. 首次正式发布在提交前的 PowerShell 数据校验中因 DBNull 转 decimal 失败，异常处理成功回滚事务，未创建生产过程。
+11. 修正校验脚本的空值处理后重新执行，事务内验证仓库仅含 SAP、大厅不含已完成质检任务、装配不含已完成装配任务、质检不含已完成序检任务，全部通过后提交。
+12. 正式发布后过程创建及修改时间为 `2026-07-21 10:06:45`；独立复核四种结果仍为16、17、12、2行，每种结果包含28个字段和堵点字段。
+13. 核对原 `装配中心任务看板_发货状态查询` 修改时间仍为 `2026-07-20 11:29:55`，确认发货通知参考过程没有被本次发布覆盖。
+14. 使用本地 Vite 页面连接生产接口，在1920×1080下检查大厅、仓库、装配和质检页面，字段及实时数据正常显示。
+15. 页面复核发现仓库旧汇总过程的发货数量与新SAP明细不一致；前端改为从 `发货任务堵点_看板查询` 的仓库结果计算发货任务、小于今日和加急条数，未再修改数据库过程。
+
+### 修改文件
+- `db_backups/create_shipping_bottleneck_dashboard_proc_20260721.sql`
 - `gptlog-process/gpdlog.md`
 - 外部看板项目的四个页面数据接入文件。
 
@@ -4842,6 +4875,7 @@ pm run build：通过，仅有既有警告。
 - `src/views/ProductionManagement/SaleOutsourceMange/index.vue`
 - `db_backups/add_design_report_hours_report_permissions_20260720.sql`
 - `db_backups/fix_delivery_notice_list_current_operators_20260720.sql`
+- `db_backups/fix_delivery_notice_list_data_merge_20260720.sql`
 
 ### 结论
 - 当前工作区的全部修改已统一提交并推送到远端当前分支。
@@ -4875,3 +4909,420 @@ pm run build：通过，仅有既有警告。
 ### 结论
 - 该计划用于报工填写是合理的，任务方向和时间顺序基本正确。
 - 该计划作为当天全部交付承诺偏满，主要风险是四个大屏同时开发测试、客户确认时效以及临时线上问题。
+- 在需求上午及时冻结、公共逻辑能够复用且没有较大线上问题的情况下，核心任务可以完成；全部扩展内容能否完成不应作刚性承诺。
+- 建议以14:20为切换检查点，并保留最后40分钟作为修正和归档缓冲。
+
+### 验证结果
+- 上午开发范围和未确认口径已识别。
+- 下午建档范围和可交付粒度已评估。
+- 必须完成项、争取完成项和阶段检查点已给出。
+- 本次未修改业务资源。
+
+## 2026-07-21 生成工时模块全流程技术说明 PDF
+
+### 用户提问
+- 用户要求详细整理从加工中心、装配中心开始，到工时校验结束的全部工时相关功能，包括页面、存储过程、计算方法、数据表、视图等，并生成 PDF 文件。
+- 用户提供了数据库只读查询条件，明确要求只可查询、不可修改。
+
+### 执行过程
+1. 检索生产管理前端目录及数据库备份脚本，定位加工中心、装配中心、工时修正、工时校验、人员绑定、班次管理等相关页面。
+2. 逐页提取 `CreateData` 调用、前端校验条件、开始/结束动作、加班选择、异常工时、工时编辑和 SAP 调用逻辑。
+3. 确认加工中心通过 `MES_ProductTask_WorkingStart`、`MES_ProductTask_HelpStart`、`MES_ProductTask_HelpEnd`、`MES_ProductTask_ProdReport` 产生工时记录。
+4. 确认装配中心通过 `MES_人员工时记录_开始` 和 `MES_人员工时记录_结束` 产生人员工时和加班记录。
+5. 确认工时修正页面可更新起止时间、设备工时、人员工时和班次标准工时，并支持补录操作记录。
+6. 确认工时校验页面按昨日以前记录进行筛选，调用批量工时计算过程，并逐条补充 SAP 工序和资源、提交资源工时单据，上传成功后保存校验副本。
+7. 使用只读 SQL 查询数据库系统目录，核对当前存储过程参数、对象类型、对象依赖、表字段、索引、视图定义、函数定义和班次配置；未执行任何业务存储过程，未写入或修改数据库数据。
+8. 读取 `MES_ProductCenter_OptRecord_Save` 当前定义，确认设备总时长、暂停总时长和实际工时的计算与开始/结束记录配对规则。
+9. 读取 `计算人员工时` 和 `计算班次重叠秒数` 当前定义，确认人员、工位、班次绑定及重叠秒数的拆分逻辑。
+10. 读取 `usp_CalculateDailyRatio`、`usp_CalculateShiftTime`、`usp_CalculateUploadMinutes`、`usp_BatchValidateWorkTime` 和 `usp_ValidateWorkTime` 当前定义，整理当日归一化系数、班次内外拆分及 SAP 上传分钟公式。
+11. 读取 `View_生产工时视图`、`View_生产工时视图全部`、`View_校验后的生产工时`、`View_工位人员绑定数` 和 `View_设备工位人员` 当前定义，整理视图连接、字段优先级和过滤规则。
+12. 核对 `YL_加工中心_操作记录表`、`生产管理_工时校验_校验工时表`、`YL_加工中心_报工记录`、班次及绑定相关表的字段用途。
+13. 核对 `src/api/b1s.js` 和工时校验页面，整理 SAP `ProductionOrders` 查询/更新、资源行计划量调整和 `InventoryGenExits` 工时单据映射。
+14. 明确文档边界：以工时校验为终点；工时查询、工时报表、结算工时和设计报工属于校验后统计或其他业务域，不作为主流程展开。
+15. 整理当前实现中的重点风险，包括班次配置与代码注释不一致、日期筛选参数未生效、300 秒跳过 SAP、批量计算详情未落库、直接校验前端硬编码权限、校验表缺少唯一约束等。
+16. 编写详细 HTML 文档，包含目录、总流程、页面清单、加工/装配流程、工时修正、校验流程、计算公式、过程函数矩阵、表视图说明、SAP 映射、状态单位、风险和验收用例。
+17. 使用本机 Edge 无头打印生成 PDF，保留 HTML 作为可维护源文件。
+18. 使用 PDF 文本解析检查成品，共 20 页、约 1.5 万个可检索字符，无空白页，关键过程、视图、SAP 接口和风险章节均存在。
+19. 检查 PDF 字体对象，确认包含嵌入式 TrueType 字体；使用浏览器截图确认 HTML 中文和版式正常。Node 版 PDF.js 画布后端对部分中文子集字体映射不完整，因此该预览图不作为成品显示判定依据。
+20. 计算 PDF SHA256 校验值，并将仅用于校验的临时浏览器配置和预览图片移出工作区。
+21. 保留工作区中与本任务无关的既有修改，不覆盖、不撤销，也不纳入本次文档内容。
+
+### 新增文件
+- `doc/工时模块全流程技术说明_20260721.html`
+- `doc/工时模块全流程技术说明_20260721.pdf`
+
+### 结论
+- 已完成从加工中心、装配中心到工时校验结束的工时模块全流程整理。
+- 文档详细覆盖 6 个直接或支撑页面、核心存储过程和函数、事实表与校验表、统一工时视图、人员/班次绑定、设备与人员工时计算、加班规则、SAP 上传以及现状风险。
+- 数据库查询全过程为只读，没有修改数据库对象、配置或业务数据。
+- PDF 共 20 页，可检索、无空白页；HTML 源文件一并保留，便于后续更新。
+
+### 验证结果
+- 前端页面和调用链检索：完成。
+- 数据库当前对象定义只读核对：完成。
+- PDF 文件生成：成功。
+- PDF 页数：20 页。
+- PDF 可检索文本：约 1.5 万字符。
+- PDF 空白页：0 页。
+- PDF SHA256：`C2A90033708903EB3AC64AD015369F6D136236A375A315869D8B5EAE8B9F68B8`。
+
+## 2026-07-21 扩展工时模块 PDF 范围
+
+### 用户提问
+- 用户确认工时查询、工时报表和结算工时也属于工时模块，需要补充外协部分、生产计划跟踪报表等功能。
+- 用户确认设计报工不纳入本文，并要求删除“现状风险与核对项”章节。
+
+### 执行过程
+1. 检索 `Workhours`、`Timesheet`、`SettlementWorkhours`、`OutsourceMange`、`SaleOutsourceMange`、`OutsourceSheet` 和 `ProductionPlanTrack` 页面，提取查询参数、树形分组、汇总公式、导出和外协发收料调用。
+2. 使用只读 SQL 查询当前数据库定义，核对 `生产管理_工时查询_工序工时_查询`、项目/作业者/任务/设备四类工时统计过程、`生产管理_结算工时_查询`、`生产管理_生产计划跟踪`、外协管理和外协报表过程。
+3. 确认工时查询使用当前生产工时视图，按 TaskAID、日期、单次开始记录形成三级工序工时树，并关联工艺库标准工时。
+4. 确认工时报表使用包含已关闭订单的全量工时视图，提供项目、作业者、任务和设备四个页签及四套导出过程；人员班组用于工时类型分类。
+5. 确认结算工时连接生产计划、资源任务和工时视图，按物料及订单工位形成两层汇总，计算报工、辅助、合计和单件结算工时。
+6. 读取 `View_外协报表视图`、外协任务查询、外协发料保存和外协收料保存定义，确认外协发料写“收料”记录、外协收料写“报工”记录。
+7. 确认标准生产工时视图排除工位为“外协”的记录，因此外协不参与内部设备/人员工时校验，而通过外协任务、操作事件、采购、发收料和质检链路单独跟踪。
+8. 读取生产计划跟踪过程，确认其合并全部订单、工艺标准工时、操作起止、外协结束、收检/终检和任务状态，并由前端生成订单工序路线。
+9. 修改文档封面、范围、总流程和页面清单，将查询、报表、结算、外协和生产计划跟踪纳入完整工时模块。
+10. 新增“工时查询、工时报表与结算工时”章节，详细记录数据范围、三级结构、有效工时口径、结算公式和导出方式。
+11. 新增“外协与生产计划跟踪”章节，详细记录外协在工时体系中的边界、派工、发料、收料、外协报表和生产路线跟踪。
+12. 扩展存储过程、数据表、视图、页面调用矩阵和代码来源清单，并统一重排为 16 章。
+13. 将设计报工、设计工时校验和设计工时报表明确列为排除业务域。
+14. 完整删除“现状风险与核对项”及原验收用例，不保留目录链接或章节残留。
+15. 重新使用 Edge 生成 PDF，并用 PDF 文本解析检查页数、可检索字符、空白页和新增页面路径。
+16. 使用浏览器截图复核新版封面、目录、中文字体和版式，显示正常。
+17. 数据库操作全过程仅执行只读查询，没有执行存储过程，没有修改数据库对象、配置或业务数据。
+
+### 修改文件
+- `doc/工时模块全流程技术说明_20260721.html`
+- `doc/工时模块全流程技术说明_20260721.pdf`
+- `gptlog-process/gpdlog.md`
+
+### 结论
+- 工时查询、工时报表、结算工时、外协管理、外协报表和生产计划跟踪已纳入工时模块说明。
+- 设计报工相关页面和数据库对象明确排除。
+- “现状风险与核对项”章节已完整删除。
+- 新版文档共 23 页，覆盖从现场报工、外协业务、工时校验到查询、统计、结算和生产计划跟踪的完整链路。
+
+### 验证结果
+- HTML 章节数量：16 章。
+- PDF 页数：23 页。
+- PDF 可检索文本：约 1.99 万字符。
+- PDF 空白页：0 页。
+- 新增页面路径检查：全部存在。
+- 已删除章节残留检查：未发现。
+- PDF SHA256：`93D33B50BBDF7FBF42D3B70A744C76F494AEF3F9CDC8C90F1FC9237976577567`。
+
+## 2026-07-21 根据工作内容生成明日计划
+
+### 用户提问
+- 用户提供 8 个明日工作时间段，要求根据生产退库接口、采购申请接口、大屏刷新与设备状态、及时拣配机加/装配报表、标牌打印内容管理及临时调整归档等内容生成明日计划。
+- 用户要求每小时拆分为 6 条记录，内容允许重复。
+
+### 执行过程
+1. 保留用户给出的 8 个主时间段和工作先后顺序。
+2. 按每 10 分钟一条记录拆分：完整 1 小时时间段各生成 6 条。
+3. `10:30-11:50` 共 80 分钟，生成 8 条记录；`17:20-18:00` 共 40 分钟，生成 4 条记录。
+4. 全天共生成 48 条计划记录。
+5. `08:30-09:30` 围绕生产退库接口和采购申请接口的现状核对、参数修改、联调及验证安排。
+6. `09:30-10:30` 围绕所有大屏自动刷新方式、刷新时间、机加看板一设备运行状态及明细安排。
+7. `10:30-11:50` 和 `13:20-14:20` 围绕 SAP 及时拣配机加报表的数据源、字段、接口、页面和联调安排。
+8. `13:20-14:20` 和 `14:20-15:20` 同时衔接及时拣配装配报表的数据对接、开发、测试和修正。
+9. `15:20-17:20` 围绕标牌打印内容管理页面的字段对接、功能开发、测试和修改安排。
+10. `17:20-18:00` 安排大屏及报工临时调整、版本整理和当日修改归档。
+11. 本次只生成计划文本并追加过程日志，没有修改业务代码、数据库对象或业务数据。
+
+### 修改文件
+- `gptlog-process/gpdlog.md`
+
+### 结论
+- 已按 8 个主时间段生成 48 条明日计划记录。
+- 完整小时均拆分为 6 条，非完整小时按实际每 10 分钟一条拆分。
+- 计划覆盖接口修改、大屏调整、及时拣配机加/装配报表、标牌打印内容管理、临时问题和版本归档。
+
+### 验证结果
+- 主时间段：8 个。
+- 完整小时拆分：每段 6 条。
+- 80 分钟时段：8 条。
+- 40 分钟时段：4 条。
+- 全天计划记录：48 条。
+
+## 2026-07-22 检查及时齐套跟踪结果订单 8238 少一条数据
+
+### 用户提问
+- 用户反馈“生产管理-及时齐套跟踪结果”查询生产订单（订单编号）`8238` 时，存储过程只返回 6 条数据，而 `[SAP].[SBO_YL].[dbo].[VIEW_Jijiankukc]` 中有 7 条，要求检查原因。
+- 用户进一步明确问题位于存储过程而非页面，并提供数据库 `192.168.2.92` 的连接账号和密码；日志不记录明文密码。
+
+### 执行过程
+1. 在项目中检索“及时齐套”“齐套跟踪”和 `VIEW_Jijiankukc`，定位查询过程为 `dbo.生产管理_及时齐套跟踪结果_查询`，本地对应脚本为 `db_backups/update_timely_kit_tracking_result_multi_detail_orders_20260630.sql`。
+2. 检查本地过程脚本，确认过程先从 SAP 视图读取未发货数量大于 0 的缺件，再在最终结果处使用 `ROW_NUMBER()` 分组去重，并仅保留 `rn = 1`。
+3. 使用用户提供的连接信息，以只读方式连接 `192.168.2.92 / YL_MESDB`；未执行任何数据库写入、对象发布或数据修改。
+4. 查询线上过程元数据，确认 `dbo.生产管理_及时齐套跟踪结果_查询` 最后修改时间为 `2026-07-15 14:25:11.830`，线上定义同时包含 SAP 源级去重和最终结果去重逻辑。
+5. 查询 `[SAP].[SBO_YL].[dbo].[VIEW_Jijiankukc] WHERE DocEntry = 8238`，确认共有 7 条缺件记录，SAP 行号分别为 `2、3、21、28、33、48、75`，且未发货数量均大于 0。
+6. 执行 `EXEC dbo.[生产管理_及时齐套跟踪结果_查询] @订单号 = 8238`，确认过程实际返回 6 条，SAP 行号为 `2、3、21、28、48、75`，缺少 SAP 行号 `33`。
+7. 对比缺少的 SAP 行号 `33` 与保留的行号 `48`：行号 33 为物料 `23601-032-A6x6x25`（平键），缺件数量 2；行号 48 为物料 `23202-030-M5x12`（螺钉），缺件数量 5；两条均为外购件，且“在制采购”均为 `4957`。
+8. 核对过程字段映射，确认外购件的“缺件生产订单号”实际取 `在制采购`。最终去重按“订单号 + 缺件生产订单号”分组；当该字段为空时才改用“缺件物料编码 + SAP 行号”。因此两种不同外购物料因共同的 `在制采购 = 4957` 被错误归到同一组。
+9. 使用与过程一致的分组和排序表达式复算 7 条记录：SAP 行号 48 因缺件数量 5 较大得到 `rn = 1` 并保留，SAP 行号 33 得到 `rn = 2`，被最终 `WHERE rn = 1` 排除；其余 5 条均为各自分组的 `rn = 1`。
+10. 本次按“检查原因”的范围仅完成只读诊断，未修改业务代码、存储过程或数据库数据。
+
+### 结论
+- 页面或 SAP 视图没有少数据，少一条发生在 `dbo.生产管理_及时齐套跟踪结果_查询` 的末级去重。
+- 被排除的是 SAP 行号 `33`、物料 `23601-032-A6x6x25`（平键）。它与 SAP 行号 `48`、物料 `23202-030-M5x12`（螺钉）的“在制采购”均为 `4957`，过程误把两条不同外购物料视为同一“缺件生产订单号”分组。
+- 分组内按缺件数量倒序，行号 48 的缺件数量为 5，得到 `rn = 1`；行号 33 的缺件数量为 2，得到 `rn = 2` 并被过滤，所以最终由 7 条变成 6 条。
+- 若后续修复，外购件不应仅按“在制采购”去重，应至少将物料编码或 SAP 行号纳入去重键；自制件仍可按实际缺件生产订单号归并。该修复本次未执行。
+
+### 验证结果
+- SAP 视图订单 8238：7 条。
+- 存储过程订单 8238：6 条。
+- 明确缺失记录：SAP 行号 33，平键，缺件数量 2。
+- 末级去重复算：行号 33 的 `rn = 2`，行号 48 的 `rn = 1`。
+- 数据库修改：无。
+
+## 2026-07-22 修正及时齐套跟踪结果订单 8238 外购缺件误去重
+
+### 用户提问
+- 用户确认上一轮诊断结论正确，要求修正 `dbo.生产管理_及时齐套跟踪结果_查询` 将订单 `8238` 的两种不同外购物料误合并的问题。
+
+### 执行过程
+1. 制定执行步骤：核对线上与本地去重逻辑、修改过程脚本、事务预演、正式发布、回归验证和追加日志。
+2. 读取本地 `db_backups/update_timely_kit_tracking_result_multi_detail_orders_20260630.sql` 第 379 至 425 行，并读取线上过程定义末段，确认两者均按“订单号 + 缺件生产订单号”执行最终 `ROW_NUMBER()` 去重。
+3. 检查该 SQL 脚本的 Git 状态，确认修改前脚本没有用户的未提交改动，可以在现有最新过程脚本上进行最小范围修改。
+4. 修改最终去重键：当 `[缺件属性] = N'外购'` 时，优先使用“缺件物料编码 + SAP 行号”；非外购件仍优先使用缺件生产订单号，缺件生产订单号为空时仍回退到“缺件物料编码 + SAP 行号”。
+5. 创建临时事务预演脚本，在同一数据库会话中先将线上旧过程对订单 8238 的结果写入临时表，然后开启事务、加载新过程定义、再次执行过程并比较前后结果，最后回滚事务。
+6. 事务预演结果：修改前 6 条、修改后 7 条；唯一新增记录为 SAP 单据 `8238`、SAP 行号 `33`、物料 `23601-032-A6x6x25`（平键）、缺件数量 2、缺件属性“外购”、缺件生产订单号 `4957`。
+7. 事务预演未发现减少记录，也未发现相同 SAP 单据和 SAP 行号的重复结果；事务正常回滚。
+8. 删除仅用于预演的临时 SQL 文件，确认线上过程修改时间仍为 `2026-07-15 14:25:11.830` 且尚未包含新分组分支，证明预演没有残留线上修改。
+9. 对正式脚本执行 `git diff --check`，未发现空白符或补丁格式错误；差异仅为最终分组 `CASE` 中新增一条外购判断。
+10. 使用 `sqlcmd -b` 正式执行 `db_backups/update_timely_kit_tracking_result_multi_detail_orders_20260630.sql`，成功发布 `dbo.生产管理_及时齐套跟踪结果_查询`。
+11. 发布后通过存储过程方式执行订单号 8238，结果为 7 条，SAP 行号为 `2、3、21、28、33、48、75`；SAP 视图中未发货数量大于 0 的记录同样为 7 条、7 个不同 SAP 行。
+12. 发布后确认行号 33 的平键和行号 48 的螺钉均正常返回，虽然两条的缺件生产订单号均为 `4957`，但不再互相覆盖；结果中相同 SAP 单据和 SAP 行号的重复数量为 0。
+13. 首次使用 SQL `LIKE` 检查线上定义时，由于方括号在 `LIKE` 模式中具有特殊含义而得到错误的 0；改用 `CHARINDEX` 精确检查后，确认线上定义已经包含新的外购分组分支，并仍保留自制件按缺件生产订单号归并的分支。
+14. 线上过程最新修改时间为 `2026-07-22 09:00:01.960`。
+15. 保留工作区内原有的其他未提交修改，没有覆盖或撤销与本任务无关的文件。
+
+### 修改文件
+- `db_backups/update_timely_kit_tracking_result_multi_detail_orders_20260630.sql`
+- `gptlog-process/gpdlog.md`
+
+### 结论
+- 已修正外购物料共用“在制采购”编号时被末级去重误合并的问题。
+- 外购件现在按“订单号 + 物料编码 + SAP 行号”区分，自制件仍按“订单号 + 缺件生产订单号”归并，原有自制件逻辑未改变。
+- 订单 8238 的平键和螺钉现在都会返回，存储过程结果已由 6 条恢复为与 SAP 视图一致的 7 条。
+- 修正后的存储过程已经正式发布到 `192.168.2.92 / YL_MESDB`。
+
+### 验证结果
+- 事务预演：修改前 6 条，修改后 7 条，唯一新增 SAP 行号 33，无减少、无重复，随后回滚成功。
+- 正式发布：成功。
+- 线上新外购分组分支：存在。
+- 线上原自制件归并分支：保留。
+- SAP 视图订单 8238：7 条，7 个不同 SAP 行。
+- 存储过程订单 8238：7 条，SAP 行号完整。
+- 存储过程结果重复 SAP 键：0。
+- `git diff --check`：通过。
+
+## 2026-07-22 修正工时校验人员工时在加工工时为零时的显示
+
+### 用户提问
+- 用户要求修改 `src/views/ProductionManagement/WorkHoursCheck/index.vue` 的“人员工时”列，解决 `scope.row.加工工时 = 0` 时的计算问题。
+
+### 执行过程
+1. 检查“人员工时”列、设备工时列、编辑表单及 SAP 上传逻辑，确认业务口径为：加工工时大于 0 时属于设备工时，人员工时显示 0；加工工时为 0 时，人员工时显示“总时长 / 60”。
+2. 检查工作区差异，发现该行已有未提交尝试，条件使用多个 `OR` 判断，导致条件恒为真，且真值分支直接返回加工工时，无法正确处理加工工时为 0 的情况。
+3. 首次应用补丁时，该行在读取后发生并行变化，补丁因上下文不一致而未应用；重新读取最新文件后，确认代码恢复为 `scope.row.加工工时 != NULL ? 0 : scope.row.总时长 / 60`。
+4. 将表达式修改为：先用 `Number(scope.row.加工工时 || 0)` 统一数值类型；等于 0 时显示 `Number(scope.row.总时长 || 0) / 60`，否则显示 0；保留原两位小数及末尾零清理规则。
+5. 使用 Node 复算边界值：加工工时为数值 0、字符串 `"0"`、`null` 和空字符串时，人员工时分别按总时长折算；加工工时为正数或正数字符串时显示 0。
+6. `git diff --check` 通过。随后启动页面 ESLint，但用户切换到新任务时该检查被中断；本次表达式本身未产生语法错误。
+
+### 修改文件
+- `src/views/ProductionManagement/WorkHoursCheck/index.vue`
+
+### 结论
+- 加工工时为 0、`"0"`、空值或空字符串时，人员工时现在正确显示“总时长 / 60”。
+- 加工工时大于 0 时，人员工时显示 0。
+
+### 验证结果
+- 加工工时 0、总时长 3600：显示 60。
+- 加工工时 `"0"`、总时长 3600：显示 60。
+- 加工工时 `null`、总时长 1800：显示 30。
+- 加工工时 1200、总时长 3600：显示 0。
+- `git diff --check`：通过。
+
+## 2026-07-22 增加设计报工工时校验数据权限
+
+### 用户提问
+- 用户要求修改 `ResearchManagement/DesignReportTask/Check/index` 页面数据权限：普通用户只能查看自己创建任务或自己报工的数据；角色包含“领导”或“管理员”的用户可以查看全部数据。
+
+### 执行过程
+1. 检索页面路径，确认项目中的实际文件为 `src/views/ProductionManagement/DesignReportTask/Check/index.vue`，页面查询过程为 `dbo.设计报工_工时校验_查询`。
+2. 检查审核页面查询参数、当前用户获取方式和存储过程定义。修改前页面未传当前用户或角色，线上校验查询过程只有 8 个筛选参数，并直接调用无权限限制的 `dbo.设计报工_记录_查询`。
+3. 检查本模块已有的 `add_design_report_hours_report_permissions_20260720.sql` 和工时报表页面，确认现有权限口径使用当前用户名、角色编号及 `登录基础数据_角色信息.Roles_Function`，角色功能包含“领导”或“管理员”时可查看全部。
+4. 核对线上表结构：任务表具有 `创建人` 字段；报工记录表具有 `操作人ID` 和 `操作人` 字段；角色表包含 `Roles_number` 和 `Roles_Function`。
+5. 查询线上特权角色，确认当前包含超级管理员、质量部领导、管理员、采购部领导、设备管理员和技术部领导等角色，均可按“领导/管理员”关键字识别。
+6. 修改审核页面 `buildSearchParams()`，增加 `当前操作人` 和 `角色编号` 参数；增加 `currentRoleId()`，沿用模块现有方式从 Vuex `token` getter 取得角色编号。
+7. 新增 `db_backups/add_design_report_check_permissions_20260722.sql`，重新定义 `dbo.设计报工_工时校验_查询`。过程保留原 8 个筛选参数和返回字段，并增加 `@当前操作人`、`@角色编号` 两个可选参数。
+8. 新过程通过角色表判断 `Roles_Function` 是否包含“领导”或“管理员”。特权角色不限制数据；普通角色必须满足任务创建人等于当前用户，或报工操作人等于当前用户；当前用户名为空且不是特权角色时不返回数据。
+9. 创建临时事务预演脚本，在事务内加载新过程并测试四种身份：普通用户“张立柱”返回 53 条，空用户名返回 0 条，技术部领导返回全部 184 条，超级管理员返回全部 184 条。
+10. 对普通用户的 53 条结果逐行核对，越权记录为 0；反向检查全部任务创建人或报工人为“张立柱”的记录，遗漏记录为 0。
+11. 回滚预演事务并删除临时脚本；确认线上过程仍为原 8 个参数且不含新权限参数，证明预演没有残留修改。
+12. 对正式 SQL 和页面差异执行 `git diff --check`，检查通过。
+13. 正式执行 `add_design_report_check_permissions_20260722.sql`，成功发布 `dbo.设计报工_工时校验_查询` 到 `192.168.2.92 / YL_MESDB`。
+14. 发布后重新调用线上过程：普通用户“张立柱”返回 53 条，与独立 SQL 计算的本人相关记录 53 条一致；空用户名返回 0 条；技术部领导和超级管理员均返回当前全部 184 条。
+15. 检查线上过程元数据，确认参数已从 8 个增加到 10 个，包含当前操作人和角色编号，且同时包含“领导”和“管理员”角色判断；线上修改时间为 `2026-07-22 10:22:33.010`。
+16. 执行页面 ESLint。完整规则检查发现页面原有第 58 行属性顺序警告和第 315 行函数括号空格错误，均不在本次差异中；临时关闭这两条既有规则后重新检查，本次修改通过，仅有依赖数据过期提示。
+17. 保留工作区内其他未提交修改，没有覆盖或撤销与本任务无关的文件。
+
+### 修改文件
+- `src/views/ProductionManagement/DesignReportTask/Check/index.vue`
+- `db_backups/add_design_report_check_permissions_20260722.sql`
+- `gptlog-process/gpdlog.md`
+
+### 结论
+- 设计报工工时校验页面现在由数据库查询过程执行数据权限，不依赖前端返回后再过滤。
+- 普通用户只能查看自己创建任务产生的报工记录，或操作人为自己的报工记录。
+- 当前用户名为空的普通角色不返回数据，避免登录信息缺失时放开权限。
+- `Roles_Function` 包含“领导”或“管理员”的角色可以查看全部数据。
+- 权限过程已正式发布到生产数据库。
+
+### 验证结果
+- 普通用户“张立柱”：53 条；预期 53 条；越权 0；遗漏 0。
+- 普通角色且当前用户为空：0 条。
+- 技术部领导：184 条，与全部记录一致。
+- 超级管理员：184 条，与全部记录一致。
+- 线上过程参数：10 个，权限参数及角色判断均存在。
+- `git diff --check`：通过。
+- 页面 ESLint（排除两项既有规则）：通过。
+
+## 2026-07-22 为设计任务和设计报工增加附件功能
+
+### 用户提问
+- 用户要求在设计任务和设计报工界面增加“上传附件”和“查看附件”功能，上传和查看方法参考 `ProcessManagement/PartDrawing/index`。
+- 用户特别说明附件不一定是 PDF，需要正确处理不同文件类型的查看方式；还要求解决上传文件重名覆盖问题，可使用时间戳或更可靠的唯一命名方案。
+
+### 执行过程
+1. 检索参考页面和目标页面，确认参考文件为 `src/views/ProcessManagement/PartDrawing/index.vue`，目标文件为 `src/views/ProductionManagement/DesignReportTask/Task/index.vue` 和 `Report/index.vue`；两个目标文件修改前没有未提交差异。
+2. 拆解参考页面上传链路：使用 `MESUploadFile.ashx` 接收 `file + params`，参数包含业务编号、表名、上传人和上传时间；文件访问根路径为 `/webpage/part/`；参考页的 PDF 查看使用 `seepdf`。
+3. 查询线上 `物料基础数据_零件图纸` 表结构和近期数据，确认通用上传表具有 `id、num、uid、name、suffix、是否启用、worker、uploadTime` 8 个字段，且上传接口按实际文件名保存物理文件。
+4. 查询 `工艺管理_图纸维护_查看图纸` 当前定义并使用只读 HTTP 请求核对文件路径。确认近期文件不能通过 `uid.pdf` 访问，而可以通过 URL 编码后的 `name.pdf` 访问；因此数据库 `uid` 不是当前真实文件路径，物理重名必须在上传前处理。
+5. 确定附件按设计任务 `DID` 共享：设计任务页面和设计报工页面查看同一任务时使用同一附件集合，允许一个任务上传多份附件。
+6. 新增 `db_backups/create_design_report_attachments_20260722.sql`，创建与通用上传接口兼容的 `dbo.MES_设计报工_附件` 表，字段顺序和基础上传表保持一致，并增加按 `num、是否启用、id` 查询的索引。
+7. 在同一脚本中新增 `dbo.设计报工_附件_查询`，按 `DID` 查询启用附件，返回附件 ID、原文件名、物理存储文件名、文件类型、上传人和上传时间。
+8. 设计物理文件唯一命名规则：`DESIGN_TASK_<DID>_<年月日时分秒毫秒>_<随机串>__<清洗后的原文件名>.<扩展名>`。时间戳和浏览器密码学随机数共同保证唯一，任务 ID 便于定位；双下划线作为内部名前缀和原文件名的分隔符。
+9. 文件名清洗会替换 Windows 文件系统不允许的字符、去除尾部点号和空格、限制总长度；上传时创建真正的新 `File`/`Blob` 并将唯一名称作为 multipart 文件名提交，因此数据库记录和物理目录都不会因同名附件互相覆盖。
+10. 查询过程通过双下划线分隔符去掉内部唯一前缀，列表仍向用户显示原文件名；同名附件可以并存，并可通过上传人和上传时间区分。
+11. 新增共享组件 `src/views/ProductionManagement/DesignReportTask/components/TaskAttachments.vue`，集中实现附件对话框、最多 10 个文件选择、单文件 100MB 限制、逐个上传、结果统计、附件查询、文件类型显示、预览和下载。
+12. 非 PDF 查看采用分流策略：PDF、PNG/JPG/JPEG/GIF/BMP/WebP 和 TXT/CSV/JSON/Markdown 等浏览器可安全展示格式在新窗口预览；Word、Excel、压缩包及其他格式通过 Blob 下载并使用原文件名保存，由本机程序查看。
+13. 安全复核时将 SVG、HTML、HTM 和 XML 从直接预览列表移除，改为下载后查看，避免主动内容在附件站点直接执行。
+14. 在设计任务页面操作列增加带上传和查看图标的“上传附件”“查看附件”按钮，将操作列宽度从 340 调整为 540，并注册共享附件组件。
+15. 在设计报工页面操作列增加相同两个按钮，将操作列宽度从 440 调整为 640，并注册同一共享附件组件；两个页面调用统一的 `openAttachments(row, mode)`。
+16. 初次运行共享组件 ESLint 时发现文件名清洗正则的控制字符范围触发 `no-control-regex`；考虑浏览器文件名不会包含该范围，移除控制字符范围并保留 Windows 非法字符处理，随后三个 Vue 文件 ESLint 全部通过。
+17. 创建临时事务预演脚本，在事务内创建附件表和过程，插入一个启用的 DOCX 示例和一个停用的 PDF 示例。查询正确返回 `报价附件_最终版.docx`，保留唯一物理文件名，停用附件未返回，索引存在。
+18. 回滚事务、删除临时预演脚本，并确认线上附件表和过程均不存在，证明预演没有残留对象或数据。
+19. 正式执行 `create_design_report_attachments_20260722.sql`，成功发布 `MES_设计报工_附件` 和 `设计报工_附件_查询` 到 `192.168.2.92 / YL_MESDB`。
+20. 发布后检查线上对象：附件表共 8 个兼容字段，任务查询索引存在，查询过程有 1 个 `@DID` 参数，修改时间为 `2026-07-22 13:38:17.420`；新表当前 0 条数据。
+21. 执行 `npm run build`，Webpack 生产构建成功，仅保留项目原有字体、图片和入口包体积警告。
+22. 使用相同随机算法在同一批次生成 1000 个标识，1000 个均唯一，重复数为 0；实际文件名还同时包含 DID 和毫秒时间戳。
+23. 启动本地开发服务器。因 1997 端口已有服务，新实例自动使用 `https://127.0.0.1:1998/`；HTTP 状态为 200，最后一次热更新编译成功。
+24. 最终对 SQL、共享组件和两个页面执行 `git diff --check`，检查通过；未覆盖或撤销工作区内其他用户修改。
+25. 没有向生产附件目录上传测试文件：现有上传接口没有提供可确认删除物理文件的测试清理能力，为避免留下孤立测试文件，本次使用线上既有上传行为、兼容表结构、数据库事务、前端 ESLint、生产构建和开发服务器编译完成验证。
+
+### 修改文件
+- `src/views/ProductionManagement/DesignReportTask/Task/index.vue`
+- `src/views/ProductionManagement/DesignReportTask/Report/index.vue`
+- `src/views/ProductionManagement/DesignReportTask/components/TaskAttachments.vue`
+- `db_backups/create_design_report_attachments_20260722.sql`
+- `gptlog-process/gpdlog.md`
+
+### 结论
+- 设计任务和设计报工页面均已增加上传附件和查看附件入口，并共享同一套附件数据和组件逻辑。
+- 附件不限制为 PDF；浏览器适合展示的安全格式直接预览，Office、压缩包和主动内容格式下载后查看。
+- 物理文件名采用 DID、毫秒时间戳、密码学随机串和原文件名组合，同名附件不会覆盖；界面仍显示原文件名。
+- 附件数据库表和查询过程已经正式发布到生产数据库。
+- 本地开发服务器运行于 `https://127.0.0.1:1998/`。
+
+### 验证结果
+- 共享组件 ESLint：通过。
+- 设计任务页面 ESLint：通过。
+- 设计报工页面 ESLint：通过。
+- 数据库事务预演：通过，DOCX 原文件名还原正确，停用附件过滤正确，随后回滚成功。
+- 数据库正式发布：成功。
+- 线上附件表字段：8 个，与通用上传接口参考表兼容。
+- 线上任务附件索引：存在。
+- 线上附件查询过程：存在，参数 1 个。
+- 线上附件表当前数据：0 条。
+- 1000 次随机标识测试：1000 个唯一，0 个重复。
+- `npm run build`：通过，存在非阻断包体积警告。
+- 开发服务器：`https://127.0.0.1:1998/`，状态 200，热更新编译成功。
+- `git diff --check`：通过。
+- 生产物理文件上传测试：未执行，避免遗留无法确认清理的孤立测试文件。
+- 安全预览类型调整后的最终 `npm run build`：再次通过，生成 `static/js/app.2f4b894c.js`，仅有原有包体积警告。
+
+## 2026-07-22 增加研发类别立项号必填校验
+
+### 用户提问
+- 用户要求修改 `ResearchManagement/DesignReportTask/Task/index`：当类别选择“研发”时，研发立项号必须填写。
+
+### 执行过程
+1. 定位项目中的实际页面路径为 `src/views/ProductionManagement/DesignReportTask/Task/index.vue`，并保留该文件中刚增加的附件功能修改。
+2. 检查任务表单、规则对象、编辑回填和保存入口，确认保存统一通过 `this.$refs.taskForm.validate()`，但原表单只有任务描述必填规则；类别和研发立项号表单项均未绑定校验属性。
+3. 为研发立项号表单项增加 `prop="研发立项号"`，并通过 `:required="formData.类别 === '研发'"` 动态显示必填标识。
+4. 在规则对象中增加研发立项号自定义校验器，失焦和内容变化时触发。
+5. 新增 `validateResearchProjectNo`：类别严格等于“研发”且研发立项号去除首尾空格后为空时，返回“请输入研发立项号”；其他情况通过。
+6. 为类别选择增加 `handleCategoryChange`。从“研发”切换到其他类别时，清除研发立项号已有的校验错误，避免非研发类别残留红色错误状态。
+7. 使用独立逻辑复算三种边界：研发且空值为不通过；研发且填写 `RD-2026-001` 为通过；订单类别且空值为通过。
+8. 执行该页面 ESLint，检查通过，仅有项目依赖数据过期提示。
+9. 检查本地开发服务器 `https://127.0.0.1:1998/`，状态为 200，最终热更新 Webpack 编译成功。
+10. 执行 `git diff --check`，检查通过；本次未修改数据库对象或业务数据，也未覆盖工作区内其他修改。
+
+### 修改文件
+- `src/views/ProductionManagement/DesignReportTask/Task/index.vue`
+- `gptlog-process/gpdlog.md`
+
+### 结论
+- 新建或编辑设计任务时，类别为“研发”且研发立项号为空或仅包含空格，保存会被阻止并提示“请输入研发立项号”。
+- 类别不是“研发”时，研发立项号仍为可选字段。
+- 从研发切换到其他类别后，旧的必填错误会自动清除。
+
+### 验证结果
+- 研发 + 空立项号：校验失败。
+- 研发 + `RD-2026-001`：校验通过。
+- 订单 + 空立项号：校验通过。
+- 页面 ESLint：通过。
+- 开发服务器热更新编译：通过。
+- `git diff --check`：通过。
+- 数据库修改：无。
+
+## 2026-07-22 为设计报工列表增加五分钟静默刷新
+
+### 用户提问
+- 用户要求修改 `ResearchManagement/DesignReportTask/Report/index`，在不影响现有操作的情况下，每 5 分钟自动刷新一次列表。
+
+### 执行过程
+1. 定位项目中的实际页面为 `src/views/ProductionManagement/DesignReportTask/Report/index.vue`，并保留该文件中已增加的附件上传和查看功能。
+2. 检查页面生命周期、查询方法、开始/结束报工、说明弹窗、附件弹窗和通用操作方法，确认原页面没有定时器及生命周期清理逻辑，`searchTable()` 每次都会显示表格加载遮罩和查询失败消息。
+3. 检索项目其他自动刷新实现，发现部分页面直接使用 `setInterval(this.searchTable, 300000)`，该方式会在用户操作和弹窗期间刷新，也无法处理请求返回顺序，因此本页面未直接照搬。
+4. 定义 `AUTO_REFRESH_INTERVAL = 5 * 60 * 1000`，即 300000 毫秒；在页面数据中增加 `refreshTimer` 和 `querySequence`。
+5. 新增 `startAutoRefresh` 和 `stopAutoRefresh`。组件挂载或从 keep-alive 恢复时启动定时器，组件停用或销毁时清除定时器；启动方法具备幂等判断，避免 mounted 和 activated 重复创建定时器。
+6. 新增 `shouldSkipAutoRefresh`，当页面不可见、正在手工查询、正在执行报工/说明操作、结束报工弹窗打开、说明弹窗打开或附件对话框打开时，自动刷新直接跳过。
+7. 新增 `refreshTableSilently`，只在页面空闲时调用 `searchTable({ silent: true })`，自动刷新不显示表格加载遮罩，也不会弹出查询失败消息。
+8. 扩展 `searchTable(options)`，保留原手工查询调用方式；只有明确传入 `silent: true` 才进入静默模式，所以查询按钮、回车查询和业务操作后的主动刷新行为保持不变。
+9. 每次查询递增 `querySequence` 并保存本次请求编号。响应返回时只有编号仍为最新的请求才允许更新列表，防止较早发起的自动刷新覆盖之后发起的手工查询结果。
+10. 静默请求返回时再次检查操作状态。如果自动请求发出后用户打开弹窗或开始操作，该响应会被忽略，不会在操作过程中替换表格行。
+11. 执行页面 ESLint，检查通过，仅有项目依赖数据过期提示。
+12. 执行 `npm run build`，生产构建成功，生成 `static/js/app.074e6ff6.js`；仅保留项目原有包体积警告。
+13. 复算定时周期和跳过条件：周期为 300000 毫秒；操作中、结束弹窗、说明弹窗、附件弹窗和页面隐藏场景均返回跳过。
+14. 检查本地开发服务器 `https://127.0.0.1:1998/`，状态为 200，最终热更新 Webpack 编译成功。
+15. 执行 `git diff --check`，检查通过；本次未修改数据库对象或业务数据，也未覆盖工作区内其他修改。
+
+### 修改文件
+- `src/views/ProductionManagement/DesignReportTask/Report/index.vue`
+- `gptlog-process/gpdlog.md`
+
+### 结论
+- 设计报工列表现在每 5 分钟执行一次后台静默刷新。
+- 手工查询、开始/结束报工、保存说明、结束/说明弹窗和附件上传/查看均不会被自动刷新打断。
+- 页面隐藏、离开或销毁时不会继续无效刷新；返回页面后会自动恢复定时器。
+- 并发请求使用序号保护，旧自动请求不会覆盖较新的手工查询结果。
+
+### 验证结果
+- 自动刷新周期：300000 毫秒。
+- 空闲状态：允许静默刷新。
+- 操作中：跳过自动刷新。
+- 结束报工弹窗打开：跳过自动刷新。