# 6-22 修复规划文档 > 基于《订单全流程软件6-22修改规划》的需求,结合当前系统代码分析,逐项拆解为可执行的修改任务。 > 每个任务包含:当前状态、目标状态、涉及文件、实现方案、验证标准。 **更新时间:2026-06-22** **状态图例:** - ✅ 已完成 — 功能已实现并通过验证 - ⚠️ 部分完成 — 前端或后端某一方已完成,另一方待完善 - ❌ 未完成 — 功能尚未实现 - 🔍 待确认 — 需要进一步验证后端逻辑 --- ## 一、业务员网页端 ### 1.1 新建订单页面 #### 任务 1:产品选择增加搜索功能 ✅ 已完成 | 项目 | 内容 | |------|------| | **当前状态** | `OrderFormPage.vue` 中产品下拉使用原生 `` 替换为带搜索输入框的自定义下拉组件:顶部一个文本输入框用于搜索过滤,下方显示匹配的产品列表。输入文字时实时过滤 `productOptions` 数组(匹配 `product_name` 或 `specification`)。选择后自动填充 `product_name`、`specification`、`unit`、`sale_price`、`cost_price`。无需引入第三方库,纯 Vue 实现。 | | **验证标准** | ① 输入关键词后列表实时过滤;② 选中产品后自动填充规格/单位/价格;③ 清空搜索框后显示全部产品 | | **完成情况** | ✅ `OrderFormPage.vue:166-187` 已实现搜索输入框+下拉过滤组件,支持按产品名称/规格模糊匹配,选择后自动填充所有字段 | --- #### 任务 2:产品明细区域增加成本核算提示 ✅ 已完成 | 项目 | 内容 | |------|------| | **当前状态** | 产品明细板块无任何提示说明 | | **目标状态** | 在产品明细板块标题后增加提示文字:"此处属于成本核算区域,需要根据实际的货物选择对应的规格" | | **涉及文件** | `frontend/web-sales/src/views/OrderFormPage.vue` | | **实现方案** | 在"客户需求"板块的产品列表标题旁增加一个灰色提示文字 `

`。纯文本展示,不影响功能。 | | **验证标准** | 提示文字在产品列表上方清晰可见 | | **完成情况** | ✅ `OrderFormPage.vue:158` 已有灰色提示文字 `此处属于成本核算区域,需要根据实际的货物选择对应的规格`,样式类 `.hint-text-cost` | --- #### 任务 3:产品规格后增加计算逻辑说明 ✅ 已完成 | 项目 | 内容 | |------|------| | **当前状态** | 规格字段只显示结果,无计算过程 | | **目标状态** | 在规格字段后面展示计算逻辑(如:长×宽×数量=面积),帮助业务员理解价格来源 | | **涉及文件** | `frontend/web-sales/src/views/OrderFormPage.vue`、`backend/app/services/pricing_engine.py`(可选)| | **实现方案** | **方案A(简单)**:在产品行的规格字段后,如果有 `surcharge_detail`(定价引擎的附加费详情),将其解析并以文字形式展示计算过程。**方案B(完整)**:后端定价引擎返回计算步骤字符串,前端直接展示。推荐方案A,改动最小。如果产品是手动填写(非定价引擎计算),则不显示计算逻辑。 | | **验证标准** | ① 通过定价引擎计算的产品,规格后显示计算过程;② 手动填写的产品不显示 | | **完成情况** | ✅ `OrderFormPage.vue:196` 规格字段后展示 `_calcHint`,内容来自 `surcharge_detail` 的解析(计价方式/公式/尺寸/面积),`OrderFormPage.vue:612-627` `handleProductChange` 中解析 `surcharge_detail` 并生成提示文本 | --- #### 任务 4:去掉含税金额字段,使用定价引擎计算 ⚠️ 部分完成 | 项目 | 内容 | |------|------| | **当前状态** | 表单中有独立的"含税金额"输入框(`form.tax_amount`),用户手动填写 | | **目标状态** | 去掉手动输入的含税金额字段,改由后台定价引擎自动计算含税价格 | | **涉及文件** | `frontend/web-sales/src/views/OrderFormPage.vue`(去掉UI)、`backend/app/services/pricing_engine.py`(已有含税计算逻辑)、`backend/app/services/order_service.py`(确认 tax_amount 计算)| | **实现方案** | ① 前端:删除"含税金额"输入框的渲染代码(约行222附近);② 后端:`order_service.py` 的 `create_order` 和 `update_order` 中,`tax_amount` 字段改为从定价引擎的含税结果自动计算(当前已有 `tax_total` 的计算逻辑,确认 `tax_amount` 是否需要独立计算)。注意:`tax_amount` 和 `tax_total` 的区别需要明确——`tax_total` 是税额,`tax_amount` 是含税总价。 | | **验证标准** | ① 前端不再显示含税金额输入框;② 创建订单后 `tax_amount` 由系统自动计算填充;③ 审批详情页能正确显示含税信息 | | **完成情况** | ⚠️ **前端已完成**:模板中已不渲染含税金额输入框。`form` 对象中仍保留 `tax_amount` 字段(`OrderFormPage.vue:375`),提交时传入但值始终为0。**后端待确认**:需确认 `order_service.py` 中 `create_order` 是否自动计算 `tax_amount`,还是依赖前端传入 | --- #### 任务 5:合同金额模块重构(收款渠道 + 发票 + 订单类型)✅ 已完成 | 项目 | 内容 | |------|------| | **当前状态** | 合同金额仅一个数字输入框;收款渠道(支付方式)在"其他信息"区域单独展示;发票是一个复选框;无订单类型字段 | | **目标状态** | 合同金额模块整合:合同金额 + 收款渠道 + 是否开发票 + 订单类型(工业订单/日用品订单)。收款渠道由管理员在后台配置。订单类型根据收款渠道自动区分电商/普通。 | | **涉及文件** | **前端**:`frontend/web-sales/src/views/OrderFormPage.vue`(UI重构);**后端**:`backend/app/models/business.py`(新增字段)、`backend/app/schemas/orders.py`(新增schema字段)、`backend/app/services/order_service.py`(新增逻辑)、`backend/app/repositories/order_repository.py`(持久化);**数据库**:新增 Alembic 迁移;**配置**:`backend/app/services/config_service.py` + `bootstrap.py`(收款渠道配置项)| | **实现方案** | **数据库层**:
① `sales_order` 表新增 `order_type` 字段(String(32),值:`industry`/`daily`,对应工业订单/日用品订单)
② `system_config` 表新增配置项 `payment_channels`(JSON数组,管理员可配置收款渠道列表及每个渠道是否为电商渠道)

**后端层**:
① `business.py` 模型增加 `order_type` 字段
② `schemas/orders.py` 增加 `order_type` 字段
③ `order_service.py` 创建/更新订单时处理 `order_type`;根据收款渠道的电商标记自动设置 `order_source`
④ 配置项 `payment_channels` 格式:`[{"name":"现金","is_ecommerce":false},{"name":"淘宝","is_ecommerce":true}]`

**前端层**:
① 合同金额区域重新布局:合同金额输入框 + 收款渠道下拉(从配置读取)+ 是否开发票复选框 + 订单类型单选(工业订单/日用品订单)
② 收款渠道选择后,如果该渠道标记为电商,自动将订单来源设为电商
③ 去掉原"其他信息"区域中的支付方式和发票复选框 | | **验证标准** | ① 收款渠道下拉选项由管理员后台配置控制;② 选择电商收款渠道后订单来源自动标记为电商;③ 订单类型(工业/日用品)保存成功;④ 报表统计可按订单类型拆分 | | **完成情况** | ✅ **数据库**:`business.py:141-143` 已有 `order_type`、`self_delivery`、`tracking_number` 字段。**前端**:`OrderFormPage.vue:222-254` 已有收款渠道下拉(从 `payment_channels` 配置读取)、是否开发票复选框、订单类型选择(工业/日用品)。`OrderFormPage.vue:708-709` 已实现根据收款渠道 `is_ecommerce` 自动设置 `order_source`。`OrderFormPage.vue:653-679` 已从后端加载 `payment_channels` 配置 | --- #### 任务 6:订单附件下方增加物流信息输入 ✅ 已完成 | 项目 | 内容 | |------|------| | **当前状态** | 新建订单表单无物流信息输入;物流信息在订单创建后由管理员分配司机时才录入 | | **目标状态** | 在订单附件下方增加"物流信息"模块,业务员可直接输入快递单号。如果业务员在新建时已填物流信息,订单跳过"下发工厂"节点,审批通过后直接进入待分配司机状态。审批时提示"马甸工厂自发"。 | | **涉及文件** | **前端**:`frontend/web-sales/src/views/OrderFormPage.vue`(新增UI);**后端**:`backend/app/services/order_service.py`(修改审批流程)、`backend/app/api/orders.py`(接收物流字段);**数据库**:`sales_order` 表或新建 `order_logistics_info` 表 | | **实现方案** | **数据库层**:
① `sales_order` 表新增 `self_delivery` 布尔字段(默认 false)和 `tracking_number` 字符串字段

**后端层**:
① `create_order` / `update_order` 接收并保存 `self_delivery` 和 `tracking_number`
② `approve_order` 中:如果订单有 `tracking_number`(已填物流信息),审批通过后状态直接变为 `pending_driver`(跳过 `pending_factory`),并生成提示"马甸工厂自发"
③ 审批通知中附带提示信息

**前端层**:
① 订单附件下方新增"物流信息"区块
② 包含:快递单号输入框(可选)、提示文字"如已填写快递单号,订单将跳过工厂下发环节"
③ 提交时将 `tracking_number` 和 `self_delivery` 随表单一起提交 | | **验证标准** | ① 填写快递单号的订单,审批通过后状态直接为 `pending_driver`;② 未填写的订单正常走 `pending_factory` 流程;③ 管理员审批时能看到"马甸工厂自发"提示 | | **完成情况** | ✅ **数据库**:`business.py:142-143` 已有 `self_delivery`(Integer,默认0)和 `tracking_number`(String(128))字段。**前端**:`OrderFormPage.vue:280-291` 已有物流信息区域,含快递单号输入框和提示文字。`OrderFormPage.vue:710-726` 提交时已将 `self_delivery` 和 `tracking_number` 包含在 payload 中。**后端审批逻辑待确认**:需验证 `order_service.py` 的 `approve_order` 是否已处理自发订单跳过工厂下发的逻辑 | --- ### 1.2 我的订单页面 #### 任务 7:英文状态全部改为中文 ⚠️ 部分完成 | 项目 | 内容 | |------|------| | **当前状态** | `OrdersPage.vue` 的 `statusTextMap` 已将状态码映射为中文,但部分地方可能仍显示英文原始值(如 API 返回的 `statusText` 字段如果为空时的 fallback) | | **目标状态** | 所有状态信息全部以中文展示,用户无任何英文阅读障碍 | | **涉及文件** | `frontend/web-sales/src/views/OrdersPage.vue`、`frontend/web-sales/src/views/OrderDetailPage.vue`(如存在)| | **实现方案** | ① 确认 `OrdersPage.vue` 中 `statusTextMap` 覆盖所有17种状态码;② 检查列表中状态列的渲染逻辑,确保 fallback 也显示中文;③ 检查订单详情页面的状态显示。`backend/app/services/order_service.py` 的 `normalize_list_filters` 已在返回数据中添加 `statusText` 字段(中文),确认前端优先使用该字段。 | | **验证标准** | 页面中不出现任何英文状态码(如 `pending_approve`、`approved` 等)| | **完成情况** | ⚠️ **前端映射完整**:`mockApi.js:63-84` 的 `mapOrderStatus` 已覆盖全部17种状态码(含 `pending_settle`、`settled`)。但 `OrdersPage.vue:86` 显示的是 `row.status` 而非 `row.statusText`,需确认后端 `normalize_list_filters` 返回的 `status` 字段是否已是中文。如果后端返回英文原始值,则需改为 `row.statusText` 或调用 `mapOrderStatus(row.rawStatus)` | --- #### 任务 8:订单列表物流信息实时查询(快递100 API)❌ 未完成 | 项目 | 内容 | |------|------| | **当前状态** | 订单列表的"物流信息"列显示的是静态文本(来自订单记录),无法看到最新物流状态。需要点击进详情才能查看。 | | **目标状态** | 订单列表直接展示最新物流状态,调用快递100 API 查询。如果物流超时(后台配置的时间内无更新),物流信息文字变红色。 | | **涉及文件** | **前端**:`frontend/web-sales/src/views/OrdersPage.vue`(物流列渲染);**后端**:`backend/app/services/logistics_service.py`(新增快递100查询接口)、`backend/app/api/logistics.py`(新增API端点)、`backend/app/services/config_service.py`(超时配置)| | **实现方案** | **后端层**:
① 新增 API 端点 `GET /api/logistics/trace-by-tracking?tracking_number=xxx`,调用快递100 API 查询最新物流状态
② 返回:`{status, latest_update, update_time, is_timeout}`
③ 超时判断:`update_time` 距今超过配置的 `logistics_timeout_hours` 则 `is_timeout=true`
④ 如已有快递100集成(`logistics_trace_provider` 配置为 `kdniao`),复用现有逻辑;否则新增

**前端层**:
① 订单列表加载后,对有快递单号的订单批量查询最新物流状态
② 物流信息列渲染:正常状态显示黑色文字,超时状态显示红色文字
③ 考虑性能:列表分页时每页最多20条,逐条查询可接受;或后端提供批量查询接口 | | **验证标准** | ① 有快递单号的订单显示最新物流状态;② 超时的物流信息文字为红色;③ 无快递单号的订单不显示物流信息 | | **完成情况** | ❌ **未实现**。`OrdersPage.vue:85` 物流信息列只显示 `row.logisticsInfo` 静态文本,无快递100 API 调用,无超时红色标记逻辑。后端 `logistics_service.py:1226` 已有快递100集成(`_fetch_kuaidi100_traces`),`config.py:72-75` 已有快递100配置项,但前端未对接。需新增按 `tracking_number` 查询的 API 端点 + 前端实时查询逻辑 | --- #### 任务 9:订单列表增加分页大小选择 ✅ 已完成 | 项目 | 内容 | |------|------| | **当前状态** | 分页大小硬编码为20,只有上一页/下一页按钮 | | **目标状态** | 用户可选择每页显示多少条数据(如 10/20/50/100)| | **涉及文件** | `frontend/web-sales/src/views/OrdersPage.vue` | | **实现方案** | ① 在分页栏增加一个 `