634 lines
61 KiB
Markdown
634 lines
61 KiB
Markdown
# GPT 执行过程日志
|
||
|
||
## 2026-07-02 装配中心任务看板修改
|
||
|
||
1. 接收任务：根据 `doc/装配中心任务看板修改方案.docx` 修改 `src/views/index.vue`，并创建 work 文档与过程日志。
|
||
2. 初始检查：读取项目目录、doc 目录、现有 `src/views/index.vue`、参考项目 `C:\WorkYuanLy\MES_Manage_View_V20\src\views`。
|
||
3. 文档解析：使用 .NET Zip 方式解包 docx，读取 `word/document.xml`，确认方案要求包括移除缺件/已完成/可执行/及时送检/加急模块，右侧放发货和在制列表，左侧新增 16 行分类汇总表。
|
||
4. 截图确认：查看 docx 内 `image1.png` 当前页面截图和 `image2.png` 新增表格样式截图。
|
||
5. 参考页面读取：使用 UTF-8 读取发货状态、阀类任务、系统类任务、装配及时送检页面，确认接口和字段。
|
||
6. 用户中断并要求先上传远程：暂停页面修改，检查本地目录不是 Git 仓库。
|
||
7. 远程确认：访问 `http://154.8.160.151:3000/api/v1/version`，确认远程服务可用。
|
||
8. 仓库处理：账号下已有仓库与当前项目不完全匹配，因此创建新仓库 `zhangxinyang/zhuangpei-task-kanban`。
|
||
9. 基线提交：执行 `git init -b main`，提交修改前代码，提交号 `e003b23 chore: baseline before dashboard update`。
|
||
10. 基线推送：将 `main` 推送到 `http://154.8.160.151:3000/zhangxinyang/zhuangpei-task-kanban`，远程地址未写入密码。
|
||
11. 页面修改：重写 `src/views/index.vue`，保留缩放布局和全局注入的 `CreateData`、`ExecDatabase`。
|
||
12. 布局调整：顶部改为派工汇总、齐套汇总、加急汇总、滞留汇总、装配合格率、异常未关闭 6 个卡片；左侧新增分类汇总表；右侧展示发货状态列表和在制任务列表。
|
||
13. 数据调整：移除不再需要的缺件明细、已完成任务、可执行任务数、及时送检数、加急任务总数查询。
|
||
14. 聚合逻辑：新增阀类、系统类、滞留查询，统一按 `计划数量 > 完成数量` 过滤，再按派工、齐套、加急、滞留统计。
|
||
15. 分类逻辑：阀类按产品名称是否包含“阀”分为阀类/其他类；系统类按指派对象包含“电气”或“机械/装配”分为电气类/装配类。
|
||
16. 构建验证：执行 `npm run build` 两次，均成功；第二次在调整 16 行表行高后再次通过。
|
||
17. 文档归档：创建 `work/装配中心任务看板修改方案`，复制原始方案 docx，新增 README 和 01-06 文档。
|
||
18. 本地预览：5173 端口已被其他进程占用，启动 Vite 到 `http://localhost:5174/`，访问入口返回 `StatusCode=200`。
|
||
|
||
## 2026-07-03 日志记录规则确认
|
||
|
||
### 提问
|
||
|
||
用户要求建立后续日志记录规则：每次 GPT/Codex 执行完毕后，必须将完整执行过程日志追加至 `gptlog-process/gpdlog.md`，日志需要包含提问、结论和完整执行过程，并且必须使用中文记录。
|
||
|
||
### 执行过程
|
||
|
||
1. 接收用户规则要求，确认该要求适用于后续每次 GPT/Codex 任务执行结束后的记录动作。
|
||
2. 检查 `gptlog-process` 目录，确认目录已存在。
|
||
3. 检查 `gptlog-process/gpdlog.md`，确认日志文件已存在且已有历史中文执行记录。
|
||
4. 将本次规则确认作为新的日志段落追加到 `gptlog-process/gpdlog.md`。
|
||
|
||
### 结论
|
||
|
||
后续每次 GPT/Codex 执行完毕后，将按用户要求把中文执行日志追加到 `gptlog-process/gpdlog.md`，内容包含提问、结论和完整执行过程。
|
||
|
||
## 2026-07-03 装配任务分类汇总显示调整
|
||
|
||
### 提问
|
||
|
||
用户要求修改 `C:\WorkYuanLy\装配任务看板\src\views\index.vue`：
|
||
|
||
1. “装配任务分类汇总”中加急数量和滞留数量改成与指标列相同颜色。
|
||
2. “装配任务分类汇总”中分类图片不要作为背景图片，改成真实图片显示，布局为文字和数量在左、图片在右。
|
||
3. “发货状态列表”数据有几条就显示几条，不要重复填充。
|
||
4. 随后用户补充：四个分类图片是不一样的，图片路径在 `C:\WorkYuanLy\装配任务看板\src\assets\dashboard\`。
|
||
|
||
### 执行过程
|
||
|
||
1. 读取 `src/views/index.vue`，定位分类汇总表模板、数量列样式、分类图片显示样式、发货列表显示函数和滚动函数。
|
||
2. 检查当前工作区状态，确认存在与本次任务无关的未提交文件，例如 `dist.zip`、`AGENTS.md`、旧 `work` 目录和临时 Word 锁文件；本次不处理这些无关项。
|
||
3. 将分类汇总数量列从固定白色改为绑定 `metric-${row.metricKey}` 类，使数量列颜色与指标列保持一致，包括加急红色、滞留橙色。
|
||
4. 将分类图片从伪元素背景改为 `<img>` 真实图片元素，布局调整为左侧分类名称和汇总数量、右侧图片。
|
||
5. 修改发货列表显示逻辑：`deliveryDisplayRows` 调用非循环模式，少于可见行数时按实际条数显示，不再用取模方式重复补满。
|
||
6. 调整发货列表滚动逻辑：当发货数据条数小于等于可见行数时，偏移量固定为 0；超过可见行数时顺序滚动，到末尾后回到开头。
|
||
7. 根据用户补充要求检查 `src/assets/dashboard` 目录，确认存在 `阀.png`、`其他.png`、`电气.png`、`机械.png`。
|
||
8. 修改图片 import：分别导入 `阀.png`、`其他.png`、`电气.png`、`机械.png`。
|
||
9. 修改分类配置：`阀` 使用 `阀.png`，`其他` 使用 `其他.png`，`电气` 使用 `电气.png`，`装配` 使用 `机械.png`。
|
||
10. 修改聚合行数据，给每个分类行附加对应 `image` 字段，模板使用 `row.image` 显示。
|
||
11. 调整 `.subclass-image` 样式为 `object-fit: contain`，避免产品图被裁切，并增加深色图片底板、边框和阴影以匹配看板风格。
|
||
12. 执行 `npm run build` 验证，构建成功，四个中文图片资源均被正常打包。
|
||
|
||
### 结论
|
||
|
||
已完成本次 `index.vue` 修改：分类汇总数量颜色与指标列一致，分类图片改为左文右图的真实图片显示，四个分类分别使用不同图片；发货状态列表不再重复填充不足的行数。构建验证通过，只有 Vite chunk size 和 Sass legacy JS API 的常规警告。
|
||
|
||
## 2026-07-03 修改质检测试任务看板
|
||
|
||
### 提问
|
||
|
||
用户要求先上传远程修改，然后根据 `doc/修改质检测试任务看板.docx` 修改页面 `C:\WorkYuanLy\装配任务看板\src\views\TestTaskDashboard.vue`。修改完成后，在 `work` 下创建对应路径，复制原始文档，并新增或修改 `01-项目功能内容`、`02-项目程序开发详细步骤`、`03-推进台账`、`04-任务矩阵`、`05-验收证据`、`06-决策记录`、README 索引，同时将完整中文执行过程追加到 `gptlog-process/gpdlog.md`。
|
||
|
||
### 执行过程
|
||
|
||
1. 检查 Git 状态，发现上一轮 `index.vue` 分类汇总修改、四张分类图片和 `gptlog-process/gpdlog.md` 尚未推送，同时 `TestTaskDashboard.vue` 已存在一处未提交差异。
|
||
2. 为避免两轮需求混在一起，先暂存上一轮相关文件：`src/views/index.vue`、`src/assets/dashboard/阀.png`、`src/assets/dashboard/其他.png`、`src/assets/dashboard/电气.png`、`src/assets/dashboard/机械.png`、`gptlog-process/gpdlog.md`。
|
||
3. 执行提交 `feat: refine aggregate dashboard display`，提交号 `765ed0a`。
|
||
4. 执行 `git push origin main`，将上一轮修改推送到远程 `origin/main`。
|
||
5. 读取 `doc` 目录，确认存在 `修改质检测试任务看板.docx`。
|
||
6. 使用 docx 解包方式读取 `word/document.xml`，提取到需求：注释掉可执行任务数和旧加急任务数，增加加急汇总和滞留汇总；注释掉在制任务缺件明细；已完工任务放在测试任务汇总下面；发货状态列表和测试装配任务列表放在右侧；左侧增加测试任务汇总且不需要齐套和派工；滞留取及时检验报表任务数；加急取 `质量管理_测试装配任务_查询` 中加急总数大于 0 的任务数。
|
||
7. 读取当前 `src/views/TestTaskDashboard.vue`，确认原布局为顶部 5 卡片、左侧发货/测试列表、右侧缺件/已完工列表。
|
||
8. 读取参考页面 `src/views/index.vue`，确认分类汇总表布局参考。
|
||
9. 读取参考页面 `C:\WorkYuanLy\MES_Manage_View_V20\src\views\QualityManagement\CheckTask\punctualInspection.vue`，确认及时检验报表存储过程为 `质量管理_及时检验报表_查询`，并确认参数结构和属性 `2` 对应装配。
|
||
10. 读取参考页面 `C:\WorkYuanLy\MES_Manage_View_V20\src\views\QualityManagement\TestAssemblyTask\index.vue`，确认测试装配任务查询使用 `质量管理_测试装配任务_查询` 和任务类型、生产订单、销售订单、物料名称、物料编码参数。
|
||
11. 修改 `TestTaskDashboard.vue` 模板：左侧改为“测试任务汇总”和“已完工任务”，右侧改为“发货状态列表”和“测试装配任务列表”。
|
||
12. 从模板中移除“在制任务缺件明细”面板，避免页面空位。
|
||
13. 新增测试任务汇总表，按“阀类/系统类”分组展示“加急/滞留”两个指标。
|
||
14. 新增 `rawTestAssemblyRows` 和 `stagnationRows` 数据源，用于汇总计算。
|
||
15. 新增 `testSummaryGroups`、`testSummaryMetrics` 和 `testSummaryRows`，生成左侧测试任务汇总表行。
|
||
16. 新增 `searchStagnationData`，调用 `质量管理_及时检验报表_查询`，参数按参考页面构造并设置 `属性` 为 `2`。
|
||
17. 调整 `searchDashboardData`，新增滞留查询，移除缺件明细查询。
|
||
18. 恢复 `searchTestAssemblyTaskData` 对查询参数 `param` 的传递，使其与参考页面一致。
|
||
19. 修改 `applyTestAssemblyTaskData`：保存原始测试装配任务行，计算待协助、加急汇总、异常未关闭，并继续写入测试装配任务列表。
|
||
20. 修改 `applyQualityTimelinessData`：质检及时率写入新的顶部卡片索引。
|
||
21. 新增 `applyStagnationData`：保存及时检验报表行，并将滞留汇总设置为结果行数。
|
||
22. 新增 `isUrgentTask`、`getTaskGroupKey`、`countTestSummaryRows`，分别用于加急识别、阀类/系统类归类和汇总表统计。
|
||
23. 将顶部 `summaryCards` 改为 `reactive` 数组，并改为 5 项：待协助任务数、加急汇总、滞留汇总、质检及时率、异常未关闭消息数。
|
||
24. 修改样式：主区域改为左窄右宽，左列上下展示测试任务汇总和已完工任务，右列上下展示发货状态和测试装配任务。
|
||
25. 新增测试任务汇总表样式，包括项目列、指标列、数量列，以及加急红色、滞留橙色。
|
||
26. 删除不再使用的缺件明细查询函数、缺件行数据和缺件列配置。
|
||
27. 执行 `npm run build`，构建成功；Vite 正常生成 `TestTaskDashboard` 相关 JS/CSS 产物。
|
||
28. 创建 `work/修改质检测试任务看板`。
|
||
29. 将原始 `doc/修改质检测试任务看板.docx` 复制到 `work/修改质检测试任务看板/修改质检测试任务看板.docx`。
|
||
30. 在 work 目录中新增 README、`01-项目功能内容.md`、`02-项目程序开发详细步骤.md`、`03-推进台账.md`、`04-任务矩阵.md`、`05-验收证据.md`、`06-决策记录.md`、`07-执行过程日志.md`。
|
||
31. 将本轮完整中文执行日志追加到 `gptlog-process/gpdlog.md`。
|
||
|
||
### 结论
|
||
|
||
已按 `修改质检测试任务看板.docx` 完成 `TestTaskDashboard.vue` 修改：顶部统计卡片已调整，左侧新增测试任务汇总并放置已完工任务，右侧放置发货状态列表和测试装配任务列表，缺件明细已移除；加急汇总来自测试装配任务查询中加急总数大于 0 的任务数，滞留汇总来自及时检验报表任务数。`npm run build` 构建通过。work 目录资料已创建并复制原始 docx。
|
||
|
||
## 2026-07-03 测试任务汇总补回产品列
|
||
|
||
### 提问
|
||
|
||
用户反馈“项目和指标中间的产品怎么没了”，要求将测试任务汇总改成第二张参考图样式，即在“项目”和“指标”之间补回“产品”列，并展示产品图片、产品名称和产品汇总数量。
|
||
|
||
### 执行过程
|
||
|
||
1. 读取 `src/views/TestTaskDashboard.vue` 当前模板、汇总数据结构和样式。
|
||
2. 确认当前“测试任务汇总”为三列：项目、指标、数量，确实缺少产品列。
|
||
3. 修改表头，增加“产品”列。
|
||
4. 修改汇总行模板：项目列显示项目名称和项目汇总数；产品列显示图片、产品名称和产品汇总数；右侧继续显示指标和数量。
|
||
5. 导入 `阀.png`、`其他.png`、`电气.png`、`机械.png` 四张产品图片。
|
||
6. 将测试任务汇总数据结构改为“阀类/系统类”项目下包含“阀/其他/电气/装配”产品，每个产品下展开“加急/滞留”两行。
|
||
7. 新增 `getTaskProductKey`，按任务内容归类到阀、其他、电气、装配。
|
||
8. 新增产品合计和项目合计函数，使产品列和项目列都能显示红色汇总数。
|
||
9. 调整测试任务汇总表样式，使其接近参考图：项目列展示大类及总数，产品列图片在左、名称和数量在右，指标和数量列保持加急红色、滞留橙色。
|
||
10. 执行 `npm run build`，构建成功。
|
||
11. 同步更新 work 目录中的推进台账、任务矩阵、验收证据和决策记录。
|
||
|
||
### 结论
|
||
|
||
已将“测试任务汇总”改为“项目 / 产品 / 指标 / 数量”四列结构，产品列按参考图展示图片、产品名称和产品汇总数；构建验证通过。
|
||
|
||
## 2026-07-03 测试任务汇总总数口径与显示压缩
|
||
|
||
### 提问
|
||
|
||
用户要求修改 `C:\WorkYuanLy\装配任务看板\src\views\TestTaskDashboard.vue`：
|
||
1. 截图部分里面数据太大，超出后看不到。
|
||
2. 产品和项目下的汇总数不对，不能简单使用滞留和加急相加；应使用存储过程 `质量管理_测试装配任务_查询` 返回的所有任务统计。
|
||
3. 大类按物料编码区分阀类和系统类。
|
||
4. 产品阀类和其他类按物料编码判断，包含“阀”的为阀，不包含“阀”的为其他。
|
||
5. 产品电气和机械按指派对象判断，指派对象为机械装配的归机械，指派对象为电气装配的归电气。
|
||
|
||
### 执行过程
|
||
|
||
1. 读取 `src/views/TestTaskDashboard.vue`，确认当前测试任务汇总表包含“项目 / 产品 / 指标 / 数量”四列。
|
||
2. 检查当前汇总逻辑，发现 `getTestProductTotal` 通过加急和滞留两个指标相加得到产品汇总，`getTestGroupTotal` 再累加产品汇总，因此不符合本次要求。
|
||
3. 使用 `rg` 搜索 `质量管理_测试装配任务_查询`、物料编码、指派对象、加急、滞留等关键字，确认目标文件已有测试装配任务查询结果 `rawTestAssemblyRows`。
|
||
4. 读取 `src/views/index.vue` 中已有分类汇总逻辑，参考其字段兜底方式，但本轮按用户要求收紧到“物料编码”和“指派对象”口径。
|
||
5. 读取参考页面 `C:\WorkYuanLy\MES_Manage_View_V20\src\views\QualityManagement\TestAssemblyTask\index.vue`，确认 `质量管理_测试装配任务_查询` 的展示字段包含 `物料编码`。
|
||
6. 修改测试汇总行的 `v-for` key，从 `groupKey-metricKey` 改为 `groupKey-productKey-metricKey`，避免同一项目下不同产品的加急/滞留行出现重复 key。
|
||
7. 将系统类第二个产品名称从“装配”改为“机械”，与“机械装配/电气装配”的指派对象口径一致。
|
||
8. 新增 `getField` 和 `normalizeText`，用于稳定读取返回行中的字段并处理空值。
|
||
9. 新增 `getMaterialCodeText`，优先读取 `物料编码`，同时兜底读取 `零件编码`、`物料编号`、`零件编号`、`产品编码`。
|
||
10. 新增 `getAssignTargetText`，读取 `指派对象` 和 `二次派工`，不再使用 `操作人` 作为电气/机械分类依据，避免人员姓名误命中。
|
||
11. 重写 `getTaskGroupKey`：项目大类优先按物料编码判断，物料编码包含“系统”归系统类，包含“阀”归阀类；缺少明确编码时才兜底使用任务类型、自制件属性、物料名称等文本。
|
||
12. 重写 `getTaskProductKey`：先按项目大类分支处理；系统类内部按指派对象判断，包含“电气装配/电气”归 `systemElectric`，其余归 `systemAssembly`；阀类内部按物料编码是否包含“阀”归 `valveMain` 或 `valveOther`。
|
||
13. 新增 `countTestProductTotal`，直接从 `rawTestAssemblyRows` 统计 `质量管理_测试装配任务_查询` 的全部任务数量。
|
||
14. 修改 `getTestProductTotal`，产品汇总数改为 `countTestProductTotal(productKey)`，不再累加加急和滞留。
|
||
15. 保留 `countTestSummaryRows` 的指标行统计：加急仍统计测试装配任务查询中加急数量大于 0 的任务；滞留仍使用及时检验报表数据源。
|
||
16. 调整左上测试任务汇总表样式：表题高度从 38px 降到 34px，表头从 48px 降到 38px，行高从 55px 降到 40px。
|
||
17. 缩小汇总表列宽、产品图片、项目/产品红色汇总数、指标和数量字号，使 8 行汇总数据能完整落在左上面板内。
|
||
18. 执行 `npm run build`，构建成功，产物正常生成；仅出现既有 Sass legacy JS API 警告和 chunk size 警告。
|
||
19. 复核分类规则，发现如果先按指派对象识别产品，会影响“项目按物料编码区分阀类/系统类”的要求，因此再次调整为先由物料编码确定项目大类，再在系统类内部按指派对象分电气/机械。
|
||
20. 再次执行 `npm run build`，构建成功；仍仅出现既有 Sass legacy JS API 警告和 chunk size 警告。
|
||
21. 检查 `git diff`，确认本轮业务修改只涉及 `src/views/TestTaskDashboard.vue`。
|
||
22. 检查构建后的工作区状态，确认已跟踪的 `dist` 目录未产生变化；工作区已有的 `dist.zip`、`AGENTS.md`、临时 docx 和 work 目录未作为本轮目标处理。
|
||
23. 将本次提问、结论和完整执行过程追加到 `gptlog-process/gpdlog.md`。
|
||
|
||
### 结论
|
||
|
||
已修正测试任务汇总总数口径：项目和产品下的红色汇总数改为基于 `质量管理_测试装配任务_查询` 返回的全部任务按分类直接统计，不再用“加急 + 滞留”相加。阀/其他按物料编码是否包含“阀”分类，电气/机械按指派对象分类。左上汇总表已压缩行高、字号和图片尺寸，避免截图区域数据过大导致下方内容不可见。`npm run build` 构建通过。
|
||
|
||
## 2026-07-03 发货任务列表字段调整与待协助口径核对
|
||
|
||
### 提问
|
||
|
||
用户要求：
|
||
1. 将“发货状态列表”改为“发货任务列表”。
|
||
2. 发货任务列表内去掉“齐套”“发料状态”“操作人”。
|
||
3. 发货任务列表增加“累计工时”，参考 `src/views/index.vue`。
|
||
4. 说明“待协助任务数”当前数据是怎么来的。
|
||
5. 用户提供数据库连接信息，用于核对真实存储过程字段。
|
||
|
||
### 执行过程
|
||
|
||
1. 读取 `src/views/TestTaskDashboard.vue`，定位右侧发货列表标题、`applyDeliveryData` 数据映射和 `taskColumns2` 列配置。
|
||
2. 读取 `src/views/index.vue`，确认参考页面标题为“发货任务列表”，发货数据中 `合同装配工时` 映射到累计工时列。
|
||
3. 初步修改右侧标题：`发货状态列表` 改为 `发货任务列表`。
|
||
4. 修改 `applyDeliveryData`，去掉 `completeSet`、`issueStatus`、`urgentQty`、`operator` 等不再展示字段。
|
||
5. 修改 `taskColumns2`，删除“齐套”“发料状态”“操作人”“装配开工”列，新增“累计工时”列。
|
||
6. 检查本机 SQL Server 工具，确认 `sqlcmd` 可用。
|
||
7. 使用数据库只读查询确认在线库包含 `YL_MESDB`。
|
||
8. 查询 `YL_MESDB` 中存储过程元数据，确认 `装配中心任务看板_质检发货状态查询` 和 `质量管理_测试装配任务_查询` 存在。
|
||
9. 使用 `sys.dm_exec_describe_first_result_set_for_object` 查询返回列，发现当前页面调用的 `装配中心任务看板_质检发货状态查询` 不返回 `合同装配工时`。
|
||
10. 同样查询参考页面使用的 `装配中心任务看板_发货状态查询`，确认该过程返回 `合同装配工时`。
|
||
11. 将 `searchDeliveryData` 调用的过程从 `装配中心任务看板_质检发货状态查询` 改为 `装配中心任务看板_发货状态查询`，确保累计工时列有数据源。
|
||
12. 新增 `formatWorkHours`，按参考页面逻辑将 `合同装配工时` 秒数转换为小时，整数不带小数，非整数保留两位小数。
|
||
13. 将发货数据中的 `accumulatedHours` 改为 `formatWorkHours(item.合同装配工时)`。
|
||
14. 使用数据库执行 `质量管理_测试装配任务_查询` 并按当前页面逻辑聚合，确认当前口径为：`完成数量 > 检验数量` 且 `检测说明` 包含“返工”的任务数。
|
||
15. 数据库核对结果：当前 `质量管理_测试装配任务_查询` 返回 112 条任务，其中 `完成数量 > 检验数量` 的任务为 19 条，符合待协助口径的任务为 0 条。
|
||
16. 执行 `npm run build`，构建成功；仍仅出现既有 Sass legacy JS API 警告和 chunk size 警告。
|
||
17. 检查 `git diff` 和 `git status`，确认本轮业务修改落在 `src/views/TestTaskDashboard.vue`，并追加本日志到 `gptlog-process/gpdlog.md`。
|
||
|
||
### 结论
|
||
|
||
已将右侧列表标题改为“发货任务列表”，并去掉“齐套”“发料状态”“操作人”“装配开工”列，新增“累计工时”列。由于原质检发货状态过程不返回 `合同装配工时`，已切换为参考页面使用的 `装配中心任务看板_发货状态查询`，累计工时按秒转换为小时显示。当前“待协助任务数”来自 `质量管理_测试装配任务_查询`：先筛选 `完成数量 > 检验数量` 的未检完任务，再统计 `检测说明` 包含“返工”的数量；本次数据库核对该数量为 0。`npm run build` 构建通过。
|
||
|
||
## 2026-07-03 质检发货状态过程补充合同装配工时
|
||
|
||
### 提问
|
||
|
||
用户要求不要切换到 `装配中心任务看板_发货状态查询`，而是让 `装配中心任务看板_质检发货状态查询` 返回 `合同装配工时`，并且前端工时单位使用分钟。
|
||
|
||
### 执行过程
|
||
|
||
1. 读取数据库中 `装配中心任务看板_质检发货状态查询` 和 `装配中心任务看板_发货状态查询` 的定义。
|
||
2. 对比确认参考过程 `装配中心任务看板_发货状态查询` 中 `合同装配工时` 来自子查询：按合同号汇总 `View_生产工时视图.总时长`，并通过 `登录基础数据_人员信息` 限定人员班组为“装配”。
|
||
3. 初次使用 `sqlcmd` 管道执行中文 `ALTER PROCEDURE` 后，检查发现过程定义未变化，判断为命令行编码/中文对象处理导致未按预期生效。
|
||
4. 改用 .NET `System.Data.SqlClient` 直接执行 Unicode SQL，成功 `ALTER PROCEDURE dbo.装配中心任务看板_质检发货状态查询`。
|
||
5. 在质检发货状态过程中新增 `LEFT JOIN` 子查询 `htzp`，返回 `ISNULL(htzp.合同装配工时, 0) AS 合同装配工时`，并在 `GROUP BY` 中加入 `htzp.合同装配工时`。
|
||
6. 使用 `sys.dm_exec_describe_first_result_set_for_object` 验证 `装配中心任务看板_质检发货状态查询` 返回列已经包含 `合同装配工时`，类型为 `int`。
|
||
7. 执行 `装配中心任务看板_质检发货状态查询` 验证真实结果集，确认结果表头包含 `合同装配工时`，样例数据中该字段返回 `92`。
|
||
8. 修改 `src/views/TestTaskDashboard.vue`，将 `searchDeliveryData` 调用恢复为 `装配中心任务看板_质检发货状态查询`。
|
||
9. 将前端工时格式化函数从 `formatWorkHours` 改为 `formatWorkMinutes`，按 `合同装配工时 / 60` 转换为分钟显示，整数不带小数，非整数保留两位小数。
|
||
10. 修改发货数据映射，`accumulatedHours` 使用 `formatWorkMinutes(item.合同装配工时)`。
|
||
11. 执行 `npm run build`，构建成功；仍仅出现既有 Sass legacy JS API 警告和 chunk size 警告。
|
||
12. 检查 `git diff` 和关键行，确认前端仍调用 `装配中心任务看板_质检发货状态查询`，累计工时列仍展示，单位已改为分钟。
|
||
13. 将本次提问、结论和完整执行过程追加到 `gptlog-process/gpdlog.md`。
|
||
|
||
### 结论
|
||
|
||
已按要求不切换发货查询过程。数据库存储过程 `装配中心任务看板_质检发货状态查询` 已补充返回 `合同装配工时`；前端 `TestTaskDashboard.vue` 已恢复调用该过程，并将累计工时按分钟显示。`npm run build` 构建通过。
|
||
|
||
## 2026-07-03 发货任务列表取消重复补齐显示
|
||
|
||
### 提问
|
||
|
||
用户要求发货任务列表里面的数据查出来几条就是几条，不要重复显示。
|
||
|
||
### 执行过程
|
||
|
||
1. 读取 `src/views/TestTaskDashboard.vue` 的滚动显示逻辑。
|
||
2. 确认当前 `makeDisplayRows` 固定按 `VISIBLE_ROWS.delivery` 生成 8 行；当查询结果少于 8 行时，通过 `% len` 取模循环补齐，因此会重复显示同一批发货任务。
|
||
3. 修改 `makeDisplayRows(rows, offset, visibleCount, loopFill = true)`，新增 `loopFill` 参数。
|
||
4. 当 `loopFill` 为 `false` 时，显示行数改为 `Math.min(visibleCount, len)`，即查询结果几条就最多显示几条，不再循环补齐。
|
||
5. 将 `deliveryDisplayRows` 改为调用 `makeDisplayRows(deliveryRows.value, deliveryOffset.value, VISIBLE_ROWS.delivery, false)`，只关闭发货任务列表的重复补齐。
|
||
6. 保持测试装配任务列表和已完工任务列表仍使用原循环补齐逻辑，避免影响其他面板。
|
||
7. 新增 `startScrollWhenOverflow`，发货任务列表只有当真实行数大于可见行数时才滚动；如果真实行数小于或等于可见行数，则偏移重置为 0。
|
||
8. 修改 `startAllScroll`，发货任务列表使用 `startScrollWhenOverflow`，其他列表继续使用原 `startScroll`。
|
||
9. 执行 `npm run build`，构建成功；仍仅出现既有 Sass legacy JS API 警告和 chunk size 警告。
|
||
10. 检查关键行，确认 `deliveryDisplayRows` 已关闭补齐，发货滚动已改为溢出时才滚动。
|
||
11. 将本次提问、结论和完整执行过程追加到 `gptlog-process/gpdlog.md`。
|
||
|
||
### 结论
|
||
|
||
已实现发货任务列表按真实查询结果显示：查出几条就显示几条，不再为了凑满可见行数重复显示。只有发货任务真实条数超过可见行数时才会滚动。`npm run build` 构建通过。
|
||
|
||
## 2026-07-03 测试装配任务列表数据源与列调整
|
||
|
||
### 提问
|
||
|
||
用户要求：
|
||
1. 测试装配任务列表使用 `质量管理_测试装配任务_查询2`。
|
||
2. 测试任务汇总仍使用原来的 `质量管理_测试装配任务_查询`。
|
||
3. 修改测试装配任务列表：去掉“检验数量”；“预计送检”改为“操作人”；物料名称和物料编码加宽。
|
||
|
||
### 执行过程
|
||
|
||
1. 读取 `src/views/TestTaskDashboard.vue`，确认当前 `searchTestAssemblyTaskData` 被改成了 `质量管理_测试装配任务_查询2`，会导致汇总也使用查询2。
|
||
2. 使用数据库元数据查询 `质量管理_测试装配任务_查询2` 返回列，确认其返回 `操作人`、`物料编号`、`物料描述`、`加急总数`、`订单号`、`合同号`、`零件编码`、`零件名称`、`分配数`、`完成数量` 等字段，适合右侧测试装配任务列表。
|
||
3. 将 `searchDashboardData` 拆分为两次查询：先执行 `searchTestAssemblyTaskData`，再执行 `searchTestAssemblyTaskListData`。
|
||
4. 将 `searchTestAssemblyTaskData` 恢复为调用原 `质量管理_测试装配任务_查询`，并传入任务类型、生产订单、销售订单、物料名称、物料编码参数；该结果继续写入 `rawTestAssemblyRows`，用于测试任务汇总、加急汇总、待协助任务数和异常未关闭消息数。
|
||
5. 新增 `searchTestAssemblyTaskListData`，单独调用 `质量管理_测试装配任务_查询2`，只用于右侧测试装配任务列表。
|
||
6. 从 `applyTestAssemblyTaskData` 中移除 `applyTaskData(sortedRows)`，避免原查询结果覆盖右侧列表。
|
||
7. 修改 `applyTaskData` 映射，兼容查询2返回字段：生产订单取 `生产订单/订单号/计划号`，销售订单取 `销售订单/合同号`，物料名称取 `物料名称/物料描述/零件名称`，物料编码取 `物料编码/物料编号/零件编码`，操作人取 `操作人`。
|
||
8. 删除右侧测试装配任务列表中的 `inspectQty` 数据映射。
|
||
9. 修改 `taskColumns`：删除“检验数”列；将原“预计送检”列改为“操作人”；物料名称列宽从 190px 调整为 280px，物料编码列宽从 176px 调整为 260px。
|
||
10. 给测试装配任务列表表头和单元格绑定 `c.width`，使列配置宽度实际生效。
|
||
11. 执行 `npm run build`，构建成功；仍仅出现既有 Sass legacy JS API 警告和 chunk size 警告。
|
||
12. 检查关键行，确认 `质量管理_测试装配任务_查询` 与 `质量管理_测试装配任务_查询2` 已按汇总和列表分离。
|
||
13. 将本次提问、结论和完整执行过程追加到 `gptlog-process/gpdlog.md`。
|
||
|
||
### 结论
|
||
|
||
已将数据源拆分：测试任务汇总继续使用原 `质量管理_测试装配任务_查询`；右侧测试装配任务列表单独使用 `质量管理_测试装配任务_查询2`。右侧列表已去掉“检验数”，将“预计送检”改为“操作人”，并加宽物料名称、物料编码列。`npm run build` 构建通过。
|
||
|
||
## 2026-07-03 测试装配任务列表取消重复补齐显示
|
||
|
||
### 提问
|
||
|
||
用户要求测试装配任务列表里面的内容也是查询出来几条就显示几条，不重复补充。
|
||
|
||
### 执行过程
|
||
|
||
1. 读取 `src/views/TestTaskDashboard.vue` 的显示行和滚动逻辑。
|
||
2. 确认 `makeDisplayRows` 已支持 `loopFill` 参数，发货任务列表已通过 `loopFill=false` 关闭重复补齐。
|
||
3. 修改 `taskDisplayRows`，从 `makeDisplayRows(taskRows.value, taskOffset.value, VISIBLE_ROWS.task)` 改为 `makeDisplayRows(taskRows.value, taskOffset.value, VISIBLE_ROWS.task, false)`。
|
||
4. 修改 `startAllScroll`，测试装配任务列表从原 `startScroll(taskRows, taskOffset)` 改为 `startScrollWhenOverflow(taskRows, taskOffset, VISIBLE_ROWS.task)`。
|
||
5. 保持已完工任务列表仍使用原循环补齐逻辑，避免影响未提出修改的区域。
|
||
6. 执行 `npm run build`，构建成功；仍仅出现既有 Sass legacy JS API 警告和 chunk size 警告。
|
||
7. 检查关键行，确认 `taskDisplayRows` 已关闭补齐，`taskRows` 已改为超出可见行数时才滚动。
|
||
8. 将本次提问、结论和完整执行过程追加到 `gptlog-process/gpdlog.md`。
|
||
|
||
### 结论
|
||
|
||
已实现测试装配任务列表按真实查询结果显示：查询出来几条就显示几条，不再为了凑满可见行数重复显示。只有真实条数超过可见行数时才会滚动。`npm run build` 构建通过。
|
||
## 2026-07-03 仓库大屏看板规划
|
||
|
||
### 提问
|
||
用户要求：根据 `doc/仓库大屏数据.docx` 文档规划一个仓库大屏看板并给出文档；要求优先显示汇总，能用图表尽量用图表，如果有剩余位置再显示明细。
|
||
|
||
### 执行过程
|
||
1. 读取仓库根目录规则，确认每次执行完成后需要将中文过程日志追加到 `gptlog-process/gpdlog.md`。
|
||
2. 检查 `doc/仓库大屏数据.docx` 是否存在，并通过 docx 压缩包结构读取 `word/document.xml` 中的文字内容。
|
||
3. 从文档中整理出仓库大屏的数据范围：
|
||
- 已质检未入库入库任务汇总及明细：装配件、机加件、原材料、外购件。
|
||
- 超 2 天未入库任务、超 2 天未上架物料。
|
||
- 未清拣配清单：装配件、机加件的汇总及明细。
|
||
- 超 10 天未出库拣配任务、拣配任务已清但汇报未清任务。
|
||
- 销售交货未清任务、发货日期小于等于当天的及时发货任务。
|
||
4. 提取 docx 内图片到 `work/仓库大屏规划/docx-media/`，并查看主要截图，确认业务侧关注点是入库、上架、拣配出库、发货的汇总优先展示，明细作为补充。
|
||
5. 连接用户提供的数据库环境，查询 SAP 视图是否存在、字段结构和当前数据体量。日志中不记录数据库密码。
|
||
6. 根据文档和数据库字段，整理了当前数据体量参考，包括入库汇总、超期入库、超期上架、拣配未清、超期出库、汇报未清和今日应发等指标。
|
||
7. 编写规划文档 `work/仓库大屏规划/仓库大屏看板规划方案.md`，规划 1920x1080 首屏布局：
|
||
- 顶部 8 个核心 KPI 卡片，优先显示汇总压力和风险。
|
||
- 中部用柱状图、环图/玫瑰图、仪表图展示结构和风险。
|
||
- 底部仅在剩余空间展示关键明细表，且明细按查询结果真实行数展示，不做重复补齐。
|
||
8. 在规划文档中补充数据源映射、刷新策略、交互建议、后续开发建议和验收标准。
|
||
|
||
### 结论
|
||
已完成仓库大屏看板规划文档，文件位置为 `work/仓库大屏规划/仓库大屏看板规划方案.md`。方案以汇总指标为首屏优先级，尽量使用图表展示结构和趋势，仅将明细放在底部剩余空间作为风险追踪入口。
|
||
|
||
## 2026-07-06 仓库任务大屏页面生成
|
||
|
||
### 提问
|
||
用户要求：根据 `doc/仓库大屏数据.docx` 和 `仓库大屏看板规划方案.md` 生成 `WarehouseDashboard.vue` 页面，样式风格参照 `index.vue`，并提供数据库连接信息用于核验数据。
|
||
|
||
### 执行过程
|
||
1. 读取项目结构，确认当前是 Vue 3 + Vite 项目，现有页面位于 `src/views/`，路由位于 `src/router/index.js`。
|
||
2. 读取 `src/views/index.vue`，确认装配中心任务看板的 1920x1080 固定画布、自适应缩放、深色背景、发光边框面板、顶部品牌 Logo、标题和时间样式。
|
||
3. 读取 `src/views/ProductionTaskDashboard.vue`、`src/views/TestTaskDashboard.vue`、`src/main.js`、`src/utils/curdVue3.js`、`src/utils/request.js` 和 `public/config.js`，确认项目通过 `CreateData('11', 存储过程名, 参数)` 和 `ExecDatabase` 调用后端，不应在前端写入数据库账号密码。
|
||
4. 读取 `doc/仓库大屏看板规划方案.md`，确认页面布局要求：顶部 8 个 KPI，中部 4 个图表，底部 2 到 3 个风险明细表，明细查询几条显示几条，不重复补齐。
|
||
5. 解析 `doc/仓库大屏数据.docx`，提取到 SAP 链接视图清单，包括入库汇总/明细、超 2 天未入库、超 2 天未上架、未清拣配、超 10 天未出库、汇报未清、销售交货未清和今日应发等数据源。
|
||
6. 使用用户提供的数据库连接信息连接 `192.168.2.92`，只执行只读结构和样例查询；日志中不记录数据库密码。
|
||
7. 查询到当前实例包含 `YL_MESDB`，并存在 SAP 链接服务器；确认文档中的 `SAP.SBO_YL.dbo.*` 视图可访问。
|
||
8. 查询真实字段结构：入库汇总视图包含 `任务条数/加急条数`，拣配汇总视图包含 `任务条数/加急状态`，风险明细包含 `open_quantity/加急数量/计划数量/库存` 等字段。
|
||
9. 查询数据库中已有 `TV_视图看板仓库_查询`，但其口径为旧的 `UBT_MES_TASK2_2`，不符合本次文档规划，因此未在新页面中复用。
|
||
10. 新增并验证 4 个只读包装存储过程：`仓库大屏_汇总查询`、`仓库大屏_入库超期明细`、`仓库大屏_出库超期明细`、`仓库大屏_今日应发明细`。
|
||
11. 执行包装过程验证返回字段和样例数据，确认汇总过程返回 12 行分类汇总，3 个明细过程分别返回入库超期、出库超期和今日应发明细。
|
||
12. 测量过程执行耗时，汇总过程约 3.9 秒，三个明细过程约 0.26 到 0.45 秒；尝试改为链接服务器远程执行以优化耗时，但 SAP 链接服务器未启用 RPC，因此保持四段式链接查询。
|
||
13. 对 `仓库大屏_汇总查询` 做稳健性调整，确保空数据时聚合值返回 0 而不是 NULL。
|
||
14. 新增 `src/views/WarehouseDashboard.vue`，沿用 `index.vue` 的大屏视觉风格和缩放方式。
|
||
15. 页面顶部实现 8 个 KPI：待入库任务、入库加急、超 2 天未入库、超 2 天未上架、未清拣配、超 10 天未出库、汇报未清、今日应发。
|
||
16. 页面中部使用 ECharts 实现 4 个图表：入库任务结构柱状图、拣配任务结构柱状图、超期风险玫瑰/环图、今日发货保障柱状图。
|
||
17. 页面底部实现 3 个风险明细表：超 2 天未入库明细、超 10 天未出库明细、今日应发明细；滚动逻辑只在真实行数超过可见行数时滚动，不做重复补齐。
|
||
18. 新页面实现 5 分钟自动刷新、当前时间、数据刷新时间、窗口缩放重算和图表 resize/dispose 清理。
|
||
19. 修改 `src/router/index.js`，新增 `/WarehouseDashboard` 路由，组件指向 `src/views/WarehouseDashboard.vue`。
|
||
20. 执行 `npm run build`，构建成功；仅出现既有 Sass legacy JS API 提示和 Vite chunk size 警告。
|
||
21. 尝试用手工 HTTP 请求测试后端接口，手工模拟请求对已有过程和新过程均返回 `result=0`，判断该测试方式无法代表真实前端上下文；SQL 层新过程本身已验证可执行。
|
||
22. 检查本地是否安装 Playwright，结果为未安装，因此未执行自动截图检查。
|
||
23. 启动 Vite 开发服务器，确认 `http://localhost:5173/#/WarehouseDashboard` 返回 200。
|
||
24. 检查工作区状态，发现 `src/views/TestTaskDashboard.vue`、`dist.zip`、部分文档和工作目录已有未提交变化；本次未回滚这些已有变化。
|
||
25. 将本次提问、结论和完整执行过程追加到 `gptlog-process/gpdlog.md`。
|
||
|
||
### 结论
|
||
已完成仓库任务大屏页面 `src/views/WarehouseDashboard.vue`，并新增路由 `/WarehouseDashboard`。页面按文档规划展示顶部汇总 KPI、中部图表和底部风险明细，样式参照现有 `index.vue`。数据库侧已新增 4 个只读包装过程供页面调用。`npm run build` 构建通过，本地开发服务已启动，访问地址为 `http://localhost:5173/#/WarehouseDashboard`。
|
||
|
||
## 2026-07-06 上传所有修改到远程
|
||
|
||
### 提问
|
||
用户要求：上传所有修改到远程。
|
||
|
||
### 执行过程
|
||
1. 检查当前 Git 工作区状态，确认存在已修改文件和未跟踪文件，包括 `dist.zip`、`gptlog-process/gpdlog.md`、`src/router/index.js`、`src/views/TestTaskDashboard.vue`、`src/views/WarehouseDashboard.vue`、`AGENTS.md`、`doc/` 下新增文档以及 `work/` 下新增工作目录。
|
||
2. 检查当前分支，确认当前分支为 `main`。
|
||
3. 检查远程仓库，确认远程 `origin` 地址为 `http://154.8.160.151:3000/zhangxinyang/zhuangpei-task-kanban.git`。
|
||
4. 检查最近一次提交，当前最新提交为 `280d066 fix: add product column to test summary`。
|
||
5. 按用户“所有修改”的要求，准备将当前工作区所有已跟踪和未跟踪修改统一纳入提交。
|
||
6. 将本次上传远程的提问、执行过程和结论追加到 `gptlog-process/gpdlog.md`，确保日志文件本身也包含在待提交内容中。
|
||
7. 执行 `git add -A`，将所有当前修改加入暂存区。
|
||
8. 执行 `git commit -m "feat: add warehouse dashboard"`，创建提交 `41af5a7`。
|
||
9. 执行 `git push origin main`，远程返回 `280d066..41af5a7 main -> main`，确认已推送到 `origin/main`。
|
||
10. 推送完成后补充本段实际结果日志，并准备再次提交推送日志补充内容，确保最终工作区不遗留未上传的日志修改。
|
||
|
||
### 结论
|
||
所有当前修改已提交并推送到远程 `origin/main`，主要提交为 `41af5a7 feat: add warehouse dashboard`。本次补充日志也将一并提交并推送，保持本地与远程一致。
|
||
|
||
## 2026-07-06 仓库任务大屏按客户 Excel 调整
|
||
|
||
### 提问
|
||
用户要求：继续修改仓库任务大屏，参考 `C:\Users\meswork764\Documents\xwechat_files\wxid_3113011130614_d858\msg\file\2026-07\库房大屏幕260704.xlsx`，客户提出数据源需要调整；当前四个图表占两行较松，表格应为四个明细表；上面的汇总数不允许有省略号。随后用户补充：条数放上面，件数放下面，大屏条数比件数有用，没必要大调整排版，数据能显示出来即可。
|
||
|
||
### 执行过程
|
||
1. 检查 Git 状态，确认当前分支 `main` 与远程一致，工作区初始干净。
|
||
2. 确认客户 Excel 文件存在，解析 xlsx 内部 XML，读取工作表 `布局说明`。
|
||
3. 从 Excel 中提取新布局和新数据口径：入库任务、加急入库列表、拣配任务列表、加急拣配列表、发货任务列表，以及右侧数据源和取值逻辑。
|
||
4. 核对 Excel 中数据源：入库汇总仍使用 `UBT_MES_DP_receipttask_101/103/105/106`；加急入库列表使用四个 `UBT_MES_DP_receipttask_material_*` 明细视图按加急合并；拣配任务列表使用未清拣配明细；加急拣配列表使用两类拣配明细按加急合并；发货汇总使用 `UBT_MES_DP_OpenODLN_material` 和今日发货视图；异常出库使用 `UBT_MES_DP_OpenOPKL_material_10Days`。
|
||
5. 查询数据库字段结构，确认四个入库明细视图包含 `external_num/item_name/open_quantity/加急数量`，拣配明细视图包含 `项目/生产订单号/物料名称/齐套状态/打印状态/加急状态`，发货相关已有过程包含 `合同号/物料描述/交货数量/要求发货日期/检验数量`。
|
||
6. 更新数据库包装过程 `仓库大屏_汇总查询`，按用户补充要求将 `任务数` 作为条数主指标，将 `数量` 作为件数辅助指标。入库件数改从入库明细 `open_quantity` 统计，拣配件数改从拣配明细 `计划数量` 统计，及时处理和发货分别保留条数与件数。
|
||
7. 新增或更新只读包装过程 `仓库大屏_加急入库列表`、`仓库大屏_拣配任务列表`、`仓库大屏_加急拣配列表`，分别返回客户表格需要的字段。
|
||
8. 修改 `src/views/WarehouseDashboard.vue`：顶部 8 个汇总卡主数字全部改为条数，副文本显示件数和加急件数。
|
||
9. 修改 `src/views/WarehouseDashboard.vue`：四个图表压缩为一行展示，减少图表区高度，整体不做大幅重构。
|
||
10. 修改 `src/views/WarehouseDashboard.vue`：底部明细由 3 张表调整为 4 张表，分别为加急入库列表、拣配任务列表、加急拣配列表、发货任务列表。
|
||
11. 修改 `src/views/WarehouseDashboard.vue`：加急入库、拣配任务、加急拣配、发货任务分别接入新过程或现有发货过程，并按客户给出的字段展示。
|
||
12. 修改顶部 KPI 样式，去掉主数字的 `overflow hidden`、`max-width` 和 `text-overflow: ellipsis`，确保汇总数不显示省略号。
|
||
13. 调整表格和图表高度、字号、行高，四个明细表每表可见 8 行，保持原大屏风格。
|
||
14. 执行数据库过程样例验证，确认 `仓库大屏_汇总查询`、`仓库大屏_加急入库列表`、`仓库大屏_拣配任务列表`、`仓库大屏_加急拣配列表`、`装配中心任务看板_发货状态查询` 均能返回数据。
|
||
15. 执行 `npm run build`，构建成功，仅保留既有 Sass legacy JS API 提示和 Vite chunk size 警告。
|
||
|
||
### 结论
|
||
已按客户 Excel 和补充说明调整仓库任务大屏：汇总卡改为条数在上、件数在下；顶部汇总数字不再省略；四个图表压缩到一行；底部改为四个明细表并接入新数据源。构建验证通过。
|
||
|
||
## 2026-07-06 仓库任务大屏数据为 0 和布局空白修复
|
||
|
||
### 提问
|
||
用户反馈：仓库任务大屏顶部和图表数据都没了，下面太空；要求在四个图表下面再加四个图表。随后用户补充：八个图表两行加上列表三行高度都一样。
|
||
|
||
### 执行过程
|
||
1. 根据用户截图判断：明细表有数据，但顶部 KPI 和图表全为 0，问题集中在汇总接口或前端汇总数据处理。
|
||
2. 直接执行数据库过程 `仓库大屏_汇总查询`，发现执行约 8.3 秒，超过前端 Axios 原 5 秒超时，导致前端查询失败后把汇总数据置空，因此顶部和图表显示 0。
|
||
3. 尝试使用 `OPENQUERY` 优化 SAP 远程聚合，单类测试约 1.8 秒；随后确认完整聚合仍可能受 SAP 链接查询波动影响。
|
||
4. 将 `仓库大屏_汇总查询` 改回较快的直接汇总口径，优先保证 `任务数` 条数能快速返回，件数保留为辅助数量；复测完整过程约 4.7 秒。
|
||
5. 修改 `src/utils/request.js`，将 Axios 超时时间从 5 秒调整为 15 秒，避免 SAP 链接偶发慢一点时前端清空汇总。
|
||
6. 修改 `src/views/WarehouseDashboard.vue`，增加第二排 4 个图表，合计 8 个图表：
|
||
- 入库任务结构
|
||
- 拣配任务结构
|
||
- 超期风险分布
|
||
- 今日发货保障
|
||
- 入库条数结构
|
||
- 拣配条数结构
|
||
- 及时处理件数
|
||
- 发货件数结构
|
||
7. 为新增 4 个图表增加 ECharts ref、实例初始化、渲染、resize 和 dispose 管理。
|
||
8. 新增通用单柱状图配置函数，复用现有汇总数据，不新增额外接口压力。
|
||
9. 按用户要求将内容区域设置为三行等高：前两行为 8 个图表，第三行为 4 个列表；顶部汇总卡单独保留。
|
||
10. 将明细表可见行数调为 5 行，真实数据超过可见行数时继续自动滚动，避免列表区域显得过空。
|
||
11. 给汇总数据应用函数增加兜底：如果汇总接口偶发返回空数组，不覆盖已有汇总数据，避免刷新后突然全 0。
|
||
12. 执行 `npm run build`，构建成功；仅保留既有 Sass legacy JS API 提示和 Vite chunk size 警告。
|
||
|
||
### 结论
|
||
已修复汇总数据因接口超时导致全为 0 的问题，并将大屏主体调整为三行等高：两行 8 个图表加一行 4 个列表。构建验证通过。
|
||
|
||
## 2026-07-06 仓库任务大屏字号放大
|
||
|
||
### 提问
|
||
用户要求：因为是看板，需要把字号调大。
|
||
|
||
### 执行过程
|
||
1. 保持现有三行等高布局和数据逻辑不变，只调整视觉字号。
|
||
2. 放大顶部 KPI 卡片：标题从 19px 调整为 22px，主数字从 39px 调整为 48px，单位从 18px 调整为 22px，副文本从 14px 调整为 16px。
|
||
3. 放大面板标题：图表和表格标题调整为 28px，并保持 38px 标题栏高度。
|
||
4. 放大表格文字：表头从 13px 调整为 16px，表体从 12px 调整为 15px，行高同步增加。
|
||
5. 放大 ECharts 图表文字：tooltip、图例、坐标轴标签、柱状图标签、饼图标签等统一上调字号。
|
||
6. 执行 `npm run build`，构建成功；仍仅有既有 Sass legacy JS API 提示和 Vite chunk size 警告。
|
||
|
||
### 结论
|
||
已放大仓库任务大屏的 KPI、图表和表格字号，更适合大屏看板远距离查看。构建验证通过。
|
||
|
||
## 2026-07-06 仓库任务大屏列表右侧遮挡修复
|
||
|
||
### 提问
|
||
用户反馈：四个列表右边被挡住了，没有完全显示出来。
|
||
|
||
### 执行过程
|
||
1. 根据截图判断，四个列表面板为四等分布局，但表格列宽仍使用固定像素，列宽总和超过单个面板宽度，导致右侧列被裁切。
|
||
2. 将四个列表的列宽从固定 `px` 改为百分比宽度，确保每张表总宽度不超过所在面板。
|
||
3. 拣配任务列表去掉非必要的 `状态` 列，保留客户要求的 `合同号/生产订单/物料名称/齐套`，减少横向挤压。
|
||
4. 调整表格容器左右内边距，从 8px 收紧到 6px。
|
||
5. 表格单元格增加 `overflow: hidden` 和 `text-overflow: ellipsis`，避免长文本把右侧列挤出面板。
|
||
6. 表格字号略收紧到表头 15px、表体 14px，保证右侧列完整显示。
|
||
7. 执行 `npm run build`，构建成功；仍仅有既有 Sass legacy JS API 提示和 Vite chunk size 警告。
|
||
|
||
### 结论
|
||
已修复四个列表右侧列被挡住的问题。四个列表现在使用百分比列宽，右侧字段可以完整落在面板内。构建验证通过。
|
||
|
||
## 2026-07-06 仓库任务大屏图表合并与网格线去除
|
||
|
||
### 提问
|
||
用户要求：去掉第三行的图表，第一行的数量放入到对应第二行的图表里面；去掉图表里面的横线（Y 轴），数量显示在柱状图上面。
|
||
|
||
### 执行过程
|
||
1. 定位 `src/views/WarehouseDashboard.vue` 中的 8 个图表模板和对应 ECharts 实例。
|
||
2. 删除第二排独立数量/件数图表，只保留入库任务、拣配任务、及时处理、发货任务 4 个图表。
|
||
3. 清理第二排 4 个图表对应的 ref、实例变量、初始化、渲染、resize 和 dispose 逻辑。
|
||
4. 将入库和拣配图表改为双柱展示：条数和件数在同一图表内显示。
|
||
5. 将及时处理和发货任务图表从原先独立图表/饼图样式统一改为条数与件数双柱图。
|
||
6. 修改通用柱状图配置，隐藏 Y 轴轴线、刻度、标签和横向网格线。
|
||
7. 给柱状图两个系列增加顶部标签，直接在柱子上方显示数值。
|
||
8. 将主体布局改回顶部汇总、4 个图表、4 个列表三段结构。
|
||
9. 执行 `npm run build`，构建成功；仍仅有既有 Sass legacy JS API 提示和 Vite chunk size 警告。
|
||
|
||
### 结论
|
||
已去掉第三行图表，将数量/件数合并到对应的 4 个主图表中；图表横线和 Y 轴视觉元素已隐藏，数值直接显示在柱状图上方。构建验证通过。
|
||
|
||
## 2026-07-06 仓库任务大屏汇总并入图表与加急口径修正
|
||
|
||
### 提问
|
||
用户反馈：当前图表数据不对，加急和任务一样多；要求把上边汇总放到对应图表里，基本取消第一行汇总区域。
|
||
|
||
### 执行过程
|
||
1. 检查 `src/views/WarehouseDashboard.vue` 当前实现，确认上一轮把图表第二组数据接成了 `quantity` 件数，导致图例虽显示第二组柱子，但并不是加急口径。
|
||
2. 删除模板中的顶部 `kpi-row` 汇总卡片区域，不再单独占用第一行。
|
||
3. 在四个主图表面板内部新增汇总头部，分别显示入库任务、拣配任务、及时处理、发货任务的总条数，并在下方显示件数和加急数量。
|
||
4. 删除不再使用的 `summaryCards` 计算逻辑，新增 `chartSummaries` 计算对象和 `formatChartSummary` 格式化函数。
|
||
5. 将内容主体布局从“汇总行 + 图表行 + 列表行”调整为“两行”：第一行为四个图表，第二行为四个列表。
|
||
6. 将四个列表可见行数从 5 行调整为 8 行，减少取消顶部汇总行之后列表区域显得过空的问题。
|
||
7. 修正四个柱状图的数据口径：蓝色柱为 `taskCount` 任务，红色柱为 `urgentQty` 加急，不再使用 `quantity` 件数作为红色柱。
|
||
8. 保留图表内隐藏 Y 轴、隐藏横向网格线、柱顶显示数值的配置。
|
||
9. 执行静态搜索，确认旧的顶部卡片类名和 `quantity` 红柱绑定已清理。
|
||
10. 执行 `npm run build`，构建成功；仍仅有既有 Sass legacy JS API 提示和 Vite chunk size 警告。
|
||
11. 检查本地 5173 端口服务仍在监听，并通过 HTTP 请求确认页面入口返回 200。
|
||
|
||
### 结论
|
||
已将顶部汇总并入四个图表面板，页面主体不再有独立第一行汇总卡片；柱状图已改回“任务 / 加急”口径，避免加急数据误用件数导致看起来与任务一样多。构建验证通过，本地页面入口可访问。
|
||
|
||
## 2026-07-06 仓库任务大屏去除件数与异常出库合并
|
||
|
||
### 提问
|
||
用户要求：
|
||
1. 四个图表柱状图不要数量（件数），去掉所有件数，只要条数；加急的数量要求是红色。
|
||
2. 异常出库的数据跟拣配任务一起展示。
|
||
3. 加大字号显示。
|
||
|
||
### 执行过程
|
||
1. 读取 `src/views/WarehouseDashboard.vue`，确认当前图表头部仍显示“件数 / 加急”，柱状图已显示“任务 / 加急”，但数据库过程里部分 `加急数量` 仍为件数累加。
|
||
2. 修改四个图表面板头部摘要：去掉所有“件”相关展示，只保留总条数和“加急 X 条”。
|
||
3. 修改 `formatChartSummary`，返回总条数和加急条数，不再返回件数文本。
|
||
4. 修改拣配图表：分类从“机加 / 装配”扩展为“机加 / 装配 / 异常出库”，其中异常出库从发货环节的“异常出库”汇总行读取。
|
||
5. 修改发货图表：分类只保留“发货任务 / 今日”，不再单独展示异常出库。
|
||
6. 修改拣配图表汇总数：拣配总条数和加急条数合并异常出库数据，保证面板汇总与图表分类一致。
|
||
7. 放大 ECharts 字号：tooltip、图例、X 轴、柱顶标签均上调字号，柱宽也略加宽。
|
||
8. 将加急柱顶标签颜色改为红色 `#ff3345`，加急汇总数字也设置为红色。
|
||
9. 放大页面字号：图表标题、图表主数字、加急摘要、表格标题、表头和表体字号均上调。
|
||
10. 由于表格字号和行高放大，将列表可见行数从 8 行调整为 7 行，避免 1080 高度下内容被裁切。
|
||
11. 使用数据库直接执行 `仓库大屏_汇总查询`，发现原过程里发货、及时处理、异常出库等 `加急数量` 是加急件数累加，例如发货任务 13 条但加急显示 131，不符合“只要条数”的要求。
|
||
12. 查看 `YL_MESDB` 中 `dbo.仓库大屏_汇总查询` 定义，确认入库和拣配加急已是条数，及时处理和发货类仍按 `SUM(加急数量)` 统计件数。
|
||
13. 初次使用 `sqlcmd` 管道更新过程时遇到中文编码问题，SQL Server 将中文标识识别成问号，执行失败且未成功修改过程。
|
||
14. 改用 PowerShell `System.Data.SqlClient` 以 Unicode 字符串执行 `ALTER PROCEDURE`，成功更新 `dbo.仓库大屏_汇总查询`。
|
||
15. 数据库过程调整口径：及时处理入库、及时处理汇报、发货任务、今日、异常出库的 `加急数量` 改为统计 `加急数量 > 0` 的记录条数。
|
||
16. 重新执行 `仓库大屏_汇总查询` 验证，发货任务变为 13 条、加急 10 条；今日变为 11 条、加急 8 条；异常出库变为 227 条、加急 13 条，符合条数口径。
|
||
17. 执行 `npm run build`，构建成功；仍仅有既有 Sass legacy JS API 提示和 Vite chunk size 警告。
|
||
|
||
### 结论
|
||
已去掉图表区域所有件数展示，四个图表统一为条数口径；加急柱顶标签和加急摘要数字已改为红色；异常出库已合并到拣配任务图表，发货图表只保留发货任务和今日；字号已整体放大。数据库汇总过程也已同步修正加急条数口径，避免前端显示加急件数。
|
||
|
||
## 2026-07-06 仓库任务大屏发货汇总口径修正
|
||
|
||
### 提问
|
||
用户反馈：发货任务图表顶部总数明显不对，怀疑忘记去掉异常出库数据。
|
||
|
||
### 执行过程
|
||
1. 根据截图判断：发货图表柱子只显示“发货任务 13”和“今日 11”，但右上角汇总仍显示 250 条、加急 31 条。
|
||
2. 检查 `src/views/WarehouseDashboard.vue`，确认发货图表分类已经去掉“异常出库”，但图表头部汇总仍调用 `getSectionTotal('发货')`，因此把“异常出库”也算入了总数。
|
||
3. 新增 `getDeliverySectionTotal`，只合计 `发货 / 发货任务` 与 `发货 / 今日` 两个分类。
|
||
4. 将 `chartSummaries.delivery` 从 `getSectionTotal('发货')` 改为 `getDeliverySectionTotal()`，保证发货图表顶部数字与图表柱子一致。
|
||
5. 执行 `npm run build`，构建成功；仍仅有既有 Sass legacy JS API 提示和 Vite chunk size 警告。
|
||
|
||
### 结论
|
||
已修正发货任务图表顶部汇总口径，异常出库不再计入发货任务顶部总数；当前发货顶部汇总只对应图表里的“发货任务 + 今日”。
|
||
|
||
## 2026-07-06 质检测试任务列表增加入库数与合格数
|
||
|
||
### 提问
|
||
用户要求修改 `C:\WorkYuanLy\装配任务看板\src\views\TestTaskDashboard.vue`：测试装配任务列表在完成数后增加两个字段“入库数”和“合格数”。入库数取 `[dbo].[View_生产订单_MES].入库数量`；合格数取 `[dbo].[YL_质量检验_质检记录].合格数` 的和，关联条件为 `YL_质量检验_质检记录.TaskAID = View_生产订单_MES.TaskAID` 且 `检测类型编号 = 6`；当合格数等于完成数时，该条数据不显示。
|
||
|
||
### 执行过程
|
||
1. 读取 `src/views/TestTaskDashboard.vue`，定位“测试装配任务列表”模板、`taskColumns` 列定义和 `applyTaskData` 数据映射。
|
||
2. 确认测试装配任务列表当前调用的数据源为 `质量管理_测试装配任务_查询2`。
|
||
3. 查询数据库 `YL_MESDB` 中 `dbo.质量管理_测试装配任务_查询2` 的定义，确认当前过程已经从 `View_生产订单_MES` 返回 `入库数量`，但没有返回合格数，也没有过滤 `合格数 = 完成数` 的记录。
|
||
4. 查询数据库字段元数据，确认 `View_生产订单_MES` 包含 `TaskAID/入库数量/完成数量`，`YL_质量检验_质检记录` 包含 `TaskAID/检测类型编号/合格数`。
|
||
5. 更新存储过程 `dbo.质量管理_测试装配任务_查询2`：增加按 `TaskAID` 汇总的质检记录子查询，只统计 `检测类型编号 = 6` 的 `合格数`。
|
||
6. 在过程返回字段中新增 `ISNULL(qc.合格数, 0) AS 合格数`。
|
||
7. 在过程过滤条件中增加 `ISNULL(qc.合格数, 0) <> ISNULL(pt.完成数量, 0)`，过滤掉合格数等于完成数的任务。
|
||
8. 执行过程验证，确认结果返回列包含 `入库数量` 和 `合格数`。
|
||
9. 额外执行核对 SQL，确认过滤后的结果中不存在 `合格数 = 完成数` 的记录。
|
||
10. 修改 `src/views/TestTaskDashboard.vue`：`applyTaskData` 中增加前端兜底过滤 `合格数 !== 完成数量`。
|
||
11. 修改 `applyTaskData` 映射，新增 `inboundQty` 取 `入库数量`，`passQty` 取 `合格数`。
|
||
12. 修改 `taskColumns`，在“完成数”后增加“入库数”和“合格数”两列，并适当缩小“操作人”列宽。
|
||
13. 执行 `npm run build`，构建成功；仍仅有既有 Sass legacy JS API 提示和 Vite chunk size 警告。
|
||
|
||
### 结论
|
||
已完成测试装配任务列表改造：完成数后新增入库数和合格数；合格数按 `检测类型编号 = 6` 的质检记录汇总；合格数等于完成数的任务已在数据库过程和前端双重过滤。构建验证通过。
|
||
## 2026-07-08 修复装配与质检测试看板右上角时间
|
||
|
||
### 提问
|
||
用户要求修改 `C:\WorkYuanLy\装配任务看板\src\views\index.vue` 和 `C:\WorkYuanLy\装配任务看板\src\views\TestTaskDashboard.vue`，反馈右上角时间不对。
|
||
|
||
### 执行过程
|
||
1. 读取 `src/views/index.vue` 和 `src/views/TestTaskDashboard.vue`，定位右上角时间显示绑定为 `currentTime`。
|
||
2. 检索项目中时间相关实现，确认两个目标文件都将 `now` 初始化为固定时间 `2026-05-06 10:10:10`。
|
||
3. 确认两个目标文件的定时器逻辑都是基于旧的 `now.value` 每秒加 1000 毫秒，因此页面显示的是从固定时间递增的模拟时间，不是系统当前时间，并且页面休眠或定时器暂停后也容易产生偏差。
|
||
4. 修改 `src/views/index.vue`：将 `const now = ref(new Date('2026-05-06 10:10:10'))` 改为 `const now = ref(new Date())`。
|
||
5. 修改 `src/views/index.vue`：在 `startClock` 启动时立即刷新一次 `now.value = new Date()`，并将定时器更新逻辑改为每秒直接读取 `new Date()`。
|
||
6. 修改 `src/views/TestTaskDashboard.vue`：将 `const now = ref(new Date('2026-05-06 10:10:10'))` 改为 `const now = ref(new Date())`。
|
||
7. 修改 `src/views/TestTaskDashboard.vue`：将 `startClock` 改为启动时立即读取当前系统时间，后续每秒直接读取 `new Date()`。
|
||
8. 查看 `git diff`，确认本次修改集中在右上角时钟相关逻辑；同时注意到两个目标文件中存在其他既有未提交改动，本次没有回退或改写这些无关内容。
|
||
9. 查看 `package.json`，确认项目可用校验脚本为 `npm run build`。
|
||
10. 执行 `npm run build`，Vite 构建成功；输出中仅保留既有 Sass legacy JS API 提示和 chunk size 警告。
|
||
|
||
### 结论
|
||
已修复两个看板右上角时间不对的问题。`index.vue` 和 `TestTaskDashboard.vue` 现在都会以系统当前时间初始化，并在运行中每秒直接读取当前系统时间，避免继续显示固定的 `2026-05-06 10:10:10` 模拟时间。构建验证通过。
|
||
## 2026-07-08 上传所有修改到远程
|
||
|
||
### 提问
|
||
用户要求：上传所有的修改到远程。
|
||
|
||
### 执行过程
|
||
1. 检查当前 Git 工作区状态，确认存在已修改文件：`dist.zip`、`gptlog-process/gpdlog.md`、`src/utils/request.js`、`src/views/TestTaskDashboard.vue`、`src/views/WarehouseDashboard.vue`、`src/views/index.vue`。
|
||
2. 检查未跟踪文件，确认 `doc/未完成计划.xlsx` 和 `doc/~$未完成计划.xlsx` 也在当前工作区内；由于用户要求上传所有修改，本次按全部纳入处理。
|
||
3. 检查当前分支，确认当前位于 `main` 分支。
|
||
4. 检查远程仓库，确认 `origin` 指向 `http://154.8.160.151:3000/zhangxinyang/zhuangpei-task-kanban.git`。
|
||
5. 检查最新本地提交，当前提交为 `4e4a419 docs: update upload log`。
|
||
6. 执行 `git fetch origin`，刷新远程引用。
|
||
7. 执行 `git status -sb`，确认 `main` 与 `origin/main` 未显示 ahead/behind 分歧。
|
||
8. 查看 `git diff --stat`，确认本次待上传改动包含日志、看板页面、请求配置、压缩包等文件。
|
||
9. 按项目日志规则，将本次提问、执行过程和结论追加到 `gptlog-process/gpdlog.md`，使日志文件也随本次提交上传。
|
||
10. 准备执行 `git add -A` 暂存所有修改，随后创建提交并推送到 `origin/main`。
|
||
|
||
### 结论
|
||
本次将按“所有修改”口径提交并推送当前工作区全部变更到远程 `origin/main`，包括本次追加的中文执行日志。
|
||
|
||
### 推送结果补充
|
||
1. 执行 `git add -A`，已将当前工作区所有修改和未跟踪文件纳入暂存区。
|
||
2. 执行 `git commit -m "chore: upload dashboard updates"`，创建提交 `4eef87d chore: upload dashboard updates`。
|
||
3. 执行 `git push origin main`，远程返回 `4e4a419..4eef87d main -> main`，确认主提交已推送到 `origin/main`。
|
||
4. 本段为推送完成后的日志补充，将作为单独日志提交继续推送，确保本次执行过程记录也同步到远程。
|