feat: add warehouse dashboard

This commit is contained in:
2026-07-06 09:19:46 +08:00
parent 280d0660eb
commit 41af5a74f9
37 changed files with 2223 additions and 58 deletions

10
AGENTS.md Normal file
View File

@@ -0,0 +1,10 @@
# AGENTS.md
## Scope
日志记录规则
每次 GPT/Codex 执行完毕后,须将完整的执行过程日志追加至:
gptlog-process/gpdlog.md
日志包含提问和结论以及完整的执行过程,写入该文件的日志内容必须使用中文记录。

BIN
dist.zip

Binary file not shown.

Binary file not shown.

BIN
doc/仓库大屏数据.docx Normal file

Binary file not shown.

View File

@@ -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 下无文字重叠、无表格溢出。
- 数据刷新后图表和明细同步更新。

View File

@@ -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`

View File

@@ -21,6 +21,12 @@ const routes = [
path: "/TestTaskDashboard",
name: "TestTaskDashboard",
component: () => import("@/views/TestTaskDashboard.vue"),
},
{
// 仓库任务大屏
path: "/WarehouseDashboard",
name: "WarehouseDashboard",
component: () => import("@/views/WarehouseDashboard.vue"),
}
];

View File

@@ -46,7 +46,7 @@
</tr>
</thead>
<tbody>
<tr v-for="row in testSummaryRows" :key="`${row.groupKey}-${row.metricKey}`">
<tr v-for="row in testSummaryRows" :key="`${row.groupKey}-${row.productKey}-${row.metricKey}`">
<td v-if="row.groupRowspan" :rowspan="row.groupRowspan" class="summary-group-cell">
<div class="summary-total">
<span>{{ row.group }}</span>
@@ -91,7 +91,7 @@
</div>
<aside class="right-column">
<article class="panel table-panel">
<div class="panel-caption">发货状态列表</div>
<div class="panel-caption">发货任务列表</div>
<div class="scroll-wrap">
<table>
<thead>
@@ -116,13 +116,13 @@
<thead>
<tr>
<th class="idx-th">序号</th>
<th v-for="c in taskColumns" :key="c.key">{{ c.label }}</th>
<th v-for="c in taskColumns" :key="c.key" :style="{ width: c.width }">{{ c.label }}</th>
</tr>
</thead>
<tbody :style="taskScrollStyle">
<tr v-for="(r, i) in taskDisplayRows" :key="i" :class="{ warning: r.urgentQty > 0 }">
<td class="idx-td">{{ r._idx }}</td>
<td v-for="c in taskColumns" :key="c.key">{{ r[c.key] }}</td>
<td v-for="c in taskColumns" :key="c.key" :style="{ width: c.width }">{{ r[c.key] }}</td>
</tr>
</tbody>
</table>
@@ -214,7 +214,7 @@ const testSummaryGroups = [
label: '系统类',
products: [
{ key: 'systemElectric', label: '电气', image: electricImage },
{ key: 'systemAssembly', label: '装配', image: assemblyImage }
{ key: 'systemAssembly', label: '机械', image: assemblyImage }
]
}
]
@@ -225,19 +225,20 @@ const testSummaryMetrics = [
]
// 生成带序号和循环滚动的显示行
const makeDisplayRows = (rows, offset, visibleCount) => {
const makeDisplayRows = (rows, offset, visibleCount, loopFill = true) => {
if (!rows || rows.length === 0) return []
const len = rows.length
const count = loopFill ? visibleCount : Math.min(visibleCount, len)
const result = []
for (let i = 0; i < visibleCount; i++) {
for (let i = 0; i < count; i++) {
const idx = (offset + i) % len
result.push({ ...rows[idx], _idx: idx + 1 })
}
return result
}
const deliveryDisplayRows = computed(() => makeDisplayRows(deliveryRows.value, deliveryOffset.value, VISIBLE_ROWS.delivery))
const taskDisplayRows = computed(() => makeDisplayRows(taskRows.value, taskOffset.value, VISIBLE_ROWS.task))
const deliveryDisplayRows = computed(() => makeDisplayRows(deliveryRows.value, deliveryOffset.value, VISIBLE_ROWS.delivery, false))
const taskDisplayRows = computed(() => makeDisplayRows(taskRows.value, taskOffset.value, VISIBLE_ROWS.task, false))
const doneDisplayRows = computed(() => makeDisplayRows(doneRows.value, doneOffset.value, VISIBLE_ROWS.done))
const testSummaryRows = computed(() => {
const rows = []
@@ -288,9 +289,21 @@ const startScroll = (rowsRef, offsetRef) => {
return id
}
const startScrollWhenOverflow = (rowsRef, offsetRef, visibleCount) => {
const id = window.setInterval(() => {
if (rowsRef.value.length > visibleCount) {
offsetRef.value = (offsetRef.value + 1) % rowsRef.value.length
} else if (offsetRef.value !== 0) {
offsetRef.value = 0
}
}, 2000)
scrollTimers.push(id)
return id
}
const startAllScroll = () => {
startScroll(deliveryRows, deliveryOffset)
startScroll(taskRows, taskOffset)
startScrollWhenOverflow(deliveryRows, deliveryOffset, VISIBLE_ROWS.delivery)
startScrollWhenOverflow(taskRows, taskOffset, VISIBLE_ROWS.task)
startScroll(doneRows, doneOffset)
}
@@ -302,6 +315,7 @@ const stopAllScroll = () => {
// ============ 数据查询 ============
const searchDashboardData = () => {
searchTestAssemblyTaskData()
searchTestAssemblyTaskListData()
searchQualityTimelinessData()
searchStagnationData()
searchDoneTaskData()
@@ -317,6 +331,9 @@ const searchTestAssemblyTaskData = () => {
]
queryDashboardData('质量管理_测试装配任务_查询', applyTestAssemblyTaskData, param)
}
const searchTestAssemblyTaskListData = () => {
queryDashboardData('质量管理_测试装配任务_查询2', applyTaskData)
}
const searchQualityTimelinessData = () => {
const param = [
['任务类型', '全部'],
@@ -365,8 +382,6 @@ const applyTestAssemblyTaskData = rows => {
summaryCards[0].value = executableRows.filter(isReworkTask).length
summaryCards[1].value = sortedRows.filter(isUrgentTask).length
summaryCards[4].value = sortedRows.reduce((sum, item) => sum + getNumber(item.异常未关闭数 || item.测试装配异常未关闭总数), 0)
applyTaskData(sortedRows)
}
const applyQualityTimelinessData = rows => {
const row = getFirstRow(rows)
@@ -399,12 +414,9 @@ const applyDeliveryData = rows => {
salesOrder: item.合同号 || '',
materialName: item.物料描述 || '',
materialCode: item.物料编号 || '',
completeSet: item.齐套 === 1 ? '是' : '否',
issueStatus: item.发料状态 === '1' ? '发料齐套' : (item.发料状态 === '2' ? '发料缺件' : ''),
urgentQty: item.操作人,
assignQty: item.交货数量,
taskdate: requiredDate,
operator: item.任务状态 === 0 ? '待执行' : (item.发料状态 === 1 ? '可执行' : '已开工'),
accumulatedHours: formatWorkMinutes(item.合同装配工时),
}
})
}
@@ -422,14 +434,13 @@ const applyTaskData = rows => {
taskRows.value = rows.map(item => ({
productionOrder: item.生产订单?.toString() || item.订单号?.toString() || item.计划号?.toString() || '',
salesOrder: item.销售订单 || item.合同号 || '',
materialName: item.物料名称 || item.零件名称 || '',
materialCode: item.物料编码 || item.零件编码 || '',
materialName: item.物料名称 || item.物料描述 || item.零件名称 || '',
materialCode: item.物料编码 || item.物料编号 || item.零件编码 || '',
taskType: item.任务类型 || (String(item.自制件属性 || item.物料名称 || item.零件名称 || '').includes('系统') ? '系统类' : '阀类'),
urgentQty: getNumber(item.加急总数 || item.加急数量),
assignQty: getNumber(item.计划数量 || item.计划生产数 || item.分配数),
completeQty: getNumber(item.完成数量),
inspectQty: getNumber(item.检验数量),
expectedInspectionDate: formatDate(item.预计送检日期)
operator: item.操作人 || ''
}))
}
const queryDashboardData = (procedureName, applyData, param = []) => {
@@ -462,12 +473,40 @@ const formatDate = value => {
return String(value).split(' ')[0]
}
const formatWorkMinutes = value => {
if (value === null || value === undefined || value === '') return ''
const number = getNumber(value)
if (number <= 0) return '0'
const minutes = number / 60
return Number.isInteger(minutes) ? String(minutes) : minutes.toFixed(2)
}
const getDateTime = value => {
if (!value) return Infinity
const time = new Date(String(value).replace(/-/g, '/')).getTime()
return Number.isNaN(time) ? Infinity : time
}
const getField = (row, fields) => {
for (const field of fields) {
if (row[field] !== undefined && row[field] !== null) {
return row[field]
}
}
return ''
}
const normalizeText = value => {
if (value === undefined || value === null) {
return ''
}
return String(value).trim()
}
const getMaterialCodeText = item => normalizeText(getField(item, ['物料编码', '零件编码', '物料编号', '零件编号', '产品编码']))
const getAssignTargetText = item => normalizeText(getField(item, ['指派对象', '二次派工']))
const getTaskType = item => item.任务类型 || (String(item.自制件属性 || item.物料名称 || item.零件名称 || '').includes('系统') ? '系统类' : '阀类')
const isInspectionUnfinished = item => getNumber(item.完成数量) > getNumber(item.检验数量)
@@ -477,20 +516,32 @@ const isReworkTask = item => String(item.检测说明 || '').includes('返工')
const isUrgentTask = item => getNumber(item.加急总数 || item.加急数量) > 0
const getTaskGroupKey = item => {
const taskType = String(getTaskType(item))
const text = String(item.自制件属性 || item.物料名称 || item.零件名称 || item.物料描述 || '')
return taskType.includes('系统') || text.includes('系统') ? 'system' : 'valve'
const materialCode = getMaterialCodeText(item)
if (materialCode.includes('系统')) {
return 'system'
}
if (materialCode.includes('阀')) {
return 'valve'
}
const taskType = normalizeText(getTaskType(item))
const fallbackText = normalizeText(getField(item, ['自制件属性', '物料名称', '零件名称', '物料描述']))
return taskType.includes('系统') || fallbackText.includes('系统') ? 'system' : 'valve'
}
const getTaskProductKey = item => {
const groupKey = getTaskGroupKey(item)
const text = String(item.任务类型 || item.自制件属性 || item.物料名称 || item.零件名称 || item.物料描述 || '')
if (groupKey === 'system') {
return text.includes('电气') ? 'systemElectric' : 'systemAssembly'
const assignTarget = getAssignTargetText(item)
return assignTarget.includes('电气装配') || assignTarget.includes('电气') ? 'systemElectric' : 'systemAssembly'
}
return text.includes('阀') ? 'valveMain' : 'valveOther'
return getMaterialCodeText(item).includes('阀') ? 'valveMain' : 'valveOther'
}
const countTestProductTotal = productKey => {
return rawTestAssemblyRows.value.filter(item => getTaskProductKey(item) === productKey).length
}
const countTestSummaryRows = (productKey, metricKey) => {
@@ -502,7 +553,7 @@ const countTestSummaryRows = (productKey, metricKey) => {
}
const getTestProductTotal = productKey => {
return testSummaryMetrics.reduce((total, metric) => total + countTestSummaryRows(productKey, metric.key), 0)
return countTestProductTotal(productKey)
}
const getTestGroupTotal = group => {
@@ -562,16 +613,15 @@ const summaryCards = reactive([
{ title: '异常未关闭消息数', value: 0, unit: '条', icon: icons.urgent, valueClass: 'red-text', className: 'exception-card' }
])
const taskColumns = [
{ label: '生产订单', key: 'productionOrder', width: '72px' },
{ label: '生产订单', key: 'productionOrder', width: '92px' },
{ label: '销售订单', key: 'salesOrder', width: '92px' },
{ label: '物料名称', key: 'materialName', width: '190px' },
{ label: '物料编码', key: 'materialCode', width: '176px' },
{ label: '任务类型', key: 'taskType', width: '62px' },
{ label: '物料名称', key: 'materialName', width: '220px' },
{ label: '物料编码', key: 'materialCode', width: '260px' },
{ label: '任务类型', key: 'taskType', width: '92px' },
{ label: '加急数', key: 'urgentQty', width: '62px' },
{ label: '计划数', key: 'assignQty', width: '70px' },
{ label: '完成数', key: 'completeQty', width: '70px' },
{ label: '检验数', key: 'inspectQty', width: '70px' },
{ label: '预计送检', key: 'expectedInspectionDate', width: '88px' },
{ label: '操作人', key: 'operator', width: '120px' },
]
const taskColumns2 = [
@@ -581,10 +631,7 @@ const taskColumns2 = [
{ label: '物料编码', key: 'materialCode', width: '176px' },
{ label: '数量', key: 'assignQty', width: '176px' },
{ label: '要求发货日期', key: 'taskdate', width: '176px' },
{ label: '齐套', key: 'completeSet', width: '52px' },
{ label: '发料状态', key: 'issueStatus', width: '88px' },
{ label: '操作人', key: 'urgentQty', width: '62px' },
{ label: '装配开工', key: 'operator', width: '82px' },
{ label: '累计工时', key: 'accumulatedHours', width: '82px' },
]
const doneColumns = [
{ label: '生产订单', key: 'productionOrder', width: '88px' },
@@ -993,28 +1040,40 @@ th {
height: 47px;
}
.test-summary-panel .panel-caption {
height: 34px;
font-size: 26px;
line-height: 34px;
}
.test-summary-panel .summary-wrap {
padding: 0 7px 7px;
}
.test-summary-table th {
height: 48px;
height: 38px;
font-size: 18px;
}
.test-summary-table td {
height: 55px;
height: 40px;
font-size: 18px;
}
.summary-group-th {
width: 126px;
width: 124px;
}
.summary-product-th {
width: 250px;
width: 244px;
}
.summary-metric-th {
width: 104px;
width: 98px;
}
.summary-count-th {
width: 94px;
width: 88px;
}
.summary-group-cell {
@@ -1025,20 +1084,20 @@ th {
.summary-total {
display: grid;
gap: 12px;
gap: 6px;
justify-items: center;
line-height: 1.05;
}
.summary-total span {
color: #ffffff;
font-size: 30px;
font-size: 27px;
font-weight: 900;
}
.summary-total strong {
color: #ff3040;
font-size: 38px;
font-size: 34px;
font-weight: 900;
}
@@ -1048,45 +1107,45 @@ th {
.summary-product {
display: grid;
grid-template-columns: 118px minmax(0, 1fr);
grid-template-columns: 88px minmax(0, 1fr);
align-items: center;
gap: 10px;
min-height: 110px;
padding: 8px 12px;
gap: 6px;
min-height: 78px;
padding: 4px 8px;
}
.summary-product-image {
width: 106px;
height: 90px;
width: 82px;
height: 62px;
object-fit: contain;
}
.summary-product-text {
display: grid;
gap: 8px;
gap: 4px;
justify-items: center;
line-height: 1.05;
}
.summary-product-text span {
color: #ffffff;
font-size: 26px;
font-size: 24px;
font-weight: 900;
}
.summary-product-text strong {
color: #ff3040;
font-size: 34px;
font-size: 31px;
font-weight: 900;
}
.summary-metric-cell {
font-size: 26px;
font-size: 24px;
font-weight: 900;
}
.summary-count-cell {
font-size: 34px;
font-size: 31px;
font-weight: 900;
}

File diff suppressed because it is too large Load Diff

Binary file not shown.

After

Width:  |  Height:  |  Size: 52 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 320 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 250 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 252 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 245 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 178 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 352 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 277 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 130 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 107 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 150 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 193 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 206 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 100 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 176 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 319 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 324 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 212 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 366 KiB

View File

@@ -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 下无文字重叠、无表格溢出。
- 数据刷新后图表和明细同步更新。

View File

@@ -0,0 +1,49 @@
# 01-项目功能内容
## 目标页面
- 页面路径:`src/views/index.vue`
- 页面名称:装配中心任务看板
## 本次功能调整
1. 注释/移除页面展示中的以下模块:
- 在制任务缺件明细列表
- 已完成任务列表
- 可执行任务数卡片
- 及时送检数卡片
- 加急任务数卡片
2. 调整页面布局:
- 左侧新增“装配任务分类汇总”表。
- 右侧上下排列“发货状态列表”和“在制任务列表”。
- 顶部保留汇总卡片,并放置“装配合格率”“异常未关闭”。
- 页面不保留空白区域。
3. 新增 16 行分类汇总表:
- 大类:阀类、系统类。
- 阀类细分:阀类、其他类。
- 系统类细分:电气类、装配类。
- 每个细分类下统计:派工、齐套、加急、滞留。
## 数据口径
- 所有新增汇总计算先过滤:`计划数量 > 完成数量`
- 辅助配件筛选条件:`包含`
- 阀类数据参考:`PlanManagement/ValueInstallTask/index.vue`
- 系统类数据参考:`PlanManagement/SystemInstallTask/index.vue`
- 滞留数据参考:`AnomalousManagement/AssemblyPunctualInspection/index.vue`
## 汇总规则
- 派工:`派工时间` 不为空。
- 齐套:任务状态为可执行;前端兼容 `任务状态=1` 或字段文本包含“可执行”,并在缺少任务状态时兼容 `齐套=1/是`
- 加急:`加急总数``加急数量``加急数` 大于 0`加急状态/加急` 包含“加急”,或 `优先级=是`
- 滞留来自“异常提醒_装配及时送检_查询”的未及时送检数据。
## 保留列表
- 发货状态列表:继续使用 `装配中心任务看板_发货状态查询`
- 在制任务列表:继续使用 `装配中心任务看板_装配在制任务查询`
- 装配合格率:继续使用 `装配中心任务看板_装配合格率`
- 异常未关闭:继续使用 `装配中心任务看板_异常未关闭总数`

View File

@@ -0,0 +1,52 @@
# 02-项目程序开发详细步骤
## 1. 修改前基线入库
1. 当前目录原先不是 Git 仓库。
2. 创建远程仓库:`zhangxinyang/zhuangpei-task-kanban`
3. 本地执行 `git init -b main`
4. 提交当前代码:`e003b23 chore: baseline before dashboard update`
5. 推送到远程 `main`,远程地址不写入密码。
## 2. 读取方案与参考页面
1. 解包并读取 `doc/装配中心任务看板修改方案.docx`
2. 查看文档中的当前页截图和目标 16 行表格截图。
3. 使用 UTF-8 读取参考页面,确认字段与存储过程:
- `ProductionManagement/DeliveryNoticeList/index.vue`
- `PlanManagement/ValueInstallTask/index.vue`
- `PlanManagement/SystemInstallTask/index.vue`
- `AnomalousManagement/AssemblyPunctualInspection/index.vue`
## 3. 页面结构调整
1. 重写 `src/views/index.vue` 模板。
2. 顶部改为 6 个卡片:
- 派工汇总
- 齐套汇总
- 加急汇总
- 滞留汇总
- 装配合格率
- 异常未关闭
3. 主区域改为两列:
- 左侧:装配任务分类汇总,完整显示 16 行。
- 右侧:发货状态列表、在制任务列表。
## 4. 数据查询调整
1. 删除页面中缺件明细、已完成任务、可执行任务数、及时送检数、加急任务总数的查询调用。
2. 新增聚合查询:
- `计划排产_阀类任务查询`
- `计划排产_系统类任务查询`
- `异常提醒_装配及时送检_查询`
3. 查询参数统一补充:
- `物料类型=自制件`
- `辅助配件=包含`
- `指派对象=全部`
- `排产状态=已完成`
4. 前端聚合统一应用 `计划数量 > 完成数量`
## 5. 验证
1. 执行 `npm run build`
2. 构建通过,存在 Vite chunk 体积警告和 Sass legacy API 警告,均为现有依赖/打包提示,不影响本次页面编译。

View File

@@ -0,0 +1,8 @@
# 03-推进台账
| 轮次 | 日期 | 做了什么 | 改了哪些文件 | 验证了什么 | 下一步 |
| --- | --- | --- | --- | --- | --- |
| 1 | 2026-07-02 | 读取方案 docx、查看目标截图、检查参考页面和现有 `index.vue`。 | 无 | 确认方案要求与参考接口。 | 先按用户要求上传修改前代码。 |
| 2 | 2026-07-02 | 初始化 Git 仓库,创建远程仓库并推送修改前基线。 | `.git` 元数据 | `git push -u origin main` 成功。 | 开始页面修改。 |
| 3 | 2026-07-02 | 重写 `src/views/index.vue`,调整布局、删除不需要展示/查询的模块、新增 16 行汇总表和前端聚合逻辑。 | `src/views/index.vue` | `npm run build` 通过。 | 补齐 work 文档与过程日志。 |
| 4 | 2026-07-02 | 创建 work 文档目录,复制原始方案,补充 README、01-06 文档和中文过程日志。 | `work/装配中心任务看板修改方案/*``gptlog-process/gpdlog.md` | 文档路径与内容完整。 | 复核 Git 状态并交付结果。 |

View File

@@ -0,0 +1,16 @@
# 04-任务矩阵
| 任务编号 | 任务内容 | 状态 | 验收标准 |
| --- | --- | --- | --- |
| T-001 | 修改前代码上传远程 | 已完成 | 远程仓库存在,`main` 分支包含基线提交 `e003b23`。 |
| T-002 | 移除缺件明细列表展示 | 已完成 | 页面模板中不再渲染“在制任务缺件明细”。 |
| T-003 | 移除已完成任务列表展示 | 已完成 | 页面模板中不再渲染“已完成任务”。 |
| T-004 | 移除可执行/及时送检/加急卡片 | 已完成 | 顶部不再展示原三个卡片,不再调用对应总数查询。 |
| T-005 | 发货状态列表移到右侧 | 已完成 | 主区域右侧上半部分显示“发货状态列表”。 |
| T-006 | 在制任务列表移到右侧 | 已完成 | 主区域右侧下半部分显示“在制任务列表”。 |
| T-007 | 新增左侧 16 行分类汇总表 | 已完成 | 左侧表按阀类/系统类及派工、齐套、加急、滞留完整显示 16 行。 |
| T-008 | 汇总计算增加计划数量大于完成数量过滤 | 已完成 | `countRows` 聚合前调用 `isPlanUnfinished`。 |
| T-009 | 阀类/系统类分类参考指定页面 | 已完成 | 使用阀类、系统类计划排产查询,并按产品名称/指派对象分类。 |
| T-010 | 保留装配合格率和异常未关闭 | 已完成 | 顶部卡片显示“装配合格率”和“异常未关闭”。 |
| T-011 | 构建验证 | 已完成 | `npm run build` 成功。 |
| T-012 | work 文档与日志 | 已完成 | work 目录包含方案副本、README、01-06 文档,过程日志已追加。 |

View File

@@ -0,0 +1,51 @@
# 05-验收证据
## 远程基线
- 远程仓库:`http://154.8.160.151:3000/zhangxinyang/zhuangpei-task-kanban`
- 基线分支:`main`
- 基线提交:`e003b23 chore: baseline before dashboard update`
- 推送命令结果:`main -> main`,并设置本地分支跟踪 `origin/main`
## 修改文件
- `src/views/index.vue`
- `work/装配中心任务看板修改方案/README.md`
- `work/装配中心任务看板修改方案/01-项目功能内容.md`
- `work/装配中心任务看板修改方案/02-项目程序开发详细步骤.md`
- `work/装配中心任务看板修改方案/03-推进台账.md`
- `work/装配中心任务看板修改方案/04-任务矩阵.md`
- `work/装配中心任务看板修改方案/05-验收证据.md`
- `work/装配中心任务看板修改方案/06-决策记录.md`
- `gptlog-process/gpdlog.md`
## 验证命令
```bash
npm run build
```
## 验证结果
- Vite 构建成功。
- 转换模块数3697。
- 输出目录:`dist/`
- 构建提示:
- Sass legacy JS API deprecation warning。
- chunk 大小超过 500kB 警告。
- 判断:以上为依赖和打包体积提示,不是本次页面代码编译错误。
## 页面证据
- 页面入口:`/`
- 路由文件:`src/router/index.js`
- 页面文件:`src/views/index.vue`
- 本地开发服务:`http://localhost:5174/`
- 入口访问验证:`Invoke-WebRequest http://localhost:5174/` 返回 `StatusCode=200`
## job_id / report_id / PDF / 截图
- job_id无。
- report_id无。
- PDF无。
- 截图:本轮未生成新截图,方案截图来自原始 docx。

View File

@@ -0,0 +1,31 @@
# 06-决策记录
## D-001先创建新远程仓库保存基线
- 背景:当前项目目录不是 Git 仓库,账号下已有仓库 `meswork/10-JixaZhuangPei-Kanban`,但描述为“机匣装配单元生产看板”,与当前“装配中心任务看板”不完全一致。
- 决策:创建新仓库 `zhangxinyang/zhuangpei-task-kanban`,保存修改前基线。
- 原因:避免覆盖已有远程项目历史。
## D-002重写 `index.vue` 而不是局部修补
- 背景:原文件虽然 UTF-8 读取正常,但页面结构已不符合方案要求,且包含多个不再需要的查询和展示模块。
- 决策:保留缩放框架、全局注入接口和视觉风格,重写模板、脚本和样式。
- 原因:减少遗留逻辑干扰,确保页面没有空白区域。
## D-003新增汇总表在前端聚合
- 背景:方案没有提供新后端存储过程,只要求参考已有页面。
- 决策:复用 `计划排产_阀类任务查询``计划排产_系统类任务查询``异常提醒_装配及时送检_查询`,在前端按 16 行规则聚合。
- 原因:不新增后端接口,改动范围集中在看板页面。
## D-004齐套统计做兼容处理
- 背景:方案文字写到 `任务状态=1`,目标图条件写“任务状态为可执行”,现有参考表也展示 `齐套` 字段。
- 决策:优先使用 `任务状态=1/可执行`,缺少任务状态时兼容 `齐套=1/是`
- 原因:避免不同接口字段不一致导致汇总始终为 0。
## D-005保留装配合格率与异常未关闭
- 背景:方案允许“有地方放就放,没地方也注释掉”。
- 决策:顶部 6 卡片中保留这两项,同时显示新增汇总的四个总数。
- 原因:顶部空间足够,且不产生空白区域。

View File

@@ -0,0 +1,22 @@
# 装配中心任务看板修改方案索引
## 文档目录
- `装配中心任务看板修改方案.docx`:原始修改方案。
- `01-项目功能内容.md`:本次页面功能范围和数据口径。
- `02-项目程序开发详细步骤.md`:实施步骤、涉及接口和前端处理。
- `03-推进台账.md`:每轮做了什么、改了哪些文件、验证了什么、下一步是什么。
- `04-任务矩阵.md`:任务编号、状态、验收标准。
- `05-验收证据.md`:命令、页面、远程提交、构建结果等证据。
- `06-决策记录.md`:关键实现取舍和后续变更依据。
## 当前状态
- 修改前基线已推送到远程仓库:`http://154.8.160.151:3000/zhangxinyang/zhuangpei-task-kanban`
- 基线提交:`e003b23 chore: baseline before dashboard update`
- 页面修改文件:`src/views/index.vue`
- 验证命令:`npm run build`
## 后续推进方式
后续继续开发时,优先查看 `04-任务矩阵.md`,按任务编号补充状态和验收证据,避免重复处理同一项。