595 lines
24 KiB
Markdown
595 lines
24 KiB
Markdown
# 订单模式工作模式与工作规则说明
|
||
|
||
> 文档用途：说明当前生产扫码 APP 中“订单模式”的实际工作方式、数据规则、校验规则、状态流转与边界。本文仅基于当前项目已实现代码梳理；对尚未实现或未被调用的配置能力，会明确标注，避免将规划误认为现行规则。
|
||
>
|
||
> 适用范围：`frontend/scanapp` 移动端订单模式、`backend/plugin/produce` 的 APP API 及其生产记录数据。
|
||
|
||
---
|
||
|
||
## 1. 概述
|
||
|
||
订单模式用于生产人员在指定的**工序**和**步骤**下，对单个订单号进行扫码或手工录入，并生成一条订单扫码记录。
|
||
|
||
一次成功提交的核心结果是：
|
||
|
||
1. 生成一条 `produce_scan_data` 订单扫码记录；
|
||
2. 将当前登录用户映射为记录的操作人员；
|
||
3. 为记录写入当前步骤的初始状态；
|
||
4. 对满足条件的上游步骤，尝试执行“下一步骤扫码”自动状态转换；
|
||
5. 更新移动端的最近记录与统计数据。
|
||
|
||
订单模式是**单订单、单次记录**的录入模式。它记录订单在某工序步骤的作业动作，不等同于订单主档，也不会在当前实现中直接维护“整张订单已完成”的全局终态。
|
||
|
||
---
|
||
|
||
## 2. 现行工作模式
|
||
|
||
### 2.1 操作入口与页面
|
||
|
||
| 项目 | 当前实现 |
|
||
| --- | --- |
|
||
| 页面 | `frontend/scanapp/pages/entry/order.vue` |
|
||
| 页面名称 | 订单模式 |
|
||
| 主要用途 | 扫描订单号并按当前工序、步骤提交生产扫码记录 |
|
||
| 提交接口 | `POST /appapi/produce/scan-data/record` |
|
||
| 最近记录接口 | `GET /appapi/produce/scan-data` |
|
||
| 统计接口 | `GET /appapi/produce/scan-data/statistics` |
|
||
| 配置接口 | `GET /appapi/produce/config/data-entry` |
|
||
|
||
APP 请求基础前缀为 `/appapi`；生产插件通过 Swagger 注解注册 APP API 路由。控制器实际执行逻辑位于：
|
||
|
||
```text
|
||
backend/plugin/produce/app/api/controller/DataEntryController.php
|
||
```
|
||
|
||
APP API 控制器为委托层，复用上述逻辑。
|
||
|
||
### 2.2 页面加载后的准备流程
|
||
|
||
订单模式页面加载时，按当前本地登录用户初始化并请求以下数据：
|
||
|
||
1. 从本地缓存 `scanapp_user` 读取用户编码；
|
||
- 取值优先级：`username` → `nickname` → 默认值 `U001`。
|
||
2. 获取启用的工序列表；
|
||
3. 获取当前用户的订单模式统计；
|
||
4. 获取当前用户的最近订单扫码记录；
|
||
5. 根据已保存的个人选择恢复工序与步骤；
|
||
6. 获取当前工序的启用步骤；
|
||
7. 获取当前工序/步骤对应的录入配置和特定规则。
|
||
|
||
用户的工序、步骤选择会保存到本地存储，键名格式为：
|
||
|
||
```text
|
||
scanapp_entry_order_selection_<用户编码>
|
||
```
|
||
|
||
保存字段为：
|
||
|
||
```json
|
||
{
|
||
"processId": "工序ID",
|
||
"stepId": "步骤ID"
|
||
}
|
||
```
|
||
|
||
因此，同一用户再次进入订单模式时，会优先恢复上一次选择的工序与步骤；不同用户的选择互不覆盖。
|
||
|
||
### 2.3 工序和步骤选择规则
|
||
|
||
#### 工序
|
||
|
||
- 数据源：`produce_process`。
|
||
- 仅返回 `status = 1` 的启用工序。
|
||
- 排序：先按 `sort` 升序，再按 `id` 升序。
|
||
- 操作人员可在页面中切换工序。
|
||
|
||
#### 步骤
|
||
|
||
- 数据源：`produce_process_step`。
|
||
- 仅返回 `status = 1` 的启用步骤。
|
||
- 仅返回当前选中工序下的步骤。
|
||
- 排序：先按 `sort` 升序，再按 `id` 升序。
|
||
- 切换工序后，页面会重新加载步骤、录入配置，并保存当前选择。
|
||
|
||
### 2.4 订单号录入方式
|
||
|
||
订单号支持两种录入方式：
|
||
|
||
1. **手工输入**：在订单号输入框直接录入；
|
||
2. **相机扫码**：调用 `uni.scanCode`，仅允许通过相机扫码，支持：
|
||
- 一维条码：`barCode`
|
||
- 二维码：`qrCode`
|
||
|
||
扫码成功后，系统将结果转为字符串并去除首尾空格，再回填订单号字段。扫码取消或失败时，页面提示“未完成扫码”。
|
||
|
||
### 2.5 连续扫码
|
||
|
||
页面提供“连续扫码”开关，默认关闭。
|
||
|
||
- 关闭：提交成功后清空订单号，等待下一次手工输入或主动扫码。
|
||
- 开启：提交成功后清空订单号、刷新页面数据，并在约 350 毫秒后自动再次唤起相机扫码。
|
||
|
||
连续扫码只影响前端扫码动作，不改变后端校验、记录创建或状态流转规则。
|
||
|
||
---
|
||
|
||
## 3. 提交前校验规则
|
||
|
||
订单模式采取“前端预校验 + 后端强制校验”的方式。前端用于及时提示，后端是最终准入边界。
|
||
|
||
### 3.1 页面级必填校验
|
||
|
||
提交前必须满足：
|
||
|
||
| 校验项 | 规则 | 失败提示 |
|
||
| --- | --- | --- |
|
||
| 订单号 | 去除首尾空格后不能为空 | 请输入订单号 |
|
||
| 工序 | 当前必须存在有效选中项 | 请选择工序 |
|
||
| 步骤 | 当前必须存在有效选中项 | 请选择步骤 |
|
||
|
||
### 3.2 基础配置校验
|
||
|
||
配置来源为 `produce_config` 表中 `group_code = basic_setting` 的配置项。当前订单模式实际使用以下字段：
|
||
|
||
| 配置代码 | 当前作用 |
|
||
| --- | --- |
|
||
| `order_no_min_length` | 大于 0 时，订单号长度不得小于该值 |
|
||
| `order_no_regex` | 配置非空时，订单号必须匹配该正则表达式 |
|
||
| `global_allow_repeat` | 步骤未覆盖时，作为全局重复扫码默认开关 |
|
||
| `repeat_scan_interval` | 重复扫码最短间隔，单位秒 |
|
||
| `recent_records_today_only` | 控制最近记录和统计在无订单号筛选时是否仅统计当天 |
|
||
|
||
规则说明：
|
||
|
||
- 未配置 `order_no_min_length` 或值小于等于 0：不做最小长度限制；
|
||
- 未配置 `order_no_regex`：不做格式正则校验；
|
||
- 正则配置格式异常时，前端会记录错误日志，但不会因该错误阻塞用户提交；后端的特定规则匹配会将无法匹配的规则视为不命中。
|
||
|
||
### 3.3 特定规则（订单命中规则）
|
||
|
||
特定规则来源：`produce_specific_rule`，仅查询 `is_enabled = 1` 的规则，并按 `sort`、`id` 升序处理。
|
||
|
||
规则可按以下维度限制：
|
||
|
||
| 字段 | 说明 |
|
||
| --- | --- |
|
||
| `apply_mode` | 生效模式：`order` 表示订单模式，`both` 表示订单和整机模式均生效 |
|
||
| `match_field` | 用于匹配的字段；订单模式默认是 `order_no` |
|
||
| `rule_pattern` | 正则表达式内容 |
|
||
| `step_ids` | 可选的步骤 ID 范围；为空表示不限制步骤 |
|
||
| `rule_type` | 当前实现中 `2` 表示命中后禁止提交；`1` 在重复扫码策略中表示允许重复 |
|
||
|
||
订单模式页面会在提交前检查：若存在一个满足模式、步骤范围和正则条件的 `rule_type = 2` 规则，则拒绝提交，并提示规则名称；规则未命名时提示“当前订单命中特定规则，禁止提交”。
|
||
|
||
> 注意：前端会先加载规则并做预拦截；后端 `record` 提交接口当前没有再次执行“订单号长度、订单号正则、禁止型特定规则”的完整校验。因此，客户端校验不能替代服务端校验。现行系统中，前置步骤、重复扫码、用户编码和请求字段校验由后端强制执行。
|
||
|
||
### 3.4 后端请求字段校验
|
||
|
||
接口 `POST /produce/scan-data/record` 使用 `ScanDataValidate` 的 `store` 场景校验，要求：
|
||
|
||
| 字段 | 规则 |
|
||
| --- | --- |
|
||
| `order_no` | 必填，最长 100 字符 |
|
||
| `user_code` | 必填，最长 50 字符 |
|
||
| `process_id` | 必填，整数 |
|
||
| `step_id` | 必填，整数 |
|
||
| `status_id` | 可选，整数 |
|
||
| `scan_result` | 必填，只允许 `0` 或 `1` |
|
||
| `remark` | 可选，最长 65535 字符 |
|
||
|
||
当前订单模式前端固定提交：
|
||
|
||
```json
|
||
{
|
||
"order_no": "订单号",
|
||
"user_code": "当前用户编码",
|
||
"process_id": "当前工序ID",
|
||
"step_id": "当前步骤ID",
|
||
"scan_result": 1
|
||
}
|
||
```
|
||
|
||
即订单模式正常提交默认写入成功结果 `scan_result = 1`，页面没有提供失败结果或备注的录入控件。
|
||
|
||
### 3.5 操作人员校验与归属
|
||
|
||
后端以 `user_code` 查询会员表 `member` 的 `username`：
|
||
|
||
- 用户不存在：拒绝提交，返回“用户编码不存在”；
|
||
- 用户存在：后端以会员真实信息写入操作人员信息；
|
||
- `user_code`：请求中的用户编码；
|
||
- `operator`：优先会员昵称，否则使用会员用户名；
|
||
- `operator_id`：会员 ID。
|
||
|
||
前端传入的 `operator` 不作为最终可信操作人员来源，服务端会重新从会员数据生成操作人快照。
|
||
|
||
---
|
||
|
||
## 4. 前置步骤与重复扫码规则
|
||
|
||
### 4.1 前置步骤规则
|
||
|
||
每个步骤可以配置前置步骤，配置字段属于 `produce_process_step`：
|
||
|
||
| 字段 | 含义 |
|
||
| --- | --- |
|
||
| `prerequisite_steps` | 前置步骤 ID 数组 |
|
||
| `prerequisite_mode` | 验证模式：`all`、`any`、`none` |
|
||
| `prerequisite_require_final` | 是否要求前置步骤已进入终态：`1` 是，`0` 否 |
|
||
|
||
后端在创建当前步骤记录前执行校验。
|
||
|
||
#### 验证模式
|
||
|
||
| 模式 | 含义 | 不满足时的结果 |
|
||
| --- | --- | --- |
|
||
| `none` | 不校验前置步骤，或未配置前置步骤 | 允许提交 |
|
||
| `all` | 所有前置步骤都要满足 | 返回“前置步骤未完成：步骤A、步骤B” |
|
||
| `any` | 至少一个前置步骤满足 | 返回“前置步骤未满足，至少需要完成一个前置步骤” |
|
||
|
||
#### 前置步骤满足条件
|
||
|
||
系统以“同一订单号 + 指定前置步骤”查询历史订单扫码记录：
|
||
|
||
- `prerequisite_require_final = 0`：只要存在任意历史记录，即视为满足；
|
||
- `prerequisite_require_final = 1`：必须存在关联步骤状态为 `is_final = 1` 的历史记录，才视为满足。
|
||
|
||
因此，是否称得上“完成”，在当前订单流程中取决于**步骤状态是否是终态**，而不是仅仅存在过扫码记录。
|
||
|
||
### 4.2 重复扫码规则
|
||
|
||
后端以“同订单号 + 同工序 + 同步骤”查询最新扫码记录。若不存在历史记录，允许直接提交；若存在，则按下列优先级计算重复扫码策略：
|
||
|
||
1. 全局基础配置 `global_allow_repeat`、`repeat_scan_interval`；
|
||
2. 当前步骤配置覆盖全局是否允许重复及允许的状态；
|
||
3. 命中的特定规则可最终覆盖“是否允许重复”。
|
||
|
||
#### 默认与覆盖逻辑
|
||
|
||
| 配置来源 | 影响 |
|
||
| --- | --- |
|
||
| `global_allow_repeat` | 未配置步骤规则时的默认允许重复开关 |
|
||
| `repeat_scan_interval` | 最短重复扫码间隔（秒） |
|
||
| `allow_repeat_scan` | 步骤级允许重复开关，会覆盖全局开关 |
|
||
| `repeat_scan_statuses` | 限制仅在指定状态下允许重复；空数组表示不额外限制状态 |
|
||
| 命中特定规则且 `rule_type = 1` | 允许重复 |
|
||
| 命中特定规则且 `rule_type != 1` | 不允许重复 |
|
||
|
||
当存在历史记录时，以下任一条件不满足都会拒绝提交：
|
||
|
||
1. 当前策略未允许重复：提示“当前配置不允许重复扫码”；
|
||
2. 配置了允许重复状态，且最近记录的状态不在范围内：提示“当前状态不允许重复扫码”；
|
||
3. 配置了最短间隔，且距离最近一次扫码不足该秒数：提示“重复扫码间隔不能小于 N 秒”。
|
||
|
||
> 实现细节：重复扫描校验只检查同工序、同步骤下的最新记录，不会因其他步骤或其他工序的记录直接阻止当前提交。
|
||
|
||
---
|
||
|
||
## 5. 状态与工作流规则
|
||
|
||
### 5.1 订单扫码记录的初始状态
|
||
|
||
提交接口收到 `status_id` 时会优先使用该值；订单模式页面当前不传 `status_id`，因此后端会自动查询当前步骤 `is_initial = 1` 的状态并写入记录。
|
||
|
||
相关状态配置表为 `produce_step_status`：
|
||
|
||
| 字段 | 说明 |
|
||
| --- | --- |
|
||
| `step_id` | 所属步骤 |
|
||
| `status_code` / `status_name` | 状态编码与显示名称 |
|
||
| `is_initial` | 是否初始状态 |
|
||
| `is_final` | 是否终态 |
|
||
| `status` | 是否启用 |
|
||
|
||
当前实现没有在记录创建时显式校验“初始状态是否唯一、是否启用”；管理端配置时应保证每个可用步骤存在明确且唯一的初始状态，避免记录没有状态或状态语义不确定。
|
||
|
||
### 5.2 下一步骤扫码触发上游状态转换
|
||
|
||
提交当前步骤订单记录后，后端在同一数据库事务中处理“下一步骤扫码自动触发状态转换”。该机制含义是：当前步骤扫码可以推动与它相连的**前置步骤记录**切换状态。
|
||
|
||
触发过程如下：
|
||
|
||
1. 找到所有已启用、且目标步骤等于当前步骤的步骤关系：`produce_step_relation.to_step_id = 当前 step_id`；
|
||
2. 按 `priority`、`sort`、`id` 升序逐项处理；
|
||
3. 对每个关系，取同一订单在源步骤（`from_step_id`）的最新扫码记录；
|
||
4. 若源记录不存在或没有状态，则跳过；
|
||
5. 查找源步骤上已启用、自动触发的状态转换：
|
||
- `trigger_event = next_step_scan`
|
||
- `auto_trigger = 1`
|
||
- 当前源记录状态等于 `from_status_id`
|
||
6. 若存在多条可用转换，按以下顺序取第一条：
|
||
- `priority` 降序；
|
||
- `sort` 升序；
|
||
- `id` 升序；
|
||
7. 将源记录 `status_id` 更新为转换目标状态 `to_status_id`；
|
||
8. 无论成功或失败，均写入一条 `produce_transition_log` 流转日志。
|
||
|
||
### 5.3 “已完成”的系统含义
|
||
|
||
当前代码中没有独立的“订单完成表”或统一的订单全局完成字段。订单层面的“已完成”主要通过以下事实判断：
|
||
|
||
1. 某步骤的订单扫码记录关联的状态配置为 `is_final = 1`；
|
||
2. 在后续步骤校验前置条件时，该步骤可被视为已完成（当 `prerequisite_require_final = 1`）；
|
||
3. 当前流程末端步骤是否代表整张订单完成，取决于管理端为该步骤配置的终态及步骤关系。
|
||
|
||
因此，**订单是否已完成是流程配置驱动的结果，不是当前订单模式页面上的固定布尔状态。**
|
||
|
||
### 5.4 状态转换日志
|
||
|
||
自动状态转换会创建 `produce_transition_log`，记录：
|
||
|
||
- 被转换的源订单记录 ID 和订单号；
|
||
- 源步骤和状态、目标状态；
|
||
- 触发事件 `next_step_scan`；
|
||
- 当前扫码记录、用户、工序及关系等触发快照；
|
||
- 触发人员、IP、耗时；
|
||
- 自动触发标识；
|
||
- 成功/失败结果和异常信息。
|
||
|
||
日志用于追溯“为什么某一步状态被改动”，不直接替代订单扫码记录。
|
||
|
||
---
|
||
|
||
## 6. 数据模型与数据口径
|
||
|
||
### 6.1 主记录：`produce_scan_data`
|
||
|
||
订单模式的每次提交生成一行记录，核心字段如下：
|
||
|
||
| 字段 | 说明 |
|
||
| --- | --- |
|
||
| `id` | 记录主键 |
|
||
| `order_no` | 订单号 |
|
||
| `user_code` | 操作用户编码 |
|
||
| `operator` / `operator_id` | 操作人员快照及会员 ID |
|
||
| `process_id` / `step_id` | 执行的工序和步骤 |
|
||
| `status_id` | 当前步骤状态 |
|
||
| `scan_result` | 扫码结果：`0` 失败，`1` 成功 |
|
||
| `scan_time` | 业务扫码时间 |
|
||
| `remark` | 备注 |
|
||
| `created_at` / `updated_at` / `deleted_at` | 创建、更新、软删除时间 |
|
||
|
||
每次提交均写入当前服务器时间作为 `scan_time`。模型创建钩子也会在 `scan_time` 为空时补写当前时间，避免出现空扫码时间。
|
||
|
||
### 6.2 与整机模式的边界
|
||
|
||
整机模式写入的是 `produce_product_record`，主要字段为工序订单号、商品编码、数量、工序步骤、状态和扫码结果。
|
||
|
||
订单模式与整机模式的差异：
|
||
|
||
| 对比项 | 订单模式 | 整机模式 |
|
||
| --- | --- | --- |
|
||
| 主表 | `produce_scan_data` | `produce_product_record` |
|
||
| 主识别字段 | `order_no` | `process_order_no` + `product_code` |
|
||
| 记录粒度 | 单个订单号 | 整机/物料及数量 |
|
||
| 前置步骤校验 | 已实现 | 当前提交接口未调用同等校验 |
|
||
| 重复扫码校验 | 已实现 | 当前提交接口未调用同等校验 |
|
||
| 下一步自动状态转换 | 已实现 | 当前提交接口未触发 |
|
||
|
||
### 6.3 与异常和维修模块的边界
|
||
|
||
异常记录位于 `produce_exception_record`，维修记录位于 `produce_repair_record`。它们可按订单号与订单扫码数据建立业务关联，但当前订单模式提交成功不会自动创建异常或维修记录。
|
||
|
||
异常处理目前使用独立状态：
|
||
|
||
| 异常状态值 | 含义 |
|
||
| --- | --- |
|
||
| `0` | 待处理 |
|
||
| `1` | 处理中/待复核（不同展示位置的命名存在差异） |
|
||
| `2` | 已处理 |
|
||
|
||
维修任务列表仅筛选异常状态为 `0` 的记录，并按异常提报时间升序展示，用于优先处理较早提报的异常。该规则不等同于订单模式的步骤完成规则。
|
||
|
||
---
|
||
|
||
## 7. 最近记录与统计规则
|
||
|
||
### 7.1 最近记录
|
||
|
||
订单模式调用：
|
||
|
||
```text
|
||
GET /appapi/produce/scan-data?user_code=<当前用户>&limit=5
|
||
```
|
||
|
||
后端行为：
|
||
|
||
- 支持按订单号、工序、步骤、状态、扫码结果过滤；
|
||
- 订单模式页面实际传入用户编码和数量限制，但当前后端订单扫码过滤函数**没有使用 `user_code` 条件**；
|
||
- 记录按 `scan_time` 降序、`id` 降序返回；
|
||
- 支持分页，默认每页 10 条，单页最大 50 条；
|
||
- 返回结构包含：`items`、`total`。
|
||
|
||
> 现状说明：页面文案为“当前登录用户的最近记录”，但接口实现尚未按 `user_code` 过滤。因此，在当前实现中，该列表实际可能包含其他用户的订单扫码记录。此为文档记录的现行行为，不应被误解为已完成个人隔离。
|
||
|
||
### 7.2 统计
|
||
|
||
订单模式调用：
|
||
|
||
```text
|
||
GET /appapi/produce/scan-data/statistics?user_code=<当前用户>
|
||
```
|
||
|
||
返回字段：
|
||
|
||
| 字段 | 含义 |
|
||
| --- | --- |
|
||
| `today_total` | 查询范围内记录总数 |
|
||
| `success_total` | `scan_result = 1` 的记录数 |
|
||
| `failed_total` | `scan_result = 0` 的记录数 |
|
||
|
||
当前统计实现同样没有在订单扫码过滤函数中应用 `user_code`，因此页面虽然传入用户编码，统计口径实际并非严格的个人统计。
|
||
|
||
此外，`today_total` 这个字段名称不必然代表“今日”：
|
||
|
||
- 当基础配置 `recent_records_today_only = 1` 且未传 `order_no` 时，只计算当天 00:00:00 至 23:59:59 的记录；
|
||
- 当该配置不是 `1` 时，统计全部历史记录。
|
||
|
||
页面中“今日统计”“当前工序/步骤扫码量”的文案与当前接口传参及过滤实现并不完全一致：页面未传当前工序、步骤，接口未按用户编码过滤。实际数据范围应以服务端查询规则为准。
|
||
|
||
---
|
||
|
||
## 8. 当前端到端流程
|
||
|
||
```text
|
||
进入订单模式
|
||
↓
|
||
读取当前用户和已保存的工序/步骤选择
|
||
↓
|
||
加载启用工序、当前用户参数下的记录/统计、当前工序步骤和规则配置
|
||
↓
|
||
选择工序与步骤（可切换并保存）
|
||
↓
|
||
输入或扫描订单号
|
||
↓
|
||
加载当前上下文的配置与特定规则
|
||
↓
|
||
前端校验：订单号/工序/步骤/长度/正则/禁止型规则
|
||
↓
|
||
提交 POST /produce/scan-data/record（scan_result 固定为 1）
|
||
↓
|
||
后端校验：请求字段、会员用户、前置步骤、重复扫码
|
||
↓
|
||
创建订单扫码记录，并赋予步骤初始状态
|
||
↓
|
||
按步骤关系尝试自动推进上游步骤状态，记录流转日志
|
||
↓
|
||
返回录入成功
|
||
↓
|
||
前端提示成功，清空订单号，刷新页面数据
|
||
↓
|
||
若开启连续扫码，则自动再次发起相机扫码
|
||
```
|
||
|
||
---
|
||
|
||
## 9. 管理配置对订单模式的影响
|
||
|
||
订单模式的实际行为高度依赖管理端配置。上线或调整流程前，应至少检查下列内容。
|
||
|
||
### 9.1 工序与步骤
|
||
|
||
- 工序、步骤是否启用；
|
||
- 工序和步骤的 `sort` 是否符合现场操作顺序；
|
||
- 每一步是否正确配置前置步骤；
|
||
- `prerequisite_mode` 是否符合“全部完成”或“任意完成”的业务要求；
|
||
- 是否必须要求前置步骤终态。
|
||
|
||
### 9.2 步骤状态
|
||
|
||
- 每个可使用步骤是否配置了初始状态；
|
||
- 初始状态是否唯一、名称是否清晰；
|
||
- 哪些状态是终态（`is_final = 1`）；
|
||
- 终态是否与“可进入下步”“该步骤结束”等业务语义一致；
|
||
- 状态是否启用。
|
||
|
||
### 9.3 步骤关系和状态转换
|
||
|
||
- 是否建立从上游步骤到下游步骤的关系；
|
||
- 关系是否启用；
|
||
- 当前下游步骤扫码时，是否需要自动更新上游步骤状态；
|
||
- 状态转换是否设置：
|
||
- 源步骤；
|
||
- 源状态；
|
||
- 目标状态；
|
||
- 触发事件 `next_step_scan`；
|
||
- `auto_trigger = 1`；
|
||
- 启用状态；
|
||
- 多条转换并存时，优先级是否正确。
|
||
|
||
### 9.4 订单校验与重复策略
|
||
|
||
- 最小订单号长度是否符合现场编码；
|
||
- 正则表达式是否已在真实订单样本上验证；
|
||
- 是否允许同订单、同工序、同步骤重复扫码；
|
||
- 如允许，最短间隔是否合理；
|
||
- 是否限制只能在指定状态下重复；
|
||
- 特定规则是否正确设置应用模式、匹配字段、步骤范围和规则类型。
|
||
|
||
---
|
||
|
||
## 10. 当前实现的已知边界与风险
|
||
|
||
以下内容是当前代码已确认的边界，后续若要以“已完成订单”为核心建设功能，应优先统一定义。
|
||
|
||
1. **没有独立的全局订单完成状态。**
|
||
- 当前“完成”依赖步骤状态 `is_final` 与流程配置。
|
||
- 若需要“已完成订单列表”，需要明确：是最后一步进入终态即完成，还是所有必经步骤进入终态即完成。
|
||
|
||
2. **订单模式前端的部分校验没有在后端重复执行。**
|
||
- 最小长度、订单正则、禁止型特定规则主要在前端执行。
|
||
- 直接调用接口的客户端理论上可以绕过这些规则。
|
||
- 后续需将关键业务准入规则统一收敛至后端，前端只保留体验层预校验。
|
||
|
||
3. **最近记录与统计未实际按 `user_code` 过滤。**
|
||
- 页面传递用户编码，但服务端 `applyScanDataFilter` 未处理该字段。
|
||
- 当前页面“当前用户”相关文案与真实数据范围可能不一致。
|
||
|
||
4. **统计字段命名与口径依赖配置。**
|
||
- `today_total` 是否仅统计当日由 `recent_records_today_only` 决定。
|
||
- 页面未传工序和步骤，所以“当前工序/步骤扫码量”文案不能保证与实际查询范围一致。
|
||
|
||
5. **初始状态存在性由配置保证。**
|
||
- 若当前步骤未配置初始状态，记录可能以空状态创建，影响后续前置完成判定和自动流转。
|
||
|
||
6. **自动流转只由订单模式提交触发。**
|
||
- 整机模式当前不会执行相同的前置步骤、重复扫码和下一步骤自动流转逻辑。
|
||
|
||
7. **当前订单模式默认只提交成功结果。**
|
||
- 页面固定 `scan_result = 1`，失败记录、备注等需要通过其他页面或接口能力处理。
|
||
|
||
---
|
||
|
||
## 11. 后续建设“已完成订单”功能前的统一规则建议
|
||
|
||
若后续要增加“已完成订单”列表、详情、查询或统计，建议先由业务方确认以下定义，再实施接口和页面：
|
||
|
||
1. **完成判定对象**：
|
||
- 指定末端步骤进入终态；
|
||
- 所有必经步骤进入终态；
|
||
- 指定末端步骤成功扫码即可；
|
||
- 是否还要排除未关闭的异常或维修任务。
|
||
|
||
2. **完成时间**：
|
||
- 最后一步进入终态的时间；
|
||
- 最后一次成功扫码时间；
|
||
- 所有必经步骤均完成时的最大完成时间。
|
||
|
||
3. **同订单重工/返工**：
|
||
- 完成后是否允许再次扫码；
|
||
- 再次扫码是否撤销完成状态；
|
||
- 应使用订单维度快照还是按最新步骤记录实时计算。
|
||
|
||
4. **异常和维修的影响**：
|
||
- 待处理异常是否阻止进入已完成列表；
|
||
- 已维修但未复核的订单是否算完成；
|
||
- 维修完成后是否要回写生产步骤或重新进入某一工序。
|
||
|
||
5. **列表数据模型**：
|
||
- 运行时按 `produce_scan_data` 聚合计算；
|
||
- 或建立订单流程汇总表，以提高查询性能、固化完成时间并支持审计。
|
||
|
||
在这些规则统一前，不建议将“存在终态扫码记录”简单等同于“整张订单完成”，以免与返工、异常、维修等现场业务冲突。
|
||
|
||
---
|
||
|
||
## 12. 代码与配置定位清单
|
||
|
||
| 类型 | 位置 |
|
||
| --- | --- |
|
||
| 订单模式页面 | `frontend/scanapp/pages/entry/order.vue` |
|
||
| APP 请求封装 | `frontend/scanapp/api/produce/data-entry.js` |
|
||
| 请求基础前缀 | `frontend/scanapp/config/index.js` |
|
||
| 生产数据入口控制器 | `backend/plugin/produce/app/api/controller/DataEntryController.php` |
|
||
| APP 委托控制器 | `backend/plugin/produce/app/appapi/controller/DataEntryController.php` |
|
||
| 订单扫码模型 | `backend/plugin/produce/app/model/ScanData.php` |
|
||
| 订单扫码校验器 | `backend/plugin/produce/app/validate/ScanDataValidate.php` |
|
||
| 步骤模型 | `backend/plugin/produce/app/model/ProcessStep.php` |
|
||
| 步骤状态模型 | `backend/plugin/produce/app/model/StepStatus.php` |
|
||
| 步骤关系模型 | `backend/plugin/produce/app/model/StepRelation.php` |
|
||
| 状态转换模型 | `backend/plugin/produce/app/model/StatusTransition.php` |
|
||
| 流转日志模型 | `backend/plugin/produce/app/model/TransitionLog.php` |
|
||
| 基础表迁移 | `backend/plugin/produce/resource/database/migrations/2026_07_30_000001_create_produce_basic_tables.php` |
|
||
| 扫码记录迁移 | `backend/plugin/produce/resource/database/migrations/2026_07_31_000003_create_produce_config_and_scan_data_tables.php` |
|
||
| 插件路由配置 | `backend/plugin/produce/config/route.php` |
|