diff --git a/AGENTS.md b/AGENTS.md new file mode 100644 index 0000000..1d7b01e --- /dev/null +++ b/AGENTS.md @@ -0,0 +1,10 @@ +# AGENTS.md + +## Scope + +日志记录规则 +每次 GPT/Codex 执行完毕后，须将完整的执行过程日志追加至： + +gptlog-process/gpdlog.md + +日志包含提问和结论以及完整的执行过程，写入该文件的日志内容必须使用中文记录。 diff --git a/dist.zip b/dist.zip index f51aa90..b503eef 100644 Binary files a/dist.zip and b/dist.zip differ diff --git a/doc/产出的文档和AI沟通预案.zip b/doc/产出的文档和AI沟通预案.zip new file mode 100644 index 0000000..d1192a4 Binary files /dev/null and b/doc/产出的文档和AI沟通预案.zip differ diff --git a/doc/仓库大屏数据.docx b/doc/仓库大屏数据.docx new file mode 100644 index 0000000..322e66d Binary files /dev/null and b/doc/仓库大屏数据.docx differ diff --git a/doc/仓库大屏看板规划方案.md b/doc/仓库大屏看板规划方案.md new file mode 100644 index 0000000..b8e6e2e --- /dev/null +++ b/doc/仓库大屏看板规划方案.md @@ -0,0 +1,269 @@ +# 仓库大屏看板规划方案 + +## 1. 目标定位 + +仓库大屏用于展示仓库当前待处理任务压力、超期风险和发货保障情况。页面应优先显示汇总指标和趋势/结构图表，只有在空间允许时展示明细列表。 + +核心原则： + +- 优先汇总：首屏先看总量、异常、加急、超期。 +- 图表优先：能用柱状图、环图、排行图表达的，不优先放大表格。 +- 明细兜底：明细只展示风险最高或最需要处理的少量记录。 +- 按仓库作业链路组织：入库、上架、拣配出库、销售发货。 + +## 2. 数据范围 + +文档 `doc/仓库大屏数据.docx` 中涉及的数据源来自 `SAP.SBO_YL.dbo` 下的仓库大屏视图。 + +### 2.1 入库 + +| 数据源 | 业务含义 | 建议用途 | +|---|---|---| +| `UBT_MES_DP_receipttask_101` | 已质检、未入库汇总-装配件 | 入库分类汇总、加急占比 | +| `UBT_MES_DP_receipttask_103` | 已质检、未入库汇总-机加件 | 入库分类汇总、加急占比 | +| `UBT_MES_DP_receipttask_105` | 已质检、未入库汇总-原材料 | 入库分类汇总、加急占比 | +| `UBT_MES_DP_receipttask_106` | 已质检、未入库汇总-外购件 | 入库分类汇总、加急占比 | +| `UBT_MES_DP_receipttask_material_101` | 已质检、未入库明细-装配件 | 明细兜底 | +| `UBT_MES_DP_receipttask_material_103` | 已质检、未入库明细-机加件 | 明细兜底 | +| `UBT_MES_DP_receipttask_material_105` | 已质检、未入库明细-原材料 | 明细兜底 | +| `UBT_MES_DP_receipttask_material_106` | 已质检、未入库明细-外购件 | 明细兜底 | +| `UBT_MES_DP_receipttask_material_2Days` | 超过 2 天未入库任务 | 重点风险指标、超期明细 | + +### 2.2 上架 + +| 数据源 | 业务含义 | 建议用途 | +|---|---|---| +| `UBT_MES_DP_inventory_2Days` | 超过 2 天未上架物料 | 重点风险指标、库位/物料排行 | + +### 2.3 拣配与出库 + +| 数据源 | 业务含义 | 建议用途 | +|---|---|---| +| `UBT_MES_DP_OpenOPKL_101` | 未清拣配汇总-装配件 | 拣配分类汇总 | +| `UBT_MES_DP_OpenOPKL_103` | 未清拣配汇总-机加件 | 拣配分类汇总 | +| `UBT_MES_DP_OpenOPKL_material_101` | 未清拣配明细-装配件 | 明细兜底 | +| `UBT_MES_DP_OpenOPKL_material_103` | 未清拣配明细-机加件 | 明细兜底 | +| `UBT_MES_DP_OpenOPKL_material_10Days` | 超过 10 天未出库拣配任务 | 重点风险指标、超期明细 | +| `UBT_MES_DP_ubt_wm_issuetask_material_OPKL` | 拣配任务已清、汇报未清 | 异常闭环指标、明细兜底 | + +### 2.4 销售发货 + +| 数据源 | 业务含义 | 建议用途 | +|---|---|---| +| `UBT_MES_DP_OpenODLN_material` | 销售交货未清任务 | 发货未清总量、加急总量 | +| `UBT_MES_DP_OpenODLN_material_ToDay` | 发货日期小于等于今天的及时发货任务 | 今日应发、今日加急 | + +## 3. 当前数据体量参考 + +以下为规划时的数据库抽样统计结果，用于判断展示优先级。实际看板应实时查询。 + +| 指标 | 行数 | 数量 | 加急数量 | +|---|---:|---:|---:| +| 入库汇总-装配件 | 31 | 898 | 0 | +| 入库汇总-机加件 | 65 | 4448 | 11061 | +| 入库汇总-原材料 | 10 | 4177 | 1584 | +| 入库汇总-外购件 | 47 | 2521 | 21 | +| 超过 2 天未入库 | 345 | 135030 | 21795 | +| 超过 2 天未上架 | 526 | 2994729.774 | - | +| 拣配汇总-装配件 | 414 | 284748 | 2185 | +| 拣配汇总-机加件 | 17 | 18144 | 0 | +| 超过 10 天未出库拣配 | 239 | 71972 | 86 | +| 拣配已清、汇报未清 | 20 | 10286 | 9000 | +| 销售交货未清 | 10 | 27 | 144 | +| 今日应发 | 9 | 21 | 19 | + +## 4. 首屏布局建议 + +建议按 1920 x 1080 设计。 + +### 4.1 顶部：全局汇总 KPI + +顶部放 8 个指标卡，作为进入页面第一眼看到的仓库压力总览。 + +| 指标卡 | 口径 | 颜色建议 | +|---|---|---| +| 待入库任务 | 四类入库汇总行数或未入库数量合计 | 蓝色 | +| 入库加急 | 四类入库汇总加急数量合计 | 红色 | +| 超 2 天未入库 | `UBT_MES_DP_receipttask_material_2Days` 行数/数量 | 橙色 | +| 超 2 天未上架 | `UBT_MES_DP_inventory_2Days` 行数/库存 | 橙色 | +| 未清拣配 | 装配件 + 机加件拣配汇总 | 蓝色 | +| 超 10 天未出库 | `UBT_MES_DP_OpenOPKL_material_10Days` | 红色 | +| 汇报未清 | `UBT_MES_DP_ubt_wm_issuetask_material_OPKL` | 红色 | +| 今日应发 | `UBT_MES_DP_OpenODLN_material_ToDay` | 绿色/红色按加急占比 | + +### 4.2 中部：四个主图表 + +中部占页面主要区域，优先用图表表达。 + +1. 入库任务结构图 + - 图表：分组柱状图 + - X 轴：装配件、机加件、原材料、外购件 + - Y 轴：未入库数量 + - 系列：总数量、加急数量 + - 价值：快速看哪类入库压力最大，加急压力集中在哪类。 + +2. 拣配任务结构图 + - 图表：分组柱状图 + - X 轴：装配件、机加件 + - Y 轴：计划数量/任务数 + - 系列：总数量、加急数量 + - 价值：对比装配和机加出库准备压力。 + +3. 超期风险雷达/环图 + - 图表：环图或玫瑰图 + - 维度：超 2 天未入库、超 2 天未上架、超 10 天未出库、汇报未清、今日应发加急 + - 指标：行数或数量 + - 价值：把风险事项集中到一个区域，突出处理优先级。 + +4. 今日发货保障图 + - 图表：仪表盘 + 小柱状图 + - 指标：今日应发数量、今日应发加急数量、销售交货未清数量 + - 价值：突出当天必须处理的发货任务。 + +### 4.3 底部：风险明细区 + +底部只保留 2 到 3 个高优先级明细表，每个表显示 5 到 8 行，自动滚动，但不重复补齐。 + +建议明细优先级： + +1. 超 2 天未入库明细 + - 数据源：`UBT_MES_DP_receipttask_material_2Days` + - 字段：单据日期、订单号、物料编码、物料名称、未入库数量、加急数量 + +2. 超 10 天未出库拣配明细 + - 数据源：`UBT_MES_DP_OpenOPKL_material_10Days` + - 字段：拣配清单号、拣配日期、生产订单号、物料编码、物料描述、计划数量、加急数量、行状态 + +3. 今日应发明细 + - 数据源：`UBT_MES_DP_OpenODLN_material_ToDay` + - 字段：发货日期、客户、订单号、物料编码、物料名称、未清数量、加急数量 + +如果屏幕空间不足，只保留前两个风险明细；今日应发用图表表达。 + +## 5. 推荐页面线框 + +```text +┌────────────────────────────────────────────────────────────────────────────┐ +│ 仓库任务大屏 当前时间 / 数据刷新时间 │ +├──────────┬──────────┬──────────┬──────────┬──────────┬──────────┬────────┤ +│待入库任务│入库加急 │超2天未入库│超2天未上架│未清拣配 │超10天出库│今日应发│ +├──────────────────────────────┬─────────────────────────────────────────────┤ +│ 入库任务结构图 │ 拣配任务结构图 │ +│ 分组柱状：总量/加急 │ 分组柱状：装配件/机加件，总量/加急 │ +├──────────────────────────────┼─────────────────────────────────────────────┤ +│ 超期风险环图/玫瑰图 │ 今日发货保障图 │ +│ 入库超期/上架超期/出库超期 │ 今日应发、今日加急、销售交货未清 │ +├──────────────────────────────┴─────────────────────────────────────────────┤ +│ 明细区：超2天未入库 / 超10天未出库 / 今日应发（按空间展示 2-3 个表） │ +└────────────────────────────────────────────────────────────────────────────┘ +``` + +## 6. 图表与指标映射 + +### 6.1 入库任务结构 + +| 分类 | 汇总视图 | 明细视图 | +|---|---|---| +| 装配件 | `UBT_MES_DP_receipttask_101` | `UBT_MES_DP_receipttask_material_101` | +| 机加件 | `UBT_MES_DP_receipttask_103` | `UBT_MES_DP_receipttask_material_103` | +| 原材料 | `UBT_MES_DP_receipttask_105` | `UBT_MES_DP_receipttask_material_105` | +| 外购件 | `UBT_MES_DP_receipttask_106` | `UBT_MES_DP_receipttask_material_106` | + +建议统计： + +- 任务行数：`COUNT(*)` +- 未入库数量：汇总视图用 `SUM(总计未入库数)`，明细视图用 `SUM(open_quantity)` +- 加急数量：`SUM(加急数量)` + +### 6.2 超期任务 + +| 指标 | 数据源 | 建议图表 | +|---|---|---| +| 超 2 天未入库 | `UBT_MES_DP_receipttask_material_2Days` | KPI + 明细表 | +| 超 2 天未上架 | `UBT_MES_DP_inventory_2Days` | KPI + 物料/库位排行 | +| 超 10 天未出库 | `UBT_MES_DP_OpenOPKL_material_10Days` | KPI + 明细表 | + +### 6.3 拣配出库 + +| 分类 | 汇总视图 | 明细视图 | +|---|---|---| +| 装配件 | `UBT_MES_DP_OpenOPKL_101` | `UBT_MES_DP_OpenOPKL_material_101` | +| 机加件 | `UBT_MES_DP_OpenOPKL_103` | `UBT_MES_DP_OpenOPKL_material_103` | + +建议统计： + +- 未清拣配任务：`COUNT(*)` +- 未清拣配数量：`SUM(计划数量)` +- 加急拣配数量：`SUM(加急数量)` + +### 6.4 销售发货 + +| 指标 | 数据源 | 建议展示 | +|---|---|---| +| 销售交货未清 | `UBT_MES_DP_OpenODLN_material` | KPI + 小表 | +| 今日应发 | `UBT_MES_DP_OpenODLN_material_ToDay` | KPI + 仪表盘 | + +建议统计： + +- 未清数量：`SUM(open_quantity)` +- 加急数量：`SUM(加急数量)` +- 今日应发任务：`COUNT(*)` + +## 7. 数据刷新与交互 + +建议： + +- 自动刷新：5 分钟一次。 +- 大屏不做复杂筛选，只保留数据刷新时间。 +- 明细自动滚动，但查询出几条显示几条，不做重复补齐。 +- 加急、超期用红色；普通待处理用蓝色；正常今日应发用绿色。 + +## 8. 实施建议 + +### 8.1 后端/数据层 + +建议新增一个统一查询入口，避免前端直接拼多个跨库视图。 + +建议过程： + +- `仓库大屏_汇总查询` +- `仓库大屏_入库超期明细` +- `仓库大屏_出库超期明细` +- `仓库大屏_今日应发明细` + +如果短期先做前端，也可以直接通过 `CreateData('11', 过程名/视图包装过程, 参数)` 调用多个接口，但建议最终收敛为存储过程，降低前端计算复杂度。 + +### 8.2 前端页面 + +建议新增页面： + +- 文件：`src/views/WarehouseDashboard.vue` +- 路由名称：`WarehouseDashboard` +- 图表库：继续使用项目现有 `echarts` + +页面组件结构： + +- 顶部 KPI：`summaryCards` +- 入库结构图：`inboundChart` +- 拣配结构图：`pickingChart` +- 风险环图：`riskChart` +- 今日发货图：`deliveryChart` +- 明细表：`riskTables` + +### 8.3 开发顺序 + +1. 先实现汇总接口或视图包装过程。 +2. 实现顶部 KPI 和四个主图表。 +3. 接入 2 个风险明细表。 +4. 根据真实屏幕效果决定是否增加第三个明细表。 +5. 做字体、行高、滚动和适配调优。 + +## 9. 验收标准 + +- 首屏优先展示汇总和图表，明细不占据主要视觉区域。 +- 入库、上架、拣配、发货四条链路都有可见指标。 +- 加急和超期任务有明显红色/橙色强调。 +- 明细列表不重复补齐，查询几条显示几条。 +- 页面在 1920 x 1080 下无文字重叠、无表格溢出。 +- 数据刷新后图表和明细同步更新。 + diff --git a/gptlog-process/gpdlog.md b/gptlog-process/gpdlog.md index e9e9a7a..457a036 100644 --- a/gptlog-process/gpdlog.md +++ b/gptlog-process/gpdlog.md @@ -135,3 +135,255 @@ ### 结论 已将“测试任务汇总”改为“项目 / 产品 / 指标 / 数量”四列结构，产品列按参考图展示图片、产品名称和产品汇总数；构建验证通过。 + +## 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`，确保日志文件本身也包含在待提交内容中。 + +### 结论 +已准备将所有当前修改提交并推送到远程 `origin/main`。 diff --git a/src/router/index.js b/src/router/index.js index 599d46a..d17d80b 100644 --- a/src/router/index.js +++ b/src/router/index.js @@ -21,6 +21,12 @@ const routes = [ path: "/TestTaskDashboard", name: "TestTaskDashboard", component: () => import("@/views/TestTaskDashboard.vue"), + }, + { + // 仓库任务大屏 + path: "/WarehouseDashboard", + name: "WarehouseDashboard", + component: () => import("@/views/WarehouseDashboard.vue"), } ]; diff --git a/src/views/TestTaskDashboard.vue b/src/views/TestTaskDashboard.vue index fc196f5..b54a6c0 100644 --- a/src/views/TestTaskDashboard.vue +++ b/src/views/TestTaskDashboard.vue @@ -46,7 +46,7 @@ - +
{{ row.group }} @@ -91,7 +91,7 @@